Justifying Modeling Effort on an Infusion Pump Program
A medical device manufacturer is 10 months into an 18-month infusion pump program. The team has 240 shall requirements, 6 external suppliers, and a change rate near 35% per year. The current SysML model contains four diagrams created for a design review; test engineers still work from a spreadsheet, and suppliers exchange PDF interface control documents. Last year a similar program discovered 12 interface mismatches during integration, adding 9 weeks. Management asks whether the modeling effort should be expanded or stopped. The chief engineer wants a business case that ties modeling to specific program risks, not a general 'improves communication' claim. The team has budget for two more part-time modelers and 6 weeks before the next supplier interface freeze. They need to decide which modeling purposes to prioritize and how to measure benefit within the program. The model is not currently linked to requirements or test.
1. Identify three modeling purposes that address this program's specific risks. For each, state what would be modeled and how benefit would be measured within the program.
Read the worked answer
The purposes must be chosen against the stated risks: supplier interface churn, high requirement change rate, and late integration defects.
- Interface specification and supplier exchange: model the pump's external and supplier-facing interfaces as blocks, ports, and interface blocks, with item flows for fluids, power, and signals. Measure benefit by the number of interface mismatches found before integration and by the time to answer a supplier change request. A realistic target is to reduce the 12-mismatch class of defect and shorten supplier clarification cycles.
- Requirement-to-design impact analysis: link requirements to design elements with «satisfy» and to test cases with «verify». Measure benefit by the time to assess the impact of a changed requirement and by the percentage of changed requirements with an identified affected design and test set. With a 35% change rate, even a modest reduction in impact-analysis time is measurable.
- Behavioral and safety analysis: model the pump's modes and alarm handling as a state machine so hazards can be checked against reachable states and transitions. Measure benefit by the number of hazardous state/transition questions answered from the model during the hazard workshop and by the number of issues found before test.
Do not claim general productivity; tie each purpose to a decision the program actually makes.
2. What should the team NOT try to model in the six weeks before the interface freeze, and why?
Read the worked answer
They should not attempt a complete behavioral or physical simulation of the pump, a full geometric model, or a comprehensive model of every supplier's internal design. Those efforts would consume the six weeks and would not address the immediate interface-freeze risk. They should also avoid modeling all 240 requirements at equal depth; the program needs a thin, complete trace for the requirements affected by supplier interfaces and recent changes, not a perfect model of stable requirements. Do not build a custom stereotype library or a formal viewpoint framework at this stage; those are organization-level investments and would delay the interface work. The judgment call is to model the boundary and the change path: supplier-facing interfaces, the requirements that constrain them, and the tests that verify them. Defer internal software design detail and detailed failure-mode simulation until after the freeze, when the interface baseline is stable.
3. How should the team connect model use to supplier interface control so the benefit is visible to management?
Read the worked answer
Make the model the source of the interface control document rather than a parallel artifact. Define each supplier interface as a block or interface block with ports and item flows; generate the interface control document from a view of those elements. When a supplier requests a change, record it against the interface element and show the affected requirements, design parts, and tests through trace links. At the interface freeze, baseline the interface package and compare supplier documents against that baseline. Report three metrics: number of interface elements under configuration control, number of supplier change requests answered from the model, and number of mismatches found at document review rather than integration. This makes the modeling benefit concrete: it changes how the interface freeze is conducted. If the model is only used to draw four review diagrams, management is right to question the cost.