Begriffsdefinition - Von was redet der Typ überhaupt?

Business Analysis / Anforderungsanalyse / Geschäftsprozess-Analyse / Fachanalyse - Was ist das?
Die Frage des Nachbarn
Berufsbild - Was macht ein Business Analyst den ganzen Tag?
Einordnung der Anforderungsanalyse innerhalb eines IT-Projekts - Was wollen wir überhaupt?
Ein Beispiel - Die Fläche eines Dreiecks
Exkurs - kleine Katastrophen

Business Analysis / Anforderungsanalyse / Geschäftsprozess-Analyse / Fachanalyse - Was ist das?

Ich benutzte die Begriffe Business Analysis, Anforderungsanalyse, Geschäftsprozess-Analyse und Fachanalyse redundant, obwohl dies nicht ganz korrekt ist. Der Hintergrund liegt darin, dass es im deutschen Sprachgebrauch keine konkrete Bezeichnung für die Bezeichnung Business Analyst gibt. Die englische Sprache unterscheidet sehr klar in den "business analyst" und den "analyst/programmer", wogegen man im Deutschen eigentlich nur vom "Analytiker" spricht, oder, wenn die technische Seite der Analyse stärker betont werden soll, vom "Systemanalytiker". Der analyst/programmer ist sehr technisch, er befasst sich wie auch Software-Architekt, Software-Designer oder Software-Entwickler alleine mit dem "Wie", also mit der Lösung eines Problems. Der business analyst definiert dagegen das "Was", also die Anforderungen an das Produkt, das gebaut werden soll. Seine Fokussierung ist zwar fachlich, aber da er das Bindeglied zwischen Technik und Fachabteilung darstellt, muss er beide Felder im Blickfeld behalten.

Das Resultat einer business analysis ist ein Anforderungsdokument, ein Konzept, das möglichst uninterpretierbar beschreibt, was das gewünschte Software-Produkt am Ende tun soll. Im allgemeinen Projekt-Management-Sprachgebrauch wird dieses Konzept Lastenheft genannt, im IT-Sprachgebrauch kommt der Begriff aber kaum vor. Dafür hört man den Begriff Anforderungsdokument, Fachkonzept oder Software Requirements Document (SRD). Auf diesen Seiten benutze ich den Begriff Anforderungsdokument.

Die Beschreibung, was zu tun ist, kann in der Theorie eindeutig und uninterpretierbar erfolgen, in der Praxis ist das aber nicht ganz ohne Tücken, und die Wahrheit steckt am Ende in der Software.

Betrachten wird das klassische Bild eines Programms nach dem Black-Box-Prinzip, so sehen wir die EVA-Idee. EVA steht für Eingabe, Verarbeitung, Ausgabe.

Zur eindeutigen, uninterpretierbaren und vollständigen Beschreibung eines jeden Software-Produkts gehört:

Die Eingabe: Alle Datenquellen müssen beschrieben werden. Hierzu findet eine Datenanalyse (Geschäftsdatenanalyse, business data analysis) statt.
Die Verarbeitung: Alle Prozesse, die auf die eingehenden Daten aus den Datenquellen angewendet werden sollen, alle Umformungen, alle Algorithmen müssen beschrieben werden. Hierzu findet eine Geschäftsprozessanalyse (business process analysis) statt. Dies ist das Hauptthema dieser Seiten.
Die Ausgabe: Alle gewünschten Resultate von der Speicherung in irgendwelchen Datensenken (z.B. Datenbanken), über gedrückte Reporte bis hin zu Bildschrimdialogen, aber auch Ausgabeströme für andere Prozesse müssen beschrieben werden. Hierzu findet wiederum eine Datenanalyse statt.

Die Geschäftsprozess-Analyse (business process analysis) ist bei der Verarbeitung anzusiedeln. Wird von Geschäftsdatenanalyse (business data analysis) gesprochen, so meint man damit vor allem die eingehenden Daten, jedoch auch die resultierenden Daten. Der Begriff Anforderungsanalyse umfaßt darüber hinaus noch weitere Anforderungen, z.B. an Datenmengen, Performance oder Robustheit des Systems. Fachanalyse umfaßt am ehesten die ausschließlich die Fachabteilung betreffende Geschäftsprozess- und Geschäftsdaten-Analyse.

