Im heutigen 3. Teil der Requirements Engineering Serie geht es darum, die erhobenen Anforderungen in eine Beziehung zu Zielen, Features und Tasks zu bringen.
Hierzu kann uns das Requirements Abstraction Model behilflich sein. Ich erkläre dieses Modell aus meiner Sicht, da die originale Erklärung sehr komplex und ausführlich ist.
Die Ebenen des Requirements Abstract Model
- 1. Ebene – Ziele
- 2. Ebene – Features
- 3. Ebene – Anforderungen
- 4. Ebene – Technik / Tasks
Auf der ersten Ebene werden die zu erreichenden Ziele aus dem Business / Management formuliert. Daraus werden auf der 2. Ebene Features abgeleitet. Auf der 3. Ebene werden nun die Anforderungen angesiedelt, welche sich wiederum von Features ableiten sollten. Da Anforderungen für die Implementierung meistens noch zu ungenau sind, kann noch eine 4. Ebene, nämlich die Technikebene erstellt werden. Hier werden die einzelnen Anforderungen noch detaillierter formuliert.
Regeln für Anforderungen
Da uns in diesem Beitrag hauptsächlich die Anforderungen interessieren, möchte ich noch einige Regeln für Anforderungen formulieren:
- Jedes Requirement sollte mindestens bis zur Ebene 3 (Anforderungen) detailliert werden
- Jede Anforderung muss einen Bezug zu einem Ziel bzw. zu einem Feature haben. Ansonsten ist es überflüssig und kann gestrichen werden. Eventuell sind auch Ziele und Features vergessen worden.
- Erst ab der 3. Ebene macht es überhaupt Sinn, Sprachschablonen zu verwenden. Die Ebene der Ziele und Features unterliegt anderen Regeln.
Nutzen des Requirements Abstraction Model
Das Requirements Abstraction Model bietet uns eine Hilfestellung, Anforderungen zu strukturieren und das Zusammenspiel zwischen Zielen, Features und Anforderungen zu erkennen. Durch das Erstellen des RAM ist es einfacher, Ungereimtheiten auf den verschiedenen Ebenen zu erkennen.
“Jedes Requirement sollte mindestens bis zur Ebene 3 (Anforderungen) detailliert werden”
Die interessante Frage hier ist wann soll diese Detaillierung erfolgen?
Der klassische Wasserfall und traditionelle “Spec-First” Methoden wollen diese Detaillierung komplett erstellen bevor mit der Implementation begonnen wird. (Push-Ansatz)
Agile Ansätze verfolgen bei der Detaillierung einen “Just in Time” Ansatz: Die Detaillierung wird erst erstellt, wenn sie tatsächlich benötigt wird (Pull-Ansatz). D.h in der Regel erst kurz vor dem Start der Iteration in welcher das Feature implementert wird.
Dies erlaubt erhöhte Flexibilität und verhindert unnötige Arbeit.
Ein ganz interessanter Ansatz ist hierzu “Feature Injection”:
http://www.infoq.com/articles/pulling-power
Hi Jonas
Danke für Dein Feedback. Ich bin immer sehr dankbar für solche Inputs!
Die Frage des Erstellungszeitpunktes ist in der Tat eine Frage, die ich zum aktuellen Zeitpunkt nicht kompetent beantworten könnte. Aber Du hast mir ja Kanonenfutter geliefert. Ich werde deine Quelle mal studieren.
Ich meine, eines der Hauptaspekte von RAM ist, dass dieses Modell die Tatsache anerkennt, dasss zu jedem Zeitpunkt auf jeder Ebene Anforderungen postuliert werden können. Was nun das RAM produktiv macht, ist, dass für low-level Anforderngen entweder darüber liegende (bestehende oder neue) Features und Ziele gefunden oder die Anforderung verworfen werden muss, bei höherliegenden Zielen und Features nach diese konkretisierenden Anforderungen gesucht und resp. um solche ergänzt werden muss.