Jörg Friedrich

Ziel der Anforderungsanalyse ist es nicht nur, zu konsistenten Modellen zu kommen, welche die Anforderungen an das neue Softwaresystem adäquat beschreiben, sondern diese Modelle auch mit den Partnern kommunizieren zu können. Ein Modell ist nur dann praktisch effektiv, wenn alle Partner des Analyseprozesses es verstehen und bearbeiten können.
Es hat sich deshalb als effektiv erwiesen, nicht übermäßigen Gebrauch von Begriffen und Symbolen der Objektorientierten Designverfahren zu machen, insbesondere dann, wenn die Partner aus den Fachabteilungen mit dieser Terminologie nicht hinreichend vertraut sind. Statt immer wieder auf die Existenz von Klassen und Instanzen oder Objekten zu verweisen, sollte konkret über Dokumente und Akteure sowie über andere Elemente des Systems gesprochen werden.
Objekteigenschaften oder Attribute sind nichts anderes als diejenigen Merkmale, welche zur genauen Bestimmung eines Elementes nötig sind bzw. diejenigen, welche im Zusammenhang mit unserem Geschäftsprozess relevant sind, weil sie durch ihn geändert werden oder weil Entscheidungen auf ihnen basieren.

Wenn der (objektorientiert denkende) Designer oder Analyst nach Objektmethoden oder Operationen fragt, meint er nichts anderes als die Frage, was man mit den Systemelementen machen kann, wie man sie verändern kann. So sollte die Frage auch gestellt werden.

Letztlich kommt es immer darauf an, dass die drei Partner im Analyseprozess (Fachabteilung, Analyst, Entwickler) eine gemeinsame Sprache finden und sicher sein können, dass sie das gleiche meinen, wenn sie das gleiche sagen. Objektorientierte Denk- und Herangehensweisen sind für den Analysten hilfreich, in der Kommunikation mit der Fachabteilung sollten deshalb objektorientierte Begrifflichkeiten aber nicht unbedingt im Vordergrund stehen.

Im Prozess der Anforderungsanalyse müssen wir zwei Handlungskomplexe unterscheiden:
1. Die eigentliche Anforderungsentwicklung, in deren Verlauf aus Problemen und Zielen plausible und valide Anforderungsdokumentationen spezifiziert werden
2. Das Anforderungsmanagement, in welchem sozusagen auf einer übergeordneten Handlungsebene die Pflege, Versionierung und Weiterentwicklung von Anforderungsspezifikationen während des Gesamtprojektes betrieben wird.
Anforderungsmanagement
Zum Anforderungsmanagement gehört zunächst die Definition der verschiedenen Verfahren, welche im Gesamtprozess der Anforderungsanalyse zum Einsatz kommen. Hierzu gehören insbesondere das Anforderungsentwicklungs- und das Änderungskontrollverfahren.
Ein weiterer Schwerpunkt ist das definieren der Anforderungsbaseline sowie das Änderungsmanagement (Versionierung, Änderungskontrollgremium, Statusüberwachung).
Anforderungsentwicklung
Im Mittelpunkt der Anforderungsentwicklung steht die Kommunikation zwischen dem, der die Anforderung stellt und dem, der sie zu analysieren, zu objektivieren, zu strukturieren und zu dokumentieren hat – dem Anforderungsanalysten. Die Bedeutung der Kommunikation ist dabei nicht zu unterschätzen. Aus der großen Bedeutung der Kommunikation für das Erstellen optimaler Anforderungsspezifikationen ergeben sich zwei entscheidende Bedingungen:
1. Anforderungssteller und Anforderungsanalyst müssen eine gemeinsame Sprache sprechen.
2. Anforderungssteller und Anforderungsanalyst müssen vor allem viel Zeit in die Anforderungsanalyse investieren.
Die Anforderungsentwicklung kann – entsprechend der oben genannten Tätigkeiten des Analysten – im wesentlichen in vier Phasen unterteilt werden: Erhebung, Analyse, Spezifikation und Validierung.
Ein gut strukturiertes und definiertes Anforderungsmanagement ist Voraussetzung für erfolgreiche Anforderungsentwicklung. Zu Beginn des Projektes wird das Anforderungsentwicklungsverfahren definiert, dies ist genau genommen ein Bestandteil des Anforderungsmanagements. Wenn Standards im Unternehmen definiert sind, sind diese auf ihre Anwendbarkeit und Aktualität zu prüfen.
Vor der eigentlichen Erhebung steht die Benennung Anspruchsgruppen und die Auswahl von geeigneten Repräsentanten für die Durchführung der Anforderungsanalyse, insbesondere die Anspruchsgruppe der Benutzer ist dann weiter zu differenzieren, Benutzerklassen werden gebildet und Produktchampions identifiziert.
Neben der Durchführung spezieller Veranstaltungen (Interviews, Workshops) gehören auch das Studium von Dokumenten und die Beobachtung der Benutzer bei der Arbeit zur Anforderungserhebung.
Unter Analyse verstehen wir hier das Sichten, Strukturieren, Klassifizieren und Objektivieren der erhobenen Fakten. Mit einem aus der Meteorologie übernommenen Begriff können wir diese Phase auch als Synopsis (Zusammenschau) bezeichnen. Das Ergebnis sind insbesondere die identifizierten Anwendungsfälle.
Bei der Spezifikation kommen die verschiedenen Modellierungsansätze zum Einsatz. Neben weiter ausgeprägten Anwendungsfalldokumentationen entstehen hier Prozess- und Objektmodelle sowie logische Datenmodelle und (Papier-)Prototypen.

