APRENDER. PRATICAR. EVOLUIR.Identificar exatamente o que muda
O sponsor altera a janela de processamento de uma aplicação fictícia. O pedido parece uma troca de número, mas pode afetar concorrência, calendário de lotes, observabilidade e operação fora de horas. Regista o requisito atual, a proposta, a razão, o âmbito, a data pretendida e o responsável pela decisão. Não substituas imediatamente o texto aprovado pela nova frase, pois isso apaga a referência que explica o comportamento em produção. Mantém versões identificadas e liga a proposta ao objetivo que pretende melhorar. Se a mudança tem urgência, adapta a análise à janela disponível sem esconder questões não resolvidas. Uma exceção aprovada deve indicar o que cobre e quando será revista.
Avaliar a frescura das relações e aprovações
No laboratório, R-window muda de versão 1 para 2. As relações L1, proveniente da necessidade, e L3, para o worker, ainda referem a versão 1 e são assinaladas para revisão. Não significa que estejam erradas; significa que a validade para a nova versão ainda não foi demonstrada. Uma aprovação que identifica versão 1 não aprova automaticamente versão 2. Do mesmo modo, um teste aprovado contra a condição antiga pode precisar de nova expectativa, de outra execução ou apenas de confirmação fundamentada de que continua adequado. Não atualizes só o número da versão para eliminar o aviso. Guarda quem avaliou a relação, com que evidência e que decisão tomou.
Separar descoberta de impacto e decisão
A consulta encontra worker e testes relacionados. O analista confirma com desenvolvimento e APS quais precisam de alteração, quais só precisam de revalidação e quais permanecem adequados com justificação. Pergunta também por dependências não representadas: equipas de outro fuso horário, fornecedores, relatórios e procedimentos de recuperação. Cada candidato deve ter um destino explícito, mas não precisa obrigatoriamente de originar código novo. Uma lista de impacto não é um pedido aprovado nem uma estimativa completa. A recomendação combina benefício esperado, custo, risco, capacidade e restrições. A autoridade definida decide aceitar, rejeitar, adiar ou pedir mais informação; o papel da análise é tornar essa escolha fundamentada e rastreável.
Preparar uma entrega coerente
A API está planeada para a primeira release e o worker para a segunda. Se o novo contrato só funciona com ambos, a equipa precisa de decidir como manter compatibilidade, ativar a capacidade ou entregar o conjunto. Uma data em cada linha de um plano não resolve a dependência. Relaciona requisito, componente, teste, ativação e handover com a versão que será usada. Inclui o estado intermédio: que pedidos são aceites, como são tratados e como se recupera uma falha antes da segunda release. Não confundes aprovação de requisitos com autorização de deployment. Cada decisão tem âmbito e evidência próprios, embora a rastreabilidade ajude a verificar que usam uma referência coerente.
Fechar o ciclo sem apagar a história
Depois da mudança, observa os critérios acordados e regista desvios. Se a janela melhorou mas o número de intervenções manuais cresceu, a avaliação deve conservar ambos os resultados. A versão anterior continua útil para explicar incidentes, decisões e dados históricos; retirá-la de uso corrente não exige apagar a evidência. No exercício, a cópia da baseline permanece na versão 1 enquanto outra estrutura representa a proposta. Em trabalho real, o mecanismo pode ser uma ferramenta de requisitos, controlo de versões ou um repositório governado. O importante é conseguir reconstruir a decisão e identificar a referência aplicável. O laboratório demonstra lógica de relações e versões, sem executar uma mudança bancária, obter aprovação real ou medir benefício em produção.
# Inspect staleRelationsAfterVersionChange in the lab evidence.
# Expected: L1 and L3 still cite R-window version 1.
# A previous approval is evidence about its identified version.
# Updating a version field alone is not a review.R-window v2 deixa duas relações por revalidar. A aprovação de v1 conserva valor histórico, mas não cobre a nova proposta.
Armadilhas comuns
Atualizar versões sem revisão; rastreabilidade como aprovação; apagar baselines; ignorar o estado entre releases.
Tópicos relacionados: Ciclo de vida dos requisitos · Alternativas e valor potencial · Aceitação e passagem à operação
Preserva a referência, revê as relações e distingue recomendação, aprovação e aceitação da mudança.
Referência: The Business Analysis Standard · CBAP six-knowledge-area blueprint, May 2026 handbook