Looking for Support With Your IT Project?
Would you like individual advice, or do you have questions about project management in your company? No problem. We are happy to assist you.
Contact UsNachdem 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.
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:
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.
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.
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:
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.
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 |
|
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 |
|
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.
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
Would you like individual advice, or do you have questions about project management in your company? No problem. We are happy to assist you.
Contact UsHinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!
Kommentar hinterlassen