Bei der Validierung steht wiederum die Kommunikation mit den (Vertretern der) Anspruchsgruppen im Vordergrund. Anforderungstests werden durchgeführt, die Spezifikationen werden nach formalen und inhaltlichen Kriterien bewertet.

Zunächst muss Klarheit darüber bestehen, was gemeint ist wenn wir von Anforderungen sprechen. Die Abgrenzung zu Begriffen wie „Problem“, „Lösungsvorschlag“, „Funktionalität“ ist dabei genauso wichtig wie die Frage, welche Anforderungsarten und –ebenen es gibt.
Anforderungen sind die Erwartungen von Menschen an ein System, mit dessen Hilfe sie ihre Arbeit erledigen wollen.

Wie kommt es zu Anforderungen?

Vor der Anforderung steht immer ein Problem. Menschen haben ein Ziel, können dieses mit den ihnen zur Verfügung stehenden Mitteln aber nicht erreichen. Sie suchen nach einem Werkzeug, mit welchem sie das Ziel erreichen können. An dieses Werkzeug stellen sie die Anforderung, dass mit seiner Hilfe das Ziel erreichbar sein möge.
Wir sehen an dieser Überlegung bereits einen ganz wesentlichen Aspekt der Anforderungsanalyse, welcher uns immer begleiten wird: In ihrem Zentrum steht nicht die Lösung, nicht die Frage, wie das Ziel letztlich tatsächlich erreicht wird, sondern das Verstehen des Problems und damit des Zieles!

Anforderungsanalyse ist primär nicht die Suche nach Lösungen sondern die Dokumentation von Problemen und Zielen auf eine Weise, dass daraus Lösungen abgeleitet werden können. Das ist deshalb besonders wichtig, weil in der Anforderungsanalyse häufig viel zu früh über mögliche Lösungen gesprochen wird, ohne dass das Ziel bereits hinreichend klar spezifiziert ist. Wenn die Beteiligten aber keine klare und gemeinsame Vorstellung von den Zielen haben, können sie auch keine wirkliche Übereinstimmung darin haben, ob eine angestrebte Lösung tatsächlich zielführend ist, ja, sie werden von der „Lösung“ die sie gemeinsam beschreiben, oft ganz unterschiedliche Vorstellungen haben, da jeder seine Zielvorstellungen in die „Lösung“ hineininterpretiert.

Welche Ansätze zur Beschreibung von Geschäftsprozessen gibt es?
1. Die erste Frage, die gestellt werden kann, um Geschäftsvorfälle zu beschreiben und zu verstehen, heißt: Was wird getan? Welche Prozesse laufen ab und in welcher Reihenfolge, wann werden Entscheidungen getroffen, die den Prozessablauf ändern, wann ist ein Prozess abgeschlossen? In welche Teilprozesse zerfällt ein Prozessschritt?

