APRENDER. PRATICAR. EVOLUIR.Planear a autoridade e a informação necessária
Uma mudança urgente pode chegar por uma chamada informal, mas a equipa precisa de saber quem decide e com que informação. No plano de análise, define canais, papéis, delegações, critérios de escalamento e registos de decisão adequados ao projeto. A pessoa que conhece o requisito pode não ter autoridade para comprometer orçamento ou aceitar risco operacional. O modelo usa uma lista fictícia de decisores autorizados para demonstrar essa distinção; não autentica pessoas nem valida assinaturas. Num ambiente real, consulta a governação aplicável e mantém evidência da autoridade. A adaptação ao risco pode reduzir formalidade em mudanças pequenas, mas não transforma qualquer pedido em aprovação.
A aprovação tem um objeto identificável
No exercício, CR7 propõe passar R de v1 para v2 sobre a baseline B1. A proposta conserva uma impressão digital do conteúdo da baseline; a decisão conserva também a impressão digital da proposta. Isto permite detetar diferenças na simulação. Se alguém mudar a proposta para v3 depois da aprovação, a decisão anterior deixa de corresponder ao pacote. A resposta não é alterar o identificador da aprovação para eliminar o erro: é esclarecer a diferença, atualizar a análise e obter a decisão aplicável. Uma impressão digital permite comparar conteúdo; não prova quem aprovou, se tinha autoridade real ou se a informação original era verdadeira. Esses controlos exigem mecanismos e evidência adicionais.
Concorrência entre alterações e versões de referência
Enquanto CR7 aguarda implementação, outra equipa pode atualizar a baseline. Mesmo que CR7 mantenha o mesmo texto, o contexto em que foi avaliada mudou. A política didática rejeita uma implementação cuja baseline já não coincide com a analisada. O BA e o gestor técnico devem verificar diferenças, dependências e condições da decisão anterior antes de a reutilizar. Não significa que toda a mudança concorrente invalide sempre uma aprovação em qualquer organização; significa que a aplicabilidade precisa de ser demonstrada segundo o processo local. Preserva a baseline anterior e a justificação da nova decisão para reconstruir a sequência. Sob pressão do fecho, uma ligação para o pedido original é insuficiente se ninguém confirmar a versão de referência.
Aprovar, implementar e aceitar são estados diferentes
A aprovação de CR7 não muda R automaticamente. No exercício, R continua em v1 até à transição que recebe a decisão correspondente e verificações explícitas para os elementos alterados. Um estado deferred ou rejected não permite essa transição; um valor textual yes também não substitui o booleano exigido pelo contrato da fixture. Esses detalhes servem para expor pressupostos de estado, não para prescrever uma API universal. A transição cria uma nova baseline, conserva a antiga e regista a decisão. O teste T permanece em v1: ser candidato a revisão não o altera nem o marca como aprovado. As verificações do modelo são entradas sintéticas, pelo que não demonstram deployment, execução de testes ou aceitação funcional reais.
Fechar o ciclo de comunicação e evidência
Depois da decisão, comunica o resultado às equipas afetadas, identifica documentos por atualizar e acompanha as ações até existir evidência suficiente. Para uma alteração da hora de corte, o runbook, a monitorização, os critérios de teste e a informação ao utilizador podem precisar de revisão separada. O relatório deve distinguir aprovado, implementado e aceite, com responsáveis e pendências. As duas execuções do laboratório passaram 36 verificações cada, incluindo propostas alteradas, baselines desatualizadas e delegação retirada. Isso demonstra o contrato sintético executado. Não demonstra a validade jurídica de uma assinatura, a completude do grafo ou a eficácia de um comité real. Resume a decisão, o objeto exato aprovado e o que ainda falta confirmar antes de encerrar o pedido.
# Fictional teaching policy; these are not authenticated approvals.
proposal = propose(B1, 'CR7', {'R': 'v2'})
approval = decision(proposal, 'business-owner', 'approved', authority)
B2 = implement(B1, proposal, approval, authority, {'R': True})
# B1 is retained; B2 records history.
# Changed proposal or baseline: reassessment required by this model.
# A supplied True is not external implementation evidence.CR7 aprovada para B1/R-v2 não pode ser reutilizada no modelo para R-v3 ou para uma baseline posterior.
Armadilhas comuns
Pedido como aprovação; hash como assinatura; aprovação antiga como autorização ilimitada; implementação como aceitação automática.
Tópicos relacionados: Gestão de requisitos · Estimativas e dependências · Controlo de alterações e aceitação
Liga a decisão à versão avaliada, preserva a história e encerra apenas os estados sustentados pela evidência disponível.
Referência: 6.5 Configuration Management · Five-domain ECO / verified 2026-10-01