Requirements Engineering als Qualitäts- und Sicherheitsfaktor

Warum strukturiertes Anforderungsmanagement für Software und vernetzte Systeme immer wichtiger wird

„Das System funktioniert doch.“

Dieser Satz kann in einem Softwareprojekt gefährlich sein.

Denn ein System kann technisch funktionieren und trotzdem die Anforderungen des Kunden nicht erfüllen. Es kann schnell genug sein, aber nicht sicher. Es kann sicher sein, aber nicht die geforderte Verfügbarkeit erreichen. Es kann alle Funktionen bereitstellen, aber nicht nachweisen können, dass regulatorische Anforderungen erfüllt wurden.

Genau hier beginnt die Bedeutung von Requirements Engineering.

Requirements Engineering – kurz RE – ist weit mehr als das Schreiben von Lasten- und Pflichtenheften oder das Verwalten von User Stories. Es schafft die Verbindung zwischen den Erwartungen der Stakeholder, den technischen Eigenschaften eines Systems, den Qualitätszielen, den Sicherheitsanforderungen und letztlich dem Nachweis, dass das entwickelte Produkt tatsächlich das leistet, was es leisten soll.

Mit zunehmender Vernetzung von Produkten und Software gewinnt dieser Zusammenhang zusätzlich an Bedeutung. Der europäische Cyber Resilience Act (CRA) stellt Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen über deren gesamten Lebenszyklus.

Damit wird eine Frage immer wichtiger:

Wie kann ein Unternehmen nachweisen, dass die relevanten Anforderungen erkannt, umgesetzt, geprüft und über den Lebenszyklus beherrscht werden?

Eine wesentliche Antwort darauf lautet: durch ein professionelles Requirements Engineering.

1. Was bedeutet Requirements Engineering?

Das International Requirements Engineering Board (IREB) beschreibt Requirements Engineering als einen systematischen und disziplinierten Ansatz zur Spezifikation und Verwaltung von Anforderungen.

Dabei geht es nicht nur darum, Anforderungen aufzuschreiben.

Requirements Engineering umfasst insbesondere:

• Anforderungen ermitteln
• Anforderungen analysieren
• Anforderungen dokumentieren
• Anforderungen validieren
• Anforderungen mit Stakeholdern abstimmen
• Anforderungen priorisieren
• Anforderungen ändern und versionieren
• Beziehungen zwischen Anforderungen und anderen Entwicklungsartefakten nachvollziehbar machen

Damit ist Requirements Engineering ein kontinuierlicher Prozess.

Eine Anforderung ist also nicht einfach ein Satz in einem Dokument.

Sie ist ein steuerndes Element des Entwicklungsprozesses.

Von einer Anforderung können beispielsweise Designentscheidungen, Testfälle, Sicherheitsmaßnahmen, Abnahmekriterien und letztlich die Freigabe eines Produktes abhängen.

2. Anforderungen sind mehr als Funktionen

Ein häufiger Fehler besteht darin, Anforderungen hauptsächlich als funktionale Anforderungen zu betrachten.

Beispiel:

„Der Benutzer muss sich am System anmelden können.“

Das beschreibt eine Funktion.

Aber für ein reales Produkt entstehen sofort weitere Fragen:

• Welche Authentisierung ist erforderlich?
• Muss eine Mehrfaktor-Authentisierung verwendet werden?
• Was passiert bei fünf falschen Anmeldeversuchen?
• Wie lange darf eine Sitzung bestehen?
• Wie werden Passwörter gespeichert?
• Welche Ereignisse müssen protokolliert werden?
• Welche Anforderungen gelten für Administratoren?
• Was passiert bei einem kompromittierten Benutzerkonto?

Damit entstehen neben den funktionalen Anforderungen weitere Anforderungen – beispielsweise an:

• Sicherheit
• Performance
• Verfügbarkeit
• Zuverlässigkeit
• Bedienbarkeit
• Datenschutz
• Wartbarkeit
• Wiederherstellbarkeit
• Protokollierung
• Kompatibilität

Gerade diese sogenannten Qualitäts- oder nichtfunktionalen Anforderungen werden in Projekten häufig zu spät betrachtet.

Das ist problematisch.

Denn eine Eigenschaft, die erst nach Abschluss der Entwicklung als „wichtig“ erkannt wird, lässt sich häufig nur mit erheblichem Aufwand nachrüsten.

3. Von der Anforderung zur überprüfbaren Eigenschaft

Eine gute Anforderung muss nicht nur verständlich sein.

Sie muss auch überprüfbar sein.

Eine Aussage wie:

„Das System muss eine gute Performance haben.“

ist keine ausreichend präzise Anforderung.

Was bedeutet „gut“?

Eine bessere Formulierung wäre beispielsweise:

„Das System muss 95 % aller Suchanfragen innerhalb von maximal 500 ms beantworten, gemessen unter einer definierten Last von 1.000 gleichzeitig aktiven Benutzern.“

Jetzt existieren überprüfbare Kriterien.

Die Entwicklung weiß, was erreicht werden soll.

Der Tester weiß, was geprüft werden muss.

Der Kunde weiß, was er erwarten kann.

