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
Tag Archive for: Traceability
Static analysis and dynamic testing: Even after several decades of software engineering, we still far away from guaranteed error-free software. Even for software developed to the highest safety standards, no one can guarantee absolute freedom from errors. All functional safety standards recognize that a guaranteed error-free software (with the current state of the technology) cannot be achieved. The measures in the standards have the goal to minimize the number of errors and to detect occurring errors in time to prevent a serious error effect.
The static analysis and dynamic testing represent two such measures. Especially in safety-relevant systems, the use of both measures is required, although in some cases the same errors are found.
Extensive validation, verification and testing is associated with high costs. In most projects this leads to a high pressure to develop an optimized test strategy.
A prerequisite for successful test optimization strategies is the comprehensive understanding of strengths and weaknesses of static analysis and dynamic test and analyses. The following article provides a basic overview of the topic.
The EN 50129 safety case is the structured and documented safety statement that the conditions for safety acceptance have been fulfilled. The safety case includes all safety-relevant aspects of the product life cycle. When creating the document, the challenge is therefore to present a wide range of information in a clear and comprehensible manner. EN 50129 supports you in this by providing a relatively detailed structure for the documentation.
In the following article, I will deal with the key factors relevant to practice for an EN 50129 compliant safety case. Read more
The term Safety Case is used in the automotive industry and railway industry (EN50129). The following article focuses on the automotive industry. Project experience shows that the achievement of a proven functionally safe system is complex and extensive. This is particularly true if the development of a product is spread over several companies. I will discuss the key factors to achieve the safety case objectives named in ISO26262.
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 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
