Requirements Traceability [CALC2]¶
As in “[CALC1] A simple calculator”, we can automatically generate the an overview of the requirements.
The tree view¶
- We can directly see that specification Big fractional numbers (CALC2_1000ND) influences all existing test-cases.
- Each test depends on both a (functional) requirement and a (non-functional) specification (at least in this case).
- The requirements-relations can become more complicated, even by adding only one requirement!
Can you imagine what will happen when we add a handful of requirements to the calculator (memory, square-root, powers)? Or, a few more non-functionals (speed-of-operation, floats). Then the complexity quickly raises even for such a simple product. And it becomes hard to predict which tests have to be adapted or rerun.
Likewise, when a few requirements become altered in an upcoming sprint: can you predict which tests will have to change? A graph, as above, will certainly help in working that out.
The table view¶
|CALC2||demo||Exact Calculator||CALC_ADD; CALC_SUB; CALC_MULT; CALC_DIV; CALC2_1000ND||CALC1|
|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|
|CALC2_1000ND||spec||Big fractional numbers||CALC_TEST_ADD_1; CALC_TEST_ADD_2; CALC_TEST_SUB_1; CALC_TEST_MULT_1; CALC2_TEST_DIV_1||CALC_ADD; CALC_SUB; CALC_MULT; CALC_DIV; 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|
|CALC2_TEST_DIV_1||test||DIV test (demo2 only)||CALC_DIV; CALC2_1000ND|
- The advantage of a table-view is that is will only grow in one direction: it just becomes a bit longer.
- Even for a big project, it’s a great page to bookmark and use as a start-page for all kinds of requirements.
Probably, you like to split it into the kind of ‘need’.
It would be great to show a classical Requirements Traceability matrix (RTM) too. This table shows the relations between all the requirements and all the tests.
As ‘needs’ currently does not support classical RTMs, I can’t generate/show it here. See a manually made
TRM to get the idea. As you will see: it’s easy to read.
However, its quite hard to grasp deep relations; then the tree above is more helpfull.
We might add more product-variants, or more sprints to convince you that requirement-traceability is important. The only effect is more pages with (trivial) requirements, specifications or other ‘needs’. And the same to generated overviews; the later cost only a small number of lines, independent of the size of the product. So we will leave that as an exercise.
Whenever you have more quistions, you can email me Albert.Mietus.