Anforderungsmanagement nach IREB: Anforderungen richtig verstehen, strukturieren und beschreiben

Warum gute Anforderungen der Anfang guter Produkte sind

(IREB: International Board of Requirements Engineering)

Viele Probleme in Software- und Systemprojekten beginnen nicht mit schlechtem Code, einer falschen Architektur oder unzureichenden Tests.

Sie beginnen häufig viel früher – bei einer Anforderung, die nie richtig verstanden, nicht eindeutig formuliert oder schlicht nicht überprüfbar ist.

„Das System soll schnell sein.“

„Die Anwendung muss sicher sein.“

„Der Benutzer soll die Daten einfach ändern können.“

„Das System muss intuitiv bedienbar sein.“

Solche Aussagen klingen zunächst plausibel. Für Entwicklung und Qualitätssicherung sind sie jedoch nur bedingt hilfreich. Was bedeutet „schnell“? Welche Sicherheitsanforderungen sind gemeint? Was ist „einfach“? Und woran erkennen wir später objektiv, dass die Anforderung erfüllt ist?

Genau hier setzt Requirements Engineering (RE) an.

Das International Requirements Engineering Board – IREB – beschreibt Requirements Engineering als einen systematischen und disziplinierten Ansatz zur Spezifikation und Verwaltung von Anforderungen. Ziel ist es, die Bedürfnisse und Wünsche der Stakeholder zu verstehen und das Risiko zu reduzieren, ein System zu entwickeln, das diese Bedürfnisse nicht erfüllt.

Requirements Engineering ist damit weit mehr als das Schreiben eines Lasten- oder Pflichtenhefts.

Es geht um die Frage:

Was soll ein System leisten, warum soll es das leisten und wie können wir später nachweisen, dass es dies tatsächlich leistet?

1. Requirements Engineering und Anforderungsmanagement – nicht ganz dasselbe

Im Alltag werden die Begriffe Requirements Engineering, Requirements Management und Anforderungsmanagement häufig synonym verwendet. Nach IREB lohnt sich jedoch eine Unterscheidung.

Requirements Engineering

Requirements Engineering umfasst insbesondere:

• Anforderungen ermitteln
• Anforderungen analysieren
• Anforderungen dokumentieren
• Anforderungen abstimmen
• Anforderungen validieren
• Anforderungen verwalten

Der Requirements Engineer arbeitet dabei mit Stakeholdern, Entwicklern, Fachbereichen, Testern und weiteren Beteiligten zusammen.

Requirements Management

Requirements Management beschäftigt sich stärker mit den bereits vorhandenen Anforderungen und den dazugehörigen Arbeitsergebnissen.

Dazu gehören beispielsweise:

• Speicherung und Strukturierung
• Versionierung
• Änderungen
• Priorisierung
• Status
• Beziehungen zwischen Anforderungen
• Traceability
• Umgang mit Änderungsanträgen

IREB definiert Requirements Management als den Prozess der Verwaltung bestehender Anforderungen und anforderungsbezogener Arbeitsergebnisse einschließlich Speicherung, Änderung und Nachverfolgbarkeit.

Kurz gesagt:

Requirements Engineering hilft uns, die richtigen Anforderungen zu verstehen und zu formulieren.
Requirements Management sorgt dafür, dass diese Anforderungen über ihren Lebenszyklus kontrolliert und nachvollziehbar bleiben.

2. Was ist eine Anforderung?

Eine der wichtigsten Fragen im Requirements Engineering lautet erstaunlicherweise:

Was ist eigentlich eine Anforderung?

IREB verwendet hierfür eine Definition mit drei Perspektiven:

Eine Anforderung ist

1. ein von einem Stakeholder wahrgenommenes Bedürfnis,
2. eine Fähigkeit oder Eigenschaft, die ein System besitzen soll, oder
3. eine dokumentierte Darstellung eines solchen Bedürfnisses, einer Fähigkeit oder Eigenschaft.

Diese Definition ist wichtig, weil sie zeigt:

Eine Anforderung ist nicht einfach jeder Wunsch, der irgendwo aufgeschrieben wurde.

Zwischen einem ursprünglichen Bedürfnis und einer konkreten Systemanforderung findet ein Übersetzungsprozess statt.

Beispiel

Ein Kunde sagt:

„Unsere Mitarbeiter sollen Bestellungen schneller bearbeiten können.“

Das ist zunächst ein Bedürfnis bzw. Ziel.

Daraus könnte beispielsweise die Anforderung entstehen:

