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.

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; 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

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