SOFTWARE REQUIREMENTS

MANAGEMENT

CHAPTER - 6

Prepared By : Berhanu S.
 Requirement Management
 The process of managing change to the requirements for a
system
 It is the process of documenting, analyzing, tracing,
prioritizing and agreeing on requirements and then
controlling change and communicating to relevant
stakeholders.
 All of this has to take place within a controlled environment
so that each requirement can be traced back to a specific
need and also traced to a function/feature/piece of code
in the system being developed
 Requirements Management is the control framework that
governs this process
 Cont…
 The purpose of requirements management is to ensure that
the organization validates and meets the needs of its
customers and external and internal stakeholders.
 Requirements management involves communication between
the project team members and stakeholders, and adjustment
to requirements changes throughout the course of the project.
 To prevent one class of requirements from overriding another,
constant communication among members of the development
team is critical.
 Requirements management does not end with product
release.
 It is a continuous process throughout a project.
Cont…
Requirements management encompasses the activities
involved in
 Managing changes to agreed requirements

 Managing the relationships between requirements

 Requesting changes to the baseline requirements,

 Performing impact analysis for the requested changes,

 Approving or disapproving changes,

 implementing the approved changes

 Measure the progress

 Managing the logical links between individual

requirements and other project work products
 Cont..
 Requirement Management process must ensure that:
 Negotiations between the stakeholders and project team are
facilitated.
 All requirements are fully negotiated, defined and prioritized
between the stakeholders.
 A coherent and complete requirements document is issued, agreed
upon and kept up to date during the lifecycle of the project.
 Commitment to the requirements is given by all stakeholders.

 Any changes to requirements during the project lifecycle are

reviewed, verified, negotiated, approved and implemented.
 All changes are fully tracked and traceable.

 All requirements are mapped to test cases; source code; design. This
traceability is bidirectional.
Cont…
Requirements
Management

Change control Version control Requirements Requirements

status tracking tracing
 Proposing  Defining a version  Defining a  Defining links to
changes identification possible other
scheme requirement requirements
 Analyzing impact
statuses
 Identifying  Defining links to
 Making decisions
requirements  Recording the other system
 Updating document status of each elements
requirements versions requirement
documents
 Identifying  Reporting the
 Updates plans individual status distribution
requirement of all
 Measuring
versions requirements
requirements
volatility
Requirements evolution
 Stable and volatile requirements
8

 Requirements changes occur while the requirements are

being elicited, analysed and validated and after the
system has gone into service
 Some requirements are usually more subject to change
than others
 Types of requirement evolution
 Stable requirements are concerned with the essence of a
system and its application domain. They change more slowly
than volatile requirements.
 Volatile requirements are specific to the instantiation of the
system in a particular environment and for a particular
customer.
 Types of volatile requirement

 Mutable requirements – These are requirements which change

because of changes to the environment in which the system is
operating
 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
 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.
 Compatibility requirements – These are requirements which
depend on other equipment or processes.
 Requirements management planning
 Establishes the level of requirements management detail that is
required.
Requirements management decisions:
 Requirements identification:- Each requirement must be uniquely
identified
 Traceability policies :-These policies define the relationships

between each requirement and between the requirements and

the system
 A change management process:- This is the set of activities that

assess the impact and cost of changes.

 Tool support :-Tools that may be used range from specialist

requirements management systems to spreadsheets and simple

 Requirements identification
11

 It is essential for requirements management that every

requirement should have a unique identification
 The most common approach is requirements numbering
based on chapter/section in the requirements document
 Problems with this are:
 Numbers cannot be unambiguously assigned until the
document is complete
 Assigning chapter/section numbers is an implicit
classification of the requirement. This can mislead readers of
the document into thinking that the most important
relationships are with requirements in the same section
 Requirements identification techniques
12

 Dynamic renumbering
 Some word processing systems allow for automatic renumbering of
paragraphs and the inclusion of cross-references. As you re-organise
your document and add new requirements, the system keeps track of
the cross-reference and automatically renumbers your requirement
depending on its chapter, section and position within the section
 Database record identification
 When a requirement is identified it is entered in a requirements
database and a database record identifier is assigned. This database
identifier is used in all subsequent references to the requirement
 Symbolic identification
 Requirements can be identified by giving them a symbolic name which is