Zum Verständnis wichtig ist, dass ein Geschäftsprozess nicht zwingend etwas mit Software zu tun haben muss. Im Jahr 1960 waren Computer eine neue und exotische Sache, aber die Geschäftswelt funktionierte recht gut; vielleicht sogar besser als heute. Innerhalb einer betrieblichen Organisation kann ein Geschäftsprozess z.B. das Abheften eines Beleges beinhalten. Dies ist eine Tätigkeit, die zwar als Teil der Geschäftstätigkeit notwendig ist und auch als Arbeitsablauf (und somit Geschäftsprozess) definiert und in einer Arbeitsvorschrift oder in einem Qualitätshandbuch festgehalten sein kann, jedoch nicht zwingend etwas mit einem IT-System zu tun haben muss.

Ein Software-Produkt, also ein Programm, bildet lediglich die echte Welt ab. Damit ein Geschäftsprozess in einem Stück Software abgebildet werden kann, muss zuerst der Geschäftsprozess auf dem Papier funktionieren. Der Weg dorthin soll auf diesen Seiten beschrieben werden.

Die Frage des Nachbarn

Als ich einmal im Sommer 2002 in meiner Heimatstadt zu Besuch war, fragte mich mein Nachbar, ein Handwerksmeister und Abteilungsleiter eines mittelständischen Betriebes ohne jeden IT-Hintergrund, damals schon einige Jahre in Rente, was ich nun eigentlich genau als Beruf mache. Ich war etwas in Verlegenheit, und er bemerkte dies. "Erkläre es mir so, wie wenn Du es einem Kind erklären solltest." forderte er mich auf.

"Nun", sagte ich, "stellen wir uns vor, ein Programm sei ein Haus. Jetzt kommt jemand zu Dir und sagt zu Dir, dass Du ein Haus für ihn bauen sollst. Das machst Du, vielleicht so eines, wie Du selber hast. Dann kommt der Auftraggeber, schüttelt den Kopf, und erklärt Dir, dass er eher an eine Villa und nicht an eine Doppelhaushälfte gedacht hat." Mein Job im Rahmen der Software-Entwicklung ist es im übertragenen Sinne, dass ich mich mit dem Auftraggeber hinsetze und ihn so lange ausfrage und seine Ideen so weit strukturiere und nieder schreibe, bis der Architekt anfangen kann, einen Bauplan zu zeichnen. Außerdem will ich wissen, wofür er das Haus hernimmt, ob er vielleicht irgendwo einen Gasanschluss braucht, vielleicht sogar, ob er irgendwo Tapeten in einem Zimmer haben will. Die Farbe der Tapeten interessiert mich aber nicht mehr.

Berufsbild - Was macht ein Business Analyst den ganzen Tag?

Aufgabe des Business Analysten ist es, die Kundenanforderungen aufzunehmen und so zu formulieren, dass sie vom technischen Personal verstanden und in ein IT-System umgesetzt werden können. Bei http://www.rational.com/media/whitepapers/rup_bestpractices.pdf S.10 wird treffend festgestellt:

One of the major problems with most business engineering efforts, is that the software engineering and the business engineering commuinity do not communicate properly with each other.This leads to the output from business engineering is not being used properly as input to the software development effort, and vice-versa.

Die Hauptarbeit des Business Analysten ist zuhören, hinterfragen, verstehen, strukturieren und dokumentieren. Er stellt das Bindeglied zwischen Fachabteilung und IT-Team her.

Ein Business Analyst hat keinen kreativen Anspruch, er denkt sich keine Dinge aus. Die Idee ist dem Kunden überlassen. Die Vision arbeitet der Kunde häufig bereits mit dem Analytiker aus. Das Analysedokument ist das Produkt, das der Analytiker mit Hilfe des Kunden und in seinem Auftrag erarbeitet. Wenn ein Business Analyst kreativ ist, dann bei der Ausarbeitung von Algorithmen, die er aus den Beispielsammlungen der Fachabteilung erstellt.

Allerdings wirkt ein Business Analyst auch an der Gestaltung von Geschäftsprozessen mit. Im Rahmen einer Analyse erarbeitet der Analytiker eine hohe Sicht auf die gesamte zu untersuchende Organisation. Dabei können Prozesse verbessert oder vereinfacht werden. Man sollte sich den Business Analysten allerdings nicht als wichtigtuerischen Berater vorstellen, der ja irgendwie seine Existenz rechtfertigen muss. Wenn ein IT-System gebaut wird, dann hat dies zwangsläufig Rückwirkungen auf die abgebildeten Geschäftsprozesse. Ziel soll es ja sein, das Leben leichter und nicht schwerer zu machen. Die Gestaltung bzw. Umgestaltung der Geschäftsprozesse muss also neben einem finanziell meßbaren Gewinn für das Unternehmen auch zu einem Gewinn an Arbeits- und Lebensqualität für den einzelnen Mitarbeiter führen.