Und das Qualitätsmanagement verfügt über ein objektives Kriterium.

Genau diese Verbindung zwischen Anforderung und Nachweis ist ein Kern des Requirements Engineering.

4. Requirements Engineering und Qualitätsmanagement

Requirements Engineering und Qualitätsmanagement haben ein gemeinsames Ziel:

Nicht erst am Ende feststellen, dass das falsche Produkt gebaut wurde.

Qualität entsteht nicht erst beim Test.

Sie beginnt mit der Frage:

Was muss das Produkt eigentlich leisten?

Das Qualitätsmanagement kann deshalb einen wichtigen Beitrag bereits bei der Definition und Bewertung von Anforderungen leisten.

Critical to Quality – CTQ

Ein besonders hilfreiches Konzept sind Critical to Quality (CTQ)-Anforderungen.

CTQs beschreiben Eigenschaften, die für die Qualität oder den geschäftlichen Erfolg eines Produktes besonders kritisch sind.

Beispiele:

   CTQ - Anforderung - Nachweis

    Performance -  95 % der Anfragen < 500 ms -  Performance-Test

   Verfügbarkeit -  ≥ 99,9 % im definierten Zeitraum -  Monitoring / Auswertung

   Datenintegrität -  Keine unbemerkte Veränderung gespeicherter Datensätze -  Integritätsprüfung

   Wiederherstellbarkeit -  Wiederherstellung innerhalb von 4 Stunden -  Recovery-Test

   Security -  Kontosperrung nach definierter Anzahl fehlerhafter Anmeldeversuche -  Security-Test

   Auditierbarkeit -  sicherheitsrelevante Ereignisse werden nachvollziehbar protokolliert -  Review / Test

  Der entscheidende Punkt:

CTQs dürfen nicht nur als Qualitätsziele formuliert werden. Sie müssen in konkrete, überprüfbare Anforderungen übersetzt werden.

5. Abnahmekriterien: Wann ist eine Anforderung wirklich erfüllt?

Eine Anforderung ohne Abnahmekriterium lässt häufig Interpretationsspielraum.

Ein Satz wie:

„Das System muss sicher sein.“

ist praktisch nicht abnahmefähig.

Eine konkrete Anforderung könnte dagegen lauten:

„Nach fünf aufeinanderfolgenden fehlgeschlagenen Authentisierungsversuchen wird das Benutzerkonto für mindestens 15 Minuten gesperrt.“

Dazu lässt sich ein eindeutiges Abnahmekriterium formulieren:

Bei fünf unmittelbar aufeinanderfolgenden fehlerhaften Anmeldeversuchen wird das Konto gesperrt und kann während der Sperrzeit nicht erfolgreich authentisiert werden.

Damit wird aus einer abstrakten Erwartung eine prüfbare Eigenschaft.

Das ist genau die Verbindung zwischen:

Requirement → Acceptance Criteria → Test Case → Test Result

ISTQB beschreibt Akzeptanzkriterien als messbare Kriterien, anhand derer überprüft wird, ob eine Anforderung beziehungsweise User Story wie erwartet umgesetzt wurde.

Damit wird deutlich:

Testen beginnt nicht erst nach der Programmierung. Testen beginnt bei der Qualität der Anforderungen.

6. Traceability – die Verbindung zwischen Anforderung und Nachweis

Eine der wichtigsten Eigenschaften eines professionellen Requirements Engineering ist die Traceability, also die Nachverfolgbarkeit.

Eine Anforderung sollte beispielsweise mit folgenden Informationen verbunden werden können:

Stakeholder / Bedarf

↓

Requirement

↓

Risiko

↓

Architektur / Design

↓

Implementierung

↓

Testfall

↓

Testergebnis

↓

Freigabe / Nachweis

Damit kann beispielsweise auf die Frage:

„Warum existiert diese Sicherheitsfunktion?“

eine belastbare Antwort gegeben werden.

Man kann auf das zugrunde liegende Risiko, die Sicherheitsanforderung, die technische Umsetzung und den Testnachweis zurückverweisen.

Das ist nicht nur für Audits interessant.

Es hilft auch Entwicklern, Testern, Product Ownern, Qualitätsmanagern und Security-Verantwortlichen im täglichen Projektgeschäft.

7. Was passiert ohne strukturiertes Requirements Engineering?

Die Folgen eines schwachen Anforderungsmanagements sind in vielen Projekten ähnlich.

Typische Symptome sind:

• unterschiedliche Vorstellungen zwischen Kunde und Entwicklung
• widersprüchliche Anforderungen
• nicht dokumentierte Annahmen
• fehlende Qualitätsanforderungen
• vergessene Sicherheitsanforderungen
• fehlende Abnahmekriterien
• Tests, die nicht zu den Anforderungen passen
• Änderungen ohne kontrollierte Auswirkungsanalyse
• hoher Aufwand für Nacharbeiten
• Diskussionen über die Frage, wann ein Produkt „fertig“ ist

Besonders problematisch ist der letzte Punkt.

Wenn nicht definiert wurde, was „fertig“ bedeutet, wird die Diskussion darüber häufig erst am Ende eines Projektes geführt.

