• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • COMPANY
  • PRODUCTS
  • HEICON BLOG
  • English
    • Deutsch
    • English
  • Menu Menu
You are here: Home1 / A_Requirement Engineering2 / Requirement Engineering – Aspects which even not considerd in theory!...

Requirement Engineering – Aspects which even not considerd in theory!

A_Requirement Engineering

Requirement Engineering theory: In most of the requirement engineering publications, the focus is on management aspects. The collection and management of requirements is discussed extensively. In the following blog I discuss important aspects which are not sufficiently considered in the RE theory. I start with the definition of Requirement Engineering in the book “Requirements Engineering Fundamentals” (Klaus Pohl, Chris Rupp).

Requirement Engineering theory – Overview:

Klaus Pohl and Chris Rupp define Requirement Engineering as follows:

Requirement engineering is a systematic and disciplined approach to the specification and management of requirements with the following goals:

  1. Knowing the relevant requirements, achieving a consensus  among the stakeholders about these requirements, documenting them according to given standards and managing them systematically
  2. Understanding and documenting the stakeholders’ desire and needs, they specifying and managing requirements to minimize the risk of delivering a system that does not meet the stakeholders’ desires and needs

Klaus Pohl und Chris Rupp identify four main tasks which need to be performed:
Elicitation, Documentation, Validation and negotiation, Management.

Requirement Engineering in the development of safety critical systems:

In the development of safety critical systems there is always a system break down. Firstly, the entire system with its interfaces to the outer world will be described as a black box in system requirements.

The architecture is then defined for the system. The functions of the blocks created in the architecture are then again described in the form of black-box requirements. An important criterion is the separation between SW and HW requirements. As most of the functionality is usually implemented in SW, there may be additional functional blocks in the software.

The resulting SW and HW requirements are then linked with the system requirements. This creates a continuous traceability which makes the system break down transparent and comprehensible.

Conclusion:

The system break down described supported by Requirement Engineering is an essential aspect in every development of an embedded system. This step is also very important for the verification of many robustness aspects.

Klaus Pohl and Chris Rupp discuss this subject in chapter 8.2 Views on Requirements and 8.4 Traceability of Requirements in the IREB standard book. The engineering aspect of this subject is, however, clearly too short. In practice, you sometimes face rather complex challenges when you want to create the right requirements at the various levels and then trace it properly. All these aspects can only be solved with engineering techniques and not with the management of requirements.

In this sense, I see the definition of Requirement Engineering as incomplete. In addition, the example also shows that there are important differences between IT software and embedded software development. It is therefore time that the Embedded Community also start writing books about Requirement Engineering. The variability of HW interfaces, the programming of embedded operating systems and the proof of a 100% structural code coverage have important implications for the requirements engineering, which are currently not really considered in the standard requirements engineering methods.

Related HEICON Blog posts

  • Requirement and Test Traceability – Any added value?
  • Requirement Engineering Embedded versus IT systems
  • 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.

3. October 2017/0 Comments/by HEICON Global Engineering GmbH
Tags: Derive Requirements, Development process, Functional Requirements, Functional Safety, Requirements, Software Engineering, Software Requirements, System Break Down, Traceability
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
https://heicon-ulm.de/wp-content/uploads/2020/08/DI1A6236_klein_Requirement_Eng.jpg 475 684 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2017-10-03 20:31:462021-02-02 21:54:45Requirement Engineering – Aspects which even not considerd in theory!
You might also like
RailwayEN 50128 configurable Systems – The solution?
Validation and VerificationStatic analysis and dynamic testing: What are the strengths and weaknesses?
IndustrialSpecification Architecture Requirement in IEC 61508; Is there any difference?
Requirement EngineeringEconomical considerations on requirement reviews!
Requirement EngineeringUser Stories – The better Requirements?
Functional SafetyTool qualification – The pain of functional safety (part 2)!
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Categories

  • A_Requirement Engineering
  • B_Validation and Verification
  • C_Config- / Change Management
  • D_Security
  • FuSa__General
  • FuSa_Aerospace
  • FuSa_Agriculture
  • FuSa_Automotive
  • FuSa_Industrial
  • FuSa_Railway

Contact

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Phone: +49 7353 – 98 17 81
Mobile: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRINT  |  DATA PROTECTION

Compiler for safety critical software – What needs to be done?Functional SafetyRequirement EngineeringRequirement Engineering Embedded versus IT systems
Scroll to top