Requirements Engineering

Dokumentation der Anforderungen

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)

 

Abbildung 1: Gute vs. schlechte Anforderungen Quelle: SoftwareONE

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:

Abbildung 2: Satzschablone für Anforderungen. Quelle: SoftwareONE

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:

Abbildung 3: Satzschablonen-Beispiele für Anforderungen. Quelle: SoftwareONE

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

 

Kommentieren Sie diesen Artikel

Hinterlassen Sie einen Kommentar, um uns mitzuteilen, was Sie von diesem Thema halten!

Kommentar hinterlassen

Autor

Henrik Krumbholz

Senior Consultant SharePoint

Microsoft SharePoint

Verwandte Artikel

Namensänderung oder echter Wandel? Office 365 wird Microsoft 365

Abschied von Office 365 – Microsoft 365 ist die Antwort für den modernen Arbeitsplatz. Lesen Sie dazu unseren Blogbeitrag.

Die intelligente Lösung für den Remote Einsatz – Citrix Workspace

Bieten Sie ihren Mitarbeitern die Möglichkeit, flexibel arbeiten zu können und unkompliziert auf Daten zuzugreifen. Datensicherheit, Softwarefragen und Service-Aspekte werden durch Citrix Workspace gelöst.

Windows Virtual Desktop – Überblick, Kosten, Technik

Windows Virtual Desktop (WVD) ist Microsofts Cloud-basierter Service für die Bereitstellung von Windows 10 Desktops auf Azure. Wir geben einen Überblick.