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.

@startuml

' Nodes definition 

node "<size:12>Demonstrator</size>\n**Simple**\n**Calculator**\n<size:10>CALC1</size>" as CALC1 [[../SystemEngineering/RequirementsTraceability/demo/demo1.html#CALC1]] #9DC5BB 
frame "<size:12>Requirement</size>\n**Generic Add**\n<size:10>CALC_ADD</size>" as CALC_ADD [[../SystemEngineering/RequirementsTraceability/demo/demo1.html#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#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#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#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#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#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#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#CALC_TEST_MULT_1]] #F6E27F 

' Connection definition 

CALC_ADD --> CALC1
CALC_SUB --> CALC1
CALC_MULT --> CALC1
CALC_DIV --> CALC1
CALC_TEST_ADD_1 --> CALC_ADD
CALC_TEST_ADD_2 --> CALC_ADD
CALC_TEST_SUB_1 --> CALC_SUB
CALC_TEST_MULT_1 --> CALC_MULT

@enduml

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?

Attention

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 also

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

Hint

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

comments powered by Disqus