Specification isn't about writing long documents. It's about choosing the right representation so the right people can understand the right thing.
BABOK Task 5.1 covers this: selecting models and representations that make requirements precise enough to be reviewed, built from, and tested against.
Different requirement types call for different representations:
- Use cases → for process flows involving a user and a system
- User stories + acceptance criteria → for agile delivery, sprint-level clarity
- ERDs / data models → for data structure and relationships
- State machine diagrams → for objects that change state over their lifecycle
- BPMN → for business process flows, especially when multiple roles interact
- Prototypes → for UI and interaction, when verbal descriptions fail
On the McKinsey project, most of our requirements were expressed as user guides and configuration docs — because the audience was consultants who needed to use the system, not developers who needed to build it. The representation choice was deliberate. A data model would have been useless to them; a step-by-step guide with screenshots was what they actually needed.
The BABOK principle here:
"Requirements (what is needed) should not cross into prescribing designs (how to meet the need)."
That's the most common boundary violation in BA work. The moment a requirement says "the system shall display a dropdown with these values" instead of "the user shall be able to select a category," the BA has stepped into design territory. Sometimes that's appropriate. It should always be intentional.
Exam tip: CBAP distinguishes between requirements (needs) and designs (solutions). Specifying requirements should not default to describing solutions. This is tested directly.