CHAPTER SIX

Software Requirement Management

College of Computing and Informatics

Department of Software Engineering
Requirement Management
• The process of managing change to the requirements
for a system
• Requirements need to be elicited, analyzed, negotiated,
specified, validated, tracked, and changed/updated
during the life of a project
• 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
Requirement Management 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.
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.
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.
Types of Requirements Management Tools
• Heavyweight Requirements Management Tools
– IBM Rational Requisite Pro
• Middleweight Requirement Management Tools
– Accompa Requirements Management Tool
• Lightweight Requirement Management Tools
– Spread Sheets
Requirements management tool
support
• 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.
Stable and volatile requirements
• 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
– 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.
Requirements identification
• 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
• 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
Storing requirements
• 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
• 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
• 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
• 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.
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 From
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.
Traceability
• Traceability information is information which helps you
assess the impact of requirements change. It links
related requirements and other system representations
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
Requirements analysis and negotiation
• Requirements analysis and negotiation are concerned
with the high-level statement of requirements elicited
from stakeholders.
• Requirements engineers and stake- holders negotiate
to agree on a definition of the system requirements.
• In some organizations, these requirements
will then be developed in more detail as a system
specification or model.
 Developing these models usually reveals further
contradictions and incompleteness in the requirements.
 then we must re-enter the elicitation, analysis and
negotiation phases to discuss requirements changes.
Cont…
• Complex systems have many stakeholders and they
are bound to have conflicting requirements.
• The negotiation process is intended to discuss the
conflicts in requirements and to find some
compromise which satisfies everyone involved.
• negotiations are never simply conducted using
logical, technical arguments.
quiz
1,explain requirement change management in detail

2,define software requirement management tool and list

types of software requirement management tool

3, discuss project change management process