Requirement management

Introduction

Once a system has been deployed, new requirements inevitably emerge. It is difficult for the users to anticipate the effect of these new requirements if a new system is developed for these requirements on the organization. Thus, to understand and control changes to system requirements, requirements management is performed.

Enduring and volatile requirements

Requirements classes

Enduring requirements: Stable requirements which are derived from the core activity of the organization and which relate directly to the domain of the system.
Volatile requirements: These requirements are likely to change during the system development or after the system has been put into operation.

Mutable requirement: Requirements which change because of changes to the environment in which the organization is operating.
Emergent requirement: Requirements which emerge as the customer’s understanding of the system develops during the system development.
Consequential requirement: Requirements which result from the introduction of the computer system which may change the organization’s process and open up for new system requirements.
Compatibility requirements: Requirements which depend on the particular systems.

Requirements management can be defined as a process of eliciting, documenting, organizing business processes within an organization, and controlling changes to the requirements.

Activities in requirements management

Generally, the process of requirements management begins as soon as the requirements document is available, but planning for managing the changing activities performed in requirements management are:

Establishing a relationship amongst stakeholders and involving them in the requirements.
Recognizing the need for change in the requirements.
Identifying and tracking requirements attributes.

Requirements management enables the development team to identify, control, and track requirements and changes that occur as the software development process progresses.

Advantages

Better control of complex projects: This provides the development team with a clear understanding of what, when and why the software is to be delivered. The resources are allocated according to user-driven priorities and relative implementation effort.
Improves software quality: This ensures that the software performs according to enhance software quality. This can be achieved when the developers and testers have a precise understanding of what to develop and test.
Reduced project costs and delays: This minimizes errors early in the development. As a result, the project costs also reduce.
Improved team communications: This facilitates early involvement of users to ensure that their needs are achieved.
Easing compliance with standards and regulations: This ensures that standards involved with software compliance and process improvement have a thorough understanding of requirement management. For example, CMM addresses requirements management as all the user requirements are specified in the software requirement specification. The project manager, as part of requirements management, tracks the requirement for the current project and those which are planned for the next release.

Requirements management process

Requirements management starts with planning, which establishes the level of requirements management needed. After planning, each requirement is assigned a unique identifier so that it can be crosschecked by other requirements. Once requirements are identified, requirements tracing is performed.

Requirement tracing

Requirement tracing is a medium to trace requirements from the start of development process till the software is delivered to the user. The objective of requirement tracing is to ensure that all the requirements are well understood and included in test plans and test cases.

Various advantages of requirement tracing are:

It verifies whether user requirements are implemented and adequately tested or not.
It enables user understanding of impact of changing requirements.

Traceability techniques facilitate the impact of analysis on changes of the project, which is under development. Traceability information is stored in a traceability matrix, which relates requirements to stakeholders or design module. The traceability matrix refers to a table that correlates high-level requirements with the detailed requirements of the product.

Traceability

“Traceability” refers to the ability to track and link a requirement throughout its entire lifecycle, from its initial definition to its implementation and testing.

Features traceability: Indicates how requirements relate to important features specified by the user.
Source traceability: Identifies the source of each requirement by linking the requirements to the stakeholders who proposed them. When a change is proposed, information from this table can be used to find and consult the stakeholders.
Requirement traceability: Indicates how dependent requirements in the SRS are related to one another. Information from this table can be used to evaluate the number of requirements that will be affected due to the proposed changes(s).
Design traceability: Links the requirements to the design modules where these requirements are implemented. Information from this table can be used to evaluate the impact of proposed requirements changes on the software design and implementation.
Interface traceability: Indicates how requirements are related to internal interface and external interface of a system.

Requirements change management

Requirements change management is used when there is a request or proposal for a change in the requirements. The advantage of this process is that the changes to the proposals are managed consistently and in a controlled manner.

Stages of requirements change management

An efficient requirements change management process undergoes a number of stages for changes to the requirement. These stages are:

Problem analysis and change specification: The entire process begins with identification of problems to the requirements. The problem or proposal is analyzed to verify whether the change is valid or not. The outcome of the analysis is provided to the ‘change requester’ and a more specific requirements change proposal is then made.
Change analysis and costing: The effect of a change requested on the requirement is assessed according to traceability information. The cost for this can be estimated on the basis of modification made to the design and implementation. After the analysis is over, a decision is made whether changes are to be made or not.
Change implementation: Finally, the changes are made to the requirements document, system design, and implementation. The requirements document is organized in such a manner so that changes to it can be made without extensive rewriting. Minimizing the external references and making document sections modular achieves changeability in the document.