If functional safety was declared illegal tomorrow and I could only keep one thing from the functional safety standards, it would be requirements management. Of course, requirements management predates functional safety but to put it another way, in my opinion, there is no point in worrying about functional safety if you don't have good requirements management.

In fact, data from the HSE in the UK suggests that almost half of control system failures are due to issues related to the specification i.e. the requirements of a control system.

Figure 1 Extract on sources of failure from the HSE in the UK

Requirements management according to IEC 61508 has two main aspects:

  1. Requirements for the individual requirements
  2. Requirements for the complete set of requirements

Each individual requirement needs to be:

  • Correct – technically and legally possible
  • Feasible – can be accomplished within cost and schedule
  • Clear – unambiguous and not confusing
  • Verifiable – it can be determined that the system meets the requirements
  • Traceable – can be uniquely identified and tracked
  • Abstract – does not impose a specific design solution on the layer below

While the set of requirements should be:

  • Complete – expresses a whole idea, all requirements are present
  • Consistent – no conflicting requirements
  • Unique – each requirement is only specified once
  • Modular – requirements that belong together are put close together
  • Structured – top down and traceable

Note - The most relevant sections of IEC 61508 to arrive at the above are part 1 – 7.5, 7.6 and 7.10. Part 2 7.2 and part 3 7.2, table A.1, C.2 along with part 7 elaborations. These IEC 61508 sub-clauses also remind you to include requirements related to integration, failure rates, and architectural requirements to meet the safety integrity requirements, EMI requirements etc. but the above guidance treats those as any other requirements. Also, for no good reason that I can think of, there are different rules in part 2 and part 3 so the above is an amalgamation that should help ensure you are compliant.

Writing a structured set of requirements however is actually a lot more complicated than you think when you try it for the first time. Having good templates to work with from a previous project makes it a lot easier. Many books show nice examples, and it all makes sense until you try it for yourself. The process is shown below with an example from the book Requirements Engineering showing how top-level requirements flow down to sets of requirements at lower levels. Most sources suggest that a higher-level requirement shouldn’t trace to any more than 10 lower-level requirements. In practice, this means that for a simple system with up to 10 requirements you can get away with only one level of hierarchy in your requirements. For a more complicated system with up to 100 requirements, you need two levels of hierarchy, for up to 1,000 individual requirements you need three levels of hierarchy, for up to 10,000 requirements you need four levels, etc.

Figure 2 - a nice V model from the book Requirements Engineering

The book Avionics Certification suggests you should have one requirement for every twenty lines of source code so that for even a modest amount of code you will need several levels of requirements.

For simple systems (one or two levels of hierarchy) you might be able to manage your requirements in Word or Excel but any more than that and you need a requirements management tool such as Jama or Doors.

Figure 3 - Requirement’s traceability

Requirement’s traceability is vital. Forward traceability allows you to take a requirement and see which code or hardware implements it. Backwards traceability allows you to see what requirement led to a specific piece of code or hardware. Aside from traceability’s use for development it also has uses during debug and deciding which features can be deleted from the requirements.

Why do I say traceability is vital? For instance, if your system implements a feature that doesn’t trace back to a top-level requirement then it shows your set of requirements is not complete or the engineering team has implemented an unexpected feature. If a top-level requirement doesn’t trace to low level requirements, then you clearly have an unsatisfied requirement and either the top-level requirement needs to be changed or extra features added to your system. Requirement’s traceability is an area where the requirements management tool takes away a lot of the hard work. Typically, such tools can spit out a report, such as a traceability matrix, showing problems with your requirements and their satisfaction. The Requirement’s Engineering book has an interesting story where this was done in a large room with one side of the room featuring a list of requirements, the other side of the room showing a listing of the code, with cords going between each side to show the traceability. If nothing else, it shows traceability can be proven without a tool, but it’s a lot of work to do.

Finally, we get to the main topic I wanted to discuss, which is the difference between requirements and specifications. Top level requirements should be technology and implementation agnostic. This leaves as much freedom as possible for the people who have to implement the hardware and software to choose the optimum solution to meet the requirement. Moving too quickly to the solution place is a well known product development issue. For me the eventually chosen solution is represented by a specification. Therefore, I find the terminology used in IEC 61508 confusing when it talks of “requirements specification”, “software requirements specification” etc. I think it would be clearer to talk about “sets of requirements” and then a “specification” or “technical specification” for a system designed to address the set of requirements. I think there might be an IEEE standard with good terminology, but I could not put my hand on it in time for this blog.

I have tried to capture this in the graphic below. Suppose ADI has to design a new IC. The black outside circle represents the universe of all possible IC that ADI could design including ADC, DAC, digital isolators, power management IC, CMOS vision sensors, Ethernet APL chips, accelerometers etc... However, the set of requirements represented by the four red lines indicates the subset of possible parts to meet the required set of requirements. Within that limited set of all IC that could meet the set of requirements the black dot represents the specification for an IC to meet that set of requirements. Other IC could also meet the set of requirements but perhaps for reasons related to cost or power we have decided on that exact solution.


Figure 4 - Requirements vs specifications

In effect the traceability between requirements and specifications is a one-to-many relationship. Which specification is chosen to meet the requirements is a design decision. Once an actual solution is chosen it becomes a one-to-one relationship.

The extract below from the book Product Reliability published by Springer represents some aspects of aspects of what I mean by the differences between requirements (which the authors call performance) and specifications.

Figure 5 - an extract from the book Product Reliability section 1.5.3

Section 3.4 of the book talks about having a “product design specification” which I also like rather than “requirements specification”.

For a book on product reliability, I was surprised to find such good details on requirements elicitation where for instance in section 3.2.1 it gives a definition of requirements as “that which is required or needed, a want or need” and then talks about customer requirements, corporate requirements, regulatory requirements, technical requirements and functional requirements and later constraints including financial, resource and time.

To learn more on the topic of requirements management see:

  • The book – Requirement’s Engineering – by Elizabeth Hull, Ken Jackson, and Jeremy
  • The book – Avionics Certification – by Vance Hilderman
  • The book – Product Reliability – by D.N. Prabhakar Murthy, Marvin Rausand, Trond Osteras
  • ISO 26262:2018 part 8 clause 6