Dann ist es allerdings sehr teuer.

8. Informationssicherheit beginnt beim Requirement

Ein Penetrationstest kann Schwachstellen finden.

Er kann aber nicht feststellen, ob das Produkt überhaupt die richtigen Sicherheitsanforderungen besitzt.

Deshalb beginnt Informationssicherheit wesentlich früher.

Beispielsweise kann bereits während der Anforderungsanalyse festgelegt werden:

• welche Daten geschützt werden müssen
• welche Benutzergruppen existieren
• welche Zugriffsrechte erforderlich sind
• welche Authentisierung verwendet werden muss
• welche Ereignisse protokolliert werden
• welche kryptografischen Verfahren erforderlich sind
• welche Schnittstellen abgesichert werden müssen
• wie Updates durchgeführt werden
• wie Schwachstellen behandelt werden
• welche Wiederherstellungszeiten erforderlich sind

Damit werden aus allgemeinen Sicherheitszielen konkrete Security Requirements.

9. Security Requirements Engineering

Security Requirements sollten nicht einfach aus einer Checkliste kopiert werden.

Sie sollten aus dem tatsächlichen System, seinem Einsatzzweck und den relevanten Risiken abgeleitet werden.

Ein sinnvoller Zusammenhang ist beispielsweise:

Asset

→ Was ist schützenswert?

Threat

→ Was kann passieren?

Risk

→ Welche Konsequenz hat das?

Security Requirement

→ Welche Eigenschaft muss das System deshalb besitzen?

Security Control

→ Wie wird diese Eigenschaft technisch oder organisatorisch umgesetzt?

Security Test

→ Wie wird nachgewiesen, dass sie funktioniert?

Beispiel:

Asset: Kundendaten

Bedrohung: Unberechtigter Zugriff

Risiko: Offenlegung vertraulicher Informationen

Security Requirement: Zugriff auf Kundendaten darf nur nach erfolgreicher Authentisierung und entsprechender Autorisierung möglich sein.

Abnahmekriterium: Ein Benutzer ohne entsprechende Berechtigung erhält weder über die Benutzeroberfläche noch über die API Zugriff auf fremde Kundendaten.

Test: Positiver und negativer Autorisierungstest.

Damit entsteht eine nachvollziehbare Kette von Risiko bis Test.

10. Requirements Engineering und der Cyber Resilience Act

Der Cyber Resilience Act verändert die Rahmenbedingungen für Hersteller von Produkten mit digitalen Elementen.

Der CRA fordert unter anderem, dass Cybersicherheitsrisiken berücksichtigt werden und Produkte entsprechend ihrer Risiken entwickelt und produziert werden.

Zu den Anforderungen gehören unter anderem Aspekte wie:

• angemessenes Cybersicherheitsniveau auf Basis der Risiken
• sichere Standardkonfiguration
• Begrenzung von Angriffsflächen
• Schutz von Vertraulichkeit und Integrität
• Schutz wesentlicher Funktionen
• Sicherheitsinformationen und Logging
• sichere Update-Mechanismen
• Schwachstellenmanagement
• regelmäßige Sicherheitsprüfungen
• Dokumentation von Komponenten und Schwachstellen
• Software Bill of Materials (SBOM)
• technische Dokumentation

Entscheidend ist dabei nicht nur die einzelne Sicherheitsmaßnahme.

Entscheidend ist die Nachweisbarkeit über den gesamten Entwicklungs- und Produktlebenszyklus.

Genau hier entsteht eine starke Verbindung zum Requirements Engineering.

11. CRA-Anforderungen müssen in Entwicklungsanforderungen übersetzt werden

Regulatorische Anforderungen sind zunächst häufig abstrakt.

Beispielsweise lautet das Ziel:

Das Produkt soll angemessen gegen Cyberangriffe geschützt sein.

Die Entwicklung benötigt jedoch konkrete Anforderungen.

Daraus können beispielsweise Anforderungen entstehen wie:

• Das Produkt muss eine sichere Standardkonfiguration besitzen.
• Nicht benötigte Netzwerkdienste müssen deaktiviert sein.
• Administrative Funktionen müssen authentisiert und autorisiert werden.
• Sicherheitsereignisse müssen nachvollziehbar protokolliert werden.
• Sicherheitsupdates müssen sicher eingespielt werden können.
• Schwachstellen müssen identifiziert, bewertet und behandelt werden.
• Komponenten und Abhängigkeiten müssen nachvollziehbar sein.

Damit wird aus einer regulatorischen Vorgabe eine Menge konkreter Engineering Requirements.

Und genau diese müssen wiederum:

implementiert → getestet → dokumentiert → nachgewiesen

werden.

Der CRA schreibt dabei nicht vor, dass hierfür ein bestimmtes IREB-Requirements-Engineering-Verfahren verwendet werden muss. Er schafft aber einen regulatorischen Rahmen, in dem ein strukturiertes Anforderungs-, Entwicklungs- und Nachweismanagement praktisch sehr relevant wird.

12. Der besondere Vorteil: Eine Anforderung kann mehrere Ziele gleichzeitig erfüllen

