Os requisitos de software consistem num conjunto de características necessárias à aceitação de um software por parte do cliente, descrevendo quais atividades o software deve desempenhar, quais suas limitações e restrições, além de outras características não ligadas diretamente às funções desempenhadas pelo software. Logo, tratam-se da descrição das funções e restrições do sistema (SOMMERVILLE, 2003), seu fluxo de informações, comportamento e atributos (PETERS, 2001).
Em suma, o requisito de sistema fornece uma estrutura básica para o desenvolvimento de um software. Alguns dos problemas mais críticos do processo de desenvolvimento de software estão relacionados às etapas de especificação e gerenciamento dos requisitos. Conseqüentemente, temos requisitos que não atendem adequadamente às necessidades dos clientes e algumas das razões para este insucesso são: falta de processos de desenvolvimento bem definidos; requisitos de software não bem compreendidos e acordados; uso de técnicas inadequadas; falta de uma ferramenta de apoio adequada e a própria complexidade dos softwares a serem desenvolvidos (PAULA, 2001). Em relação aos requisitos, um problema bastante comum refere-se a sua instabilidade. A instabilidade está relacionada a alterações em requisitos já acordados ou inclusão de novos requisitos durante o processo de desenvolvimento. Essas alterações ocorrem, principalmente, em função de problemas durante a etapa de especificação do sistema a qual raramente é conduzida de forma adequada. O retrabalho é a conseqüência imediata da instabilidade dos requisitos, o que impacta diretamente no prazo do projeto e na qualidade do produto final (PAULA, 2001).
Em suma, o requisito de sistema fornece uma estrutura básica para o desenvolvimento de um software. Alguns dos problemas mais críticos do processo de desenvolvimento de software estão relacionados às etapas de especificação e gerenciamento dos requisitos. Conseqüentemente, temos requisitos que não atendem adequadamente às necessidades dos clientes e algumas das razões para este insucesso são: falta de processos de desenvolvimento bem definidos; requisitos de software não bem compreendidos e acordados; uso de técnicas inadequadas; falta de uma ferramenta de apoio adequada e a própria complexidade dos softwares a serem desenvolvidos (PAULA, 2001). Em relação aos requisitos, um problema bastante comum refere-se a sua instabilidade. A instabilidade está relacionada a alterações em requisitos já acordados ou inclusão de novos requisitos durante o processo de desenvolvimento. Essas alterações ocorrem, principalmente, em função de problemas durante a etapa de especificação do sistema a qual raramente é conduzida de forma adequada. O retrabalho é a conseqüência imediata da instabilidade dos requisitos, o que impacta diretamente no prazo do projeto e na qualidade do produto final (PAULA, 2001).
Entretanto, mesmo que a especificação de requisitos seja realizada de forma adequada é natural que ao longo do ciclo de vida do software sejam necessárias alterações nos requisitos do sistema em função da necessidade de manutenções corretivas e evolutivas (PRESSMAN, 2001). Por isso, é extremamente importante que todos os requisitos tenham sido adequadamente documentados e mantidos. É baseando-se na especificação dos requisitos que o profissional ou equipe que prestara a manutenção poderá minimizar os riscos de causar impacto não desejado em outras partes do sistema (SOMMERVILE, 2003).
Além disso, durante o desenvolvimento de softwares de grande porte e alta complexidade inevitavelmente teremos alterações nos requisitos. Nestes casos, podemos considerar que os requisitos são necessariamente incompletos durante o processo de desenvolvimento. O problema inicialmente levantando amadurece e acaba sendo compreendido com mais clareza durante o desenvolvimento, ocasionando a necessidade de alterações nos requisitos (SOMMERVILLE, 2003).
Assim, tão importante quanto à especificação adequada dos requisitos é realização constante de um eficaz processo de gerenciamento dos requisitos. O gerenciamento de requisitos visa compreender e controlar as mudanças nos requisitos de software, garantindo um melhor controle sobre estas mudanças e minimizando os riscos de impactos não desejados e não conhecidos (SOMMERVILLE, 2003).
A FIGURA 1 tem sido utilizada no mercado e na academia, pois ilustra de forma bem humorada os inúmeros problemas possíveis durante o processo de especificação e gerenciamento de requisitos:
FIGURA 1 – Possíveis problemas durante o processo de requisitos (DAGNONE, 2009)
Como ilustrado na FIGURA 1, muitos softwares que hoje são utilizados no mercado resultaram de projetos problemáticos nos quais nenhuma ou pouca documentação foi gerada. Conseqüentemente, é possível que a sua manutenção seja difícil e onerosa (PETERS, 2001).
Entretanto, estes softwares ainda são comercializados, representando grande parte da receita das empresas desenvolvedoras, e utilizados por muitos clientes que, após sucessivas atualizações e modificações, têm as suas necessidades atendidas.
Em razão disso, é extremamente importante que as empresas que realizam constantemente manutenção de software possuam todos os requisitos documentados e gerenciem efetivamente esses requisitos a fim de otimizar e qualificar o processo de manutenção garantindo, assim, maior qualidade e confiabilidade nas novas versões entregues aos clientes.
Referências Bibliográficas
DAGNONE, Donaldo M. How Projects Really Work (Version 1.5).Disponível em: <http://www.projectcartoon.com/cartoon/611>. Acesso em: 5 mar. 2009.
PAULA, Wilson de Pádua Filho. Engenharia de Software: Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.
PETERS, James F.; Pedrycz, Wiltold. Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 2001.
PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5th ed. New York: McGraw-Hill, 2001.
SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
A complexidade de um sistema (com referência ao post do Marcelo)
ResponderExcluirNota-se, com o assunto deste post, a necessidade de uma compreensão
da real necessidade do cliente. Uma vez não alinhada as técnicas e ferramentas de
desenvolvimento com a funcionalidade esperada, torna-se mais trabalhoso
e o sistema perde em eficiência.
Acredito que antes da equipe, de desenvolvimento / manutenção, iniciar os
trabalhos, há a necessidade do Consultor em conjunto ao Analista de Sistemas
colher as informações do cliente de forma extremamente pragmática. Focando
sempre no resultado esperado por cada módulo ou recurso do, futuro, sistema.
Apartir desse ponto consegue-se definir a ferramenta e as técnicas a serem
utilizadas, garantindo ao sistema funcionalidade, integridade e maior otimização.
Bem como diminuindo futuros "bug's"(dores de cabeça) e custos desnecessários.
A matéria também deixa legível a precisão de elaborar uma documentação
detalhada e completa de todas funcionalidades esperadas (com prévia visualização
e acordo com o cliente), com as técnicas utilizadas bem como a visão geral do sistema.
Esta normalmente vista através de um diagrama de todo o projeto.
Thiago Corrêa
Thiago.
ResponderExcluirObrigado pela opinião.
Concordo plenamente com você e meu maior interesse é conseguirmos expandir os assuntos e discussões principalmente sobre as etapas que vem antes da devida construção do software.
Visando seguir um melhor ciclo de vida de software é necessário que este trabalho do analista de negócio e também do analista de sistemas seja concebido antes de chegarmos à construção do software. Isto aumenta significametivamente a qualidade de software e seu produto final.
Em breve, pretendo postar tópicos sobre modelos de qualidade que justamente visam orientar as etapas do processo de desenvolvimento, principalmente as etapas que antecedem à sua construção.
Certo Marcelo.
ResponderExcluirFicarei acompanhando os assuntos de seu blog e participarei sempre que possível. Aquecendo as discussões, visando a construção e divulgação de conhecimentos.
Deixo os parabéns pela iniciativa.
Thiago Corrêa