REQ-024: Das System muss die Erfassung einer Standardbestellung innerhalb von maximal 30 Sekunden ermöglichen.

Jetzt haben wir eine deutlich konkretere Aussage.

Noch besser wird die Anforderung, wenn wir festlegen können, wie ihre Erfüllung überprüft wird:

Nachweis: Messung der Bearbeitungszeit anhand eines definierten Testszenarios mit 100 Standardbestellungen.

Damit entsteht eine Kette:

Bedürfnis → Anforderung → messbare Eigenschaft → Test/Nachweis

Genau diese Kette ist für professionelles Requirements Engineering entscheidend.

3. Anforderung versus Spezifikation

Ein besonders wichtiger Unterschied wird in der Praxis häufig übersehen:

Eine einzelne Anforderung ist nicht dasselbe wie eine Spezifikation.

IREB definiert eine Requirements Specification als eine systematisch dargestellte Sammlung von Anforderungen, die bestimmte Kriterien erfüllt.

Eine Spezifikation kann beispielsweise enthalten:

• funktionale Anforderungen
• Qualitätsanforderungen
• Randbedingungen
• Schnittstellenanforderungen
• regulatorische Anforderungen
• Sicherheitsanforderungen
• Datenanforderungen
• Abnahmekriterien
• Modelle
• Beziehungen zwischen Anforderungen

Vereinfacht:

   Begriff

 Bedeutung

    Bedürfnis

 „Wir müssen schneller arbeiten können.“

   Anforderung

 „Das System muss die Bestellung innerhalb von 30 Sekunden erfassen können.“

   Spezifikation

 Systematisch strukturierte Sammlung aller relevanten Anforderungen

   Design

 Beschreibung, wie die Anforderungen technisch umgesetzt werden

   Implementierung

 Realisierung der Lösung

   Test

 Nachweis, ob die Anforderungen erfüllt sind

  Eine Spezifikation beantwortet deshalb nicht nur die Frage:

„Was soll das System können?“

Sie stellt Anforderungen in einen strukturierten Zusammenhang.

4. Die neun grundlegenden IREB-Prinzipien

IREB stellt Requirements Engineering auf neun grundlegende Prinzipien. Diese Prinzipien sind besonders wertvoll, weil sie nicht einfach eine Dokumentationsmethode beschreiben, sondern eine Denkweise für Requirements Engineering.

1. Value Orientation – Orientierung am Nutzen

Anforderungen sind Mittel zum Zweck und kein Selbstzweck.

Es geht nicht darum, möglichst viele Anforderungen zu produzieren oder möglichst umfangreiche Dokumente zu erstellen.

Eine Anforderung ist dann wertvoll, wenn sie beispielsweise:

• einen Stakeholder-Nutzen unterstützt,
• Risiken reduziert,
• Fehlentwicklungen verhindert,
• Klarheit schafft oder
• spätere Nacharbeit reduziert.

Das ist ein wichtiger Grundsatz:

Nicht möglichst viele Anforderungen sind das Ziel, sondern die richtigen Anforderungen.

2. Stakeholders – Stakeholder berücksichtigen

Requirements Engineering beschäftigt sich mit den Bedürfnissen und Erwartungen der Stakeholder.

Dabei gibt es selten nur „den Kunden“.

Stakeholder können beispielsweise sein:

• Auftraggeber
• Benutzer
• Betreiber
• Management
• Entwicklung
• Qualitätssicherung
• Informationssicherheit
• Datenschutz
• Einkauf
• Service
• Behörden
• Auditoren
• Lieferanten

Diese Gruppen können unterschiedliche und sogar widersprüchliche Erwartungen haben.

Ein Benutzer möchte beispielsweise maximale Benutzerfreundlichkeit.

Die Informationssicherheit fordert möglicherweise zusätzliche Authentifizierung.

Der Betrieb möchte einfache Administration.

Der Kunde möchte niedrige Kosten.

Requirements Engineering muss diese unterschiedlichen Perspektiven sichtbar machen und zu einem gemeinsamen Verständnis führen.

3. Shared Understanding – gemeinsames Verständnis

Ein Dokument allein erzeugt noch kein gemeinsames Verständnis.

Das ist einer der wichtigsten Punkte im Requirements Engineering.

Wenn fünf Personen eine Anforderung lesen und fünf unterschiedliche Interpretationen entwickeln, ist die Anforderung nicht gut.

IREB stellt deshalb das gemeinsame Verständnis als grundlegendes Prinzip heraus.

