APRENDER. PRATICAR. EVOLUIR.Começar pela decisão que a vista deve apoiar
Num projeto fictício de processamento de fundos, a direção pergunta se o fecho cabe na janela acordada. APS precisa de saber quem recupera uma operação interrompida, e a equipa de desenvolvimento precisa de compreender o contrato entre API e worker. Um único desenho cheio de setas pode esconder estas perguntas. Define primeiro o ponto de vista: destinatário, preocupação, informação necessária e convenções. Depois constrói a vista concreta com identificadores estáveis e relações explicadas. Uma vista operacional pode destacar estados, monitorização e responsáveis; uma vista de dados pode mostrar identidade, transformação e reconciliação. As duas devem referir os mesmos conceitos, evitando criar requisitos contraditórios só porque os públicos são diferentes.
Explicar o significado e a direção das relações
No exercício, N-close representa uma necessidade, R-window um requisito de janela e D-worker uma opção de componente que o suporta. A seta R-window para D-worker significa que uma alteração do requisito obriga a rever essa alocação; não significa que o requisito executa código. D-worker liga aos testes T-window e T-replay. Seguir estas relações a partir de R-window devolve três candidatos a revisão. O teste de replay aparece porque o worker é partilhado, não porque já esteja provado que o resultado do teste vai mudar. Se a equipa usar setas no sentido inverso, a consulta deve acompanhar essa convenção. A semântica é uma decisão explícita do modelo didático, não uma notação imposta pelo IIBA.
Decompor sem perder o comportamento entre partes
Uma equipa divide o fluxo em receção, validação e execução. Cada parte passa os seus testes, mas uma mensagem recebida pode ficar sem execução e sem alerta. A arquitetura de requisitos deve conservar o comportamento entre partes: o significado de recebido, aceite, rejeitado, concluído e em recuperação. Pergunta qual componente regista cada transição, que informação passa pela interface e como o operador distingue espera normal de falha. Alocar o mesmo requisito a várias componentes não é necessariamente duplicação; pode representar colaboração necessária. Porém, repetir o texto em três documentos sem uma relação controlada cria versões divergentes. Verifica também requisitos transversais como autorização e evidência operacional, que podem desaparecer quando a equipa só analisa funcionalidades isoladas.
Testar a qualidade do repositório
O laboratório remove deliberadamente L3, a ligação entre R-window e D-worker. A pesquisa passa a devolver zero candidatos, embora o worker continue no conjunto de nós. Este resultado demonstra uma limitação da informação registada, não ausência de impacto real. O script também rejeita uma ligação para um identificador inexistente e evita contar duas vezes o mesmo teste alcançado por caminhos diferentes. São verificações úteis de coerência, mas não descobrem automaticamente um stakeholder omitido ou uma necessidade nunca registada. Combina a consulta com revisão por quem conhece o processo, exemplos de ponta a ponta e comparação com o âmbito acordado. Guarda a versão do repositório usada para que outra pessoa possa refazer a análise.
Interpretar ciclos e comunicar a conclusão
D-api pode relacionar-se com D-worker nos dois sentidos numa vista informativa. Isso não torna automaticamente o modelo inválido. No exercício, só relações prerequisite têm a regra de não formar ciclos, porque representam ordem obrigatória de implementação. Se API exigir worker concluído e worker exigir API concluída, a equipa precisa de rever a decomposição, criar uma entrega conjunta ou esclarecer a natureza da dependência. Não apagues uma seta para fazer o validador passar. Explica a conclusão ao comité: que relações foram analisadas, quais pressupostos limitam a pesquisa e quem confirma os candidatos. A arquitetura serve para organizar decisões sobre um conjunto coerente; a quantidade de nós e setas não é, por si só, uma medida de completude ou qualidade.
python3 content/labs/cbap-requirements-architecture/run.py --output /tmp/cbap-architecture.json
# Inspect windowImpactCandidates and emptyImpactAfterMissingLink.
# Neither list is a business approval.R-window alcança D-worker, T-window e T-replay. Remover a relação de alocação produz zero resultados sem remover o worker.
Armadilhas comuns
Setas sem significado; ausência de ligação como ausência de impacto; componentes aprovadas como prova do fluxo completo; qualquer ciclo como erro.
Tópicos relacionados: Ciclo de vida dos requisitos · Alternativas e valor potencial · Aceitação e passagem à operação
Uma relação permite fazer uma pergunta de revisão; a resposta exige contexto, evidência e pessoas com conhecimento do âmbito.
Referência: The Business Analysis Standard · CBAP six-knowledge-area blueprint, May 2026 handbook