Requirements begin life in raw form. They start as an unstructured bunch of desires, features, hunches and estimated needs. Some may be well known, however usually, they are ill thought out, undetailed, conflicting, poorly aligned to needs and poorly articulated. It is up to the BA to refine them and turn them into meaningful and validated requirements. Part of this process is categorising them into related groups and decomposing higher level requirements into sub requirements at lower levels of detail with the goal of reaching a fully decomposed atomic state. This typically evolves through layers of analysis that starts general and works itertively in stages towards the low-level detail.

The hierarchy groups related requirements  – grouping requirements that are similar in nature.

Requirement Types

  1. Functional – the actual functionality required of the new process. What the product or service does.


  1. Non Functional – The ‘ilities (quality, reliability, availability)
  • Security
  • Performance
  • Usability


  1. General (business policies, constraints, legal, cultural)


  1. Technical (Hardware, software, interconnectivity)


Benefits of a solid Requirements Hierarchy

  • Definition of a functional requirement is clear across the team
  • The business context and supports for a defined requirement are clearer
  • Non-functional requirements can be easily matched to business and technical policies
  • Once defined non-functional requirements can be easily reused
  • Traceability – back to original business needs
  • Level of requirement priority
  • Grouped requirements can be easily accessed for review or testing
  • Requirement relationships can be easily traced helping manage change


You can use hierarchical relationships to subdivide a requirement into more explicit or related requirements. Child requirements provide additional detail for their parent requirement. If a parent (or indeed a sibling) is changed we can trace what other requirements may be affected.


Parent requirement:

  • The system shall display customer information.

Child requirements provided for detail:

  • Name
  • Address
  • Date of Birth

Hierarchical requirements use an outline numbering style, with a period denoting each child level. For example, if the requirement tag is FR101, then its immediate children are numbered FR101.1 and FR101.2. Their immediate children are numbered FR101.1.1 and FR101.2.1.


Share This