1. Requisito das partes interessadas
1.1. As partes interessadas devem fornecer informação e feedback quanto aos requisitos apresentados.
2. Domínio do problema
2.1. Ponto de partida;
2.2. Buscar entendimento para desenvolver a solução.
3. Requisito da solução
3.1. Dizem respeito a resolução de conflitos, eliminação das lacunas de informação e aproveitamento das oportunidades de racionalização.
3.2. É usada para identificar especificações incompletas.
3.3. Processo geral de desenvolvimento de requisitos:
3.3.1. 1. Organizar os requisitos em um escopo;
3.3.2. 2. Desenvolver os requisitos, resolver conflitos, eliminar redundâncias, superar lacunas de informação e detalhar requisitos da solução;
3.3.3. 3. fechar um pacote de requisitos para encaminhar as especificações para atualizar a arquitetura; implementar e testar as unidades que compõem o softwarwe.
4. Requisitos de transição
4.1. Permitem que a solução seja desenvolvida, porém são descartados após a solução final.
5. Requisitos funcionais
5.1. Descrevem o comportamento que o software deve ter.
5.2. A maior ou menor abrangência na descrição do comportamento esperado do software em uma especificação funcional é chamada de nível de granularidade.
5.3. Requisitos funcionais com objetivo de usuário
5.3.1. Responsável por garantir a satisfação do usuário ao cumprir seu objetivo.
5.4. Requisitos funcionais com objetivo agregador
5.4.1. Agregam vários objetivos de usuários individuais em uma unica especificação de alto nível; Abrangência no nível de objetivos colaborativos.
5.4.2. Requisitos de negocio X Requisitos agregadores: embora parecidos, enquanto os requisitos de negócio geralmente visam resolver um problema, os requisitos agregadores procuram deixar o usuário satisfeito.
5.5. Requisitos funcionais com objetivo de subfunção
5.5.1. Passos e regras que isoladamente não atendem o objetivo do usuário, porém quando conjuntas podem guiar o mesmo até seu objetivo, sendo assim uma subfunção.
6. Requisitos não funcionais:
6.1. Limitações de ordem geral aos requisitos funcionais, complementam as especificações do software.
6.2. Estabelecem níveis de serviço para que o software funcione bem.
6.3. Costumam ser padronizados.
7. Requisitos não funcionais se manifestam de uma forma geral, já os funcionais de forma mais especifica.
8. Requisitos de negócios
8.1. Razões, metas e métricas do projeto; Necessidades das organizações; Problemas a resolver.
8.2. Método SMART (avalia a validade dos objetivos)
8.2.1. eSpecífico: Algo que apresenta um resultado observável.
8.2.2. Mensurável: Resultados passíveis de acompanhamento.
8.2.3. Alcançável: as necessidades do negócio consideram a viabilidade do investimento.
8.2.4. Relevante: alinhadas com a visão, a missão e os objetivos da organização.
8.2.5. Tempestivo: janela de tempo definida consistente com as oportunidades ou problemas associados.