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

“I have used your company’s materials as reference for many years and recently had the pleasure of meeting Ivy Hooks in person at the recent INCOSE International Symposium.

My question is this: Does your company have any numbers that could be used as a “figure of merit” that could be used as a rule of thumb when evaluating requirements decomposition or are you aware of any research in this area?  For instance, should 10 functional requirements decompose to 30 at the next level or 3-to-1?  Some figure or range such as this that could be used as an initial gauge during project evaluations and help determine if additional review is required.

I immediately thought of your company as requirements experts who might have some information in this regard having seen hundreds or thousands more requirements and projects than I have.”

We do not think it is as simple as assigning a number or “figure of merit” when it comes to decomposition.    We look at decomposition several ways.

Decomposition within a level.
This starts getting into the topic of levels of detail with a level of the architecture.  One example of this is when a general function may need to be decomposed into subfunctions to be meaningful and verifiable.  For this case you would decompose the function into whatever subfunctions make sense and write corresponding functional requirements.  It would be difficult to put a rule-of-thumb “figure of merit”  on the number of subfunctions, it will be two or more, but normally  would  not be over 5-7 as a general rule, but there are always exceptions.

It may be one or more of the sub-functions need to be further decomposed within this same level.  The same numbers would apply.  You would stop decomposing within a level when the resulting functions apply to only one part of the next level architecture.  Then you would go back to the previous/parent function, write the functional requirement and allocate that functional requirement  to the parts of the architecture at the next level and document the decomposed/derived (children) requirements in that part’s set of requirements, tracing back to the parent requirement that was allocated to it.

Another prime example of decomposition within a level is when you develop performance requirements to go with the functions.  Again, a specific number it would be difficult to put a specific number of performance requirements tied to a given function.  Whatever performance requirements you don’t specify, you are leaving up to the designers to define for you.

Decomposition  at the next level of the architecture
This is when you allocate (assign responsibility) to implement requirements at one level of the architecture to parts of the architecture at the next level.  When this is done, the systems of interest at the next level will decompose the allocated requirement and derive children requirements, that when implemented, will result in or enable the parent requirement to be met.

The number of parts of architecture at the next level that the parent was allocated to, will greatly affect the total number of children requirements traced back to the parent.  For a single part of the architecture, a specific “figure of merit” would be difficult to define.   It would be at least two.  If zero, then the requirement isn’t being implemented at the next level.  If only one, what often is the case is that someone just copied the parent requirement to the next level with a noun change.  As far as the maximum, again I wouldn’t think the number would be more than 5-7.   The key question that needs to be asked “Is the set of derived children requirements necessary and sufficient, that when implemented, will result in or enable  the parent requirement to be met?”  One thing that is scary is the number of organizations that understand the need for and do the needed analysis to answer this question.  In a sense, this is the real issue you are trying to address.

Decomposition and internal interfaces.
When a requirement  is allocated to two or more parts of the architecture at the next level, you also have to address whether or not there are any internal interfaces between the parts of the architecture the requirement was allocated to.  If so, you will have to define the interactions between the interfacing systems and write interface requirements for the systems on both sides of the interface that point to the agreed-to definitions.  This would add to the number of derived requirements.

Conclusion
Requirement definition, allocation, decomposition, is a complex systems engineering task.  A simple “figure of merit” cannot substitute for the case-by-case analysis needed to determine whether or not the requirements that result from decomposition form a necessary and sufficient set of requirements.  If an allocated requirement has 0 or 1 children, you have an issue that needs to be addressed. If 0, then this requirement has no children and is not being implemented at the next level.  If 2 or more children, you just have to do the analysis on a case-by-case basis to determine if they are necessary and sufficient to meet the intent of the parent requirement.

Comments on this blog are welcome.

If 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.