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.
- 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.
- When the requirement Generic Add (CALC_ADD) changes, two tests might need an update.
- 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 Requirements Matrix (table)¶
Some people prefer to see the same information in a table; again this one is automatically generated.
|CALC1||demo||Simple Calculator||CALC_ADD; CALC_SUB; CALC_MULT; CALC_DIV; CALC2|
|CALC_ADD||req||Generic Add||CALC_TEST_ADD_1; CALC_TEST_ADD_2; CALC2_1000ND||CALC1; CALC2|
|CALC_SUB||req||Generic Sub||CALC_TEST_SUB_1; CALC2_1000ND||CALC1; CALC2|
|CALC_MULT||req||Generic Multiply||CALC_TEST_MULT_1; CALC2_1000ND||CALC1; CALC2|
|CALC_DIV||req||Generic Divide||CALC2_1000ND; CALC2_TEST_DIV_1||CALC1; CALC2|
|CALC_TEST_ADD_1||test||Basic addition test||CALC_ADD; CALC2_1000ND|
|CALC_TEST_ADD_2||test||Big addition test||CALC_ADD; CALC2_1000ND|
|CALC_TEST_SUB_1||test||Subtract test||CALC_SUB; CALC2_1000ND|
|CALC_TEST_MULT_1||test||Multiplication test||CALC_MULT; CALC2_1000ND|
For now, ignore the links to CALC2 and CALC2_1000ND. Those will be in documented in [CALC2] The exact calculator
- This generated tabular overview kind of act as an index to all “clickable” needs. It’s a great page to bookmark.
- One can even add a status-column (not shown here), or filter on (show only) e.g. test that fails.
- 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.
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.