Inhalt eines Anforderungsdokuments


Zusammenfassung
Allgemeines
Formelles
Zusammenfassungen
Definition von Erfolg und Misserfolg
Quantitative Aussagen
Story Board
Prozesse
Daten
Interfaces
Randbedingungen der Systemumgebung
Verlässlichkeit
Sicherheitsanforderungen
Gesetzliche Forderungen und Regelungen
Benutzerrollen
Wartbarkeit und Weiterentwicklung
Aussagen bei Unvollständigkeit der Spezifikation, falls die Entwicklung vor Beendigung der Spezifikation beginnt
Projektspezifischen Regelungen und Anforderungen

vgl. auch Qualität im Anforderungsdokument
vgl. auch Anforderungsanalyse und die Entstehung eines Anforderungsdokuments

Zusammenfassung

Diese Seite stellt eine relativ ausführlich erklärte Vorlage oder ein Beispiel dar, wie ein Anforderungsdokument aufgebaut sein kann und was es enthalten muss. Für (UML-taugliche) Anwendungsfälle wird sowohl eine detaillierte Beschreibung der zu definierenden Inhalte als auch ein einfaches Beispiel dargestellt, für Story Boards eine ungefähre Beschreibung. Diese Seite kann bzgl. des zu erarbeitenden Ergebnisses im Rahmen einer Anforderungsanalyse als die Essenz meiner Seiten über Business Analysis angesehen werden.

Allgemeines

Die hier aufgeführten Punkte gehen über die blanke Beschreibung von Geschäftsdaten und Geschäftsprozessen hinaus. Was Sie hier sehen ist ein Resultat jahrelanger, z.T. bitterer Erfahrung.

Für Anforderungsdokumente gilt das Prinzip der Schriftlichkeit, denn sie sind meist Vertragsbestandteil. Mündliche Verabredungen werden gerne vergessen, sind nicht nachvollziehbar, nicht dokumentiert und auch nicht testbar.

Um späteren Streit zu vermeiden bzw. die beteiligten Parteien rechtzeitig auf kritische Punkte aufmerksam zu machen, sollten Aussagen nicht einfach weggelassen werden, sondern deutlich negiert werden. Z.B. kann geschrieben werden: "Besondere Anforderungen an die Sicherheit, auch bei der Übertragung der persönlichen Daten des Anwender bei der Registrierung, bestehen explizit nicht." Häufig hat man als Analytiker Bedenken, dass der Fachanwender einen Abschnitt überlesen hat oder nicht versteht, man sollte ihn dann nochmals darauf ansprechen und damit die Angelegenheit endgültig erledigen. Meistens wenigstens.
Beispiel aus der Praxis

Der Business Analyst hatte in mehreren Versionen des Anforderungsdokument über mehrere Monate einen hinweisenden Abschnitt stehen, dass bei der geplanten (Internet-) Anwendung personenbezogene Daten verarbeitet werden und er Fachanwender (Auftraggeber) und Auftragnehmer explizit ermuntert, die zuständigen Datenschutzbeauftragten im Hause zu kontaktieren. Irgendwann baten die Auftraggeber darum, diesen Passus endlich aus dem Dokument zu entfernen, da er ja keine Anforderung enthielt. Eine Woche später bekam der Datenschutzbeauftragte im Hause des Auftraggebers Wind von dem Projekt und wurde aktiv.
Bei manchen der dargestellten Inhalte kann man sich streiten, ob sie nun in das Anforderungsdokument im Sinne einer Business Analysis für ein IT-System oder in ein anderes Dokument gehören. Gehört z.B. eine Definition des Erfolgs bzw. Misserfolgs eines IT-Projekts in das Anforderungsdokument? Oder ist sie direkter Vertragsbestandteil?  Ist eine Zusammenfassung und eine Management Summary notwendig, oder vollkommen überflüssig? Sind Aussagen über die Ausfallsicherheit des Produkts und die Definition von Wiederaufsetz-Verfahren hier unterzubringen? Oder vielleicht in einem SLA? Hier entscheidet die Firmenphilosophie und die individuelle Situation des Projekts. Wie auch immer: Alle Informationen, die hier aufgelistet sind, sind notwendig, um ein IT-Produkt zu bauen und zu betreiben, und alle diese Informationen werden in der einen oder anderen Weise als Anlage dem Vertrag beigefügt werden.

Der Normalfall ist, dass der Analytiker mit den hier aufgeführten Informationen im Laufe des Projekts als erste IT-Person in Berührung kommt, sie vielleicht auch nur deshalb erhält oder erfragt, weil das technische Personal zu weit weg vom Kunden ist. Konkrete Vorgaben im Sinne von hinreichend guten Dokumentvorlagen und Checklisten gibt es gerade in kleineren und mittleren Betrieben nur selten. Irgendwo müssen diese Informationen aber festgehalten werden, um ein für den Kunden brauchbares Produkt zu erstellen und Sicherheit über die Abnahme-Kriterien zu erhalten. Ein sinnvoller Ansatz ist es, diese Fragen zu klären und zunächst im Anforderungsdokument festzuhalten. Sofern im Rahmen einer internen Durchsicht des Anforderungsdokuments Bedenken bestehen, die eine oder andere Aussage im Anforderungsdokument aufzuführen, kann sie dort entfernt und in einem anderen Dokument festgehalten werden, das seinerseits dem Auftraggeber bzw. Auftragnehmer vorgelegt wird. Dieses Vorgehen setzt jedoch gründliche Mitarbeit der Projektbeteiligten voraus.
Beispiele aus der Praxis

Es ist vollkommen üblich, Aussagen über die Performance und das Antwortzeitverhalten festzuhalten. Aus welchen Gründen auch immer wollte ein Projektleiter eines Auftragnehmers in dessen Auftrag auch der Analytiker tätig war, diese Informationen nicht im Anforderungsdokument sehen. Dies reklamierte er jedoch erst beim Analytiker, nachdem der Kunde, der hier klare Vorgaben gemacht hatte, diese nach verschiedenen Durchsichten des Dokuments bestätigt  und als Erfolgskriterium für das Projekt erklärt hatte. Es stellte sich heraus, dass der Projektleiter das Anforderungsdokument, das er selbst an den Kunden weitergeleitet hatte, weder im Rahmen der internen informellen Durchsichten noch vor Weiterleitung an den Kunden komplett gelesen hatte. Zudem kannte er die Checklisten des Analytikers, die u.a. Aussagen über die Performance forderten.

Ein Auftraggeber bestand darauf, dass bestimmte Aussagen im Anforderungsdokument festgehalten werden, obwohl diese auch nach Meinung des Analytikers dort nichts zu suchen hatten. Der Projektleiter des Auftragnehmers wollte diese Aussagen auf keinen Fall im Anforderungsdokument, hatte aber auch keine Vorlage für ein Alternativdokument vorzuweisen, sodass kurz vor Fertigstellung der Anforderungsanalyse ein Wust von Minidokumenten entstand. Der Auftraggeber äußerte sich dahingehend, dass er so etwas noch nie erlebt hätte.
Ein Anforderungsdokument von vielleicht 30 Seiten, das in wenigen Tagen oder Wochen erstellt wird und dessen Umsetzung nicht produktionskritisch ist, verlangt bei weitem nicht die Exaktheit wie ein Dokument mit dem fünf- bis zehnfachen Umfang, das im Laufe von mehreren Personenmonaten entsteht. Kleine Projekte haben i.d.R. nur eine eingeschränkte Menge an kritischen Anforderungen, große decken dagegen das gesamte Spektrum ab.

Formelles

Deckblatt

Das Deckblatt sollte mindestens den Namen des Projekts, die Version des Dokuments, das letzte Bearbeitungsdatum und den Autor benennen.

Weiterhin kann dort der Status des Anforderungsdokuments (in Bearbeitung, bereit zum Review, bereit für informelle Durchsicht, abgenommen) und das gewünschte Feedback-Verhalten des Lesers (Feedback erwünscht, Feedback nicht erwünscht) stehen. Feedback ist stets lösungsorientiert, Kreativität ist also erlaubt und Diskussionen über den Inhalt des Anforderungsdokuments sind möglich. Feedback ist natürlich immer erwünscht, wenn das Dokument zur informellen Durchsicht freigegeben wird. Bei einem in Bearbeitung befindlichen Dokument drückt der Wunsch nach Feedback aus, dass man durchaus bereit ist, informelle Kommentare auch einfach so entgegen zu nehmen. Tückisch dabei ist jedoch, dass verschiedene Versionen eines Dokuments zirkulieren und sich ein Feedback auf einen Abschnitt beziehen kann, der schon längst überarbeitet ist. Feedback bei einem Dokument zu fordern, das zum Review vorgelegt wird, ist etwas merkwürdig, denn im Rahmen eines Reviews wird nicht nach Lösungen geforscht sondern das Anforderungsdokument wird validiert. Hat man jedoch mit Fachanwendern zu tun, die strikte Reviews nicht kennen, oder mit Projektleitern, die den Review nicht als nicht-kreativen und strikt formalisierten Prozess verstehen, dann kann u.U. auch ein Feedback erwünscht sein. Klar gestellt werden sollte aber, dass dieses Feedback rechtzeitig vor dem Review oder erst im Anschluss daran erfolgen soll. - Diese Informationen sind nur dann wirklich interessant, wenn es sich um ein wenigstens mittelgroßes Projekt handelt, bei dem kein Pingpong-Verhältnis zwischen einem Analytiker und einem oder zwei Fachanwendern besteht.

