Chapter Seven

Requirements Management
1 Introduction
”There is nothing permanent except Change” Heraclitus
Requirements Management is the management of all requirements received by or generated by the
project or work group, including both technical and non-technical requirements levied on the project
or work group by the organization. Technical requirements are defined as ”properties of product or
service to be acquired or developed” and non-technical requirements are defined as ”requirements
affecting product and service acquisition or development that are not properties of the product or
service”.
Requirements management is the process of documenting, analyzing, tracing, prioritizing, and
agreeing on requirements and then controlling and communicating to relevant stakeholders. It is a
continuous process throughout the project. This definition also states that the process of requirements
management begins with the starting of the projects and completes with the ending of the project.

2 Why Requirements Management?

Requirements changes due to interpretation, scope creep, or other random factors should be sup-
pressed to the greatest extent practical. Requirements changes that result from emerging insight
must be embraced and managed. High levels of requirements volatility suggest that the underlying
problem being solved by the system or software is not yet fully understood. In that case, moving
further along the design cycle could well be the root cause of the problem, not the instability of
requirements themselves.
Requirements changes and new requirements are the major reason that projects get out of control.
The responsibility in this area is to familiarize the project team, the customer, and the users with
industry experience and to gain commitment to controlling changes and new requirements. For
example, consider the approach of having subsequent versions and releases of work products, rather
than pretending that the project can accommodate changes while it is in development.
User requirements are original and first in the chain. Software requirements are not original. They
are derived from user requirements. When user requirements change, the software requirements also
change. Therefore, we need to manage user requirements. If we can minimize changes to user
requirements, the changes to software requirements would automatically be minimized.
The requirements for large software systems are always changing. One reason for the frequent
changes is that these systems are often developed to address ”wicked” problems problems that cannot
be completely defined. Because the problem cannot be fully defined, the software requirements are
bound to be incomplete. During the software development process, the stakeholders’ understanding
of the problem is constantly changing.

3 Requirements Evolution
The system requirements must then evolve to reflect this changed problem understanding.
Software Requirement Engineering, Ch-7 March 2, 2019

Once a system has been installed and is regularly used, new requirements inevitably emerge. This is
partly a consequence of errors and omissions in the original requirements that have to be corrected.
However, most changes to system requirements arise because of changes to the business environment
of the system:

• The business and technical environment of the system always changes after installation. New
hardware may be introduced and existing hardware updated. It may be necessary to interface
the system with other systems. Business priorities may change (with consequent changes in the
system support required), and new legislation and regulations may be introduced that require
system compliance.

• The people who pay for a system and the users of that system are rarely the same people.
System customers impose requirements because of organizational and budgetary constraints.
These may conflict with end-user requirements, and, after delivery, new features may have to
be added for user support if the system is to meet its goals.

• Large systems usually have a diverse stakeholder community, with stakeholders having different
requirements. Their priorities may be conflicting or contradictory. The final system require-
ments are inevitably a compromise, and some stakeholders have to be given priority. With
experience, it is often discovered that the balance of support given to different stakeholders has
to be changed and the requirements re-prioritized.

As requirements are evolving, you need to keep track of individual requirements and maintain links
between dependent requirements so that you can assess the impact of requirements changes. You
therefore need a formal process for making change proposals and linking these to system requirements.
This process of ”requirements management” should start as soon as a draft version of the requirements
document is available.

3.1 Requirements Management Planning

The quote attributed to Abraham Lincoln states, ”If I am given six hours to fell a tree, I will spend the
first four on sharpening the axe”, emphasizes the importance of planning. Another quote attributed
to Peter Drucker states ”Nobody plans to fail; but they just fail to plan”. I don’t think that I can do
any better than these two quotes to explain the importance of planning. Planning may not prevent
failure altogether but it certainly increases the chances of success and reduces the risk of failure in
Software Requirement Engineering, Ch-7 March 2, 2019

any human endeavor. It helps in anticipating the required resources reliably and in locating the risky
areas in our endeavor so that we have adequate time to prepare and mitigate them successfully. But
before we move further on this topic, let us define planning and understand its import.
Requirements management planning is concerned with establishing how a set of evolving require-
ments will be managed. During the planning stage, you have to decide on a number of issues:

1. Requirements identification: Each requirement must be uniquely identified so that it can

be cross-referenced with other requirements and used in traceability assessments.

2. A change management process: This is the set of activities that assess the impact and
cost of changes. I discuss this process in more detail in the following section.

3. Traceability policies: These policies define the relationships between each requirement and
between the requirements and the system design that should be recorded. The traceability
policy should also define how these records should be maintained.

4. Tool support Requirements: management involves the processing of large amounts of in-
formation about the requirements. Tools that may be used range from specialist requirements
management systems to shared spreadsheets and simple database systems.

4 Requirements Change Management

