Conceito e mecanismo
Um requisito utilizável precisa de identidade e história. Regista a origem, razão, versão, estado, responsável e ligações úteis para a entrega. A rastreabilidade deve responder a perguntas reais: que necessidade justifica este trabalho, que componentes são afetados e que evidência mostra cumprimento? Não exige ligar indiscriminadamente todos os elementos a todos os outros. Escolhe relações que apoiem análise de impacto e manutenção. Quando o âmbito muda, preserva a versão anterior e a decisão que autorizou a mudança. Reutilizar um requisito de outro serviço exige confirmar contexto, pressupostos e aplicabilidade; copiar o texto não transfere a validade da aprovação. Uma obrigação permanente de suporte também precisa de um proprietário depois de o projeto terminar.
Aplicação guiada
Num caso fictício, antecipar a disponibilização de posições depende de receber preços de outro sistema. O requisito visível ao negócio pode ter prioridade alta, mas a dependência técnica tem de entrar na sequência. Discute critérios como valor, urgência, risco e dependências antes de comparar pedidos. Uma alteração pequena no texto pode exigir novos testes, formação ou revisão de contratos de interface. Apresenta esses impactos à autoridade acordada, regista a decisão e comunica a versão resultante aos consumidores. Se o responsável estiver ausente, usa a delegação definida; o analista não herda automaticamente o poder de aprovação. Mantém também pedidos rejeitados ou adiados com a respetiva razão, para evitar que regressem como se nunca tivessem sido avaliados.
Prioridade elevada não elimina uma dependência que torna a entrega possível.
Armadilhas comuns
Alterar a baseline sem histórico; reutilizar aprovação de outro contexto.
Tópicos relacionados: Planear análise e decisões · Elicitação, evidência e colaboração · Estado atual, futuro e transição
Conserva a ligação entre necessidade, mudança, decisão e evidência.
Referência: Success with requirement traceability · Six-knowledge-area blueprint / handbook May 2026