We were asked by one of our clients the following question via our Ask the Experts page:  “Can a child requirement have more than one parent requirement?”

More recently we received a similar question: “At our company, we take stakeholder “voices” and decompose them into one or many “translations”.  Can a “child” translation ever trace upstream to more than one “parent” voice? I was under the impression that it should not be done this way, but I have been told otherwise.”

The short answer is “Yes, it is possible for a child requirement to have more than one parent requirement and a child translation can trace to multiple parent voices”.

It is clearly possible that multiple stakeholder voices have the same needs in terms of additional functionality, performance, and quality.  Part of the systems engineer’s job is to do an engineering analysis of each voice and translate this into a clearly stated stakeholder need and then into well-formed requirement(s).   It is reasonable that the result can trace to multiple voices concerning the same of very similar statement from the stakeholders.

As to whether or not a child requirement can trace to more than one parent, there is no single rule that applies.

At the system level there may be a several requirements dealing with functional, performance, and quality issues.  It is reasonable that the systems engineers at the next level may come up with a response ( derived child requirement) for their subsystem or component that addresses the intent of more than one parent requirements.

The areas that I can think of where a requirement may trace to two or more parents are:

• –iliities.  Reliability, operability, availability, safety, security, etc.  I can see that a case could be made that a single derived child requirement satisfies two or more –iliities.
• Design and construction standards.  You may have several standards that address a common area and a single derived child requirement may address more than one of the standards.
• Organizational good design principles, practices, and business rules.  Again, a single derived requirement may address more than one design principle or business rule.

However, when you see a child linked to multiple parents in your Systems Engineering Tool, it is a good idea to check to make sure the linkage to multiple requirements is valid and not done in error.

My advice is that your requirement management tool be configured such that you can get a report that will list all children that link to multiple parents.  Then for each of these do an analysis and see if it makes sense for the requirement to link to more than one parent.  In some cases, the links may be in error and you need to fix the problem.  In other cases, more than one parent makes sense.  To avoid having to answer this question over and over again, you could document why the child is linked to more than one parent in the rational. (This makes sense in that rational is supposed address why a requirement is needed.  If it is needed to satisfy more than one parent, then say so.)

Also, when there are multiple parents, this needs to be reflected in your verification and validation planning.  You always want to make sure that all children requirements have been verified before you can complete the verification of the parent requirement.  In the case that the child had more than one parent, the successful verification of that child requirement is a prerequisite to the verification of all the parents it is linked to.

This approach can also be used to determine if the child should be linked to the parent.  If you could verify the parent without the child requirement being implemented, then maybe that child should not have been linked to the parent.

Allocation & Traceability

I am always glad to hear from organization’s that they are documenting and managing allocation and traceability of their requirements.  It is important to make sure that all parent requirements have children and that all children requirements are linked to parents.  Performance requirements generally will link to a single parent function that they are associated.  Interface requirements will generally link to a single parent (function that involves an interaction between two or more subsystems).  Interface requirements can also link to siblings at the same level as well as to their interface definition in some type of interface definition document.   All requirements can be linked to their verification requirements as well.  For more information you can read my blog on allocation and traceability.

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