Requirement Engineering Embedded versus IT systems
Requirement Engineering Embedded versus IT: If you analyses the book market, publications or conferences on requirements management and Requirement Engineering, 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.
Requirement Engineering Embedded versus IT – Differences
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.
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.
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 Requirement Engineering 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)
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!
Related HEICON Blog posts
- Requirement and Test Traceability – Any added value?
- Requirement Engineering – Aspects which even not considerd in theory!
- User Stories – The better Requirements?
- Requirement/Code Reviews – The better TDD?
- Economical considerations on requirement reviews!
- Are you still writing documents or are you already specifying?
- Non-Functional Requirements – A challenge?
- Requirement Categories – Why they are useful?
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.
Leave a ReplyWant to join the discussion?
Feel free to contribute!