Task: Review Requirements









var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=[{view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_gpYSoAILEdq-_NKqZM1EhA", "_26PQIAIMEdq-_NKqZM1EhA", "_ydt60dnmEdmO6L4XMImrsA", "{FEC5ED66-F467-4BD5-AB11-B300E101DB9B}"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_LWLSQDIEEdqwaNnSEheSAg", "_EzUssACVEdqrKcHWz1HoWw", "{0319C70C-35C9-4190-94F0-E7E5E9216CA0}", "{FEC5ED66-F467-4BD5-AB11-B300E101DB9B}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_f6_YwN7DEdmsEI4YDGX2ag", "_EzUssACVEdqrKcHWz1HoWw", "{0319C70C-35C9-4190-94F0-E7E5E9216CA0}", "{FEC5ED66-F467-4BD5-AB11-B300E101DB9B}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_kC0pcN7GEdm8G6yT7-Wdqw", "_ydt60dnmEdmO6L4XMImrsA", "{FEC5ED66-F467-4BD5-AB11-B300E101DB9B}"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', true, false, false);










Task: Review Requirements















This task describes how to review the requirements work products.


Disciplines: Requirements






Purpose



The purpose of this task is to formally verify that the results of the requirements tasks conform to the customer's view of the system.



Relationships



RolesPrimary Performer:



Technical Reviewer


Additional Performers:



InputsMandatory:



Business Case


Iteration Plan


Software Requirement



Optional:



Actor


Change Request


Glossary


Software Requirements Specification


Stakeholder Requests


Storyboard


Supplementary Specifications


Use Case


Use-Case Model


Use-Case Package


Vision






Outputs


Review Record






Process Usage


Requirements
 > 
Manage Changing Requirements
 > 
Review Requirements






Steps




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 quality is as high as possible. Checklists are provided for this purpose; refer to the checklist for each work product. You can use them for informal review meetings or in daily work. The reviews should concentrate on the requirements currently being developed. The following roles will participate in the review meetings: Requirements Reviewer: 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 Requirements Specifier System Analyst You should also consider the following roles for participation in review meetings, especially at key milestones: Stakeholders - customers and users (Where possible) Change Control Manager (Where reviewing Change Requests) Test Designer (Optional) Software Architect (Optional, usually early in the software lifecycle when the software architecture is under development) Project Manager (Optional, usually during the early parts of the the lifecycle, or when major changes are being reviewed) 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 for each of the key requirements work products.  If the system is large, break this review into several meetings, possibly one per key functional area. 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 requirements work products.



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.







More Information



Checklists


Glossary


Software Requirements Specification


Stakeholder Requests


Supplementary Specifications


Use-Case Model


Vision





Guidelines


Review Existing Requirements





Tool Mentors


Creating an Actor Report Using Rational SoDA


Creating a Use-Case Model Survey Using Rational SoDA


Creating a Use-Case Report Using Rational SoDA


Publishing Web-based Rational Rose Models Using Web Publisher








©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();