Fagan Inspection

Details

Also known as: Formal Code Inspection, Software Inspection, Fagan’s Inspection Method

Core Concepts:

Formal inspection process: A structured, multi-phase review process for software artifacts (requirements, design, code) with defined roles and entry/exit criteria
Roles: Moderator (facilitates and logs), Author (created the artifact), Inspectors (reviewers), Recorder (documents defects)
Six phases: Planning → Overview → Preparation → Inspection Meeting → Rework → Follow-up
Entry and exit criteria: Explicit conditions that must be met before entering and leaving each phase, preventing premature progression
Defect classification: Defects are categorized by type (missing, wrong, extra) and severity, enabling process improvement through causal analysis
Metrics-driven: Inspection data (defect rate, inspection rate) are collected and used to improve both the product and the inspection process itself
Key Proponents: Michael Fagan ("Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal, 1976)

Safety-critical or high-assurance software where defect escape is costly
Reviewing requirements, architecture, design, or code artifacts early in development
Establishing a culture of quality and shared code ownership in teams
When you want measurable, process-level quality improvement over time
Regulated environments (medical devices, avionics, finance) requiring documented review evidence

The definition is intact and unchanged since Fagan’s 1976 paper (IBM Systems Journal 15(3)): a formal, multi-role inspection with defined phases and measured defect data
The formal meeting-based inspection is rarely practiced today; asynchronous, tool-based pull-request review has largely replaced it — a documented shift with its own trade-offs: modern review finds fewer defects per hour of rigor but adds knowledge transfer and team awareness (Bacchelli & Bird, "Expectations, Outcomes, and Challenges of Modern Code Review", ICSE 2013; Rigby & Bird, FSE 2013)