Eine gute Anforderung muss deshalb nicht nur „korrekt geschrieben“, sondern von den relevanten Beteiligten gleich verstanden werden.

4. Context – Kontext

Ein System existiert niemals isoliert.

Eine Anforderung muss deshalb immer im Kontext betrachtet werden.

Beispielsweise:

• Wer verwendet das System?
• Welche Prozesse unterstützt es?
• Mit welchen anderen Systemen kommuniziert es?
• Welche gesetzlichen Anforderungen gelten?
• Welche technischen Randbedingungen bestehen?
• Welche Risiken existieren?
• Welche Umgebung ist relevant?

Die Aussage

„Das System muss verfügbar sein“

ist ohne Kontext kaum sinnvoll.

Erst die Ergänzung

„Das System muss während der Betriebszeit von Montag bis Freitag zwischen 06:00 und 22:00 Uhr eine Verfügbarkeit von mindestens 99,9 % erreichen.“

macht daraus eine wesentlich belastbarere Anforderung.

5. Problem – Requirement – Solution

IREB betrachtet Problem, Anforderung und Lösung als eng miteinander verbundene Konzepte.

Das ist ein sehr wichtiger Gedanke.

Eine Anforderung sollte nicht vorschnell mit einer technischen Lösung verwechselt werden.

Beispiel:

„Das System muss eine Oracle-Datenbank verwenden.“

Das klingt wie eine Anforderung.

Tatsächlich kann es sich aber bereits um eine Lösungsentscheidung handeln.

Die eigentliche Anforderung könnte beispielsweise sein:

„Die Anwendung muss Transaktionsdaten dauerhaft und konsistent speichern.“

Erst danach stellt sich die Frage:

Wie lösen wir dieses Problem technisch?

Diese Trennung schafft Freiraum für Architektur und technische Innovation.

6. Validation – Anforderungen validieren

Eine nicht validierte Anforderung ist nach IREB nicht ausreichend.

Bei der Validierung wird insbesondere geprüft:

Haben wir tatsächlich das Richtige spezifiziert?

Das ist etwas anderes als die spätere technische Prüfung.

Beispiel:

Der Kunde sagt:

„Das System benötigt einen Export nach Excel.“

Die technische Umsetzung kann korrekt funktionieren.

Aber vielleicht bestand das eigentliche Problem darin, dass der Kunde monatlich bestimmte Kennzahlen an die Geschäftsführung liefern muss.

Dann könnte eine automatische Berichtsfunktion das eigentliche Bedürfnis besser erfüllen als ein Excel-Export.

Requirements Engineering muss deshalb nicht nur fragen:

„Haben wir die Anforderung richtig umgesetzt?“

sondern bereits vorher:

„Ist dies überhaupt die richtige Anforderung?“

7. Evolution – Anforderungen verändern sich

Anforderungen sind nicht statisch.

Neue Erkenntnisse, neue Technologien, neue Kundenanforderungen, neue Risiken oder neue gesetzliche Anforderungen können zu Änderungen führen.

IREB betrachtet diese Entwicklung nicht als Ausnahme, sondern als normalen Bestandteil des Requirements Engineering.

Professionelles Requirements Management bedeutet deshalb nicht:

„Wir verhindern Änderungen.“

Sondern:

„Wir machen Änderungen kontrolliert, nachvollziehbar und beherrschbar.“

8. Innovation – nicht nur Bestehendes fortschreiben

Requirements Engineering darf nicht zu einer reinen Verwaltung bestehender Lösungen werden.

Die Frage sollte nicht nur lauten:

„Wie machen wir das bisherige Verfahren digital?“

Sondern auch:

„Welches Problem wollen wir eigentlich lösen – und gibt es dafür eine bessere Lösung?“

Das verhindert, dass bestehende Prozesse einfach unverändert in Software gegossen werden.

9. Systematic and disciplined work – systematisches und diszipliniertes Arbeiten

Requirements Engineering braucht Struktur.

Das bedeutet beispielsweise:

• definierte Verantwortlichkeiten
• nachvollziehbare Anforderungen
• einheitliche Begriffe
• eindeutige Identifikation
• Reviews
• Validierung
• Priorisierung
• Änderungsmanagement
• Traceability

IREB beschreibt Requirements Engineering ausdrücklich als systematischen und disziplinierten Ansatz.

5. Anforderungen richtig kategorisieren

Ein häufiger Fehler besteht darin, verschiedene Klassifizierungen von Anforderungen miteinander zu vermischen.

IREB unterscheidet insbesondere bei den Systemanforderungen zwischen:

