User Needs to Testing: A Complete Example – Part 3: Requirements

Why Requirements?

We’ve all seen the tree swing analogy. Each member of a project has a different idea about the final product and it results in several misunderstandings. 

How could this have been avoided? With good requirements!

Requirements are a contract between the business, the user and the design team. It transforms the user and business needs into a language that guides design, but does not dictate it. It captures all the goals that the design needs to meet in easy to understand language.

Generally speaking though, requirements get a bad rap. For many small companies, the people that write the requirements might also be those that do the design. For simple products, they may not have that many requirements and for complex products, writing requirements could take up to 30% of development time and be hundreds of pages long.

So why even bother with requirements?

Requirements are important for many reasons:

1. They provide a clear understanding between the business and the design team about what will be made. Any disagreements can be headed off early by defining the requirements in advance.
2. They help spark more innovative approaches. This may seem counterintuitive but there is a big difference between telling the design team to make the product with a USB port so they can plug in the mouse or just telling them that the customer needs to be able to make menu selections. The first negates any possibility that the designers could determine that a touch screen is better, or a joystick, or even gestures.
3. The help with testing. By providing comprehensive design requirements, testers can better understand how comprehensive their testing is by evaluating their requirements coverage. If a requirement does not have an associated test case, maybe this aspect of the design is not being tested?
4. They save time and money on errors. By defining something as simple as the requirement using pen and paper or a computer in advance, you can avoid expensive and time consuming iterations of design. For example, if the designers forget to take into account that a medical device needs to be steam sterilizable, this may only be detected during the validation stage when it fails this test. Or worse still, without the requirement listed, this aspect is not even tested and then puts a patient at risk when it is put into use.

The main conclusion here is that requirements are suuuuuper important. They save time, money, and the most important of all, well written requirements may lead to a safer medical device.

U.S. Market

The U.S. market has a clear reference to requirements.

“(c) Design input. Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.” – Sec. 820.30 Design controls.

European Market

The European market has a more indirect reference for requirements in the 2017/745 Medical Device Regulations:

“The quality management system shall address at least the following aspects: ….
(g) product realisation, including planning, design, development, production and service provision;” – Article 10 – General obligations of manufacturers – Clause 9

“For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.” – Annex I – Chapter II – Clause 17.2.

Once again, as with user needs, many harmonized standards oblige manufacturers to use requirements as well.

International Standards

International standards such as the ISO 13485, IEC 62304, IEC 60601-1, etc. all mention the need for product requirements. The following examples are taken from the ISO 13485 as it is the most used by manufacturers of all international standards:

7.1 Planning of product realization
…
In planning product realization, the organization shall determine the following, as appropriate:
a) quality objectives and requirements for the product;
…

7.2.1 Determination of requirements related to product
The organization shall determine:
a) requirements specified by the customer, including the requirements for delivery and post-delivery
activities;
b) requirements not stated by the customer but necessary for specified or intended use, as known;
c) applicable regulatory requirements related to the product;
d) any user training needed to ensure specified performance and safe use of the medical device;
e) any additional requirements determined by the organization.

Format of Requirements

Requirements Structure

Each requirement consists of a unique identifier, the requirements text. Requirements can also optionally include a context, a criticality, and a version (depending on whether you version individual requirements or the document as a whole). Finally, requirement text may use words or phrases that are associated with a specific business definition.

Identifier

The requirements identifier is a set of characters that can be alphanumeric that uniquely identify a requirement over its lifetime. If you are using a requirement database, these are usually generated automatically for you. If not, it makes sense to include some set of digits that count up as new requirements are added.

Plan your identifiers carefully. If you want to follow a pattern, consider whether this pattern will be applicable to a requirement over its entire lifetime. For example, if you decide to add a prefix to the identifier that shows where in the document to find it, consider what will happen if more requirements are slotted into the document. 

A possible example of a requirement identifier is as follows:

P001-F-00026 (P001- requirement for product 001, F – functional requirement, 00026 – the requirement number )
A040-NF-00450 (A040 – requirement for assembly 040, NF – non-functional requirement, 00450 – the requirement number)

Or an alternative:

6.2.3.4.5 (Chapter 6 – Functional Requirements, section 2 – Patient Images, subsection 3 – Display, subsubsection 4 – Zoom, requirement 5)