Die Tätigkeit ist sehr kundennah, aber nicht unbedingt vollkommen technikfern. Wenn ein Business Analyst sich die Kundendaten anschaut und diese Daten bereits in einem IT-System vorhanden sind, dann wird er selbstständig die Datenbank auswerten. Hat er die notwendigen technischen Kompetenzen, so wirkt er beratend beim Software-Design mit, u.U. wird er sogar gelegentlich als pair programmer aktiv.

Wichtigstes Handwerkszeug des Business Analysten ist sein Kopf. Er denkt. Er vollzieht die Gedankengänge des Fachanwenders nach und formuliert sie in einer Sprache, die sowohl der Fachanwender als auch der Software-Entwickler verstehen. Er versteht Prozesse und kann daher diese Prozesse dokumentieren und auch optimieren.

Das Zuhören setzt ein hohes Maß an Geduld und sozialer Kompetenz voraus. Der Job es Business Analysten ist also nichts für Eigenbrötler oder ungeduldige Choleriker. Vielmehr muss ein Analytiker auch mit dem cholerischen Anfall eines ungeduldige Kunden umgehen können. Frustrationstoleranz ist also angebracht. Ein Business Analyst läßt vor allem seine Fachanwender erzählen und er fragt auch nach, denn er muss das Arbeitsfeld des Fachanwenders so weit verstehen, dass er ein Kochrezept schreiben kann, also einen Algorithmus beschreiben, der in einem IT-System abgebildet werden kann. Dieses Zuhören sollte im weiteren Sinne als das Sammeln und Aufbereiten von Informationen verstanden werden. Dies kann im Rahmen von Workshops, Interviews, informellen Treffen in der Teeküche, Beobachtung der Arbeitsschritte und auch in Form direkter Mitarbeit in der zu untersuchenden Organisation geschehen. In besonderen Fällen kann auch mit Fragebögen gearbeitet werden

Die Erfahrung zeigt, dass sehr viele Fachanwender nicht in der Lage sind, ihre eigenen Gedanken strukturiert zu Papier zu bringen. Beim Analytiker entsteht somit häufig der subjektive Eindruck, dass der Fachanwender überhaupt nicht versteht, was er tut. Tatsächlich ist dies natürlich Unsinn: Der Fachanwender versteht sehr wohl, was er tut, er ist allerdings kein Informatiker und hat keine Übung darin, seine Arbeit Programmierer-gerecht zu erklären. Dies liegt einerseits an der Ausbildung und am Anspruch des Fachanwenders an seine Arbeit, andererseits auch an der Zeit, die er nicht hat. Ein mittleres oder großes IT-Projekt soz. nebenbei abzuwickeln funktioniert nicht. Der Anspruch eines Fachanwenders ist reproduktiv, in aller Regel begnügt er sich damit, die Tätigkeit, die er abwickeln soll, Tag für Tag zu reproduzieren. Alle Aufgaben, die jenseits seines Tätigkeitsfeldes existieren, interessieren ihn kaum. Somit ist sich der normale Fachanwender häufig über zwei Dinge nicht im Klaren: Er hat keinen Blick für die Organisation als ganzes und er hat keine Vorstellung der Auswirkungen seiner Arbeit auf sein Umfeld. Der Business Analyst muss jedoch den Blick fürs Ganze haben und dennoch ins Detail gehen können. Er vollzieht also nicht nur die einzelne Tätigkeit eines einzelnen Fachanwenders nach, sondern die einzelnen Tätigkeiten vieler Fachanwender. Und er stellt sie in einen Kontext zueinander.

Ein interessanter Nebeneffekt in manchen kaum durchschaubaren oder nicht recht funktionierenden Organisationen ist, dass die Informationsanalyse, die im Anfangsstadium eines IT-Projekts stattfindet, häufig erstmalig auch für das mittlere oder höhere Management nachvollziehbar macht, was in diesen Organisationen eigentlich passiert. Häufig haben auch, so ganz nebenbei, einzelne Mitarbeiter Aha-Erlebnisse: sie verstehen endlich, warum die Vorarbeit eines anderen Mitarbeiters genau so und nicht anders statt findet oder weshalb im Geschäftsprozess nachfolgende Mitarbeiter bestimmte Forderungen stellen, die lange Zeit nur als Schikane wahrgenommen wurden. Manchmal wird sich der einzelne Mitarbeiter der Wichtigkeit seines eigenen Beitrages zum Gelingen eines Unternehmens erstmalig bewußt. - Dies sind allerdings wie gesagt Nebeneffekte.