1. funktionalen Anforderungen
2. Qualitätsanforderungen
3. Constraints bzw. Randbedingungen.

Qualitätsanforderungen und Constraints werden dabei auch als nichtfunktionale Anforderungen bezeichnet.

Funktionale Anforderungen

Funktionale Anforderungen beschreiben, was ein System tun oder wie es sich verhalten soll.

Beispiele:

• Das System muss Bestellungen erfassen können.
• Das System muss Benutzer authentifizieren.
• Das System muss Rechnungen erzeugen.
• Das System muss Daten an das ERP-System übertragen.
• Das System muss bei einem Fehler eine Fehlermeldung anzeigen.

Eine funktionale Anforderung beschreibt also insbesondere:

Welche Funktion bzw. welches Verhalten wird erwartet?

Qualitätsanforderungen

Qualitätsanforderungen beschreiben Eigenschaften des Systems, die über eine konkrete Funktion hinausgehen.

Typische Beispiele sind:

• Performance
• Verfügbarkeit
• Zuverlässigkeit
• Sicherheit
• Wartbarkeit
• Benutzbarkeit
• Skalierbarkeit
• Übertragbarkeit
• Wiederherstellbarkeit

Beispiel:

Nicht:

„Das System muss schnell sein.“

Sondern:

„Das System muss eine Suchanfrage bei einer Datenmenge von bis zu 10 Millionen Datensätzen innerhalb von maximal 2 Sekunden beantworten.“

Damit wird aus einer allgemeinen Qualitätsvorstellung eine überprüfbare Anforderung.

IREB ordnet beispielsweise Performanceanforderungen den Qualitätsanforderungen zu.

Constraints – Randbedingungen

Constraints schränken den Lösungsraum ein.

Beispiele:

„Die Anwendung muss auf Windows Server 2025 betrieben werden.“

„Die Kommunikation zwischen den Systemkomponenten muss über HTTPS erfolgen.“

„Die Lösung muss die vorgegebene Unternehmensarchitektur berücksichtigen.“

„Für die Verschlüsselung müssen vom Unternehmen freigegebene kryptografische Verfahren verwendet werden.“

Der entscheidende Unterschied:

Eine funktionale Anforderung beschreibt was das System leisten soll.

Eine Qualitätsanforderung beschreibt welche Qualitätseigenschaft erreicht werden soll.

Ein Constraint beschreibt welche Grenzen oder Vorgaben bei der Lösung einzuhalten sind.

6. Eine wichtige zweite Dimension: Anforderungsebene

Neben der Art der Anforderung kann man Anforderungen auch nach ihrer Abstraktionsebene oder Herkunft betrachten.

Beispielsweise:

Geschäftsanforderung

„Das Unternehmen möchte die Bearbeitungszeit von Kundenaufträgen reduzieren.“

Stakeholder-Anforderung

„Der Sachbearbeiter soll einen Auftrag ohne Medienbruch erfassen können.“

Systemanforderung

„Das System muss die Auftragsdaten aus dem Kundenportal automatisch übernehmen.“

Diese Aussagen sind nicht einfach drei verschiedene Formulierungen derselben Kategorie.

Sie stehen in einer Beziehung zueinander.

Aus einem Geschäftsziel können Stakeholder-Bedürfnisse entstehen. Daraus werden konkrete Systemanforderungen abgeleitet.

Damit entsteht beispielsweise:

Geschäftsziel → Stakeholder-Bedürfnis → Systemanforderung → Design → Implementierung → Test

Genau diese Beziehungen sind später für Traceability besonders wertvoll.

7. Was ist eine gute Anforderung?

Eine gute Anforderung ist nicht einfach eine sprachlich schöne Anforderung.

IREB nennt für einzelne Anforderungen unter anderem folgende Qualitätskriterien:

• angemessen / adäquat
• notwendig
• eindeutig
• vollständig
• verständlich
• verifizierbar.

Besonders interessant ist dabei die IREB-Perspektive auf Adäquanz.

Eine Anforderung ist adäquat, wenn sie die tatsächlichen und abgestimmten Bedürfnisse der Stakeholder ausdrückt.

Das ist etwas anderes als lediglich „grammatikalisch korrekt“.

8. Die gefährlichsten Wörter in Anforderungen

Ein guter Praxistest ist die Suche nach Begriffen, die unterschiedliche Interpretationen zulassen.

Problematisch sind beispielsweise:

• schnell
• einfach
• intuitiv
• benutzerfreundlich
• sicher
• möglichst
• angemessen
• ausreichend
• zeitnah
• effizient
• regelmäßig
• komfortabel
• modern
• robust

Beispiel:

„Das System muss eine schnelle Verarbeitung ermöglichen.“

Was bedeutet „schnell“?

500 ms?

2 Sekunden?

10 Sekunden?

Oder eine Minute?

Eine bessere Formulierung wäre:

REQ-017: Das System muss eine Standard-Suchanfrage bei bis zu 10 Millionen Datensätzen innerhalb von maximal 2 Sekunden beantworten.

Jetzt ist die Anforderung:

• eindeutig,
• messbar,
• überprüfbar,
• testbar.

9. Eine gute Struktur für die Beschreibung einer Anforderung

IREB schreibt nicht vor, dass jede Organisation exakt eine bestimmte Vorlage verwenden muss. IREB beschreibt vielmehr verschiedene Möglichkeiten zur Dokumentation von Anforderungen, darunter natürliche Sprache, Vorlagen und Modelle.

Für die Praxis hat sich jedoch eine strukturierte Anforderungsbeschreibung bewährt.

Eine einzelne Anforderung könnte beispielsweise so aufgebaut sein:

   Feld - Inhalt

•     ID -  Eindeutige Kennung
•    Titel -  Kurze verständliche Bezeichnung
•    Kategorie -  Funktional / Qualität / Constraint
•    Anforderung -  Eigentliche Anforderung
•    Quelle -  Stakeholder, Vertrag, Gesetz, Risiko etc.
•    Begründung -  Warum wird die Anforderung benötigt?
•    Kontext -  Relevante Rahmenbedingungen
•    Priorität -  z. B. Muss / Soll / Kann
•    Abhängigkeiten -  Verknüpfte Anforderungen
•    Risiken -  Relevante Risiken
•    Akzeptanzkriterium -  Woran erkennen wir die Erfüllung?
•    Verifikation -  Wie wird die Erfüllung geprüft?
•    Status -  Entwurf / geprüft / freigegeben / geändert
•    Verantwortlicher -  Zuständiger Stakeholder bzw. Owner
•    Version -  Änderungsstand
•    Traceability -  Beziehungen zu Design, Test, Risiko etc.

  Damit wird aus einem einfachen Satz ein kontrolliertes Arbeitsergebnis.

10. Der eigentliche Kern: Die Anforderung selbst

Das wichtigste Feld bleibt natürlich die eigentliche Anforderung.

Eine praxistaugliche Grundstruktur lautet:

Das System muss [Objekt] [Aktion/Verhalten] unter [Bedingung] mit [messbarem Kriterium].

Beispiel:

Das System muss bei einer erfolgreichen Anmeldung das Benutzerkonto innerhalb von maximal 2 Sekunden anzeigen, sofern der Authentifizierungsdienst verfügbar ist.

Noch besser ist es, wenn die Anforderung anschließend unmittelbar mit einem Prüfverfahren verbunden wird.

Anforderung

Das System muss die Benutzeroberfläche nach erfolgreicher Anmeldung innerhalb von maximal 2 Sekunden anzeigen.

Akzeptanzkriterium

Bei 100 aufeinanderfolgenden Anmeldungen darf die Zeit zwischen erfolgreicher Authentifizierung und Anzeige der Startseite in mindestens 95 Fällen 2 Sekunden nicht überschreiten.

Verifikation

Performance-Test unter definierter Systemlast.

Damit entsteht eine sehr wichtige Verbindung:

Anforderung → Akzeptanzkriterium → Test → Ergebnis

11. Anforderungen sollten nicht die technische Lösung vorwegnehmen

Eine der wichtigsten Regeln für gute Anforderungen lautet:

Nicht vorschnell das Wie mit dem Was verwechseln.

Beispiel:

Schlechte Anforderung

„Das System muss eine PostgreSQL-Datenbank verwenden.“

Wenn die Datenbanktechnologie nicht aus einer Randbedingung heraus zwingend vorgeschrieben ist, beschreibt diese Aussage möglicherweise bereits eine Designentscheidung.

Besser

„Das System muss die Geschäftsdaten dauerhaft, konsistent und gegen unbeabsichtigten Verlust geschützt speichern.“

Damit bleibt zunächst offen, wie diese Eigenschaft realisiert wird.

Die Architektur und Entwicklung können anschließend eine geeignete technische Lösung bestimmen.

Das entspricht dem IREB-Prinzip Problem – Requirement – Solution.

12. Anforderungen müssen überprüfbar sein

