Requirement Engineering ist eine wichtige Disziplin, um die Anforderungen der Stakeholders aufzunehmen. Wenn es um das Aufnehmen von Anforderungen geht, gibt es gewisse Aspekte zu beachten. Dieser Beitrag soll das wichtigste zusammenfassen.

Arten von Anforderungen

Grundsätzlich unterscheidet man drei Arten von Anforderungen:

1. Funktionale Anforderungen
Diese legen die Funktionalität fest, die das zu implementierende System aufweisen soll. Sie werden in Funktions-, Verhaltens- und Strukturanforderungen unterteilt (siehe unten).

Beispiel: Der Kunde muss die Möglichkeit haben, eine über unseren Webshop zu kaufen.

2. Qualitätsanforderungen oder Nicht-funktionale Anforderungen
Diese legen die gewünschte Qualität des Zielsystems fest. Meistens handelt es sich dabei um technische Anforderungen, die eingehalten werden müssen – auch abhängig von den Gegebenheiten des bestehenden Systems. Typischerweise beziehen sie sich auf Themen wie Performanz, Verfügbarkeit, Zuverlässigkeit, Skalierbarkeit oder die Portabilität des Systems. Achten Sie darauf, dass Sie diese Anforderungen messbar definieren.

Beispiel: Klickt der Kunde auf den „Bestellen“ Knopf, muss ihm innerhalb von 0.5 Sekunden eine Bestätigung oder Fehlermeldung angezeigt werden.

3. Randbedingungen oder Rahmenbedingungen
Diese können von den Projektbeteiligten nicht beeinflusst werden. Stattdessen handelt es sich um die Gegebenheiten des Systems, die die Implementierung auf gewisse Art einschränken. Sind zum Beispiel alle Applikationen einer Firma in Java programmiert, macht es gegebenfalls Sinn, eine neue Applikation auch in Java umzusetzen (ausser man verfolgt eine Microservices Architektur). Darum handelt es sich hier nicht um Anforderungen, die vom Team umgesetzt werden müssen.

Eigenschaften von Qualitätsanforderungen

1. Performanz
Wie schnell muss das System laufen?

2. Sicherheit
Welche Sicherheitsanforderungen müssen eingehalten werden? Welches sind die Firmenstandards?

3. Zuverlässigkeit
Wie steht es um die SLA’s des Systems? (Service Level Agreement, vertraglich festgelegte maximale Ausfallzeiten des Systems)

4. Benutzbarkeit
Wie leicht ist das System zu erlernen/bedienen?

5. Änderbarkeit
Anforderungen an die Wartbarkeit

6. Übertragbarkeit
Wie steht es um die Installierbarkeit, Anpassbarkeit, Austauschbarkeit?

Die drei Perspektiven von Anforderungen

1. Strukturperspektive / Strukturanforderungen
Dies sind Anforderungen an die Struktur, konkret an die Ein- und Ausgabedaten des Zielsystems. In dieses Kapitel kommen also alle Anforderungen zum Thema Schnittstellen.

2. Funktionsperspektive / Funktionsanforderungen
Hier werden Anforderungen an die Logik im entsprechenden Modul aufgelistet. Wie werden Daten manipuliert, welche Algorithmen müssen eingesetzt werden etc.

3. Verhaltensperspektive / Verhaltensanforderungen
Hier dreht es sich um Anforderungen, die in Verbindung mit gewissen Ereignissen/Events stehen. Anforderungen an Zustandswechsel sind hier am rechten Platz.

Anforderungskategorisierung nach dem Kano-Modell

Anforderungen werden gemäss dem Kano-Modell in drei Kategorien eingeteilt.

1. Basisfaktoren
Dies sind UNTERbewusste Anforderungen, die der Stakeholder an das System voraussetzt. Diese werden auch „implizierte“ Anforderungen genannt. Wenn diese nicht erfüllt sind, wird der Kunde unzufrieden, auch wenn diese Anforderungen nicht konkret in die Spezifikation aufgenommen wurde.

2. Leistungsfaktoren
Hier handelt es sich um das, woran man beim Wort Anforderung zuerst denkt: Bewusste Anforderung, die der Kunde von seinem Zielsystem erwartet. Diese müssen erfüllt werden, damit das System live gehen kann.

3. Begeisterungsfaktoren
Hierbei handelt es sich um UNbewusste Anforderungen, deren Wert ein Stakeholder erst erkennt, wenn er diese gesehen hat oder selber ausprobieren kann. So wie etliche Personen gesagt haben „Ein iPad? Was für ein Schwachsinn – Für was sollte ich das brauchen?“ und die heute ihr iPad nicht wieder hergeben würden.

Anforderungsquellen

Da ich in diesem Beitrag eh schon so viele Aufzählungen habe, kann eine weitere nicht schaden. Anforderungen kommen aus einer der folgenden drei Quellen:

1. Stakeholder
Ein Stakeholder ist eine Person oder eine Organisation, die direkt oder indirekt Einfluss auf die Anforderungen und das Projekt haben. Beispiele dafür sind der Kunde, die Projektteilnehmer, die Regierung, der Geldgeber etc.

2. Dokumente
Anforderungen können oft aus existierenden Dokumenten zum System kommen. Dies können etwa Gesetzestexte oder Standards der Firma sein. Genauso kann aus einem Fehlerbericht des Systems aus der Vergangenheit eine neue Anforderung resultieren.

3. Systeme im Betrieb
Dies können Systeme sein, die momentan laufen und abgelöst werden sollen, aber auch Konkurrenzsysteme, die zu Anforderungen generieren. So kann man zum Beispiel die Funktionalität des Systems anhand einer Live Demo anschauen, aber auch eine Codeanalyse kann zu neuen Erkenntnissen führen.