Change Management is a critical activity of requirements management. Requirements change man-
agement begins only upon freezing of the requirements, that is, the requirements documents are
approved and are subjected to the project’s configuration management. It will continue through the
project execution until the project deliverables are handed over to the customer.
Requirements change management should be applied to all proposed changes to a system’s re-
quirements after the requirements document has been approved. Change management is essential
because you need to decide if the benefits of implementing new requirements are justified by the
costs of implementation. The advantage of using a formal process for change management is that all
change proposals are treated consistently and changes to the requirements document are made in a
controlled way.

4.1 What is a change?

A change is basically a requirement that is specified/modified after the requirements are frozen. The
new requirement may be a modified version of an already specified requirement. Or it could be a
new requirement altogether.

4.2 Why do requirements change?

Requirements change midway through the course of project execution for a variety of reasons. Core
functionality requirements may change due to:

1. The business environment in which the organization operates undergoes a change to which the
organization needs to respond. This can cause the software requirements to change.

2. The management of the organization may effect a reorganization of its operations and this may
necessitate a change in the core functionality requirements.
Software Requirement Engineering, Ch-7 March 2, 2019

3. Some of the end users may have forgotten some requirements or remembered a new requirement
after freezing the requirements. This would necessitate a change of requirements.

4. A new statute or a court judgment, or a government diktat can cause changes after the re-
quirements are frozen.

5. Process improvement activities may have modified some of the existing business practices and
these can cause the requirements to change

6. Data analysis of completed projects can reveal some anomalies which could result in changing
the requirements

Ancillary functionality requirements also can change for the following reasons:

1. During design phase or construction phase, it may be uncovered that implementation of some
requirements as frozen may not be possible due either to technical reasons or cost considerations.
This may necessitate a change of requirements.

2. Some of the system software may release patches or service packs affecting the software design
causing the requirements to change.

3. A new threat or a security hole may be discovered in the system software necessitating a revision
of the requirements.

4. Someone may uncover a better way to achieve the functionality causing the requirements to
change.

Whatever the reason may be and whatever the requirement may be, some changes become necessary
during the project execution after the requirements are frozen. Therefore, we need to equip ourselves
with the means to handle changes in an orderly manner ensuring that the smooth work flow continues
without major interruption.

4.3 Origination of Changes

Changes can originate from various stakeholders including:

1. Customers: Customers’ representatives raise change requests mainly to change core function-
ality requirements. Occasionally they can also raise requests to modify ancillary functionality
when the system software proposed by them has undergone changes. The changes stem mainly
from changes in a business scenario, or new/modified statutes, and reorganization of key de-
partments etc. The world is dynamic and anything could change to effect the frozen core
functionality requirements and customers could raise change requests.

2. End users: End users raise change requests when a frozen requirement needs to be changed
because they either forgot a key aspect of a requirement or they forgot a requirement totally.
They may add a field or modify a field; they may change the screen layout or report layout;
they may need an additional report; and modify the steps of a process and so on. Normally
change requests raised by end users would affect core functionality requirements.

3. Project team: Project team members can raise a change request occasionally when they are
not able to implement a requirement in its entirety or need a design modification. They may
not be able to pack all the controls on the same screen or all the fields on the same report
Software Requirement Engineering, Ch-7 March 2, 2019

and this would cause them to raise a change request. Sometimes, they may be able to combine
multiple screens into one screen layout. Normally project team’s change requests are concerned
with implementing the design and issues thereof.

4. Testing team: It is rare that a testing team raises a change request as it is focused more on
uncovering defects than on finding opportunities for improvement. But testing teams may find
opportunities for improvement (especially about system response times uncovered on perfor-
mance testing, system stress uncovered in stress testing or concurrency control aspects uncov-
ered in concurrent testing) while carrying out testing and may raise change requests albeit in
practical terms these changes often are initially confused with problem reports. Testing teams
do find some opportunities for improvement and raise change requests to resolve those changes.

5. Organizational Standards group: Organizational Standards groups may change an existing

standard or bring out a new one, which may impact projects in progress. In such cases they may
raise a change request to retrofit the standard into the project deliverables. Unless the change
addresses a critical issue, the Organizational Standards group generally identifies a migration
path for the change.

4.4 Communication of Changes

How are changes communicated to the project team? Changes can be communicated to the project
team either by telephonic information, in person, through an email, through a software tool or more
formal methods. Agile methods mandate colocation of the customer with the project team and
hence see no need for formal or written methods for communicating change. In the agile projects the
communication would be in person. In other projects, all the above methods would be used. The
formal mechanism used for handling change management is a CR (Change Request). It is possible to
communicate changes without written documents but, formal methods have advantages. They are:

1. 1. Formal methods help in keeping a record of the changes requested for analysis later at the
end of the project.

2. Formal methods facilitate tracking each change to its resolution and that no requested change
is forgotten.

3. Formal methods ensure that all required information is communicated along with the requested
change.

4. Formal methods enable analysis of changes and effect improvements in the process to minimize
changes as well as to improve the process of defining project requirements more comprehen-
sively.

4.5 Change Request Resolution

