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 (220.127.116.11) 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.Tags: ambigous standards, ambiguous requirements, ambiguous terms, medical devices, Standards, Verification
By AeroEngineer July 23, 2014 - 3:49 am
Thanks for the very good article as always!
In my experience there is another issue with such requirements. The level or hierarchy of the requirements derived from the standard may not be appropriate for the requirement document being authored. In this case, system level requirements to comply with standard IEC 60601-1-8 should be specified. Whereas, the four valid requirements mentioned at the end of the article should be specified at appropriate lower level. Any thoughts?
By Lou Wheatcraft July 23, 2014 - 8:44 am
Thank you for your comment. This is a very valid question. A well written requirement needs to be documented at the appropriate level. One rule of thumb is that requirements need to be documented at the level they will be verified. The requirement must also be unambiguous and verifiable.
For this example, let’s look at the system architecture. For discussion, assume there are three levels: system, subsystem, component. The topic is about both audible and visual alarms. If more than one subsystem is involved in the inactivation of an alarm, then the four valid requirements would need to be written at the system level and then allocated to the appropriate subsystems. If only one subsystem is involved in alarm inactivation, then the four valid requirements would need to written at the subsystem system level and then allocated to the appropriate components that make up that subsystem. Then at the component level, children requirements would be derived and documented at that level.
The main problem I have for this example is that the topic of IEC 60601-1-8 is alarms and what the standard says is ambiguous and allows the developer to make choices (a common issue with most standards). If only one subsystem has alarms, then this standard should be invoked for that subsystem, however the point of the blog is that the nature of this standard is it is ambiguous, so just invoking the standard is not enough – the four valid requirements need to be the ones that are documented in your requirement spec – no matter which level they are documented in – not just a requirement to comply with the standard. Also, keep in mind that the standard deals with all aspects of alarms, not just inactivation. Thus, for the subsystem dealing with alarms, there will be the same issues for the other aspects and there will be the need to derive multiple valid requirements dealing with all the other alarm topics addressed by the standard.
During scope definition, the standard would be identified as a driver for the medical device. As a result, the requirement writers will know they have to derive requirements that meet the intent of the standard and document them at the appropriate level.
In rare cases where what is in the standard is unambiguous, you may not need to derive valid children requirements and can just invoke the standard as a whole or portions of the standard. In cases where the standard deals with multiple topics AND the requirements in the standard are not ambiguous, you can invoke the standard at the system level and then allocate it to the subsystems involved in a portion of the standard. The subsystem would then determine which part of the standard applies and then derive children requirements that result in the intent of the applicable requirements in the standard to be met.