Skip to content

Requirements trees

Many textbooks on requirements management show examples of representations of a requirement linked to other requirements. It is seldom explained what this link means.

What does the line between Requirement 001 and Requirement 101 mean? Is Requirement 001 a “parent” requirement? Whatever it means. Is Requirement 101 “derived” from Requirement 001? If so, where is this information stored? Is there a relation between Requirement 101 and Requirement 201?

As soon as you start asked questions like these, you find out that it really does not make any sense to link requirements to other requirements. Requirements are input for design and architecture processes.

Anyone who has participated in a real project with real requirements and a proper development process has seen that in between requirements is either an analysis statement (from the Requirements Engineering Analysis process step) or a design decision that answer the two questions above.

In the example above system-level requirements R-001 and R-002 are analysed. During the analysis it was agreed that if a decision must be made for a particular component’s characteristics mass and cost, the priority lies with mass. This analysis statement AS-001 gives guidance to the two system-level budget tables (both are part of the system design) and are formatted as Design Decisions.
Four requirements are derived from these budget tables R-101 states how much of the mass budget is allocated to physical module XYZ and R-201 states how much mass is allocated to physical module ABC. Similar for cost: R-102 is part of the total cost budget that is allocated to physical module XYZ and R-202 for physical module ABC.

In this way tracelinks, Design Decisions and Analysis Statement can perfectly help to account for the reason why these requirements are there and also why the requirements have these specific values.

‘Terrible’ examples

Here are some examples from our current practices that demonstrate how not to do it.

In the Systems Engineering Book of Knowledge a page on the System Requirements Definition shows an image with a so-called Requirements Tree. The tree is created without any practical reference to the real world. Mixing up the functional and physical architectures that are leading for not only the requirements but also for the designs that need to satisfy the requirements. In practice requirements are never related to other requirements. Either an analysis statement or a design decision will explain the relation (if any).
It is advised to avoid that page completely.

Loading

Leave a Reply

Your email address will not be published. Required fields are marked *