associated with the requirement itself. For example, EFF-1, EFF-2, EFF-3
may be used for requirements which relate to system efficiency
 Requirement Traceability
13

 Traceability information is information which helps you

assess the impact of requirements change.
 It links related requirements and the requirements and
other system representations
 It refers to the ability to describe and follow the life
of a requirement, in both forwards and backwards
direction (i.e., from its origins, through its development
and specification, to its subsequent deployment and
use, and through all periods of ongoing refinement
and iteration in any of these phases).
 One cannot manage what cannot be traced.
 Cont…
14

 A software requirements specification is traceable if the

origin of each of its requirements is clear and if it facilitates
the referencing of each requirement in future development
or enhancement documentation.
 Traceability gives essential assistance in understanding the
relationships that exist within and across software
requirements, design, and implementation.
 link or relationship defined between entities.
 Traceability is a property of a system description technique
that allows changes in one of the three system descriptions –
requirements, specifications, implementation – to be traced
to the corresponding portions of the other descriptions.
 Importance of Traceability
15

 Requirements cannot be managed effectively without

requirements traceability
 A requirement is traceable if you can discover who
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
 Cont…
16

Benefits of traceability
 Prevents losing knowledge

 Supports the verification process (certification, localization of

defects)
 Impact analysis

 Change control

 Process monitoring

 Improved software quality (make changes correctly and completely)

 Reengineering (define traceability links is a way to record reverse

engineering knowledge)
 Reuse (by identifying what goes with a requirement: design, code…)

 Risk reduction (e.g., if a team member with key knowledge leaves)

 Traceability Difficulties
17

 Various stakeholders require different information

 Huge amount of requirements traceability information
must be tracked and maintained
 Manual creation of links is very demanding
 Specialized tools must be used
 Integrating heterogeneous models/information from/to
different sources (requirements, design, tests, code&
documentation)
 Requires organizational commitment (with an
understanding of the potential benefits)
 Backward and Forward Traceability
18

 Backward traceability
 To previous stages of development
 Depends upon each element explicitly referencing its source in
earlier documents
 Forward traceability
 To all documents spawned by a document
 Depends upon each element in the document having a unique
name or reference number
Business plan Requirements Document Design Specification
Forward-to traceability Forward-from traceability
Backward-from traceability Backward-to traceability
 Cont…
19

Top to bottom from requirements‟ point of view

 Forward-to traceability

 Linksother documents (which may have preceded the

requirements document) to relevant requirements
 Forward-from traceability
 Linksrequirements to the design and implementation
components
 Help assure that all requirements have been satisfied
 Cont…
20

Bottom to top from requirements‟ point of view

 Backward-to traceability

 Links design and implementation components back to

requirements
 Help determine why each item is
designed/implemented
 Backward-from traceability
 Help evaluate how changes to requirements impact
stakeholders needs
 Types of Traceability
21

 Requirements – source traceability

 Links requirements with a person or document
 Requirements – requirements traceability
 Links requirements with other requirements which are, in some way,
dependent on them
 Requirements – architecture traceability
 Links requirements with the subsystems where these requirements
are implemented (particularly important where subsystems are
being developed by different subcontractors)
 Requirements – design traceability
 Links requirements with specific hardware or software components
in the system which are used to implement the requirement
 Cont…
22

 Requirements – interface traceability

 Links requirements with the interfaces of external
systems which are used in the provision of the
requirements
 Requirements – feature traceability
 Requirements – tests traceability
 Links requirements with test cases verifying them
(used to verify that the requirement is implemented)
 Requirements – code traceability
 Traceability tables
23

 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
24

Depends -on
R1 R2 R3 R4 R5 R6
R1 * *
R2 * *
R3 * *
R4 *
R5 *
R6
 Traceability lists
25

 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
26

Requirement Depends -on

R1 R3, R4
R2 R5, R6
R3 R4, R5
R4 R2
R5 R6
 Example of Traceability Links
27

Business
requirement
modifies
Drives specification of

System requirements, influences

Change modifies
use case, external Business rule
request
interface, quality attribute

Is origin of Is origin of
modifies modifies
Software functional
Depends on another
requirement
Is satisfied by
Is verified by Lead to creation of
Architectrue, Project plan
user interface, or System test
task
functional design
Is verified by Is implemented in