Ebenfalls kann die Geheimhaltungsstufe des Dokuments hier stehen. Kleine und mittlere Unternehmen können damit häufig nichts anfangen. Typische Geheimhaltungsstufen sind auf
Festzuhalten ist ggf. auch, wer Personen benennen darf, die in den Kreis der Eingeweihten aufgenommen werden dürfen (z.B. alle vom Projektleiter explizit benannten Personen).

Verteiler

Dies geht am besten tabellarisch. Die Daten sind firmen- und projektabhängig. Mögliche Informationen sind:

Änderungshistorie / Reviewhistorie

Auch Anforderungsdokumente werden versioniert, wobei man sich grob an die Versionierungsgewohnheiten aus der IT halten kann. Zu jeder neuen Version kann fest gehalten werden:

Abnahmeerklärung

Eine Abnahme kann auch abschnittsweise stattfinden. Irgendwann ist jedoch das gesamte Anforderungsdokument abgenommen. Schon alleine, um dem Kunden die Wichtigkeit und Verbindlichkeit der Abnahme klar zu machen, sollte eine Seite dafür vorgesehen werden. Eine Abnahmeerklärung sollte unterschrieben sein und unmissverständlich aussagen, dass der Inhalt des Dokuments zur Kenntnis genommen und für vollständig und richtig befunden wurde, dass verstanden wurde, dass das Dokument das Fundament für die Produktentwicklung und Kostenabschätzung ist und alle weiteren Änderungswünsche auf Basis eines Change Request erfolgen müssen, für den jeweils eine eigene Kostenabschätzung stattfinden wird.

Eine Abnahmeerklärung erübrigt sich, wenn der Auftraggeber das Anforderungsdokument selbst erstellt hat und von verschiedenen interessierten Auftragnehmern Angebote einholt.

Referenzen und verwendete Dokumente

Aufzuzählen sind alle Dokumente, auf die sich das Anforderungsdokument bezieht. Der Begriff Dokumente ist dabei sehr weit gefasst, es kann sich auch um Tabellenkalkulations-Sheets o.ä. handeln, die verbindliche Geschäftsdaten enthalten. Jede Referenz kann folgende Informationen enthalten:
Dokumente haben die Eigenart, sich zu ändern, den Archivierungsort zu wechseln oder verloren zu gehen. Der Analytiker sollte also auf einer eigenen Kopie bestehen, die er mit der jeweils aktuellen Version seines Anforderungsdokuments zusammen archiviert.

Ansprechpartner

Fachfragen werden vom Analytiker meist nicht mit einem Ansprechpartner, sondern mit verschiedenen Ansprechpartnern gelöst. Häufig wird für besondere Fälle auf einen Spezialisten verwiesen, der wiederum auf einen weiteren Spezialisten verweist. Aussagen im Anforderungsdokument, die auf diese Weise zu Stande gekommen sind, sollten im jeweiligen Abschnitt auch den Namen des Spezialisten enthalten, sonst könnte der Analytiker oder dessen Nachfolger sehr viel Zeit verschwenden müssen, um bei einer Weiterentwicklung des Produkts den richtigen Ansprechpartner zu finden. Aufgezählt können aber auch Mitarbeiter aus den technischen Bereichen werden, die z.B. bzgl. der Prüfung von Performance-Forderungen konsultiert wurden. Folgende Informationen können gesammelt werden:

Firmenspezifika

Firmenspezifika unterliegen der Hausphilosophie. Hier kann z.B. eine Kostenstelle stehen.

Glossar

In jedem Projekt entsteht eine Gruppensprache, die erklärungsbedürftig ist. Deshalb muss ein Glossar angelegt werden, das die verwendete Begrifflichkeit so erklärt, dass sie sowohl der Fachanwender als auch der Entwickler versteht. Nötigenfalls ist ein zweisprachiges Glossar anzulegen, z.B. wenn die Analysesprache Deutsch ist, die Entwicklersprache aber Englisch, sodass ein Übersetzer, der meist nicht aus dem IT-Bereich kommt, nicht Unfug erdichtet.
Beispiel aus der Praxis

Ein deutscher Text enthielt den Begriff "Muster" in unterschiedlichen Zusammenhängen, z.B. Muster-Abrechnungsplan. Die englische Übersetzung benutzte den Begriff "sample", was zu erheblicher Verwirrung führte. Gemeint war "pattern".
Die im Glossar verwendete Begriffswelt muss natürlich strikt in der Anforderungsanalyse eingehalten werden und sollte auch in allen anderen Dokumenten einheitlich weiter benutzt werden. Regelmäßige, z.T. auch zeitraubende Überarbeitungen der Projektdokumentation sind daher unvermeidbar.

Inhaltsverzeichnis / Abbildungsverzeichnes

Das Inhaltsverzeichnis lässt man sich vom Textverarbeitungssystem erstellen.

Außerdem sollte ein Abbildungsverzeichnis erwogen werden, ggf. auch ein eigenes Verzeichnis für die Anwendungsfälle, sofern sie nicht aus dem Inhaltsverzeichnis hervorgehen oder in einem eigenen Dokument beschrieben werden.

Aufbau des Dokuments

Wenn man den Eindruck hat, dass das Inhaltsverzeichnis nicht mehr ausreicht, um sich im Dokument zu orientieren, wenn man es das erste Mal in der Hand hat, dann kann man ein kurzes Kapitel einschieben, das den Aufbau darstellt und Hinweise gibt, wie das Dokument gelesen werden sollte.

Zusammenfassungen

Idee / Management Summary

Die Idee, die hinter einem System steckt, sollte zusammen mit dem Verwendungszweck immer ausformuliert werden.

Eine Management Summary oder Executive Summary ist nur dann angezeigt, wenn die Anforderungsanalyse relativ umfangreich ist und überhaupt zu erwarten ist, dass sich ein Manager (oder eine andere Person, die nur wenig Zeit und Interesse für Details mitbringt) rasch informieren will, um was es in dem Dokument und auch im Projekt geht. Der Umfang sollte im Bereich von einer oder zwei Seiten sein bzw. nicht mehr als ein Prozent des gesamten Dokuments ausmachen. Dargestellt werden nur die allergröbsten Ideen des Produkts.

Vision / Mission / Kurzübersicht

Eine Kurzübersicht lohnt ebenfalls nur dann, wenn die Spezifikation relativ umfangreich ist. In meiner beruflichen Praxis entsteht i.d.R. zuerst die Kurzübersicht, und erst dann die Anforderungsanalyse. Die Kurzübersicht wird meist vom Vertrieb als abgekürztes Resultat eines Grobkonzepts verlangt, um weitere Partner ins Boot holen zu können. In diesem Fall besteht die Kurzübersicht eher aus stichpunktartig aufgelisteten plakativen Aussagen und wesentlichen Highlights, die das Funktionsspektrum des Produkts gerafft aber doch annähernd vollständig darstellt. Ebenfalls dargestellt werden sollte der Verwendungszweck, Nutzen und die Zielgruppe des Produkts. Auf Details wird dabei verzichtet. Für das technische Team ist solch eine Kurzübersicht auch interessant, um einen Überblick über das Produkt und die dahinter steckenden Ideen zu bekommen.

Die Kurzübersicht sollte nicht mehr als fünf bis zehn Prozent des gesamten Dokuments ausmachen und eher als roter Faden verstanden werden, sie stellt die Vision bzw. Mission dar, die erfüllt werden muss, um das Produkt zu erzeugen.

Definition von Erfolg und Misserfolg

Man kann nur kontrollieren, was man messen kann.

Es besteht kein Diskussionsbedarf darüber, dass Software nicht fehlerfrei sein kann (allgemeiner Konsens ist, dass selbst sehr gut getestete kommerzielle Software noch ca. 4 Fehler auf 1000 Codezeilen enthält, in Extremfällen (z.B. Raumfahrt) geht man von 1 Fehler auf 1000 Codezeilen aus) und dass im Laufe der Entwicklung eines Produkts bestimmte Forderungen aus dem Anforderungsdokument nicht erfüllt werden. Dies ist sogar sinnvoll, falls das Anforderungsdokument fehlerhaft ist und ein evtl. bürokratisch aufwendiger Korrekturprozess vermieden werden soll, der in keinem Verhältnis zur tatsächlich stattfindenden technischen Korrektur bei der Implementierung steht. Manchmal stellt sich auch heraus, dass die technische Umsetzung eines geforderten Features einfach nicht hundertprozentig machbar ist, so wie es spezifiziert worden ist. Genau genommen stellt jede Abweichung vom Anforderungsdokument, sei sie nun im Sinne des Kunden oder auch nicht, einen Vertragsbruch bzw. eine Abweichung vom Vertrag dar. Die meisten Abweichungen sind jedoch kein Grund, die Abnahme des Produkts zu verweigern.

