Requirements Engineering: Documentation of Requirements

Nachdem wir uns mit dem Erkennen von Zielen und um die ersten Anforderungen an ein Projekt beschäftigt haben, soll es dieses Mal um die Dokumentation der erkannten Anforderungen gehen. Damit die Dokumentation im Nachgang auch verständlich ist, gibt es gewisse Kriterien, an denen man gute Anforderungen erkennt.

Anforderungen an gute Anforderungen

Diese Anforderungen oder Kriterien sind teilweise recht simpel und selbstverständlich – manchmal aber auch etwas schwieriger zu verstehen. Eine gute Anforderung sollte folgende Kriterien erfüllen:

• Abgestimmt (Für alle Stakeholder korrekt)
• Eindeutig (Unmissverständlich)
• Notwendig (Muss gültig sein)
• Konsistent (Widerspruchsfrei)
• Prüfbar (Ein Test ermöglicht die Prüfung)
• Realisierbar (Organisatorisch, rechtlich, technisch, finanziell)
• Verfolgbar (Warum wollen wir das nochmal?)
• Vollständig (Keine Interpretationslücken)
• Verständlich (Für alle Stakeholder)
  

 

Das bedeutet nicht zwingend, dass eine Anforderung, die diese Kriterien nicht zur Gänze erfüllt, keine relevante Anforderung ist. Es bedeutet nur, dass es mitunter im Nachgang eine größere Herausforderung wird, damit zu arbeiten. Unscheinbar, aber sehr wichtig, ist der Punkt „Verfolgbar“. Wie oben bereits erwähnt, geht es darum, zu wissen, warum diese Anforderung sinnvoll ist bzw. wo sie herkommt. Das ist sehr wichtig, da im Laufe des Projektes der Grund für eine Anforderung durchaus mal vergessen wird. Man könnte argumentieren, dass diese dann irrelevant ist. Das ist aber nicht immer korrekt. Es kann beispielsweise sein, dass sich das Projektteam ändert und neu in die Anforderungen einarbeiten muss.

Woher Anforderungen holen, wenn nicht stehlen?

Einige erste Anforderungen haben wir bereits im Und-Oder-Baum unseres Beispielprojektes (Teil 3) visualisiert, auch wenn sie noch nicht den Kriterien entsprechen. Die Quelle dafür waren unsere Stakeholder – und dabei in erster Linie die natürlichen Personen. Als weitere Quelle dienen diverse Normen und Gesetze sowie, und das sollte man nicht unterschätzen, Konkurrenz-, Alt- und Vorgängersysteme. In unserem Beispielprojekt wären das mitunter Teamevents von anderen Teams oder frühere Events des gleichen Teams.

In den einfachsten Fällen werden die Stakeholder befragt, um die Anforderungen und deren Priorität zu ermitteln – bei Dokumenten werden natürlich keine Fragen gestellt, sondern sie werden gelesen. Hinzu kommen verschiedene andere Techniken, auf die ich in dieser Serie nicht tiefer eingehen werde, wie Beobachtungs- oder auch Kreativtechniken.

Notation von Anforderungen

Ich habe gute Erfahrungen mit Satzschablonen gemacht, um Anforderungen zu notieren. Dabei ist der Aufbau stets gleich und der Inhalt ist (vollkommen) losgelöst von der technischen Realisierung. Die Satzschablone, die ich benutze, wie wohl viele andere auch, sieht wie folgt aus:

Hier gibt es wieder einige Herausforderungen, die bei der Verwendung der Satzschablone beachtet werden müssen. Wer dort tiefer hineingehen möchte, kann die Suchmaschine seiner Wahl nach den folgenden Schlagwörtern befragen:  Mehrdeutigkeit, Transformationseffekte, Nominalisierung, Substantive ohne Bezugsindex, Universalquantoren etc. Abgesehen davon muss die deutsche Grammatik beachtet werden. Wenn es keine Bedingung gibt, sollte das Substantiv am Satzanfang stehen.

Anforderungen an unser Beispielprojekt können der Satzschablone entsprechend sein:

Zugegeben an dieser Stelle gestaltet sich unser Beispielprojekt etwas schwierig, da keiner ein Teamevent mit solchen Anforderungen organisiert. Deshalb führe ich an dieser Stelle noch ein paar Beispiele aus dem Projektalltag (vielleicht eine Filmdatenbank) auf, um das Ganze besser zu verdeutlichen:

• Falls der angemeldete Nutzer mindestens 18 Jahre alt ist, MUSS das System dem angemeldeten Nutzer die Möglichkeit bieten, Filme FSK 18 anzusehen.
• Falls der angemeldete Nutzer unter 18 Jahre alt ist, MUSS das System dem angemeldeten Nutzer alle Filme mit FSK 18 ausblenden.
• Das System KANN dem angemeldeten Nutzer die Möglichkeit bieten, sein Passwort zu ändern.
• Das System MUSS dem Nutzer die Möglichkeit bieten, sein Geburtsdatum einzugeben.
• Das System MUSS fähig sein, Geburtsdaten der Nutzer zu verifizieren.

