Requirements Traceability [CALC1]

With the defined ‘needs’, their relations can be shown automatically, or some tables with relevant ones can be listed. Below you will find two examples, for Simple Calculator (CALC1).

A graphical view (“tree”)

This view shows the relationship between all kinds of specifications. It is fully automatically generated and will be updated when the specifications change.


' Nodes definition 

node "<size:12>Demonstrator</size>\n**Simple**\n**Calculator**\n<size:10>CALC1</size>" as CALC1 [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Simple+Calculator_CALC1]] #9DC5BB {
frame "<size:12>Requirement</size>\n**Generic Add**\n<size:10>CALC_ADD</size>" as CALC_ADD [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Generic+Add_CALC_ADD]] #C5EBC3 {
frame "<size:12>Requirement</size>\n**Generic Sub**\n<size:10>CALC_SUB</size>" as CALC_SUB [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Generic+Sub_CALC_SUB]] #C5EBC3 {
frame "<size:12>Requirement</size>\n**Generic**\n**Multiply**\n<size:10>CALC_MULT</size>" as CALC_MULT [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Generic+Multiply_CALC_MULT]] #C5EBC3 {
frame "<size:12>Requirement</size>\n**Generic Divide**\n<size:10>CALC_DIV</size>" as CALC_DIV [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Generic+Divide_CALC_DIV]] #C5EBC3 {
folder "<size:12>Test_Case</size>\n**Basic addition**\n**test**\n<size:10>CALC_TEST_ADD_1</size>" as CALC_TEST_ADD_1 [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Basic+addition+test_CALC_TEST_ADD_1]] #F6E27F {
folder "<size:12>Test_Case</size>\n**Big  addition**\n**test**\n<size:10>CALC_TEST_ADD_2</size>" as CALC_TEST_ADD_2 [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Big++addition+test_CALC_TEST_ADD_2]] #F6E27F {
folder "<size:12>Test_Case</size>\n**Subtract test**\n<size:10>CALC_TEST_SUB_1</size>" as CALC_TEST_SUB_1 [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Subtract+test_CALC_TEST_SUB_1]] #F6E27F {
folder "<size:12>Test_Case</size>\n**Multiplication**\n**test**\n<size:10>CALC_TEST_MULT_1</size>" as CALC_TEST_MULT_1 [[.._SystemEngineering_RequirementsTraceability_demo_demo1.html?highlight_Multiplication+test_CALC_TEST_MULT_1]] #F6E27F {

' Connection definition 



Lessons learned

  1. This graph clearly shows there are no tests for Generic Divide (CALC_DIV). This is easily overseen as there are four requirements and four tests defined.
  2. When the requirement Generic Add (CALC_ADD) changes, two tests might need an update.
  3. Likewise, for the other requirements, it is directly visual where the relations are.

This very simple demo has only one product with four requirements and a few tests. There are no product-variant, no product-increments (“new releases”) and no intermediate (or hierarchical) specifications. As a (deliberate) result, its Requirements Traceability is simple.
Still, its easy to forget a test; as I did. Did you noticed it?


The “forgotten test” is intentional in this first demo. It will be hot-fixed in the next chapter, and you will see it in the other graphs.

Therefore I had to use some “trick” in needs; see the notes about the forgotten test for more info.

The Requirements Matrix (table)

Some people prefer to see the same information in a table; again this one is automatically generated.

ID Type Title Incoming Outgoing
CALC1 demo Simple Calculator
CALC_ADD req Generic Add
CALC_SUB req Generic Sub
CALC_MULT req Generic Multiply
CALC_DIV req Generic Divide
CALC_TEST_ADD_1 test Basic addition test
CALC_TEST_ADD_2 test Big addition test
CALC_TEST_SUB_1 test Subtract test
CALC_TEST_MULT_1 test Multiplication test


For now, ignore the links to CALC2 and CALC2_1000ND. Those will be in documented in [CALC2] The exact calculator

Lessons learned

  1. This generated tabular overview kind of act as an index to all “clickable” needs. It’s a great page to bookmark.
  2. One can even add a status-column (not shown here), or filter on (show only) e.g. test that fails.
  3. It gives less insight; therefore it good to have both overviews.

Everybody understands that when the product-definition changes, the implementation will change too. And, that the test-set will change, partially; by example: new tests will be added.
However, some tests may even become obsolete!

So, just re-running all (existing) tests as a regression-test, may not work. The question is: which of all test are related to the changed requirement?

With a table as above, the answer is just one click away.

Next steps

When we introduce variants, sprint-increments, multiple (sub)components, libraries, versions, releases, etc, the challenge becomes bigger. Especially when a project-teams grows, it might become a nightmare to know which test has to be re-run, when a specification changes.

Unless one uses a (simple) approach as shown above. Then, everybody can just see which rework is needed when something “upstream” changes. And, by adding a “status” to each spec, we can even make this visual.

See [CALC2] The exact calculator for a bit more complex example: Adding a product-variant and (only) one extra (non-functional) requirement.


comments powered by Disqus