Deshalb soll eine konkrete Auflistung der vom Kunden geforderten Features erfolgen, die mit Sicherheit zur Verweigerung der Abnahme des fertigen Produkts führt. Beispielhaft sei eine bestimmte Performance-Forderung genannt, die um zehn Prozent überschritten wird. In aller Regel wird es z.B. keinen Unterschied machen, ob eine Systemantwort in einem Call Center nun 2 oder 2,2 Sekunden dauert, oder ob ein nächtlicher Verarbeitungsprozess nun 2 Stunden oder 2:12 Stunden dauert. Wenn es sich aber um ein System handelt, das in Echtzeit zu reagieren hat, z.B. die Steuerung von Bremsen eines Fahrzeugs, dann können 10% fatal sein.

Eine solche Definition ist nicht nur wesentlich, um die Projektziele zu priorisieren. Sie hilft auch, im Zweifelsfall Streit zu vermeiden. Der Auftraggeber sucht Sicherheit dahingehend, dass bestimmte Minimalanforderungen erfüllt werden. Der Auftragnehmer sucht Sicherheit dahingehend, dass klare, quantifizierbare und messbare Mindestkriterien gegeben sind, die den Auftraggeber zu einer Abnahme zwingen, wenn sonst keine schwer wiegenden Fehler gemacht wurden. Hintergrund ist hier, dass sich gelegentlich die Politik des Auftraggebers oder die eigentlichen Projektziele und die damit verbundenen Anforderungen ändern, und er zwar keinen Grund auf Basis der gemachten Vereinbarungen hat, die Abnahme zu verweigern, die Abnahme jedoch vermeiden will, um noch weitere Forderungen ohne zusätzliche Kosten unterbringen zu können.

Weiterhin sollte der Kunde definieren, wann er das Projekt als Erfolg betrachtet. Diese Definition muss nicht unbedingt etwas mit dem IT-System zu tun haben und gehört dann auch nicht unbedingt in ein Anforderungsdokument. Aber ein Bewußtsein bzw. eine bewußte und schriftlich fixierte Definition sollte im Hause des Auftraggebers vorhanden und dem Business Analysten auch kommuniziert worden sein. Naturgemäß ist solch eine Forderung bei vielen Leuten nicht beliebt, denn sie bestätigt am Ende nicht nur den Projekterfolg, sondern evtl. das genaue Gegenteil. An irgend einem Kriterium sollte jedoch ein Auftraggeber den Erfolg messen können und auch ggf. eine Grenze festlegen können, bei der er das Projekt einstellt, um weiteren Schaden durch konsequente Fehlinvestition zu vermeiden.

Quantitative Aussagen

Mengengerüste

Aufzuführen sind fallabhängig
Bei Bedarf sind Mengengerüste auch bei Anwendungsfällen (s.u.) anzugeben.

Das Mengengerüst ist kritisch für die Dimensionierung der Hardware und die gewählte Architektur der Software. Aus dem Mengengerüst müssen vom IT-Team die Durchsatz- und Speicheranforderungen an das System spezifiziert werden. Heutzutage ist Speicher zwar i.d.R. kein Thema mehr, da er billig ist, aber dennoch sollte nachgewiesen werden, dass Massenspeicher und Hauptspeicher der Hardware auch dann ausreichen, wenn der schlimmste aller vorstellbaren Fälle eintritt. Beim Systemdurchsatz sieht es anders aus, denn die Frage, ob einer, zwei oder noch mehr Server gekauft oder gemietet werden müssen, kann eine kritische Finanzierungsgröße werden. Es ist wichtig zu verstehen, dass es für die Software-Entwicklung nicht egal ist, wie viele Daten verarbeitet werden, denn Performance-Optimierung kann kompliziert sein und somit teuer werden.

Die Datenmenge ist stets eine von der Nutzerzahl und den Systemaktivitäten abhängige Zahl und kann relativ leicht ermittelt werden, wenn für die Basiswerte verlässliche Zahlen vorliegen.

Bei klassischen Anwendungen aus der old economy sind die Mengenabschätzungen i.d.R. problemlos. Ehe ein Unternehmen Geld ausgibt, stellt es gründliche und realistische Marktanalysen an, die zu einigermaßen verlässlichen Zahlen führen. Hoffentlich. Da aber das System stets so dimensioniert ist, dass es auch nach einiger Zeit des Wachstums arbeitet, bedeutet ein Übertreffen der Zuwachsraten lediglich, dass die Systemgrenzen vor der geplanten Zeit erreicht werden, nicht jedoch am ersten Produktionstag. Es bleibt also Zeit genug, um das System zu erweitern. Die guten Zuwachsraten rechtfertigen auch die zusätzlichen Kosten. Technische Schwierigkeiten gibt es nur dann ausnahmsweise, wenn die Marktanalysen offensichtlich total falsch sind und die Erwartungen mehr als nur übertroffen werden.
Beispiele aus der Praxis

Der Erfolg der T-Netbox der Deutschen Telecom wurde anfangs total unterschätzt. Der Service war in den ersten Tagen kaum erreichbar. Aufgesprochene Ansagen gingen verloren, wahrscheinlich eine Folge des überlasteten Systems und der notwendigen Erweiterungsarbeiten. Offensichtlich war das Call Center ebenfalls überlastet, da man kaum durchkam und die Mitarbeiter teilweise sehr gereizt reagierten.

In den Hochzeiten der Börseneuphorie hatten manche frisch gestarteten Discount Broker ernsthafte Probleme mit dem Kundenandrang. Weder kam man beim Call Center durch, noch war die Website erreichbar.
Das Internet-Zeitalter mit seinen anonymen Massenprodukten hat seine eigenen Regeln bzgl. Mengengerüsten. Wenngleich die new economy kein relevantes Schlagwort mehr ist, stehen doch nach wie vor sehr viele Marketing-Mitarbeiter dem Medium Internet hilflos gegenüber. Abschätzungen von Nutzerzahlen für Marketing-Produkte scheinen gelegentlich vom Himmel zu fallen, nachvollziehbare Basiswerte und Metriken aus Marktanalysen gibt es selten. Ein typisches beobachtbares Verhalten erinnert an die Devisenbeschaffung von produzierenden Betrieben früherer kommunistischer Staaten: sollte damals ein bestimmter Betrag x an Devisen durch y Stück Produkte erwirtschaftet werden, so wurde der Stückpreis kurzerhand mit x/y fest gelegt; weder gab es Ansätze zur Gewinnmaximierung noch Puffer im Versagensfalle. Ist das Ziel einer E-Marketing-Aktion das Generieren von Adressen, so wird die "erwartete" Nutzerzahl gerne definiert als Budget / maximal akzeptable Kosten je Nutzer. Davon erfährt der Business Analyst im Normalfall aber nichts. Die tatsächliche Nutzerzahl erinnert eher an Glücksspiel und hat mit solchen Zahlen selten etwas zu tun, Abweichungen von 70% nach unten oder 100% nach oben sind ohne weiteres möglich.
Beispiele aus der Praxis

Im Rahmen einer Auseinandersetzung um die Aufwände für die Implementierung eines bestimmten Features stimmte ein vom Auftraggeber benannter Gesamtprojektleiter mit der Abschätzung des technischen Projektleiters nicht überein. Möglich waren entweder nur wenige Minuten oder ein Tag. Grundlage des Streits war die Performance, die die gewählte Architektur zu liefern hätte. Der Gesamtprojektleiter vertrat die Meinung, dass Zugriffszeiten von Millisekunden oder Nanosekunden keinen Unterschied für den Anwender machen würden, deshalb also die billigere Implementierung zu wählen sei. Der technische Projektleiter hielt dagegen, dass dieser Unterschied sehr wohl fühlbar wird, wenn 20000 oder mehr parallele Benutzer zu Stoßzeiten zugreifen würden. Der Kunde wiederum war nicht bereit, sich auf eine Benutzerzahl festzulegen oder das Nutzerverhalten über den Tag verteilt anders zu postulieren, als dies das technische Team tat, das wiederum auf Basis von Metriken ähnlicher Anwendungen zu ihrer Empfehlung gekommen war.

Die pessimistische Schätzung einer Nutzerzahl für eine Internetanwendung lag bei einem Drittel der optimistischen Schätzung. So betrachtet hätten noch Server in Reserve gehalten werden müssen. Der Auftraggeber entschied sich aus Kostengründen dagegen. Aber selbst die pessimistische Schätzung lag noch immer um zwei Drittel über der tatsächlichen Nutzerzahl.
Das andere Extrem sind Unternehmen, die kein Interesse an der Generierung von Adressen haben, weil sie schon genügend haben, und die vor allem ihre Marke platzieren oder einen besonderen Service anbieten wollen. Hier wird oft lediglich ein diffuses Wunschziel genannt, das ebenfalls ohne nachvollziehbare Grundlage entsteht.

In beiden Fällen kann sich der Analytiker lediglich auf die Aussagen des Kunden verlassen, sofern er nicht selbst Marktstudien betreiben kann oder Metriken für den Erfolg von vergleichbaren Marketing-Aktionen griffbereit hat. Dies ist allerdings nicht seine Aufgabe.

