Tradicionalmente, os requisitos são vistos como instruções de texto que se encaixam em uma das categorias mencionadas em Conceito: Requisitos. Cada requisito indica "uma condição ou um recurso com o qual o sistema deve estar em conformidade".

Para desempenhar um Gerenciamento de Requisitos eficiente, nós aprendemos que isso ajuda a estender o que mantemos como requisitos somente além dos "requisitos de software" detalhados.  Introduzimos a noção de tipos de requisitos para ajudar a separar os diferentes níveis de abstração e de propósitos dos nossos requisitos. 

Convém controlarmos "desejos" ambíguos, bem como pedidos formais, dos envolvidos para certificar-nos se sabemos como eles estão sendo cuidados. O documento de Visão nos ajuda a controlar as principais "necessidades do usuário" e os "recursos" do sistema. O Modelo de Caso de Uso é uma maneira eficiente de expressar os "requisitos de software" funcionais detalhados, portanto, os casos de uso talvez precisem ser controlados e mantidos como requisitos, bem como talvez instruções individuais dentro das propriedades de casos de uso que indiquem "condições ou recursos com os quais o sistema deve estar conformidade". As Especificações Suplementares podem conter outros "requisitos de software", como restrições de design ou requisitos jurídicos ou reguladores do nosso sistema. Para uma definição completa dos requisitos de software, os casos de uso e as Especificações Suplementares podem ser empacotados juntos para definir uma SRS (Especificação dos Requisitos de Software) para um "recurso" específico ou outro agrupamento de subsistemas.

Quanto maior e mais confuso o sistema desenvolvido, mais expressões ou tipos de requisitos aparecerão e maior será o volume de requisitos. As instruções de "regras de negócios" e de "visão" para um projeto são rastreados quanto a "necessidades do usuário", "recursos" ou outros "requisitos de produto". Os casos de uso ou outras formas de modelagem e outras Especificações Suplementares conduzem os requisitos de design, que podem ser decompostos posteriormente em "requisitos de software" funcionais e não funcionais representados em modelos e diagramas de análise e design.

Informações Adicionais

Informações adicionais sobre este tópico podem ser localizadas em:

Conceito: Requisitos
Conceito: Gerenciamento de Requisitos
Conceito: Rastreabilidade
Whitepaper: Aplicando Gerenciamento de Requisitos com Casos de Uso