Requirements Impact Assessment

Requirements Impact Assessment in TOGAF 10 Foundation

Understanding Requirements Impact Assessment

What is Requirements Impact Assessment?

Requirements Impact Assessment is a critical activity within the TOGAF ADM (Architecture Development Method) that evaluates the consequences and effects of proposed changes, new requirements, or modifications to existing requirements on the enterprise architecture. It is part of the Requirements Management phase and helps organizations understand how requirements changes will affect different aspects of the architecture, systems, processes, and stakeholders.

Why Is Requirements Impact Assessment Important?

1. Risk Management
Identifying potential negative impacts before implementation reduces risks associated with architectural changes. This allows organizations to develop mitigation strategies proactively.

2. Resource Planning
Understanding the full scope of impact helps in accurate resource allocation, budgeting, and timeline estimation for implementing architectural changes.

3. Stakeholder Communication
Impact assessments provide clear documentation of how changes affect different stakeholders, enabling transparent communication and managing expectations.

4. Decision Making
Senior management and architecture governance bodies need comprehensive impact information to make informed decisions about accepting, rejecting, or modifying requirements.

5. Cost-Benefit Analysis
Organizations can weigh the benefits of new requirements against the costs and disruptions they will cause, ensuring optimal return on investment.

6. Dependency Management
Impact assessment reveals dependencies between systems, processes, and other architecture components, preventing unexpected cascading failures.

How Requirements Impact Assessment Works

Phase 1: Identification of Requirements Changes
The process begins by identifying new requirements or modifications to existing ones. These may come from business drivers, stakeholder requests, regulatory changes, or technology innovations.

Phase 2: Analysis of Current State
The architecture team thoroughly understands the current enterprise architecture, including systems, processes, data flows, organizational structures, and dependencies. This baseline is essential for measuring impact.

Phase 3: Mapping Requirements to Architecture Components
The team identifies which architecture domains and components would be affected by the requirement changes:

• Business Architecture: Impact on business processes, organizational structure, and business capabilities
• Data Architecture: Impact on data models, data flows, and information management
• Application Architecture: Impact on applications, their interfaces, and integration points
• Technology Architecture: Impact on infrastructure, platforms, and technical standards

Phase 4: Impact Assessment
For each affected component, the team evaluates:

• Scope of Change: How many components or systems are affected?
• Magnitude of Impact: How significant is the change?
• Type of Impact: Is it functional, technical, organizational, or financial?
• Timeline Impact: What is the urgency and implementation schedule?
• Cost Impact: What are the direct and indirect costs?
• Risk Impact: What new risks are introduced?

Phase 5: Documentation
All findings are documented in impact assessment reports that clearly articulate the analysis, findings, and recommendations.

Phase 6: Communication and Recommendation
Results are communicated to stakeholders and architecture governance bodies with clear recommendations on accepting or modifying the requirements.

Key Considerations in Requirements Impact Assessment

Ripple Effects and Dependencies
Changes rarely affect just one component. Requirements Impact Assessment must trace through the architecture to identify secondary and tertiary effects. For example, a change in a data structure might impact multiple applications, reporting tools, and business processes.

Interdependencies Across Domains
The assessment must consider how changes in one architectural domain affect others. A technology change might require process modifications and organizational restructuring.

Stakeholder Perspectives
Different stakeholders experience impact differently. Business stakeholders are concerned about process disruptions and costs, while technical stakeholders focus on system compatibility and integration challenges.r
Prioritization and Sequencing
When multiple requirements are under assessment, the team must prioritize them based on impact, urgency, and available resources. Some requirements may need to be sequenced to minimize cumulative impact.r
Reversibility
Some changes are reversible with minimal effort, while others are difficult or impossible to undo. This affects risk assessment and decision-making.r

Requirements Impact Assessment in the ADM

Requirements Impact Assessment is a continuous activity throughout the ADM lifecycle:

• Phase A (Architecture Vision): Initial requirements are assessed for their impact on the architecture vision
• Phase B-D (Development Phases): New requirements are continuously assessed as they arise
• Phase E (Opportunities and Solutions): Implementation options are evaluated for their impacts
• Phase F (Migration Planning): Implementation impacts are thoroughly assessed
• Requirement Management: Requirements changes are perpetually assessed throughout the architecture lifecycle