The first response to a CR is to record it in a Change Request Register (CRR) so that it can be
tracked to resolution. A CRR could be as simple as an Excel Worksheet or a software tool like
PMPal that facilitates the functionality of a CRR. The CRR is the main tool for tracking all CRs
to resolution. By recording the CR in the CRR will ensure that no CR is overlooked/forgotten. It
would also enable tracking every CR to resolution. It would further enable us to analyze the CRs at
the end of the project. The resolution of a change request can be:

1. Accept the CR and implement it immediately

Software Requirement Engineering, Ch-7 March 2, 2019

2. Accept the CR but implement it later along with all other CRs

3. Reject the CR

After a change request has been logged in the register, the CR is analyzed by a PM or a designated
person. In large projects, there would be a CCB (Change/Configuration Control Board) that would
analyze the CR and accord approval for implementation or reject it. In either case, the analysis
would determine:

1. Whether the information contained in the CR is comprehensive with all pertinent details and
facilitates implementation of CR.

2. Whether implementation of CR would be feasible both in technical as well as financial consid-

erations. When the CR is raised by internal sources such as the project team or testing team,
the analysis would also determine if the implementation is desirable from a user viewpoint in
addition to its feasibility.

3. The amount of effort, cost and calendar time it would consume to implement the CR.

4. The impact of the CR on the overall project, if it is accepted (especially in terms of effort,
schedule and cost) or rejected (fulfillment of functionality).

Once the analysis is completed, the Impact Analysis would be submitted to CCB or the PM who
would approve or reject the CR. In the case of rejection, the decision along with reasons for rejection
would be communicated to the originator of the CR and the CR is closed in the CRR. If the CR is
accepted, the PM or the CCB would decide on the strategy for implementation of the CR. Once a CR
is approved for implementation, it would be implemented in accordance with the CR implementation
strategy decided and recorded in the Software Configuration Management Plan (SCMP). Strategies
can include:

1. Implementing CRs immediately on receipt and approval

2. Consolidate all CRs and retrofit them at the end of the project or any another appropriate
point in the development process

3. Situational implementation:

• If the component which is affected by the CR is yet to be constructed or is being con-

structed, then implement the CR when the impacted component is under construction.
• If the construction of the component, which is affected by the CR, is completed, keep the
CR pending and retrofit it into the component at the end or at a convenient time.
• If the construction of the component is completed but not implementing the current CR
would render the component a bottleneck for other components, it would be implemented
immediately.

Once the analysis and strategy for CR implementation are decided, the CR would be implemented
in line with the analysis and implementation strategy decided by the CCB or the PM.
Software Requirement Engineering, Ch-7 March 2, 2019

5 Requirements Change Management Process

There are three principal stages to a change management process:

1. Problem analysis and change specification: The process starts with an identified require-
ments problem or, sometimes, with a specific change proposal. During this stage, the problem
or the change proposal is analyzed to check that it is valid. This analysis is fed back to the
change request or who may respond with a more specific requirements change proposal, or
decide to withdraw the request.

2. Change analysis and costing: The effect of the proposed change is assessed using traceability
information and general knowledge of the system requirements. The cost of making the change
is estimated in terms of modifications to the requirements document and, if appropriate, to the
system design and implementation. Once this analysis is completed, a decision is made as to
whether or not to proceed with the requirements change.

3. Change implementation: The requirements document and, where necessary, the system
design and implementation, are modified. You should organize the requirements document
so that you can make changes to it without extensive rewriting or reorganization. As with
programs, changeability in documents is achieved by minimizing external references and making
the document sections as modular as possible. Thus, individual sections can be changed and
replaced without affecting other parts of the document.

If a new requirement has to be urgently implemented, there is always a temptation to change

the system and then retrospectively modify the requirements document. This almost inevitably
leads to the requirements specification and the system implementation getting out of step. Once
system changes have been made, it is easy to forget to include these changes in the requirements
document. In some circumstances, emergency changes to a system have to be made. In those cases,
it is important that you update the requirements document as soon as possible in order to include
the revised requirements.

6 Requirements Change Management Tools

Requirements management needs automated support, and the software tools for this should be chosen
during the planning phase. You need tool support for:

1. Requirements storage The requirements should be maintained in a secure, managed data store
that is accessible to everyone involved in the requirements engineering process.

2. Change management The process of change management is simplified if active tool support is
available. Tools can keep track of suggested changes and responses to these suggestions.
Software Requirement Engineering, Ch-7 March 2, 2019

3. Traceability management As discussed above, tool support for traceability allows related re-
quirements to be discovered. Some tools are available which use natural language processing
techniques to help discover possible relationships between requirements.

For small systems, you do not need to use specialized requirements management tools. Requirements
management can be supported using shared web documents, spreadsheets, and databases. However,
for larger systems, more specialized tool support, using systems such as DOORS (IBM 2013), makes
it much easier to keep track of a large number of changing requirements.
Software Requirement Engineering, Ch-7 March 2, 2019

Course Objectives:
After completion of this course, you will have the ability:

• Discover and elicit requirements using variety of techniques

• Organize and prioritize requirements

• Apply analysis techniques and validate requirements

• Negotiate with stakeholders and agree on set of requirements

• specify and measure quality attributes

• Write requirement Specification documents