Eine besonders wichtige Eigenschaft ist die Verifizierbarkeit.

IREB definiert Verifizierbarkeit als den Grad, zu dem die Erfüllung einer Anforderung durch das implementierte System überprüft werden kann. Dies kann beispielsweise durch Testfälle, Messungen oder Inspektionen erfolgen.

Daraus folgt eine einfache Praxisfrage:

Wie würde ich diese Anforderung später prüfen?

Wenn darauf keine klare Antwort möglich ist, sollte die Anforderung überarbeitet werden.

Beispiel

Nicht gut:

Das System muss benutzerfreundlich sein.

Besser:

Neue Benutzer müssen nach einer maximal 30-minütigen Einweisung in der Lage sein, einen Standardauftrag ohne Unterstützung anzulegen.

Noch besser:

Die Benutzerfreundlichkeit wird mit einem definierten Usability-Test anhand von fünf Standardaufgaben überprüft.

Damit wird die Qualitätsanforderung tatsächlich prüfbar.

13. Akzeptanzkriterien sind kein Ersatz für Anforderungen

Akzeptanzkriterien werden häufig mit Anforderungen gleichgesetzt.

Das ist nicht ganz richtig.

Eine Anforderung beschreibt, was benötigt wird.

Ein Akzeptanzkriterium beschreibt, woran die Erfüllung erkannt werden kann.

Beispiel:

Anforderung

Das System muss Benutzerkonten nach fünf fehlgeschlagenen Anmeldeversuchen sperren.

Akzeptanzkriterien

• Nach dem fünften fehlgeschlagenen Versuch wird das Konto gesperrt.
• Ein weiterer Login ist nicht möglich.
• Die Sperrung wird protokolliert.
• Ein berechtigter Administrator kann die Sperrung aufheben.

Die Akzeptanzkriterien machen die Anforderung operationalisierbar.

14. Traceability: Die Anforderung bekommt einen Lebenslauf

Eine gute Anforderung steht nicht allein.

Sie sollte mit anderen Arbeitsergebnissen verbunden werden können.

Beispielsweise:

• Stakeholder-Bedürfnis
• Anforderung REQ-017
• Risiko R-023
• Architekturentscheidung
• Implementierung
• Testfall TC-081
• Testergebnis
• Release 2.4

IREB beschreibt Traceability als die Möglichkeit, explizite Beziehungen zwischen zusammengehörigen Arbeitsergebnissen herzustellen – beispielsweise zurück zur Quelle, vorwärts zur Implementierung und zu den zugehörigen Tests.

Das ist insbesondere bei sicherheitskritischen, regulierten oder auditierbaren Produkten von hoher Bedeutung.

15. Requirements Engineering und Informationssicherheit

Gerade bei Software reicht es heute nicht mehr aus, nur funktionale Anforderungen zu betrachten.

Sicherheitsanforderungen müssen frühzeitig in das Requirements Engineering integriert werden.

Beispiele:

Funktionale Anforderung

Das System muss Benutzern die Änderung ihrer Kontaktdaten ermöglichen.

Sicherheitsanforderung

Das System darf die Änderung der Kontaktdaten nur nach erfolgreicher Authentifizierung ermöglichen.

Weitere Sicherheitsanforderung

Änderungen an Kontaktdaten müssen mit Benutzerkennung, Zeitstempel und geändertem Feldwert protokolliert werden.

Qualitätsanforderung

Die Protokolldaten müssen mindestens 12 Monate manipulationsgeschützt aufbewahrt werden.

Jetzt wird sichtbar:

Eine scheinbar einfache Funktion kann mehrere unterschiedliche Anforderungen erzeugen.

Funktion – Qualität – Sicherheit – Nachweis

gehören zusammen.

16. Requirements Engineering als Verbindung zwischen Qualität, Sicherheit und Compliance

Hier wird Requirements Engineering besonders interessant.

Eine Anforderung kann gleichzeitig mehrere Perspektiven haben.

Beispielsweise:

„Das System muss bei einem Ausfall der primären Datenbank innerhalb von 60 Sekunden auf ein redundantes System umschalten.“

Diese eine Anforderung betrifft möglicherweise:

• Funktionalität
• Verfügbarkeit
• Resilienz
• Informationssicherheit
• Business Continuity
• Architektur
• Testbarkeit
• Abnahme
• Risikomanagement

Deshalb ist Requirements Engineering nicht nur eine Aufgabe der Softwareentwicklung.

Es ist eine verbindende Disziplin zwischen:

