The 45-Minute Requirements 'Review' at MediCore

This is a walkthrough in form - author-led, presented to an audience, no individual preparation, primarily knowledge transfer - while the organisation believes, and the regulator expects, that a formal technical review or inspection is happening.

Defects, mapped to the review process:

• No individual preparation. Preparation is where most defects are actually found. Material issued the same morning guarantees the meeting becomes a presentation.
• Author leads and scribes. Findings are lost, filtered and softened; there is no independent record.
• Unrealistic rate. 60 pages in 45 minutes is about 45 seconds per page.
• No defined roles or entry/exit criteria, no checklist, no follow-up on actions.
• No written record of findings, so there is no audit evidence.

What to put in place: a formal review with a moderator/review leader, author, scribe and reviewers; material circulated 2–3 days ahead with a checklist; individual preparation with findings logged; the meeting used only to discuss, classify and agree actions; findings recorded in a tracked log with owner, status and closure date; explicit entry and exit criteria. For a regulated product, consider inspection for the dose-calculation requirements. That log is also the audit evidence - 'no major issues' in minutes written by the author is not.

The tool is producing signal buried in noise, and the response so far - disabling rules that caused arguments - has removed coverage precisely where it matters.

Actions, in order:

1. Triage by risk, not by count. The 60 null-pointer findings in dose calculation are safety-related and come first; a null dereference there can mean an over-infusion. Style findings are a coding-standard issue for the team, not a release blocker.
2. Configure the rule set deliberately against the coding standard the product claims to follow, and measure false-positive rates per rule. A rule is disabled only with a documented justification and an approver - never because it caused a debate.
3. Route findings into the defect/issue workflow so they have owners and status, and set a quality gate on new or changed code so the backlog stops growing.
4. Report trends, not totals, to management and the auditor.

Also state the boundary clearly: static analysis finds certain defect classes (coding standard breaches, some data-flow and control-flow faults) but cannot find requirements defects, missing logic or usability problems - it complements reviews, it does not replace them.

Respond with the economics, not with process dogma. Defects found in a requirements review cost a fraction of the same defects found in system test or, worse, in the field - and a static analysis tool cannot see a wrong dose formula, a missing alarm condition, or an ambiguous requirement. For a medical device, a requirements defect is also the most expensive kind: the code can be perfectly written and still wrong.

Sequence for the eight weeks available, chosen by risk:

1. Dose-calculation requirements and their safety-related parameters - highest harm potential, and where ambiguity is most likely.
2. Architecture and interface design for the safety-related modules.
3. The code of the dose-calculation module (review alongside the static analysis triage).
4. Test plans and test cases for the safety-related functionality - reviewing tests finds gaps before execution does.
5. Traceability records, which the notified body will ask for.

Be realistic: do not promise a full inspection of 60 pages plus everything else in eight weeks. Propose a risk-based schedule, start with the highest-harm items, and record what is out of scope so the decision is visible and owned.