Os diversos relacionamento e restrições que os requisitos exercem uns sobre os outros são muito difíceis de ser controlados e gerenciados. Principalmente se considerarmos que algumas decisões de design que afetam um ou mais requisitos só serão tomadas mais adiante do desenvolvimento. Por este motivo, os requisitos precisam ser gerenciados durante todo o desenvolvimento. Um exemplo simples é a decisão de requisitos de segurança mais restritos que podem ir de encontro ao requisito de melhor desempenho.
A importância e complexidade de todas as atividades relacionadas aos requisitos levaram, no início dos anos 90, ao surgimento da Engenharia de Requisitos. O objetivo desta denominação é ressaltar que o processo de definir os requisitos de software é uma atividade extremamente importante e independente das outras atividades da engenharia de software. Ela requer fundamentação e processos próprios, e que devem ser planejados e gerenciados ao longo de todo o ciclo de vida.
Os objetivos da Engenharia de Requisitos podem ser categorizados em três grupos principais [Zave]:
- Investigação de objetivos, funções e restrições de uma aplicação de software
- Ultrapassar as barreiras de comunicação
- Gerar estratégias para converter objetivos vagos em propriedades ou restrições específicas
- Compreender prioridades e graus de satisfação
- Associar requisitos com os vários agentes do domínio
- Estimar custos, riscos e cronogramas
- Assegurar completude
- Especificação do software
- Integrar representações e visões múltiplas
- Avaliar estratégias de soluções alternativas que satisfaçam os requisitos
- Obter uma especificação completa, consistente e não ambígua
- Validar a especificação - verificar que ela satisfaz aos requisitos
- Obter especificações que sejam apropriadas para as atividades de design e implementação
- Gerenciamento da evolução e das famílias do software
- Reutilização de requisitos durante o processo de evolução
- Reutilização de requisitos no desenvolvimento de software similares
- Reconstrução de requisitos
A engenharia de requisitos é inerentemente abrangente, interdisciplinar e aberta. Ela lida com a descrição de observações do mundo real através de notações apropriadas.
Os benefícios da Engenharia de Requisitos são:
- Concordância entre desenvolvedores, clientes e usuário sobre o trabalho a ser feito e quais os critérios de aceitação do sistema.
- Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos)
- Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema.
- Atingir os objetivos com o mínimo de desperdício
Uma boa especificação de requisitos deve ser:
- Clara e não-ambígua
- Completa
- Correta
- Compreensível
- Consistente
- Concisa
- Confiável
(Veja mais em Dorfman, Merlin - Requirements Engineering)
Técnicas de levantamento de requisitos
Um dos objetivos da Engenharia de Requisitos é ultrapassar barreiras de comunicação entre os clientes e usuários e os analistas para que os requisitos possam capturados e modelados corretamente.
Dentre as técnicas mais importantes para a comunicação podemos citar três:
- Entrevistas
- Observação in loco
- Encontros
Estas três técnicas são complementares e podem todas ser usadas numa mesma análise de requisitos. A entrevista é normalmente a primeira técnica utilizada. Analistas entrevistam clientes para definir os objetivos gerais e restrições que o software deverá ter. A entrevista deve ser feita de forma objetiva visando obter o máximo de informações do cliente. Diversas seções de entrevistas podem ser marcadas.
Na observação in loco os analistas devem estar inseridos na rotina de trabalho da organização tentando entender e descrever as principais atividades que são realizadas. Na observação devem ser identificadas quais as atividades podem ser automatizadas, quem são os potenciais usuários, quais tarefas eles querem realizar com a ajuda do novo sistema, etc. A observação deve ser complementada com entrevistas específicas com os futuros usuários.
Os encontros são reuniões envolvendo analistas, clientes e usuários que têm por objetivo exclusivamente realizar o levantamento de informações, a descrição dos problemas atuais e indicar metas futuras e requisitos do sistema. Os encontros devem ser realizados em um local neutro (fora da organização), coordenados por um moderador que também não deve pertencer ao grupo dos envolvidos (stakeholders) e normalmente duram de 1 a 3 dias. Nos encontros as informações que vão sendo levantadas vão sendo afixadas em painéis na sala de encontro para que possam ser analisadas e validadas pelos clientes e usuários. Ao final do encontro os analistas devem elaborar um relatório descrevendo os requisitos analisados.
Modelos de documentos de especificação de requisitos
O resultado final da análise e especificação de requisitos e das outras atividades da fase de definção deve ser apresentado aos clientes para que eles possam validá-lo. Este documento oferece a concordância entre clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. É utilizando este documento que as atividades da fase de desenvolvimento (design e programação) serão validadas.
Cada desenvolvedor utiliza um modelo específico para elaborar este documento. A sua estrutura muitas vezes depende do método que está sendo utilizado. Em linhas gerais este modelo deve ser basicamente textual, utilizando o mínimo de termos técnicos, e ilustrados como modelos gráficos que demonstrem mais claramente a visão que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.
Vamos apresentar, a seguir, dois modelos de documentos encontrados na literatura. Estes modelos descrevem não apenas a especificação dos requisitos, mas os resultados do estudo de viabilidade e o processo de desenvolvimento.
Pressman apresenta o seguinte documento de especificação de requisitos de software:
I. Introdução
1. Referências do Sistema
2. Descrição Geral
3. Restrições de projeto do software
II. Descrição da Informação
1. Representação do fluxo de informação
a. Fluxo de Dados
b. Fluxo de Controle
2. Representação do conteúdo de informação
3. Descrição da interface com o sistema
III Descrição Funcional
1. Divisão funcional em partições
2. Descrição funcional
a. Narativas
b. Restrições/limitações
c. Exigências de desempenho
d. Restrições de projeto
e. Diagramas de apoio
3. Descrição do controle
a. Especificação do controle
b. Restrições de projeto
IV. Descrição Comportamental
1. Estados do Sistema
2. Eventos e ações
V. Critérios de Validação
1. Limites de desempenho
2. Classes de testes
3. Reação esperada do software
4. Considerações especiais
VI. Bibliografia
VII Apêndice
Uma proposta alternativa é a de Farley. De acordo com ele, um documento de especificação de requisitos deve possui as seguintes seções:
- Visão geral do produto e Sumário
- Ambientes de desenvolvimento, operação e manutenção
- Interfaces Externas e Fluxo de Dados
- Requisitos Funcionais
- Requisitos de Desempenho
- Tratamento de Exceções
- Prioridades de Implementação
- Antecipação de mudanças e extensões
- Dicas e diretrizes de Design
- Critérios de aceitação
- Índice Remissivo
- Glossário
Dorfman, Merlin - Requirements Engineering
Zave, Pamela - Classification of Research Efforts in Requirements Engineering - ACM Computing Surveys, vol. 29, no 4, 1997.
Comentários