Should requirement be limited to ONE parent?

The “DOORS Experts” from the home facility are giving help and adamantly state that each requirement in a lower level spec should have only one parent. This is counter to my 10 years experience with requirements management. Does anyone have any thoughts on this philosophy?
aalmo - Thu Apr 09 13:58:53 EDT 2009

Re: Should requirement be limited to ONE parent?
SystemAdmin - Thu Apr 09 14:20:08 EDT 2009

What do they mean by "parent"? Generally the relation between e.g. user requirements and system requirements is one to many, i.e. one user requirement generates many system requirements. But, a system requirement might also satisfy (in part) many user requirements, or have many parent requirements - all depends on how you want to organize your requirements structure.

Re: Should requirement be limited to ONE parent?
aalmo - Thu Apr 09 14:24:57 EDT 2009

They meant lower level to system spec i.e., B spec to A spec.

Re: Should requirement be limited to ONE parent?
Ron_Lewis - Thu Apr 09 14:40:10 EDT 2009

aalmo - Thu Apr 09 14:24:57 EDT 2009
They meant lower level to system spec i.e., B spec to A spec.

From http://www.jiludwig.com/Definitions.html

Parent: parent and child requirements have a hierarchical relationship. In functional decomposition, a parent may have many children, but a child can have only one parent. Where there is more than one level of decomposition, some requirements will be both parent and child. Functional primitives have no children. Some authors refer to them as "leaves." Parent-child is also used to describe traceable relationships. Traceable relationships can be one-to-one, one-to-many, many-to-one, or many-to-many.

Re: Should requirement be limited to ONE parent?
SystemAdmin - Mon Apr 13 19:20:33 EDT 2009

Not withstanding the odd exception, it is not normal for a lower level requirement to have multiple higher level parent requirements. This is known as relationship convergence, that is, the satisfaction of multiple parents are being focused or converged into a single child. This either suggests that:

1. The child is not very atomic (multiple parent requirements shoe horned into one child requirement statement, usually exhibited by multiple "shall"s or connector words within the one statement, perhaps even a bullet list but that opens up another can of worms)

2. The parents are highly similiar or are duplications of eachother and can be optimised by a single requirement statement at the child level.

There are other possibilities, but generally, such convergent traceability should raise alarms and be treated as suspect until they can be proven otherwise.

The odd exception can always be managed, nothing is ever perfect, but if this turns out to be a normal situation, then either the Parent specification needs some rework, or the child spec needs some rework, or both. If the parent spec is owned by the customer, then the chances of getting them to rework the spec are probably nil as this represents their perception and understanding, so in such a circumstance, the child spec does end up having to be bit of a punching bag to re-order and correct the poor structural and writing errors of the parent spec. But then again, this is the purpose of the notional System Spec - this must represent the vendors traceable perception and understanding of the customers parent requirements, but hopefully in a structural format and writing style that meets all of the characteristics of good quality requirements.

Paul Miller
Specification Practices Specialist
EuroCyber
Melbourne, Australia

Re: Should requirement be limited to ONE parent?
Bob_Swan - Tue Apr 14 04:09:35 EDT 2009

'One Parent' is a good rule of thumb, but as other replies say, there are exceptions.
If a project has several stakeholders they may each specify the same requirement, (e.g. 'use lead free components'), or several units may have a common component with its oen specification, (e'g' a Poer supply module).

Our guidance is that if they occur they should be carefully examined and justified, it could be that the data model needs revising. But they are certailnly not a 'MUST never occur'.

Re: Should requirement be limited to ONE parent?
Paul_Franz_NYSTEC - Fri Apr 17 08:37:09 EDT 2009

We specify system requirements for government systems. The parents of our system requirements are often laws. New laws often build upon existing laws. The only way to understand the real system requirement is to link all of the applicable statements in the various laws together. When we do this, we sometimes find conflicts in the laws. We put more emphasis on having simple, understandable, and testable system requirements and allow as many parents as necessary to support the requirement. Where we decompose down to a lower set of software requirements, we do find that we tend to only have one parent, but not always.

Re: Should requirement be limited to ONE parent?
mcnairk - Fri Apr 17 08:43:03 EDT 2009

Paul_Franz_NYSTEC - Fri Apr 17 08:37:09 EDT 2009
We specify system requirements for government systems. The parents of our system requirements are often laws. New laws often build upon existing laws. The only way to understand the real system requirement is to link all of the applicable statements in the various laws together. When we do this, we sometimes find conflicts in the laws. We put more emphasis on having simple, understandable, and testable system requirements and allow as many parents as necessary to support the requirement. Where we decompose down to a lower set of software requirements, we do find that we tend to only have one parent, but not always.

Paul,

What happens when you find conflicts in the laws? Do you send a change request to the appropriate legislative body? I'm not being flippant, just curious...

Ken

Re: Should requirement be limited to ONE parent?
Miamc - Fri Apr 17 09:02:35 EDT 2009

SystemAdmin - Thu Apr 09 14:20:08 EDT 2009
What do they mean by "parent"? Generally the relation between e.g. user requirements and system requirements is one to many, i.e. one user requirement generates many system requirements. But, a system requirement might also satisfy (in part) many user requirements, or have many parent requirements - all depends on how you want to organize your requirements structure.

Going from user to functional, we have many functional reqs with multiple parents:

Step in UC 1: "User enters name for event collection"
Step in UC 1 Alternate Flow: "User edits name of event collection"

Both of these are linked to the same requirement: "The system shall allow the user to enter a name for the event collection" In our schema, functional reqs are children of UCs.

This requirement is also linked upward to a business rule specifying the format and number of characters of the name. And, if I'm being excessive, I link both of the UC steps to the rule too so that there's no way our coders can miss it, and so that I only have to go one level deep during impact analysis when we, say, make the name field bigger. In our schema, the BR and the UC are at the same level, hierarchly -- both come from the user or the business and are parents to the functional reqs.

However, if I were to decompose to a more technical level I would expect the system requirements to each have only one functional requirement parent, and the parents to have one to may children.