Some people like the idea of hierarchical requirements, i.e. requirements having sub and sub-sub requirements.

However, hierarchical organisation of requirements is principally flawed, and tools which provide this as the only method of organisation should be avoided.

Why hierarchical organisation can’t work

Most Functional requirements typically have one or more Usability, Reliability, Performance, Scaleability, Security requirement associated with them (FURPS’).

For example, a performance requirement like “the system shall display the window / information within one second” may apply to several specific windows / UseCases. Would you want to repeat this performance requirement N-times as a sub-requirement? After all, it is the same requirement applicable to a number of functional requirements.

Or would you list the functional requirements by URPS (non-functional / qualitative) requirement? What happens if a functional requirement is impacted by both a reliability and a performance requirement: are you going to list it twice?!

Equally we can have a functional requirement which is a “sub-requirement” of several functional requirements. For example, “the system shall calculate GST as per the rules Xyz” is a functional requirement which may apply to several windows / web-pages of the application. Would you list that requirement many times as a sub-requirement to other “main” functional requirements to which it is applicable?

Requirements are not hierarchical but relational

The above clearly shows that the relationship between requirements is not hierarchical but rather is relational, i.e. best represented by “requirements to requirements” linking. And yes, requirements may be best organised by “grouping” but the group “header” is not necessarily the same as a “parent” requirement!

The issues of requirements hierarchies is often further aggravated by people using, or tools imposing, hierarchical requirements identifiers, like 2.1, or 2.3.1. As explained in detail in Requirement numbering traps such numbering schemes cause major problems for everyone in the team. For example, consider what happens if you insert a requirement “above” 2.3.x, moving 2.3.x to say 2.4.x? All of a sudden your reference numbers have changed and thus are no longer traceable to/in other artefacts such as test scripts or documents.

For these reasons it is clear that requirements should never be captured in a hierarchical fashion, and their identifiers should not reflect a hierarchical numbering. To understand the impacts of changes, business requirements coverage, etc, what is needed is not a hierarchy, but requirements linking! To be able to create and maintain the links you need a relational database or a tool like ScopeTracker, RequisitePro or CaliberRM.