Performance-Anforderungen

Selbstverständlich wünscht jeder Auftraggeber eine gute Performance. Diese muss allerdings in Zahlen gefasst werden. Zu unterscheiden ist das Antwortzeitverhalten einer Anwendung im Dialogbetrieb und die Laufzeit von Batchjobs. Ggf. müssen auch Datenübertragungszeiten berücksichtigt werden (z.B. bei kontinuierlichen Datenströmen wie Börsenkursdaten oder die Berücksichtigung langsamer Modemverbindungen bei Internetanwendungen).

Beim Antwortzeitverhalten im Dialogbetrieb kann jeweils lastabhängig ein Zielkorridor festgelegt werden, z.B. 80% der Systemanfragen sollen bei Volllast in 3 Sekunden, weitere 15% in 4 Sekunden und die verbleibenden 5% in maximal 8 Sekunden beantwortet werden. Bei kalkulierbaren Anwendungen, z.B. in Call Centern, lassen sich solche Zahlen recht gut festlegen. Vollast bedeutet hier, dass alle Telefone gleichzeitig heiß laufen.

Auch hier haben Internetanwendungen ihre eigenen Regeln. Der Auftragnehmer kann lediglich die time to first byte kontrollieren, also die Zeit vom Eintreffen einer Anfrage bis zum Versand des ersten Bytes. Auf alles weitere, z.B. die Geschwindigkeit des Modems des Endanwenders, hat der Auftragnehmer keinen Einfluss und kann auch keine Zahlen nennen. Professionelle Webdesigner berücksichtigen dies natürlich und gestalten keine absurd großen Seiten.
Beispiel aus der Praxis

Eine Homepage war zwar sehr schön gestaltet, hatte aber eine Größe von einem Megabyte. Anwender ohne Hochgeschwindigkeitsanbindungen verloren regelmäßig die Geduld.
Der frühestmögliche Startzeitpunkt eines Batchjobs hängt vom spätest möglichen Endzeitpunkt des Vorgängerprozesses ab. Die maximal akzeptable Laufzeit hängt davon ab, wann die Ergebnisse spätestens benötigt werden. Hier muss der Analytiker die betroffenen technischen Abteilungen konsultieren, konkrete Kundenwünsche gibt es normalerweise nicht, solange die Daten rechtzeitig bereit stehen. Abhängig von diesen Randbedingungen wird der Systemdurchsatz definiert, wobei natürlich zu beachten ist, dass bei den wenigsten Systemen ein linearer Zusammenhang zwischen Datenmenge und Durchsatz besteht.

Story Board

vgl. hierzu Entstehung eines Anforderungsdokuments - Hinweise zur Definition der Benutzeroberfläche

Das Story Board wird i.d.R. in einem eigenen Dokument dargestellt und eher vom Oberflächen-Designer als vom Business Analyst geschrieben. Das Story Board definiert die Übergänge des Systems von einem Zustand in den nächsten im Sinne eines finiten Automaten, wobei man sich meist damit begnügt, lediglich die an der Benutzeroberfläche sichtbaren Vorgänge darzustellen. Die nicht-sichtbaren werden als Prozess bzw. Anwendungsfall im Anforderungsdokument fest gehalten. Die inhaltlichen Vorgaben dieses Automaten kommen vom Business Analysten, für die Benutzeroberfläche kommen die Darstellung und Navigation vom Oberflächendesigner, für alle anderen Schnittstellen ist wiederum der Analytiker verantwortlich. Aufgrund der Parallelität dieser Arbeiten entsteht ein gewisser Interessenskonflikt: Änderungen an der Oberfläche wirken sich zwar nicht zwingend auf die Geschäftsprozesse aus, sehr wohl jedoch auf funktionale Beschreibungen und Anwendungsfälle innerhalb des Analysedokuments - und umgekehrt. Sie schlagen selbstverständlich auf die oberste Schicht einer Dreischicht-Architektur durch und können auch auf die zweite Schicht einwirken. Der Projektleiter hat also für eine klare Kompetenzenverteilung zu sorgen, um zeit- und kostenintensive Konflikte zu reduzieren. Dabei ist festzulegen, ob Designer bzw. Analytiker für den anderen relevante Vorgaben ohne Rücksprache festschreiben darf.

Weiterhin soll festgelegt werden, wo Randbedingungen ("Constraints") bei Eingaben in Bildschrimformularen verbindlich definiert werden (z.B. ganze Zahlen 1 <= x <= 10000). Der logische Ort ist bei der Beschreibung des Anwendungsfalls im Anforderungsdokument, bzw. bei der Beschreibung der Eingabe in einen Verarbeitungsprozess. Die Praxis zeigt jedoch, dass diese Informationen häufig auch redundant im Story Board gehalten und nicht parallel aktualisiert werden, sodass bei Entwicklungsbeginn die verbindliche Vorgabe nicht mehr nachvollziehbar ist. Eine Lösung dieses Dilemmas kann darin bestehen, dass die Randbedingungen in ein eigenes Dokument geschrieben werden, das sowohl den Anwendungsfällen als auch dem Story Board als Anlage angefügt wird. Das ist aber nur dann praktikabel, wenn die Behandlung der Verletzung der Randbedingungen ebenfalls dort beschrieben wird und beim Review und der Entwicklung diszipliniert auch in diesem Dokument nachgeschlagen wird. Es ist für den Programmierer offensichtlich ärgerlich, drei verschiedene Dokumente parallel lesen zu müssen.

Sofern notwendig müssen sonstige allgemeine Bedingungen festgehalten werden, z.B. bei Browser basierten Anwendungen, dass bei Popups die Addresszeile oder die Standard-Schaltflächen nicht angezeigt werden sollen.

Im Anforderungsdokument sollte auf jeden Fall ein Überblick über die Abfolge der Bildschirmformulare und eine hohe Sicht auf die ablaufenden Prozesse graphisch wieder gegeben sein. Ein Zustandsdiagramm, wie es auch in der UML vorgesehen und zur Darstellung finiter Automaten normal ist, kann verwendet werden. Dabei wird der gesamte Ablauf i.d.R. in mehrere Teildiagramme aufgeteilt werden müssen. Etwas dubios sind Darstellungen auf einer einzigen Seite Din A 4, die nur die wichtigsten Formulare darstellen und sonst gar nichts. Es ist guter Stil, Formulare zu numerieren, in klassischen Hostanwendungen ist die Formularnummer auch nach wie vor auf dem Formular sichtbar, sodass Rückfragen vom Anwender direkt addressierbar sind. Bei Web-Anwendungen ist die Darstellung der Nummer jedoch aus optischen Gründen unpopulär.

Je Formular kann ein Story Board folgende Informationen enthalten:

Prozesse

vgl. hierzu Darstellungsformen für Daten,  Bildschrimformularen und Prozesse

Allgemeines

Dieser Abschnitt wird im Normalfall der mit Abstand umfangreichste Teil des Anforderungsdokuments. Er macht (Story Board nicht mitgerechnet) i.d.R. 60% bis 90% des Dokuments und zusammen mit der zugehörigen Datenanalyse über 90% der zu investierenden Arbeit aus.

Hohe Sicht auf die Prozesse

Die hohe Sicht auf die wichtigsten Prozesse läßt sich i.d.R. mit einer Präsentationssoftware auf einer Seite darstellen. Sinnvoll ist es, zunächst die tatsächlichen Geschäftsprozesse darzustellen. In mittleren oder größeren Projekten wird ohnehin alle viertel oder halbe Jahre im Rahmen von Meetings mit einigen Dutzend Leuten aus anderen Projekten, die man noch nie gesehen hat, eine Präsentation verlangt werden. Dabei werden dann die Übergänge von einem (Teil-) Projekt zum nächsten sichtbar.

Man sollte dabei nicht zu sehr in die Tiefe gehen. Ein Überblick auf hohem Niveau reicht, sollte aber tatsächlich vollständig sein. Z.B. sollte man auf dem Weg vom Gras zum Käse nicht Details wie die enzymatische Aufspaltung der im Gras enthaltenen Nährstoffe in der Verdauung einer Kuh darstellen, allerdings muss die Kuh gemolken werden. Dass sie irgendwann einmal gekalbt haben muss, ist eine Randbedingung, der gerne übersehen wird.

Aufbauend auf dieser hohen Sicht der Geschäftsprozesse kann eine ebenso hohe Sicht der IT-Prozesse gezeichnet werden.

Beschreibung der Dialogkomponenten

Das Story Board beschreibt lediglich die Übergänge von einem Bildschirmformular zum nächsten. Hier müssen die Vorbedingungen, Randbedingungen, Auslöser, Verarbeitungsschritte, Ergebnisse, alternative Abläufe und Ausnahmen beschrieben werden. Man kann dies sehr gut mit einem Formular machen, das use cases (Anwendungsfälle) beschreibt.

Die Sortierung sollte nach Domäne stattfinden und logisch zusammen gehörig sein.

Beschreibung von Batch-Prozessen