Eine sauber formulierte Anforderung kann gleichzeitig für verschiedene Management- und Engineering-Bereiche relevant sein.

Beispiel:

„Das System muss sicherheitsrelevante administrative Aktionen revisionsfähig protokollieren und die Protokolle gegen unbefugte Veränderung schützen.“

Diese eine Anforderung kann Berührungspunkte haben mit:

• funktionalen Anforderungen
• Qualitätsanforderungen
• Informationssicherheit
• Datenschutz
• Risikomanagement
• Testmanagement
• Auditierung
• regulatorischen Anforderungen

Das zeigt:

Requirements Engineering ist eine Integrationsdisziplin.

Es verbindet die unterschiedlichen Perspektiven auf ein Produkt.

13. Der wirtschaftliche Nutzen

Strukturiertes Requirements Engineering wird manchmal als zusätzlicher Dokumentationsaufwand betrachtet.

Das greift zu kurz.

Der eigentliche Nutzen entsteht dadurch, dass Fehler möglichst früh erkannt werden.

Eine unklare Anforderung verursacht zunächst vielleicht nur eine Diskussion.

Später kann daraus ein falsches Design entstehen.

Noch später eine falsche Implementierung.

Danach entstehen Testfehler.

Und am Ende möglicherweise eine Änderung kurz vor der Freigabe.

Je später ein grundlegendes Missverständnis entdeckt wird, desto größer sind typischerweise die Auswirkungen.

Requirements Engineering verschiebt deshalb einen Teil der Problemlösung nach vorne – dorthin, wo Änderungen noch vergleichsweise einfach möglich sind.

14. Was bedeutet das für Unternehmen?

Ein wirksames Requirements Engineering benötigt nicht zwangsläufig ein großes Bürokratiemonster.

Es benötigt vor allem klare Spielregeln.

Zum Beispiel:

1. Einheitliche Qualitätskriterien für Anforderungen

Jede wichtige Anforderung sollte beispielsweise auf folgende Fragen geprüft werden:

• Ist sie eindeutig?
• Ist sie verständlich?
• Ist sie vollständig?
• Ist sie widerspruchsfrei?
• Ist sie eindeutig identifiziert?
• Ist sie testbar?
• Ist sie priorisiert?
• Ist ihre Quelle bekannt?

2. Abnahmekriterien bereits bei der Anforderung

Nicht:

Requirement heute – Test irgendwann später.

Sondern:

Requirement und Nachweisbarkeit gemeinsam denken.

3. Security früh integrieren

Security Requirements gehören in die Anforderungsphase und nicht ausschließlich in den Penetrationstest vor der Auslieferung.

4. Traceability etablieren

Nicht jede Information muss mit jeder anderen Information verknüpft werden.

Aber für kritische Anforderungen sollte nachvollziehbar sein:

Woher kommt die Anforderung – warum existiert sie – wie wurde sie umgesetzt – wie wurde sie geprüft?

5. Änderungen kontrollieren

Eine neue Anforderung kann Auswirkungen auf Architektur, Security, Tests, Dokumentation und Zulassung haben.

Deshalb braucht Requirements Management auch ein funktionierendes Change Management.

15. Die entscheidende Verbindung

Am Ende lässt sich Requirements Engineering auf eine einfache Frage reduzieren:

Was muss das Produkt können – und wie können wir beweisen, dass es das tatsächlich kann?

Für moderne Software und softwarebasierte Systeme reicht diese Frage jedoch noch nicht ganz aus.

Hinzu kommen:

Warum muss das Produkt diese Eigenschaft besitzen?

Welches Risiko wird damit behandelt?

Welche Qualitätsanforderung steckt dahinter?

Welche Sicherheitsanforderung ergibt sich daraus?

Wie wird die Anforderung getestet?

Welcher Nachweis bleibt nach der Entwicklung bestehen?

Damit entsteht eine belastbare Engineering-Kette:

Need → Requirement → Risk → Design → Implementation → Test → Evidence

Und genau diese Kette verbindet Requirements Engineering mit Qualitätsmanagement, Informationssicherheit und regulatorischen Anforderungen.

Fazit

Requirements Engineering ist keine reine Dokumentationsdisziplin.

Es ist eine Methode, um Komplexität beherrschbar zu machen.

Ein strukturiertes Anforderungsmanagement schafft Klarheit darüber,

• was ein Produkt leisten muss,
• welche Qualitätsmerkmale kritisch sind,
• welche Risiken berücksichtigt werden müssen,
• welche Sicherheitsfunktionen erforderlich sind,
• wie Anforderungen getestet werden,
• wann ein Produkt tatsächlich abnahmefähig ist
• und wie die Erfüllung der Anforderungen nachgewiesen werden kann.

Gerade bei Software und vernetzten Produkten wird diese Fähigkeit immer wichtiger.

Der Cyber Resilience Act verstärkt diese Entwicklung: Cybersicherheit muss bereits in Entwicklung und Produktlebenszyklus berücksichtigt und durch geeignete Nachweise belegbar gemacht werden.

Dabei geht es nicht darum, noch mehr Dokumente zu produzieren.

