Die korrekte, konsistente und vollständige Formulierung der Anforderungen ist für die Entwicklung des Endprodukts von entscheidender Bedeutung. Sie stellt sicher, dass alle Ziele, Anforderungen und Erwartungen der verschiedenen Interessengruppen präzise beschrieben, verständlich und eindeutig sind und nicht unterschiedlich interpretiert werden können. Zu diesem Zweck gibt es verschiedene Techniken, die helfen können, die Anforderungen korrekt zu formulieren.
Gegenüberstellende Übersicht über "gute" und "schlechte" Anforderungen im Requirements Engineering.
(Bild: Heitec)
Anforderungen in natürlicher Sprache
Anforderungen können in natürlicher Sprache geschrieben werden, was eine sehr flexible Formulierung von Anforderungen ermöglicht und für alle Arten von Anforderungen geeignet ist. Der Nachteil dabei ist, dass die natürliche Sprache oft mehrdeutig ist oder Auslassungen enthält, die in der Überprüfungsphase schwer zu identifizieren sind. Damit derart formulierte Anforderungen dennoch effektiv sind, müssen sie kurz, präzise, gut strukturiert und widerspruchsfrei sein sowie eine einheitliche Terminologie aufweisen. Unspezifische oder unvollständige Sätze sowie Universalquantoren wie“ alle, immer, keine, nie“ sind zu vermeiden. Weitere „DONTS“ sind weiter unten in diesem Artikel aufgeführt.
Anforderungsmuster / Vorlagen (Templates)
Eine bessere Möglichkeit, Anforderungen zu schreiben, ist die Verwendung von Mustern oder Vorlagen. Dabei handelt es sich um vordefinierte Sätze, die in ihrer Struktur die Formulierung qualitativ hochwertiger Anforderungen unterstützen. Die Vorteile hierbei liegen in der Reduktion von Spracheffekten, der syntaktischen Eindeutigkeit und der hohen, bewährten Qualität bei vergleichsweise geringem Aufwand.
Für das Schreiben einzelner Anforderungen wurden in der Literatur verschiedene Formulierungsvorlagen definiert. Eine hiervon ist folgende Vorlage für individuelle Anforderungen:
[<Bedingung>] <Gegenstand> <Aktion> <Objekte> [<Einschränkung>] Hier demonstriert am Beispiel eines Bankautomaten:
Wird eine gültige Karte erkannt, muss das System innerhalb von 200 ms die Meldung „Geben Sie Ihre PIN ein“ auf dem Dialogbildschirm anzeigen.
Definition einer Verbindlichkeit
Jede Anforderung muss ein Verb enthalten, das die Verbindlichkeit der Anforderung anzeigt. Diese Verben sind normiert und immer identisch zu verwenden:
„Muss“ (engl. „shall“): Bei diesen Anforderungen handelt es sich um zwingende, verbindliche Bestimmungen.
„Sollte“ (engl. „should“): Erwünschte, unverbindliche Bestimmungen wie Vorlieben oder Ziele werden im Konjunktiv mit „sollte“ formuliert.
„Kann“ (engl. „may“): Vorschläge oder Erlaubtes sind ebenfalls unverbindliche, nichtbindende Bestimmungen und verwenden das Verb „können“.
Ungünstige Praktiken bei der Anforderungsformulierung
Bei der Formulierung der Anforderungen gibt es ungünstige Praktiken, die vermieden werden sollten, um die positiven Effekte des Requirements-Engineerings zur vollständig zu nutzen. Einige der wichtigsten davon sind hier aufgeführt:
Inkonsistenzen zwischen Anforderungen
Bei der Formulierung der Anforderungen besteht die Möglichkeit, dass zwei Anforderungen nicht miteinander vereinbar sind, oder die natürlichsprachliche Formulierung nicht mit einer modellbasierten übereinstimmt. Daher müssen die Anforderungen analysiert und miteinander abgeglichen werden.
Anforderungen, die nicht zu realisieren sind
Während der Formulierung der Anforderungen darf die Machbarkeit und die Möglichkeit der Umsetzung nicht aus den Augen verloren werden. In dieser Phase sollten die Stakeholder eine realistische Umsetzung ihres Produkts anstreben, wobei Konflikte als Folge unterschiedlicher Erwartungen entstehen können.
Anforderungen, gegen die nicht verifiziert werden kann
Artefakte, die während des Entwicklungsprozesses entstehen (Spezifikationen, Schaltpläne, Konstruktionszeichnungen), spätestens aber ein Muster des Produkts muss gegen die Anforderungen verifiziert werden, um sicherzustellen, dass die Anforderungen erfüllt sind. Dies kann durch Aktivitäten wie Review oder Tests erfolgen. Sind die Anforderungen fälschlicherweise so formuliert, dass gegen sie nicht z.B. durch einen Test verifiziert werden kann, kann dies zu Unstimmigkeiten zwischen den Projektparteien führen. Im schlimmsten Fall müssen Anforderungen neu formuliert und Teile der Entwicklung wiederholt werden. Das Thema Verifizierung wird dediziert noch einmal in einem späteren Artikel dieser Serie behandelt.
Nicht-Atomarität von Anforderungen
Eine leider immer noch stark verbreitete „Sünde“ ist es, mehrere Anforderungen in einem Anforderungs-Statement unterzubringen. Die Vorteile liegen zunächst auf der Hand: weniger Anforderungen, weniger Pflegeaufwand, schnelleres Vorankommen. Die Probleme dieser nicht-atomaren (nicht-eigenständigen) Anforderungen treten jedoch später im Entwicklungsprozess auf, wenn das Produkt gegen die Anforderungen verifiziert werden muss: Testfälle müssen erstellt werden. Wenn nun mehrere Anforderungen in einem Anforderungs-Statement enthalten sind, müssen mehrere Testfälle dieser Anforderung zugeordnet und deren Erfüllung geprüft werden. Mapping und Nachvollziehbarkeit sorgen für deutlichen Mehraufwand und erhöhte Komplexität.
Konzentration auf nur eine Formulierungsstrategie
Wird nur eine Formulierungsstrategie verwendet (z. B. nur natürliche Sprache), kann dies zu Unvollständigkeit oder Ungenauigkeit der Anforderungen führen, was später eine fehlerhafte Entwicklung des Produkts zur Folge hat. Idealerweise sollten alle verfügbaren Werkzeuge wie z. B. auch Modelle genutzt werden, um die Anforderungen so klar wie möglich zu formulieren. Diese werden im nächsten Teil der Serie behandelt.
Keine Nachvollziehbarkeit der Anforderungen
Um sicherzustellen, dass die Anforderungen einen Mehrwert bieten und auch um in regulierten Märkten konform zu normativen Vorgaben zu sein, müssen sie in allen Phasen der Entwicklung nachvollziehbar („traceable“) sein. Das bedeutet, für eine Entwicklung nach dem V-Modell müssen die Anforderungen durch den Entwurf, die Implementierung und die Verifikation verfolgt werden, um sicherzustellen, dass sie in allen relevanten Artefakten enthalten sind. Ein Werkzeug wie eine Requirements Traceability Matrix oder spezielle Software-Tools für das Requirements-Engineering müssen die Rückverfolgbarkeit der Anforderungen über den gesamten Lebenszyklus des Produkts hinweg ermöglichen.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel Communications Group GmbH & Co. KG, Max-Planckstr. 7-9, 97082 Würzburg einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von redaktionellen Newslettern nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung, Abschnitt Redaktionelle Newsletter.
Neben der Formulierung von Anforderungen in Sprache spielen aber auch modellbasierte Anforderungen eine immer stärkere Rolle. Diese werden im nächsten Teil der Serie betrachtet, seien Sie dabei! (sg)
IREB (2022). Certified Professional for Requirements Engineering - Foundation Level - Handbuch (1.2.0). IREB e.V.
ISO/IEC/IEEE 29148:2018. Systems and software engineering - Life cycle processes - Requirements engineering
Alistair Mavin, Philip Wilkinson, Adrian Harwood, and Mark Novak (2009). Easy Approach to Requirements Syntax (EARS). 17th IEEE International Requirements Engineering Conference (RE'09). Atlanta, Georgia
C. Rupp (2021). Requirements Engineering und Management (7. Auflage). Hanser
* Stefan Lange ist Teamleiter Systems Engineering im HEITEC Geschäftsgebiet Elektronik und Dozent für Systems Engineering an der Hochschule Augsburg.
* Moises Lorenzo-Leon ist Systemingenieur im HEITEC Geschäftsgebiet Elektronik und Certified Professional für Requirements Engineering.