Für die Beschreibung von Batch-Prozessen gilt sinngemäß dasselbe wie für Dialogkomponenten. Sie sollten in einem eigenen Kapitel gesammelt werden, da sie i.d.R. von einer anderen Gruppe der Entwicklungsabteilung bearbeitet werden, als der Dialogteil. Ein logischer Widerspruch entsteht dabei so gut wie nie, denn eine Dialogkomponente mag zwar implizit einen Batch-Prozess auslösen, jedoch wird sie niemals auf das Ergebnis einer wie auch immer gestalteten offline-Funktionalität warten.

Anwendungsfälle

Der Anwendungsfall (use case) beschreibt einen konkreten Ablauf im Sinne des EVA-Prinzips, wobei neben Eingabe, Verarbeitung und Ausgabe noch Akteure (also Personen und Systeme, die bestimmte Arbeitsschritte vollziehen) und Randbedingungen beschrieben werden. Anwendungsfälle werden im Rahmen der UML (unified modelling language) benutzt und stellen eine strukturierte Darstellungsform dar.

Anwendungsfälle werden normalerweise aus Anwendungsszenarien hergeleitet. Ein Anwendungsszenario ist ein konkretes Beispiel, der Anwendungsfall verallgemeinert die Beispiele und bildet viele ähnliche Beispiele innerhalb eines Regelwerks ab.

Ein Anwendungsfall ist sehr klar definiert und gegen andere Anwendungsfälle abgegrenzt, sodass für jeden Anwendungsfall ebenso klare Testfälle definiert werden können.

Der Begriff Anwendungsfall wird innerhalb der IT etwas schwammig benutzt. So kann ein einzelner abgeschlossener Benutzerdialog als ein einziger Anwendungsfall betrachtet werden, oder aber er kann ein ganzes Teilsystem umfassen. [Fowler2] S. 42 spricht z.B. von ca. einem Dutzend Basis-Anwendungsfällen in einem Projekt, das zehn Personenjahre umfasst, verweist jedoch auf andere Projekte derselben Größenordnung mit über hundert Anwendungsfällen. Bricht man die Beschreibung einer Anwendung bis auf Bildschirmebene herunter (und dies muss man, wenn ein Anwendungsverhalten vollständig beschrieben sein soll) und beschreibt jeden dieser Vorgänge als Anwendungsfall, so kann man bereits bei Anwendungen in der Größenordnung einiger Personenmonate auf mehrere Dutzend Anwendungsfälle kommen.

Den Anwendungsfällen muss eine Auflistung und Erklärung der Akteure vorangestellt werden. Eine Übersichtstabelle, die Name, Identifier und Beschreibung aller Anwendungsfälle enthält, ist sicher nicht falsch.

Der Aufbau eines Anwendungsfalls kann etwa so aussehen:

Nehmen wir als Beispiel einen Anwender, der sich in (irgendeinem System) anmeldet..

Erfundenes Beispiel:

Name und Identifier: UC 1.01 Anwender meldet sich am System an.

Beschreibung:
Der Anwender meldet sich mit seinen Benutzerdaten (Benutzername, Passwort) am System an und er erhält das Hauptauswahlformular, von dem aus er die Sitzung weiter führen kann.
Beteiligte Akteure: Anwender, System

Status: bereit zum Review

Verwendete Anwendungsfälle: keine

Auslöser: Die Aktion wird vom Anwender explizit ausgelöst.

Vorbedingung:
  1. Der Anwender hat das Anmeldeformular F-L 1.00 aufgerufen.
Nachbedingung / Ergebnis:
  1. Der Anwender ist im System angemeldet.
  2. Die Hauptauswahlformular F.H 1.01 erscheint.
  3. Der Security-Counter wird auf 0 gesetzt.
  4. Eine Sitzung ist generiert.
Ablaufschritte:
  1. Der Anwender tippt Benutzername und Passwort ein und klickt auf den login-Button.
  2. Das System identifiziert den Anwender anhand seines Benutzernamens und stellt das Datenobjekt Benutzer bereit.
  3. Das System prüft den Security-Counter des Datenobjekts Benutzer. Ist der Security-Counter < 3 wird regulär fortgefahren.
  4. Das System prüft das eingegebenen Passwort gegen das im Datenobjekt Benutzer hinterlegten Passwort.
  5. Ist das Passwort identisch, so wird regulär fortgefahren.
  6. Der Security-Counter wird auf 0 gesetzt.
  7. Eine Sitzung wird für den Anwender generiert, der Anwender ist damit im System angemeldet.
  8. Das Hauptauswahlformular wird angezeigt.
Alternative Ablaufschritte:
2.1 Der Benutzername ist unbekannt, es kann kein Datenobjekt Benutzer für den eingetippten Benutzernamen gefunden werden.
2.2 Das System zeigt Fehlerformular F 1.1 an und der Vorgang wird beendet.

3.1 Security-Counter >= 3
3.2 Das System zeigt Fehlerformular F 1.2 an und der Vorgang wird beendet.

5.1 Das eingegebene Passwort ist nicht mit dem hinterlegten Passwort identisch.
5.2 Der Security-Counter wird um 1 hochgezählt.
5.3 Das System zeigt Fehlerformular F 1.1 an und der Vorgang wird beendet.
Ausnahmen:
  1. Datenobjekt Benutzer kann nicht bereit gestellt werden.
  2. Security-Counter < 0
  3. Hinterlegtes Passwort ist "null" (kein Passwort ist nicht erlaubt)
  4. Sitzung für den Benutzer kann nicht generiert werden.
  5. Hauptauswahlformular kann nicht geladen werden.
Hinweise:
  1. Das Datenobjekt Benutzer ist im Abschnitt xy erklärt.
  2. Wir gehen davon aus, dass sich der durchschnittliche Benutzer 3 mal pro Woche anmeldet. 70% der Benutzer tun dies erfahrungsgemäß zwischen 17:00 und 20:00 an Werktagen, der Rest gleichmäßig über den Tag zwischen 8:00 und 22:00; an Wochenende und Feiertagen ist die Last gleichmäßig über den Tag verteilt.
  3. Alle Daten, die in der Hauptauswahlmaske angezeigt werden müssen (vgl. Story Board XY) sind im Datenobjekt Benutzer enthalten.
  4. Werden vor oder hinter dem Benutzernamen Leerzeichen eingetippt, so müssen diese vor der Suche nach dem Datenobjekt Benutzer entfernt werden.
  5. Das Datenobjekt Benutzer wird immer eindeutig anhand des Benutzernamens identifiziert.
Änderungshistorie:
0.1 Karl Scharbert, 5.10.2003 (review failed, keine Quantifizierung der Nutzungshäufigkeit)
0.2 Karl Scharbert, 7.10.2003
Bei den Ausnahmen handelt es sich offensichtlich um Katastrophen, die nicht eintreten dürften. Wenn das Datenobjekt Benutzer nicht erstellt werden kann, liegt wahrscheinlich ein Datenbankfehler vor, d.h. die Datenbank ist nicht erreichbar. Wenn das Passwort null ist oder der Security-Counter < 0 ist, dann sind die Daten zerstört worden, vermutlich liegt ein schwerwiegender Datenbankfehler vor oder die Daten wurden unkontrolliert verändert. Kann eine Sitzung nicht generiert werden oder das Hauptauswahlformular kann nicht geladen werden, dann ist der zuständige Server (bei Internetanwendungen der Webserver) vermutlich nicht erreichbar. - Den technischen Hintergrund dazu muss der Fachanwender nicht kennen, der Business Analyst sollte ihn kennen und auch beschreiben können. Die Behandlung solcher Ausnahmen besteht i.d.R. nur in der Protokollierung solcher Fehler, was später die Suche und Behebung erleichtert. Es obliegt dem Auftraggeber zu entscheiden, wie differenziert auf solche Ausnahmen geachtet werden soll. Wird das Thema vernachlässigt, so fühlt man dies erst im realen Betrieb, z.B. weil eine Anwendung immer wieder ausfällt, die Ursache dafür aber nicht gefunden werden kann.

Anwendungsfälle können manchmal technischer sein, als hier dargestellt. Z.B. können konkrete Konfigurationsparameter benannt werden. Dies ist allerdings nur dann der Fall, wenn bereits existierende und parametrisierbare Komponenten verwendet werden. Soweit möglich, sollte ein Fachanwender damit nicht belastet werden.

Zu den Anwendungsfällen können auch Anwendungsfalldiagramme gezeichnet werden, wie sie die UML vorsieht. Im Web findet sich hierzu reichlich Anschauungsmaterial.

Daten

vgl. hierzu Darstellungsformen für Daten,  Bildschirmformulare und Prozesse und Datenmodellierung

Datenquellen / Input

Für alle Datenquellen muss als Resultat der Geschäftsdatenanalyse die Herkunft nachgewiesen werden. Neben den reinen Schnittstellenbeschreibungen technischer Schnittstellen (ggf. auch zu Messgeräten!)  ist auch die Eingabe des Anwenders relevant.

