Requirements Management Knowledge-Based Study

Study notes

1. The Central Role of Requirements Management

   In the TOGAF Standard, 10th Edition, Requirements Management occupies a unique position at the visual and operational center of the Architecture Development Method (ADM) cycle. Rather than acting as a sequential, discrete phase executed once from start to finish, Requirements Management is a continuous, dynamic process that interacts with every phase of the ADM—from Phase A (Architecture Vision) through Phase H (Architecture Change Management).

   Its primary objective is to ensure that architecture requirements are identified, recorded, stored, prioritized, and continuously addressed as the architecture evolves. Any phase of the ADM can both consume existing requirements and generate new ones as deeper architectural discovery takes place.

   Managing vs. Generating Requirements

   A critical conceptual distinction in TOGAF is understanding what Requirements Management does and does not do:

   • Does NOT dictate or create requirements: The Requirements Management process does not independently invent business targets, set technical constraints, or specify requirements in isolation. Requirements are elicited, validated, and refined within the respective ADM phases.
   • Manages the requirements lifecycle: The process is responsible for capturing, cataloging, maintaining traceability, performing impact analysis, and monitoring changes to requirements throughout the lifecycle of the architecture capability.

   By keeping this distinction clear, enterprise architects avoid the misconception that Requirements Management is an upfront design activity. Instead, it provides the governance mechanism that prevents requirement drift and unmanaged scope changes.

   Operating the Process within Architecture Governance

   When establishing an Enterprise Architecture Capability, organizations must implement formal mechanisms to support Requirements Management:

   1. Requirements Repository: Establishing a shared, structured location within the Architecture Repository to hold current, deferred, and retired requirements along with their attributes (e.g., priority, owner, status, source phase).
   2. Traceability: Maintaining bidirectional traceability between stakeholder drivers, architecture principles, architectural models, and implementation projects.
   3. Impact Assessment: Systematically assessing how changes in business strategy, technical environments, or stakeholder priorities impact in-flight or baselined architectures.
   4. Disposal and Change Governance: Deciding whether a change request can be handled within current iterations, deferred to a future cycle, or rejected, and escalating to Architecture Board governance when necessary.

   Essential Conceptual Takeaways

   To succeed in applying and assessing Requirements Management in TOGAF Foundation concepts, remember these core principles:

   • Central Hub: It connects to all phases of the ADM, reflecting that requirements are dynamic and subject to constant refinement.
   • Baseline Requirements: Requirements are baselined at specific milestones, but baseline changes must pass through formal impact assessment.
   • Continuous Interaction: If a requirement cannot be met within the current architecture cycle, the Requirements Management process ensures it is formally documented and prioritized for subsequent ADM iterations rather than silently dropped.