Entwicklung von Anforderungen und Testfällen Hand in Hand

Requirements Engineering und Test gehören zusammen. Historisch haben Tester die Anforderungen oft erst zu Gesicht bekommen, wenn das System bereits teilweise realisiert war. Das hatte zwei gravierende Nachteile. Zum einen kam unzureichende Anforderungsqualität viel zu spät auf den Tisch. Zum anderen war es ein ziemlicher Mehraufwand, ohne den Kontext der Anforderungsermittlung passende Testfälle abzuleiten. Viel Zusatzaufwand und lange Korrekturschleifen waren die Folge. Test hat die unangenehme Eigenschaft, dass er immer zu teuer ist und in der Regel massiv Aufwand verschwendet. In vielen Projekten wird für Verifikation und Validierung über die Hälfte der Lebenszykluskosten bezahlt. Mehr Test ist nicht mehr wert. Testfälle zu sammeln und ständig zu wiederholen, bringt nichts, wenn dahinter keine gute Teststrategie steht. Unsere Projekte von Vector Consulting mit ganz verschiedenen Kunden zeigen, dass Test in der Regel künstlich und losgelöst von den kritischen Anwendungsszenarien ist [Ebe19]. Das Falsche wird getestet, und Abdeckungslücken werden spät oder gar nicht erkannt. Nur eine agile Balance von geplanter Abdeckung und früher Testvorbereitung führt zum Erfolg [You18, You20]. Solch risikoorientiertes Arbeiten optimiert auch das Requirements Engineering. Statt Paralyse durch Analyse wird das spezifiziert, was nötig ist. Mein Kollege und Freund Al Davis nannte das „Just enough requirements engineering“ [Dav05, You20]. Gute Tester brauchen negative Ergebnisse. Dies liegt nicht daran, dass sie negativ eingestellt sind, sondern daran, dass sie für den Misserfolg bezahlt werden. Ein gelungener Testfall zeigt einen Fehler. Ein Testfall, der erfolgreich läuft, zeigt ohne Teststrategie rein gar nichts. Viele Testfälle zu sammeln wie weiland Briefmarken, mag zwar manch unbegabten Entwicklern ein Gefühl der Sicherheit geben, aber Menge erhöht zunächst nur die Kosten – ohne Aussicht auf Erfolg. Schlimmer noch, Tester wählen unter Stress in Regressionstests die falschen Kombinationen aus. Klasse statt Masse ist auch im Test die Devise. Die Teststrategie muss daher ständig hinterfragt und risikoorientiert optimiert werden [Cha18, Hus16, Ebe14, Bja16].

Klasse statt Masse

Testorientiertes Requirements Engineering verbessert die Anforderungsqualität und macht damit das Projekt von Beginn an schlanker und effizienter. Der Grund dafür ist einfach. Ein Tester fragt grundsätzlich bei jeder Anforderung und in jedem Szenario zuerst einmal: „Was wäre, wenn ...?“ Falls die Antwort klar und nachvollziehbar ist, wird er weiter fragen, bis eine Situation auftritt, die noch nicht ausreichend spezifiziert oder gar analysiert und abgestimmt ist. Erst dann kann er zufrieden sein und wird die gefundenen Schwachpunkte in seiner Liste der Auffälligkeiten markieren. Die parallele Entwicklung von Anforderungen und Testfällen verbessert die Anforderungen bereits in deren Entstehungsprozess. Das reduziert Fehler in den Anforderungen und verringert drastisch den Abstimmungsaufwand im Projekt aufgrund missverstandener Anforderungen. Das sichert Testbarkeit der Anforderungen sowie eine frühzeitige Betrachtung der Umsetzbarkeit und des nötigen Integrationsaufwands. Durchgängiges Testen, gezielte Testabdeckung und effiziente Regressionstests sind damit möglich. Testorientiertes Requirements Engineering bildet verschiedene Arten von Anforderungen, wie Funktionen, Qualitätsanforderungen und Randbedingungen, frühzeitig in der Analyse auf passende Testfälle ab. Nur diese klare Aufteilung verschiedener Arten von Anforderungen und Testfällen stellt sicher, dass Fehler frühestmöglich in der Phase gefunden werden, in der sie zuerst auftreten. Damit ist testorientiertes Requirements Engineering auch eine Erweiterung des risikobasierten Testens, denn aus hochpriorisierten Anforderungen oder auch solchen mit kritischem Bezug, wie Safety und Security, werden unmittelbar passende Testfälle abgeleitet. Dieser Beitrag beschreibt die praktische Umsetzung von testorientiertem Requirements Engineering (TORE) in der Praxis. Testfälle werden parallel zu den Anforderungen entwickelt, und damit die Machbarkeit der Anforderungen viel schneller analysiert als in der traditionellen sequenziellen Vorgehensweise, in der Tests relativ spät spezifiziert werden. Die Testfälle werden dabei zunächst in der gleichen Struktur wie die Anforderungen als Ergänzung zu Anforderungen beschrieben. Damit verlagert sich das als agile Methodik bereits bewährte Test-Driven Development (TDD) auf die Spezifikationsebene. Regressionstests werden attributiert, um die spätere Automatisierung vorbereiten zu können. Der für den Test nötige Aufwand ist auf dieser Basis besser schätzbar, und damit sind die Projekt- und Qualitätsrisiken reduziert. Dieser Beitrag basiert auf Methodik und einem Beispiel, das im Buch „Systematisches Requirements Engineering“ beschrieben wurde [Ebe19].