Im Rahmen der Definition von Mengengerüsten muss auch die Datenmenge, Datenformate, Wertebereich und die Lieferfrequenz beschrieben werden. Ebenfalls wichtig ist die Gültigkeit der Daten. Macht z.B. die Verarbeitung von zu spät angelieferten Daten noch Sinn, oder sollen lieber aktuellere Daten benutzt werden?

Wichtig sind auch Aussagen zur Genauigkeit und Vollständigkeit der Daten. Augenscheinlich ist dies stets bei Benutzereingaben: Hat der Anwender tatsächlich alle Daten immer griffbereit? Ist es akzeptabel, irgendeinen gültigen Wert einzugeben, wenn der Anwender nicht den richtigen Wert zur Verfügung stehen hat? Was passiert, wenn falsche Daten geliefert wurden? Gibt es eine Art Korrekturdatensatz, der dann wiederum zur Korrektur von alten Ergebnissen führt?
Beispiel aus der Praxis

Wer kennt nicht das leidige Thema einer falschen Telefonrechnung? Nach einer Kundenreklamation, oder auch schon wenn die Techniker einen Hardware-Fehler nachweisen konnten, liefert ein Billing-System Korrekturdatensätze. Diese gelten natürlich nicht nur für die Kundenrechnung sondern für alle nachfolgenden Prozesse, die schließlich sogar auf die Quartalszahlen für den nächsten Börsenbericht des Unternehmens Auswirkung haben können.

Datensenken / Output

Für Datensenken gilt sinngemäß dasselbe wie für Datenquellen. Neben der Definition des Zielorts und Angaben zu Datenmenge, Datenformat, Wertebereich sind Lieferzeitpunkte bzw. Lieferfrequenz festzuschreiben. Soweit angebracht, müssen auch Angaben über die Genauigkeit der Daten gemacht werden. Wurden z.B. statistische Ergebnisse absolut genau ausgezählt, oder sind wegen unberücksichtigter Ausnahmen Abweichungen möglich? Im Beispiel kann dies zu Ärger führen, wenn die Statistik von der Fachabteilung zur ungefähren Quantifizierung von Geschäftsergebnissen benutzt werden soll, aber von den Technikern zu Prüfzwecken gegen eine andere Schnittstelle benutzt wird und sich Abweichungen ergeben.

Reporte und gedruckte Ausgaben

Zu definieren sind die genauen Report-Formate. Bei Druckausgaben können z.B. besondere Anforderungen an die Schriftgröße, Papierformat, Font, zusätzlicher Platz für Notizen etc. gegeben sein.

Beispiel aus der Praxis

In Arztpraxen werden anch wie vor Nadeldrucker eingesetzt, da bestimmte Forumulare mit Durchschlag(!) ausgefüllt werden müssen. Dazu ist ein besonderes Papier notwendig, das auch nur mechanisch bedruckt werden kann.

Datenmodell

Fertige Datenmodelle für ganze Anwendungen sind normalerweise sehr groß. Eine Tapete von zwei mal zwei Metern ist nicht all zu bemerkenswert. Unter normalen Fachanwendern findet sich kaum jemand, der willens und fähig ist, solch ein Modell komplett zu lesen und zu beurteilen. Da jedoch eine Anwendung in einzelne Teile zerlegt werden kann, kann eine graphische Darstellung einzelner Modellteile aus hoher Sicht erwogen werden. Die Erfahrung zeigt, dass eine tabellarische Auflistung der verwendeten Daten bei der Darstellung einzelner Prozesse normalerweise ausreicht.

Vorsicht ist auf jeden Fall geboten, wenn ein Fachanwender ein physikalisches Datenmodell analysieren will, selbst wenn er augenscheinlich hohe IT-Kompetenz haben müsste. Dies ist dann der Fall, wenn ohne gründliche Spezifikationsphase gearbeitet wird und nur konkrete technische Ergebnisse für einen Review bzw. eine Abnahme vorliegen.
Beispiel aus der Praxis

Ein Fachanwender einer Sales-Abteilung erklärte, dass er einen Abschluss in einem IT-Ausbildungsberuf hätte, jedoch nach einem halben Jahr Cobol-Programmierung zu dem Schluss gekommen sei, dass die IT nichts für ihn wäre. Der Branchenwechsel lag bereits einige Jahre zurück. Er bestand darauf, ein physikalisches Datenmodell zu lesen. Dies war im konkreten Fall wünschenswert, sogar notwendig, da die Entwicklung ohne ein abgenommenes Fachkonzept stattfand. Sehr viele Anforderungen waren auf Zuruf geregelt worden. Der Fachanwender erhielt von einem analyst/programmer einen Walkthrough und bejahte die Vollständigkeit des Modells. Nach dem ersten Betrieb des Produkts reklamierte er jedoch, dass bestimmte von ihm gewünschte Ergebnisse nicht aus der Datenbank zu extrahieren seien. Dies war aus dem Datenmodell offensichtlich zu ersehen, die Anforderung war zuvor niemals artikuliert worden. Der notwendige Änderungsaufwand hätte das Budget gesprengt, sodass auf eine Modifikation der Anwendung verzichtet werden musste.

Datenobjekte

Gemeint sind hier fachliche Datenobjekte. Nicht in allen Anforderungsdokumenten wird mit solchen Datenobjekten gearbeitet. Sofern jedoch, wie im Beispiel beim Anwendungsfall eines benutzt wird, muss es auch explizit erklärt werden. Die Darstellung wird normalerweise in Form einer Tabelle sein, die alle Attribute auflistet.

Interfaces

vgl. hierzu Darstellungsformen für Daten,  Bildschirmformulare und Prozesse

Neben reinen Dateninterfaces können auch Kommunikationsschnittstellen mit anderen externen Produkten (hard- und software!) gegeben sein. Die Fachabteilung weiß davon in den seltensten Fällen etwas, und der Business Analyst wird sich damit nur insofern befassen, als er die notwendigen Unterlagen beschafft und als Anlage zum Anforderungsdokument beifügt bzw. dafür sorgt, dass die richtigen Leute miteinander sprechen. Zwar ist dies eher eine Aufgabe des Projektleiters, jedoch wird nur ein technisch und fachlich sehr versierter Projektleiter überhaupt in der Lage sein, unabhängig von seinem Analytiker mehr als nur die Existenz dieser Schnittstellen feststellen zu können.

Ein Beispiel ist die Einbindung von Servlets eines Content-Anbieters in das Content Management System des Kunden, wobei beide Systeme physikalisch voneinander getrennt sind. Der Business Analyst stellt die Existenz solcher Interfaces und die grundlegende Anforderung, dass Kommunikation stattfinden wird, fest. Die notwendigen Unterlagen werden der Anforderungsanalyse beigefügt und sollten frühzeitig auf ihren Einfluss auf die zu implementierenden Prozesse hin überprüft werden. Diese Prüfung kann in den Aufgabenbereich des Business Analysten fallen, in jedem Fall wird sich ein technischer Mitarbeiter des IT-Teams damit im Detail befassen müssen.

Randbedingungen der Systemumgebung

Hierunter fallen verbindliche Vorgaben über zu verwendende Entwicklungswerkzeuge, Laufzeitplattformen und jede andere Form von Produktabhängigkeiten. Z.B. muss bei Internetanwendungen die genaue Browser-Version angegeben sein.
Beispiele aus der Praxis

Bei einer Internetanwendung verlangte der Kunde pauschal die Unterstützung aller Browser. Nachdem er eine Marktübersicht vorgelegt bekommen hatte und ihm recht deutlich die Kosten für den Test und absehbare notwendige individuelle Anpassungen des HTML-Codes vor Augen geführt worden waren, beschränkte er sich auf die Forderung, mit einer Browser-Version vollständig zu testen und zwei andere lediglich stichprobenartig auf look and feel zu prüfen.

Als der Betriebssystemkrieg zwischen OS/2 und Windows noch in vollem Gange war, stellte ein Kunde die Forderung, dass eine von ihm bestellte Software, die u.a. einen Graphen-Editor enthielt, auf beiden Plattformen laufen müsse. Die ebenfalls vom Kunden vorgegebene Bibliothek, die diese beiden (und einige weitere) Betriebssysteme unterstützte, machte es notwendig, bestimmte Wünsche zur graphischen Oberflächen-Gestaltung zu streichen, die sich schließlich auch in der funktionalen Umsetzung der Forderungen bemerkbar machte.
Abhängig vom jeweiligen Projekt können auch besondere Forderungen an die Hardware gestellt werden, z.B. dass unbedingt Spiegelserver verwendet werden sollen. Diese Aussagen gehören aber eher nicht in ein Anforderungsdokument.

Verlässlichkeit

Aussagen über Konsequenzen aus Abstürzen, Fehlererkennung, Wiederaufsetzen und Schutz vor Verfälschungen der Daten gewinnen um so mehr an Wichtigkeit, je genauer ein System (im Sinne des Konfliktes Robustheit vs. Genauigkeit) arbeiten muss und je teurer ein Ausfall wird. Im weiteren Sinne können hier auch notwendige Betriebsunterbrechungen für Wartungsarbeiten eingeordnet werden, die als geplante Ausfälle eingestuft werden können.
Beispiele aus der Praxis

