The requirements, documentation process. Isn’t just about writing and recording information. You also have to review the requirements. Anytime someone other than the author of a software requirements, document examines the product for problems. A peer review takes place. Reviewing requirements. Documents is a powerful technique for identifying ambiguous or unverifiable requirements. You can also detect bugs in the design. During the review process, before they’re developed, it costs five times more to fix a bug at the development stage than in the requirement stage.
There are both formal and informal types of reviews. The informal types include a peer desk check where you ask a colleague to look over your work product, a pass around where you invite several coworkers to look at the document at the same time and a walkthrough where you describe the document and ask for comments on it.
A formal peer review on the other hand follows a well defined process. A formal review produces a report that identifies the material, the reviewers in the review team’s judgment as to whether the product is acceptable. The review produces a summary of the defects found and the members of a formal review share responsibility for the quality of the review.
Digging deeper into the review process gets us to the inspection process. Any software work product can be inspected, including requirements and design documents, source code, test documentation, and project plans. Inspection is a well defined multi-stage process that involves a small team of trained participants who carefully examine a work product for defects and improvements. Participants in the inspection should represent four objectives. The author of the work product, the author of any predecessor work product or specification for the item being inspected. The people who are responsible for work products that interface with the item being inspected. And finally, the people who do work based on the item being inspected, such as a developer, a tester or a project manager, we recommend limiting the team to no more than six participants.
There are four major roles in the inspection process. The author creates or maintains the work product being inspected. The moderator serves as the inspection leader, planning the inspection with the author, coordinating activities and running the inspection meetings. The reader paraphrases the SRS one requirement at a time with the other participants then pointing out potential defects and issues by stating the requirements in her own words, the reader provides an interpretation that might differ from that held by the other inspectors. The final role is the recorder who uses an issue tracking software to document the issue raised. And the defects found during inspection meetings.
The inspection happens in stages, starting with the planning phase, when the author and moderator plan the inspection together, deciding who should participate, what materials the inspectors will need to receive before the inspection meeting and how many meetings they’ll need to cover the material.
The next stage is the overview meeting in which the author describes the background of the material that will be inspected.
The preparation stage happens prior to the inspection meeting and it involves each inspector examining the product to identify possible defects and issues that should be raised up to 75% of defects are found during this phase. So keep a sharp eye.
Then it’s time for the inspection meeting. During this meeting, the reader leads the other inspectors through the SRS, describing one requirement at a time in his own words, the inspectors bring a possible defects and the other issues while the recorder captures them on a form that becomes the action item list for the author. The purpose of the meeting is to identify as many major defects in the document as possible. The meeting shouldn’t last more than two hours, but if you need more time, schedule another meeting at the end of the meeting, the team will decide whether to accept the requirements document as is accept the minor revisions or indicate that major revisions are needed.
The rework stage is where the author spends time reworking the requirements after the inspection meeting and follow up is the final step in which the moderator works with the author to ensure that all open issues have been resolved and errors have been corrected. The entire process ends when all of the issues raised during the inspection have been addressed or any changes in the document have been correctly made, or when the document has been checked into the project’s configuration management system
To help inspectors look for typical kinds of errors in the products that they inspect, develop a defect checklist for each type of requirements, document. This draws the inspector’s attention to historically frequent problems.
There are a lot of challenges associated with requirements review, and fortunately our program will help make the process much easier. There are a few tips we’d like to pass along to you though, to help you with other aspects of the process. For instance, we know that large requirements documents like a several hundred page SRS document can be seriously daunting. So to avoid overwhelming the inspection team, try performing incremental reviews throughout the requirements development, identify high risk areas that need a careful look and use informal reviews for less risky material, definitely consider using several small teams to inspect different portions of the material. Also establish several small teams to inspect the SRS in parallel and combine their defect lists.
And even if you have a long list of potential participants for requirements inspections, try not to let your inspection team get too large because that complicates things like scheduling meetings and reaching agreement on issues. Make certain that every participant is there to find defects, not to be educated or to protect a political position. Also, we recommend that you decline the participation of people who duplicate a perspective that’s already covered.