Requirements Management

The software requirements provide a basis for creating the Software Requirements Specifications (SRS). The SRS will aid in estimating cost, planning team activities, performing tasks, and tracking the team's progress throughout the development activity. Requirements management is the process of managing these project resources that are called requirements. The process will help to establish a common understanding between the customer and the project team of stakeholder's requirements.

Goals

• To establish a process through which the project team will work with the customer to agree upon a set of software requirements.
• To produce a validated set of requirements.
• To document the requirements in a requirements specification document.
• To establish a procedure for maintaining the software requirements specifications that will ensure that they are kept consistent with the customer's expectations, as well as the project's software plans, products and activities.
• To establish a mechanism to manage changes to the agreed requirements.
• To identify and manage relationships between dependent requirements.
• To manage the dependencies between the requirements document and other documents produces during the project.

Commitment to Perform

This process involves specifying the requirements for the system or software, verifying that these requirements match the customer's expectations, ensuring that the software is developed in accordance with those requirements, and verifying that the software developed meets the requirements. Further, the software development process involves careful review and tracking of changes to the software requirements, as well as the incorporation of any changes into the software products, design documentation, test plans, project plans and other documents developed for the software project. These portions of the software process are the subject of this section.

Ability to Perform

The Requirements Manager will be responsible for managing the software requirements process and documentation. One member of the project team assumes the role of requirements manager. The Requirements Manager's responsibilities include:

• developing a plan for conducting requirements elicitation and analysis.
• working with the customer, and the rest of the team to develop the initial requirements specification.
• training the project team in understanding the requirements management process.
• documenting the requirements.
• working with SQA to initiate requirements review and inspections.
• resolving problems identified with requirements.
• working with SCM to incorporate approved changes into the documented requirements and other related documents (e.g. design document, test plan, etc.) once the SRS is under configuration control.
• ensuring that current requirements documentation is available to all team members, the project advisor, and the customer.
• ensuring that the requirements document is properly used throughout the develop ment process.
• ensuring requirements traceability.

In general, the requirements manager is responsible for the requirements engineering process for the project. This includes the initial determination of the requirements, and the ongoing management of the requirements once developed and documented.

Documentation

All of the software requirements will be stored in a Software Requirements Specification (SRS) document. If necessary, the SRS can include references to other documents, prototypes or other files that also serve to define the requirements for the project.

System Overview

Each project group will have to take many factors into account while establishing and elaborating the requirements. As much as possible, these considerations need to be documented so that team members understand the thought processes that led to the established set of requirements.

Verification/Validation

Once developed, interaction scenarios can be used as test cases to verify that the Technical Requirements meet the Requirements Considerations and that the system performs according to Functional Requirements. These interaction scenarios do not specify a complete set of test cases to be run on the software. That level of testing should be performed during the system test phase of the software development cycle. Instead, they specify a set of test cases that will demonstrate that the system can perform each of the functions that the customer requires of it.

Activities Performed

Establish Requirements

An SOW received by the customer will serve as an initial proposal to start the project process. In many instances the first SOW is vague and lacks sufficient detail for a comprehensive set of requirements to be compiled. The requirements received from the customer must be elaborated into a set of detailed requirements that can be used for software development.

To elaborate the requirements, the project team should begin by writing the Problem Overview and System Overview sections of the SRS. Once an initial draft has been made of these sections, the results should be reviewed with the customer to ensure they adequately reflect the customer's expectation of the system. In particular, the customer should be asked to validate that the System Overview accurately describes the requested system, and that the System Overview correctly identify the requirements issues. The project group revise the Problem Overview and System Overview until the customer and the project group both agree that they are complete and adequate.

You can refer to the requirements engineering process for additional guidance in this activity.

The Problem Overview and System Overview are then used to design the external interfaces of the system as described for the Technical Requirements section of the SRS. When complete, this section should completely specify the external interfaces of the system. In particular:

• The defined interfaces provide for each of the tasks that the system should perform
• The defined interfaces take into account each of the issues identified in the Require ments Considerations
• The defined interfaces are implementable

The Requirements Manager should ensure that defined external interfaces provide for each of the tasks the system should perform and that all System Overview are taken into account.

Before presenting these Technical Requirements to the customer, the project team should develop interaction scenarios for the Acceptance Criteria/Interaction Scenarios section of the SRS. In developing these scenarios attention should be paid to ensuring that the user can easily perform each of the required functions for the system. The exercise of developing these scenarios should be used to verify that the proposed Technical Requirements will meet the expectations of the customer and the System Overview. Once these scenarios have been developed, the Technical Requirements section should be presented to the customer to validate that the proposed system will meet their requirements.

Application

Once the SRS has been completed, it must be used as the basis for all planning and development. In particular, the SRS must be used as the basis for:

• The Long-Term Project Plan
• Each Short-Term Project Plan
• All software design
• All software development
• All software testing

Requirements Change

• A defined requirement cannot be met
• The customer requests a requirement change

The Project Leader must be notified whenever any member of the project team identifies a technical reason or constraint that the software requirements cannot be met. The Project Leader will verify the situation and will work with the team and customer to develop a recommendation for how the requirements should be changed. If the situation can be resolved without changing the requirements, no change is made. If a change is required, the Requirements Manager will initiate a change request on the SRS to include the recommended change. The procedures in Software Configuration Management will be used to review, negotiate, revise, approve and incorporate the change.

If the customer requests a change to the software requirements, the Requirements Manager will initiate a change request on the SRS to include the requested change. Again, the procedures in Software Configuration Management to review, negotiate, revise and incorporate the change.

Measurement and Analysis

There should be an initial review once the SRS is established to verify that the SRS is complete and ready to be baselined. The review should objectively evaluate the require ments so that the group reviewing can determine whether the SRS is complete. Once agree upon, the SRS should be presented to the Customer for further review. If the Customer is satisfied, then a meeting with the Design group will take place to discuss any design issues. Any necessary changes should be made and reported to the Customer to establish a final agreement.

Verifying Implementation

The Project Leader must review the procedures used and activities performed related to the creation and maintenance of the Software Requirements Specification. This review will be an integral part of the software process activities reviewed as described in Project Tracking and Oversight.

The Requirements Manager should make sure that the Project Leader is aware of any changes to the SRS that have been requested, and is kept current on the status of any outstanding change requests.

The Requirements Manager coordinates with the Configuration Management to insure the requirements specification is maintained and that the requirements change process is properly documented and controlled.

The Software Quality Assurance group will audit the activities and work products (e.g., Software Requirements Specification documents, applicable inter-group and customer correspondence, etc.) on a defined basis. At a minimum, the Software Quality Assurance group will verify that:

• The software requirements are reviewed by the customer, the project team, and the project advisor. Inconsistencies or other problems are detected and resolved before being incorporated into the SRS.
• Changes to the SRS are reviewed by the Project Leader, and negotiated with the customer before being integrated into the SRS.
• All software plans, work products (e.g., source code, internal or product documenta tion) and scheduled activities are appropriately revised when the software requirements change.