Es geht darum, die richtigen Fragen frühzeitig zu stellen.

Denn ein Grundsatz gilt für Software genauso wie für klassische Produkte:

Was nicht eindeutig gefordert wurde, kann schwerlich eindeutig entwickelt werden.

Und was nicht eindeutig definiert wurde, lässt sich später nur schwer objektiv prüfen.

Requirements Engineering schafft deshalb die Verbindung zwischen Anforderung, Qualität, Sicherheit und Nachweis.

Nicht mehr Dokumentation ist das Ziel.

Mehr Klarheit ist das Ziel.

P.S. und die Geschichte wird komplizierter, spannender und ganzheitlicher😊

Requirements Engineering als Bindeglied zwischen Qualitätsmanagement und Informationssicherheit

Requirements Engineering steht nicht isoliert neben dem Qualitätsmanagement und dem Informationssicherheitsmanagement.

Im Gegenteil:

Ein strukturiertes Requirements Engineering verbindet zentrale Anforderungen der ISO 9001 mit den Anforderungen der ISO/IEC 27001 und schafft damit eine gemeinsame Grundlage für Entwicklung, Qualitätssicherung und Informationssicherheit.

Für Unternehmen, die Software oder softwarebasierte Produkte entwickeln, entsteht dadurch ein besonders interessanter Zusammenhang:

ISO 9001 beschreibt, wie Anforderungen an Produkte und Dienstleistungen systematisch bestimmt, entwickelt, umgesetzt und überprüft werden.

ISO/IEC 27001 ergänzt diese Perspektive um die systematische Behandlung von Informationssicherheitsrisiken und Sicherheitsanforderungen.

Requirements Engineering kann diese beiden Perspektiven in einem gemeinsamen Entwicklungsprozess zusammenführen.

1. ISO 9001:2015 – Requirements Engineering aus Sicht des Qualitätsmanagements

Die ISO 9001:2015 fordert nicht ausdrücklich einen Prozess mit der Bezeichnung „Requirements Engineering“.

Sie enthält jedoch eine Reihe von Anforderungen, die sich unmittelbar mit den Inhalten eines professionellen Requirements Engineering überschneiden.

Besonders relevant sind die Kapitel:

• 8.1 – Betriebliche Planung und Steuerung
• 8.2 – Anforderungen an Produkte und Dienstleistungen
• 8.3 – Entwicklung von Produkten und Dienstleistungen
• 8.4 – Steuerung von extern bereitgestellten Prozessen, Produkten und Dienstleistungen
• 8.5 – Produktion und Dienstleistungserbringung
• 8.5.6 – Steuerung von Änderungen
• 8.6 – Freigabe von Produkten und Dienstleistungen
• 8.7 – Steuerung nichtkonformer Ergebnisse
• 9.1 – Überwachung, Messung, Analyse und Bewertung
• 10.2 – Nichtkonformität und Korrekturmaßnahmen

Besonders deutlich wird die Verbindung bei 8.2 und 8.3.

Die ISO-9001-Auditing-Practices-Guidance beschreibt Design und Entwicklung ausdrücklich als einen Prozess, in dem Anforderungen in spezifizierte Produkt- beziehungsweise Serviceeigenschaften überführt werden.

Das ist im Kern genau die Aufgabe des Requirements Engineering.

2. ISO 9001 Kapitel 8.2 – Anforderungen an Produkte und Dienstleistungen

Kapitel 8.2 ist für Requirements Engineering besonders interessant.

Hier geht es darum, Anforderungen an Produkte und Dienstleistungen zu bestimmen und zu überprüfen.

Aus Sicht des Requirements Engineering bedeutet dies beispielsweise:

Kundenanforderung

→ Was erwartet der Kunde?

Gesetzliche/regulatorische Anforderungen

→ Was muss aufgrund externer Vorgaben erfüllt werden?

Weitere Anforderungen der Organisation

→ Welche zusätzlichen Anforderungen ergeben sich aus Strategie, Qualität, Security oder internen Standards?

Review

→ Sind die Anforderungen eindeutig und erfüllbar?

Kommunikation

→ Sind die relevanten Anforderungen an Entwicklung, Test und andere Beteiligte kommuniziert?

Damit entsteht eine direkte Verbindung zwischen ISO 9001 und Requirements Engineering.

Ein professionelles Requirements-Engineering-Verfahren kann deshalb als praktische Umsetzung dieser Anforderungen dienen.

3. ISO 9001 Kapitel 8.3 – Entwicklung und Requirements Engineering

Noch enger wird die Verbindung bei 8.3 – Design und Entwicklung von Produkten und Dienstleistungen.

Für ein Softwareunternehmen ist dieser Abschnitt besonders relevant.

Requirements Engineering liefert dabei die Grundlage für die Entwicklung.

Vereinfacht:

8.2 – Was wird benötigt?

↓

Requirements Engineering – Was bedeutet diese Anforderung konkret?

↓

8.3.3 – Design- und Entwicklungsinputs

↓

Architektur / Design

↓

Implementierung

↓

Verifikation und Validierung

↓