Im Rahmen eines Verwaltungsvorgangs bei einer Behörde wurde sowohl ein Status für einen personenbezogenen Datensatz gespeichert, als auch zeitgleich ein Schreiben ausgedruckt. Erst, als bei einem Drucker das Papier ausging und der Druck fehlschlug, kam man dahinter, dass sich der Ausdruck nicht wiederholen ließ, da das Kennzeichen bereits gespeichert war und der Vorgang nur als ganzes möglich war und nicht wiederholt werden konnte. In der Folgeversion wurden die beide Prozesse "Status setzen" und "Schreiben ausdrucken" getrennt.

Um Ausfallsicherheit in einer Anwendung zu gewährleisten, wurden Spiegelserver in getrennten Brandabschnitten gefordert. Da sich zeigte, dass das System extrem ausfallsicher war, wurde später entschieden, dass Totalabstürze, Netzwerkunterbrechungen und die Wiederaufsetzprozedur nach einem totalen Datenverlust einmal jährlich geübt werden sollten. Gelegentlich zog ein Techniker nur irgendwo einen Stecker oder schnitt ein Kabel durch, damit die Notfallprozeduren nicht in Vergessenheit gerieten.

Die Unterbrechung eines Montagevorgangs in der Autoindustrie kostet einige tausend Euro pro angefangene fünf Minuten.
Das erste Beispiel zeigt, dass Fehlertoleranz eine Frage der IT-Prozess-Gestaltung sein kann, denn ein Geschäftsprozess als solcher muss sich nicht mit Druckern ohne Papier befassen.

Man bewegt sich als Business Analyst bei der Definition von Anforderungen zur Ausfallsicherheit oder den Konsequenzen aus Abstürzen in einer Grauzone. I.d.R. kann der Analytiker lediglich die Wichtigkeit der Daten klassifizieren und zusammen mit den Fachanwendern eine Kostenschätzung für einen Totalausfall von einem Tag o.ä. abgeben und dann Forderungen dahingehend fixieren, wie lange ein Ausfall tolerierbar ist. Ggf. werden abhängig von diesen Aussagen Konventionalstrafen vereinbart. Mit der Entwicklung benutzerspezifischer Software haben solche Anforderungen nur wenig zu tun, berücksichtigt müssen sie aber dennoch werden.

Gelegentlich ist man mit unrealistischen Anforderungen oder unsinnigen Regelungen konfrontiert, die Nicht-IT-Spezialisten nur schwer vermittelbar sind:
Beispiel aus der Praxis:

In einen Vertrag wurden 99,9% Verfügbarkeit für einen bestimmten Service zugesichert, bei dem reichlich Hardware involviert war. Konkret bedeutet dies, dass ein System nur 86,4 Sekunden pro Tag oder 8:45 Stunden pro Jahr nicht erreichbar sein kann. Die Zeit reichte bestenfalls, um einmal pro Jahr umfangreichere Systemarbeiten durchführen zu können. Die vereinbarten Betriebskosten reichten bei weitem nicht aus, um die dafür notwendige Hardware hinreichend redundant vorzuhalten, jedoch gab es keinen wirklichen Grund, eine so hohe Ausfallsicherheit anzustreben. Bei der Vertragsgestaltung wurde das technische Personal nicht konsultiert.

Ein Mitarbeiter eines Rechenzentrums einer Behörde hatte eine erhebliche Auseinandersetzung wegen der Änderung einer Gleitzeitregelung. Bislang war abzusehen, dass die Mitarbeiter des Verwaltungsbereichs gegen 17:00 das Haus verließen und anschließend Wartungsarbeiten an Hard- und Software erfolgen konnten. Nach einer weiteren Liberalisierung der Arbeitszeiten konnten die Mitarbeiter bis 19:30 bleiben. Der Rechenzentrumsmitarbeiter schlug eine Erweiterung seiner persönlichen Gleitzeit auf 20:30 vor, um nach wie vor einen unterbrechungsfreien Tagesbetrieb zu gewährleisten. Der Wunsch wurde abgelehnt. Auf Rückfrage wurde ihm jedoch bestätigt, dass man ohne weiteres akzeptiere, dass der Betrieb des Systems in den Kernzeiten(!), also immer dann, wenn alle Mitarbeiter (ca. 50) mit dem System arbeiten sollten, unterbrochen wird.

Sicherheitsanforderungen

Die Verarbeitung sensibler Daten, an erster Stelle personenbezogener Daten, erfordert besondere Sicherheitsmaßnahmen, die z.T. gesetzlich geregelt sind. Der Analytiker wird hierzu i.d.R. die Hausjuristen konsultieren, bei anderen zu schützenden Daten (z.B. wesentliche Geschäftsdaten oder Betriebsgeheimnisse) kann die Fachabteilung selbst Auskunft geben.

Die Ausarbeitung dieser Forderungen ist i.d.R. keine einfache Angelegenheit und stößt häufig an Verständnisgrenzen.
Beispiele aus der Praxis

Ein mittlerer Manager ohne jeden IT-Hintergrund bekam einmal mit, dass Administratoren Zugriff auf alle Systeme eines Rechners haben. Er wollte dies verbieten.

Das Datenschutzgesetz verlangt, dass bei einer Löschung personenbezogener Daten auch alle Kopien dieser Daten gelöscht werden. Technisch ist es aber nicht machbar bzw. nicht bezahlbar und auch nicht sinnvoll, Datensicherungen aus dem Schrank zu ziehen um dort nach einzelnen Datensätzen zu suchen, da ja dort die Vergangenheit soz. eingefroren ist.

Ein Abteilungsleiter verlangte einmal pauschal, dass niemand Zugriff auf bestimmte Daten haben dürfe. Die Rückfrage des Analytikers, wozu dann die Daten gespeichert würden, wurde zunächst nicht verstanden. Die Definition von Zugriffsrechten war im konkreten Fall jedoch einfach.
Sicherheitsanforderungen können verschlüsselte Übertragung von Daten oder auch besondere Forderungen zum Schutz der Hardware umfassen.

Gesetzliche Forderungen und Regelungen

Gemeint ist hier vor allem das Bundesdatenschutzgesetz bzw. die Landesdatenschutzgesetze, die bei der Verarbeitung personenbezogener Daten zu beachten sind. Z.B. sind manche Verfahren genehmigungspflichtig, andere nur anzeigepflichtig beim Datenschutzbeauftragten des jeweiligen Bundeslandes. Dies zu regeln ist Aufgabe des Hausjuristen. Da die Mitarbeiter der Fachabteilungen normalerweise keinerlei Sensibilität für gesetzliche Forderungen haben, wird der Datenschutzbeauftragte so gut wie immer übergangen und meist erst in einer fortgeschrittenen Projektphase vom Business Analysten mehr oder weniger zufällig und manchmal sogar gegen den Willen der Fachabteilung in Kenntnis gesetzt.

Auswirkungen auf den Entwicklungsprozess bestehen grundsätzlich, u.a. da nachgewiesen werden muss, wer welche Daten wann geändert hat; d.h. eine Prtokollierungsfunktion muss vorgesehen werden. Ebenfalls muss nachgewiesen werden können, welche Daten wann an wen weitergegeben worden sind. Die konkreten Erfordernisse müssen zunächst mit dem Hausjuristen abgestimmt werden und dann in der Anforderungsanalyse beachtet werden. Der Gesetzgeber fordert auch besondere Maßnahmen zum Schutz der Daten vor Verfälschung oder Missbrauch. Die Aufgabe des Analytikers kann in diesem Fall auch sein, neben den IT-Prozessen manuelle Geschäftsprozesse bis hin zu Arbeitsanweisungen zu definieren.

Zu beachten ist §202a StGB, der eine Bestrafung für das Ausspähen von Daten nur dann vorsieht, wenn die Daten "gegen unberechtigten Zugriff besonders gesichert" sind. Sehr viele Sicherungsmechanismen können ohne weiteres selbst von einem Schüler der Mittelstufe ausgehebelt werden, von einer besonderen Sicherung kann deshalb häufig nur schwerlich die Rede sein. Vielmehr muss man eher von Nachlässigkeiten beim Hersteller und Betreiber der Software ausgehen.
Beispiele aus der Praxis

Eine Behörde, die personenbezogene Daten verarbeitete, protokollierte bis auf Attributebene mit, welcher Mitarbeiter welche Daten wann geändert hatte. Außerdem galt eine Arbeitsanweisung, dass nur rote Disketten verwendet werden durften, um solche Daten auf einen Datenträger zu speichern. Weiterhin wurde festgelegt, dass Dateien mit umfangreichen Stammdatensammlungen, die regelmäßig aus dem Verwaltungsbereich (der keine Verbindung zum Internet hatte) in einen öffentlichen Bereich übertragen wurden, nur PGP-verschlüsselt auf die Reise gehen durften.

