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.