0% found this document useful (0 votes)
24 views19 pages

Requirement Change Management

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views19 pages

Requirement Change Management

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 19

Requirement

Change
Management
Ameer Hamza
What is Requirement Change
Management?

 "A systematic approach to identifying, evaluating, and implementing


changes to requirements during the project lifecycle."
Common Causes

• Evolving business needs.


• Market dynamics and competition.
• Stakeholder need.
• Technology advancements.
• Errors or omissions in initial requirements.
Changing Requirements

 All stakeholders want to change requirements, due to different


reasons
 Studies have shown that very significant percentage of delivered
defects can be traced back to changing user requirements.
 A major issue in requirements engineering is the rate at which
requirements change once the requirement phase has officially
ended.
 This rate is on average 3% per month in the subsequent design
phase, and should godown after that.
 This rate should come down to 1% per month during coding.
 Ideally, this should come down to no changes in testing, however,
this is very rare
Requirement Change Factors

 Requirement conflict
 End knowledge of the system
 Schedule or cost of problem
 Environmental change
 Organizational change
Volatile Requirement:

 Volatile Requirement refers to requirements that are likely to


change frequently during the software development lifecycle due to
various reasons such as evolving business needs, market conditions,
or stakeholder feedback
Enduring Requirement

 Enduring Requirement refers to requirements that are relatively


stable and unlikely to change over time. These requirements often
represent the core functionality, constraints, or goals of a system and
are typically aligned with long-term business objectives.
Requirements Change
Management Process
 1. Change Identification

• Purpose: Identify when a requirement change is necessary, and


capture requests for modifications.
• Process: Change requests may arise from stakeholders, market
changes, or regulatory updates..
 2. Impact Analysis

• Purpose: Assess the potential impacts of a change on existing


requirements, project scope, timeline, cost, and resources.
• Process: The team evaluates how the proposed change will interact
with current requirements, affect dependencies, and influence overall
project scope. A detailed impact analysis highlights the trade-offs and
potential risks associated with implementing the change.
 3. Change Evaluation

• Purpose: Weigh the pros and cons of implementing the change to


make an informed decision.
• Process: The team considers the value the change will bring, the
associated risks, and how it aligns with project objectives. Cost-
benefit analysis, feasibility studies, and prioritization techniques can
aid in evaluating each change request.
 4. Approval Process

• Purpose: Define who has the authority to approve or reject changes,


ensuring accountability.
• Process: Establish a Change Control Board (CCB) or designate
decision-makers responsible for approving changes. Approval criteria
and levels should be clearly outlined, ensuring only beneficial and
feasible changes move forward.
 5. Change Documentation

• Purpose: Maintain a clear record of all changes, their justifications,


impacts, and approval history.
• Process: Document each change, including the reason for the
change, impact analysis, approval details, and any additional notes.
This creates a traceable history, which is essential for project audits,
accountability, and communication with stakeholders.
 6. Change Implementation

• Purpose: Integrate the approved change into the existing


requirements, ensuring smooth incorporation.
• Process: After approval, the change is assigned to the relevant team
members for integration. This phase involves updating requirements
documents, modifying affected components, and conducting tests if
necessary. A structured implementation plan minimizes errors and
ensures the change is executed efficiently.
Requirements Change Management
Technique
1. Change Control Process

 Description:
A formalized approach for managing and implementing changes to
requirements while maintaining control over scope, cost, and schedule.
 Steps:
1. Submission: Stakeholders submit a change request (CR) detailing the
proposed change and its justification.
2. Evaluation: The Change Control Board (CCB) reviews the CR, assessing
its impact on the project.
3. Approval/Rejection: Decisions are documented. Approved changes
are implemented, and stakeholders are notified.
4. Implementation and Verification: The approved change is
implemented, tested, and verified to meet requirements.
2. Impact Analysis

 Purpose:
Evaluate how a proposed change will affect the existing project
requirements, design, architecture, and schedule.
 Steps:
1. Identify the affected requirements and associated dependencies.
2. Assess potential ripple effects on related modules or components.
3. Estimate the required effort, time, and cost for implementation.
4. Document findings for stakeholder review.
3. Stakeholder Communication

 Purpose:
Engage stakeholders throughout the change management process to
ensure alignment and reduce resistance.
 Steps:
1. Use collaborative workshops or meetings to discuss changes.
2. Clearly communicate the impact and benefits of changes.
3. Involve stakeholders in decision-making to increase buy-in.
4. Prototyping and Incremental
Development

 Definition:
Developing visual prototypes or incremental versions to help
stakeholders understand the impact of changes before final
implementation.
 Benefits:
• Reduces costly rework by refining changes iteratively.
• Enables early feedback and validation.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy