Requirements Inspection Process

Contents

• Overview
• Objectives
• Entry Conditions
• Exit Conditions
• Recommendations
• Tasks

Overview

An essential ingredient in producing quality software products is producing the product the customer wants and the users need. Validation is an activity that continues to ask developers that question, "are you building the right product?". It is clearly possible to construct an artifact that meets a set of requirements. It is possible to do that within a fixed time period and budget. It is also possible that the product developed is wrong because development was done based on a wrong, or misunderstood, set of requirements.

The intent of a requirements inspection is to determine if a given set of requirements are sufficiently stable, acceptable, and understood to support system/software development. A major factor in this effort is 1) insuring the individual developing the requirements has a firm grasp what is expected, 2) potential designers can comprehend what is stated in the document, and 3) potential designers find the requirements as stated technically feasible. Eventually a requirements document must have the litmus test of customer review and a acceptance, but for now a first round of review involves just the project staff.

Objectives

The objectives of the Requirements Inspection activity is:

• To determine whether the requirements are:
  • consistent,
  • understood by the requirements author,
  • considered complete and stable,
  • consider feasible by potential designers,
  • understandable by potential designers.
• To identify errors, misunderstandings, clerical errors, and omissions in the requirements document.

Entry Conditions

The Requirements Inspection can begin when:

• A requirements document (SRS) is available for review.
• All inspection participants have been identified to the SRS author.
• A date and time for the inspection has been specified.

Exit Conditions

The Requirements Inspection is complete when:

• The set of requirements has been exhaustively assessed for understandability and feasibility.
• The set of requirements is considerable feasible to initiate design.
• A revised SRD that addresses the defects is available.

Recommendations

Requirements Selection and Risk Analysis

Requirements are nominated by requirments manager or the project leader to be taken to design, when it is felt that they are stable and well-defined enough to do so.

The purpose of risk analysis is to determine the risks involved in taking requirements through the design phase. If requirements are subject to frequent revisions, it may not be prudent to commence design activities. There are also risks involved with not moving requirements through design; stable requirements not being put to use represent wasted time and opportunities lost. The people who should participate in this process are:

• Designers, who should be present to determine whether they understand the requirements as expressed in the requirements document and whether they consider it technically feasible and appropriate to commence design for the requirements.
• Requirements authors, who have the most intimate understanding of the document, and who may act as interpreters to resolve ambiguities.
• The project manager, who has the overall goals and schedule of the project in mind.

Tasks

Tasks that should be completed as part of the Requirements Inspection activity are:

1. Participants are trained in the inspection process.

2. Participants review the defined roles for an SRD inspection.

3. The moderator distributes the SRS to the inspection participants.

4. The moderator selects a participants to serve as recorder.

5. The requirements author discusses the SRS section by section, noting in his/her words the nature of the problems to be solved and the requirements that have been elaborated.

6. The reviewers ask questions, and ask for clarification regarding remarks of the author and the content of the SRS, including possible conflicting opinions.

7. The recorder keeps a log of all defects found during the session.

8. The recorder keeps a log of all clarifications requested by the reviewers.

9. The recorder submits the defect and clarification log to the author with a copy to SQA and the project leader.

10. The author revises the SRS by addressing the points raised during the inspection. This my require returning to requirements elicitation to clarify certain points.

11. The author notifies the participants when the revised SRS is available.

12. SCM posts the change history of the SRS.