Was will der Kunde?

Requirements Engineering

Die Disziplin Requirements Engineering befasst sich mit dem Erheben, Dokumentieren, Prüfen und Verwalten von Anforderungen [1]. Zu Beginn eines Projekts gilt es die Ziele zu definieren sowie die von der Systementwicklung betroffen Personen, die als Stakeholder bezeichnet werden, zu identifizieren. Gerade letzteres beeinflusst den Projekterfolg immens, da sonst die Gefahr besteht, dass entweder ein praxisuntaugliches System entsteht oder dass das System boykottiert wird. Zusätzlich gilt es zu Projektbeginn die Systemgrenzen und den Systemkontext festzulegen. Die Systemgrenzen legen fest, was Bestandteil des Systems sein soll und korrelieren mit diesem die festgelegten Zielen aber auch die Nichtziele. Durch diese Festlegung wird verhindert, dass in weiterer Folge Energie in nichtrelevante Aspekte investiert wird, wenngleich auch zugestanden werden muss, dass die Systemgrenzen nicht in Stein gemeißelt sind sondern sich im Laufe des Requirements-Engineering-Prozesses aufgrund der gewonnenen Erkenntnisse leicht verschieben können. Der Systemkontext beinhaltet Aspekte, die zwar nicht Teil des Systems sind, jedoch trotzdem berücksichtigt werden müssen. Beispielsweise befinden sich im Systemkontext Nachbarsysteme, mit denen kommuniziert werden muss, aber auch Prozesse, an deren Unterstützung das zu erstellende System beteiligt ist. Wie die Systemgrenzen wird auch der Systemkontext im Zuge des Requirements-Engineering-Prozesses häufig eine Modifikation erfahren.

Für die Erhebung von Anforderungen existieren verschiedene Techniken, die wiederum zu Gruppen zusammengefasst werden können. Kreativitätstechniken kommen zum Einsatz, wenn ein neuartiges Produkt entwickelt werden soll. Beispiele hierfür sind das bekannte Brainstorming, die Methode 6-3-5 oder der Wechsel der Perspektive. Beobachtungstechniken finden Verwendung, wenn Stakeholder Anforderungen nicht kommunizieren können, zum Beispiel weil es sich dabei um implizites Wissen handelt oder weil die nötigen Fakten „in den Köpfen unterschiedlicher Personen verteilt vorliegen“. In diesem Fall bietet es sich an, die Stakeholder bei der Arbeit zu beobachten oder sich von ihnen anlernen zu lassen.

Befragungstechniken sind die wohl häufigste Gruppe von Erhebungstechniken. Hierzu zählt der Einsatz von Fragebögen, Interviews aber auch die aus agilen Methoden bekannten On Site Customer [2] und die Selbstaufschreibung.

