Many books have been written in the last 30 years on the subject of requirement engineering. The method has been designed and improved. The great success of these efforts lies in the fact that the awareness of the topic has been raised in a broad professional audience. There is hardly anyone today who would fundamentally deny that requirement engineering is useful for embedded systems and IT systems. On the other hand, it can also be stated that the practical implementation of requirement engineering in projects still has significant shortcomings. This is where the following article starts. On the basis of some selected topics of requirements engineering I show differences between the requirements in the method description and the needs in practice. Possible solutions are indicated but are not part of this article. Here, it is “only” a matter of sharpening the awareness of the problem. Read more
Posts
Requirement and Test Traceability: Think about the following situation: You are near the end of your safety-related project and you have established traceability between all the project artifacts.
In an audit (e.g. Internal Quality Assurance, Customer, External Authority) you have to demonstrate which software requirements are developed from which System Requirements. Each software requirement is linked to one or more system requirements and also any system requirement is linked to one or more software or hardware requirements. Read more
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. Read more
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). Read more
The compiler is the central “tool”, which is required for every software development. It forms the link between the human-readable high-level source code (e.g., C and C ++) and the machine code, interpretable for the hardware processor. For the development of safety critical software according to relevant functional safety standards special requirements apply for the tools used during the development. (Refer to tool qualification blog 1 and blog 2) Such functional safety standards are ISO26262 (car), EN50128 (rail), IEC61508 (automation, general) or DO178C (aerospace). The compiler plays a special role here. On the one hand, it is the central tool for any development. On the other hand, the measures proposed in the standards can not be fully applied in practice. The blog shows a process from the aerospace industry how to use compiler for safety critical systems. This process can highly be recommended for other industries. Read more
IEC 61508, ISO26262, DO 178C, ISO 25119: Have you ever encountered these abbreviations in your professional life? If so, there is a high probability that you are already implementing functional safety projects in your company or that you are entering the market in the near future. Perhaps you have already made the experience, or at least, heard of the fact that especially software projects in the field of functional safety can only be carried out with very high documentation / test effort. The safety development process requires this effort. In addition, such projects are very rigid, inefficient, and inflexible. Is such an argument or experience known to you? Read more
In the first part of the blog I defined the term Implicit Testing and discussed root causes for the need of implicit tests. Now, in the second part I will focus on the disadvantages of such tests and on possible solution approaches with the goal to avoid these disadvantages. Read more
In larger safety-critical projects, quite often I hear the following statement: “Well, the Requirement A is indirectly or implicitly proven with the test XY!” Do you know this sentence as well? Have you ever experienced what can happen in late project phases when you have tested many requirements indirectly?
The blog defines the term in part 1 and it discusses the causes of implicit testing. Read more
The book “User Stories” from Mike Cohn (ISBN 978-0321205681) has inspired me to think about the relationship between user stories and requirements. In software development, agile methods are often preferred in recent years. The classic approaches, especially the waterfall model and the V-model, seem to be more and more outdated.
As a result, user stories are preferred more and more. Do user stories really help to deliver better software quality? Read more
Specification Architecture Requirement : For an increasing number of systems in the industrial automation functional safety requirements must be fulfilled. The IEC 61508 compliance must be demonstrated for the software development.
On the other hand, there are commercial requirements which often severely limit the product development budget.
The solution lies in an efficient development process that meets the safety-relevant requirements. A prerequisite for a successful implementation of such a process is a deep understanding of the standard and a clear definition of used terms. In the following blog, I discuss the three terms Specification Architecture Requirement. Read more
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