An important and effective method for verifying the output from a particular phase of a software life cycle. The phase output is scrutinized by a team of reviewers against the documentation (specification) available at the start of that phase and against general review criteria for the particular phase completed. These criteria may be defined by a particular method adopted, by the application domain of the proposed software, or by local conventions within a development organization (or any combination of these). The purpose of the review is to evaluate the emerging software in order to discover faults as early as possible.

Reviews can be conducted at most life-cycle phases and at different levels of detail, hence for example:

• user requirements specification review

• software requirements specification review

• system design review

• module design review

• module coding review

• module test procedure review

• integration test plan review

• acceptance test review

Informal reviews are usually conducted on the documented output of an individual by fellow (technical) members of the project team. For example, in a module design review the module author will guide the reviewers through the design, and differences between the module specification and the design will be recorded for later analysis and reworking of the design. Project verification and validation plans, together with the quality plan, will give guidance on procedure, and acceptance levels for unresolved differences.

Formal technical reviews may be conducted by project staff, by independent reviewers from other projects, or by independent third parties. They are usually planned as milestones in verification and validation activities.

Management reviews are usually more concerned with progress monitoring, risk assessment, plans, and scheduling.