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
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
Carrying out a data- and control flow analysis is required in almost all functional safety standards (ISO 26262-6 Table 7 Measures 1f/g, DO 178C Table A-7 Measure 8 and EN 50128, EN 50657Table A19 Measures3/4). In comparison to other measures, the data and control flow analysis causes a lot of questions, when it comes to the real execution. This is mainly since the technological capabilities have so far been lacking to carry out such an analysis.
The new non-intrusive system observation technology (www.accemic.de) offers the possibility to prove data- and control flows by tests. Therefore, a systematic check can be performed in future to prove the functional completeness of the 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 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
If a project getting difficulties with writing requirements, there is Test Driven Development (TDD) often referred to as the solution. Is that really the solution? If so, why TDD has not really become widely accepted in the software development up to now? In this blog I will express my thoughts about this topic. Read more
Quality costs money! Many can probably agree with this statement. Anyway, it is difficult to refute the statement, as it is very generic.
At the same time very often the simplistic conclusion is drawn, that any quality measure within the software development process is just expensive.
I want to take a closer look with the following blog. As an example for quality measures I will take the requirement review. These reviews are required by all the functional safety standards. Read more
In my daily projects in the automotive and industrial automation industry I’m continually confronted with the following question: How many levels of software requirements have to be written? That’s an interesting question, especially if we take the aerospace industry also into account. Software requirement level are a key topic if you want to improve your requirement engineering process. Therefore, I want to highlight in this blog post this topic a bit closer. I will compare the specifications of functional safety standards IEC 61508, ISO 26262 and DO-178B / C. In the final conclusion I will provide project best practices based on my more than 15 years of experience.
In my view, a good software specification is divided into two major parts: architecture / design and textual requirements.
The architecture describes, most predominantly in graphical form, the structure and design of the software. In particular, the data and control flows are shown. The focus of textual requirements is on the description of the functionality, and the time demands on the system.
The initial question of this blog refers to the number of levels of textual requirements. Not included is the level of system requirements, which must always be present. Read more
You want to start a new project, the product to be developed is already set in broad terms. You decide that now is the right time to structure these rough ideas, functions and solutions and to write it down. This point in time and the questions that arise now are subsequently examined in more detail. Typical questions and thoughts that you might think about:
- Are requirements nowadays recorded in writing?
- Do textual Requirements imply heavy processes and thousands of pages of documents that anyway nobody reads or understands?
- A picture tells you more than 1000 words!
