Manter os requisitos rastreáveis à medida que o software muda

Descreva um comportamento que alguém possa verificar

«Criar um export de clientes moderno» deixa decisões importantes em aberto. Não define os utilizadores, os registos, os campos nem o comportamento em caso de falha. Um agente tem de perguntar ou assumir pressupostos. Os pressupostos não registados são difíceis de rever mais tarde.

Use um requisito fictício com um limite claro: um gestor autenticado pode exportar clientes ativos da sua própria organização. O export contém o identificador e o nome de apresentação do cliente. Exclui contactos e registos arquivados. Um utilizador sem a função de gestor não obtém nenhum export.

Ainda são necessárias decisões sobre o formato, o volume, o tempo de resposta e o tratamento de falhas. Assinale explicitamente o que é desconhecido. Uma especificação útil expõe a incerteza em vez de a ocultar em texto confiante.

Separe os requisitos das escolhas de implementação

O utilizador precisa de um conjunto permitido de registos num formato utilizável. A consulta à base de dados, a biblioteca e a estrutura do endpoint são escolhas de implementação. Ligue-as ao requisito sem tratar cada escolha atual como uma necessidade permanente do negócio.

Registe uma decisão com consequências relevantes, incluindo o contexto, as alternativas e a justificação. Por exemplo, um export síncrono pode ser adequado para pequenos volumes. Um volume maior pode exigir uma tarefa em segundo plano e uma verificação separada da autorização para descarregar o ficheiro.

Sempre que possível, mantenha o requisito estável e crie uma nova versão da decisão alterada. Isto ajuda os revisores a distinguir uma implementação diferente de uma promessa diferente aos utilizadores.

Crie uma cadeia curta de evidências

Use identificadores que continuem a ser compreensíveis nas revisões. Neste exemplo, EXPORT-01 pode identificar o limite da organização. O nome é ilustrativo, não um sistema de numeração obrigatório.

A cadeia tem de apontar para evidências reais. Um nome de teste que inclua o identificador do requisito não prova que a asserção o verifica. Examine o teste e o percurso do código de produção que este exercita.

O SSDF do NIST enquadra os requisitos e a verificação no desenvolvimento seguro. Use a rastreabilidade para tornar estas atividades examináveis, em vez de produzir documentação apenas por produzir. Leia o referencial.

Reveja o impacto de um pressuposto alterado

Suponha que o negócio passa a precisar de clientes arquivados. Essa alteração afeta mais do que uma opção da consulta. Verifique as regras de retenção, a autorização, o volume esperado, as explicações aos utilizadores e o significado dos relatórios existentes.

Assinale os documentos e as verificações afetados para revisão. Preserve a decisão anterior para que um operador possa explicar um lançamento mais antigo. Não reescreva silenciosamente o histórico para fazer parecer que a conceção mais recente era inevitável.

Um agente pode ajudar a encontrar referências e propor atualizações. Os responsáveis têm de resolver requisitos incompatíveis e aceitar o comportamento alterado. Uma lista de ficheiros correspondentes é um ponto de partida, não uma avaliação de impacto completa.

Mantenha o registo suficientemente pequeno para ser usado

Registe as decisões que afetam a implementação, a verificação e a operação. Evite repetir o mesmo requisito em muitos documentos sem ligação. Prefira ligações a uma única fonte mantida.

Antes de aceitar uma alteração, pergunte se um revisor consegue seguir a sua finalidade até às evidências reais. Antes de a operar, pergunte se o responsável pelo serviço consegue localizar o limite relevante e a decisão de recuperação. Estes são testes práticos de uma rastreabilidade útil.