8.3.5 – Design- und Entwicklungsergebnisse

↓

8.3.6 – Änderungen

Die Auditing-Practices-Guidance der ISO/IAF beschreibt genau diese Funktion von Design und Entwicklung: Anforderungen werden in spezifizierte Produkt- bzw. Serviceeigenschaften überführt.

Für Softwareentwicklung bedeutet das beispielsweise:

   Requirements Engineering - ISO 9001:2015

    Kundenanforderungen -  8.2

   System Requirements - 8.3.3

   Qualitätsanforderungen -  8.3.3

   Security Requirements -  8.3.3

   Architekturentscheidungen -  8.3.4

   Design Reviews -  8.3.4

   Verifikation -  8.3.4 / 8.3.5

   Validierung -  8.3.4 / 8.3.5

   Designänderungen -  8.3.6

   Abnahmekriterien -  8.6

   Nicht erfüllte Anforderungen -  8.7 / 10.2

  Damit wird deutlich:

Requirements Engineering ist praktisch ein wesentlicher Bestandteil eines beherrschten Entwicklungsprozesses nach ISO 9001.

4. CTQ-Anforderungen und ISO 9001

Das im Artikel beschriebene Konzept der Critical to Quality (CTQ)-Anforderungen lässt sich ebenfalls sehr gut mit ISO 9001 verbinden.

Beispiel:

Das System muss bei 1.000 gleichzeitig aktiven Benutzern 95 % der Anfragen innerhalb von 500 ms beantworten.

Aus RE-Sicht ist dies eine nichtfunktionale Anforderung.

Aus QM-Sicht ist sie ein objektiv überprüfbares Qualitätsmerkmal.

Daraus können entstehen:

Requirement → Performance-Anforderung

CTQ → Antwortzeit

Acceptance Criterion → 95 % < 500 ms

Test Case → definierter Lasttest

Test Result → Messergebnis

Release Decision → Anforderung erfüllt / nicht erfüllt

Damit wird aus einem Qualitätsziel ein objektiver Nachweis.

Genau diese Verbindung zwischen Anforderungen, Akzeptanzkriterien, Prüfung und Freigabe ist für ein wirksames Qualitätsmanagement wesentlich. Die ISO-9001-Leitlinien zur dokumentierten Information nennen beispielsweise Nachweise zur Freigabe einschließlich Akzeptanzkriterien und Rückverfolgbarkeit.

5. ISO 9001 Kapitel 8.6 – Abnahme und Freigabe

Hier wird ein weiterer wichtiger Punkt aus dem ursprünglichen Artikel besonders deutlich:

Eine Anforderung sollte bereits bei ihrer Definition so formuliert werden, dass später festgestellt werden kann, ob sie erfüllt wurde.

Requirements Engineering und Qualitätsmanagement treffen sich damit bei der Frage:

Wann darf ein Produkt freigegeben werden?

Beispiel:

Nicht:

„Das System muss sicher funktionieren.“

Sondern:

„Nach fünf aufeinanderfolgenden fehlgeschlagenen Authentisierungsversuchen wird das Benutzerkonto für mindestens 15 Minuten gesperrt.“

Daraus lassen sich direkt:

• Abnahmekriterien
• Testfälle
• Testergebnisse
• Freigabekriterien

ableiten.

Das ist eine sehr starke Verbindung zwischen RE und ISO 9001.

6. ISO 9001 Kapitel 8.5.6 – Änderungen

Software lebt von Änderungen.

Neue Funktionen, Fehlerkorrekturen, Sicherheitsupdates, Änderungen von Schnittstellen oder Änderungen von Abhängigkeiten können Auswirkungen auf bereits bestehende Anforderungen haben.

Deshalb gehört Change Management unmittelbar zum Requirements Management.

Eine Änderung sollte beispielsweise die Frage beantworten:

Welche bestehenden Anforderungen, Risiken, Tests und Nachweise sind von dieser Änderung betroffen?

Damit entsteht eine Verbindung:

Change Request

→ betroffene Requirements

→ betroffene Risiken

→ betroffene Architektur

→ betroffene Softwarekomponenten

→ betroffene Tests

→ erneute Verifikation

→ Freigabe

Die ISO/IAF-Guidance nennt bei Änderungen unter anderem die Dokumentation der Änderung, deren Überprüfung und die dafür autorisierten Personen.

7. ISO/IEC 27001:2022 – die Security-Perspektive

Während ISO 9001 den Schwerpunkt auf die Fähigkeit legt, Produkte und Dienstleistungen entsprechend den Anforderungen bereitzustellen, betrachtet ISO/IEC 27001 das Thema aus der Perspektive des Informationssicherheitsrisikomanagements.

ISO/IEC 27001:2022 definiert Anforderungen an ein Information Security Management System (ISMS).

Für Requirements Engineering sind insbesondere die Kapitel 6 und 8 sowie verschiedene Controls aus Annex A relevant.

Besonders wichtig sind:

