Englische BlogsRequirements Engineering eng

RE for embedded and IT systems – It’s time for the embedded community to become aware of the differences!

Requirement Engineering

If you analyses the book market, publications or conferences on requirements management and engineering (RE), you will find that more than 90% consider requirements engineering from the point of view of IT software systems. There are very few publications that look at the topic from the perspective of embedded systems. On the one hand, it is the great success of some pioneers in IT development that procedures for the RE have been discussed and established in the last 20 years. On the other hand, it leads to problems in the development of embedded systems, because these procedures are adopted without consideration.

Differences between IT systems and embedded systems

The following table shows some significant differences between Embedded and IT Systems:

Embedded Systems IT Systems
Many, specialised HW Interfaces Only standardised HW Interfaces
Random HW Failure will be checked by Software Random HW Failure are not treated
Big Data is no topic Big Data is one of the future topics
HMI Interfaces are rarely used HMI Interfaces are very often used
Security is a new topic Security topics are treated very well

Points 1 and 4 of the above list are significant for RE.

HMI-Interfaces

The topic of HMI-interfaces (point 4 above) plays a minor role in embedded systems. In IT development it is a central point that is often important for the overall quality of the product from the customer’s point of view. The creation of a valuable specification for a system with such an interface is complex. In fact, a whole special field has been created in the RE, which only takes care of this topic – usability engineering. However, there are only a few embedded systems where this point would be relevant. If you look at the safety-relevant systems, the number of systems is negligible.

Specialized HW-Interfaces

The exact opposite is handled in the first point in the above list. Embedded systems are characterised by the fact that they are developed for a wide variety of hardware. In contrast, the HW interface for IT systems is of practically no importance. In IT, the hardware is standardised and changes relatively rarely. For application software, the widely used and standardized operating systems such as Windows, are providing the HW interface layer.

This does not apply to embedded systems. Almost every system has different hardware interfaces that it needs to operate. Although operating systems are also used in embedded development, they are by no means as standardized as in the IT world.

For the specification of embedded systems this means that without a hardware-software interface specification, good and complete functional requirements cannot be created. Practical experience shows that if the wrong approach is adopted, the effort for RE can increase dramatically. The following two points are decisive here:

  • Separation of functionality and interface aspects
  • Traceability between Interface Requirements and Functional Requirements

Which conference or publication provides answers to such points? I don’t know anything about this place!

Further points which are success critical for embedded RE systems

The situation is very similar with the following points, where embedded and IT development differed markedly:

  • Level of Requirements (System, HW and SW)
  • Individual customer project, instead of business analysis (the role of the customer is clearly different!)
  • Requirements of the functional safety standards have a great influence in the embedded area
  • Quality requirements for the product (non-functional requirements)

Conclusion

If the embedded community wants to sustainably improve the effectiveness and efficiency of Requirements Engineering, it is time to make the existing knowledge about the above-mentioned points available to the general public! The RE pioneers in the embedded community play a key role here!

I’ll be glad to help you also with any specific questions about your project. The HEICON Starter as well as the HEICON Consulting products are designed to solve such open points.

Send an email to: info[at] heicon-ulm.de!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.