We were recently asked the following question from one of our clients concerning the decomposition of requirements:

“Do Requirements Traceability Matrices always trace down? One of the concepts we try to ensure is parent requirements at lower levels of design. So there we would be more interested in showing traceability up. But examples in textbooks seem to only go down.”

This question points out a common problem with some textbooks as well as requirement management tools (RMT).   There seems to be a lack of understanding between the concepts of allocation vs. traceability.  Below are the definitions we use:

• Allocation is the process by which requirements (“resources” and other) defined at one level (system, segment, element, etc.) are assigned to the parts of the physical architecture at the next lower level (segment, element, subsystem, etc.)
• Traceability is the ability (process) to trace (via linkage) a lower level requirement back to its source requirement; bottom to top.
• An alternate definition: Traceability is the ability to trace a child requirement back to its parent requirement (child-to-parent) or a set of related requirements to each other (peer-peer).

Another way of looking at allocation is that it is the process of “flowing down” requirements from one level of the architecture to the lower levels of the architecture.   Allocation is accomplished via a matrix listing requirements as row headers and then having a column for each part of the architecture at the next level.  If you were doing a true top-down system engineering (SE) process, at the time of allocation there are no requirements at the next level.  Therefore, your RMT needs to allow you to name the parts of the architecture at each level and then link requirements from the level you are at to parts of the architecture at the next level.

Once you have defined the architecture at the next level  (N+1) AND have allocated N level requirements to those parts of the architecture, each part then will develop (derive) children requirements at their level (N+1) and then link these “children” requirements back to their parent requirement at the previous “N” level.

An artifact of most RMTs is that once you have linked a requirement to its parent, a link also exist between the parent to its children.  This “feature” then establishes “bi-directional” traceability between levels of requirements.

Once these links have been established, you can then generate child-to-parent traceability matrices.  The RMT (if set up correctly) will also let you generate parent to child traceability matrices as well as Parent to parts of the architecture allocation matrices.  The problem with a parent to child traceability matrix is that you have to assume that parent requirement was actually allocated to the part of the architecture the child requirement was written on.  This may be a bad assumption.  Unless you document allocation as described above you will not be able to make this determination.

If done correctly you can query your RMT to produce a report that shows all requirements that trace to a parent that was not allocated to the subsystem  to which that requirement was written.  If everything is done correctly, the report output should be null.  If not, you have an issue that needs to be addressed.

Using allocation and traceability together allow you to address the following common level problems:

• Requirements at the wrong level
• Higher-level requirements not implemented at lower levels
• Lower-level requirements that cannot be justified by higher-level requirements
• Inadequate impact assessment of changes to requirements

The concepts of allocation and traceability also allow you to find and address the following requirement defects

• Requirements not allocated
• Requirements not allocated correctly
• Requirements without parents
• Requirements with incorrect parents
• Requirements with incorrect children
• Child requirements are not necessary or are not sufficient to implement the parent requirement
• Interfaces are not addressed

Your RMT should allow you to create reports that will help find and correct these defects.

As with all our blog posts, your comments on this topic are welcome.

I you have any other questions, feel free to ask your question on our “Ask the Experts” page and we will do our best to provide a timely response.