Integration test Code

Is verified by

Unit test
 Cardinality of Traceability Links
28

 Depending on the traceability information, the

cardinality of traceability links may be
 One-to-one
 e.g., one design element to one code module
 One-to-many
 e.g., one functional requirement verified by multiple test cases
 Many-to-many
 e.g.,a use case may lead to multiple functional requirement,
and a functional requirement may be common to several use
cases
Change Management Process
What is a Change Management
Process
 A Change Management Process is a method by which
changes to the project (e.g. to the scope, deliverables,
timescales or resources) are formally defined, evaluated
and approved prior to implementation
 The process entails completing a variety of control
procedures to ensure that, if implemented, the change will
cause minimal impact to the objectives of the project.
 A Change Management Process is used to ensure that every
change identified is formally:
 Communicated
 Documented
 Reviewed
 Approved
 Implemented
When to use a Change Management
Process
 Any change to the project during the Execution
phase will need to be formally managed as part of
the Change Management Process.
 Without a formal Change Management Process in
place, the objective of delivering a solution within
„time, cost and quality‟ may be compromised.
 The Change Management Process is terminated only
when the Execution phase of the project is
completed (i.e. just prior to Project Closure).
Identify and Submit Change Request
 This process provides the ability for any member of the
project team to submit a request for a change to the project.
The Change Requester:
 Identifies a requirement for change to any aspect of the project (e.g.
scope, deliverables, timescales and organization)
©

 Completes a Change Request Form (CRF) and distributes the form to the
Project Manager. The CRF summarizes the change:
 Description
 Reasons
 Benefits
 Costs
 Impacts
 Any supporting documentation
 Approvals
Review Change Request
 The Project Manager reviews the CRF and determines
whether or not additional information is required for the
Change Control Board to assess the full impact of the
change to the project time, scope and cost. The decision
will be based on factors, such as:
 Number of change options presented
 Feasibility and benefits of the change
 Complexity and/or difficulty of the change options
requested
 Scale of the change solutions proposed.
 The Project Manager will record the CRF details in the
Change Log to track the status of the change request.
Approve Change Request
 The Project Manager will forward the Change Request Form and any
supporting documentation to the Change Control Board (CCB) for
review and final approval. The CCB will determine the feasibility of
this change by examining factors, such as:
 Risk to the project in implementing the change
 Risk to the project in NOT implementing the change
 Impact on the project in implementing the change (time, resources,
finance, quality).
 After a formal review, the CCB may:
 Reject the change
 Request more information related to the change
 Approve the change as requested
 Approve the change subject to specified conditions.
Implement and Close Change Request

 If the change is approved, the following will occur:

 An implementation date of the change will be
identified
 A test of the change will be scheduled and performed
 The change will be implemented
 The implementation of the change will be reviewed and
deemed successful or corrective actions taken
 The success of the change implementation will be
communicated to all parties
 The change request will be closed on the Change Log
Change Management Documents
 Change Request Form
 The „Change Request Form‟ is used to identify and
describe a proposed change to the project.
 Change Log
 The „Change Log‟ is the log where all requests for
changes are registered and tracked through to
resolution.
Baseline for Requirements

 Represents the set of functional and non-functional

requirements that the development team has committed
to implement in a specific release
 Before going into the baseline, the requirements should
be reviewed and approved by stakeholders
 Once in the baseline, all changes should follow a
defined change control process
Baseline
 Different viewpoints  Shared understanding
 No formal documents  Configuration management
 Always changing  Change management
 Cont…
40

 Subsequent changes can be made only through the project's

defined change-control process
 Non-modifiable (read-only) version of a document
 May include multiple documents at the same time
 Enables document comparison and management
 Comes with a change history for the document
 Requires access control
 It is advisable to establish a baseline for a new
document that is imported into the document
management system
 In order not to lose any changes
Baseline Usage

 Baselines may be
 Created
 Complete image of requirements state at a given time
 Deleted
 Visualized
 Possibility to go back
 Compared
 To see changes since a certain time
 Copied
 Signed
 For authorization, contract
Requirements Management Tools
 A requirements management tool is a software
system that helps you manage the various manually
intensive tasks in the requirements development and
requirements management processes.
 Good requirements management tools (RM Tools)
