Requirements change management

Requirements change management requirements document and, if appropriate, to the system design and implementation.
Once this analysis is completed, a decision is made whether to proceed
with the requirements change.
3. Change implementation The requirements document and, where necessary, the
system design and implementation are modified. You should organise the
requirements document so that you can make changes to it without extensive
rewriting or reorganisation. As with programs, changeability in documents is
achieved by minimising 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. should be applied to all proposed
changes to the requirements. The advantage of using a formal process for change
management is that all change proposals are treated consistently and that changes
to the requirements document are made in a controlled way. There are three principal
stages to a change management process:
1. Problem analysis and change specification Th\~ process starts with an identified
lequirements problem or, sometimes, with a specific change proposal. During
this stage, the problem or the change proposal is analysed to check that it is
valid. The results of the analysis are fed back to the change requestor, and sometimes
a more specific requirements change proposal is then made.
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. This almost inevitably leads to the requirements specification
and the system implementation getting out of step. Once system changes have
been made, requirements document changes may be forgotten or made in a way that
is not consistent with the system changes.
Iterative development processes, such as extreme programming, have been
designed to cope with requirements that change during the development process.
In these processes, when a user proposes a requirements change, this does not go
through a formal change management process. Rather, the user has to prioritise that
change and, if it is high priority, decide what system features that were planned for
the next iteration should be dropped.

KEY POINTS
1111II·
The requirements engineering process includes a feasibility study, requirements elicitation
and analysis, requirements specification, requirements validation and requirements
management.
Requirements elicitation and analysis is an iterative process that can be represented as a
spiral of activities - requirements discovery, requirements classification and organisation,
requirements negotiation and requirements documentation.
Different stakeholders in the system have different requirements. All complex systems
should therefore be analysed from a number of viewpoints. Viewpoints can be people or
other systems that interact with the system being specified, stakeholders who are affected
by the system, or domain viewpoints that constrain the requirements.
Social and organisational factors have a strong influence on system requirements and may
determine whether the software is actually used.
Requirements validation is the process of checking the requirements for validity,
consistency, completeness, realism and verifiability. Requirements reviews and prototyping
are the principal techniques used for requirements validation.
Business, organisational and technical changes inevitably lead to changes to the
requirements for a software system. Requirements management is the process of managing
and controlling these changes.
The requirements management process includes management planning, where policies and
procedures for requirements management are designed, and change management, where
you analyse proposed requirements changes and assess their impact.