Like all hard questions, the answer is, it depends. A child requirement shouldn't have more than one parent, but notice I said should. There are cases where you end up with just this situation, but first let's see why we want avoid it.
Why we want only one parent per child requirement
We use requirements to manage the scope of our work. They are used to systematically break down large complex systems into smaller blocks that can be more easily designed and tested. Those smaller blocks can then be integrated back into the larger system. To do that we need to decompose each requirement into more detail at each layer of design.
If we have a child requirement that satisfies two parents, it often means the parent requirement doesn't meet the definition of a good requirement. It's not orthogonal. The parent requirement is specifying something that is partially or entirely covered by another requirement. Consider the following two aircraft requirements,
- [1] The system shall display own position.
- [2] The system shall display own altitude.
- [A] The GPS shall display own latitude. (links to [1])
- [B] The GPS shall display own longitude. (links to [1])
- [C] The Altimeter shall display own altitude. (links to [1] and [2])
When this system is tested we could find that the altimeter fails to provide expected results, which means it fails requirement [C]. Since [C] traces to both [1] and [2], both parent requirements fail. We will report to our customer that the system cannot provide altitude nor position correctly. Which makes it seem like the GPS doesn't work either, which isn't true. Of course, you can always write a report interpreting the impact of each test failure for each and every requirement but that's extra work that wouldn't be needed if the requirements weren't coupled.
Once the system is up and running, if we choose to replace the altimeter with a newer model we'd use the requirements to figure out which systems are impacted by the change. We do this by selecting all requirements on the changing system (in this case, requirement [C]) trace them up to their parents then trace back down to see which systems are touched and need analysis for impact. In this case because requirement [C] shares a parent with [A] and [B] the GPS subsystem appears to be impacted. This would cause us to kick off a task to quantify that impact which costs us resources we could be using elsewhere. The team will quickly realize there is no impact, but there was still a cost to realizing there was no impact. And over the life of a system these little analysis-no-impact events add up.
The best solution is to decouple the parent requirements. When we have one parent per child our requirements trace becomes an analysis tool that reduces the amount of work needed to test and maintain the system. It helps us focus our resources wisely.
When is it OK to have more than one parent per child requirement?
However, I did say should rather than shall when it came to the one parent per child rule. In a limited number of real world situations, you will choose to violate this rule (and incur the costs). For instance, when your customer provides you a set of requirements that are not fully orthogonal. If you have the option, you should work with the customer to decouple their requirements and improve the specification.
Unfortunately, that's not always possible, so the next best thing for a project (and your budget) is build your own specification composed of orthogonal requirements a level below the customer specification and link your requirements up to the customer specification. Since the customer requirements aren't orthogonal you will get multiple parents per child. It's better to compromise on the 'one parent per child' rule at a single layer and build a solid specification with which your team can work, than to propagate the issues down.
-Michael Sepa, P.Eng
13 September 2014
INCOSE Canada publishes an article of technical interest to engineers each week. You can read them all by clicking here.