# 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*.

<!--
Guidance: How to use this template
- Use one record per review. Planning (section 2) is filled before the
  review starts; sections 4 to 6 during and after it.
- Choose the review type for the purpose: an inspection finds defects
  with defined roles, entry and exit criteria and measures; a technical
  review reaches consensus on a technical approach; a walkthrough
  explains a work product to its readers and gathers feedback.
- Log issues against a location (section, line, element), not against
  the author. A review judges the work product, never the person.
- Record effort and counts honestly. They are the only way to tell
  whether reviews pay for themselves (section 6).
- For day-to-day pull request reviews, the Code Review Checklist
  (`quality/code-review-checklist`) is lighter; use this record when a
  formal review is required by the plan, a contract or a regulator.
- The worked example is a fictional inspection of a requirements
  specification for Quillfern Desk 5.3, a help desk product of the
  fictional Quillfern Systems.
-->

## Document control

<!-- Guidance: Identify the review and the exact version of the work product reviewed. A review of an unversioned draft cannot be traced. -->

| 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

<!-- Guidance: State why this review is held and why this type was chosen. ISO/IEC 20246:2017 describes reviews by attributes (clause 5.2) and common types (clause 5.3); IEEE 1028-2008 names management reviews, technical reviews, inspections, walkthroughs and audits. -->

| 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

<!-- Guidance: 20246 clause 6.4.1 (planning) and 6.4.2 (initiate review). Decide scope, roles, schedule and entry criteria before sending anything out. Do not start if the entry criteria fail: reviewing a half-finished document wastes everyone's time. -->

### 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

<!-- Guidance: Give reviewers a short checklist, ten to fifteen items, built from defects that escaped earlier reviews. A long checklist is read once and then ignored. -->

| 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

<!-- Guidance: 20246 clauses 6.4.3 (individual review) and 6.4.4 (issue communication and analysis). Log each issue once, after merging duplicates, with its location, the checklist item, a class and the agreed action. -->

| 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

<!-- Guidance: Record effort per activity in person-hours. Measures help decide next time how much material to review per session and whether the checklist works. Compare with the organisation's own history, not with figures from elsewhere. -->

| 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

<!-- Guidance: 20246 clause 6.4.5 (fixing and reporting). State the decision against the exit criteria, who checks the fixes, and when. A review without a follow-up check often leaves major issues unfixed. -->

| 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

<!-- Guidance: Link the work product, the source documents and any related records. -->

- 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.