of 32
7/29/2019 RESM lecture-18.pdf
1/32
1
Requirements Management - I
Lecture # 18
7/29/2019 RESM lecture-18.pdf
2/32
2
Requirements Engineering Process
Requirements
Elicitation
Requirements
Analysis and
Negotiation
Requirements
Specification
Requirements
Validation
User Needs,
Domain Information,
Existing System
Information, Regulations,
Standards, Etc.
Requirements
Document
Agreed
Requirements
7/29/2019 RESM lecture-18.pdf
3/32
3
Requirements Management
The process of managing changes to
the requirements for a system
In this lecture, well talk about the
reasons for changes in requirements
and how to manage them
7/29/2019 RESM lecture-18.pdf
4/32
4
Requirements Management and
Traceability Requirements cannot be managed
effectively without requirements traceability
A requirement is traceable if you can discoverwho suggested the requirement, why the
requirement exists, what requirements are
related to it and how that requirement relates to
other information such as systems designs,
implementations and user documentation
7/29/2019 RESM lecture-18.pdf
5/32
5
Change - A Constant There is nothing permanent except change
Heraclitus (500 B.C.)
No matter where you are in the system life
cycle, the system will change, and the desireto change it will persist throughout the lifecycle
Software is like a sponge due to itssusceptibility to change
7/29/2019 RESM lecture-18.pdf
6/32
6
Changing Requirements - 1
All stakeholders want to changerequirements, due to different reasons
Studies have shown that verysignificant percentage of delivered
defects can be traced back to changinguser requirements
7/29/2019 RESM lecture-18.pdf
7/32
7
Changing Requirements - 2
A major issue in requirements engineering
is the rate at which requirements change
once the requirements phase has officiallyended
This rate is on average 3% per month in the
subsequent design phase, and should godown after that
7/29/2019 RESM lecture-18.pdf
8/32
8
Changing Requirements - 3
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
7/29/2019 RESM lecture-18.pdf
9/32
9
Sources of Change - 1
New business or market conditions dictate
changes in product requirements or business
rules
New customer needs demand modification
of data produced by information systems,
functionality delivered by products, orservices delivered by computer-based
system
7/29/2019 RESM lecture-18.pdf
10/32
10
Sources of Change - 2
Reorganization or business
growth/downsizing causes changes in
project priorities or software
engineering team structure
Budgetary or scheduling constraintscause a redefinition of the system or
product
7/29/2019 RESM lecture-18.pdf
11/32
11
Why All This Modification?
As time passes, all constituencies knowmore
About what they need
Which approach would be best
How to get it done and still make money
Statement of the fact: most changes arejustified!
7/29/2019 RESM lecture-18.pdf
12/32
12
Managing Changing
Requirements ??? Following quality assurance
mechanisms can limit the damage done
by changing requirements
Formal change management procedures
State-of-the-art configuration controltools
Requirements reviews
7/29/2019 RESM lecture-18.pdf
13/32
13
Main Concerns in Requirements
Management Managing changes to agreed requirements
Managing the relationships between
requirements
Managing the dependencies between the
requirements document and other
documents produced in the systemsengineering process
7/29/2019 RESM lecture-18.pdf
14/32
14
CASE Tools for Requirements
Management Requirements management involves the
collection, storage and maintenance of large
amounts of information There are now a number of CASE tools
available which are specifically designed tosupport requirements management
Configuration management tools may beadapted for requirements engineering
7/29/2019 RESM lecture-18.pdf
15/32
15
Stable and Volatile Requirements
- 1 Requirements changes occur while the
requirements are being elicited,
analyzed and validated and after the
system has gone into service
Some requirements are more stable,while others may be more subject to
change than others
7/29/2019 RESM lecture-18.pdf
16/32
16
Stable and Volatile Requirements
- 2 Stable requirements are concerned with the
essence of a system and its application
domain. They change more slowly thanvolatile requirements
Volatile requirements are specific to the
instantiation of the system in a particularenvironment and for a particular customer
7/29/2019 RESM lecture-18.pdf
17/32
17
Requirements Change Factors - 1
Requirements errors, conflicts and
inconsistencies
Evolving customer/end-user
knowledge of the system
Technical, schedule or cost problems
7/29/2019 RESM lecture-18.pdf
18/32
18
Requirements Errors, Conflicts
and Inconsistencies As requirements are analyzed and
implemented, errors and
inconsistencies emerge and must be
corrected. These may be discovered
during requirements analysis and
validation or later in the development
process
7/29/2019 RESM lecture-18.pdf
19/32
19
Evolving Customer/End-user
Knowledge of the System As requirements are developed,
customers and end-users develop a
better understanding of what they
really require from a system
7/29/2019 RESM lecture-18.pdf
20/32
20
Technical, Schedule or Cost
Problems Problems may be encountered in
implementing a requirement. It may be
too expensive or take too long to
implement certain requirements
7/29/2019 RESM lecture-18.pdf
21/32
21
Requirements Change Factors - 2
Changing customer priorities
Environmental changes
Organizational changes
7/29/2019 RESM lecture-18.pdf
22/32
22
Changing Customer Priorities Customer priorities change during
system development as a result of a
changing business environment, the
emergence of new competitors, staff
changes, etc.
7/29/2019 RESM lecture-18.pdf
23/32
23
Environmental Changes
The environment in which the system
is to be installed may change so that
the system requirements have to
change to maintain compatibility
7/29/2019 RESM lecture-18.pdf
24/32
24
Organizational Changes
The organization which intends to use
the system may change its structure
and processes resulting in new system
requirements
7/29/2019 RESM lecture-18.pdf
25/32
25
Types of Volatile Requirements
Mutable requirements
Emergent requirements
Consequential requirements
Compatibility requirements
7/29/2019 RESM lecture-18.pdf
26/32
26
Mutable Requirements
These are requirements which change
because of changes to the environment
in which the system is operating
7/29/2019 RESM lecture-18.pdf
27/32
27
Emergent Requirements
These are requirements which cannot
be completely defined when the system
is specified but which emerge as the
system is designed and implemented
7/29/2019 RESM lecture-18.pdf
28/32
28
Consequential Requirements
These are requirements which are
based on assumptions about how the
system will be used. When the system
is put into use, some of these
assumptions will be wrong
7/29/2019 RESM lecture-18.pdf
29/32
29
Compatibility Requirements
These are requirements which depend
on other equipment or processes
7/29/2019 RESM lecture-18.pdf
30/32
30
Summary - 1
Requirements change is inevitable as
customers develop a better
understanding of their real needs and
as the political, organizational and
technical environment in which a
system is to be installed, changes.
7/29/2019 RESM lecture-18.pdf
31/32
31
Summary - 2
There are Stable and volatile
requirements
Types of volatile requirement include
mutable requirements, emergent
requirements, consequential
requirements and compatibility
requirements
7/29/2019 RESM lecture-18.pdf
32/32
32
References
Software Engineering: A Practitioners
Approach by Roger S. Pressman
Requirements Engineering: Processes
and Techniques by G. Kotonya and I.
Sommerville, John Wiley & Sons,
1998
