Review Record: [Work product name and version]
Record of one formal work product review (inspection, technical
review or walkthrough) of a document, model, design or code. It
captures the review type and attributes, the roles, the checklist or
reading technique, the issues found, the effort spent and the exit
decision. Review types, process activities and techniques follow the
vocabulary of ISO/IEC 20246:2017 (work product reviews) and, for
organisations that still use it, IEEE 1028-2008 (software reviews and
audits). Replace every [bracketed] value and every row marked
Example.
Document control
| Field | Value |
|---|
| Review ID | [REV-QD53-004] (Example) |
| Work product | [Software Requirements Specification, SRS-QD53, sections 4 to 6] (Example) |
| Version reviewed | [0.6, commit or document version] |
| Size | [18 pages] (Example) |
| Review type | [Inspection / Technical review / Walkthrough / Informal review] |
| Status | [Planned / In progress / Closed] |
| Owner (review leader) | [@review-leader] |
| Classification | [Internal] |
| Last updated | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Planned |
| 1.0 | YYYY-MM-DD | [@name] | Example: Closed after follow-up check |
1. Purpose and review type
| Attribute | Value |
|---|
| Purpose | Example: Find defects in the requirements before design starts |
| Review type | Example: Inspection |
| Reason for this type | Example: High-risk requirements (export and accessibility) with contractual acceptance |
| Formality | [Formal with entry and exit criteria / informal] |
| Meeting | [Review meeting / no meeting, issues handled asynchronously] |
| Reading technique | [Checklist-based / scenario-based / perspective-based / role-based / ad hoc] |
2. Planning and entry criteria
2.1 Roles
| Role | Name | Perspective or focus |
|---|
| Review leader (moderator) | [@name] | Runs the process, checks criteria |
| Author | [@name] | Answers questions, fixes issues |
| Reviewer R1 (Example) | [@tester] | Testability (perspective: tester) |
| Reviewer R2 (Example) | [@developer] | Feasibility (perspective: designer) |
| Reviewer R3 (Example) | [@support-lead] | Usability (perspective: user) |
| Reviewer R4 (Example) | [@accessibility-lead] | Accessibility requirements |
| Scribe | [@name] | Logs issues in the meeting |
2.2 Schedule
| Activity | Date | Duration |
|---|
| Kick-off and material sent | YYYY-MM-DD | [15 min] |
| Individual review ends | YYYY-MM-DD | [About 2 hours each] |
| Review meeting | YYYY-MM-DD | [90 min] |
| Fixing due | YYYY-MM-DD | |
| Follow-up check | YYYY-MM-DD | |
2.3 Entry criteria
| Criterion | Met? |
|---|
| Work product is complete for the scope and version-controlled | [Yes / No] |
| Source documents (higher-level requirements, standards) are available | [Yes / No] |
| Automated checks done (spelling, links, lint or static analysis for code) | [Yes / No] |
| Reviewers have the checklist and their assigned perspective | [Yes / No] |
3. Checklist or reading guide
| ID | Check | Applies to |
|---|
| CHK-01 (Example) | Every requirement is testable: it has a measurable acceptance condition | All |
| CHK-02 (Example) | No requirement contradicts another or a higher-level requirement | All |
| CHK-03 (Example) | Error and empty states are specified, not only the success path | Functional |
| CHK-04 (Example) | Performance and size limits have numbers and units | Non-functional |
| CHK-05 (Example) | Accessibility requirements name the standard and level (for example WCAG 2.2 AA) | Non-functional |
| CHK-06 (Example) | Terms match the glossary | All |
| [CHK-nn] | [Check] | [Scope] |
4. Issues found
| ID | Location | Description | Checklist | Class | Found by | Action | Status |
|---|
| ISS-01 (Example) | SRS 4.3, FR-212 | Export time limit missing for large histories | CHK-04 | Major | R1, R2 | Add limit and file size range | Fixed |
| ISS-02 (Example) | SRS 5.1 | Accessibility requirement says "accessible" without standard or level | CHK-05 | Major | R4 | Name WCAG 2.2 AA and EN 301 549 | Fixed |
| ISS-03 (Example) | SRS 4.7, FR-240 | No behaviour defined when the assignee leaves the organisation | CHK-03 | Major | R3 | Add rule | Fixed |
| ISS-04 (Example) | SRS 6.2 | "Queue" and "inbox" used for the same concept | CHK-06 | Minor | R2 | Use "queue" | Fixed |
| ISS-05 (Example) | SRS 4.1 | Is bulk export in scope for 5.3? | | Question | R1 | Product owner answered: no, 5.4 | Closed |
| [ISS-nn] | [Location] | [Description] | [CHK] | [Major / Minor / Question / Improvement] | [Reviewer] | [Action] | [Open / Fixed / Rejected / Closed] |
Classes (Example): Major, would cause a wrong product or failed
acceptance if not fixed; Minor, unclear or untidy but would not cause
a wrong product; Question, needs an answer from the author or owner;
Improvement, a suggestion the author may decline.
4.1 Issue summary
| Class | Logged by individuals | After merging duplicates |
|---|
| Major (Example) | 10 | 5 |
| Minor (Example) | 18 | 14 |
| Question (Example) | 4 | 4 |
| Total | 32 | 23 |
5. Effort and measures
| Measure | Value (Example) | How calculated |
|---|
| Individual review effort | 8.0 person-hours | R1 2.0 + R2 2.5 + R3 1.5 + R4 2.0 |
| Meeting effort | 7.5 person-hours | 1.5 hours x 5 attendees |
| Total review effort | 15.5 person-hours | 8.0 + 7.5, excluding fixing |
| Preparation rate | 9.0 pages per hour | 18 pages / 2.0 average hours per reviewer |
| Issue density | 1.28 unique issues per page | 23 / 18 |
| Major and minor issues per person-hour | 1.23 | (5 + 14) / 15.5 |
| Fixing effort | [n person-hours] | Author's estimate |
6. Exit decision and follow-up
| Exit criterion | Result |
|---|
| All major issues fixed and checked by the review leader | Example: Met on YYYY-MM-DD |
| Minor issues fixed or recorded with a reason | Example: 13 fixed, 1 rejected with reason |
| Questions answered | Example: 4 of 4 |
| Item | Value |
|---|
| Decision | [Accept / Accept after fixes checked by leader / Re-review required] |
| Decided by | [@review-leader] |
| Date | YYYY-MM-DD |
| Version accepted | [0.7] (Example) |
6.1 Process observations
Example: Three of the five major issues came from the tester and
accessibility perspectives; keep both perspectives for requirements
reviews. CHK-04 found two issues; consider an automated check for
numbers without units.
7. References
- Work product: [link to SRS-QD53 version 0.6 and 0.7]
- Source documents: [higher-level requirements, contract annex]
- Related templates: Code Review Checklist (
quality/code-review-checklist), Software Requirements Specification (requirements/srs-iso-29148), Verification and Validation Plan (quality/vv-plan), Software Quality Assurance Plan (quality/sqa-plan)
- ISO/IEC 20246:2017, Software and systems engineering: Work product reviews, first edition (2017-02), confirmed at its last systematic review (stage 90.93 in ISO open data, October 2026). Official text: ISO and IEC, purchase or licensed access: https://www.iso.org/standard/67407.html
- IEEE 1028-2008, IEEE Standard for Software Reviews and Audits (listed by IEEE as inactive-reserved since 2019-11-07). Official text: IEEE, purchase or licensed access: https://standards.ieee.org/ieee/1028/4402/
Standard and licence note
Structure aligned with ISO/IEC 20246:2017, Software and systems
engineering: Work product reviews: review attributes and types (clauses
5.2 and 5.3), the review process activities of planning, initiating the
review, individual review, issue communication and analysis, and fixing
and reporting (clause 6.4), and the individual reviewing techniques
(clause 7.2). Review type names also follow IEEE 1028-2008, which IEEE
lists as inactive-reserved. Both standards are copyrighted and are cited
by name, edition and clause number only; no text, table or example from
them is reproduced, and all wording here is original. Check the current
edition and status before claiming conformance. Official text: ISO, IEC
and IEEE, purchase or licensed access, at the links in section 7.
Template licence: MIT.