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.