Die Phase der Anforderungsanalyse und der Spezifikation hat zum Ziel, die Fragen nach dem WAS zu klären:

• Was soll das System können? (=>Funktionalität)
• Was ist das System? (=> Abgrenzung zu Akteuren und anderen Systemen)
• Was ist der Nutzen des Systems? (z.B. Geld, Image, ...)

Die technische Realisierung ist an dieser Stelle noch völlig uninteressant.

Problem- und Aufgabenstellung

Durch eine Beschreibung des Ist- und des Sollzustandes wird verdeutlicht, worin die Aufgabe liegt. Dies beinhaltet

• Business-Case: Welchen (meist finanziellen) Nutzen erhoffen wir uns durch die Realisierung des Projekts? In welchem Zeitraum, in welcher Größe?
• Alternativen: Welche anderen Möglichkeiten hätte es gegeben, um das Ziel zu erreichen? Weshalb haben wir uns für die gewählte entschieden? Hiermit lassen sich am Ende des Projekts die getroffenen Annahmen gut überprüfen.

Stakeholder

In diesem Zusammenhang ist es ratsam zu reflektieren und dokumentieren, wen dieses System betrifft, wer helfen und wer schaden kann, das Ziel des Systems zu erreichen.

• Wer sind die Benutzer? Was sind deren wirkliche Interessen?
• Wer gibt den Auftrag?
• Wer nimmt das System ab?
• Wer betreibt das System?
• Wen betrifft das System? Wer profitiert davon und wer nicht?

Der Begriff des Stakeholders umfasst alle, die an der Entwicklung, dem Betrieb oder der Vermarktung des Systems Interesse haben.

Anforderungen

Die Spezifikation der Anforderungen stellt den zentralen Punkt dieser Phase dar. Sie unterscheidet

• Funktionale Anforderungen: Hier muss genau beschrieben werden, wie das System funktioniert, was es leistet, wie man damit arbeiten wird. Es ist auch ratsam zu beschreiben, was das System nicht kann, besonders wenn man das implizit annehmen würde.
• Nichtfunktionale Anforderungen: Dies sind oft technische oder regulatorische Anforderungen wie Verfügbarkeit, Antwortzeiten, Skalierbarkeit, Stabilität, zu erfüllende Gesetze und Standards, Kompatibilität, Portierbarkeit uvm.
• Priorisierung der Anforderungen: Fast jedes Projekt hat mit Zeit- oder Budgetknappheit zu kämpfen. Daher sollte bereits bei Beginn entschieden werden, auf welche Anforderungen am ehesten und auf welche keinesfalls verzichtet werden kann.

Tests

Auch wenn es nicht jeder Entwicklungsprozess verlangt, so sei doch stärkstens empfohlen, in dieser Phase die Akzeptanzkriterien und die funktionalen Tests zu beschreiben. Damit wird sichergestellt, dass die beschriebenen Anforderungen wirklich messbar sind. Die meisten Spezifikationen leiden unter zu allgemein gehaltenen Anforderungen wie "muss gut benutzbar sein", "sollte stabil laufen und flüssiges Arbeiten ermöglichen".

Systemgrenzen

Nachdem geklärt wurde wer mit dem System arbeitet und was die Anforderungen an das System sind, muss weiter beschrieben werden, welcher Teil des Systems mit diesem Projekt realisiert wird und welcher Teil durch Fremdsystem abgedeckt wird. Dazu gehört eine Beschreibung der Schnittstellen zu diesen anderen System.

Sonstiges

Ebenso Teil der vollständigen Dokumentation, die während dieser Phase zu entworfen wird, sind:

• Annahmen, beispielsweise über Benutzerprofile, Datenvolumen, Häufigkeit der Nutzung, existierende Software und Hardware
• Projektplanung: Zeit, Geld, personelle Ressourcen

Kriterien für die Anforderungen in einer guten Spezifikation

• Messbar, quantifizierbar (WICHTIG!)
• Widerspruchsfrei
• Vollständig
• Dokumentiert
• Nicht redundant

In etwa 80% der IT-Projekte werden (nach C. Jones, 1996) instabile oder wachsende Benutzeranforderungen zu einem Problem. Umso wichtiger ist es, die Anforderungen (zu Beginn) gemäß den eben genannten Regeln zu beschreiben.

Um möglichst rasch zu den Anforderungen zu gelangen, die obigen Kriterien genügen, haben sich folgende Vorgehensweisen bewährt:

• Workshops, in denen sich die Stakeholder treffen
• Brainstorming Sessions: Treffen bei denen die Experten zu einem Thema alle Gedanken notieren und strukturieren
• Vorstudie, um Alternativen zu untersuchen
• Rapid Prototyping: Ein Wegwerfprototyp kann geeignet sein, um einen Eindruck von der künftigen Applikation zu schaffen und zu überprüfen, ob die Anforderungen und Spezifikationen besonders von Benutzerschnittstellen angemessen sind
• Use-Case-Analyse, die alle Anwendungsfälle dokumentiert

Beim Erstellen der Spezifikation können Beschreibungen hilfreich sein, die sich beziehen auf:

• Gegenstände und Eigenschaften (=> Fachklassen)
• Kommunikation zwischen Systemen, Benutzern
• Rollen
• Arbeitsabläufen
• Ereignisse, Auslöser ("Wenn ...")
• Bedingungen ("benötigt", "hat immer")

Alle Ergebnisse dieser Phase müssen dokumentiert sein. Diese Artefakte können bestehen aus

• Freitext
• UML Use-Case Diagrammen
• Fachlexikon und Abkürzungsverzeichnis
• Mind-Maps
• Entwürfe für die GUI (Papier, Visio, Prototyp)
• UML Klassendiagramm für Geschäftsklassen
• Sequenz- und Aktivitätsdiagramme zur Geschäftsprozessmodellierung
• Entwurf des Benutzerhandbuchs

Es sei nochmals daran erinnert, dass die funktionalen Tests, besonders die Abnahmetests hier zu beschreiben sind.

Das Requirementsmanagement ist eine Methodik, die man anwendet um sicherzustellen, dass keine Anforderungen während des Entwicklungsprozesses verändert oder vergessen werden. Diese Technik wird hier beschrieben.

Alle (!) Anforderungen müssen messbar sein. Dies betrifft auch die nichtfunktionalen. Selbst Benutzbarkeit lässt sich quantifizieren:

• Alle Anforderungen einer relevanten Norm sind erfüllt
• Ein Nutzer mit Kenntnissen XY benötigt Z Stunden, um die Aufgabe mit/ohne Benutzerhandbuch zu erledigen.

Im Fall von Zuverlässigkeitsmetriken wird oft die MTBF (mean time between failure) als Mass herangezogen. Um solche oft sehr große Zahlen (z.B. 50000h) zu messen, bedarf es oft Modelle oder der FMEA, um die erwartete Zuverlässigkeit antizipieren zu können.

TODO: Goal Question Metric (DQM) des Fraunhofer Instituts Kaiserslautern recherchieren und beschreiben.