In my daily projects in the automotive and industrial automation industry I’m continually confronted with the following question: How many levels of software requirements have to be written? That’s an interesting question, especially if we take the aerospace industry also into account. Software requirement level are a key topic if you want to improve your requirement engineering process. Therefore, I want to highlight in this blog post this topic a bit closer. I will compare the specifications of functional safety standards IEC 61508, ISO 26262 and DO-178B / C. In the final conclusion I will provide project best practices based on my more than 15 years of experience.

In my view, a good software specification is divided into two major parts: architecture / design and textual requirements.
The architecture describes, most predominantly in graphical form, the structure and design of the software. In particular, the data and control flows are shown. The focus of textual requirements is on the description of the functionality, and the time demands on the system.
The initial question of this blog refers to the number of levels of textual requirements. Not included is the level of system requirements, which must always be present.

IEC 61508:

IEC 61508 defines in part 3, Table A1 one level of requirements. Whereby it is very interesting that in the recommended procedures and measures for semi-formal methods, no measure for writing textual requirements is mentioned. A reader of the standard could get the impression that textual requirements have not been considered by the team which wrote the IEC 61508.
Thus, according to the IEC 61508 a maximum of one level of textual software requirements needs to be prepared.

ISO 26262:

The software process described in part 6 of ISO 26262-2011 calls in chapter 6 “Specification of software safety requirements”, the creation of one level of requirements. In Chapter 8 “software unit design and implementation”, Table 7 “Notations for software unit design” natural requirements are proposed as a possible method. The recommended measure is “natural language requirements for the description of the software units”. Other methods can also be chosen instead: “informal notations”, “semi-formal notations” or “formal notations”.
The ISO 26262 therefore requires for the software definitely one level of requirements. A second level of textual requirements can be created but has not alternative methods are also allowed instead.

DO-178B/C:

The aerospace standard DO-178B / C clearly defines two levels of textual requirements (Table DO-178, A2). These are defined as high-level requirements and low-level requirements. Accordingly, the creation of two levels of requirements (at least for the more critical projects (DAL A, B, C)) has to be established.

Software requirement level best practice:

For a DAL A, B or C project in aviation, you have no choice, it have to be two levels of software requirements created. However, taking the definitions in ISO 26262 and IEC 61508 into account, I also want to make the following conclusion. In the automotive and industrial automation industries one level of textual requirement is sufficient! Particularly in projects where the scale and complexity of the software are limited! Instead, the efforts should be spend to manage one level of software requirements properly. Aviod trying to establish a second level of requirements!

Decades of experience in aerospace industry generally shows that the second level of requirements have their place. The requirements are called Low-Level Requirements. But these projects are very large or at least they are complex! At the same time it must also be noted critically that it is very costly to write these requirements. Experience shows that it is very difficult in many projects, in practice, to write good, textual Low-Level Requirements. Usually they are either too detailed, which means often Pseudo-code with too many unnecessary details, or they are too abstract, so that they are not testable, although they are supposed to describe the lowest level.

Conclusion:

In my experience, one level of requirement is sufficient in most projects in the automotive industry and industrial automation industry. The project should rather concentrate on this level of requirement in order to create good, testable, clear and complete requirements, than to put the effort in often not technically founded two levels of requirements.

However, it should be mentioned also that often the need to evaluate the structural code coverage means that people thinks several levels of requirements are required. This is surly true for complex projects. Equally it is true as well, that for more than 50% of the projects that I’ve seen so far, the complexity was not as high that the argument of the code coverage would be sufficient to define a second level of requirements.

Are you ready for a status workshop, to analyse improvement potentials in your requirement engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.