Are your requirements functional?

The challenges of requirement definition

In the first part of this blog we looked at traceability of requirements and how it is handled in the automotive, aviation and medical device sectors. In this second part of the blog we look at notation and the difference between functional and non-functional requirements.

Consistency is the name of the game, but sometimes this can in larger teams be more challenging if there is not a clearly defined set of rules. In this blog we look at techniques that can support a consistent definition or requirements

Requirement notation

Most of us are used to reading international standards und over the years many have adopted a set of rules to define what is mandatory or what is a recommendation for clauses in the standard. Standards such as IEC 62304 for the medical device or the technical specification IEC TS 62443 for Industrial communication network security provide definitions of ‘shall’, ‘should’ or ‘may’. Interesting is that different standards and technical documents use the terms in differing ways. ‘May’ in IEC 62304 is used to describe a permissible way to achieve compliance with a requirement and in IEC TS 62443, ‘may’ is used for advice that is optional.

The point above is not surprising as standards are written by different committees and with different participants all with their respective views.

However, within a company or organization with the same team or teams, consistency can be achieved across processes, specifications and above all requirements. The examples of ‘shall’, ‘should’ and ‘may’ is though, a simpler example than that of capturing consistency in requirement definition.

One very helpful strategy championed by Jama Software is the Easy Approach to Requirements Syntax (EARS) notation, developed by Alistair Mavin.

As a strategy very helpful in producing well defined and consistent requirements. The syntax is based on 6 keywords – shall, while, when, where, if and then. They are used to define 6 requirement structures:

1. Ubiquitous requirements – The ECG recorder shall have a mass less than 200 grams.
2.  State driven requirements – While there is insufficient charge in the battery the car dashboard shall display battery low.
3. Event driven requirements – When mute is selected the radio shall suppress all audio output.
4. Optional feature requirements – Where the blood pressure meter has more than one cuff size the LCD shall display the actual cuff size.
5. Unwanted behavior requirements – If an invalid password is entered then the LCD shall display, please re-enter the password.
6. Complex requirements – While the aircraft is on the ground, when reverse thrust is commanded the engine control system shall enable reverse thrust.