Testorientierung in der Praxis

Gutes Requirements Engineering (RE) braucht gute Tester, die im Analyse- und Spezifikationsprozess aktiv beteiligt sind. Umgekehrt gilt, dass ein brauchbarer Test mit hoher Effektivität und Produktivität bereits in der Spezifikationsphase beginnt. Effizient wird das Requirements Engineering, wenn die Anforderungen nicht nur testbar sind, sondern auch direkt als Testfälle nutzbar sind [Ebe19, Bja16]. Die Anforderungsermittlung beeinflusst den späteren Test. Abbildung 1 zeigt die grundlegenden Zusammenhänge im testorientierten RE. Die zentrale Frage hier lautet: Was ist der wesentliche Nutzen für verschiedene Anspruchsträger? Danach richtet sich nicht nur die Priorisierung und Iterationsplanung, sondern auch die Testplanung. Schließlich müssen die gelieferten Funktionen im fertigen System mit der richtigen Qualität zur Verfügung stehen. Jede darunterliegende Schicht geht zwar mehr ins Detail, weitet dabei aber immer das RE und den damit verbundenen Test aus. Die Systemanalyse liefert ein Pflichtenheft oder Fachkonzept bei IT-Lösungen, das als Basis für den Systemtest aus einer internen Sicht dient. Der Systementwurf legt die Hardware- und Softwareanforderungen fest. Entsprechend werden diese Funktionen später im Integrationstest verifiziert.

Testorientiertes RE gewährleistet, dass für jede Abstraktionsebene (horizontale Schichten in Abbildung 1) sowohl die Anforderungen als auch die wesentlichen Testfälle spezifiziert werden. Beim TORE wird insbesondere die obere Ebene betrachtet, um Systemanforderungen direkt mit Integrations- und Systemtests zu verknüpfen. Nur diese klare Aufteilung verschiedener Arten von Anforderungen und Testfällen stellt sicher, dass Fehler frühestmöglich in der Phase gefunden werden, in der sie zuerst auftreten. Damit steht auch das Gerüst der Regressionstests für spätere Änderungen und agiles Arbeiten fest [You18, You20]. Wie wird testorientiertes Requirements Engineering umgesetzt? Vereinfacht gesagt wird jede Anforderung bereits in der Ermittlung als Testfall spezifiziert. Das kann in zwei Methoden erfolgen:

• Man schreibt die Anforderung unmittelbar als Testfall, ähnlich wie man im Test-Driven Development (TDD) zuerst den Unit-Testfall schreibt, und dann den Code, der diesen Test erfüllt.
• Man nimmt die klassische Kundenanforderung so, wie sie ist, und schreibt dazu einen oder mehrere Testfälle, die diese Anforderung unmittelbar testbar machen und die wesentliche Funktionalität abdecken. Korrelationen von Anforderungen können offensichtlich in dieser Phase nicht beachtet werden.

Sofern die Anforderungen formalisiert sind, können die Testfälle automatisch aus strukturierten Anforderungen generiert werden. Das ist bei Anforderungen mit konsistenter Struktur, wie Anwendungsfällen (Use Cases) mit messbaren Vor- und Nachbedingungen, mit Skripts möglich, wie wir es beispielsweise in IT-Systemen oder auch beim Test von GUI durchführen [Ebe19]. Wir wollen dieses Vorgehen und seinen Nutzen an einem kleinen Beispiel aus der Gebäudeautomatisierung veranschaulichen. iHome ist unser Beispiel einer intelligenten und vernetzten Automatisierung, die wir komplett durchgängig realisiert haben. Nehmen wir die folgende Anforderung aus iHome:

• M-Req-1: Bei der Wartung sind die Konfigurationsdaten von iHome automatisch so zu präsentieren wie beim letzten Mal.

Die Motivation für diese Anforderung ist Benutzbarkeit. Eine mühsam optimierte Einstellung für einen bestimmten Bearbeiter sollte nicht jedes Mal manuell neu eingestellt werden müssen. Nun kommt der Tester ins Spiel. Er entdeckt sofort einige offene Punkte in der Spezifikation: Was ist das „letzte Mal“? Sollen die Einstellungen pro Szenario oder pro Benutzer eingefroren werden? Sind die Sichten beliebig und autonom durch den Benutzer definierbar oder werden sie aus vorkonfigurierten Sichten durch Parametrisierung individualisiert? Sind alle Sichten für alle Benutzer verfügbar oder aber nur diejenigen, die ein Benutzer vorher für sich selbst definiert hatte? Der Tester wird viele solcher Subtilitäten finden, die später im Projekt bestenfalls zu Klärungsbedarf führen und damit das Projekt verzögern, und schlimmstenfalls zu viel Verwirrung und Fehlern, wenn sie ohne Klärung nach Gutdünken der Entwickler realisiert werden. Nachdem diese offenen Punkte geklärt sind, wird der Tester interne Akzeptanzkriterien vorschlagen und daraus Testfälle ableiten. Ein zugehöriger Testfall könnte wie folgt aussehen:

• Testfall-1: Ändere die Darstellung eines Admin-Bildschirms von Zoom, Fensteranordnung und gewählten Ausschnitten. Verlasse die Szenario-Beschreibung. Gehe zur Beschreibung zurück. Die Beschreibung wird exakt gleich dargestellt.

Mit diesem Testfall wird die Anforderung klar, und man kann sie trotzdem so formulieren, dass sie nicht überbestimmt ist. Der klare und konsistente Bezug zwischen Anforderungen und Testfällen unterstützt das Testdatenmanagement. Abbildung 2 zeigt exemplarisch einen solchen Zusammenhang, wie er in vielen Produkten auftritt. Links ist die Produktsicht dargestellt, zu der eine bestimmte (versionsoder variantenabhängige) Testliste und projektbegleitend die jeweiligen Testergebnisse (z. B. Reports, Testabdeckung, Fehlerzahlen, Korrekturfortschritt, Regressionstests) gehören. Rechts ist – projektübergreifend – die Testbibliothek dargestellt, die es erlaubt, Testfälle in verschiedenen Varianten und Versionen einzusetzen. Konsistenz wird durch die Verweise auf bestimmte Produktanforderungen erreicht.

Testorientiertes RE sollte direkt im ALM oder PLM (Application oder Product Lifecycle Management) durch eine frühzeitige Verknüpfung von Anforderungen mit Testfällen unterstützt werden. Ohne adäquate Werkzeugunterstützung werden die Inhalte schnell inkonsistent, da in der Hektik des Alltags einfach die Zeit fehlt, mehrere Quellen parallel zu pflegen. Mit Kunden bauen wir oft spezifische Umgebungen für deren gewachsene Werkzeugumgebung auf, um TORE effizient umzusetzen [Ebe19]. Abbildung 3 zeigt ein solches Beispiel aus einer konkreten Werkzeugumgebung. Wir nutzen hier eine industrielle ALM-Umgebung, die RE, Modellierung und Test unterstützt. Über eine Traceability werden die Anforderungen unmittelbar als Testfälle für den Vorwärtsfall spezifiziert und dann im Rahmen der Teststrategie mit Korrelationen ergänzt. Regressionstests werden markiert, um spätere Änderungen effizient und dennoch zielgenau abzusichern.

Nutzen von TORE

Testorientiertes RE hat einen hohen Kosten-Nutzen-Effekt, da es die Aufwände in Analyse und Prüfung frühzeitig auf das Testen lenkt und damit Doppelarbeit reduziert. Das Planen und Spezifizieren von ersten konkreten Testfällen helfen offensichtlich beim Spezifizieren und Verstehen von Anforderungen.

Vollständigkeit der Anforderungen
Tester bemerken sofort, wenn es undefinierte Bereiche gibt. Sie fragen – und prüfen sehr pragmatisch: Wie soll ich das denn testen? Was wird hier erwartet? Und was passiert, wenn der Benutzer „xyz“ eingibt? Was werden Nichtfachleute an dieser Stelle eingeben? Woher erhält dieses System die Datei „abc“?

