Jörg Friedrich

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“.

Das Ziel der Anforderungsanalyse für Softwaresysteme ist letztendlich die hinreichende Beschreibung von Geschäftsvorfällen, die so noch nicht existieren. Nur, wenn die Struktur eines Geschäftsvorfalles, der von der erst zu entwickelnden Software unterstützt werden soll, bekannt ist, können die Anforderungen an diese Software analysiert werden. Da aber der Geschäftsvorfall in seiner Struktur von eben dieser Software abhängt, bewegen wir uns in einem „Teufelskreis“. Diesen Teufelskreis gilt es zu durchbrechen.
Der Prozess der Anforderungsanalyse für Softwaresysteme ist mehrstufig und umfasst verschiedene Aspekte. Abhängig von den konkreten Rahmenbedingungen kann er unterschiedlich komplex sein. Er umfasst:
• die Spezifikation der fachlichen Anforderungen
• die Einordnung in die gesamte IT-Infrastruktur des Unternehmens
• die Identifikation von Anwendungsfällen und die Ableitung von Testfällen.
Gleichzeitig wird ein Verfahren benötigt, mit welchem sichergestellt wird, das die gefundene Beschreibung vollständig und umfassend ist. Dies kann am ehesten sichergestellt werden, wenn die Geschäftsvorfälle mehrdimensional analysiert werden, wenn mehrere Ansätze parallel verfolgt werden, die gewissermaßen orthogonal zueinander sind. Ein wichtiges Merkmal für die Vollständigkeit der Beschreibung ist dann die innere Konsistenz der Analyseteile: Jedes Element der Beschreibung innerhalb eines Ansatzes muss sich auch in den anderen Beschreibungsansätzen wieder finden lassen.

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.

Zwei Ziele hat ein Entwicklungsprojekt: Ein Ergebnis, welches den Auftraggeber
zufrieden stellt und die Einhaltung eines vorgegebenen Kosten- und Zeitplanes.
Aber die Erfahrung fast jedes Projektmanagers zeigt, dass beides zusammen
selten zu haben ist. Und das gilt nicht nur für Softwareprojekte, die gleichen
schmerzhaften Erfahrungen machen Werbefachleute genauso wie
Produktentwickler in der Automobilindustrie.
Wenn Sie diese Seiten gelesen haben, werden Sie nicht nur wissen, warum das so
sein muss. Sie werden nicht nur Verständnis für gestresste Projektverantwortliche
in ehrgeizigen Entwicklungsprojekten bekommen, die sich immer wieder für
Verzögerungen rechtfertigen müssen, die immer wieder nach neuen Mitteln rufen
oder die am Schluss ein Produkt präsentieren, das keiner so recht haben will.
Sie werden beim Lesen eine Vorstellung davon bekommen, wie die
althergebrachten Methoden der Projektplanung, die vor einem Jahrhundert
entwickelt wurden und die heute noch immer den Kern fast aller
Projektmanagementsoftware bestimmen, modifiziert werden müssen, damit
Entwicklungsteams erfolgreich Produkte hervorbringen und sich dabei an einmal
abgegebene Kosten- und Terminzusagen halten können.
weiter lesen…