Introdução

Há inevitavelmente uma hierarquia de requisitos associados ao desenvolvimento do sistema, do último detalhado, o qual define a missão do sistema ou as finalidades ou objetivos do usuário de resumo do sistema, até o mais detalhado, talvez por meio de vários níveis intermediários. No nível mais detalhado, os requisitos podem ser expressos em grande parte no vocabulário da tecnologia utilizada pelo sistema; enquanto que no nível superior, normalmente, eles são expressos mais abstratamente no idioma do domínio a ser atendido pelo sistema, como capacidades, serviços, comportamentos, funções, recursos e assim por diante, a opção de palavra muitas vezes sendo arbitrária. Certamente é possível referir diferentes significados a estas palavras para ser mais preciso sobre o que está sendo expresso (por exemplo, é possível que a descrição de um comportamento específico de um sistema não revele muito sobre o objetivo ou intenção, e algum outro tipo descritivo seja necessário), mas essa não é a finalidade aqui.

O refinamento de requisitos (do nível superior, incluindo mais detalhes) pode continuar de forma meramente funcional, isto é, dividindo funções em subfunções ou subtarefas que as suportem - sem consideração com qualquer arquitetura de realização - e pode ser conduzido a um nível onde o que é descrito (onde o sistema construiu dessa forma) ocorreria de forma extrema dentro do sistema e talvez não tem comunicação direta fora do sistema. Esse seria o caso, por exemplo, em uma abordagem de análise estruturada que foi tão extrema quanto uma bolha de transformação primitiva.

Essa abordagem é pouco recomendada, primeiro, porque ela leva à identificação de itens como requisitos que não são requisitos de modo algum, mas apenas produtos de trabalho da decomposição; segundo, ela pode levar a arquiteturas simples (por exemplo, que falham ao atender ou desempenhar inadequadamente em oposição a outros requisitos não funcionais), se o designer mapear a realização bem próximo à decomposição. No entanto, há um motivo válido para realizar alguma decomposição funcional quando os objetivos de imaginação são expressos em um nível alto, ao limitar a profundidade da decomposição para capacidades ou funções compreensíveis, isto é, com detalhes o suficiente para capturar todos os comportamentos, recursos significativos e assim por diante (para os investidores), desta forma, o designer pode realizá-los de forma correta. Os requisitos aperfeiçoados (mais ou menos diretamente) dos requisitos de nível superior são um tipo de requisito derivado.

Requisitos Derivados

Aqui encontra-se um exemplo direto:

Suponha que um requisito do usuário seja "o sistema deve funcionar ao ar livre, 12 meses no ano no Alaska."

Os vários requisitos derivados são:

1. O sistema deve funcionar em temperaturas abaixo de 32 F / 0 C.
2. O sistema deve funcionar na neve.

Há outro tipo de requisito derivado. Quando os requisitos de nível do sistema foram expressos com detalhes apropriados para realização, em seguida:

• Particione o sistema (modelo) em elementos (por exemplo, utilizando os métodos OOAD).
• Determine como esses elementos trabalham em conjunto com a produção do comportamento do sistema desejado.
• Agregue os comportamentos de nível inferior da colaboração à produção dos requisitos de nível do elemento.

Tais requisitos de nível inferior são requisitos derivados; eles surgiram da união com a decomposição do sistema. Compara-se com uma abordagem funcionalmente baseada, onde o particionamento ocorre sem consideração a nenhuma decomposição de arquitetura e refinamento dos requisitos de nível do sistema, conforme descrito na introdução.

Requisitos Alocados

São requisitos que foram designados (baseados em considerações funcionais) aos componentes de um sistema, como por exemplo subsistemas de hardware ou software. Por exemplo, no nível bem superior, quando considerar sobre os requisitos de nível de missão para um sistema de sistemas, ainda pode ser apropriado elaborar tais requisitos funcionalmente, em seguida, particionar os requisitos derivados resultantes e alocar os grupos para sistemas - talvez o aperfeiçoamento adicional antes da realização. Além desse ponto, a preferência aqui é continuar como em Requisitos Derivados. Mesmo no nível de sistema de sistemas, é possível considerar a continuação dessa forma, utilizando a abordagem Modelagem de Negócios.

Observe que em uma abordagem derivada, uma decompõe o sistema em entidades e determina os requisitos de entidades, estudando como eles colaboram com o atendimento dos requisitos de nível superior. Em uma abordagem funcional e alocada, uma decompõe os requisitos e especifica as entidades que atendem os requisitos de nível inferior.

A abordagem a ser utilizada depende do contexto e das expectativas culturais e contratuais. Por exemplo, a NASA (National Aeronautics and Space Agency) [no Software Assurance Guidebook, NASA Goddard Space Flight Center Office of Safety, Reliability, Maintainability and Quality Assurance, 9/89] define os requisitos existentes em quatro níveis de detalhes:

• Nível 1, o nível da missão - são níveis bem superiores e são estabilizados bem no início.
• Nível 2, o nível do sistema (alocado) - há também a estabilidade bem no início nesse nível. Esses requisitos são derivados do nível de missão e, em seguida, alocados para segmentos.
• Nível 3, nível do subsistema (ou segmento) (derivado) - os requisitos nesse nível são derivados dos requisitos de nível do sistema alocados para o segmento.
• Nível 4, nível de item de configuração (HWCI [item de configuração de hardware] e de CSCI [item de configuração de software]) (detalhado) - novamente, alocado do nível anterior e, em seguida, aperfeiçoado.

Níveis de Requisitos e Mapeamento para RUP.

Normalmente, os contratos são lançados no Nível 3. A NASA está acostumada a lidar com os requisitos desta forma e seria normal para qualquer organização que lida com a NASA, adotar uma taxonomia semelhante. Ainda haveria a flexibilidade considerável disponível para os desenvolvedores sobre como os requisitos de nível inferior são derivados, mas determinado o nível muito alto de abstração de requisitos de nível de missão (esses são freqüentemente mais semelhantes aos requisitos de nível de programa), a derivação de requisitos de nível do sistema (e a alocação para segmentos) pode ocorrer naturalmente junto com as linhas funcionais. Mesmo assim, com o interesse em arquiteturas corporativas, é cada vez mais comum, mesmo para os requisitos do sistema, serem derivados, utilizando as considerações de arquitetura. A figura acima ilustra isso e mostra o mapeamento dos níveis NASA para produtos de trabalho do RUP (incluindo modelagem de negócios). Observe como, no processo do RUP, a alocação mostrada no fluxo tradicional é desempenhada no processo de Realização de Casos de Uso e agregação comportamental subseqüente. As linhas tracejadas azuis vinculam os produtos de trabalho em um nível semelhante.