LEARN. PRACTICE. GROW.Start with the decision the view should support
In a fictional fund-processing project, management asks whether close fits the agreed window. APS needs to know who recovers an interrupted transaction, and development needs to understand the API-to-worker contract. A single diagram full of arrows can hide these questions. First define the viewpoint: audience, concern, needed information and conventions. Then build the actual view with stable identifiers and explained relationships. An operational view can emphasize states, monitoring and owners; a data view can show identity, transformation and reconciliation. Both should refer to the same concepts, avoiding contradictory requirements merely because their audiences differ.
Explain relationship meaning and direction
In the exercise N-close represents a need, R-window a window requirement and D-worker a component option supporting it. The R-window to D-worker arrow means a requirement change requires reviewing that allocation; it does not mean the requirement executes code. D-worker links to tests T-window and T-replay. Following these relationships from R-window returns three review candidates. The replay test appears because the worker is shared, not because its result has already been shown to change. If the team uses arrows in the opposite direction, its query must follow that convention. Semantics are an explicit choice of this teaching model, not an IIBA-mandated notation.
Decompose without losing behavior between parts
A team divides a flow into receipt, validation and execution. Each part passes its tests, yet a received message can remain unexecuted without an alert. Requirements architecture must retain behavior between parts: the meaning of received, accepted, rejected, completed and recovering. Ask which component records each transition, what information crosses the interface and how operators distinguish normal waiting from failure. Allocating the same requirement to several components is not necessarily duplication; it can represent required collaboration. However, repeating text in three documents without a controlled relationship creates divergent versions. Also examine cross-cutting requirements such as authorization and operational evidence, which can disappear when teams analyze only isolated functions.
Check repository quality
The lab deliberately removes L3, the link between R-window and D-worker. The query then returns zero candidates even though the worker remains in the node set. This demonstrates a limitation in recorded information, not absence of actual impact. The script also rejects a link to a nonexistent identifier and avoids counting the same test twice when reached through different paths. These are useful consistency checks but do not automatically discover an omitted stakeholder or a need never recorded. Combine queries with review by people familiar with the process, end-to-end examples and comparison against agreed scope. Retain the repository version used so another person can reconstruct the analysis.
Interpret cycles and communicate the conclusion
D-api can relate to D-worker in both directions in an informational view. That does not automatically invalidate the model. In the exercise only prerequisite relationships have a no-cycle rule because they represent mandatory implementation order. If API requires a completed worker and the worker requires a completed API, the team must revisit decomposition, define a joint delivery or clarify the dependency’s nature. Do not delete an arrow merely to pass validation. Explain the conclusion to the committee: which relationships were analyzed, which assumptions limit the query and who confirms candidates. Architecture organizes decisions about a coherent whole; node and arrow counts alone do not measure completeness or quality.
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 reaches D-worker, T-window and T-replay. Removing the allocation relation produces zero results without removing the worker.
Common pitfalls
Meaningless arrows; missing links as absence of impact; approved components as proof of the complete flow; every cycle as an error.
Related topics: Requirements life cycle · Alternatives and potential value · Acceptance and operational handover
A relationship enables a review question; answering requires context, evidence and people who know the scope.
Reference: The Business Analysis Standard · CBAP six-knowledge-area blueprint, May 2026 handbook