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.