Development Case: Review Procedures
Topics
Background 
The review levels define the review procedures to be applied during the production of an artifact. The review procedure to follow is indicated in the "Review Details" columns of the individual discipline artifact and report tables (see Development Case: Discipline Configuration for details of the tables used) defined for each of the Disciplines.
The review levels below define the standard review procedures that can be adopted for the artifacts used by the project.
[The names and details of the review levels can be extended/customized to reflect the individual culture of your organization. This could include supplying review documentation templates and filing procedures.]
In some cases an artifact requires a more individual, complex or sophisticated review procedure. In these cases the artifact's review procedures is defined as part of the applicable discipline configuration's additional review procedures section.
The review levels used here are the ones recommended by the Rational Unified Process. See the RUP Guidelines: Review Levels for further details and examples.
[Note: although the standard review levels are used here it is worth including a full definition of the review levels and their associated review procedures as part of the development case itself (rather than just referencing the RUP Guidelines) as the guidelines may change in later versions of the process.]
For details of the artifacts defined by the Rational Unified Process see RUP Overview: Artifacts.
Review Levels
|
Review Levels |
Explanation |
Comments |
| This artifact is part of the delivery at a specific milestone, and requires some form approval by the customer, the sponsor, or some other external stakeholder. | The review record is configuration
managed alongside the artifact.
For example, the Vision and the Business Case, are artifacts that normally have to be reviewed by stakeholders. |
|
| This artifact is formally reviewed internally in the project. | The review record is configuration managed alongside the artifact. Typically Sub-system specifications have to be reviewed and approved by several members of the project. | |
| This artifact is reviewed, but not formally approved. | The artifact is developed and maintained. It is normally not discarded after the project is complete. There is normally not any review record. Design classes and components are examples of artifacts that are typically not formally reviewed. This can still mean that someone, for example, a peer, will review it. | |
| This artifact does not need to be reviewed / approved. | The artifact is created and as work information. It is often a temporary artifact that is discarded after the project is complete. |
If an artifact requires a more complex or sophisticated review procedure (for example if the required review level varies across the project's lifecycle phases) then these review procedures are defined as part of the discipline configuration's additional review procedures.
[All artifacts that are classified as "Must Have" or "Should Have" must have their review procedures defined.]
