Requirements Change Management

Requirements Change Management
Why Do Requirements
Change?
We failed to ask the right people the right questions at
the right time.
The problem being solved changed
The users changed their minds or their perceptions
The external environment changed
We failed to create a process to help manage change
Our understanding of the problem improved
Requirements Management
Architecture
Why to Manage Change?
“software systems are critical assets of any

organization, so they must invest in system
changes to maintain the value of these assets”.
(Ian Sommerville)
“Uncontrollable change is a common source of

project chaos (confusion), schedule slips and
quality problems.” (Karl E. Wiegers)
Change Management
Karl Wiegers illustrates:
◦ The change should be evaluated properly in advance.
◦ The appropriate individual should make decision about the
changes.
◦ Changes should be communicated to all involved participants.
◦ To incorporate requirements changes in a disciplined fashion.
Factors causing change
External Factors
◦ Those change agents over which the project team has no control.
Internal Factors
◦ Those change agents over which the project team has control.
External Factors
Change in the economy, in government regulations, or in the

marketplace and consumer preferences.
Change in the technology.
Changed user minds or their perceptions about what they wanted the
system to do.
Changed external environment, which creates new constraints and/or
new opportunities (ongoing improvements in computer hardware and
software system).
The organizational behavior evolves around the new system, the old
ways of doing things are no longer appropriate; the need for new types
of information emerge, an new requirements for the system inevitably
develop.
Internal Factors
Failed to ask the right people the right questions at the right time
during the initial requirements-gathering effort.
There is no practical process to manage changes to the requirements.
So encouraging, people to change whatever they wished whenever
they wished.
Traceability
What Is Requirements
Traceability?
Business Needs
drive
Customer Needs
which drive
User Needs
which demand
Product Features
that drive
Software Requirements
that we developers
Implement and Test
What is Requirements
Traceability?
Traceability is the "ability to describe and follow the life of
a requirement, in both forward and backward direction,
ideally through the whole system life cycle“. (Arnold, R. and
Bohner, S., 1996)
Traceability becomes a kind of roadmap to the project.

Traceability Relationships
Need
Traces to
Features
Traces to
Software requirements
Traces to
Traces to
Traces to
Use case
Traces to Traces to
Use case Glossary

Actor
section
Traceability Relations
Product
Requirements Req A 1. Trace top-level requirements into
(Features)
detailed requirements
1 2. Trace requirements into design
Detailed 3. Trace requirements into test
Requirements Req B procedures
(Use Cases)
4. Trace requirements into user
2 3 4 documentation plan
Design Test User Docs
Software Design Test Suites Documentation

Descriptions Plan
Object Models
Link Feature to Use Case
Vision Document
FEAT10:The recycling machine will allow the addition of new bottle
types.
[UC4: Use Case “Add New Bottle Type”]

New kinds of bottles can be added to the machine by starting it in
‘learning mode’ and inserting 5 samples …
Verifies that all lower level (derived requirements) are

consistent with stakeholder needs
Link Feature to Alternative flow
Within a Use Case
Vision Document
FEAT14:The recycling machine will sound an alarm if an invalid item is deposited.
UC1: Use Case “Recycle Items”

The user uses this machine to automatically …
UC1.1 Basic Flow
UC1.1.1 The use case starts when …
… UC1.1.6 End of Use Case …
Alternative Flows
[UC1.2 Deposit Item Not Valid …]
UC1.2.1 If at step UC1.1.2, the …
UC1.2.2 The item will be …
UC1.2.3 An alarm will sound …
UC1.2.4 Return to step UC1.1.2 …
UC1.3 Printer out of Paper …
If at step UC1.1.4, the paper sensor …
Link Feature to Section of a
Use Case
Vision Document
FEAT24:The recycling machine shall recognize deposit items with 95% reliability.
UC1: Use Case “Recycle Items”

The user uses this machine to automatically …
UC1.1 Basic Flow
Alternative Flows
UC1.2 Deposit Item Not Valid
Special Requirements
[UC1.17 Recycle items must be recognized with 95%
reliability]
...
Use-Case Diagram
Link Feature to Other
Requirements
Vision Document
FEAT101:The system shall provide maximum passenger comfort at all times.
Hardware Requirements
Specification
HR271:The motor control amplifier and
Supplementary Specification servo subsystem shall provide
SUPP201:The motor control servo sufficient capacity to accelerate and
algorithm shall provide smooth decelerate at a rate of 1G.
acceleration and deceleration profiles
with no detectable jerks, overshoots HR272:The environmental control
or undershoots. system shall maintain the temperature
of the elevator cabin to within 2
degrees C at all times
Verifies that all lower level (derived requirements) are consistent

