Diretriz: Decisões Importantes em Requisitos

Decidir Como Utilizar Produtos de Trabalho

Decida sobre quais produtos de trabalho devem ser utilizados e como utilizar cada um deles. Além de identificar quais produtos de trabalho devem ser utilizados, também é importante ajustar cada produto de trabalho a ser utilizado deforma a atender às necessidades do projeto.

A tabela a seguir especifica quais produtos de trabalho de Requisitos são recomendados e quais são considerados opcionais (ou seja, apenas podem ser utilizados em determinados casos). Para conhecer considerações de ajuste adicionais, consulte a seção de ajuste da página de descrição do produto de trabalho.

Produto de Trabalho	Finalidade	Adaptação (Opcional, Recomendada)
Produto de Trabalho: Modelo de Caso de Uso (Produto de Trabalho: Agente, Produto de Trabalho: Caso de Uso, Produto de Trabalho: Pacote de Caso de Uso)	Os casos de uso são usados para definir requisitos funcionais.	Recomendada para a maioria dos projetos. Os casos de uso são o método recomendado para a obtenção de requisitos funcionais.
Produto de Trabalho: Esboço Seqüencial	Os projetos com requisitos comportamentais que efetivamente não são compreendidos devem considerar o Esboço Seqüencial como um meio para obter os requisitos.	Opcional Outras técnicas de obtenção de requisitos podem ser utilizadas.
Produto de Trabalho: Glossário	Garante que todos no projeto estejam usando um vocabulário comum.	Recomendada para a maioria dos projetos.
Produto de Trabalho: Atributos de Requisitos	Um banco de dados de atributos de requisitos ajuda a garantir que os requisitos sejam priorizados, controlados e rastreados corretamente.	Opcional No entanto, em projetos com poucos requisitos, um banco de dados de atributos de requisitos talvez não seja estritamente necessário.
Produto de Trabalho: Plano de Gerenciamento de Requisitos	Descreve as informações a serem coletadas e os mecanismos de controle a serem usados para medir, relatar e controlar mudanças nos requisitos de produtos. Será preciso um documento separado se isso se fizer necessário pela complexidade do gerenciamento de requisitos ou pela visibilidade do cliente.	Opcional Projetos com poucos requisitos podem adotar uma abordagem reduzida em relação ao gerenciamento de requisitos, que poderão ser registrados diretamente no Plano de Desenvolvimento de Software. Outros projetos podem selecionar e seguir uma abordagem mais rigorosa, mas fornecendo pouca ou nenhuma descrição formal. Por exemplo, o conjunto de atributos de requisitos a serem reunidos poderá ser documentado de forma implícita pela configuração das ferramentas.
Produto de Trabalho: Especificação de Requisitos de Software	Usado para reunir o conjunto de todos os requisitos em um documento formal fornecido ao cliente.	Opcional Em projetos menos formais, talvez não seja necessário um documento formal.
Produto de Trabalho: Pedidos dos Envolvidos	Captam todas as solicitações feitas no projeto e a forma como elas foram apresentadas.	Recomendada para a maioria dos projetos. Para criar um sistema que atenda às necessidades dos envolvidos, é importante buscar solicitações e revisá-las. Muitos projetos gerenciam as Solicitações dos Principais Envolvidos apenas como uma categoria de Solicitações de Mudança. Outros projetos podem captar essas solicitações apenas informalmente.
Produto de Trabalho: Especificações Suplementares	Usadas para captar requisitos não-funcionais.	Recomendada para a maioria dos projetos.
Produto de Trabalho: Visão	Capta requisitos de nível alto e restrições de design para que o leitor compreenda o sistema a ser desenvolvido.	Recomendada para a maioria dos projetos.

Decidir quais Relatórios Utilizar

