TOGAF® Standard, 10th Edition · OGEA-101 Foundation · Quick revision
Requirement
Official definition — learn word for word
“A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability.”
Source: CC §4.64
Memory aid
U-T-N: Unambiguous · Testable (or measurable) · Necessary.
Memory aid — not TOGAF wording.
In plain words
A clear, checkable statement of something the solution must do or meet — if you can't test or measure it, it isn't a good requirement yet.
Plain-English summary — not TOGAF wording.
Worked example
“Payments must be secure” is a concern. “All card payments are processed by a PCI-DSS Level 1 certified gateway; no card number is stored in DUK systems” is a requirement.
Illustrative example (Digital University Kerala) — not from the Standard.
01Mind map — related concepts
Requirement
MUST BE
Unambiguous · testable / measurable · necessary
COMES FROM
Stakeholder concerns
WRITTEN IN
Architecture Requirements Specification (ARS)
MANAGED IN
Architecture Requirements Repository
THREE LEVELS
Strategic · Segment · Capability requirements
NOT TO CONFUSE WITH
Concern (a general interest)
Source: CC §4.64 · AC §4.2.6, §7.6
02ADD vs Architecture Requirements Specification (AC §4.2.3, §4.2.6)
| Aspect | Architecture Definition Document | Architecture Requirements Specification |
|---|---|---|
| View of the solution | Qualitative — communicates the intent of the architects | Quantitative — measurable criteria that must be met during implementation |
| Role | Deliverable container for core architectural artifacts | What an implementation project must do to comply with the architecture |
| Typical content | Baseline, Target, Transition architectures; gap analysis; impact assessment | Success measures; architecture requirements; interoperability requirements; constraints; assumptions |
Source: AC §4.2.3, §4.2.6
03Where new requirements go (Phase A · 3.3.2)
New requirement identified
within the scope of the selected requirements?
Inside scopedocument in the Architecture Requirements Specification
Beyond scopeinput to the Requirements Repository, managed by Requirements Management
Source: ADM §3.3.2
04Where it appears in the ADM
Requirements Management
Manage architecture requirements identified during any execution of the ADM cycle or a phase; make them available to each phase.
ADM §13.1
Phase A · Step 3.3.2
New in-scope requirements → ARS; out-of-scope → Requirements Repository.
ADM §3.3.2
Requirements Management artifact
Requirements Catalog.
AC §3.6.8
05Exam traps
“Requirements are only gathered in Phase A” → They can be gathered at every stage of the ADM
“The ARS gives a qualitative view” → The ARS is quantitative; the ADD is qualitative
“A concern and a requirement are the same” → A concern may lead to several particular, testable requirements
“Requirements can be vague if agreed” → They must be unambiguous and testable or measurable
“Met requirements are deleted” → When met, they are archived for audit purposes
06Self-test — tap to reveal
Q1Define a requirement.
A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability.
Q2Which deliverable states measurable criteria?
The Architecture Requirements Specification.
Q3Which is qualitative — ADD or ARS?
The ADD.
Q4Where are out-of-scope Phase A requirements put?
The Requirements Repository.
Q5Name the three levels of architecture requirements.
Strategic, Segment, Capability.
Q6Who manages the Architecture Requirements Repository?
The Requirements Management phase.
Q7What happens to requirements once met?
They are archived for audit purposes.
Q8Which catalog belongs to Requirements Management?
Requirements Catalog.