Activity: Review Requirements
Purpose
|
|
| Role: Technical Reviewer | |
| Frequency: As required, generally multiple times in each iteration, starting with Inception. | |
| Steps | |
| More Information: | |
| Input Artifacts: | Resulting Artifacts: |
| Workflow Details: |
General Recommendations 
| Purpose | General recommendations for each review. |
The following guidelines are helpful when reviewing the results of Requirements:
- Always conduct reviews in a meeting format, although the meeting participants might prepare some reviews on their own.
- Continuously check what is produced to make sure the product quality is as high as possible. Checkpoints are provided for this purpose; refer to the checkpoints for each analysis activity. You can use them for informal review meetings or in daily work.
The following roles will participate in the review meetings - a person acting as a requirements reviewer has some essential knowledge of the business or technology domain and detailed knowledge of the applied facilitation and modeling techniques:
You should also consider the following roles for participation in review meetings, possibly at milestones such as the beginning or end of a Phase:
- Stakeholders - customers and end-users (Where possible)
- Change Control Manager (Where reviewing Change Requests)
- Test Designer (Optional)
- Software Architect (Optional, usually in Inception and Elaboration)
- Project Manager (Optional, usually at Phase Start)
It is important to find the right balance between including the desired review participants and keeping the review manageable and productive. Care should be taken to include only those participants who will contribute to achieving the objectives of the review. It is usually more productive to hold several focused review sessions with a smaller number of participants, than to hold one review involving many.
Recommended Review Meetings
| Purpose | To define the scope and the goals of the review. To define the approaches used for each specific scope/goal combination. |
Normally, you should divide the review into the following meetings:
- A review of change requests which impact the existing requirements set.
- A review of the entire use-case model.
- A review of the use cases (for each use case), along with their diagrams. If the system is large, break this review into several meetings, possibly one per Use-Case Package.
Even if you can review everything at the same meeting, you probably won't get approval of your conclusions the first time. Be prepared to carry out new reviews for each new version of the use-case model.
It is recommended that you arrange one review of the use-case model per iteration in the Inception and Elaboration phases, where you review the work in progress; this is initially done and signed off by the users prior to developing any of the use cases in detail, and is a very important milestone so that resources are not spent on developing incorrect use cases. Then, at the end of the Elaboration phase, you should arrange a detailed review of the use-case model. Remember that at the end of the Elaboration phase, you should have a use-case model, and possibly a domain model representing the glossary, that is 80% complete. You should also arrange one review of the use-case model per iteration in the Construction and Transition phases when the use-case model is refined. The review should concentrate on the part of the use case model being developed for the iteration.
Prepare Review Record and Document Defects
| Purpose | To document the review results. To ensure that identified defects are documented. |
Following each review meeting, the results of the meeting are documented in a Review Record. In addition, any defects are documented in accordance with the project's change management process.
Further Reading
See: [BIT03] Chapter11.
