Vorbemerkung zur Begriffsdefinition: ,,Kunde`` ist bei der Anforderungsbestimmung die Person oder Institution, die die Software bezahlt. ,,Anwender`` sind die Personen(gruppen), die die Software persönlich benutzen oder von ihr unmittelbar in ihrer Arbeit beeinflußt werden. Im Falle von Fertigsoftware sind Kunde und Anwender also meist identisch, bei Auftragssoftware jedoch nicht. Auf der Entwicklerseite kann man unterscheiden zwischen Analytikern, die die Anforderungsbestimmung durchführen, und dem restlichen Softwareteam, das die Software realisiert. Diese Unterscheidung ist jedoch in der Praxis unscharf und wird hier deshalb nicht immer gemacht.
Die Anforderungsbestimmung umfaßt die gesamte erste Phase der Durchführung eines Softwareprojekts. Sie dient dazu festzustellen, was eigentlich gebaut werden soll (im Gegensatz zu wie). Dabei gibt es drei verschiedene Arten von Anforderungen: Funktionale Anforderungen, Qualitätsanforderungen und Randbedingungen (z.B. Hardware, Betriebssystem, vorhandene Software etc.). In diesem Abschnitt werden wir uns hauptsächlich (aber nicht ausschließlich) damit beschäftigen, wie man die funktionalen Anforderungen feststellt.
Der Prozeß der Anforderungsbestimmung ist auch unter diversen anderen Bezeichnungen bekannt: auf Deutsch als Anforderungsanalyse oder Anforderungsdefinition und auf Englisch als Requirements Elicitation, Requirements Engineering, Requirements Definition oder Requirements Gathering. Gelegentlich werden mit diesen Begriffen unterschiedliche Teilaspekte des Problems bezeichnet, oft aber auch nicht. Der deutsche Begriff Anforderungsbestimmung ist zwar eigentlich am zutreffendsten, das Englische requirements engineering drückt jedoch das Prozeßhafte daran besser aus.
Ergebnisse der Anforderungsbestimmung sind einerseits ein Pflichtenheft (das die Ergebnisse der Anforderungsbestimmung aus der Sicht des Kunden beschreibt) und andererseits eine Spezifikation (die das dazu korrespondierende Dokument für das Entwicklungsteam darstellt). Ob man das Erstellen der Spezifikation als Teil der Anforderungsbestimmung betrachtet oder nicht, ist im wesentlichen eine Ansichtssache. Allerdings werden beim Erstellen der Spezifikation oftmals Lücken oder Inkonsistenzen im Pflichtenheft aufgedeckt, die mit dem Kunden geklärt werden müssen, so daß das Erstellen der Spezifikation besser nicht erst komplett nach der Anforderungsbestimmung abläuft.
In der Vorlesung ,,Softwaretechnik`` wurde im wesentlichen nur der reine Spezifikationsaspekt behandelt, d.h. es wurde nur die Aufgabe betrachtet, eine bekannte Anforderung so aufzuschreiben, daß ein Entwicklungsteam sie in Software umsetzen kann. Hier wollen wir stattdessen nur das Problem betrachten, wie man die Anforderung selbst überhaupt ermittelt.
Für viele Softwareprojekte ist die Anforderungsbestimmung die kritischste Phase der ganzen Entwicklung. Das hat zwei Gründe: Erstens sind falsch bestimmte Anforderungen stets sehr teure Fehler, weil ihre Auswirkungen auf das gebaute System tendenziell umfangreich sind. Zweitens kann ein Projekt mit falsch bestimmten Anforderungen leicht ein totaler Fehlschlag werden, weil die Fehler über den gesamten Verlauf des Projektes nicht entdeckt werden. Das Softwareteam orientiert sich an den Anforderungen so wie sie sind, und die Anwender bemerken die Probleme erst bei der Einführung des Systems (oder sogar erst eine Weile nach der Einführung).
Aus diesem Grund kommt der Anforderungsbestimmung ein hoher Stellenwert zu, der in der Informatikausbildung leider meist sträflich vernachlässigt wird.
Drei Hinweise zum bisher gesagten sind unbedingt zu beachten:
Im einzelnen müssen folgende Probleme gelöst werden, damit eine Anforderungsbestimmung erfolgreich ist (dies ist eine erweiterte Fassung der Aufstellung aus Abschnitt 3.2.4):
Wie kommuniziert man mit den Anwendern? Dies ist das vorderste und oftmals größte Problem der Anforderungsbestimmung: Wie führt man die völlig verschiedenen Erfahrungshintergründe und Terminologien von Anwendern und Softwareleuten so zusammen, daß eine erfolgreiche Kommunikation zustandekommt und Mißverständnisse vermieden werden?
Wie entdeckt man Anforderungen? Häufig sind die Anwender nicht nur unfähig, ihre Anforderungen so auszudrücken, daß ein Softwaremensch sie verstehen kann, sondern sie kennen sie schlichtweg gar nicht. Es ist daher ein gemeinsames Ziel von Anwendern und Softwareteam, zunächst einmal überhaupt zu entdecken, welche Anforderungen man sinnvollerweise an ein Softwaresystem haben könnte oder sollte.
Wie setzt man vage Anforderungen in konkrete um? Anforderungen haben oft einen sehr vagen, qualitativen Charakter. Musterbeispiel hierfür ist die Forderung nach Benutzerfreundlichkeit. Ein wichtiges Ziel der Anforderungsbestimmung ist die Umwandlung solcher Anforderungen in eine Form, die für beide Seiten als Vertragsgrundlage akzeptabel ist, klare Richtlinien für die Systemgestaltung vorgibt und zweifelsfrei geprüft werden kann.
Wie versteht man Prioritäten und Zufriedenheitskriterien des Anwenders? Dieses Problem ist eng mit dem vorigen gekoppelt. Bei Konflikt zwischen Anforderungen oder Auftreten von Problemen im Projekt ist die Prioritätensetzung eine kritische Frage, die früh geklärt werden muß. Hierzu, und beim Versuch, vage Anforderungen zu verstehen, ist es nützlich, ein Verständnis dafür zu haben, warum ein Anwender mit irgendeiner Lösung zufrieden oder eben nicht zufrieden ist.
Wie stellt man Eindeutigkeit sicher? Besagte Konflikte zwischen Anforderungen sollten natürlich möglichst früh erkannt und aus der Anforderungsbeschreibung entfernt werden. Es stellt sich also die Frage, wie man sie systematisch auffinden und auflösen kann.
Wie geht man mit Unvollständigkeit um? Idealerweise ist die Anforderungsbestimmung beendet, wenn alle Anforderungen genau bestimmt sind. Es fragt sich also, wie man das feststellt. In sehr vielen Fällen nimmt man jedoch bewußt Unvollständigkeiten in Kauf. Dabei entsteht das Problem, welche (Arten von) Unvollständigkeiten akzeptabel sind und wie man weiter mit ihnen verfährt.
Wie löst man Interessenkonflikte? Alle diese Arbeiten werden in vielen Fällen dadurch erschwert, daß es Interessenkonflikte zwischen verschiedenen Anwendern gibt oder zwischen Anwendern (z.B. Belegschaft) und Auftraggebern (z.B. Firmenleitung). Ein Beispiel wäre der Datenschutz: Viele Daten, die sich leicht erfassen ließen, wären für die Firmenleitung ein attraktives Mittel zur Überwachung der Arbeitsleistung ihrer einzelnen Mitarbeiter, führen aus deren Sicht jedoch zu einer Verletzung ihrer Persönlichkeit (,,big brother``). Ein Ignorieren solcher Konflikte führt fast immer zu einer schlechten Anforderungsdefinition. Deshalb müssen die Konflikte klar identifiziert und offen ausgetragen werden, um zu einem eindeutigen und sinnvollen Anforderungskatalog zu gelangen.