Diretriz: Escrevendo Bons Requisitos
Esta diretriz descreve formas de escrever bons requisitos.
Relacionamentos
Descrição Principal

Para escrever um bom requisito, você deve escrevê-lo como uma sentença completa, com um sujeito e um predicado. O sujeito é um Ator, uma parte nteressada, o sistema em desenvolvimento ou uma entidade de design que está relacionado ao requisito. O predicado especifica uma ação ou um resultado desejado que é feito para, por, com ou ao sujeito, muitas vezes incluindo as condições e os critérios de desempenho.

Assim, você pode analisar o requisito de um ponto de vista gramatical. Por exemplo:

A secretaria de recebimento de pedidos deve ser capaz de completar 10 pedidos de cliente em menos de duas horas.

Este requisito tem um sujeito (a secretaria de recebimento de pedidos, que é um Ator), um estado final específico e mensurável (10 pedidos de cliente concluídos) e um critério de desempenho (em menos de duas horas).

Nos requisitos dos analistas de negócios, o uso da forma verbal "deve ser capaz de" deixa claro que o requisito especifica algo que a parte interessada deve ser capaz de fazer, mas não é (necessariamente) forçada a fazer. Nos requisitos de sistema, a forma verbal "é <ação>" deixa claro que o sistema deve executar esta ação sob as condições determinadas.

Em alguns casos, as listas numeradas podem tornar a escrita mais clara, mas cada item da lista deve ser um requisito completo para maximizar o benefício de qualquer informação de rastreabilidade.

Palavras como todos, cada e alguns podem levar a ambigüidade. Você terá certeza que levou em conta todos os casos? Qual proporção do todo o alguns representa?

As seguintes diretrizes básicas irão ajudá-lo a escrever melhores requisitos. Por razões de coerência, estes exemplos estão todos no contexto de uma aeronave.

  • Defina um requisito por vez. Por exemplo,

O piloto deve ser capaz de controlar o ângulo de subida da aeronave, com uma mão.

O piloto deve ser capaz de sentir o ângulo de subida a partir do controle de subida.

  • Evite as conjunções (e, ou) que criam múltiplos requisitos. Por exemplo, use:

O navegador deve ser capaz de visualizar a posição da aeronave em relação às balizas da rota.

O navegador deve ser capaz de visualizar a posição da aeronave pela estimativa da orientação inercial.

Em vez de:

O navegador deve ser capaz de ver a posição da aeronave em relação às balizas da rota ou pela estimativa da orientação inercial.

Esta última forma é potencialmente perigosa, pois não está claro se o "ou" indica que o navegador pode escolher o método que utilizará para a navegação ou que os desenvolvedores possam decidir qual implementar.

  • Evite cláusulas ou palavras que implicam opções ou exceções (salvo, exceto, se necessário, mas). Elas são perigosas uma vez que fica difícil determinar quando o requisito é aplicável. É melhor escrever requisitos separados, tratando cada condição específica, ou estado do sistema. Por exemplo, use:

O sistema deve fornecer 100% de classificação em condições normais.

O sistema deve ser capaz de fornecer até 125% de classificação para os primeiros 15 minutos em uma condição de emergência.

O sistema deve fornecer um mínimo de 90% de classificação em não menos de 15 minutos após os primeiros 15 minutos em uma condição de emergência.

O sistema deve ativar uma exceção de classificação reduzida se o mínimo de 95% de classificação não for mantido em uma condição de emergência.

Em vez de:

O sistema deve executar a classificação máxima em todas as ocasiões exceto, que em situações de emergência deve ser capaz de fornecer até 125% da classificação salvo se a condição de emergência continuar por mais de 15 minutos, que neste caso a classificação deve ser reduzida para 105% mas no caso de apenas 95% poder ser alcançado, então o sistema deve ativar uma exceção de classificação reduzida e deve manter a classificação em 10% dos valores declarados por no mínimo 30 minutos.

  • Use sentenças simples e diretas.

O piloto deve ser capaz de ver o indicador de velocidade do ar.

  • Use palavras simples, tanto quanto possível, especialmente se o seu público alvo for internacional, o que torna a tradução precisa uma preocupação.

A companhia aérea deve ser capaz de converter as aeronaves de vôos empresariais para festivos em menos de 12 horas.

Nota: Não há necessidade de usar palavras como reconfigurado.

  • Identifique o tipo de usuário que precisa de cada requisito.

O navegador deve ser capaz de...

  • Foque na declaração de que resultado você fornecerá para esse tipo de usuário.

...ver nuvens de tempestade através do radar...

  • Defina critérios verificáveis

...pelo menos 100 milhas à frente.

  • Use A Ser Confirmado (confirmar) para sinalizar que um requisito poderá ser alterado ou que ainda não é definitivo. Isto ajuda a identificar trabalho excedente. Por exemplo:

A aeronave deve ser capaz de aterrizar de forma segura em uma pista de aterrizagem com comprimento mínimo de 1000 metros (confirmar).

  • Use A Ser Determinado (definir) onde se saiba que um requisito específico será necessário, mas os detalhes ainda não são conhecidos. Também ajuda a identificar trabalho excedente. Por exemplo,

A aeronave deve ser capaz de aterrizar, de forma segura, em pistas de aterrizagem com comprimento mínimo de (definir) metros.