Design Reviews
Structured process for evaluating and improving system designs
Design reviews are structured evaluations of system designs to identify issues, validate decisions, and ensure alignment with requirements before implementation begins. They are critical for quality assurance and regulatory compliance.
Purpose of Design Reviews
| Goal | Description |
|---|---|
| Defect Prevention | Find design issues before they become code bugs |
| Knowledge Sharing | Spread understanding across the team |
| Consistency | Ensure alignment with architecture and standards |
| Risk Reduction | Identify and mitigate technical risks early |
| Compliance Evidence | Document design verification activities |
Types of Design Reviews
Design Review Process
1. Preparation Phase
Author responsibilities:
- Complete design documentation
- Identify review participants
- Schedule review meeting
- Distribute materials 2+ days in advance
Reviewer responsibilities:
- Review materials before meeting
- Note questions and concerns
- Prepare feedback
2. Review Meeting
Structure:
| Time | Activity |
|---|---|
| 5 min | Introduction and context |
| 10 min | Author presents design |
| 30 min | Questions and discussion |
| 10 min | Identify action items |
| 5 min | Determine next steps |
Ground rules:
- Focus on design, not the designer
- Ask questions to understand before criticizing
- Document all feedback
- Keep meeting focused and time-boxed
3. Follow-up Phase
- Author addresses feedback
- Updates design documents
- Schedules follow-up if needed
- Documents final approval
Design Review Checklist
Requirements Alignment
- Design addresses all functional requirements
- Non-functional requirements are considered
- Edge cases are handled
- Error conditions are addressed
Architecture Consistency
- Follows established patterns
- Adheres to coding standards
- Uses approved technologies
- Integrates with existing components
Quality Attributes
- Performance: Will it meet performance requirements?
- Scalability: Can it handle growth?
- Security: Are security requirements met?
- Maintainability: Is it understandable and changeable?
- Testability: Can it be effectively tested?
Technical Soundness
- Appropriate abstractions used
- Dependencies are well-managed
- Error handling is comprehensive
- Resource management is correct
Documentation
- Design is clearly documented
- Decisions are explained with rationale
- Diagrams are accurate and helpful
- Traceability to requirements exists
Architecture Review
When to Conduct
- New system or major subsystem
- Significant architectural changes
- Introduction of new technologies
- Before major milestones
Participants
| Role | Responsibility |
|---|---|
| Architect | Present design, answer questions |
| Tech Lead | Validate technical feasibility |
| Security | Assess security implications |
| Operations | Evaluate operational concerns |
| QA Lead | Consider testability |
Focus Areas
Security Design Review
Threat Modeling Integration
Link design reviews to threat modeling:
- Review threat model findings
- Verify mitigations in design
- Identify new threats from design
- Update threat model as needed
Security Checklist
- Authentication mechanisms are appropriate
- Authorization is enforced at all layers
- Sensitive data is encrypted (at rest and in transit)
- Input validation is comprehensive
- Output encoding prevents injection
- Secrets are managed securely
- Audit logging is implemented
- Error messages don't leak information
Data Model Review
Focus Areas
| Area | Questions |
|---|---|
| Structure | Are entities and relationships correct? |
| Integrity | Are constraints properly defined? |
| Performance | Are indexes appropriate? |
| Security | Is sensitive data protected? |
| Compliance | Are retention requirements met? |
Review Checklist
- Tables are properly normalized (or denormalized for good reason)
- Primary and foreign keys are defined
- Indexes support query patterns
- Constraints enforce business rules
- Sensitive columns are identified
- Audit columns exist where needed
- Migration strategy is defined
Review Meeting Template
# Design Review Meeting
**Date:** [Date]
**Design:** [Design Name]
**Author:** [Author Name]
**Reviewers:** [List of reviewers]
## Context
Brief description of the design and its purpose
## Design Presentation
Summary of key design decisions
## Discussion Points
| # | Topic | Discussion | Resolution |
|---|-------|------------|------------|
| 1 | | | |
| 2 | | | |
## Action Items
| # | Action | Owner | Due Date |
|---|--------|-------|----------|
| 1 | | | |
| 2 | | | |
## Decision
- [ ] Approved
- [ ] Approved with changes
- [ ] Not approved - redesign required
## Next Steps
[Describe follow-up actions]
## Signatures
| Name | Role | Date |
|------|------|------|
| | | |Regulatory Compliance
FDA Design Controls
For medical device software, design reviews are part of Design Controls:
| FDA Requirement | Design Review Activity |
|---|---|
| Design Input | Review requirements coverage |
| Design Output | Review design specifications |
| Design Verification | Verify design meets inputs |
| Design Validation | Validate design meets user needs |
| Design Transfer | Review production readiness |
Documentation Requirements
- Meeting agenda and attendance
- Materials reviewed
- Issues identified
- Decisions made
- Action items and owners
- Sign-off records
Best Practices
Do
- Schedule reviews early in the design process
- Keep reviews focused and time-boxed
- Document all findings and decisions
- Follow up on action items
- Include diverse perspectives
- Use checklists consistently
Don't
- Skip reviews for "simple" designs
- Let reviews become rubber stamps
- Make design reviews personal
- Delay reviews until implementation starts
- Ignore non-functional requirements
- Forget to update documentation
Related Resources
Compliance
This section fulfills ISO 13485 requirements for design review (7.3.5), design verification (7.3.6), and control of records (4.2.4), and ISO 27001 requirements for secure development lifecycle (A.8.25) and information security in project management (A.5.8).
How is this guide?
Last updated on