Genauigkeit und Klarheit der Anforderungen
Oftmals bleiben Anforderungen oberflächlich, weil sie einen faulen Kompromiss enthalten oder weil die Details noch nicht vollständig abgestimmt sind. Damit kann man kein System entwerfen. Zumindest müssen Aspekte beschrieben werden, die noch offen sind, damit man eventuell eine Parametrisierung vorsehen kann. Tester bemerken solche Oberflächlichkeiten und verlangen nach mehr Genauigkeit. Betrachten wir beispielhaft Prüfpunkte, die einem Tester sofort auffallen, aber selten einem Entwickler:

• Erwartet das Szenario eine Eingabe, die unter gewissen Randbedingungen in einem anderen Szenario noch gar nicht abgeschlossen ist?
• Wird hier ein Signal zur Synchronisation eingesetzt, welches nicht immer stabil zur Verfügung steht?
• Kann sich die Währung, Zeit oder allgemein ein Datenformat aufgrund von Lieferantenwechsel ändern?
• Was passiert, wenn an dieser Stelle der Vorgang abgebrochen wird?
• Wie verhält sich das System, wenn während der Transaktion der Server nicht reagiert?
• Kann das CPU-Board während einer Transaktion ausgetauscht werden?

Prüfbarkeit der Anforderungen
Anforderungen können genau und vollständig sein und dennoch nicht testbar, weil bestimmte Voraussetzungen noch nicht quantitativ präzisiert sind. Tester sind vor allem daran interessiert, in den Anforderungen auch die späteren Abnahmekriterien wiederzufinden. Nur diese Präzision erlaubt es ihnen, die Testfälle zu optimieren und nicht mit zu vielen Testfällen das Produkt unnötig teuer zu machen. Typische Fragestellungen sind: Wie soll denn nun die Wartbarkeit nachgewiesen werden? Brauchen wir eine bestimmte Testinfrastruktur, um die geforderte Effizienz zu erreichen? Wie wird der Kunde die gewünschte Gebrauchstauglichkeit konkret feststellen? Gibt es bestimmte Anwendungsfälle, die für den Kunden besonders wichtig sind? Welche Ausnahmesituationen müssen getestet werden? An welchen Szenarien verdient der Kunde später am meisten Geld?

Überspezifizierung und Randbedingungen abschwächen
Die Beteiligung von Testern in der Spezifikationsphase verhindert zu starke Randbedingungen. Oftmals werden alle nicht gewünschten Szenarien per Definition ausgeblendet. Dies mag zwar aus Benutzer- und aus Spezifikationssicht einfach sein, reduziert aber auch den verfügbaren Lösungsraum. Tester hinterfragen Randbedingungen und Qualitätsanforderungen genauso wie funktionale Anforderungen. Schließlich bringt jede Randbedingung ebenfalls eine Menge von Testfällen mit sich.

Warum ist der Tester wichtig?

Tester werden dafür bezahlt, Fehler zu finden. In der Spezifikationsphase ist diese Einstellung sehr viel wert, denn die meisten anderen Beteiligten wollen nur die Phase schnellstmöglich abschließen – wohlwissend, dass sich Unstimmigkeiten nachher im Projekt zeigen werden. TORE nutzt die limitierten Kapazitäten der Tester bestmöglich für bessere Anforderungsqualität und später schnelleren und wirksameren Test. Ein Tester fragt grundsätzlich bei jeder Anforderung und in jedem Szenario zuerst einmal: „Was wäre, wenn ...?“ Falls die Antwort klar und nachvollziehbar ist, wird er weiter fragen, bis eine Situation auftritt, die noch nicht ausreichend spezifiziert oder gar analysiert und abgestimmt ist. Erst dann kann er zufrieden sein und wird die gefundenen Schwachpunkte in seiner Liste der Auffälligkeiten markieren. Dieses Vorgehen zeigt, dass gute Tester an negativen Ergebnissen interessiert sind. Dies liegt nicht daran, dass sie negativ eingestellt sind, sondern daran, dass sie für den Misserfolg bezahlt werden. Negative Anforderungen benötigen eine passende Prüfung. Die Validierung mit Testfällen genügt nicht. Dazu müssen mit Techniken wie der Gefahrenanalyse, der Fehlerbaumanalyse oder der FMEA (Failure Mode and Effects Analysis) Szenarien konstruiert und analysiert werden, die nicht eintreten dürfen. Daraus lassen sich dann Testfälle und Abnahmekriterien entwickeln. Allerdings zeigen diese Testfälle nicht, ob das System wirklich sicher oder fehlerfrei ist. Nur spezifische Verifikationstechniken können dies prüfen, beispielsweise ein Erreichbarkeitsgraph, der nachweist, dass ein bestimmter ausgeschlossener Zustand unter keinen Bedingungen erreicht wird. Schauen wir nochmals auf ein Beispiel aus der oben eingeführten Hausautomatisierung iHome. Wir haben die folgende Anforderung:

• M-Req-2: Bei geöffneten Fenstern lässt sich die Alarmanlage nicht aktivieren.

Daraus wird die Produktanforderung abgeleitet:

• P-Req-21: Wenn der Fenstersensor den Zustand „offen“ zeigt, ist Alarmanlage nicht aktivierbar.

Im testorientierten RE wird nun nach einem passenden Testfall gesucht, der das ursprüngliche Ziel aus der Marktanforderung abdeckt. Geprüft wird diese Konstellation durch einen abgeleiteten Testfall (ist die Alarmlage bei geöffneten Fenstern inaktiv?) und durch eine Prüfung (gibt es einen Zustand, in dem die Alarmanlage aktivierbar ist, obwohl ein Fenster offen ist?). Offensichtlich gibt es solche Zustände, beispielsweise bei defekten Sensoren. Diese einfache Prüfung zeigt, dass P-Req-21 unvollständig war. In sicherheitskritischen Systemen sowie in Systemen, in denen kritische Zustände nicht eintreten dürfen, ist eine risikoorientierte durchgängige Prüfung aus Haftungsgründen zwingend vorgeschrieben. Dazu wird eine Gefahrenanalyse durchgeführt, aus der Sicherheitsziele abgeleitet werden. Diese Schutzziele sind initiale Systemanforderungen, die weiter in Komponentenanforderungen untergliedert werden. Eine „brute force“-Validierung durch noch so viele Testfälle genügt nicht, solange keine methodische Abdeckung dieser Schutzziele nachvollziehbar ist. Kasten 1 zeigt einen Ausschnitt der Gefahrenanalyse von iHome.

Und die methodische Ableitung der Schutzziele, die dann in Testfälle umgewandelt werden. System- und Qualifikationstests müssen bereits zu Projektbeginn konstruiert werden. Nur dann darf man davon ausgehen, dass die Anforderungen aus Kundensicht die richtige Qualität haben. Daher ist es für den Projekterfolg relevant, dass Tester bereits in der Analysephase zur Verfügung stehen. Das Problem dabei ist, dass die gleichen Tester in der Anforderungsphase benötigt werden und dort gerade in der heißen Phase des Vorgängerprojekts Überstunden aufhäufen. Abhilfe schaffen dabei dezidierte Expertenteams, die langfristig gebildet werden. In diesen Expertenteams sind verschiedene Expertisen fest eingeplant, die mit einem bestimmten Prozentsatz für die Analyse und für Reviews der Spezifikationen in den frühen Phasen von Projekten zur Verfügung stehen. Beispielsweise optimiert ein Tester die Teststrategie durch Eliminieren von Redundanzen, kritikalitätsbasiertes unbalanciertes Testen usw. Die Testabdeckung verknüpft Anforderungen mit der Umsetzung und zeigt, wie viele Anforderungen bereits getestet sind und wie gut sie funktionieren (siehe Abbildung 4). Damit steuert sie sowohl den Tester, der versucht, sie möglichst hoch zu trimmen, als auch den Auftraggeber, der sicherstellen will, dass sein Produkt adäquat getestet wurde.

Fazit

TORE ist eine Methode, die agile Softwareentwicklung nach „oben“ hin zum Test erweitert. Wo bisher vor allem Unit Testing als Spezifikation von Code genutzt wurde, abstrahiert TORE hin zu Integrations- und Systemtests im Zusammenspiel mit Anforderungen derselben Abstraktionsebene. Zum Abschluss einige Praxistipps aus unseren Projekten:

• Jede einzelne Funktionsanforderung hat mindestens ein Abnahmekriterium, das entweder erfüllt oder nicht erfüllt ist.
• Jede einzelne Qualitätsanforderung wird mit numerischen Werten beschrieben, die gemessen werden können.
• Geschäftsregeln werden so definiert, dass festgestellt werden kann, ob sie wahr oder falsch sind.
• Geschäfts- und Datenobjekte werden mit all ihren Attributen, Typen und Zuständen definiert, sodass diese zur Testzeit gesetzt und validiert werden können.
• Systemschnittstellen, wie GUIs, Berichte und Service-Schnittstellen, werden in das Anforderungsdokument aufgenommen, sodass ihnen Werte zugewiesen werden können.
• Alle Anwendungsfälle haben Vor- und Nachbedingungen, die generiert und validiert werden können.
• Der gesamte Text wird so markiert, dass er automatisch zur Generierung von Testfällen verarbeitet werden kann.

In unseren Projekten mit Kunden verschiedener Branchen, aber auch in Vector für die eigene Softwareentwicklung, hat TORE verschiedene greifbare Nutzen gezeigt [Ebe19]:

• Vollständigkeit der Anforderungen: Tester bemerken sofort, wenn es undefinierte Bereiche gibt. Sie fragen und prüfen sehr pragmatisch: Wie soll ich das denn testen? Was wird hier erwartet? Und was passiert, wenn der Benutzer „xyz“ eingibt? Was werden Nichtfachleute an dieser Stelle eingeben? Woher erhält dieses System die Datei „abc“?
• Genauigkeit und Klarheit der Anforde- rungen: Oftmals bleiben Anforderungen oberflächlich, weil sie einen faulen Kompromiss enthalten oder weil die Details noch nicht vollständig abgestimmt sind. Damit kann man kein System entwerfen. Zumindest müssen Aspekte beschrieben werden, die noch offen sind, damit man eventuell eine Parametrisierung vorsehen kann. Tester bemerken solche Oberflächlichkeiten und verlangen nach mehr Genauigkeit.
• Prüfbarkeit der Anforderungen: Anforderungen können genau und vollständig sein und dennoch nicht testbar, weil bestimmte Voraussetzungen noch nicht quantitativ präzisiert sind. Tester sind vor allem daran interessiert, in den Anforderungen auch die späteren Abnahmekriterien wiederzufinden. Nur diese Präzision erlaubt es ihnen, die Testfälle zu optimieren und nicht mit zu vielen Testfällen das Produkt unnötig teuer zu machen.
• Randbedingungen abschwächen: Die Beteiligung von Testern in der Spezifikationsphase verhindert zu starke Randbedingungen. Oftmals werden alle nicht gewünschten Szenarien per Definition ausgeblendet. Dies mag zwar aus Benutzer- und aus Spezifikationssicht einfach sein, reduziert aber auch den verfügbaren Lösungsraum. Tester hinterfragen Randbedingungen und Qualitätsanforderungen genauso wie funktionale Anforderungen. Schließlich bringt jede Randbedingung ebenfalls eine Menge von Testfällen mit sich.

Dieser Beitrag hat eine Übersicht zur Methodik und Stand der Technik des testorientierten Requirements Engineering dargestellt. Gleichzeitig zeigen unsere Industrieerfahrungen aus verschiedenen Branchen von der IT bis zu sicherheitskritischer eingebetteter Software, wie die Methodik wirksam umgesetzt wird. Die beschriebenen Lessons Learned aus der Praxis helfen beim Transfer in die eigene Umgebung.

Literatur & Links

[Bja16]
E. Bjarnason, u. a., A Multi-case Study of Agile Requirements Engineering and the Use of Test Cases as Requirements, in: Information and Software Technology, Sept. 2016, pp. 61–79

[Cha18]
R. N. Charette, Puncturing Pernicious Project Pufferies, in: IEEE Computer, Vol. 51, No. 5, pp. 78–83, 2018

[Dav05]
A. M. Davis, Just Enough Requirements Management, Dorset House, New York, USA, 2005

[Ebe14]
C. Ebert, Risikomanagement, Springer, 2. Auflage, 2014

[Ebe19]
C. Ebert, Systematisches Requirements Engineering, dpunkt.verlag, 6. Auflage, 2019

[Hus16]
A. Hussain, E. Mkpojiogu, F. M. Kamal, The Role of Requirements in the Success or Failure of Software Projects, in: Int. Review of Management and Marketing, No. S7, Vol. 6, pp. 306–311, 2016

[You18]
Agile Requirements Engineering, YouTube-Video, siehe:
https://youtu.be/svTb2X6pFTU

[You20]
When is Requirements Engineering good enough?, YouTube-Video, siehe:
https://youtu.be/VTYVxKomOWA