Dieses Verfahren wird Geschäftsprozessanalyse genannt, im Ergebnis entstehen Geschäftsprozessmodelle.
2. Der nächste Ansatz lässt sich durch die Frage fassen: Womit beschäftigen sich die Akteure in den Geschäftsvorfällen? Welche Dokumente werden erzeugt, bearbeitet, verändert, vernichtet und welche Ressourcen werden dafür benötigt? Was wird mit diesen Objekten getan? Wie sind sie aufgebaut, bestehen sie aus Teilobjekten? Ein solches Verfahren ist die Geschäftsobjektmodellierung.
3. Ein weiterer Ansatz besteht darin, nach den Daten, den Informationen zu fragen, die im Geschäftsvorfall benötigt, erzeugt, verändert und gelöscht werden. Welche Entitäten gibt es, welche Attribute haben diese? Wie hängen die Entitäten miteinander zusammen. Welche Restriktionen bestehen für die Attribute, welche Datentypen haben sie? Dieses Verfahren ist die logische Datenmodellierung.
4. Schließlich gibt es die Möglichkeit, zu versuchen, die Interaktion des Benutzers mit der Software unmittelbar zu beschreiben. Welche Menüpunkte sollen existieren, wie sollen Dialoge aufgebaut sein, welche Elemente sollen diese haben, welche Aktionen sollen ausgeführt werden können und mit welchem Ergebnis? Ziel dieses Ansatzes ist die Erstellung eines „Papierprototypen“.

Objektkategorien
Auf der Suche nach den für unser System relevanten Objekten ist es sinnvoll, zunächst die Frage zu stellen, nach was für Objekten wir eigentlich suchen.
In Geschäftsvorfällen werden Akteure tätig, die unter Benutzung von Ressourcen kommunizieren und zu diesem Zwecke Dokumente erstellen und austauschen.
Damit haben wir drei Kategorien von Objekten ausgemacht:
Definitionen:

Akteure sind die aktiven Objekte des Systems. Sie führen Aktionen mit den anderen Objekten des Systems aus. Akteure sind Menschen, zum Zwecke der Abstraktion oder der Vereinfachung eines Modells können auch wohldefinierte Gruppen von Menschen (z.B. Unternehmen, Institutionen, Behörden) als Akteure angesehen werden.
Ressourcen sind die Objekte, welche die Voraussetzungen, die Grundlage für die Tätigkeit der Akteure bilden. Sie zeichnen sich dadurch aus, dass ihre Eigenschaften durch die Geschäftsprozesse nicht geändert werden.
Dokumente sind Informationspakete, die im Geschäftsprozess von den Akteuren erzeugt und an andere Akteure weitergegeben werden.

Darüber hinaus gibt es eine vierte Art von Objekten, die wir als „abstrakte Objekte“ bezeichnen. Diese erkennen wir daran, dass sie ebenso wie die Dokumente Informationspakete darstellen, welche jedoch im Zusammenhang oder als Bestandteil verschiedener anderer Objekte an unterschiedlichen Stellen des Systems gefunden werden können.
Das iterative Vorgehen
Wie schaffen wir es, möglichst umfassend und vollständig die Objekte aufzuspüren, welche zu einem System gehören?
Da niemand auf Anhieb alle Objekte vollständig benennen können wird (ganz zu schweigen davon, dass er dann nicht beweisen kann, wirklich alle benannt zu haben), bietet sich ein iteratives Verfahren an.
Dazu wird eine Menge von Schritten immer wieder durchlaufen, bis eine Endbedingung erfüllt ist.
Wir beginnen damit, einige offensichtlich enthaltene Akteure, Dokumente und Ressourcen zu benennen. Dann befragen wir jeden Akteur, wie er im zeitlichen Ablauf des Geschäftsvorfalles die Dokumente erzeugt oder erhält, verändert, weitergibt, welche Ressourcen er dafür nutzt und mit welchen anderen Akteuren er auf diese Weise kommuniziert. Dabei finden wir weitere Akteure, Dokumente und Ressourcen.
Wir wiederholen dieses Verfahren
1. für die neu gefundenen Akteure
2. hinsichtlich der neu gefundenen Dokumente mit den bereits befragten Akteuren
solange, bis die neue Runde keine neuen Objekte mehr produziert. In diesem Moment sollte das System vollständig und umfassend dem Geschäftsvorfall entsprechen.
Wir werden natürlich in der Praxis feststellen, dass dieses Ziel selten auf Anhieb zu erreichen ist. Das liegt daran, dass Akteure bei der Beschreibung ihrer Tätigkeit oft selten auftauchende Spezialfälle vergessen. Wir minimieren dieses Problem, indem wir alle Akteure in den Prozess einbeziehen.
Neben dem Effekt, dass wir mit dem iterativen Vorgehen einem vollständigen Modell sehr nahe kommen können haben wir auf diese Weise die Möglichkeit, das Denken der Akteure in Prozessen und Abläufen für das Finden der Geschäftsobjekte zu nutzen.

