Formulating Requirements Correctly (ISO 29148)
GeneralThis article uses a fictional example to demonstrate how to create clearly traceable requirement documentation using the features of ETRM.
ISO 29148 Guidelines
A common mistake in engineering is mixing user needs with technical specifications. This leads to unclear verification criteria and costly correction loops.
ISO 29148 therefore strictly separates Stakeholder Requirements (the problem domain) and System Requirements (the solution domain). In ETRM, we achieve this through digital cascading using the new Network feature.
1. The Two Worlds of ISO 29148
- Chapter 3: Stakeholder Requirements (The Problem Domain) What does the person want to achieve? (Focus: Benefit, real-world context).
- Chapter 4: System Requirements (The Solution Domain) What must the product achieve technically? (Focus: Measurability, numbers, data, facts).
2. Practical Example: "Lieschen's Garden Bliss"
Using a simple garden swing, we show how to link levels in ETRM.
Step A: Defining the Origin (#1)
We create an outline based on ISO 29148, with stakeholder requirements in Chapter 3.
- Lieschen would like to swing. This is the core stakeholder requirement.
- Lieschen weighs 25 kg. We use the "Constraint" tag here, as this is a boundary condition.
- There are no trees in the garden. If no trees are available, the solution space is limited to free-standing swings. This is also a "Constraint".
- It should be safe. Formulated very generally; depending on the design, various requirements may follow from this.
If you look closely, you will notice that the requirement numbering is not consecutive. Why is that?
The requirement ID (marked with a hashtag #) is assigned the moment the requirement is created in the project. It is unique and unchangeable. Due to shifts within the outline structure and the subsequent addition of requirements, requirements that are not consecutively numbered can follow one another.
Step B: Deriving & Linking the Technical Answer
In Chapter 4, we define the technical requirements resulting from the stakeholder requirements and the specifics of the technical solution. To better recognize and track the connection between stakeholder and system requirements, they can be linked in ETRM. In the requirement list, the parent-child relationship of requirements is indicated by arrows. This means: if there is no arrow, there is still a need for clarification!
3. The Network View
ETRM allows you to edit relationships between requirements via drag-and-drop or visualize them in a tree view.
4. Methodological Pitfalls (No-Gos)
| Error (No-Go) | Why is it wrong? | ETRM Solution |
|---|---|---|
| Orphan Requirements | Requirements in Ch. 4 without reference to Ch. 3. | Use the "Unlinked Requirements" filter. |
| Circular References | #1 requires #2 and #2 requires #1. | The Network Editor visually warns you of logical loops. |
| Gold Plating | Technical features without a customer request. | Every requirement in Ch. 4 must have at least one "parent element" in Ch. 3. |
Conclusion
With the ETRM Network feature, you don't need to memorize IDs to check correlations. The traceability arrows show you at a glance whether a requirement has a solid foundation or is "hanging in the air."