Etwas anders gelagert ist der Fall bei anonymen Produkten. Darunter versteht man Produkte, deren Anwender man nicht kennt. Beispiele hierfür sind Massenprodukte wie Textverarbeitungssysteme oder der Webbrowser, vor dem Sie gerade sitzen, oder jede Art von Internetanwendung. Hier sitzt der Ansprechpartner meist in einer Marketing-Abteilung, und der Projektleiter wird häufig die Empfehlung aussprechen, dem Mann oder der Frau vom Marketing nur die Hälfte dessen zu glauben, was er sagt. Beim anonymen Produkt müssen in gewissem Sinne die Bedürfnisse des Endanwenders erraten werden. Natürlich wird nicht geraten, sondern wiederum gefragt oder Studien mit Testpersonen durchgeführt.

Es liegt nahe, dass der Business Analyst die Software-Entwicklung bis zum Ende begleitet. Häufig schreibt er Testkonzepte parallel zur Software-Entwicklung. In jedem Fall hilft er, die Spezifikation zu interpretieren, sollte etwas unklar sein. Ein Richtwert ist, dass eine Spezifikation dann gut ist, wenn nicht mehr als zwei kleine Fehler oder offene Fragen pro Seite von den technischen Leuten gefunden werden, und wenn nicht mehr als ein grober Fehler auf zehn Seiten gefunden wird. Dieser Richtwert gilt selbstverständlich nur für den ersten Wurf einer Spezifikation und muss noch weiter reduziert werden. Die Zahl kann weit höher oder niedriger liegen, je nach dem, wie viel Aufwand in die Spezifikation gesteckt worden ist.

Einordnung der Anforderungsanalyse innerhalb eines IT-Projekts - Was wollen wir überhaupt?

Vgl. hierzu Business Analysis als Bestandteil eines Prozess-Modells bei IT-Projekten für eine ausführliche Darstellung.

Am Anfang eines IT-Projekts steht stets die Idee. Die Formulierung dieser Idee ist meist kurz, kaum mehr als ein paar Zeilen.

Beispiel aus der Praxis

Mein Projektleiter drückte mir einmal eine ausgedruckte E-Mail seines Fachanwenders folgenden Inhalts in die Hand: "Wir wollen Gebühren einführen. Wie lange dauert es? Wieviel kostet es?" Das war alles.

Wir hatten zwar keine Ahnung, wofür die Gebühren erhoben werden sollten, ob es irgendwelche Gebührenmodelle oder Rabatte geben sollte, woher wir wissen, wann die Gebühren anfallen etc. Aber der Kunde hatte eine Idee und sicher auch eine mehr oder weniger klare Vorstellung, von den Gebühren. Gleichzeitig brachte er seine zwei wesentlichen Fragen bzw. Sorgen vor. - Die Angelegenheit dauerte inklusive Bürokratie etwa eineinhalb Jahre und kostete entsprechend viel. Bei Fertigstellung des Produkts war mein Kontrakt schon geraume Zeit beendet.

Die Idee ist vage, in jeder Hinsicht unkonkret. Nur die Leute, die die Idee hatten, können sich wirklich vorstellen, was am Ende rauskommen soll. In jedem kleinen Problem verstecken sich gerne mehrere größere Probleme. Was ist also zu tun?

Aus der Idee heraus muss eine Vision erarbeitet werden die eine Mission erkennen läßt. Dieses Mission-Statement ist eine Art Zusammenfassung, die abhängig von der Projektgröße von einer bis zu einigen Dutzend Seiten reichen kann. Ziel dieses Mission-Statements ist, dass jeder vom Top Manager bis zum Programmierer, der es gelesen hat, eine klare Vorstellung davon bekommt, wohin man eigentlich will. Es reißt alle wesentlichen zu klärenden Fragen an und enthält bereits eine Erfolgsdefinition. Diese Definition von Erfolg kann auch konkrete Kriterien für den Mißerfolg darstellen. Gerade bei anonymen Produkten kann diese Erfolgsdefinition sehr schwierig werden.

Beispiel aus der Praxis