Wir denken in Abläufen, Prozessen, Tätigkeiten
Jeder Versuch einer Beschreibung eines System beginnt mit der Beschreibung der Tätigkeit der Akteure, das heißt zunächst der Arbeitsabläufe der handelnden Personen.
Wenn wir einen Geschäftsvorfall durch den Einsatz eines Softwaresystems verbessern wollen, werden wir uns diesen Geschäftsvorfall zunächst durch einen Akteur schildern lassen. Dieser tut dies, indem er uns den zeitlichen Ablauf seiner Tätigkeiten im Zusammenhang mit dem Geschäftsvorfall schildert. Das Verfahren zur objektiven Abbildung dieser Prozesse ist die Geschäftsprozessmodellierung.
Für die Konzeption langlebiger integrierter Softwarelösungen hat dieses Verfahren, wenn es allein eingesetzt wird, jedoch entscheidende Nachteile.
Abläufe ändern sich
Bedingt durch ständige, immer schnellere Änderung der Rahmenbedingungen, Voraussetzungen und Ziele der Geschäftsprozesse sind diese einer ständigen Veränderung unterworfen. Aber das ist nicht der einzige Grund für gravierende Änderungen in den Abläufen:
• Abläufe ändern sich durch den Einsatz der Software, da diese die Voraussetzungen und Träger der Prozesse unmittelbar beeinflusst.
• Abläufe ändern sich durch den Einsatz der Software, da diese neue Möglichkeiten, Rahmenbedingungen und Wünsch schafft.
Objekte sind relativ stabil
Während sich also die Abläufe ständig verändern und damit auch Änderungen des Prozessmodells und somit auch der Software provozieren, sind die beteiligten Akteure, die von ihnen verwendeten Ressourcen sowie die dabei erzeugten Dokumente in ihrer Beschreibung und in ihren Grundfunktionen relativ stabil. Auch wenn z.B. das genaue Verfahren der Anmeldung zu einem Seminar inklusive der Genehmigung, der Prüfung der Teilnahmevoraussetzungen u.a. Prozesse sich ändern kann, wird es in diesem Verfahren immer einen Seminarteilnehmer, einen Seminarkalender, eine Anmeldebestätigung geben.
Objekteigenschaften sind langlebig
Wenn wir uns die Objekte genauer betrachten stellen wir fest, dass auch die Eigenschaften, durch welche sie bestimmt werden und welche für das Funktionieren des Geschäftsprozesses wichtig sind, über lange Zeit die gleichen bleiben. So werden der Seminartermin und das Seminarthema dauerhaft Informationen über die Seminarveranstaltung sein, welche für die Anmeldung zum Seminar von Bedeutung sind.
Operationen auf Objekten können isoliert betrachtet werden.Die eigentlichen Prozesse, welche den Geschäftsvorfall ausmachen, können wir als Operationen ansehen, die durch die Akteure an den Objekten ausgeführt oder initiiert werden. Auch diese Operationen sind relativ langlebig in dem Sinne, dass sich ihr äußeres Erscheinungsbild, d.h., die Informationen, welche für ihre Ausführung benötigt werden sowie ihr Ergebnis, nicht häufig ändert. Ihr genauer Ablauf wiederum, der sich ändern kann, kann nun losgelöst von den anderen Operationen des Systems betrachtet und variiert werden.