can help your team to save time and increase their
productivity among other benefits.
Characteristics of requirements
management tools

 To store the requirement statements.

 To store the information about requirement attributes.
 To check consistency of requirements.
 To identify undefined, missing or „to be defined later‟
requirements.
 To prioritize requirements for testing purposes.
 To trace the requirements to tests and tests to
requirements, functions or features.
 To trace through all the levels of requirements.
When to Use Requirements
Management Tools
 Based on "Number of Requirements
 Small projects with less than 200 requirements can be usually
managed using spreadsheets, wikis or simple databases
 Medium-sized projects with 200-2000 requirements usually need
to look for a commercial tool
 Large projects with over 2000 requirements necessitate the use of
robust commercial requirements management tools
 Based on "Size of Project Team
 For projects with less than 5 personnel all of whom are co-
located, a commercial requirements management tool is often not
needed.
 Larger teams, especially teams distributed across multiple cities
or even countries, can often benefit immensely from using good
requirements management tools.
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 to support
requirements management
 Configuration management tools may be adapted for
requirements engineering
Types of Requirements Management
Tools
 Heavyweight Requirements Management Tools
 IBM Rational RequisitePro
 Middleweight Requirement Management Tools
 Accompa Requirements Management Tool
 Lightweight Requirement Management Tools
 Spread Sheets
 Requirements management tool support
47

 A database system for storing requirements.

 Document analysis and generation facilities to help
construct a requirements database and to help
create requirements documents.
 Change management facilities which help ensure
that changes are properly assessed and costed.
 Traceability facilities which help requirements
engineers find dependencies between system
requirements.
 Storing requirements
48

 Requirements have to be stored in such a way that

they can be accessed easily and related to other
system requirements
 Possible storage techniques are
 In one or more word processor files - requirements are
stored in the requirements document
 In a specially designed requirements database
 Word processor documents
49

 Advantages
 Requirements are all stored in the same place
 Requirements may be accessed by anyone with the right word
processor
 It is easy to produce the final requirements document
 Disadvantages
 Requirements dependencies must be externally maintained
 Search facilities are limited
 Not possible to link requirements with proposed requirements
changes
 Not possible to have version control on individual requirements
 No automated navigation from one requirement to another
 Requirements database
50

 Each requirement is represented as one or more

database entities
 Database query language is used to access
requirements
 Advantages
 Good query and navigation facilities
 Support for change and version management
 Disadvantages
 Readers may not have the software/skills to access the
requirements database
 The link between the database and the requirements
document must be maintained
 Requirements DB - choice factors
51

 The statement of requirements

 If there is a need to store more than just simple text, a
database with multimedia capabilities may have to be used.
 The number of requirements
 Larger systems usually need a database which is designed
to manage a very large volume of data running on a
specialised database server.
 Teamwork, team distribution and computer support
 If the requirements are developed by a distributed team of
people, perhaps from different organisations, you need a
database which provides for remote, multi-site access.
DOORS(Dynamic Object Oriented Requirement
System)
 Good for management, controlled access, links, analysis,
reports
 Good query and navigation facilities
 Support for change and version management
 But: hard (and costly) to configure, manage, and use
 link between the database and the requirements document
must be maintained (final requirements document must be
generated)
 Ideally: Target the benefits of both
 E.g.,DOORS and RequisitePro offer integrations with Word
(import/export) as well as document-oriented views (for the
“look and feel”…)
52
TWiki

 A generic Wiki tool (TWiki.org)

 Promotes collaboration
 Database-driven
 Access and version control
 Forms and queries
 State-based workflows (processes)
 Text and graphics
 Lightweight, extensible (plug-in architecture)
 Example of Forms and Queries
 Requirements:
http://cserg0.site.uottawa.ca/twiki/bin/view/ProjetSEG/UCMNavRequirements
 Library: http://cserg0.site.uottawa.ca/twiki/bin/view/UCM/UCMVirtualLibrary
 Use Cases: http://cserg0.site.uottawa.ca/seg/bin/view/CSI4900/UseCases
53
Cont…
Benefits of using Requirement
Management tools

 Manage versions and changes

 Store requirement attributes
 Facilitate impact analysis
 Track requirements status
 Control access
 Reuse requirements
Thank You!