• 6.1.1 – Maßnahmen zur Behandlung von Risiken und Chancen
• 6.1.2 – Informationssicherheits-Risikobeurteilung
• 6.1.3 – Behandlung von Informationssicherheitsrisiken
• 6.2 – Informationssicherheitsziele
• 6.3 – Planung von Änderungen
• 8.1 – Betriebliche Planung und Steuerung
• 8.2 – Informationssicherheits-Risikobeurteilung
• 8.3 – Behandlung von Informationssicherheitsrisiken

Damit entsteht eine zweite Kette:

Asset

→ Threat

→ Risk

→ Security Requirement

→ Security Control

→ Security Test

→ Evidence

Das ist die Security-Variante der bereits beschriebenen Requirements-Kette.

8. ISO/IEC 27001:2022 Annex A – direkte Verbindung zur Softwareentwicklung

Besonders interessant für Softwarehersteller sind die Controls A.8.25 bis A.8.34.

Hier findet sich ein regelrechter „Security Requirements Engineering Block“.

A.8.25 – Secure Development Life Cycle

Ein sicherer Entwicklungslebenszyklus muss etabliert und angewendet werden.

Das betrifft beispielsweise:

• Security bereits in der Planung
• Security Requirements
• sichere Architektur
• sichere Implementierung
• Security Testing
• Security im gesamten Entwicklungsprozess

A.8.26 – Application Security Requirements

Hier wird die Verbindung zum Requirements Engineering besonders unmittelbar.

Bei der Entwicklung oder Beschaffung von Anwendungen müssen Informationssicherheitsanforderungen identifiziert, spezifiziert und genehmigt werden.

Das ist praktisch eine direkte Security-Requirements-Engineering-Anforderung.

A.8.27 – Secure System Architecture and Engineering Principles

Security Requirements müssen sich anschließend in Architektur und Engineering wiederfinden.

Eine Anforderung wie:

„Mandantendaten müssen voneinander getrennt sein.“

ist beispielsweise nicht nur eine funktionale Anforderung.

Sie kann eine konkrete Auswirkung auf die Systemarchitektur haben.

A.8.28 – Secure Coding

Aus den Anforderungen und Architekturprinzipien entstehen konkrete Regeln für die Implementierung.

A.8.29 – Security Testing in Development and Acceptance

Hier schließt sich die Kette wieder:

Security Requirement

→ Implementierung

→ Security Test

→ Acceptance

A.8.30 – Outsourced Development

Auch bei ausgelagerter Entwicklung dürfen Anforderungen nicht einfach „an den Dienstleister abgegeben“ werden.

Die Organisation muss die Entwicklung steuern, überwachen und überprüfen.

A.8.32 – Change Management

Änderungen an Software und Systemen müssen kontrolliert werden.

Damit besteht erneut eine direkte Verbindung zu Requirements Management.

Die Controls A.8.25–A.8.34 bilden damit einen besonders relevanten Teil der ISO/IEC 27001:2022 für einen sicheren Softwareentwicklungsprozess.

9. Eine gemeinsame Sicht auf ISO 9001 und ISO/IEC 27001

Besonders interessant wird es, wenn man beide Managementsysteme gemeinsam betrachtet.

   Requirements-Engineering-Aktivität - ISO 9001:2015 - ISO/IEC 27001:2022

    Kundenanforderungen ermitteln -  8.2 -  4.2 / 6.1

   regulatorische Anforderungen -  8.2 -  4.2 / 6.1

   Anforderungen analysieren -  8.2 / 8.3 -  6.1 / 8.2

   Qualitätsanforderungen -  8.3.3 -  6.2 / risikobezogen

   CTQ -  8.3.3 / 8.5 / 8.6 -  risikobezogen

   Security Requirements -  8.3.3 -  6.1.2 / 6.1.3 / A.8.26

   Architektur -  8.3.4 -  A.8.27

   Secure Development -  8.3 -  A.8.25

   Secure Coding -  8.5 / 8.3 -  A.8.28

   Security Testing -  8.3.4 / 8.6 -  A.8.29

   Abnahmekriterien -  8.6 -  A.8.29

   Traceability -  8.3 / 8.5.2 / 8.6 -  6.1 / 8 / A.8

   Änderungsmanagement -  8.3.6 / 8.5.6 -  6.3 / A.8.32

   Lieferantenentwicklung -  8.4 -  A.5.19–A.5.22 / A.8.30

   Nichtkonformitäten -  8.7 / 10.2 -  A.5.24–A.5.28, je nach Sachverhalt

   Verbesserung -  10 -  10

Die Tabelle sollte dabei nicht als formales 1:1-Mapping der beiden Normen verstanden werden. Sie zeigt vielmehr, wo sich die Themen fachlich überschneiden und durch einen gemeinsamen Prozess sinnvoll integrieren lassen.

10. Der eigentliche Mehrwert eines integrierten Ansatzes

Für ein Unternehmen, das beispielsweise eine Cloud-Anwendung entwickelt, könnte eine einzige Anforderung mehrere Perspektiven gleichzeitig bedienen.

Beispiel:

„Administrative Benutzer müssen sich vor dem Zugriff auf privilegierte Funktionen mit einer starken Authentisierung authentisieren. Fehlgeschlagene Authentisierungsversuche sind zu protokollieren.“

Daraus können entstehen:

