We were recently asked the following question: “I have a specific question about product requirements relating to standards that I’d like your input on:  Which requirement syntax is preferred? #1 or #2

1) “The System shall allow user to silence or inactivate audible alarm indications per IEC 60601-1-8 section 6.8.1″ (this example allows the requirement writer to interpret the details of the referenced standard & add that context to the requirement statement.)

2) The System shall comply with IEC 60601-1-8 section 6.8.1 (this example doesn’t include someone’s interpretation of the standard but yet puts the responsibility on the verification person to verify this standard section correctly.)

So #1 references the standard & adds someone’s interpretation of it in the requirement statement whereas #2 just references the standard section & relies on the verification person to interpret the meaning (with help from the standards expert)”

The short answer is that, on the surface, we prefer requirement number 1. It seems to be more precise as to what is being communicated.  Precision is good when it comes to communication – ambiguity is bad. Requirements should be written so there is no need for interpretation – the intent of the requirement and what will be verified should be clearly stated in the requirement.

However, the issue is more complex.

“IEC 60601-1-8 : Medical electrical equipment  General requirements for safety – For collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems”  Section 6.8.1 contains the following four statements: (I say statements in that they do not qualify as requirements even if they are called requirements.)

• Means are provided for the OPERATOR to inactivate the auditory, or the visual and auditory, generation of ALARM SIGNALS
• The inactivation of the generation of ALARM SIGNALS is indefinite (off) or timed (paused)
• Flashing visual ALARM SIGNALS (201.3.2.2) get inactivated by AUDIO PAUSED or AUDIO OFF
• When an ALARM SIGNAL inactivation applies to an individual ALARM CONDITION or a group of ALARM CONDITIONS, the generation of ALARM SIGNALS from other ALARM CONDITIONS is unaffected

Note the definition of the terms.  The definition of inactivate: “make inactive or inoperative”; while the definition of deactivate means “make (something, typically technical equipment or a virus) inactive by disconnecting or destroying it: the switch deactivates the alarm.”   A minor distinction but an important one the author of example requirement 1 seems not to have understood.

Given the subject of section 6.8.1 is about inactivation of the generation of an alarm signal, the person writing your requirement 1 was trying to make clear what the topic of the requirement was – inactivation of an alarm.   Requirement 2 does not do this and thus is meaningless until you read what is in the standard.  However, the person writing requirement 1 may have misinterpreted what section 6.8.1 is about.   Requirement 1, as written implies that the user needs to be able to silence or inactivate an alarm indication while the first statement of section 6.8.1 is about the inactivation of the generation of an alarm signal.  This could be interpreted as “to prevent the alarm from happening in the first place” rather than “deactivating the alarm after it happens”.   Ambiguity!!  Also, the writer of example 1, interpreted “inactivate” as “deactivate” (see above definitions).

[From a personal perspective, this is a very important distinction!!  While spending time in the hospital, there were some medical devices that during the night would sound an alarm when an IV with medication was complete.  Nothing bad would happen when the medication was all dispensed.  It would have been great to deactivate the alarm from happening so it didn’t wake us up!!  Instead the alarm went off, we called for a nurse, and when she had time, she would turn off the loud audible alarm.]

The real issue is one of communication.    A well formed requirement is unambiguous, verifiable, and can be understood one way.  Someone had the expectation and need for the user of medical device to inactivate the alarm. The problem is that this expectation is ambiguous and needs further elaboration.  The requirement writer has the responsibility to clearly communicate stakeholder expectations to the design team if the form of a requirement.  Assuming the requirement is clear, unambiguous, and verifiable it should be understood just one way.   I take issue with your statement: “relies on the verification person to interpret the meaning (with help from the standards expert)”   This should NEVER be the case!!!  The requirements should be written such that the design team and the verification team clearly understand the requirement the same way!!

Unfortunately the “statements” in section 6.8.1 are ambiguous and thus both requirement 1 and 2 of your example are ambiguous.  What needs to happen is that the requirement writer, design person, and verification person need to get together and write a set of requirements that are clear, unambiguous, and verifiable AND meet the intent of the standards in section 6.8.1.  Notice the wording of the first statement has a “and” and “or”.  The topic is about inactivation of the generation of both ”auditory” OR “visual and auditory”.  Thus you have to make a determination which case you want to implement in your medical device.  This means you have to go back to the person who had the need for the generation of the alarm to be deactivated.  Then ask them do you mean just the audible portion, the visual portion (assuming you have both) or both audible and visual?  [Note: The writer of your example requirement 1, made this determination – audible, where the question was left open in example requirement 2.  That makes example requirement 1 less ambiguous.]

You also need to ask the customer “Do you want to deactivate the alarm function so it doesn’t sound (or show a visual cue) OR do you really want the alarm to activate but then be able to silence the alarm?” Once you know the answers to these questions, you can write the requirements accordingly – no ambiguity, no room for misinterpretation by the designer nor the verifier.  The second statement in 6.8.1 also calls for a decision.  You have to decide and then write another requirement that communicates what the designer needs to design to, the same for the third statement.  The fourth statement is more of a constraint, but needs to be clarified in a well–formed requirement.

To address these kinds of questions, you need to work with the customer and other stakeholders and develop system concepts, scenarios, use cases, user stories, etc.  that include a discussion of both nominal operations of the medical device as well as off-nominal operations and how to handle alarms.

So in the end, both of your example requirements are defective and need to be replaced by four well-formed requirements that were derived from the statements in section 6.8.1.

This is a very common issue when invoking standards!!!  Standards are developed by committees who rarely know how to write requirements.  Also, because the standards apply to a generic class of products and not a single product, the statements often give options and are ambiguous.  The proper use of standards is for the users of the standards to make an interpretation for their specific application and then write (derive) well-formed requirements that are unambiguous, clear, and verifiable that address the intent of the standard.  These derived requirements then are traced to the standard they were derived from.

Comments to this blog are welcome.

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.