Requirements Management Process in Software Engineering

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.

Requirements management can be defined as a process of eliciting, documenting, organizing, and controlling changes to the requirements. Generally, the process of requirements management begins as soon as the requirements document is available, but ‘planning’ for managing the changing requirements should start during the requirements elicitation process.

The essential activities performed in requirements management are listed below.

1. Recognizing the need for change in the requirements
2. Establishing a relationship amongst stakeholders and involving them in the requirements engineering process
3. 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. Other advantages associated with the requirements management are listed below.

1. 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.
2. Improved software quality: This ensures that the software performs according to the requirements to enhance software quality. This can be achieved when the developers and testers have a precise understanding of what to develop and test.
3. Reduced project costs and delays: This minimizes errors early in the development cycle as it is expensive to ‘fix’ errors at the later stages of the development cycle. As a result, the project costs also reduce.
4. Improved team communication: This facilitates early involvement of users to ensure that their needs are achieved.
5. Easing compliance with standards and regulations: This ensures that standards involved with software compliance and process improvement have a thorough understanding of requirements management. For example, CMM addresses requirements management as one of the first steps to improve software quality.
6. All the user requirements are specified in the software requirements specification. The project manager as part of requirements management tracks the requirements 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.

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

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

Trace ability 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. Mainly, five types of traceability tables are maintained. These are listed in Table.

In a traceability matrix, each requirement is entered in a row and column of the matrix. The dependencies between different requirements are represented in the cell at a row and column intersection. ‘U’ in the row and column intersection indicates the dependencies of the requirements in the row on the column and ‘R’ in the row and column intersection indicates the existence of some other weaker relationship between the requirements.

                                      Table Types of Traceability Tables

Note that a traceability matrix is useful when less number of requirements are to be managed. However, traceability matrices are expensive to maintain when a large system with large requirements is to be developed. This is because large requirements are not easy to manage. Due to this, the traceability information of large system is stored in the ‘requirements database’ where each requirement is explicitly linked to related requirements. This helps to assess how a change in one requirement affects the different aspects of the system to be developed.

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. Note that many activities of requirements management are similar to software configuration management activities.

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

1. 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. The outcome of the analysis is provided to the ‘change requester’ and a more specific requirements change proposal is then made.
2. 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.
3. 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. By doing this, individual sections can be changed and replaced without affecting other parts of the document.