TOGAF® Standard, 10th Edition · OGEA-101 Foundation · Quick revision
Concern
Official definition — learn word for word
“An interest in a system relevant to one or more of its stakeholders.”
Concerns may pertain to any aspect of the system's functioning, development, or operation — e.g. performance, reliability, security, distribution, and evolvability — and may determine the acceptability of the system.
Source: CC §4.37 · AC §3.1
Memory aid
Stakeholder HAS concerns · Viewpoint FRAMES concerns · View ADDRESSES concerns.
Memory aid — not TOGAF wording.
In plain words
The thing a stakeholder worries about or wants from the system.
Plain-English summary — not TOGAF wording.
Worked example
The Finance Officer's concern is payment security. That one concern can lead to several requirements, e.g. “card numbers are never stored” and “every payment is logged”.
Illustrative example (Digital University Kerala) — not from the Standard.
01Mind map — related concepts
Concern
HELD BY
One or more stakeholders
FRAMED BY
An architecture viewpoint
EXAMPLES
Performance · reliability · security · evolvability
LEADS TO
One or more particular requirements
PHASE A · STEP 3.3.2
Identify stakeholders and their concerns
NOT TO CONFUSE WITH
Requirement (a testable statement of need)
Source: AC §3.1 (Fig 3-1) · ADM §3.3.2
02Concern vs Requirement
| Aspect | Concern | Requirement |
|---|---|---|
| Definition | An interest in a system relevant to one or more of its stakeholders (§4.37) | A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability (§4.64) |
| Nature | Can be a general requirement type, e.g. availability | Particular and testable |
| Relationship | May lead to the definition of several particular requirements | Derived from concerns |
Source: CC §4.37, §4.64 · AC §3.1
03Where it appears in the ADM
Phase A · Step 3.3.2
Identify Stakeholders, Concerns, and Business Requirements; the relevant concerns and viewpoints are captured in the Architecture Vision.
ADM §3.3.2
Phase A · Artifact
Stakeholder Catalog records each stakeholder's key questions, issues, or concerns.
AC §3.6.2
04Exam traps
“A concern and a requirement are the same” → A concern may lead to several particular requirements
“The architecture view frames the concern” → The viewpoint frames concerns; the view addresses them
“Concerns are only functional” → They can be any aspect — performance, reliability, security, distribution, evolvability
“A concern belongs to exactly one stakeholder” → Relevant to one or more stakeholders
05Self-test — tap to reveal
Q1Define a concern.
An interest in a system relevant to one or more of its stakeholders.
Q2Give three example concerns from the Standard.
Performance, reliability, security (also distribution, evolvability).
Q3What frames concerns?
An architecture viewpoint.
Q4What may a concern lead to?
The definition of several particular requirements.
Q5Can a concern determine acceptability of the system?
Yes.
Q6In which Phase A step are concerns identified?
Step 3.3.2.
Q7Where are relevant concerns and viewpoints captured in Phase A?
In the Architecture Vision.
Q8How does TOGAF define a requirement?
A statement of need, which is unambiguous, testable or measurable, and necessary for acceptability.