How Detailed Should A Safety Critical System's Software Requirements Be?

Foreword

There is no arguing that software requirements engineering is one of the most critical aspects of designing a robust and safe embedded system. However, its also very likely that during the development of such a system, one or both of the following two questions would have triggered some heated discussions within the software engineering teams.

"These requirements are too vague. There isn't enough detail in these requirements to implement the intended functionality"

or

"These requirements are too detailed. These are design details and must be kept out of requirements"

How must then requirements engineers get the balance right?

SWE.3 - BP5 for ASPICE recommends establishing bidirectional trace between software requirements and software units. At the same time it also recommends the bidirectional trace between software detailed design and software units; which implies that according to the standard that not all details are expected to be specified in software requirements, but at the same time some details could be. To avoid redundancy, its left to individual engineering teams to work out what to trace implementation to:- requirements or design. So, which is it? What should guide the software engineers? Should the software requirements be detailed enough to specify implementation details or should the requirements leave the implementation details out assuming them to be worked out as part of software detailed design?

This article will attempt to clarify this aspect of software engineering; at least for requirements engineers involved with Automotive Safety Critical embedded systems design and development.

Software Requirements Engineering

To understand the need for requirements to be very detailed, it is critical to identify and differentiate between software functional / non-functional requirements and software safety requirements during requirements engineering phase of a automotive embedded system.

As a general rule, this article recommends that if a software safety requirement derived out of software safety analysis (for example, software FMEA) is trying to deploy a safety mechanism to mitigate the violation of a safety goal by the system, then the said software safety requirement must contain all the critical design details of the implementation.

If the requirement is rather a functional / non-functional one, it may be acceptable to leave the software requirements at a sufficiently high level to describe over all behaviour and/or performance of the module rather than get into detailed functionality. But again, this will depend on the exact feature being implemented and it sometimes helps to specify details to avoid writing vague requirements.

Clearly the requirements flowed down to software team from Systems team also play a part of how detailed software requirements will be. For example, if the systems software requirements(SYS.3) are sufficiently detailed, the software requirements(SWE.1) cannot be less detailed than the systems requirements they are linked to. How high level should systems requirements be and what kind of details should be specified in functional and technical safety requirements is a different topic and will not be covered in this article. Instead, this article will look at an example where a system level functional and technical safety requirement is flowed down to software team to derive software functional and safety requirements.

Example

Lets take a simple example of Electric Power Steering(EPS) software design and consider two cases where in one case(Figure 1), it will be made clear that design details must be included in software requirements while on the other(Figure 2), design details are better left to be worked at software detailed design stage.

Some general back ground information to understand the context of the example before we dive a bit deeper:-

First, Vehicle Speed received over CAN is critical in determining the assistance delivered by the EPS system for a given driver torque being applied at the hand wheel. In general, less assistance needs to be delivered at higher vehicle speeds and most features implemented in the EPS software are tuned to meet this.

Second, one feature typically part of EPS software is something called "Self Centering Assist". This feature aids the normal mechanical tendency of the front wheels to come back to straight ahead orientation when one lets go of the steering wheel. In its simplest form, this is done by adding a vehicle speed dependent torque towards the straight ahead position when the vehicle conditions are right.

EPS itself is classified as an ASIL-D system and hence has appropriate safety goals to meet. Note: The example safety goal and requirements quoted in Figure 1 and Figure 2 are mainly to help with the understanding of when it is mandatory to provide design details in software requirements and when its not. The technical details and correctness of the EPS requirements themselves are not the subject of this article.

Figure 1: Software Safety Requirements with SW Design Details

Figure 2: Software Functional/Non-Functional Requirements with Design Details left out

Final Word

Where software safety requirements are being specified, all critical design details of a given safety mechanism must be included in software requirements. This will of course result in long re-work loops if the implementation needs to change. For example, a change to even the software calibration parameter specifying the low pass filter constant in Figure 1 will potentially require a software FMEA update followed by requirements update. But this is expected as not controlling the filter constant at software requirements level may result in the product violating the safety goal. This approach is consistent with ISO26262-6 where all design details and test methods specified must be requirements driven. The approach should also satisfy ASPICE where all software design details and unit test cases directly link to software safety requirements.

At the same time, as with Figure 2 if there is no safety requirement driving the implementation, software requirements engineers must try and achieve a balance such that the requirements do not get into design detail. This will avoid long re-work loops and un-necessarily constraining the software design. In such cases, ASPICE can be complied with by tracing software implementation and unit test cases to software design instead of a direct link to software requirements.

Nevertheless, the two questions quoted at the beginning of the article will continue to be asked and all the heated discussions will continue to happen within software engineering teams; but hopefully this article puts an argument forward to at least keep software safety requirements out of those discussions.