A decisão sobre os relatórios a serem utilizados depende das ferramentas de relatório disponíveis para o projeto. Se as ferramentas de geração de relatórios estiverem disponíveis, recomenda-se gerar relatórios para produtos de trabalho orientados a modelos ou a bancos de dados, como Casos de Uso e Agentes. Os relatórios existentes na configuração do RUP estão disponíveis nas páginas de descrição do produto de trabalho ou agrupados sob o produto de trabalho relevante no navegador de árvore.

Decidir Como Manter "Requisitos de Entrada"

Esta seção se aplicará somente se um contrato formal ou um documento padrão ou de especificações estiver impondo requisitos ao esforço de gerenciamento de requisitos. Isso é chamado de "especificação de requisitos de entrada".

Durante o esforço de requisitos, você captura os requisitos nestes documentos: Produto de Trabalho: Visão, Produto de Trabalho: Pedidos dos Envolvidos, Produto de Trabalho: Modelo de Caso de Uso, Produto de Trabalho: Especificações Suplementares.

Decida se manterá ou não a especificação de requisitos de entrada. Você voltará e atualizará a especificação de requisitos de entrada quando descobrir que um requisito está danificado, incorreto ou com erros? Você também deve decidir como manter o traces or references between the input requirement specification and the Produto de Trabalho: Caso de Uso.

Escolha uma ou várias destas estratégias:

Não atualizar a especificação de requisitos de entrada. Deixar que os Casos de Uso e a Especificação Suplementar especifiquem o que o sistema executará daqui em diante.
Não atualizar a especificação de requisitos de entrada, mas manter o retorno da Rastreabilidade dos casos de uso.
Atualizar a especificação de requisitos de entrada com todo o trabalho e os custos envolvidos.
Deixar que a especificação de requisitos de entrada se torne uma Especificação Suplementar que contenha requisitos não-funcionais. Os requisitos de entrada funcionais são simplesmente transferidos para os casos de uso.

Na maioria dos projetos, o número de requisitos inválidos, com erros ou incorretos é tão grande que não faz sentido manter a especificação original dos requisitos de entrada. Pouquíssimos projetos têm clientes dispostos a pagar pelo trabalho de atualização da especificação de requisitos de entrada com as novas informações reveladas durante a modelagem de casos de uso.

Não chame a atenção para esse tópico cedo demais. No início de um projeto, as pessoas ainda acreditam na especificação de requisitos inicial. Porém, depois de passar por problemas com um caso de uso, a maioria delas tem uma idéia completamente diferente dessa especificação.

Decidir Como Aprovar Casos de Uso

Decida como aprovar os casos de uso. É possível economizar bastante tempo limitando o número de casos de uso a serem formalmente revisados pelo cliente. Talvez seja aceitável para o cliente revisar formalmente apenas um subconjunto de todos os casos de uso.

Escolha uma ou mais destas estratégias:

Todos os casos de uso deverão passar por revisões formais externas com representantes externos ao projeto.
Alguns casos de uso secundários poderão ser aprovados de forma simplificada, através de uma revisão informal ou formal interna.

Casos de uso secundários são aqueles essenciais ao sistema, mas não à tarefa do usuário principal. Por exemplo, casos de uso relacionados à administração e à manutenção do sistema, como incluir usuários no sistema, alterar a autoridade deles e criar backups. Embora esses casos de uso não sejam o interesse principal dos usuários, o sistema não funcionará sem que estejam presentes.

A estratégia adotada dependerá do seu relacionamento com o cliente. Será que eles confiam na sua capacidade de desenvolver corretamente os casos de uso de suporte sem um processo de aprovação formal? Embora isso possa economizar bastante tempo, você atingirá a qualidade desejada do modelo de casos de uso?

Nota: uma solução para o problema pode ser envolver o cliente no esforço de Requisitos. Se os representantes do cliente estiverem envolvidos, eles poderão aprovar ou fornecer recomendações para outros clientes. Além disso, quando o cliente é envolvido, o projeto ganha credibilidade.

Para obter informações adicionais sobre níveis de revisão, consulte Diretriz: Níveis de Revisão.