Intent
Ensure quality by having more than just one pair of eyes looking at your product description.
Motivation
Reviews are part of every single functional safety standard, and there is a reason: Reviews improve quality and reduce development risks, especially if done early and often.
Applicability
Use the pattern at a minimum before you move to a new phase in your development (e.g. Quality Gate). But most of the time, a review should be done much more often than that. Distinguish between formal and informal reviews.
Structure
In a review stakeholders are invited to provide feedback on some work items. There are many forms of reviews:
- An informal review can happen ad-hoc by soliciting feedback
- A formal review typically has an approver who decides on whether the review outcome is good enough to proceed
- Peer work (e.g. peer programming) involves two people in the content creation, thereby making the review part of the creation.
Consequences
The pattern has the following benefits and liabilities:
- Benefits:
- Significantly higher quality
- Risks are identified early
- Knowledge transfer
- Liabilities:
- Time investment of the reviewers
- The risk of reviewing outdated information
- The risk of holding back the development (by waiting for the outcome of the review)
Implementation
Don't do your reviews by sending Word documents around via email! This is extremely inefficient and the reason why people usually dread reviews.
When working with requirements, consider Jama's review center. When working with code, consider a code review system like Crucible.
Related Patterns