Im Rahmen einer mehrseitigen Zusammenfassung für ein Projekt, die auch als erster Teil einer business specification vorhanden war, nannte der Auftraggeber im Abschnitt Erfolgsdefinition für eine geplante Internetanwendung zunächst eine Zahl x an Benutzern. Würde diese Zahl x erreicht, so sei ein wesentliches Projektziel erreicht. Im Laufe der nachfolgenden ca. einjährigen Analysezeit wurden Zahlen von x bis 15 * x genannt. Eine konkrete Festlegung erfolgte im letzten Moment, als die Server dimensioniert wurden und somit die Kostenfrage auf dem Tisch lag. Man einigte sich auf 5 * x. Die tatsächliche Menge war am Ende 1,5 * x.

Die Zahl der Anwender ist einer der wesentlichen projektkritischen Parameter bei Internetanwendungen. Denn abhängig von der Zahl und dem Benutzerverhalten (wann und wie oft kommen wie viele Seitenaufrufe) muss die Hardware dimensioniert und die Software optimiert werden. Diese eine Zahl kann, falls sie zu groß dimensioniert ist, dafür sorgen, dass die anfallenden Kosten durch die Anzahl Benutzer nicht gerechtfertigt ist; nicht nur in Bezug auf die Hardware, sondern auch in Bezug auf die Entwicklungskosten bzw. in Bezug auf den gesamten Return On Investment. Sie kann, falls sie zu klein dimensioniert ist, dafür sorgen, dass der Service nicht zur Verfügung steht, da das System überrannt wird. Die Benutzer werden dann häufig nie mehr wieder diesen "schlechten und langsamen" Service nutzen wollen.

Tatsächlich kommt es regelmäßig vor, dass keine klare Definition für Erfolg und Misserfolg eines Projekts angegeben wird. Hier ist das Qualitätsmanagement gefragt, der Business Analyst kümmert sich im Rahmen eines IT-Projekts um diese Frage eher nebenbei. Die Definition von Erfolg impliziert, dass eine Messung der Prognose stattfindet. Dadurch kann spätestens nach Projektende auch der Misserfolg verifiziert ist. Niemand läßt sich gerne nachweisen, dass er nicht recht hatte, und dies dürfte der Hauptgrund dafür sein, dass die klare Festschreibung von Erfolgskriterien vermieden wird. Der Qualitätsmanagementprozess sucht allerdings keinen Schuldigen, sondern meßbare Ergebnisse und kontinuierliche Verbesserung.

Hat man nun eine klare Vision vor Augen, so folgt die Spezifikation. Und das ist die eigentliche Arbeit des Business Analysten. Nach Analyse der Geschäftsdaten und Geschäftsprozesse und nach Aufnahme aller Benutzerwünsche erarbeitet der Analytiker ein Konzept, das die Anwendung im Detail beschreibt. Im Detail bedeutet, dass neben allen Datenquellen, Verarbeitungsschritten und Ergebnissen auch die Benutzeroberfläche beschrieben wird, und zwar bis auf Attributebene und bis hin zur Prüfung einzelner Datenfelder. Spätestens hier beginnt die enge Zusammenarbeit mit Oberflächen-Designern und Software-Designern. Für eine Business Analsten ist es also von Vorteil, wenn auch nicht zwingend eine Bedingung, wenn er die Grundlagen der Ergonomie einer Benutzeroberfläche verstanden hat und selbst Programmiererfahrung mitbringt.

Anhand der Spezifikation, also der vollständigen Beschreibung des gewünschten Leistungsumfangs des IT-Produkts, und nur anhand dieser Spezifikation, kann erstmalig eine seriöse Kostenschätzung stattfinden. Es ist zwar gängige Praxis aber vollkommen sinnlos nach einem Preis zu fragen, wenn man selbst noch gar nicht weiß oder auch nur noch nicht kommuniziert hat, was man will.

Die Spezifikation ist i.d.R. Anlage zum Vertrag, und getestet wird gegen die Spezifikation. Tut ein Programm das, was in der Spezifikation steht, dann wird das Produkt abgenommen. Man sieht hier eine wesentliche Tücke: Ist die Spezifikation falsch oder unvollständig, dann muss letztendlich auch ein falsches Produkt geliefert werden, um die Abnahme zu erreichen. Da man dies jedoch nicht will, ist ein change request, also ein Antrag auf Änderung, fällig. Dafür ist dann eine erneute Kostenschätzung notwendig.

Die Verantwortlichkeit für die Korrektheit der Spezifikation liegt zwar hauptsächlich beim Business Analysten, die Verifikation der Korrektheit und Vollständigkeit ist Sache des Kunden. Spätestens im Moment der Abnahme muss der Analytiker glauben, dass der Kunde die Spezifikation verstanden und für richtig befunden hat.

