Quais as características de uma boa especificação de requisitos de software?

Requisitos devem ser...

Completos. Nenhum requisito ou informação necessária deve estar faltando. É certo que requisitos “esquecidos” são difíceis de identificar mas às vezes o analista sabe de antemão que certas informações estão faltando. Assinale estas lacunas com uma nota ASD (“a ser determinado”) para tornar visível a omissão até que a informação seja obtida.

Consistentes. Conflitos internos entre requisitos devem ser resolvidos antes que o desenvolvimento comece.

Corretos. Cada requisito deve reportar de maneira precisa as necessidades do cliente. Apenas os clientes ou seus representantes podem determinar isto, motivo pelo qual é essencial que os mesmos participem das revisões do documentos gerados pela atividade de especificação.

Viáveis. Deve ser possível implementar todos os requisitos considerando-se as identificadas restrições e limitações do sistema e seu ambiente.

Modificáveis. Para corretamente gerenciar requisitos nós devemos ser capazes de manter o histórico das mudanças feitas em cada requisito. Isto implica que cada requisito seja unicamente rotulado de forma que possa ser referenciado sem ambiguidade.

Necessários. Cada requisito deve documentar alguma coisa que o cliente realmente precisa. Evite a tentação de “dourar o prato” na hora de especificar os requisitos através da inclusão de recursos que os desenvolvedores “tem certeza que os clientes vão adorar”.

Priorizados. Atribua uma prioridade de implementação para cada requisito. Se os requisitos são todos igualmente importantes então o analista tem sua capacidade de negociação diminuída na hora em que ele tem que reagir a novos requisitos que são propostos, a cortes de orçamento, prazos perdidos ou perda de staff. Considere uma classificação de requisitos em três níveis de prioridade:

Alta: deve estar presente na versão 1.0

Média: pode ser deixado para uma versão subsequente

Baixa: seria interessante ter mas pode-se viver sem ele

Investigáveis. É importante ser capaz de ligar cada requisito de software a sua fonte (um requisito de sistema de alto nível, um use case, etc). Também se deseja ser capaz de ligar cada requisito de software a elementos do design, elementos do código fonte e test cases que são construídos para implementar e verificar os requisitos.

Sem ambiguidade. Ambiguidade em requisitos é um problema grave. O único modo de garantir que ambiguidade vai ficar de fora é solicitar que um grupo de pessoas representando diferentes perspectivas inspecionem os requisitos como um time. Simplesmente circular o documento com a especificação dos requisitos para comentários provavelmente não revelará ambiguidades. Se uma declaração de requisito é interpretada de diferentes maneiras por diferentes revisores mas ela faz sentido para cada revisor a ambiguidade nunca virá a tona (na verdade, virá à tona em um momento posterior do projeto, quando o custo para corrigir o erro será muito maior).

Verificáveis. Examine cada requisito para tentar identificar se você pode criar um pequeno número de testes ou usar outras técnicas de verificação como inspeção ou demonstração para determinar se o requerimento foi propriamente implementado. Na verdade, uma boa diretriz para o apropriado nível de detalhe e granularidade ao escrever requisitos é fazê-los individualmente testáveis.

(Traduzido de Karl Wieger por Roque Daudt)

[Home] [IT] [Oracle/Db] [SD] [PM] [Lendas Corporativas] [Diversas] [The Secret of Life] [About IT talks]