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

Introduzimos a noção de tipos de requisitos para ajudar a separar os diferentes níveis de abstração e de finalidades dos nossos requisitos. 

Especificações de Requisitos de Software ../../artifact/ar_tstste.htm -- This hyperlink in not present in this generated website Modelo de Design Especificação Suplementar Modelo de Casos de Uso Pedidos do Investidor Visão Conceitos: Requisitos

Convém controlarmos "desejos" ambíguos, bem como pedidos formais, dos investidores para nos certificar se sabemos como eles estão sendo cuidados. O documento Vision nos ajuda a controlar as principais "necessidades dos usuários" e os "recursos" do sistema. O modelo de casos 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 as "condições ou recursos com as quais o sistema deve estar de acordo". 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 obter uma definição completa dos requisitos de software, casos de uso e Especificações Suplementares podem ser empacotados juntos para definir uma SRS (Especificação de Requisitos de Software) para um determinado "recurso" 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. Instruções de "regras de negócios" e de "visão" para um projeto são rastreadas para as "necessidades dos usuários", "recursos" ou outros "requisitos do produto". 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:

Conceitos: Requisitos
../../../papers/apprmuc.htm -- This hyperlink in not present in this generated websiteWhite Paper: Applying Requirements Management with Use Cases



Rational Unified Process   2003.06.15