On our Ask the Experts page , the following question was asked: “I am a systems engineer currently involved in a complex aerospace system development. While I was searching for some related topics on requirements management, your interesting website was pointed out. I am curious to know if you have a way of finding how stable a given requirement hierarchy is. In other words, is there any metric that shows how well the requirements are connected (or not connected) to each other at various different levels….. Any thoughts on this……. ?”
A very interesting and important question. When talking about requirement hierarchy, the concepts of levels, allocation, and traceability need to be addressed.
From a metric standpoint, for a complex aerospace system, I am assuming the requirements are being managed in a Requirement Management Tool (RMT). I am also assuming the schema of the RMT is set up to allow requirements flow down (allocation) from one level of the architecture to another. For more information concerning features an RMT should have see: Features an SE Tool Set Should Have.
When you allocate a requirement from one level of the architecture to another, you are linking the requirement at level N to an applicable part(s) of the architecture at the next lower level (N+1). These allocated requirements serve are the basis for the children requirements that you will derive at N+1. The N+1 requirements are then linked or traced (using the RMT traceability functionality) to the parent or source requirement at the previous level N.
When the RMT is set-up properly, you can address several common requirement hierarchy problems:
- 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
From a metric standpoint, your RMT should be able to directly address problem 1 and 3 above with a simple report. For problem 1, you should be able to have a report that provides you with a metric to show how many requirements have not been allocated. To make sure all your requirements have been allocated, the report should return a “null” result – saying that all requirements at one level have been allocated to the next level. For problem 3, your RMT should be able to give you a report that shows all requirements at one level that do not trace to a source or parent at the previous level. Again, the report should return a “null” – indicating that all the requirements do trace to a source or parent.
The real issue is all the other problems (i.e., requirements not allocated correctly, with incorrect parents, incorrect children, child requirements not necessary or not sufficient to implement the parent requirement, interfaces not addressed). The RMT should be able to provide allocation and traceability matrices that list the parent/child relationships. Whether or not the allocations and traceabilities are correct or whether child requirements are necessary and sufficient to implement the parent requirement requires an engineer to do the analysis – the RMT can only show numbers NOT that the allocation and traceability is correct.
The last problem, interfaces not addressed, involves the case when a parent requirement has been allocated to two or more lower level parts of the architecture. When this happens, it could reveal that the parts of the architecture the requirement was allocated to have to work together (interact) to meet that allocated requirement. If so, there is most likely an internal interface. Again, a simple report will not indict this problem exists, an engineer needs to do the analysis to identify interfaces internal to your project.
To answer the question, the RMTs can generate metrics, however it will take a person to determine “how well” the requirements are connected (allocation and traceability). From a stability standpoint, in the beginning, the allocation report will show requirements that have not been allocated and the traceability report will show requirements that do not trace to a source or parent. As the program matures, the number of occurrences should decrease, and ideally by the time the requirements at the lowest level have been baselined, each report should come up with a “null” result as discussed above. When this happens, your requirements will be fairly stable. However, change happens. Assuming you are managing allocation and traceability properly, the RMT will allow you to easily assess the impacts of a change anywhere within the system hierarchy.
Levels, allocation, and traceability have been addressed several times in our blogs:
- Requirements Decomposition
- Allocation and Traceability
- Managing Traceability Links When Requirements are Deleted
- Traceability – Multiple Parent Requirements
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our Ask the Experts page and we will do our best to provide a timely response.
