Writing individual requirements is the easy part. Organizing them so they hold together — that's where most BA work either succeeds or falls apart.
BABOK Task 5.4 (Define Requirements Architecture) is the work of giving requirements a structure: showing how they relate to each other, how they trace to business goals, and how they map to solution components. Without this, you get a pile of requirements that no one can navigate.
A requirements architecture typically makes visible:
- The hierarchy (requirements composed of sub-requirements, features composed of stories)
- The dependencies (this requirement can't be delivered without that one)
- The traceability (which business goal does each requirement support?)
- The gaps (where is something needed but not yet specified?)
On the LPT project, I built this kind of architecture from scratch — tracing from business processes described in BPMN to functional requirements in Confluence to specific Jira tickets. The traceability made a real difference when clients requested changes: instead of "I don't know what that affects," the answer was "here's the chain, here's what changes."
The techniques used to express requirements architecture vary: context diagrams for scope, data models for entities and relationships, BPMN for processes, C4 for system structure. The technique is less important than the intent — making the structure visible to everyone who needs to work within it.
Exam tip: The output of this task is the requirements architecture — a structured view of how requirements relate. It is not the requirements themselves. That distinction matters on the CBAP exam.