Anforderungen richtig formulieren (ISO 29148)
AllgemeinIn diesem Artikel wird an einem fiktiven Beispiel gezeigt, wie mithilfe der Features des ETRM eine sauber nachvollziehbare Anforderungsdokumentation angelegt wird.
Vorgaben der ISO 29148
Ein häufiger Fehler im Engineering ist die Vermischung von Benutzerwünschen und technischen Spezifikationen. Dies führt zu unklaren Prüfkriterien und teuren Korrekturschleifen.
Die ISO 29148 trennt daher strikt zwischen Stakeholder-Anforderungen (Problemwelt) und System-Anforderungen (Lösungswelt). Im ETRM nutzen wir hierfür das digitale Cascading über das neue Netz-Feature.
1. Die zwei Welten der ISO 29148
- Kapitel 3: Stakeholder Requirements (Die Problemwelt) Was will der Mensch erreichen? (Fokus: Nutzen, alltagsnah).
- Kapitel 4: System Requirements (Die Lösungswelt) Was muss das Produkt technisch leisten? (Fokus: Messbarkeit, Zahlen, Daten, Fakten).
2. Das Praxisbeispiel: „Lieschens Gartenglück“
Anhand einer einfachen Gartenschaukel zeigen wir, wie Sie die Ebenen im ETRM verknüpfen.
Schritt A: Den Ursprung definieren (#1)
Wir erstellen eine Gliederung in Anlehnung an die ISO 29148, mit den Stakeholder-Anforderungen in Kapitel 3.
- Lieschen möchte gerne schaukeln. Das ist die wesentliche Stakeholder-Anforderung.
- Lieschen wiegt 25 kg. Hier verwenden wir das Tag "Constraint", da dies eine Randbedingung ist.
- Es gibt keine Bäume im Garten. Wenn keine Bäume zur Verfügung stehen, wird die Lösungsmenge auf die Schaukeln begrenzt, die freistehend funktionieren. Also auch ein "Constraint".
- Es soll sicher sein. Sehr allgemein formuliert, hieraus können je nach Bauart unterschiedliche Anforderungen folgen.
Wenn Sie genau hinschauen, werden Sie sehen, dass die Nummerierung der Anforderungen nicht fortlaufend ist. Woher kommt das?
Die Anforderungs-ID (mit dem Hashtag # gekennzeichnet) wird in dem Moment vergeben, in dem die Anforderung im Projekt erstellt wird. Sie ist eindeutig und unveränderbar. Durch Verschiebungen innerhalb der Gliederungsstruktur und nachträgliches Hinzufügen von Anforderungen können also auch Anforderungen aufeinander folgen, die nicht fortlaufend nummeriert sind.
Schritt B: Die technische Antwort ableiten & vernetzen
In Kapitel 4 definieren wir die technischen Anforderungen, die sich aus den Stakeholder-Anforderungen und den Besonderheiten der technischen Lösung in Bezug auf diese Anforderungen ergeben. Um den Zusammenhang zwischen den Stakeholder-Anforderungen und den System-Anforderungen besser erkennen und nachverfolgen zu können, können diese im ETRM verknüpft werden. In der Anforderungsliste wird die Eltern-Kind-Beziehung von Anforderungen durch Pfeile angezeigt. D.h. wenn kein Pfeil vorhanden ist, dann gibt es noch Klärungsbedarf!
3. Die Netzansicht
Der ETRM bietet Ihnen die Möglichkeit, die Beziehungen zwischen Anforderungen per Drag & Drop zu bearbeiten bzw. in einer Baumdarstellung zu visualisieren.
4. Methodische Fehlschlüsse (No-Gos)
| Fehler (No-Go) | Warum ist das falsch? | Lösung im ETRM |
|---|---|---|
| Waisen-Anforderungen | Anforderungen in Kapitel 4 ohne Bezug zu Kapitel 3. | Nutzen Sie den Filter „Nicht vernetzte Anforderungen“. |
| Zirkelbezüge | #1 braucht #2 und #2 braucht #1. | Der Netzeditor warnt Sie visuell vor logischen Schleifen. |
| Gold-Plating | Technische Features ohne Kundenwunsch. | Jede Anforderung in Kap. 4 muss mindestens ein „Eltern-Element“ in Kap. 3 haben. |
Fazit
Durch das Netz-Feature im ETRM müssen Sie IDs nicht auswendig lernen, um Zusammenhänge zu prüfen. Die Traceability-Pfeile zeigen Ihnen auf einen Blick, ob eine Anforderung eine solide Basis hat oder "in der Luft hängt".