Exam Tips: Answering Questions on Requirements Impact Assessment

Tip 1: Understand the Definition
Know that Requirements Impact Assessment is about evaluating the consequences and effects of requirement changes on the enterprise architecture. Exam questions often test whether you understand this is forward-looking (what will happen) rather than backward-looking.

Tip 2: Remember the Multi-Domain Perspective
Always consider all four architectural domains: Business, Data, Application, and Technology. A complete answer demonstrates understanding that requirements impact these domains differently. If the question asks about a specific change, mention potential impacts across all relevant domains.

Tip 3: Focus on Dependencies and Ripple Effects
Exam questions often test your understanding that impact assessment must trace dependencies. Be prepared to discuss how changes ripple through systems and processes. Use keywords like "interdependencies," "downstream effects," and "cascading changes."r
Tip 4: Connect to Governance and Decision-Making
Understand that impact assessment feeds into architecture governance and decision-making processes. The purpose of the assessment is to provide decision-makers with the information they need to approve or reject requirements. Answers should reflect this purpose.

Tip 5: Distinguish from Other ADM Activities
Don't confuse Requirements Impact Assessment with requirements elicitation, analysis, or specification. Requirements Impact Assessment specifically evaluates the effects of requirements, not how to gather or define them. On exam questions asking "what happens after requirements are identified?", think impact assessment.r
Tip 6: Know the Assessment Dimensions
Be ready to discuss impacts across multiple dimensions: technical, financial, organizational, timeline, and risk. Questions may ask about different types of impacts, and your answer should be comprehensive and multi-dimensional.

Tip 7: Remember Stakeholder Consideration
Good impact assessments consider different stakeholder perspectives. Exam questions may ask how different groups experience impact differently. Include stakeholders in your reasoning.r
Tip 8: Recognize Iterative Nature
Impact assessment is not a one-time activity but continuous throughout the ADM. If a question asks when impact assessment occurs, remember it happens in multiple phases and during Requirements Management.r
Tip 9: Look for Process Keywords
In exam questions, watch for terms like "change request," "new requirement," "modification," or "requirement update." These signal that you should be thinking about impact assessment.r>
Tip 10: Practice Scenario-Based Questions
Requirements Impact Assessment is often tested through scenario questions. When given a scenario with a requirement change, practice systematically identifying:r

• Which architecture components are affected
• What types of impacts exist (technical, organizational, financial)
• Who the stakeholders are and how they're affected
• What risks emerge
• What resources and timeline are needed
• What recommendation you would make

Tip 11: Study Real-World Examples
The TOGAF documentation includes examples of requirements impact assessments. Study these to understand how the activity works in practice. Real exam scenarios often mirror these examples.r>
Tip 12: Connect to Architecture Governance
Understand how Requirements Impact Assessment feeds into the architecture governance framework (TOGAF Phase F). The assessment results inform Architecture Review Board decisions. Mention governance and review processes in your exam answers when discussing the purpose and outcome of impact assessments.r>
Sample Exam Question and Approach:

"A business requirement is identified to integrate a new third-party SaaS application with the organization's existing ERP system. What should be included in a Requirements Impact Assessment for this change?"

How to Answer:

1. Define what Requirements Impact Assessment is
2. Identify affected domains: Application Architecture (integration points), Technology Architecture (infrastructure, security), Data Architecture (data synchronization), and Business Architecture (process changes)
3. Discuss specific impacts: integration complexity, data migration, security considerations, vendor management, organizational change management needed
4. Mention stakeholder impacts: IT team, business users, data administrators, management
5. Discuss resource and timeline implications
6. Identify risks: vendor lock-in, data quality, system performance impact
7. Recommend next steps: governance review, detailed design, pilot testing

Key Takeaways

Requirements Impact Assessment is a vital TOGAF practice that ensures architectural changes are thoroughly evaluated before implementation. Success in exam questions requires understanding:

• It evaluates consequences of changes on the enterprise architecture
• It examines impacts across all four architecture domains
• It identifies dependencies, ripple effects, and stakeholder impacts
• It supports governance decisions about requirements acceptance
• It is a continuous activity throughout the ADM lifecycle
• It considers multiple perspectives: technical, organizational, financial, and risk-related