The advantage of the second system is you can easily find the requirements in the document. You can also easily understand the requirement context from just a glance at it. If you need to add or remove chapters or sections you can do it without interrupting the identifiers if you are ok with your document sometimes skipping chapters or sections that have been removed or finding chapters and sections in a funny order as they are added later. You just have to be sure that you define your chapters/sections very well that they will not need to be merged or separated over the lifetime of the product. 

You can define any identifier system that makes sense for your company.

Criticality

It is strongly encouraged that you add a criticality to your requirement as well. This helps guide the testers and test planner to determine the amount of effort that should be devoted to testing the requirement. Requirement with high criticality might need to be positively and negatively tested, or have upper and lower limits tested, or need to be tested in fault condition, etc, whereas a low criticality requirement may only need to be checked once.

It’s best to clearly define a system for applying criticality consistently. One example could be as follows:

• High criticality – an incorrect implementation of this requirement could lead to permanent patient harm or death
• Medium criticality – an incorrect implementation of this requirement could lead to patient injury that requires intervention but is not permanent
• Low criticality – all other requirements

It might also be best to consider whether or not the requirement exists to mitigate a risk, therefore it might also contribute to the criticality:

• High criticality – mitigates a risk with a major level of concern
• Medium criticality – mitigates a risk with a moderate level of concern
• Low criticality – mitigates a risk with a minor level of concern

Version

You can version individual requirements, or you can version the whole requirements document (or both), with much the same effort. When you have individually versioned them you can very easily direct people to those requirements to review when making a change, and you can also very easily see which tests need to be updated (if requirements are correctly traceable to test cases). If you are versioning the document, you simply need to keep a list of requirements that have changed to achieve the same result.

Rationale

A rationale can be useful for communicating important information to designers and also to any future users of the document that may wish to make changes. A rationale can help illustrate a point and ensure that vital information is not lost.

Example:

• The display shall have text with font no smaller than 18 point.
  Rationale: This device is intended to be used by patients with diabetes who may have reduced vision. The American Printing House for the Blind (APH) defines 18 point to be acceptable for low vision users.

Definition

Using a definition in the requirements language can also be a very helpful way of ensuring consistency. For example, perhaps many requirements are associated with an upper pressure limit. Instead of defining the number in each requirement, instead refer to a definition called ‘upper safe pressure limit’. That way, if the number every needs to be changed, it only needs to be changed in one place.

Examples:

• The pressure gauge should show a range of between 0 and a value 20% greater than the upper safe pressure limit.
• If the upper safe pressure limit is exceeded, the pressure gauge shall display a red light.
• When the upper safe pressure limit is not exceeded, the pressure gauge shall display a green light.

Requirements Syntax

In order to ensure consistency and clarity of requirements, it is useful to set up clear syntax rules that everyone can use. Marvin et al. developed an ‘Easy Approach to Requirements Syntax (EAR)’ system that can be quite useful to apply. Under this system, requirements take the following format:

the shall

To illustrate how that works in practice, see the below table.

Many requirements that may seem ubiquitous are really driven by some trigger or condition. For example, the requirement:

The system shall monitor the pressure sensor and display a red light within 0.2 seconds of exceeding the upper safe pressure limit.

 is written in the ubiquitous format. However, it is actually driven by an unwanted behaviour. Rewriting the requirement so that the trigger-response nature of the requirement is more clear results in:

If the upper safe pressure limit is exceeded, the pressure gauge shall display a red light.

Be sure to check all your requirements  for hidden triggers. Most true ubiquitous requirements are non-functional.

Mavin, Alistair & Wilkinson, Philip & Harwood, Adrian & Novak, Mark. (2009). Easy approach to requirements syntax (EARS). 317 – 322. 10.1109/RE.2009.9. 

Requirements Content

When writing requirements, you should consider whether they are ‘SMART’

SMART Requirements are:

• Specific – target a specific area for improvement.
• Measurable – quantify or at least suggest an indicator of progress.
• Assignable – specify who will do it.
• Realistic – state what results can realistically be achieved, given available resources.
• Time-related – specify when the result(s) can be achieved.

This ensures that requirements can be consistently interpreted by designers and can be easily tested to determine the design meets the requirements.

Another consideration is: ‘to what level of detail do I need to define my requirements?’

This can be very difficult to figure out. Too much detail is quite a burden on those developing and maintaining the requirements and too little results in designs that are not acceptable and can cause problems later if designs are not fully tested.

Consider making requirements as non-specific as possible while still ensuring that if you were to outsource this aspect of design to another party, they would still provide you with a design result that would be acceptable to you.