4.2. Der Anforderungs-Erfassungs-Prozess

Wir beginnen mit einer Top-Level-Sicht auf das von uns zu lösende Problem und die Schlüsselbereiche der Funktionalität, die wir für die Lösung adressieren müssen. Dies ist unser Visions- Dokument und es sollte nur einige Seiten lang sein.

Die Top-Level-Sicht eines Geldautomaten (automated teller machine (ATM)) zum Beispiel, sollte folgendes unterstützen.

  1. Bargeld lagern, Bargeld abheben und Kontoabfragen durch Kunden.

  2. Warten des Equipments durch Bank-Ingenieure und leeren der Kassen und Bargeld nachfüllen durch die lokale Bankfiliale.

  3. Nachvollziehbarkeit aller an den zentralen Bankcomputer gesendeten Aktivitäten.

Aus dieser Top-Level-Sicht können wir die prinzipiellen Aktivitäten des Systems und die extern Handelnden (Menschen, Equipment) die in diese Aktivitäten eingebunden sind extrahieren. Diese Aktivitäten sind als Anwendungsfälle und die extern Handelnden als Akteure bekannt.

Akteure können Menschen oder Maschinen sein. Vom praktischen Standpunkt aus gesehen besteht deren Wert darin, die Nutzer hinter einer Maschine zu kennen, da nur diese in der Lage sind, sich mit dem Anforderungs-Erfassungs-Prozess zu beschäftigen.

Anwendungsfälle sollte signifikante Aktivitäten für das System sein. Der Nutzung des Geldautomaten durch den Kunden ist zum Beispiel ein Anwendungsfall. Die Eingabe einer PIN-Nummer ist es nicht.

Es gibt eine Grauzone zwischen diesen beiden Extremen. Wie wir sehen werden, ist es oft nützlich, sehr grosse Anwendungsfälle in kleinere Sub-Anwendungsfälle zu unterteilen. Wir können zum Beispiel Bargeld lagern, Bargeld auszahlen und Kontoabfragen als Sub- Anwendungsfälle definieren.

Es gibt keine harte und schnelle Regel. Einige Architekten präferieren wenige relativ grosse Anwendungsfälle, andere präferieren eine grössere Anzahl kleinerer Anwendungsfälle. Eine nützliche Faustregel ist, dass jedes praktikable Projekt nicht mehr als 30 Anwendungsfälle erfordern sollte (wenn es mehr benötigt, sollte es in separate Projekte aufgeteilt werden).

Wir stellen dann die Beziehungen zwischen den Anwendungsfällen und Akteuren in einem oder mehreren Anwendungsfalldiagrammen dar. In grösseren Projekten wird mehr als ein Diagramm benötigt. Normalerweise werden Gruppen zusammengehöriger Anwendungsfälle in einem Diagramm dargestellt.

Wir müssen dann eine detailliertere Spezifikation für jeden Anwendungsfall erstellen. Dies beinhaltet sein normales Verhalten, alternatives Verhalten und alle Vor- und Nachbedingungen. Dies erfolgt in einem Dokument, dass häufig als Anwendungsfalldokumentation oder Anwendungsfallszenario bekannt ist.

Da Anwendungsfälle natürlicherweise funktional sind, benötigen wir ein Dokument, um die nicht-funktionalen Anforderungen (Kapazitäts-, Leistungs-, Umgebungsanforderungen usw.) aufzunehmen. Diese Anforderungen werden in einem Dokument Ergänzende Anforderungsspezifikation festgehalten.

4.2.1. Prozess-Schritte

Die Schritte im Anforderungs-Erfassungs-Prozess können wie folgt zusammengefasst werden.

  1. Das Visions-Dokument beinhaltet eine Gesamtsicht auf das Problem und die gewünschten Charakteristika seiner Lösung.

  2. Identifizieren Sie die Anwendungsfälle und Akteure aus dem Visions-Dokument und stellen deren Beziehungen zueinander in einem oder mehreren Anwendungsfalldiagrammen dar.

  3. Erstellen Sie für jeden Anwendungsfall eine detaillierte Anwendungsfall-Spezifikation, die das normale und alternative Verhalten, die Vor- und Nachbedingungen beinhaltet.

  4. Fassen Sie alle nicht-funktionalen Anforderungen in einer Ergänzenden Anforderungs-Spezifikation zusammen.

In jedem iterativen Entwicklungsprozess werden wir priorisieren und frühe Iterationen werden sich darauf fokussieren, das hauptsächliche Verhalten der wichtigsten Anwendungsfälle aufzunehmen.

Die meisten modernen Anforderungs-Erfassungs-Prozesse unterstellen, dass es wichtig ist, dass der maßgebliche Repräsentant des Kunden während dieses Prozesses vollständig involviert ist.