Der Leiter eines Verwaltungsrechenzentrums einer süddeutschen Universität entlieh sich Anfang der 90er Jahre informell zur Prüfung der Datensicherheit im Hause einen Mitarbeiter der Behörde aus dem letzten Beispiel für einen Tag. Dieser Mitarbeiter war u.a. für ein gewisses Maß an Unverschämtheiten bekannt. Zunächst loggte er sich in einen Service-account ein, dessen Kennwort für das betroffene Betriebssystem hinlänglich bekannt war. Anschließend ließ er sich die Telefonnummer eines ausgelosten Mitarbeiters geben und rief dort an. Mit unverhohlenen Drohungen und Druck ("Bin von der Fernwartung... Jede Verzögerung wird ihrem Arbeitgeber in Rechnung gestellt...") erfragte er sich Passworte von sensiblen Benutzerkonten. Nebenbei wurden auch noch an Pinwände geheftete Benutzernamen samt Passworten gefunden.

Nach wie vor "entdeckt" Microsoft bzw. irgendein Bastler immer wieder so gravierende Sicherheitslücken in MS-Produkten inkl. Betriebssystemen, die schon seit Jahren am Markt sind, dass sogar der gesamte Rechner ferngesteuert werden kann. Die Freigabe der Patches hinkt dabei naturgemäß der Entdeckung und Veröffentlichung der Lücken hinterher.
Gegen technische Pannen und Sicherheitslücken kann der Business Analyst nicht viel machen. Seine Aufgabe besteht vor allem darin, die Sensibilität der Daten zu klassifizieren. Gemeinsam mit Juristen, Technikern und Fachanwendern kann er dann Arbeitsanweisungen erarbeiten, die zum Schutz der Daten beitragen. Auf die Einhaltung dieser Arbeitsanweisungen hat er keinen Einfluss mehr. Es obliegt dem technischen IT-Personal, geeignete besondere Sicherungsmechanismen zu definieren und zu implementieren. Die Konsultation eines Sicherheitsexperten kann im Einzelfall angezeigt sein.

Benutzerrollen

Zu definieren ist, wer welche Zugriffsrechte hat, wer also welche Daten eingeben, ändern oder löschen kann bzw. wer welche Vorgänge auslösen kann. Die Regelung der Rechte kann auf Ebene ganzer Datenobjekte, einzelner Attribute, aber auch auf  Basis von Funktionalitäten und Prozessen geregelt werden. So kann z.B. rein Datenbank-technisch jeder Anwender jeden Datensatz löschen können, da auf Ebene der Datenbank keine Benutzerrollen mit den zugehörigen Rechten definiert werden, aber auf Anwendungsebene kann die Löschfunktion dafür nicht von jedem Anwender erreicht werden.
Beispiel aus der Praxis

Bei fast allen Anwendungen können wesentlich mehr Mitarbeiter auf Daten lesend zugreifen, als ändernd.

Wartbarkeit und Weiterentwicklung

Ein Unternehmen samt seinen Geschäftsprozessen ist nicht in Stein gemeißelt. Definiert werde muss daher, soweit dies absehbar ist, an welchen Stellen mit welcher Wahrscheinlichkeit sich die Geschäftslogik ändern kann. Das Geschäft verändert sich und somit auch die Anforderungen an das IT-System. Da ein System, das leicht zu warten und weiter zu entwickeln ist, stets teurer, manchmal sogar sehr viel teurer ist, als ein System, das man nur einmal schreibt, einige Zeit benutzt und dann weg wirft, dürfen klare Vorgaben nicht fehlen. Zu spezifizieren ist auch die Dauer des geplanten Einsatzes.
Beispiel aus der Praxis

Mein erstes Projekt war die Umstellung eines Amtes auf IT, eine Clipper-Lösung unter DOS. Wir gingen damals, im Jahr 1989, davon aus, dass nach spätestens fünf Jahren ein neues System eingeführt werden würde. Das System wurde jedoch kontinuierlich weiterentwickelt. Heute (Ende 2004) ist noch immer nicht in Sicht, wann das System abgelöst wird. Im Gegenteil wird das weiter entwickelte System von anderen Behörden genutzt.
Werden klare Forderungen zur Wartbarkeit und Weiterentwicklung unterlassen, so kann dies ein teurer Spass werden. Jeder Auftragnehmer wird die Entwicklungskosten stets für sich so niedrig wie möglich halten. Am einfachsten ist dies, wenn die Geschäftslogik hart im Programm eincodiert ist. Die Konsequenz ist, dass die Wartungskosten explodieren können.
Beispiele aus der Praxis

Ich sollte in meiner Entwicklerzeit ein Programmteil erweitern. Dabei ging es darum, dass auf einer Bildschirmseite 8 Spalten mit Informationen angezeigt wurden, die nun auf 12 Spalten erweitert werden mussten. Es stellte sich heraus, dass der Autor des Programms konsequent die Zahl 8 in den Code geschrieben hatte, anstatt einmalig eine Konstante zu definieren. Man spricht dabei in der IT von magic numbers (magischen Zahlen), die fest im Code stehen und von denen nicht klar ist, was sie eigentlich bedeuten. Ich war mehrere Tage damit beschäftigt, den Code nur dafür zu überarbeiteten und beantragte anschließend weitere vier Wochen, um den Code des Produkts insgesamt etwas wartungsfreundlicher zu machen.

Für Zahlungen war vom Auftraggeber eine dreistellige Hierarchie von Zahlungsempfängern gefordert worden. Im Datenmodell konnte nach Fertigstellung des Produkts festgestellt werden, dass diese Hierarchie statisch implementiert worden war (in einer Tabelle fand sich empfaenger1, empfaenger2, empfaenger3). Es war abzusehen, dass erhebliche Kosten anfallen würden, sollte jemals eine vierstufige Hierarchie eingeführt werden, jedoch hatte der Auftraggeber an diesen Fall nicht gedacht.

Aussagen bei Unvollständigkeit der Spezifikation, falls die Entwicklung vor Beendigung der Spezifikation beginnt

Falls für das Projekt ein Prozess-Modell gewählt worden ist, das vor Beginn der technischen Arbeiten ein vollständig abgenommenes Anforderungsdokument vorsieht, gibt es zur Verschiebung des Liefertermins bei Verzögerung eigentlich nur die Alternative, mit einer noch nicht vollständigen Spezifikation die Entwicklung zu beginnen. Dadurch wird das Prozess-Modell allerdings durchbrochen. Fehlende und unvollständige Prozesse sind zu dokumentieren.

Auf Teilabnahmen muss das IT-Team jedoch beharren, da sonst jede Entwicklung als Eigenmächtigkeit des Auftragnehmers betrachtet werden muss und keine Pflicht des Auftraggebers hergeleitet werden kann, dafür auch zu bezahlen. Die Teilabnahmen sollten weit genug gehen, damit ein Teilsystem fixiert werden kann, das für sich bereits vom Kunden abgenommen werden kann. Es ist müßig festzustellen, dass normale Fachanwender so gut wie nie die strikt planende Vorgehensweise von IT-Spezialisten kennen. Termin-Verzögerungen im Rahmen der Spezifikationsphase werden beinahe ausnahmslos vom Auftraggeber verursacht und sind Gegenstand einer Reihe von IT-Witzen. In den wenigen verbleibenden Fällen liegen Personalengpässe beim Auftragnehmer vor, der Analytiker ist nicht verfügbar, oder der Analytiker ist bei weitem nicht kompetent genug, um eine Anforderungsanalyse selbstständig durchzuführen, und seine Spezifikation fällt fortwährend bei den technischen Reviews durch. - Übrigens ist die häufig unbefriedigende Kooperation der Fachabteilungen eine der wesentlichen Ursachen für die frustrierende Seite der technischen Arbeit in IT-Projekten.

Sollte von Projektbeginn an Terminenge bestehen, so sollte es gar nicht soweit kommen, dass eine unvollständige Spezifikation abgegeben wird. Statt dessen sollte ein nichtlineares Prozess-Modell gewählt werden, z.B. das evolutionäre oder das nebenläufige Modell.

Lassen sich implementierbare abgenommene Prozessketten identifizieren, so kann mit deren Implementierung begonnen werden. Dem Kunden sollte nachdrücklich kommuniziert werden, dass Änderungen an implementierten Prozessen, die in Folge der noch verschwommenen Anforderungen notwendig werden könnten, zu weiteren Verzögerungen führen werden. Der Analytiker kann dem Entwicklerteam helfen, indem er mögliche Varianten der noch nicht spezifizierten Prozesse aufzeigt, sodass die Entwickler von den kommenden Ereignissen nicht zu sehr überrascht werden und ihren Code einigermaßen flexibel halten können.

Definiert man den Begriff normal demokratisch, also als das, was die Mehrheit tut, so ist es normal, dass die Entwicklung vor Fertigstellung der Spezifikation beginnt. Zu einem erfolgreichen Projekt trägt dies jedoch nicht bei.

Projektspezifische Regelungen und Anforderungen

Jedes Projekt hat seine eigenen spezifischen Regelungen und Anforderungen, die sich nicht pauschal mit einer Dokumentenvorlage oder Checkliste abdecken lassen. Ein mögliches Beispiel ist die Forderung nach der Wiederverwendbarkeit einzelner Komponenten der Systemarchitektur.

Hier ist Ihre Initiative gefragt!
home - top - Kontakt - letzter Update 13.5.2004 - © Karl Scharbert