with stakeholder needs
Link Requirements To
Implementation Objects
Product Requirements Document
FEAT101:The system shall provide maximum passenger comfort at all times.
Supplementary Specification
SUPP201:The motor control servo algorithm shall provide smooth acceleration and
deceleration profiles with no detectable jerks, overshoots, or undershoots.
Object Specifications
Object001
Name: AccelerationServo
Description: Algorithm to control acceleration and ....
Methods: Servo Algorithm, Motor Feedback
Attributes: Location, Velocity, Acceleration
Verifies that implementation supports the real requirements

Viewing Links - Traceability
Matrix
REQUIRED for your project
A Process for Managing Change
1. Recognize that change is inevitable
(expected) and plan for it.
2. Baseline the requirements.
3. Establish a single channel to control
change.
4. Use a change control system to capture
changes.
5. Manage change hierarchically.
Step 1: Recognize that Change is
Inevitable, and Plan for It
The team should develop an awareness that changing requirements
are inevitable and necessary.
Plan for managing change that should include some allowance for
change in the initial baseline.
Step 2: Baseline the Requirements
At the end of the elaboration phase the team should
baseline all known requirements for the system.
The base-lining process means collection of itemized
requirements in a document.
Once the baseline has been established, new
requirements can be more easily identified and
managed.
A request for a new requirement can be compared
against the existing baseline as whether it will
create a conflict with any other requirements.
Step 3: Establish a Single Channel
to Control Change
It is crucial that every change go through a single channel
to determine its impact on the system.
And to make the official decision as to whether the
change is going to be made in the system at all.
In a small project, this official channel can be
◦ The project champion or manager
◦ The "owner" of the Vision document and other requirements
artifacts
◦ Someone who has an overall understanding of the system
requirements and design.
Step 3: Establish a Single Channel
to Control Change (contd…)
In larger systems or ones that affect a variety of

stakeholders, this official channel should consist
of a few people (a Change Control Board, or CCB)
to decide when a change request is officially
approved.
Step 4: Use a Change Control
System to Capture Changes
During development, there will be a tremendous number
and variety of other types of potential changes to the
system.
The system should be used to capture all inputs and to
transmit them to the authority of the change control
board (CCB) for resolution.
The CCB should consist of no more than three to five
people who represent the key stakeholders for the
project: customers, marketing, and program
management.
Step 4: Use a Change Control System
to Capture Changes (contd…)
The CCB must consider the following factors:
◦ The impact of the change on the cost and functionality of the
system.
◦ The impact of the change on customers and other external stake
holders not well represented on the CCB: other project
contractors, component suppliers, and so on.
◦ The potential for the change to destabilize the system.
Step 5: Manage Change
Hierarchically
A change to one requirement can have a "ripple effect“.
◦ Like can any design-level changes have an impact on the
requirements?
◦ And do the changes to the software requirements have any impact
on the Vision document?
New feature/requirement has an impact on the cost,
schedule, reliability, and risk of the project.
To mitigate this ripple effect, changes to the
requirements should be carried out in the top-down
hierarchical fashion.
Change management
practices
Change management practices help you to understand and manage
these important project development aspects:
To determine the work consequences of that change, like to

determine the amount of rework that may be required.
To determine the effect of a change on your project resource
planning and workload planning.
To determine the effect of a change on the other elements of the
system.
Help to "roll back" a requirement and examine a previous revision
of the requirement.
Helpful to remember how and why the requirement was changed.
Three level change history
A change history should exist at three levels within your project.
1. Finest level: The change history records all changes to each individual
requirement within the project.
2. Middle level: Automatically maintain a similar change history for each
project document.
3. General level: Automatically maintain a similar change history for the
entire project.

Requirements Change Management

Uploaded by

Copyright:

Available Formats

Requirements Change Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements Change Management

Uploaded by

Copyright:

Available Formats

Requirements Change Management

“software systems are critical assets of any

“Uncontrollable change is a common source of

Change in the economy, in government regulations, or in the

Traceability becomes a kind of roadmap to the project.

Use case Glossary

Design Test User Docs

Software Design Test Suites Documentation

[UC4: Use Case “Add New Bottle Type”]

Verifies that all lower level (derived requirements) are

UC1: Use Case “Recycle Items”

UC1: Use Case “Recycle Items”

Verifies that all lower level (derived requirements) are consistent

Verifies that implementation supports the real requirements

In larger systems or ones that affect a variety of

To determine the work consequences of that change, like to

You might also like