Alarm Latency Conflict in a Bedside Patient Monitor
MedDevices is building a bedside patient monitor for two hospital groups. The product owner wrote a non-functional requirement: 'The monitor must raise an alarm within 1 second of detecting a critical arrhythmia.' At Hospital A, 12 clinicians insist on 1 second because they claim delays endanger patients. At Hospital B, 9 clinicians argue for 3 seconds because faster alarms produce nuisance alerts and desensitize staff. The company's safety risk analysis classifies any alarm delay beyond 2 seconds as hazardous, but no one has linked that analysis to the requirement. Clinicians are available for only 30-minute interviews, and the team cannot observe live surgery. A clickable prototype exists. The project has 10 weeks before design freeze, and the requirements document currently contains the 1-second statement with no rationale, no measurement method, and no source attribution. Two interface requirements for the hospital nurse call system are also unresolved.
1. Given the access constraints, which elicitation techniques should the team use to resolve the alarm-latency conflict, and why? Name at least two techniques and explain what each would produce.
Read the worked answer
Use document analysis of the safety risk analysis and the current requirements baseline first, because it is cheap and reveals the 2-second hazard boundary that no one has linked to the requirement. Then run structured interviews with a small, balanced sample of clinicians from both hospitals (for example, 3 from each), using a fixed question guide focused on concrete alarm scenarios rather than opinions about 'fast.' Follow with a prototype walkthrough: show the clickable prototype with 1 s, 2 s, and 3 s simulated alarm delays and ask clinicians to judge detectability, nuisance rate, and workflow impact. Do not rely on observation of live surgery, which is unavailable and would raise ethical and safety issues. The prototype walkthrough produces behavioral evidence; interviews produce rationale and context; document analysis produces the safety constraint. Record source, date, and rationale for each statement. If the two hospital groups still disagree, a facilitated reconciliation workshop with the safety officer can convert the conflict into a single measurable requirement and a documented decision, rather than letting the loudest stakeholder win.
2. Write a measurable version of the alarm-latency requirement that respects the safety analysis, and explain the trade-offs you are making.
Read the worked answer
The requirement must be bounded by the safety analysis: any delay beyond 2 s is classified hazardous, so the acceptance threshold cannot sit above 2 s. A defensible formulation is: 'When a critical arrhythmia is detected, the monitor shall produce an audible and visual alarm within 1.5 s of detection, measured from the detection event timestamp to the first perceivable alarm indication, for at least 99% of test events; no event shall exceed 2.0 s.' The 1.5 s target gives margin for measurement uncertainty and implementation variance while staying inside the hazard boundary. The 99th percentile and absolute cap prevent an average-only test from hiding dangerous outliers. The trade-off is that a shorter latency may increase nuisance alarms, so the requirement should be paired with a separate alarm-classification requirement and a usability validation objective, not solved by loosening the safety limit. Add rationale: 'Derived from safety risk analysis SR-14; source: risk officer and clinician interviews; verification: bench test with recorded arrhythmia signals.' That traceability prevents the number from being changed without revisiting the hazard.
3. The requirements document currently lacks rationale, source, and measurement method. What specific actions should the requirements engineer take before design freeze, and what risk does each action reduce?
Read the worked answer
Before design freeze, treat the alarm requirement as a mini-baseline: add attributes for source (named clinician group and risk analysis ID), rationale (hazard link), measurement method (bench test, signal injection, timestamp definition), owner, and verification method. Convene a 60-minute review with the safety officer and one clinician from each hospital to confirm the 1.5 s/2.0 s thresholds and the nuisance-alarm trade-off; record dissent in a decision log. Update the traceability matrix from hazard to requirement to test case; the missing link is the main risk because a later 'optimization' could silently violate the hazard boundary. Add an acceptance criterion to the test plan and a review checklist item for non-functional requirements. These actions reduce three risks: rework after design freeze, verification disputes at acceptance, and safety noncompliance. They also make the requirement negotiable on evidence rather than authority.