LEARN. PRACTICE. GROW.Concept and mechanism
Requirements management accompanies architecture work continuously. A requirement should have understood meaning, origin, ownership, and a way to verify satisfaction. Link it to decisions and the elements realizing it. When new information appears, assess its impact on previous agreements; editing one sentence in a document is insufficient. Functional and quality requirements may conflict. For example, reducing response time through caching can introduce staleness incompatible with a business decision. Make tolerances and conditions explicit before choosing technology. Approving a requirement does not remove the need to demonstrate implementation.
Guided application
In a fictional case, business changes maximum acceptable data loss from fifteen to five minutes. Identify affected replication decisions, contracts, tests, and procedures; confirm feasibility and cost with their owners. Update the authorized baseline and communicate the change to dependent teams. Distinguish RPO, concerning data loss measured in time, from RTO, concerning service restoration. A quick recovery demonstration does not automatically prove the new RPO. Also retain rejected or superseded requirements with their rationale so they do not return without context. Traceability makes it possible to ask what changes, who must decide, and what evidence will be needed to accept the solution.
Recovery in eight minutes does not demonstrate a five-minute data-loss limit.
Common pitfalls
Requirement without conditions; local change without impact analysis; traceability as mere numbering.
Related topics: Context, mandate, and value · Stakeholders, conflicts, and views · Vision, scope, and feasibility
Connect need, decision, implementation, and acceptance.
Reference: Practitioner competency-to-role mapping · OGEA-102; TOGAF Standard, 10th Edition