• 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 and Test Traceability – Any added value?

Requirement and Test Traceability – Any added value?

A_Requirement Engineering

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.

Traceability and audits

Nevertheless, it is found in the audit that many software requirements, are somehow related to the linked system requirements, but an integrated traceability strategy is not recognizable. If it is then determined in further audited examples that some aspects of system requirements are not implemented in the software (or hardware) the audit starts to be stressful. Requirement and Test TraceabilityAfter this situation, you may also start thinking about the time and money you spent to achieve a good Requirement and Test Traceability. You almost inevitably raise the question now, what is the justification for the use of tools and engineering time, if the result is such poor. You may start thinking about a drastically reduction of time and effort in this area in the next project.

“Everything” to “Everything” traceability

However, instead of doing this, you should start a root cause analysis, to identify the real issues. Basically, the use of tools is very useful and there is also a significant added value if you do traceability correctly.
A major cause of the problems described is often the linkage of “everything” to “everything”, as a substitute for the use of a project-specific traceability strategy.
In former times, when there was no convenient tool support, in the creation of traceability, this problem just did not exist. The effort to create such traceability was far outside any acceptable range. Because of this fact, the projects were forced to make very intense thoughts about the following challenges:

  1. Which results of the Hazard and Risk Analysis are implemented in which requirement(s)?
  2. What are the software requirements which implement (really!) the considered system functionality (= System Requirements)?
  3. Which Software Requirement is not derived from any system requirement, but arises as a consequence of architectural decisions and should therefore remain (=no link to another functional Requirement) as “Derived” Requirement?
  4. Which source code can not be derived from functional requirements, but (e.g.) from the interface to the hardware?
  5. Which source code occurs, for example due to applied principles as Defensive programming and not on the basis of functional requirements?
  6. What tests actually verifies which requirement, really?
  7. In which architectural block which requirements are implemented?

This list of questions does not claim to be complete.

But it forms a good starting point if you want to achieve a useful traceability.

Thanks to the support of modern and innovative Tools it is today much easier to put the individual artifacts in the software development process in an useful relation (Traceability) to each other. There are a variety of database-driven tools that reduce the complexity and the error rate for the traceability creation significantly. If you additionally make yourself aware of the issues described and you develop appropriate solutions, you are on the way to achieve the desired added value.

Traceability benefits:

  1. Very effective mean to assure that the customer’s requested product was built accordingly.
  2. Easy and quick navigation from the System Requirements to the Source Code/Hardware Implementation
  3. In case of changes, effective support of required analysis to avoid unintended side-effects
  4. Support / simplification of the completeness check with respect to the product implementation
  5. Support / simplification of a completeness check with respect to the product verification
  6. Good mean to track the implementation and verification progress

Releated HEICON Blog posts:

  • Requirement Engineering – Aspects which even not considered in RE theory!
  • Structural source code coverage and Requirements – Is there any dependency?
  • DO-178B/C, ISO 26262, IEC 61508: How many level of Software requirements are necessary and 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.

 

6. December 2019/by HEICON Global Engineering GmbH
Tags: DO178, EN50128, EN50657, IEC 61508, ISO26262, Links, Requirements, Software Engineering, 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 GmbH2019-12-06 20:48:162021-02-02 21:52:38Requirement and Test Traceability – Any added value?
You might also like
AutomotiveISO 26262 Freedom from interference – What is that?
AutomotiveReuse Scenarios in ISO 26262 (part 2)
AutomotiveFault Injection Test in ISO 26262 – Do you really need it?
RailwayEN 50128 Functional Safety in the railway industry
RailwayEN 50128 and EN 50657 support tools
RailwayEN 50129 Safety Case

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

ISO 26262 ASIL Decomposition – Pros and Cons!AutomotiveAutomotiveISO 26262 Safety Case – Success factors: management and traceability!
Scroll to top