Requirements Engineering

• Security Requirement
• Functional Requirement
• Acceptance Criteria

Qualitätsmanagement

• CTQ
• Prüfkriterium
• Testfall
• Freigabekriterium

Informationssicherheit

• Risiko
• Security Control
• Logging
• Authentication

Softwareentwicklung

• Architekturentscheidung
• Implementierung
• Secure Coding
• Security Test

Audit / Compliance

• Requirement
• Risiko
• Umsetzung
• Testnachweis
• Freigabenachweis

Das ist der eigentliche Vorteil eines integrierten Ansatzes:

Eine sauber definierte Anforderung kann mehrere Managementsysteme und Entwicklungsaktivitäten miteinander verbinden.

11. Requirements Engineering als gemeinsamer Prozess für QMS und ISMS

Aus diesen Zusammenhängen lässt sich ein integrierter Prozess ableiten:

Schritt 1 – Anforderungen ermitteln

Kunden, Benutzer, Markt, Gesetzgebung und interne Organisation.

Schritt 2 – Anforderungen klassifizieren

Zum Beispiel:

• funktional
• Qualität
• Performance
• Security
• Safety
• Regulatory
• Usability
• Business Continuity

Schritt 3 – Risiken analysieren

Welche Risiken entstehen, wenn eine Anforderung nicht erfüllt wird?

Schritt 4 – Anforderungen spezifizieren

Eindeutig, messbar, testbar und priorisiert.

Schritt 5 – Design und Architektur

Wie wird die Anforderung technisch umgesetzt?

Schritt 6 – Implementierung

Entwicklung entsprechend den definierten Anforderungen.

Schritt 7 – Verifikation und Validierung

Wurde die Anforderung korrekt umgesetzt?

Und:

Erfüllt das Produkt tatsächlich den vorgesehenen Zweck?

Schritt 8 – Nachweis

Requirement → Test → Ergebnis → Freigabe.

Schritt 9 – Änderungsmanagement

Was ändert sich bei neuen Anforderungen, Schwachstellen oder regulatorischen Vorgaben?

12. Und hier kommt der CRA ins Spiel

Der Cyber Resilience Act erweitert diese Betrachtung um regulatorische Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen.

Damit entsteht für Hersteller eine besonders interessante Dreiecksbeziehung:

ISO 9001

→ Produkt- und Prozessqualität

ISO/IEC 27001

→ Informationssicherheitsrisiken und Security Management

CRA

→ regulatorische Cybersicherheitsanforderungen für betroffene Produkte

Requirements Engineering kann diese drei Perspektiven miteinander verbinden.

Das bedeutet beispielsweise:

CRA-Anforderung

Security Requirement

Risk Assessment

Design Requirement

Implementierung

Security Test

Acceptance Criterion

Technical Documentation

Nachweis der Erfüllung

Damit wird Requirements Engineering zu einem wichtigen Bindeglied zwischen Managementsystem und Produktentwicklung.

13. Die Konsequenz für Unternehmen

Für Unternehmen, die gleichzeitig Qualitätsmanagement, Informationssicherheitsmanagement und Produkt-Compliance beherrschen müssen, liegt deshalb eine wichtige Erkenntnis nahe:

Requirements Engineering sollte nicht ausschließlich Aufgabe der Entwicklung sein.

Es ist eine gemeinsame Schnittstelle von:

• Produktmanagement
• Entwicklung
• Qualitätsmanagement
• Informationssicherheit
• Risikomanagement
• Testmanagement
• Compliance
• gegebenenfalls Regulatory Affairs

Die entscheidende Frage lautet daher nicht:

„Wer schreibt unsere Anforderungen?“

Sondern:

„Wie stellen wir sicher, dass alle relevanten Anforderungen erkannt, bewertet, umgesetzt, getestet und nachgewiesen werden?“

Genau hier beginnt ein professionelles Requirements Engineering.

Fazit

ISO 9001, ISO/IEC 27001 und der Cyber Resilience Act sind keine drei voneinander isolierten Themen.

Für einen Softwarehersteller lassen sie sich entlang des Produktlebenszyklus miteinander verbinden:

Anforderung

→ Risiko

→ Qualität

→ Security

→ Design

→ Implementierung

→ Test

→ Abnahme

→ Nachweis

→ Änderung

→ Verbesserung

ISO 9001 liefert dabei den Rahmen für die systematische Beherrschung von Kunden-, Produkt- und Entwicklungsanforderungen.

ISO/IEC 27001 ergänzt die Perspektive des Informationssicherheitsrisikomanagements und enthält mit A.8.25 bis A.8.34 besonders relevante Controls für die sichere Softwareentwicklung.

Der CRA bringt zusätzlich regulatorische Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen und deren Lebenszyklus hinzu.

Requirements Engineering kann diese Anforderungen in eine gemeinsame, nachvollziehbare Struktur überführen.

Damit wird aus Requirements Engineering mehr als eine Methode der Softwareentwicklung: Es wird zu einem verbindenden Prozess zwischen Produktqualität, Informationssicherheit, Risikomanagement und Compliance.

Ihr Konstantin Ziouras