I plan to write some posts delving into important aspects of Requirements Management, with the added twist that I shall be using the 3D graphics tool Perspector to illustrate the concepts involved. I do this because I have 13 years experience working in the requirements management (RM) industry, and one of the reasons I wanted to see a tool like Perspector being created was that I had great difficulty trying to illustrate some of the concepts used in RM just using 2D diagrams. Now with the help of Perspector, I can draw the diagrams I used to have trapped in my head.

This first installment takes a look at requirements traceability.

The wikipedia article just cited is a very reasonable summary, but it lacks a picture of an example information architecture employing traceability; here is one:

traceability matrix

above we show three levels of problem/solution decomposition. The first level is used to manage the “problem” and contains the User Requirements (UR), Acceptance Test Plan (ATP) and Acceptance Tests (AT). We call this “Level 0″ and use “0″ super-scripts in the labeled circles which represent requirements (r), test requirements (tr) and tests (t). Within a level we have arrows representing traceability links between the requirements and the test requirements (e.g. r1 is traced to by tr1 in level 0), and between tests and their test requirements (e.g. tr1 is traced to from t2 in level 0). We call this ”horizontal” traceability relationship “Qualification”. Essentially a requirement should be “qualified” by a test requirement which specifies how we will know that the requirement has been met. These test requirements in turn need to be qualified by tests which when executed contribute to the measurement of  the qualification so far achieved.

The next level down, numbered 1, is the start of the solution, where we begin with the system requirements, which will specify the system which will be built to satisfy the user requirements. Which brings us to the next type of traceability relationship, which is “Satisfies” and runs vertically between levels. In our example user requirement r2 at level 0 is ”Satisfied” by the level 1 requirements r2 and r3. Just like the layer above, the system level has the horizontal “Qualification” traceability relationship happening between the System Requirements (SR), the System Test Plan (STP) and the System Tests (ST).

We only show one further level of requirements decomposition, but there may be more depending on the complexity of the system being developed, here we stop at the “Sub-System” level, numbered 2, where we have Sub-System Requirements (SSR), a Sub-System Test Plan (SSTP), and Sub-System Tests (SST).  The point is that additional layers can be added as necessary, by simply repeating the same pattern as established between the first two layers.

You are doing well as an engineering concern if you even manage to use parts of just level 0 and/or level 1; however, mature systems engineering organizations have been known to fully deploy 7 or more layers.

Caveat - this is just an introductory short article, and so I have had to lie by omission - there is a lot more that can happen and needs to be said (e.g. multiple sub-systems in the same layer, and one reason I used “Qualification” was to side step a lack of agreement in the industry as to the meaning of “Verification” and “Validation”). But I hope to return to this and related topics.

Share This