Diretrizes: Decisões Importantes em Requisitos

As seguintes decisões devem ser tomadas em relação ao fluxo de trabalho da disciplina Requisitos:

Parte do fluxo de trabalho	Comentários
Casos de uso	Alguns projetos não usam casos de uso, o que significa que não desenvolverão artefatos como Modelo de Casos de Uso, Pacote de Casos de Uso e Caso de Uso. Nesse caso, use a Especificação de Requisitos de Software.
Design da interface do usuário	Em alguns projetos, opta-se por não projetar a interface do usuário. Essa decisão pode ser decorrente da facilidade com que ela é desenvolvida. Se você decidir não projetar a interface de usuário, a Encenação de Caso de Uso e o Protótipo da Interface do Usuário não serão desenvolvidos.
Detalhamento do Fluxo de Trabalho: Gerenciar Requisitos Variáveis	Esta parte pode ser incluída após algumas iterações no projeto, quando houver uma baseline estável.

Documente as decisões no Caso de Desenvolvimento, no tópico Disciplinas, Requisitos, Disciplina.

Decidir Como Usar Artefatos

Decida os artefatos a serem usados e como usar cada um deles. A tabela abaixo descreve os artefatos que você obrigatoriamente deve ter e os que são usados apenas em alguns casos. Para obter informações mais detalhadas sobre como adaptar cada artefato e conhecer as vantagens e desvantagens de cada um deles, consulte a seção "Adaptação" para cada artefato desejado.

Para cada artefato, decida como ele deverá ser usado: Obrigatório, Recomendável, Opcional ou Desnecessário. Para obter mais detalhes, consulte Diretrizes: Classificação de Artefatos.

Artefato	Finalidade	Adaptação (Opcional, Recomendada)
Modelo de Casos de Uso (Ator ,Caso de Uso ,Pacote de Casos 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.
Encenação de Caso de Uso, Classe de Fronteira	Projetos com uma interface de usuário grande e complexa devem considerar a modelagem e o design dessa interface.	Opcional A modelagem e a criação de um protótipo mais informal podem ser suficientes em esforços de desenvolvimento menores.
Glossário	Garante que todos no projeto estejam usando um vocabulário comum.	Recomendada para a maioria dos projetos.
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.
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 flexível 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.
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.
Solicitações dos Principais 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.
Especificações Suplementares	Usadas para captar requisitos não-funcionais.	Recomendada para a maioria dos projetos.
Protótipo da Interface do Usuário	Usado para expor e testar a funcionalidade e a usabilidade antes do início efetivo do desenvolvimento. É um meio eficaz de identificar requisitos ausentes e defeitos de requisitos antes que mais tempo seja desperdiçado.	Recomendada para a maioria dos projetos.
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 os Relatórios a Serem Usados

Decida os relatórios a serem usados. Como ponto de partida, use estes relatórios:

Decidir Como Manter Requisitos de Entrada

Esta seção aplica-se somente se um contrato formal ou um documento padrão ou de especificações estiver impondo requisitos ao esforço de gerenciamento de requisitos. Esse documento é conhecido como "especificação de requisitos de entrada".

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 precisa decidir como os rastreamentos ou as referências entre a especificação de requisitos de entrada e os casos de uso serão mantidos.

Na maioria dos projetos, o número de requisitos danificados, com erros ou incorretos é tão grande que não faz sentido manter a especificação original de 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 revisados formalmente pelo cliente. Talvez seja aceitável para o cliente revisar formalmente apenas um subconjunto de todos os casos de uso.

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?

Observação: 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.