Jörg Friedrich

Interviewsituationen gibt es in ganz unterschiedlichen Zusammenhängen. Schaltet man morgens das Radio ein, hört man die Moderatorin im Gespräch mit einem Politi-ker oder einer Wissenschaftlerin zu einem aktuellen Thema. Abends kann es gesche-hen, dass das Telefon klingelt und ein Marktforschungs- oder Meinungsinstitut unsere Ansichten zu bestimmten Themen, unsere Vorlieben, unsere Verhaltensweisen er-fragt. Später sehen wir im Fernsehen vielleicht noch ein Gespräch eines Journalisten mit einem Schriftsteller über sein neuestes Buch.
All das sind Interviews. Sie haben Gemeinsamkeiten, aber auch viele Unterschiede hinsichtlich ihrer Zielsetzung und ihrer Methode. Für Interviews in der Anforde-rungsanalyse für Softwareprojekte kann man aus diesen verschiedenen Methoden eine Menge lernen, wenn man das eigene Ziel richtig in die verschiedenen Zielstel-lungen der Interviewführung einordnet.
Die Methode der Interviewführung ist unterschiedlich systematisch untersucht. Die umfangreichsten Untersuchungen, die auch in Lehrmethoden münden, gibt es wohl zum journalistischen Interview.
Weitere methodische Ansätze zur Interviewführung finden sich in der systematischen Grundlegung der empirischen Sozialforschung, auch wenn hie immer wieder ein Mangel an Methode beklagt wird. Das Ziel der Interviewführung in diesem Gebiet weist jedoch eine große Ähnlichkeit mit den Zielen der Anforderungsanalyse in Softwareprojekten auf. Hier wie dort geht es um das Gewinnen gültiger, stabiler, letztlich objektivier Informationen gesellschaftlicher oder organisatorischer Zusam-menhänge und Handlungsgrundlagen.
Letztlich finden alle Interviewformen bei der Anforderungsanalyse Anwendung. Wichtig ist, sich darüber klar zu werden, welche Formen bei welcher Zielsetzung sinnvoll sind und wie sie erfolgreich benutzt werden können.

wird fortgesetzt…

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.

Wenn wir uns um die Inhalte von Begriffen wie „Religion“ und „Ideologie“, um den Sinn, den wir ihnen geben, etwas mehr bemühten, würden wir vermutlich zunächst darauf stoßen, dass jeder von uns eine Religion und auch eine Ideologie hat.

Religion – um mal eine kurze Begriffsbestimmung anzugeben – ist vielleicht immer so etwas wie eine normative Handlungsgrundlage die ihre Basis in Sinn oder Zwecksetzungen außerhalb des Menschen (nämlich bei Gott oder bei der Natur oder im Kosmos) hat.
Ideologie enthält nicht nur Ideo, sondern auch den logos, ich würde Ideologie als Ideen-System bezeichnen, Ideen, die aufeinander aufbauen und die die Ableitung weiterer Ideen erlauben.
Ideologien sind sicherlich häufig religiös fundiert.
Beide Begriffe werden heute meist abwertend benutzt, man wirft dem Gegner vor, einer Religion oder einer Ideologie anzuhängen und behauptet dabei gleichzeitig, die eigenen Ideen basierten nicht auf anderen Ideen oder letztlich auf Glauben an jenseitiges, sondern auf Wahrheit und logischer Erkenntnis. Aber auch das lässt sich meist als reiner Glaube, als Ideologie enttarnen. Wahrscheinlich wäre also Religions- und Ideologiekritik letztlich zunächst Selbstkritik. Ob das einem Menschen wirklich möglich ist, ist allerdings fraglich, denn Glaube und Ideologie spielen ja eine sehr stabilisierende Rolle im Leben eines Menschen, Wer kann schon die Fundamente erschüttern wollen, auf denen er steht?

Ein wirkliches Paradoxon scheint mir zu sein, dass es, wie ich gerade feststelle, mehr positive ungerade Zahlen gibt als positive gerade Zahlen.

Beweis:

Man nehme irgendeine positive Zahl und zähle alle positiven geraden Zahlen, die kleiner oder gleich dser Zahl sind, und alle positiven geraden Zahlen, die kleiner oder gleich dieser Zahl sind.

Es ergeben sich zwei Möglichkeiten:

Ist die beliebig gewählte Zahl eine gerade Zahl, so ist die Anzahl der geraden Zahlen gleich der der ungeraden Zahlen.
Ist die beliebig gewählte Zahl eine ungerade Zahl, so ist die Anzahl der geraden Zahlen um 1 geringer als die der ungeraden Zahlen.

D.h. im Mittel gibt es eine halbe ungerade Zahl mehr als gerade Zahlen!

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.

Oft neigt man dazu, den Menschen mit den Menschen gleichzusetzen, dabei hat der Mensch mit den Menschen wenig gemein