Abhängig vom Projekt und vom Auftraggeber wird der Business Analyst im Rahmen der technischen Realisierung das Produkts Design und die Entwicklung begleiten und bei der Erstellung von Testplänen nochmals sehr aktiv.

Ein Beispiel - Die Fläche eines Dreiecks

Business Analysten arbeiten am Was. Sie arbeiten also zunächst das Problem aus, die Lösung kommt später dran. Auftraggeber wollen jedoch Lösungen sehen. Somit hat sich in weniger professionellen Umgebungen eine Kultur des Lösungsfetischismus durchgesetzt, die sich mit dem Wie beschäftigt, ohne zu wissen, um was es geht. Ich selbst benutze gerne in Anlhenung an die Unterteilung von Programmiersprachen in maschienen- und problemorientierte Sprachen den Begriff Problemorientierung, der jedoch in der Lösugnsfetisch-Gemeinde nicht beliebt ist. Die Reihenfolge ist stest verstehen, spezifizieren, designen und implenentieren. Die Arbeit an der Lösugn zieht sich natürlich durch das ganze Projekt, die Definition des zu lösenden Problems steht jedoch am Anfang in der Spezifikationsphase. Erst mit Beginn der Desigphase wird an der konkreten Lösung gearbeitet. Problemorientierung bedeutet nicht zu erzählen, warum etwas nicht geht, sondern festzustellen, was genau zu tun ist.

Die Fläche eines Dreiecks zu berechnen, lernt man schon in der fünften Klasse. Später, so in der neunten oder zehnten, stolpert man aber wieder mal darüber. Lehnen Sie sich zurück und kramen Sie einen Augenblick in Ihren Erinnerungen. Vielleicht kommt Ihnen der Sinussatz in Erinnerung, oder auch der Begriff Perimeter...

Es war einmal vor langer langer Zeit ein Programmierer namens Paul, der, zumindest aus Sicht einiger Leute, nichts zu tun hatte, denn er schrieb die Dokumentation für irgendein Programm, das schon seit Monaten im Einsatz war. Nun kommt der Projektmanager Peter vorbei und ruft seinem Programmierer Paul zu: "Der Anwender Anton braucht ein Programm, das ihm den Flächeninhalt eines Dreiecks berechnet. Kannst Du das heute noch hinkriegen? Der Fall ist wie üblich dringend." Wo war doch gleich wieder Bert der Business Analyst? Ach, der trinkt schon wieder einen Kaffee mit dem Anwender Andreas, diesem DAU, doppelt so schlimm wie Anton. Aber manche Sachen kriegt man auf die schnelle hin. Programmierer Paul schaut zur Sicherheit nochmals in der alten Formelsammlung nach und findet:

Er weiß nun, oder glaubt doch zu wissen, wie die Lösung aussieht. Also programmiert er rasch ein, sagen wir mal, C-Programm, dessen Pseudocode so aussehen könnte:

lies Eingabe g;
lies Eingabe h;
verarbeite Berechnung F = (g * h) / 2;
drucke Ausgabe F;

Das Resultat schickt er an Anton und widmet sich anderen Dingen.

Kurz darauf meldet sich Anton und erklärt, dass das Programm nicht brauchbar sei, denn es könne ja nur seine rechtwinkeligen Dreiecke berechnen, und die hat er nur jeden dritten Mittwoch im Monat. Außerdem kann er mit der Zeilenorientierung der Eingabe und Ausgabe nichts anfangen. Paul wundert sich und inzwischen ist Bert der Business Analyst wieder da. Bert besucht Anton und kommt nach zwei Tagen mit folgenden Auskünften und einem Packen Papier zurück:

Anton hat mal für g = 0 eingetippt und für h = -3 und auch mal beides zusammen, aber das Programm hat ihm nicht gesagt, dass dies ein Fehler ist.
Anton hat von seinen Dreiecken gelegentlich, aber wirklich nur gelegentlich, die Höhe h.
Dafür hat Anton häufig die Länge von zwei Seiten und einen Winkel zwischen diesen Seiten. Manchmal ist es sogar ein rechter Winkel, aber wirklich nur jeden dritten Mittwoch im Monat.
Eben so häufig hat Anton die Länge von zwei Seiten und einen Winkel, der aber nicht zwischen den beiden Seiten ist, sondern am Ende einer der anderen Seiten anliegt.
Sonst hat er auch ziemlich oft eine Seitenlänge und die zwei Winkel, die an dieser Seite anliegen.
Nicht seltener aber hat er auch nur eine Seitenlänge, einen Winkel, der an der Seite anliegt, und den Winkel, der nicht an dieser Seite anliegt. (Randnotiz: Das macht aber nichts, dann die Summe der Winkel eines Dreiecks ist 180°)
Manchmal hat Anton aber auch nur die Länge von allen drei Seiten a, b und c.