Man erkennt schon, dass die eine oder andere Anforderung zwar klar beschrieben ist, aber zum Beispiel die letzte Anforderung durchaus Platz für Spielraum hinsichtlich des Verbs „verifizieren“ zulässt. Das könnte bedeuten, dass das Geburtsdatum ein valides Format haben muss (TT.MM.JJJJ) oder auch, dass gewisse Regeln geprüft werden sollen (bspw. Datum liegt in der Vergangenheit). Diese Punkte müssen mit notiert werden.

Anwendungsfälle für bessere Ablaufgestaltung

Der eine oder andere hat bereits erkannt, dass es einige Herausforderungen bei den oben genannten Anforderungen gibt: Der Spielraum für den Entwickler ist mitunter immer noch groß. Es gibt einige Informationen, die für den Entwickler hilfreich sein könnten wie beispielsweise ein Mockup, ein Interaktionsablauf und andere Dinge. Daher bieten sich Anwendungsfälle (Use Cases) an. Sie beschreiben relativ viele Aspekte des Systems und dessen Verhalten und vor allem Aspekte der Interaktion mit dem Endanwender. Dabei notiere ich einen Use Case in der Regel in Tabellenform, die wie folgt aussieht und sich tatsächlich am Lehrbuch orientiert:

Bezeichner	Erklärung	Beispiel
ID	Eindeutige Identifizierung des Use Cases	UC-0017
Name	Name des Use Cases	GoKart-Fahren
Priorität	Priorität	Mittel
Autor	Ersteller des Use Cases	Teamleiter
Quelle	Ursprung des Use Cases	Stakeholderbefragung
Verantwortlicher	Verantwortlicher des Use Cases	Teamleiter
Referenzen	Referenzen auf andere Use Cases oder Elemente	UC-0016
Beschreibung	Eine kurze Beschreibung des Use Cases	GoKart-Fahren mit Qualifying und Rennen
Akteure	Die Akteure innerhalb des Use Cases	Teilnehmer (Teammitglieder und -Leiter), Teamevent (System), Bahnbesitzer
Auslöser	Auslöser des Use Cases	Ankunft an GoKart-Bahn
Vorbedingungen	Bedingungen, die vor Eintreten des Use Cases erfüllt sein müssen	Alle Teammitglieder und Teamleiter anwesend GoKart-Bahn geöffnet und bezahlt
Hauptszenario	Szenario, das hauptsächlich ausgeführt wird	1. Der Bahnbesitzer weist die Teilnehmer ein         2. Der Bahnbesitzer teilt notwendigt Kleidung aus         3. Die Teilnehmer ziehen sich um und nehmen sich ein GoKart         4. Der Bahnbesitzer startet das Qualifying         5. Die Teilnehmer absolvieren das Qualifying         6. Der Bahnbesitzer beendet das Qualifying         7. Der Bahnbesitzer startet das Rennen         8. Die Teilnehmer absolvieren das Rennen         9. Der Bahnbesitzer beendet das Rennen       10. Der Teamleiter verteilt Urkunden
Alternativszenarien	Szenarien, die alternativ zum Hauptszenario ausgeführt werden könnten	A1         3. Es sind nicht genügend GoKarts vorhanden         4. Der Bahnbesitzer besorgt ausreichend GoKarts         5. Weiter mit 4 des Hauptszenarios
Ausnahmeszenarien	Szenarien, die Ausnahmen bilden und zu einem Abbruch des Use Case führen. Diese können auch in Alternativszenarien greifen.	E1         8. Ein Teilnehmer hat einen Unfall         9. Der Bahnbesitzer bricht das Rennen ab       10. Der Teamleiter fährt mit dem Teammitglied ins Krankenhaus
Nachbedingungen	Bedingungen, die vor Beenden des Use Cases erfüllt sein müssen	Alle Teilnehmer (Teammitglieder und -Leiter) sind im Ziel
Ergebnisse	Ergebnisse des Use Cases je nach Szenario	Alle Teilnehmer haben eine Urkunde und ein gutes Gefühl A1: Alle Teilnehmer haben eine Urkunde und ein gutes Gefühl E1: Alle Teilnehmer fahren ins Hotel und warten auf Rückmeldung

Auch wenn das Beispiel hier wieder seine Schwächen zeigt, sollte der Grundsatz klar sein. Weiter ausbauen kann man das Ganze dann noch mit Use-Case-Diagrammen, die ich den Rahmen dieses Beitrages sprengen würden.

Fazit: Dokumentation und Realität

Man kann recht viel Zeit damit verbringen Anforderungen zu dokumentieren, sodass am Ende ein Katalog herauskommt, der das System vollumfänglich und detailliert beschreibt. Das ist für den Projekterfolg sehr wichtig, es steht aber nicht immer die Zeit dafür zur Verfügung. Darum gehe ich im fünften Teil auf eine reale Situation einund wie man mit ein paar Kompromissen Requirement Engineering erfolgversprechend in IT-Projekten umsetzen kann.

Teil 1: Requirements Engineering – Gründe für RE und auch dagegen

Teil 2: Requirements Engineering – Erste wichtige Schritte bei RE

Teil 3: Requirements Engineering – Zielmodelle nutzen, um Anforderungen zu definieren

Teil 4: Requirements Engineering – Dokumentation der Anforderungen

Teil 5: Requirements Engineering – Erfahrungen mit RE in der Praxis des IT-Umfelds