• Business
• Produktmanagement
• Entwicklung
• Architektur
• Qualität
• Informationssicherheit
• Risikomanagement
• Test
• Compliance
• Betrieb

17. Ein praktisches Beispiel: „Das System muss sicher sein“

Eine typische Aussage aus Projekten lautet:

„Das System muss sicher sein.“

Aus Sicht des Requirements Engineering ist das noch keine ausreichend konkrete Anforderung.

Die Aussage muss zunächst analysiert werden.

Welche Schutzbedürfnisse bestehen?

Beispielsweise:

• Vertraulichkeit
• Integrität
• Verfügbarkeit
• Authentizität
• Nachvollziehbarkeit

Welche Risiken bestehen?

Beispielsweise:

• unberechtigter Zugriff
• Manipulation
• Datenverlust
• Schadsoftware
• Missbrauch von Schnittstellen

Welche Anforderungen ergeben sich daraus?

Zum Beispiel:

Das System muss Benutzer vor dem Zugriff auf geschützte Funktionen authentifizieren.

oder:

Das System muss sicherstellen, dass Benutzer nur auf Daten zugreifen können, für die sie berechtigt sind.

oder:

Sicherheitsrelevante Änderungen müssen revisionssicher protokolliert werden.

Aus einem abstrakten Ziel entsteht damit eine Menge konkreter, überprüfbarer Anforderungen.

18. Ein häufiger Fehler: Anforderungen und Tests werden zu spät miteinander verbunden

Ein sehr einfacher Qualitätstest für Anforderungen lautet:

Kann ich aus dieser Anforderung einen sinnvollen Testfall ableiten?

Wenn die Antwort „nein“ lautet, ist die Anforderung möglicherweise:

• zu unklar,
• zu allgemein,
• nicht messbar,
• nicht vollständig oder
• noch nicht ausreichend abgestimmt.

IREB stellt die Verifizierbarkeit ausdrücklich als Qualitätskriterium heraus.

Das führt zu einer wichtigen Denkweise:

Der Test beginnt gedanklich bereits bei der Anforderung.

Nicht erst beim Testfall.

19. Die fünf wichtigsten Fragen für jede Anforderung

In der Praxis lässt sich die Qualität einer Anforderung mit wenigen Fragen überprüfen:

1. Warum?

Welches Problem oder Bedürfnis steckt dahinter?

2. Was?

Welche Fähigkeit oder Eigenschaft soll das System besitzen?

3. Für wen?

Welcher Stakeholder benötigt diese Eigenschaft?

4. Woran erkennen wir die Erfüllung?

Wie kann die Anforderung objektiv überprüft werden?

5. Was hängt davon ab?

Welche Risiken, Anforderungen, Designs, Tests oder regulatorischen Vorgaben stehen damit in Verbindung?

Wenn diese fünf Fragen beantwortet werden können, ist bereits ein großer Teil des Requirements Engineering erledigt.

20. Die praktische Struktur einer guten Anforderung

Für viele Unternehmen reicht eine relativ einfache Vorlage.

Anforderungen-ID

REQ-SEC-017

Titel

Schutz vor unberechtigtem Zugriff

Kategorie

Security Requirement / Qualitätsanforderung

Anforderung

Das System muss den Zugriff auf administrative Funktionen ausschließlich für authentifizierte und entsprechend berechtigte Benutzer ermöglichen.

Begründung

Schutz vor unberechtigter Änderung sicherheitsrelevanter Systemeinstellungen.

Quelle

Informationssicherheitsrisiko R-023; Security Architecture.

Priorität

Muss

Akzeptanzkriterium

Ein nicht authentifizierter Benutzer darf keine administrative Funktion aufrufen können. Ein authentifizierter Benutzer ohne entsprechende Berechtigung darf ebenfalls keinen Zugriff erhalten.

Verifikation

Security Test / Penetration Test / funktionaler Test.

Traceability

R-023 → REQ-SEC-017 → Design SEC-ARCH-004 → TC-081

Damit ist die Anforderung nicht nur ein Satz in einem Dokument.

Sie ist ein identifizierbares, prüfbares und nachverfolgbares Arbeitsergebnis.

21. Anforderungen sind keine Bürokratie

Eine häufige Kritik an Requirements Engineering lautet:

„Das erzeugt doch nur zusätzliche Dokumentation.“

Das kann tatsächlich passieren – wenn Requirements Engineering falsch verstanden wird.

IREB stellt deshalb die Value Orientation an die erste Stelle.

Nicht jede Information muss in ein 20-seitiges Dokument.

