Tracing requirements and source code

In the last month, our team behind YAKINDU Traceability received a couple of questions regarding how to establish bidirectional traceability between requirements or design elements and software units a.k.a source code – as for example required in the Automotive Spice model. We also optimized the performance of our C/C++ adapter and therefore decided that it qualifies to be called “feature of the month”.

With YAKINDU Traceability, you can

  • recognize elements of the source code as traceable artifacts, e.g. files, functions, variables
  • create bidirectional trace links from source code artifacts to requirements, elements of your design, test-cases, etc.

You can configure whether trace links should be stored non-invasively (i.e. in an external file, leaving the source code untouched) or in the form of dedicated comments in the source code. If you decide to link by means of comments, YAKINDU Traceability is able to recognize and write the unique identifier of linked artifacts within source code comments. The following image illustrates how a trace link from a C-header file to the design element RainSensor [Component] which resides in an Enterprise Architect model becomes manifest in a comment.

Screenshot of YAKINDU Traceability showing how a trace link is set with a comment

The actual format of a comment can be configured freely. So for example in the case illustrated above, each link information within a comment is prefixed by „@SDD“. The image below shows an example configuration of YAKINDU Traceability which covers exactly this case:

Screenshot of YAKINDU Traceability Tool showing an example configuration that covers prefix of link informations within a comment

Depending on whether you link requirements or test cases (or both), YAKINDU Traceability can easily calculate the progress of your project or the source code implementation as it measures coverage of requirements by software units or test coverage at ease. For example, the gaps on the left side of the following sheet show missing trace links from elements of the Software detailed design to Software units which already exist.

Table of covered YAKINDU Traceability artifacts

Having a coverage report in mind, it is important to decide on which detail level you want to trace to source-code-artifacts. Do you want to link from requirements to complete source code files (e.g. to translation units in C)? Is it necessary to trace to functions or variables within a file? There is a trade-off: The more fine grained you want to evaluate your traceability, coverage analysis, impact analysis etc, the more expensive your maintenance will be. Of course, the detail level of source-code traceability can be adjusted in YAKINDU Traceability. Our example is configured to trace on the level of translation units:

Screenshot of YAKINDU Traceability Tool showing configuration to trace on level of translation units

Concluding, I want to summarize the results of our performance-tuning. In a real-world scenario comprising about 1,300 C files with about 1,600 comments relevant for traceability, it took YAKINDU Traceability about nine seconds to analyze these files and to recognize artifacts and links.

Please find more information about YAKINDU Traceability on our website.

Learn more about YAKINDU Traceability

Share this blog post

    

About The Author

I've been working as (technical) project manager in several business domains. I like the power of language engineering and every other application that makes development easier and improves quality. Since 2014, I'm in charge of YAKINDU Traceability.