Session 12: Requirements Management (Part II)
Software Requirements
Engineering
15th December 2020
1
Discussion
2
Beware of your
deeds in this life,
for they are
adding up in the
next
The change management process
◼ Some requirements problem is identified.
▪ This could come from an analysis of the requirements, new
customer needs, or operational problems with the system. The
requirements are analysed using problem information and
requirements changes are proposed.
◼ The proposed changes are analysed
▪ This checks how many requirements (and, if necessary, system
components) are affected by the change and roughly how much it
would cost, in both time and money, to make the change.
◼ The change is implemented.
▪ A set of amendments to the requirements document or a new
document version is produced. This should, of course, be validated
using whatever normal quality checking procedures are used.
3
Change management stages
Identified
problem
Problem analysis and Change analysis Change
change specification and costing implementation
Revised
requirements
Change analysis and costing
Rejected request
Change
request Req. list
Check request Find directly Find dependent
validity affected requirements
Valid requirements
request
Requirements change list Rejected request
Cost
Requirements information Accepted
Propose changes change
Assess costs Assess cost
requirements of change acceptability
changes
Rejected request Rejected request
Customer Customer
information information
6
Change analysis activities
◼ The change request is checked for validity. Customers can
misunderstand requirements and suggest unnecessary
changes.
◼ The requirements which are directly affected by the change
are discovered.
◼ Traceability information is used to find dependent
requirements affected by the change.
◼ The actual changes which must be made to the requirements
are proposed.
◼ The costs of making the changes are estimated.
◼ Negotiations with customers are held to check if the costs of
the proposed changes are acceptable.
7
Change request rejection
◼ If the change request is invalid. This normally
arises if a customer has misunderstood
something about the requirements and
proposed a change which isn’t necessary.
◼ If the change request results in consequential
changes which are unacceptable to the user.
◼ If the cost of implementing the change is too
high or takes too long.
8
Change processing
◼ Proposed changes are usually recorded on a
change request form which is then passed to
all of the people involved in the analysis of
the change
◼ Change request forms may include
▪ fields to document the change analysis
▪ data fields
▪ responsibility fields
▪ status field
▪ comments field
9
Tool support for change management
◼ May be provided through requirements management tools or
through configuration management tools
◼ Tool facilities may include
▪ Electronic change request forms which are filled in by different
participants in the process.
▪ A database to store and manage these forms.
▪ A change model which may be instantiated so that people responsible for
one stage of the process know who is responsible for the next process
activity.
▪ Electronic transfer of forms between people with different responsibilities
and electronic mail notification when activities have been completed.
▪ In some cases, direct links to a requirements database.
10
Requirements Traceability
11
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
12
What is Requirements Traceability?
◼Traceability is:
“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.
13
Traceability Definitions
IEEE (1994) provides definitions of traceability
"The degree to which a relationship can be
established between two or more products of
the development process, especially products
having a predecessor-successor or master-
subordinate relationship to one another; for
example, the degree to which the requirements
and design of a given software component
match." (IEEE 610.12-1990 §3)
14
Traceability
◼ Traceability information is information which helps you assess
the impact of requirements change. It links related
requirements and the requirements and other system
representations
◼ Types of traceability information
▪ Backward-from traceability Links requirements to their sources in
other documents or people
▪ Forward-from traceability Links requirements to the design and
implementation components
▪ Backward-to traceability Links design and implementation
components backs to requirements
▪ Forward-to traceability Links other documents (which may have
preceded the requirements document) to relevant requirements.
Backwards/forwards Traceability
Business plan Requ irements Document Design Specification
Forward-to traceability Forward-from traceability
Backward-from traceability Backward-to traceability
Types of Traceability
◼ Requirements-sources traceability
▪ Links the requirement and the people or
documents which specified the requirement
◼ Requirements-rationale traceability
▪ Links the requirement with a description of why
that requirement has been specified.
◼ Requirements-requirements traceability
▪ Links requirements with other requirements
which are, in some way, dependent on them.
This should be a two-way link (dependants and
is-dependent on).
Types of Traceability
◼ Requirements-architecture traceability
▪ Links requirements with the sub-systems where these
requirements are implemented. This is particularly
important where sub-systems are being developed by
different sub-contractors
◼ Requirements-design traceability
▪ Links requirements with specific hardware or software
components in the system which are used to implement
the requirement
◼ Requirements-interface traceability
▪ Links requirements with the interfaces of external
systems which are used in the provision of the
requirements
Traceability Tables
◼ Traceability tables show the relationships
between requirements or between
requirements and design components
◼ Requirements are listed along the horizontal
and vertical axes and relationships between
requirements are marked in the table cells
◼ Traceability tables for showing requirements
dependencies should be defined with
requirement numbers used to label the rows
and columns of the table
A Traceability Table
Depends -on
R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6
Traceability Lists
◼ If a relatively small number of requirements have to be
managed (up to 250, say), traceability tables can be
implemented using a spreadsheet
◼ Traceability tables become more of a problem when there
are hundreds or thousands of requirements as the tables
become large and sparsely populated
◼ A simplified form of traceability table may be used where,
along with each requirement description, one or more lists
of the identifiers of related requirements are maintained.
◼ Traceability lists are simple lists of relationships which can
be implemented as text or as simple tables
A traceability List
Requirement Depends -on
R1 R3, R4
R2 R5, R6
R3 R4, R5
R4 R2
R5 R6
Traceability Policies
◼ Traceability policies define what and how traceability
information should be maintained.
◼ Traceability policies may include
▪ The traceability information which should be maintained.
▪ Techniques, such as traceability matrices, which should be used for
maintaining traceability.
▪ A description of when the traceability information should be collected
during the requirements engineering and system development
processes.
▪ The roles of the people, such as the traceability manager, who are
responsible for maintaining the traceability information should also be
defined.
▪ A description of how to handle and document policy exceptions
▪ The process of managing traceability information
Factors influencing traceability policies
◼ Number of requirements
▪ The greater the number of requirements, the
more the need for formal traceability policies.
◼ Estimated system lifetime
▪ More comprehensive traceability policies should
be defined for systems which have a long
lifetime.
◼ Level of organisational maturity
▪ Detailed traceability policies are most likely to be
cost-effective in organisations which have a
higher level of process maturity
Factors influencing traceability policies
◼ Project team size and composition
▪ With a small team, it may be possible to assess the impact of
proposed informally without structured traceability information.
With larger teams, however, you need more formal traceability
policies.
◼ Type of system
▪ Critical systems such as hard real-time control systems or safety-
critical systems need more comprehensive traceability policies
than non-critical systems.
◼ Specific customer requirements
▪ Some customers may specify that specific traceability information
should be delivered as part of the system documentation.
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
26
Traceability Relations
Product
Requirements Req A
(Features) 1. Trace top-level requirements into
detailed requirements
1 2. Trace requirements into design
3. Trace requirements into test
Detailed procedures
Requirements Req B
(Use Cases)
4. Trace requirements into user
documentation plan
2 3 4
Design Test User Docs
Software Design Test Suites Documentation
Descriptions Plan
Object Models
27
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
28
Link Feature to Alternative flow
Within a Use Case
Requirements Document
Req-1: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 …
29
Link Feature to Section of a Use
Case
SS 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
30
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 sufficient
SUPP201:The motor control servo capacity to accelerate and decelerate at
algorithm shall provide smooth 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
31
Viewing Links - Traceability Matrix
32
Example (Forward Traceability)
33
Example (Backward Traceability)
34
A Process for Managing Change
1. Recognize that change is inevitable, 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.
35
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.
36
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.
37
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.
38
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.
39
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.
40
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.
41
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.
42
Q&A
43