Außerdem will Anton die Funktion nicht in C, sondern im Rahmen eines größeren Paktes als Java-Klasse. Natürlich soll das Programm absturzsicher sein und alle möglichen Fehlerfälle abdecken. Die nötigen Formeln sind im Dokument beigelegt. Außerdem wird erklärt, wann die Daten falsch sind. In der Spezifikation findet sich der Hinweis: Die Längenangaben der Seiten sind in Metern oder in Zoll, die Fläche muss sowohl in Quadratmetern, als auch in Quadratyards, als auch in Quadratfuss abgerufen werden können. Bert gibt der Testerin Therese eine Kopie der Spezifikation, die sich sogleich an einen Testplan macht.

Nehmen wir für die Datenprüfung den Fall 7: a = 1, b = 2, c = 1000 wird wohl kein Dreieck sein. Es gilt also: a + b < c oder a + c < b oder b + c < a. Und wenn a, b oder c <= 0 ist, dann ist es bestimmt kein Dreieck. Sind die Werte im Verhältnis zueinander "extrem", also z.B. a + b = c - 0,000000000001, dann könnte es numerisch etwas instabil werden. Zudem hat jeder Rechner seine Grenzen, also sollten auch keine sehr sehr großen Zahlen dran kommen. In der Spezifikation steht noch: Keine Seite kann größer als 100 km sein und muss mindestens 3 Zoll sein. Mithin gilt also 3" <= a,b,c <= 100.000 m.

Schließlich findet sich noch ein Hinweis in dem Dokument, dass in Zukunft für eine spätere Version des Programms auch die Möglichkeit in Betracht kommt, dass die Ecken durch die Koordinaten einer Landkarte bestimmt werden, wobei die Dreiecke so groß werden können, dass man die Krümmung der Erdoberfläche berücksichtigen muss.

Programmierer Paul stellt nur entnervt fest: "Kann Anton das nicht gleich sagen?"

Darauf Bert der Business Analyst: "Hast Du ihn gefragt, was er wirklich braucht?"

Was ist nun die Moral von dieser Geschichte? Paul hat angenommen, dass er weiß, was Anton will. Er hat es aber nicht gewußt. Schlimmer noch: Paul hat nicht einmal in Betracht gezogen, dass er sich irren könnte. Betriebswirtschaftlich gesehen hat er Zeit und Geld seines Arbeitgebers verschwendet. Sozial gesehen hat er schlechte Laune und womöglich ist der Rest des Tages vergrätzt.

Paul hatte eine Lösung, aber leider passte das Problem nicht dazu.

Exkurs - kleine Katastrophen

Lassen Sie uns zunächst einen Exkurs im Exkurs machen, nämlich einen zur deutschen Sprache, genauer zur deutschen Grammatik - samt Nebenwirkungen bei Geschäftsprozessen und Geschäftsdaten. Lassen Sie sich dadurch aber nicht verwirren, die Angelegenheit ist in einer Minute erledigt und ganz einfach (das behaupten Fachanwender auch immer). Die Frage ist, ob man "sind" oder "ist" sagt und es geht um die Korrektheit eines deutschen Satzes. Also, welche Aussage ist richtig: Sieben und fünf ist dreizehn. Oder: Sieben und fünf sind dreizehn. - Alle Hilfsmittel zur Klärung der Frage inklusive Anruf in der Duden-Redaktion sind erlaubt. Sie dürfen auch in einer Formelsammlung nachschlagen.

Seien Sie nicht vorschnell in Ihrem Urteil und schauen Sie sich die beiden Sätze nochmals gründlich an, denn abhängig von Ihrer Antwort ist der Erfolg eines Millionen-Projekts! Lassen Sie sich durch nichts ablenken und verfälschen Sie nicht den Satz. Es geht nur um diese paar Worte und sonst nichts. - Lösung.

Beispiele aus der Praxis