Nicht jede Anforderung benötigt dieselbe Detailtiefe.

Nicht jedes Projekt benötigt dieselben Methoden.

Entscheidend ist der Nutzen.

Bei einem kleinen internen Tool kann ein strukturierter Backlog mit guten Anforderungen vollkommen ausreichend sein.

Bei einem sicherheitskritischen oder regulierten Produkt können dagegen detaillierte Anforderungen, Traceability, Reviews, Testnachweise und formale Freigaben notwendig sein.

Die richtige Frage lautet daher nicht:

„Wie viel Dokumentation brauchen wir?“

Sondern:

„Welche Klarheit und Nachweisbarkeit brauchen wir für das Risiko, die Komplexität und den Zweck unseres Systems?“

22. Anforderungen als Bindeglied zum Qualitätsmanagement

Gerade aus Sicht des Qualitätsmanagements ist Requirements Engineering besonders interessant.

Denn Qualität entsteht nicht erst beim Test des fertigen Produkts.

Sie beginnt bereits bei der Definition dessen, was überhaupt geliefert werden soll.

Eine schlechte Anforderung kann zu:

• Fehlentwicklungen
• Missverständnissen
• zusätzlichen Änderungsrunden
• Fehltests
• Abweichungen
• Reklamationen
• Sicherheitslücken
• Verzögerungen

führen.

Eine gute Anforderung schafft dagegen eine gemeinsame Grundlage für:

Entwicklung → Test → Abnahme → Freigabe → Betrieb → Änderung

Damit wird Requirements Engineering zu einem wichtigen Bestandteil präventiver Qualitätssicherung.

23. Die wichtigste Verbindung: Anforderung → Nachweis

Aus meiner Sicht lässt sich gutes Requirements Engineering auf eine zentrale Kette reduzieren:

• Bedürfnis
• Anforderung
• Klarheit
• Abnahmekriterium
• Implementierung
• Test
• Nachweis
• Freigabe

Und bei sicherheitsrelevanten Systemen zusätzlich:

• Risiko
• Security Requirement
• Security Control
• Security Test
• Nachweis

Damit wird aus Requirements Engineering eine echte Verbindung zwischen Business, Entwicklung, Qualität, Sicherheit und Compliance.

24. Fazit

Requirements Engineering nach IREB ist weit mehr als das Schreiben von Anforderungen.

Es geht darum,

• Bedürfnisse zu verstehen,
• Stakeholder zusammenzubringen,
• Probleme von Lösungen zu unterscheiden,
• Anforderungen sinnvoll zu kategorisieren,
• Anforderungen eindeutig zu formulieren,
• Anforderungen zu validieren,
• ihre Erfüllung überprüfbar zu machen,
• Änderungen kontrolliert zu behandeln und
• Beziehungen zwischen Anforderungen, Risiken, Design, Implementierung und Tests nachvollziehbar zu halten.



Die neun IREB-Prinzipien liefern dafür eine wichtige Denkgrundlage:

Nutzenorientierung – Stakeholder – gemeinsames Verständnis – Kontext – Problem/Anforderung/Lösung – Validierung – Evolution – Innovation – systematisches Arbeiten.

Der vielleicht wichtigste Gedanke dabei ist:

Eine Anforderung ist nicht deshalb gut, weil sie schön formuliert ist. Sie ist gut, wenn sie das richtige Bedürfnis beschreibt, von den Beteiligten verstanden wird und eindeutig festgestellt werden kann, ob sie erfüllt wurde.

Oder noch praktischer:

Wenn Entwicklung, Test, Qualitätssicherung und Kunde dieselbe Anforderung unterschiedlich verstehen, haben wir kein Softwareproblem – wir haben ein Requirements-Problem.

Und genau deshalb beginnt gute Qualität häufig nicht beim Test.

Sie beginnt bei der Anforderung.

Quellen und weiterführende Informationen

Die Aussagen zu Definitionen, Prinzipien, Anforderungskategorien und Qualitätskriterien orientieren sich am aktuellen CPRE-Foundation-Level-Konzept und dem IREB-Glossar. IREB stellt den CPRE Foundation Level als Einstieg in professionelles Requirements Engineering dar und behandelt dort unter anderem Prinzipien, Arbeitsergebnisse, Dokumentationspraktiken, Anforderungsermittlung, Validierung und Prozessgestaltung.

Stichworte für Internetsuche

IREB – CPRE Foundation Level

IREB – CPRE Online Glossar

Ihr Konstantin Ziouras