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.
Lorit lead consultant and owner, Alastair Walker

To find out more about requirement notation, ISO 26262 or IEC 62304, please join one of our training courses.

Send us your inquiry to

Learn more

Using this syntax supports a consistent approach to requirements definition. Not so easy is managing teams such that this is applied across the board, but there many organizations which use this strategy or similar strategies very successfully.

Consistency checks on requirements is also an inconsistent topic across the world of international standards! More focus is placed on requirements attributes in the world of software, than at systems or hardware level (ISO 26262 and IEC 62304 as examples), but this is perhaps more in focus due to the potential systematic faults being the results of poor software definition. Hardware and systems have additional concerns over and above systematic faults.

Functional or non-functional requirements

Also, a topic that often leads to numerous discussions, is that of functional against non-functional requirements. Functional requirements define what the product shall do. Non-functional requirements specify the criteria to enable the achievement of the functional requirements, so to speak the ‘how’. Non-functional requirements define criteria such as usability, effectiveness, scalability etc.

If functional requirements are not compliant a system or product may deliver incorrect output. If non-functional requirements are not implemented correctly the system or product may not deliver the output at the correct rate or with the appropriate quality.

Many international standards do not focus on the difference between the two types, as at the end of the day all requirements need to be appropriately implemented.


Ultimately, simplicity and consistency in the approach to any subject, help reduce potential errors just as coding guidelines for software teams help to reduce the diverse style of code implementation.

Using standard notation in generating requirements helps to reduce the number of requirements flaws, provided the requirement content is appropriate.

Look out for our new requirements management course in 2024, where we will present topics covered in the last 2 blogs, plus many more.

By Alastair Walker, Consultant & Owner

If you would like to join one of our training courses covering a variety of safety related topics, take a look at our offerings . For these and our new Requirements Management course, please do not hesitate to contact us at



We look forward to hearing from you.

    Show privacy policy