Review Checklist for Detailed Designs
Correctness and Completeness
Is the design a complete and accurate implementation of the architecture?
Are there any inconsistencies between design documents of different types or levels?
Are the specifications of each component complete and verifiable?
Have all numerical techniques been analyzed for accuracy?
Has critical timing been analyzed and processing priorities addressed?
Is there a memory budget with estimated storage requirements for each module, table, and file?
Are all functions clearly specified and logically independent?
Have maintainability issues been adequately addressed?
Does each module have high internal cohesion and low external coupling?
Is the logic correct, clear, and complete?
Have all user interfaces been completely designed?
Can the termination conditions for loops be realized?
Can all logic be tested?
Have all quality attributes and performance requirements been adequately addressed?
Have all security considerations been designed?
Have internationalization issues been properly and adequately addressed?
Does analysis indicate that the design will achieve required performance and technical goals?
Data
Has all the data been properly defined and initialized?
Is all defined data used?
Are data structures and element names meaningful, compliant with naming conventions, and
consistent with the project data dictionary?
Are defaults used, and are they correct?
Standards and Traceability
Have all local design standards been followed?
Does the calling protocol follow project standards?
Does the human interface follow project standards?
Can all parts of the design be traced back to the architecture and requirements?
Are all elements of the requirements specification and architecture addressed in the design?
Robustness
Have self-test, fail-safe, and degraded mode requirements been accounted for?
Are error conditions handled in a nondestructive manner through a defined mechanism?
Can corrective action be taken by the module that traps an error?
Are unusual conditions handled reasonably and nondestructively?
Risk Areas
Do any individual requirements trace to multiple architectural components or multiple design
modules (could indicate high coupling among modules)?
Do an individual design units (modules) trace back to a large number of requirement elements
in the requirements specification (could indicate high complexity for a single module)?
Is there any globally communicated information (especially risky when it is critical that
broadcast of that information is coordinated to avoid mismatched states across the system)?
Copyright © 2006 Emerson Page 1
