1. Documento de Requisitos
1.1. Declaração oficial do que os desenvolvedores do sistema devem implementar
1.1.1. Deve conter todos os requisitos do sistema
1.1.1.1. Comunicação clara e descrição precisa
1.2. Diversos leitores, de diversas áreas
1.2.1. Clientes
1.2.1.1. Satisfação das necessidades
1.2.2. Gerentes
1.2.2.1. Controle da proposta, do orçamento e do desenvolvimento
1.2.3. Engenheiros
1.2.3.1. Entendimento do sistema a ser desenvolvido
1.2.4. Engenheiros de Testes
1.2.4.1. Entendimento do que será testado no sistema, e elaboração dos testes de validação
1.2.5. Engenheiros de Manutenção
1.2.5.1. Entendimento das partes do sistema e seus relacionamentos
2. Especificação de Requisitos
2.1. Documento de Requisitos
2.2. Requisitos claros e inequívocos
2.2.1. Difícil de conseguir
2.2.1.1. Interpretações e Inconsistências
2.3. Requisitos de Usuário
2.3.1. Funcionais e Não Funcionais
2.3.2. Linguagem simples
2.4. Requisitos de Sistema
2.4.1. Versão Expandida
2.4.2. Completos e detalhados
2.4.3. Ponto de Partida
2.4.4. Atendimento dos requisitos pelo sistema
2.5. Especifcações estruturadas
2.5.1. A linguagem estruturada é uma forma de escrever os requisitos de maneira limitada e padronizada
2.5.1.1. Utilização de templates (Cards do método VOLERE de engenharia de requisitos)
2.5.1.1.1. Prós: Elimina alguns dos problemas de especificação em linguagem natural. Reduz-se a variabilidade na especificação, e os requisitos são organizados de forma mais eficaz. Contras: Torna dificil escrever os requisitos de forma clara e inequívoca, especialmente quando processamentos complexos
2.6. Especificação em Linguagem Natural
2.6.1. Prós
2.6.1.1. Expressiva
2.6.1.2. Intuitiva
2.6.1.3. Universal
2.6.2. Contras
2.6.2.1. Potencialmente vaga
2.6.2.2. Ambígua
2.6.2.3. Significado depende do conhecimento do leitor
2.6.3. Minimizar Mal-Entendidos
2.6.3.1. Padronização
2.6.3.2. Linguagem Consistente
2.6.3.3. Destaque
2.6.3.4. Evitar Linguagem Técnica, Acrônimos e Siglas
2.6.3.5. Associação Lógica dos Requisitos
3. Nível de detalhes
3.1. Depende do tipo de software e da abordagem de desenvolvimento
3.1.1. Menos detalhes
3.1.1.1. Abordagem evolutiva: foco é a definição de requisitos do usuário e de requisitos não- funcionais
3.1.1.2. Processo interno de desenvolvimento iterativo: pode ser menos detalhado e ambiguidades são resolvidas durante o desenvolvimento
3.1.2. Mais detalhes
3.1.2.1. Sistema de grande porte, que inclui interações entre software e hardware
3.1.2.2. Sistemas críticos (que envolve segurança e proteção)
3.1.2.3. Desenvolvidos por companhia separada, como outsourcing
4. Problemas na elaboração
4.1. Muita demanda para pouco tempo
4.1.1. Muitas mudanças nos requisitos que o torna desatualizado no momento em que foi finalizado
4.1.1.1. Esforço disperdiçado
4.1.1.2. Alternativa: Extreme Programming
4.1.1.2.1. Coletam os requisitos de forma incremental e os escrevem em cartões como estórias de usuários
4.1.1.2.2. Pequenos documento de apoio com foco nos requisitos de negocio e confiança