Eine weitere Erhebungstechnik, die im Folgenden näher beschrieben wird, ist die Use-Case-Analyse [3]. Ein Use Case ist ein Dienst, der von einem System verschiedenen Stakeholdern, die in diesem Kontext als Akteure bezeichnet werden, zur Verfügung gestellt wird. Der Kasten „Use Case 4711 – Bestellanforderung bearbeiten“ zeigt die Beschreibung eines Use Case. Zur Analyse von Use Cases wird zunächst ermittelt welche Akteure welche Use Cases des Systems benötigen. Anschließend wird ein erstes Szenario ausgearbeitet, aus dem hervor geht, wie diese Akteure im Zuge dieser Use Cases mit dem System interagieren. Dabei wird der häufigste Fall, bei dem „alles gut geht“ herangezogen. Man nennt dieses Szenario deswegen auch Happy-Day-Szenario. Anschließend werden im Zuge eines Brainstormings Ereignisse erarbeitet, die dazu führen, dass vom Happy-Day-Szenario abgewichen werden muss. Im betrachteten Beispiel ist das der Fall „Die Bestellung würde das vorhandene Budget überschreiten“. Anschließend wird überlegt, wie in solchen Fällen vorzugehen ist. Diese Informationen werden strukturiert zu Papier gebracht, wobei sich hierbei Schreibworkshops, die gemeinsam mit den Stakeholdern stattfinden, bewährt haben. Um den Aufwand zu verringern, verwenden agile Teams anstatt Use Cases häufig User Stories. Diese bestehen aus ein bis zwei Sätzen, die die Anforderungen aus der Sicht der Stakeholder repräsentieren. Eine User Story für eine Patientenverwaltung könnte zum Beispiel wie folgt lauten: „Als Arzt kann ich bewilligungspflichtige Medikamente für meine Patienten anfordern“. User Stories stellen keine kompletten Anforderungen dar sondern nur ein Versprechen für ein Gespräch, das zwischen den Stakeholdern kurz vor der Umsetzung zu führen ist. Sie werden häufig auf Kärtchen, die zu Plänen angeordnet werden können, geschrieben. Damit die Sicht auf das Gesamtsystem nicht verloren geht, werden User Stories auch auf Story Walls in einer Reihenfolge, die die Benutzung des Systems durch Stakeholder widerspiegelt, angeordnet.

Use Case 4711 – Bestellanforderung bearbeiten

Primärer Akteur: Manager

[.]

Happy-Day-Szenario:

  1. Der Manager öffnet eine Bestellanforderung.
  2. Das System zeigt Namen, Telefonnummer und E-Mail-Adresse des Mitarbeiters sowie die angeforderten Produkte.
  3. Der Manager genehmigt die Bestellanforderung.
  4. Das System benachrichtigt den Mitarbeiter.
  5. Das System erstellt eine Bestellung und versendet diese an den Lieferanten via E-Mail.

2a. Die Bestellung würde das vorhandene Budget überschreiten.

2a.1 Das System informiert den Manager über das aktuelle Budget sowie über das Ausmaß der Überschreitung.

2a.2 Weiter mit Punkt 2 im Hauptszenario

[.]

Use-Cases-Beschreibungen und User Stories gehören zu den textbasierten Dokumentationstechniken. Für diese Gruppe existieren Vorlagen und Schablonen, die eine möglichst hohe Qualität des Texts gewährleisten sollen. Alternativ oder ergänzend dazu kann auf grafische Formen der Dokumentation zurückgegriffen werden. Beispiele hierfür sind ereignisgesteuerte Prozessketten (EPK), BPMN-Diagramme und UML-Diagramme.

Im Zuge der Prüfung von Anforderungen wird versucht, Lücken und Inkonsistenzen im Anforderungsdokument zu finden. Zudem wird geprüft, ob dieses den gegebenen formalen Vorgaben (zum Beispiel Strukturierung nach IEEE 830) entspricht. Eine Möglichkeit dazu ist das Einholen der Meinungen Dritter, zum Beispiel im Zuge eines Reviews, eines Walkthroughs, bei dem der Autor das Dokument präsentiert, oder einer Inspektion. Eine weitere Möglichkeit ist die Schaffung eines Perspektivenwechsels. Dieser kann zum Beispiel durch Modellieren der Anforderungen oder durch die Erstellung von Abnahmekriterien erreicht werden. Alternativ dazu bieten sich auch Prototypen an.

Das Verwalten von Anforderungen hat das Ziel, ein nachträgliches Auswerten zu ermöglichen. Dazu werden die einzelnen Anforderungen mit verschiedenen Attributen versehen, sowie untereinander und mit anderen Artefakten, wie Testfällen oder Teilen des Programmcodes, verknüpft. Somit wird zum Beispiel die Prüfung von Fehlerberichten gegen das tatsächlich erwünschte Systemverhalten erleichtert und bei Änderungsanfragen erkennbar werden, auf welche Systemteile sich die angedachte Änderung auswirkt.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.