• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • COMPANY
  • PRODUCTS
  • HEICON BLOG
  • English
    • English
  • Menu Menu
You are here: Home1 / B_Validation and Verification2 / Structural source code coverage and Requirements – Is there any depend...

Structural source code coverage and Requirements – Is there any dependency?

B_Validation and Verification

If you are newly engaged in the area of functional safety, then you will encounter fairly quickly the terms “structural source code coverage” and “requirements”. The specification of technical systems by requirements is, of course, also common in non-safety-critical areas. By contrast, the subject structural source code coverage is almost unknown outside safety-critical projects.
In this blog I want to discuss these two methods and the underlying processes. In particular, the question of inter-dependence is exciting.

Structural source code coverage:

The structural source code coverage is a measure of the degree of coverage of the source code by tests. There are different levels of coverage defined. Usually you start with the coverage of the executable source code lines. This means that if every line of code has been executed once, then you have reached 100% coverage.
With the famous MC/DC Coverage it is demonstrated that within a condition each parameter has an effect on the result of the decision. The minimum number of necessary test cases is the number of variables in a decision +. 1
The figure below shows different types of coverages:

Coverage_1_eng Coverage_2_eng

Requirements Engineering:

Good functional requirements describe the behavior of a system under defined conditions. Functional requirements therefore provide ultimately the reasons for the implemented source code.
“Wait a moment!”
In the first sentence the term “system” is used. In the second sentence “the implemented source code” is used. Is there not a contradiction?
“Yes!”
This is a contradiction! With requirements, describing the system behavior, it is in many cases impossible to understand directly, a specific functional implementation in the software. This is so far still not a problem, since, software requirements should be derived from the system requirements. All standards of functional safety demand at least these two levels of requirements.
The requirements for the software should then provide the traceability to the implemented source code? Unfortunately, there are a lot of practical cases, where this traceability is not there. The reason for this is the ever-increasing complexity of software. The software architectures are becoming more complex in order to control the increasing functional complexity.
This has the unpleasant effect that in a lot of cases it is not even possible to trace from the software requirements to each function of the source code.
Since the structural source code coverage, should be measured based on the requirements based tests, a lot of projects tend to define at least one more level of requirements.
Now we have found the point at which the structural source code coverage influences the requirements engineering and vice versa.
According to my observation, the need to achieving 100% structural coverage increases the number of requirement levels in a lot of projects.

Conclusion:

The aerospace industry accumulated already 30 years of experience with 3 levels of requirements (system, high-level and low-level SW SW). These levels are even explicitly specified in the standard. The experience here is that there are very few projects, which have found a good balance between the different requirements levels. The aerospace industry demands also the achievement of 100% structural source code coverage.
Nevertheless, the creation of the third level of requirements, the low-level software requirements, is very complex and expensive. There are many projects where the benefit is quite doubtful.
Therefore, before you want to solve the problem, by creating 3 or more level of requirements, take a closer look on the problem. In most of the cases a thoughtful strategy, both for drawing up the requirements as well as for the test strategy to achieve the source code coverage, is clearly more productive and cost-effective than simply increasing the number of requirements.

Are you ready for a status workshop, to analyse improvement potentials in your test engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.

27. July 2016/0 Comments/by HEICON Global Engineering GmbH
Tags: Fuctional Safety, Functional Requirements, Structural Coverage
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
https://heicon-ulm.de/wp-content/uploads/2020/08/DI1A5942_klein_VV_Eng.jpg 431 553 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2016-07-27 13:30:412021-02-03 21:25:44Structural source code coverage and Requirements – Is there any dependency?
You might also like
Functional SafetyStructural Source Code Coverage – Cost without benefit?
Validation and VerificationImplicit Testing – A good idea (Part 1)?
Comparison and evaluation of different test design techniques.
Requirement EngineeringUser Stories – The better Requirements?
AerospaceRTCA DO 331 Model-Based Development and Verification in aerospace
Validation and VerificationImplicit Testing – A good idea (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

Security – A term that has many meanings!SecurityRequirement EngineeringEconomical considerations on requirement reviews!
Scroll to top