Glossary Requirements & traceability
What is requirements flowdown?
Requirements flowdown turns a system requirement into derived requirements on the subsystems and parts that must meet it, each linked to its parent.
Also called requirements flow-down, requirements decomposition.
Requirements flowdown
Requirements flowdown is the process of turning a requirement at one level of a system into derived requirements at the level below, allocated to the subsystems and parts responsible for meeting them. A system mass limit, for example, becomes a mass allocation for each subsystem. Each derived requirement keeps a link to its parent, so the requirements form a tree that can be followed from the top level to the parts and back.
Why it matters
Flowdown is how a system-level need becomes something a part designer can act on and test. The parent links show whether the derived requirements, taken together, still meet the parent, and what must be revisited when the parent changes.
How it goes wrong
- Copying a parent requirement unchanged onto every subsystem instead of deriving what each must do
- Derived requirements that have lost the link to their parent
- Allocations that add up to more than the parent allows
In Cairn
In Cairn each requirement belongs to a node and can name the requirement it derives from. The Requirements lens has a flowdown view that nests derived requirements under their parents across levels, so you can follow a system requirement down to the part that carries it. When the Requirements specialist writes requirements for a node, it reads the requirements above it. Cairn does not check that derived values add up to their parent's; budgets such as mass and power roll up from children on Overview.
Questions
- What is the difference between flowdown and allocation?
- Allocation assigns a requirement, or a portion of a budget, to the element responsible for it. Flowdown is the wider process of deriving the lower-level requirements, which includes allocation.
- What is a derived requirement?
- A requirement that follows from a higher-level one, often once a design choice is made. Choosing a battery, for example, brings requirements on charging and temperature limits that the system requirement never stated.
See it on your own system.
Describe what you are building and Cairn interviews you, then builds the first model with you.