Documenting and Modeling Requirements
Key Takeaways
- BABOK v3 classifies requirements into four types: business, stakeholder, solution (further split into functional and non-functional), and transition requirements.
- BABOK v3 lists nine characteristics of good requirements: atomic, complete, consistent, concise, feasible, unambiguous, testable, prioritized, and understandable.
- An atomic requirement expresses a single, self-contained need rather than bundling multiple needs into one statement.
- Non-functional requirements describe quality attributes such as performance, security, and usability rather than specific system behaviors.
- Transition requirements describe capabilities needed only temporarily to move from the current state to the future state, such as data conversion.
From Elicited Information to Documented Requirements
Once elicitation surfaces raw information, the Need domain expects a business analyst to turn it into requirements that are documented and modeled clearly enough for other stakeholders to review, verify, and act on. BABOK v3 treats documentation and modeling as complementary: documentation captures requirements in text form (a requirements specification, user story, or acceptance criterion), while modeling represents them visually (a process flow, data model, or use-case diagram) so relationships and gaps are easier to spot than in prose alone. A situation-based exam question that describes a requirement understood differently by two departments is usually pointing at a documentation or modeling gap, not a wrong elicitation technique.
Requirement Types: A Quick Recap
BABOK v3 classifies every requirement into one of four types, and the ECBA blueprint's foundational domains expect a BA to sort a described need into the correct type:
- Business requirements - statements of goals, objectives, and outcomes describing why a change is needed, at the organizational level.
- Stakeholder requirements - the needs of a specific stakeholder or stakeholder group, bridging business requirements to more detailed solution requirements.
- Solution requirements - describe the capabilities a solution must have to meet business and stakeholder requirements, split into functional requirements (behaviors and capabilities the solution will perform) and non-functional requirements (quality attributes such as performance, security, usability, and reliability that constrain how functions are delivered).
- Transition requirements - capabilities needed only temporarily to move successfully from the current state to the future state, such as data conversion or training, and retired once the transition is complete.
Characteristics of Good Requirements
BABOK v3 lists nine characteristics that a well-documented requirement or design should exhibit. A situation-based question describing a flawed requirement is almost always testing whether the candidate can name which characteristic was violated.
| Characteristic | What It Means | Common Violation Pattern |
|---|---|---|
| Atomic | States a single, self-contained need | Combining two unrelated capabilities in one requirement statement |
| Complete | Contains all information needed to understand it, with no missing detail | A requirement that says the system will notify the user without specifying how or when |
| Consistent | Does not conflict with other requirements | Two requirements that specify contradictory business rules |
| Concise | Documented briefly, without unnecessary detail | Padding a requirement with rationale, design detail, or history |
| Feasible | Can be implemented within known constraints | A requirement that assumes technology or budget the organization doesn't have |
| Unambiguous | Stated so it can only be interpreted one way | Subjective language such as fast, easy, or user-friendly with no defined threshold |
| Testable | Written so that satisfying it can be objectively verified | A requirement with no measurable acceptance criterion |
| Prioritized | Ranked in relative importance against other requirements | Treating every requirement as equally urgent |
| Understandable | Written in language accessible to its intended reader | Jargon or acronyms unfamiliar to the reviewing stakeholder |
Choosing a Documentation Format
How a requirement is documented depends on the BA approach in use. A predictive approach favors a structured requirements specification with numbered, traceable statements reviewed and signed off before development begins. An adaptive approach favors lightweight formats such as user stories with acceptance criteria, refined iteratively as the team learns more. Both formats must still satisfy the same nine characteristics of good requirements - the format changes, but atomicity, testability, and the rest of the list do not become optional just because the documentation is lighter weight. A BA moving between a predictive project and an adaptive one should expect the underlying discipline to transfer even when the paperwork looks completely different.
Modeling to Reinforce Documentation
Text alone often hides gaps that a model reveals immediately. A process model exposes a missing exception path that a paragraph of text glossed over. A data model exposes an entity relationship no one described in an interview because it seemed too obvious to mention. Modeling and documentation should be treated as a single deliverable pair, not sequential steps - many BAs draft a model and requirement text in parallel, using each to check the other for gaps.
Applying This in Practice
When a stakeholder hands a BA a vague statement like a request for the portal to be more secure, the correct response under the Need domain is not to write that sentence down as a requirement. It is to decompose it: is this a business requirement (a compliance objective), a non-functional solution requirement (an authentication standard), or both? Then it must be rewritten so it is atomic, testable (for example, specifying that the portal will enforce multi-factor authentication for all administrative accounts), and unambiguous, before it is considered ready to move to verification. Good documentation habits at this stage prevent costly rework later, because a requirement that fails a quality characteristic almost always resurfaces as a defect, a change request, or a stakeholder dispute after development has already started. Treating documentation quality as a first-pass discipline, rather than something to clean up later, is consistently cheaper than discovering the gap during testing or after release.
A draft requirement states that the system shall allow authorized users to submit and approve expense reports and shall encrypt all data at rest. A reviewer flags this as bundling two distinct needs into one statement. Which characteristic of good requirements does this violate?
A stakeholder requirement reads that the new portal should be fast and user-friendly. Which characteristic of good requirements is most clearly missing?