As pesquisas e a experiência mostram que os erros nos requisitos são muito comuns, representando algo como 56% de todos os erros cometidos durante o desenvolvimento [TAV84]. Compondo este problema está o fato de que o custo da correção dos erros nos requisitos aumenta exponencialmente durante todo o ciclo de desenvolvimento de software [BOE88].

Frederick Brooks resumiu bem esta situação:

A única parte mais difícil para construir um sistema de software é decidir o que construir. Nenhuma outra parte do trabalho conceitual é tão difícil como o estabelecimento dos requisitos técnicos detalhados…. Nenhuma outra parte do trabalho mutila o sistema resultante se for feita errada. Nenhuma outra parte é tão difícil de corrigir depois [BRO87].

Portanto, é importante que você detecte os erros nos requisitos, o mais cedo possível, antes de se propagarem para os artefatos de concepção, implementação e teste.

O que deve ser evitado ao escrever requisitos

Embora exista uma forma certa de eliminar os erros nos requisitos em geral, existem armadilhas comuns na escrita de requisitos que são relativamente fáceis de evitar [TEL06].

Ambigüidade

Evitar a ambigüidade é um dos mais difíceis mandatos na escrita dos requisitos. Tente escrever o mais claro e explícito possível. Seja específico. Se você tiver que usar termos vagos ou ambíguos, tenha certeza de te-los definido no glossário.

Solicite a vários colegas e Stakeholders que revisem os seus requisitos para garantir a coerência e a compreensão comum. Embora não exista nenhum teste definitivo para a ambigüidade, que não seja o consenso, algumas ambigüidades perigosas podem ser causadas pelo uso das palavras para, ou e a menos que.

Exemplo
"O mesmo subsistema deve também ser capaz de gerar um sinal de cuidado/alerta visível ou audível para chamar a atenção do co-piloto ou navegador".

Qual subsistema? O sinal deve ser visível, audível ou ambos? Deve ser cuidado e alerta, somente cuidado ou somente alerta? Deve ser para o co-piloto e o navegador ou somente um deles? Se somente um deles, quem e em que condições?

Requisitos múltiplos

Requisitos que possuem conjunções (palavras que ligam cláusulas independentes) são perigosos. Problemas surgem quando os leitores tentam entender que parte se aplica, especialmente se as cláusulas diferentes parecem conflitar ou se as partes individuais se aplicam separadamente. Múltiplos requisitos também fazem a verificação ficar mais complexa.

Conjunções perigosas incluem: e, ou, mas

Exemplo
"A lâmpada de alerta de bateria fraca deve acender quando a voltagem cair abaixo de 3.6 Volts, e a área de trabalho corrente ou os dados de entrada devem ser salvos".

A lâmpada de alerta de bateria fraca deve acender quando a voltagem cair e a área de trabalho for salva? A lâmpada de alerta de bateria fraca deve acender e a área de trabalho deve ser salva quando a voltagem cair?

Cláusulas evasivas

Os requisitos que incluem opções ou exceções são perigosos. Eles parecem pedir algo definitivo, mas no último momento eles desistem e permitem outras opções. Os problemas surgem quando os requisitos são testados e alguém tem que decidir o que (se houver) provaria que o requisito foi satisfeito.

Palavras perigosas que implicam exceções incluem: se, quando, mas, exceto, a menos que, embora.

Exemplos
"A porta posterior de passageiros deve abrir automaticamente quando a aeronave parar, exceto quando a rampa traseira estiver aberta".

"O alarme de incêndio deve sempre ser tocado quando a fumaça for detectada, a menos que o alarme esteja sendo testado ou o engenheiro tenha suprimido o alarme".

A última sentença é realmente um requisito perigoso!

Incoerências

Longas sentenças Incoerentes, especialmente quando combinadas com linguagem rebuscada ou referências a documentos de difícil acesso, levam rapidamente à confusão e erros.

Exemplo
"Dado que os sinais de entrada designados dos dispositivos especificados sejam recebidos na ordem correta onde o sistema seja capaz de diferenciar os designadores, o sinal de saída deve estar de acordo com o framework requerido da seção 3.1.5 para indicar o estado desejado de entrada.

Design prematuro

Os requisitos devem especificar as possibilidades de design sem restrições desnecessárias de um design específico. Se detalharmos demais, começaremos a projetar o sistema. Ir muito longe é tentador para os designers, especialmente quando eles chegam às suas partes favoritas.

Sinais de perigo incluem nomes de componentes, materiais, objetos de software ou procedures e campos de bancos de dados.

Exemplo
"A antena deve ser capaz de receber sinais FM usando um miolo de cobre protegido por nylon e uma capa de borracha endurecida à prova d'água".

Especificar design em vez das reais necessidades aumenta o custo dos sistemas por colocar restrições desnecessárias no desenvolvimento e na manufatura. Frequentemente, saber por que é muito melhor do que saber o quê.

Misturando diferentes tipos de requisitos

Os requisitos de usuário formam um modelo completo do que os usuários querem. Eles precisam ser organizados coerentemente para exibirem falhas e sobreposições. O mesmo se aplica aos requisitos de sistema, que formam um modelo funcional completo do sistema proposto. Uma forma rápida de conseguir confusão é misturar requisitos de usuários, sistemas e como o sistema deveria ser projetado, testado ou instalado.

Sinais de perigo são qualquer referência à sistema, design, teste ou instalação.

Exemplo
"O usuário deve ser capaz de ver o número do canal corrente que deve ser exibido com fonte Swiss tamanho 14 em um painel LCD em conformidade com o Padrão Regulamentar Federal 567-89 e montado com arruelas de borracha à prova de choque".

Especulação

Os requisitos são parte de um contrato entre o cliente e o desenvolvedor. Não há espaço para listas de desejos, termos de significado geral sobre coisas que alguém provavelmente quer.

Sinais de perigo incluem idéias vagas sobre que tipo de usuário está falando e generalizações tais como: usualmente, geralmente, frequentemente, normalmente e tipicamente.

Exemplo
"Os usuários normalmente necessitam de rápida indicação de intrusão no sistema".

Termos vagos e indefinidos

Muitas palavras usadas informalmente para indicar a qualidade do sistema são muito vagas para uso em requisitos. Termos vagos incluem, entre outros: amigável, versátil, flexível, aproximadamente, possível.

Os requisitos que usam esses termos não são verificáveis porque não há teste definitivo para mostrar se o sistema tem a propriedade indicada.

Exemplos
"A caixa de diálogo de impressão deve ser versátil e amigável".

"A lâmpada indicadora de status OK deve ser acessa o mais rápido possível depois do auto-teste do sistema ser completado".

Expressando meras possibilidades

Sugestões que não são explicitamente declaradas como requisitos são invariavelmente ignoradas pelos desenvolvedores.

"Opções possíveis" são indicadas com termos tais como: pode, deveria, desejável, poderia, talvez, provavelmente.

Exemplo
"O subsistema de recepção provavelmente deverá ser forte o suficiente para receber um sinal de dentro de uma construção de placas de aço".

Pensamentos desejosos

Os pensamentos desejosos significam pedir o impossível. A engenharia é uma atividade do mundo real e nenhum sistema ou componente é perfeito.

Termos de pensamentos desejosos incluem: confiável, seguro, trata todas as falhas inesperadas, agrada a todos os usuários, roda em todas as plataformas, nunca falha, atualizável a todas as situações futuras.

Exemplos
"A caixa de câmbio deve ser 100% segura em operação normal".

"A rede deve tratar todos os erros inesperados sem travar".