Als in den achtziger Jahren eine Abteilung einer Behörde auf EDV umgestellt wurde, war eine der zu klärenden Fragen, was man mit den alten Bescheiden machen sollte. Im zuständigen Rechenzentrum saß ein Hochschulabgänger ohne wirkliche Berufserfahrung, der so ziemlich alles selbst machen mußte. Sechs Bescheide wurden mehrmals implementiert. Zunächst hieß es, man brauche nur einen Ausdruck. Anschließend hieß es, man brauche den Bescheid vierfach,dann wollte man auf einem Bescheid "Original" und auf den anderen dreien "Kopie" stehen haben. Dann sollte der Aufdruck "Original" wegfallen. Anschließend sollten verschiedene Anschriften aufgedruckt werden. Etc. Nach zwei Wochen schlug der Entwickler bei seinem Chef auf und erklärte ziemlich laut, dass zur Implementierung von ein paar Wischen Papier keine zwei Wochen zu rechtfertigen seien. Die nächste Version würde die letzte sein, die er in den nächsten sechs Monaten anfassen würde. Einen Tag später wurde die finale Korrektur vorgelegt. Darunter fand sich ein Bescheid, den der Entwickler noch niemals zu Gesicht bekommen hatte.

An einem Freitag nachmittag erfuhr ein Business Analyst, dass am folgenden Montag ein Entwicklerteam von fünf Leuten anfangen würde, um ein Projekt in der Größenordnung von ca. zwei bis drei Personenjahren abzuwickeln. Der Analytiker sollte das Projekt fachlich betreuen. Nicht genug, dass Entwickler da waren, die nicht wußten was sie tun sollten. Auf Kundenseite fand sich lediglich eine Marketingabteilung, die von den fachlichen Anforderungen im Projektfeld keine Ahnung hatte, denn die dortige Organisation war auch erst im Aufbau. Zudem waren die Kompetenzen nicht geklärt, sodass der Analytiker sich vor Oberflächen-Designern rechtfertigen musste, weshalb er bestimmte Features zurück wies. Seine Auskunft war irgendwann nur noch: "Die Oberfläche verlangt nach Daten, die es nicht gibt und sie liefert nicht die Daten, die zum gewünschten Ergebnis führen. Passen Sie die Oberfläche dem Geschäftsprozess an, denn für Ihren Entwurf gibt es keinen passenden Prozess."

Ein Business Analyst arbeitete eine Menge von Algorithmen für ein Produkt aus und gab dazu eine Spezifikation für ein Kleinprojekt ab, die vom Kunden als perfekt bezeichnet wurde. Über die Benutzeroberfläche machte der Analytiker keine Aussage, da es hierzu keine Anforderung gab. Das war zunächst auch nicht weiter schlimm, da die funktionale Interaktion mit der Oberfläche konform mit den Algorithmen ging. Allerdings war die Kostenabschätzung vom Produktmanagement nach Rücksprache mit der Entwicklerin nur auf Basis der Implementierung der Algorithmen vorgenommen worden. Im Laufe der Zeit stellte sich jedoch heraus, dass der Kunde eine sehr klare Vorstellung von der Weboberfläche hatte und davon ausging, dass der Auftragnehmer die Templates selbst baut. Der Auftragnehmer wartete jedoch schon geraume Zeit auf Templates. Der ursprünglich geschätzte Zeitrahmen wurde um den Faktor drei überschritten.

Für eine Bibliothek, deren Katalogverwaltung und Ausleihe bis dahin rein manuell ablief, sollte eine geeignete Software ausgewählt werden. Dazu wurde die Bibliotheksleitung gebeten, die wesentlichen Anforderungen zusammen zu schreiben, die die Software erfüllen sollte. Nach einigen Tagen wurde eine Liste von Kategorien (Attribute) wie Autor, Titel etc. geliefert, nach denen die Bücher katalogisiert wurden. Über Ausleihe, Mahnwesen, den Katalogisierungsvorgang, Beschaffung oder andere tagtägliche Prozesse fand sich nichts in den drei handschriftlichen Seiten.

Für den Leser mag das lustig klingen, für manche Leute sogar normal. Tatsächlich sind dies durchweg Beispiele für nicht vorhandenes oder versagendes Projektmanagement, unklare Kometenzenteilung, nicht vorhandene oder inkompetente Analytiker, desinteressierte Auftraggeber, zusammengefasst also ungenügendes Qualitätsmanagement, die nicht-Beachtung der Notwendigkeit einer ausreichenden Analysephase und das Unverständnis von IT-Prozessen. Je größer das Projekt, um so teurer wird solche Ignoranz.