Audit Finding: Is UML Worth Six Months?
A 60-person medical device firm ships infusion-pump firmware under IEC 62304 Class C. Engineers write C and unit tests; traceability lives in a spreadsheet linking 410 requirements to 1,900 test cases. An audit finds 37 requirements with no design evidence and issues a Form 483. The VP of Engineering proposes buying a UML tool and 'modeling everything' with two modelers over six months. Constraints: the product has five years of support left, 60 engineers have no UML training, release cycles are 14 months, and regulators require bidirectional traceability from requirement to design to code to test. A consultant claims modeling will 'eliminate design defects' and 'cut test cases by 40%.'
1. Which benefits of software modeling are credible and material for this audit finding, and which consultant claims should be challenged? Frame your answer in terms of what UML models can and cannot guarantee.
Read the worked answer
Credible benefits: a UML design model gives auditors an explicit design artifact that can be traced to requirements and tests, addressing the 37 missing design-evidence findings; it supports review of high-risk behavior before code; and it gives 60 engineers a shared notation for interfaces and states. These are process and communication benefits, not guarantees. Challenge 'eliminates design defects': models can be wrong, inconsistent, or stale, and UML has no built-in verification. Challenge 'cuts test cases by 40%': modeling may reduce some test design effort through earlier review, but the figure is unsupported and Class C verification still requires evidence. The material question is whether two modelers can produce reviewable, maintained models for the highest-risk requirements within the audit timeline, not whether modeling is philosophically good. Measure audit closure and review findings, not slogans.
2. Given the 37 missing design-evidence requirements, which diagram types would you model first and why? Consider effort and audit value, not completeness.
Read the worked answer
Start with the 37 findings, not with full coverage. For each, choose the diagram that makes the missing design evidence visible: state machine for pump operating modes, occlusion, battery, and fault handling; sequence for critical dosing and alarm flows across controller, sensor, and motor; activity for clinical workflow and exception handling; component/class for architecture and data. Model the highest-risk requirements first (over-infusion, air-in-line, battery depletion) because audit and safety value are highest. One diagram can cover several requirements, so map each modeled element to requirement IDs. Do not model UI screens or trivial getters. A six-month, two-modeler effort cannot cover 410 requirements in detail; a focused set of 15 to 25 diagrams with traceability is more defensible than a broad, shallow model. The criterion is audit evidence per unit of effort, not diagram count.
3. How would you prevent model-code drift and measure whether the modeling investment paid back within the five-year horizon?
Read the worked answer
Prevent drift by making the model part of the change process: every code change affecting a modeled behavior requires a model update in the same review; use generated documentation or round-trip checks where the tool supports them, and link model elements to code identifiers and test cases. Add a CI check that flags changed source files with no corresponding model element for safety-classified units. Measure payback with audit-relevant metrics: number of findings closed with model evidence, time to answer a traceability query (target under 10 minutes versus spreadsheet hours), review defects found before code, and defect escape rate for modeled functions. Track model staleness (percentage of modeled elements changed in code but not in the model). Do not measure diagram count. With five years of support, the investment pays back if it reduces audit effort and late defect discovery; set a 12-month go/no-go gate.