Integrated Solutions

Design Review Process

 

 

 

 

Prepared By:

 

 

Lead Author, Integrated Solutions

Date

 

 

 

 

Approved By & Effective on Date of Signature Below:

 

 

Yufen Chang Yu, Integrated Solutions

Date

 

 

 

 

 

 

THIS DOCUMENT IS TO BE REGARDED AS THE OFFICial DESIGN REVIEW PROCESS within INTEGRATED SOLUTIONS. IT IS TO BE MAINTAINED UNDER CHANGE CONTROL BY the DOCUMENT CONTROL COORDINATOR.

 


 

CHANGE SHEET

TITLE: Design Review Process

 

 

DESCRIPTION OF CHANGE

 

ISSUE

DATE

SECTION

DESCRIPTION

 

1.0

 

3/13/97

 

 

 

All

 

 

 

 

·        Original Issue

1.1

10/3/97

6.3

·        Added conclusion

2.0

10/12/2000

All

·        Incorporated changes from previously approved designs as “Design Change” into this Review Process.

·        Added Appendix B: Design Change Worksheet

·        Indicated that a record of each review is maintained by the Project Manager.

 

3.0

 

 

 

 

 

 

7/10/2001

 

All

 

·        Added Design Template to incorporate indications of all reviews and changes (Appendix A)

·        Removed Appendix B

 

 

3.1

11/15/01

Appendix A

·        Revised Appendix A to include tracking section on attendees.

4.0

3/20/2006

ALL

·        Rewrote to ensure effectiveness of this process.

 


1.0     Introduction

 

This documentation provides the general guidance for employee in ISI to practice when involving in the software design review.

 

2.0     Design Review Process

 

At stages, hold formal documented design reviews, with key functions represented, and records maintained [1]. The designer will then revise the design document based on reviewer’s feedback and hold further reviews until accepted.

 

System Requirements Review (SRR). The purpose of the SRR is to review the system requirements specification document, to ensure the documented requirements reflect the current knowledge of the customer and market requirements, to identify requirements that may not be consistent with product development constraints, and to put the requirements document under version control to serve as a stable baseline for continued new product development [1].

Preliminary Design Review (PDR). The purpose of the PDR is to review the conceptual design to ensure that the planned technical approach will meet the requirements [1].

Critical Design Review (CDR). The purpose of the CDR is to review the detailed design to ensure that the design implementation has met the requirements [1].

Test Readiness Review (TRR). The purpose of the TRR is to review preparations and readiness for testing of software configuration items, including adequate version identification of software and test procedures [1].

Production Readiness Review (PRR). The purpose of the PRR is to ensure that the design is completely and accurately documented and ready for formal release to manufacturing [1].

 

Reviewers may be anybody who has a role or view of the product development or is simply as an end user. Any revision as a result of any above review meeting should be recorded by using work item status tracking system, http://smart/ttracking.

 

 

 

3.0     References

 

[1]            http://www.hyperthot.com/pm_desreviews.htm, James R. Chapman 1997