Softwareanforderung

Windows 2000 als Softwarestack dargestellt: Die einzelnen Komponenten und Subsysteme werden mithilfe von Softwareanforderungen spezifiziert. Diese dienen der Beschreibung der Funktionalität, Leistung und der Schnittstelleneigenschaften.

Eine Softwareanforderung ist eine Anforderung im Rahmen der Softwareentwicklung. Sie beinhaltet die Angabe der Funktionalität, Leistung oder Eigenschaften einer Software bzw. eines Softwaresystems sowie deren internes oder externes Verhalten. Softwareanforderungen dienen somit als Grundlage für die Realisierung (Programmierung) der Software.

Allgemeines

Anforderungen an Software sind in der ISO/IEC/IEEE 29148 normiert. Zusätzlich werden Anforderungen in der Softwaretechnik mithilfe von Modellierungssprachen wie der Unified Modeling Language (UML) entwickelt, womit Software sich in seiner Struktur und seinem Verhalten beschreiben lässt. Die Entwicklung erfolgt dabei im Zuge eines Softwareentwicklungsprozesses.

Im Rahmen des Anforderungsmanagements werden Anforderungen ermittelt, analysiert, spezifiziert und verwaltet. Eine Softwarearchitektur dient außerdem zur Modellierung und Beschreibung der einzelnen Softwareelemente oder Module des Gesamtsystems „Software”. Das Produkt „Software” ist wiederum Teil des Software-Lebenszyklus.

Aus Sicht des Systems Engineering ist Software neben Hardware, Benutzern (Menschen), Prozessen und weiteren Elementen lediglich ein Bestandteil des Systems. Software ist daher Bestandteil eines informationstechnischen Systems. Sie stellt keine unmittelbaren Anforderungen an Werkstoffe oder Materialien, wohl aber an die Ressourcen der Computerhardware, etwa an den benötigten Speicherplatz für Daten.

Aufgrund der stetigen Weiterentwicklung von Programmiersprachen und Softwaretechnik, neuer Computerhardware (vgl. Rechnertechnik) sowie des Aufkommens des Internets (vgl. Informationszeitalter) haben sich die Anforderungen an Software stets verändert. Die Anforderungen an eine Spieleapplikation unterscheiden sich deutlich von denen an einen Onlinedienst, der in einer Cloud-Umgebung läuft; oder hardwarenahen Firmware oder Algorithmen, oder Codes, die beispielsweise im wissenschaftlichen Rechnen verwendet und in einer Supercomputer-Umgebung eingesetzt werden. Im folgenden Artikel wird daher nur ein genereller Ansatz beschrieben, wie Software und ihre Anforderungen grob erfasst werden können.

Anforderungsebenen

Im Rahmen eines Software-Projekts werden eine Vielzahl verschiedener Anforderungen an das Projekt und das zu erstellende softwarebasierte Produkt bzw. Softwaresystem gestellt. Aus diesen verschiedenen Rahmenbedingungen und Voraussetzungen können sich Anforderungen auf verschiedenen Ebenen an die Software ergeben:

Wirtschaftlicher Kontext

• Geschäftsanforderungen: Dazu gehören vertragliche Anforderungen zwischen Auftraggeber und Auftragnehmer sowie die grundlegenden Absichten aus einem Projektantrag, welche an das gewünschte Softwareprodukt gestellt werden. Das Produktmanagement befasst sich außerdem mit den Anforderungen des Marktumfelds. Das Projektmanagement ist hierbei für die Verwaltung der Inhalte und Umfänge zuständig. Die Geschäftsanforderungen können nur vom fertigen Softwareprodukt erfüllt werden. Schlussendlich wird der Auftraggeber die Software abnehmen (Validierung).
• Projektanforderungen: Damit sind alle sich aus dem Projektkontext (siehe die Unterstützungsprozesse) ergebenden Anforderungen an die Software oder das Produkt gemeint. Zu Berücksichtigen sind die Anforderungen im Zuge eines Application Lifecycle Managements (ALM), Product Lifecycle Management (PLM) oder auch IT-Service-Management (ITSM). Bei Software ist der Software-Lebenszyklus von Bedeutung. Das Projektmanagement ist maßgeblich für die Steuerung und Verwaltung der Softwareherstellung. Die Art des Projektmanagements richtet sich in der Softwareentwicklung nach dem gewählten Prozess. Aus dem Projektmanagement ergeben sich außerdem Anforderungen an die Dokumentation des Softwareprodukts und viele weitere.

Technischer Kontext

• Benutzeranforderungen: Eine weitere Klasse sind jene Anforderungen, welche die Anwender der Software betreffen. Sogenannte Anwendungsfälle und andere Verhaltensdiagramme dienen zur qualitativen Beschreibung möglicher Szenarien. Benutzeranforderungen werden beispielsweise von Business Analysten oder Product Ownern (dt. etwa Produktverantwortliche) im Rahmen des Scrum-Vorgehens erarbeitet. Es ist aber auch möglich, dass das Entwicklungsteam oder Vertreter der Benutzer sie selbst ermitteln. Auf dieser Ebene spielt eine Softwarearchitektur eine zentrale Rolle. Benutzeranforderungen müssen die Geschäftsanforderungen erfüllen.
• Funktionale und nichtfunktionale Anforderungen: Erfasst werden Eigenschaften, Verhalten und Leistung, die eine Software besitzen soll. Dazu kommen auch die Anforderungen an die Schnittstelle (vgl. Inteface Control Document) und die Implementierung, die ebenfalls spezifiziert werden müssen. Die einzelnen Software-Artefakte werden mittels Integration zu einem Ganzen zusammengefügt (vgl. auch die modernen Verfahren CI/CD oder DevOps). Diese technischen Anforderungen werden teilweise aus den Benutzeranforderungen abgeleitet und in Absprache mit der Softwareentwicklung und der Testabteilung definiert. Sie umfassen die grundlegende Struktur und das Verhalten der Software. Dazu zählen unter anderem die Daten und Datentypen.

Format und Spezifikation

→ Hauptartikel: Anforderung (Informatik)

Softwareanforderungen werden wie gewöhnliche Anforderungen in den folgenden Formaten erfasst:

• textuell (Sprache) und/oder
• grafisch (visuell).

Bereits erwähnt wurden Hilfswerkzeuge wie die Modellierungssprache Unified Modeling Language (UML). Müssen die Anforderungen an die Software möglichst detailliert erfasst werden, kommen formale Methoden zum Einsatz. In der agilen Softwareentwicklung werden für Anforderungen User Stories, Features und Epics eingesetzt, vgl. auch das Vorgehen nach Scrum.

Anforderungen werden kurz, prägnant und eindeutig formuliert. Sie beschreiben, was die Software oder das Softwaresystem leisten oder erfüllen soll, nicht, wie es umgesetzt wird. Dazu werden funktionale Anforderungen geschrieben. Nichtfunktionale Anforderungen beschreiben Qualitätsmerkmale und Rahmenbedingungen, etwa Leistung oder Verfügbarkeit.

Wie bereits erwähnt gibt es eine Vielzahl verschiedener Software. Für Anwendersoftware müssen Design-Anforderungen an die UI/UX/GUI erfasst werden, die für Firmware nicht in allen Fällen relevant sind (keine Anzeige). Onlinedienste leben von einer Vielzahl von Anwendungsprogrammierschnittstellen und Datenaustauschformaten wie JSON. Um der Komplexität jeder Software gerecht zu werden, ist es daher empfehlenswert, eine Softwarearchitektur zu entwickeln.

Zudem sollten alle Anforderungen verifizierbar sein. Zu diesem Zweck werden Softwaretests eingesetzt und von Testingenieuren oder Softwareentwicklern durchgeführt. Die Maßnahmen sind Teil einer Verifizierung und Validierung (V&V). Zudem müssen Anforderungen an die Qualität der Software im Rahmen der Qualitätssicherung definiert und erfüllt werden. Gleiches gilt für Anforderungen an die Informationssicherheit (englisch cybersecurity) oder funktionale Sicherheit (englisch safety) der Software.

Erhebung, Dokumentation und Verwaltung

Zunächst werden die geschäftlichen und projektbezogenen Anforderungen auf Auftraggeber- (Kunde) und Auftragnehmerseite (Produktmanager, Projektleiter oder Business Analysten) bearbeitet. Dies kann im Rahmen einer Kundenakquise oder Beschaffung erfolgen. Aber auch interne Geschäftseinheiten können als Kunde gegenüber Abteilungen auftreten und ein Softwareprodukt anfordern.

Im Rahmen des Stakeholdermanagement werden weitere Interessengruppen abgeholt. Die Informationen werden als Teil des Inhalts- und Umfangsmanagements von Anforderungsmanagern oder Business Analysten ermittelt, analysiert, spezifiziert und meistens in einer geeigneten Anforderungsmanagement-Software zusammengetragen und verwaltet. Ab diesem Zeitpunkt werden Ingenieure und Softwareentwickler die Systemanalyse sowie die Softwarearchitektur und weitere Softwarespezifikationen für eine Implementierung benutzen, wobei das „Wie“, also die Lösung eines technischen Problems, im Fokus steht. Dafür muss das „Was“, also die übergeordneten Anforderungen an die Software, möglichst korrekt und eindeutig spezifiziert worden sein. Dabei spielt der feste Stand der Anforderungen (Baseline) eine bedeutende Rolle, d. h. die Inhalte wurden definiert und von Unstimmigkeiten befreit.

Anforderungen sind Teil des Anforderungsmanagementprozesses und unterliegen einer Versionskontrolle. Jede Anforderung ist außerdem mit einem Status versehen, sodass Änderungen gesteuert werden können. In der Regel übernimmt die Anforderungsmanagement-Software diese unterstützenden Funktionen.

Anforderungen, welche lediglich mündlich, durch Voicemail, auf Klebezetteln, E-Mails, Chats, Mitschriften von Meetings, oder ähnlich unstrukturiert erfasst sind, gehören nicht zum offiziellen Anforderungskatalog des Softwaresystems und können bei der Realisierung nicht berücksichtigt werden. Diese inoffiziellen Informationen müssen zunächst von einem Analysten aufgenommen, ausgewertet und gegebenenfalls strukturiert erfasst werden, bevor sie weiterverwendet werden können.

Je nach Detailierungsebene (vgl. Anforderungsebene) sieht eine Anforderung ein Softwaresystem dabei als „Black Box“ und definiert neben dem Zweck der einzelnen Teilanforderungen auch zugehörige Anwendungsbeispiele aus Sicht der unterschiedlichen Benutzergruppen.

Im Anforderungsprozess sind ein projektbegleitendes Konfigurationsmanagement, ein Variantenmanagement und ein Veränderungsmanagement zu beachten. Ein sogenanntes Issue-Tracking-System kann dabei helfen, Informationen (bzw. Probleme) zu sammeln und zu verwalten. Hierzu existieren auch die Bugtracker. In Einzelfällen kann ein Issue-Tracking-System eine Anforderungsmanagement-Software ersetzen, verfügt in der Regel aber nicht über die gleichen Fähigkeiten wie ein professionelles Werkzeug für Anforderungen.

Die Vorgaben für die oben genannten Prozesse und Werkzeuge stammen aus regulatorischen und normativen Bestimmungen. Dies ist beispielsweise in Branchen wie der Medizintechnik, der Automobilindustrie, der Luftfahrtindustrie, der Raumfahrt sowie der Chemieindustrie speziell vor dem Hintergrund der Sicherheit notwendig. Für Online-Software gelten diese Vorgaben weniger, jedoch müssen stets alle Anforderungen an ein Softwaresystem erfasst werden.

Explizite Anforderungen müssen beispielsweise an den Datenschutz oder die Informationssicherheit gestellt werden. Das Gleiche gilt für die Kryptologie, falls Daten verschlüsselt werden sollen, da der exakte Algorithmus in diesem Fall spezifiziert werden muss.

Es wird implizit erwartet, dass Softwareanforderungen testbar sind, d. h., dass sie durch Unit-Tests überprüft werden können. Anschließend müssen Integrationstests und Systemtests durchgeführt werden, um das Gesamtprodukt zu verifizieren. Eine Abnahme ist nur möglich, wenn das Produkt vom Auftraggeber validiert wurde.

Softwareanforderung aus Kundensicht

In dem Buch Software Requirements definiert Karl Wiegers Rechte und Pflichten des Kunden, welche bei der Erstellung von Anforderungen eingehalten werden sollen:

Rechte des Kunden

1. Geschäftsanalysten verwenden den Jargon des Kunden.
2. Geschäftsanalysten erlernen die Geschäftsabläufe und -ziele des Kunden.
3. Geschäftsanalysten erfassen die Anforderungen derart, dass sie in einer für den Kunden geeigneten Form bereitgestellt werden können.
4. Anspruch auf Auskunft des Zwecks bestimmter Anforderungen und Auslieferungen.
5. Änderungen der Anforderungen.
6. Anspruch auf gegenseitigen Respekt.
7. Auskunft für alternative Ideen des Dienstleisters.
8. Anforderungen an die einfache Benutzbarkeit.
9. Auskunft über Möglichkeiten die Entwicklung zu beschleunigen, indem die Anforderungen so angepasst werden, dass bestehende Softwarekomponenten verwendet werden können.
10. Auslieferung eines Systems, welches sowohl den funktionalen Anforderungen als auch den Qualitätsanforderungen gerecht wird.

Pflichten des Kunden

1. Aufklären des Dienstleisters über die Geschäftsprozesse.
2. Einplanung der Zeit, welche benötigt wird um die Anforderungen bereitzustellen und nachzubessern.
3. Erstellung spezifischer und präziser Anforderungen.
4. Entscheidungen und Auskünfte zu Anforderungen innerhalb angebrachter Zeiträume treffen.
5. Die Einschätzungen der Entwickler zum Zeitbedarf und der Realisierbarkeit einer Anforderung sind zu respektieren.
6. Treffen realistischer Priorisierung der Anforderungen in Absprache mit den Entwicklern.
7. Regelmäßige Reviews von Anforderungen und das Evaluieren von Prototypen.
8. Festlegen von Akzeptanzkriterien in Absprache mit dem Kunden.
9. Schnelles Kommunizieren von Änderungen an den Anforderungen.
10. Einhaltung des Prozesses zum Erfassen der Anforderungen.

Herausforderungen

Dokumente mit Softwareanforderungen können sehr umfangreich ausfallen und, je nach Produkt, hunderte bis tausende Seiten an Dokumentation umfassen. Es ist dabei in der Praxis unmöglich, die Anforderungen vollständig oder widerspruchsfrei zu formulieren. Lücken und Widersprüche werden meist erst während der Entwicklung oder im Produktionsbetrieb aufgedeckt. Zudem ändern sich die Anforderungen im Regelfall während der Entwicklung eines Softwareprodukts.

Weitere Schwierigkeiten ergeben sich dadurch, dass bei Spezifikationen im Üblichen:

• nicht genügend Informationen für die Entwicklung bereitgestellt werden
• auf das Wissen weniger Personen eingeschränkt wird und betroffene Interessengruppen nicht ausreichend eingebunden werden
• Information in der Übersetzung der Kundenbedürfnisse in die Anforderung verloren gehen
• zu erreichende Geschäftsziele (Absicht) vernachlässigt werden und der Fokus zu sehr auf technische Details (konkrete Implementierung) konzentriert wird
• eine natürliche Sprache verwendet wird, welche interpretiert und gedeutet werden muss
• bestimmte Voraussetzungen als gegeben oder selbstverständlich angesehen werden und daher nicht erwähnt werden
• sich kleine Fehler und Änderungen akkumulieren, was dazu führt, dass die Anforderung und die Implementierung im Laufe des Projektfortschritts immer stärker voneinander abweichen

Studien zeigen, dass 40 % bis 50 % aller Fehler in Softwaresystemen durch eine fehlerhafte Anforderung entstehen. Alleine im Jahr 2004 wurden in der Europäischen Union 142 Milliarden Euro aufgrund fehlgeschlagener Softwareprojekte verloren. Hiervon ist die Mehrzahl auf Softwareanforderungen zurückzuführen, welche nicht ausreichend auf die Geschäftsziele ausgerichtet waren oder weil sich die Geschäftsziele verändert haben. Zudem kommt, dass 30 % bis 50 % der Projektkosten durch Änderungen der Anforderungen und damit einhergehenden Produktänderungen entstehen. Von diesen Änderungen werden 70 % bis 85 % durch Fehler in der Anforderung verursacht.

Agile Softwareentwicklung reduziert diese Probleme mittels einer regelmäßigen Kommunikation der Interessengruppen, ist jedoch von denselben Effekten betroffen.

Aufgrund dieser Herausforderungen muss auf eine möglichst präzise Kommunikation geachtet werden. Zudem müssen Prozesse vorgesehen werden, die Anforderungen bei Bedarf abzuändern. Zudem sollte die Anforderung automatisch prüfbar sein, damit die Anforderung zum Zeitpunkt der Fertigstellung der Software widerspruchsfrei ist und mit dem Verhalten der entwickelten Software übereinstimmt.

Umfang

Softwareanforderungen umfassen:

• Programmierschnittstellen
  • Beschreibungen (englisch: contracts)
  • Verhalten
  • Bindung (englisch: binding; Protokoll, Verschlüsselung etc.)
  • Adressen
• Softwarestack
• Standards und Normen (z. B. IETF-, W3C-, ISO- und IEC-Normen)
• Verweise auf Requirements aus anderen Systemen
• Form und Umfang der benötigten Benutzerdokumentation
• Anforderungen an die Qualitätssicherung
  • Testabdeckung durch Unit-Tests
  • Testen von Anforderungen (z. B. mittels BDD)
  • Peer-Review des Quelltext
  • statische Code-Analyse
  • Exploratives Testen
  • SOLID-Prinzipien und Clean Code
• Informations-Anforderungen
  • Datentypen und Datenstrukturen
  • Anforderungen an eindeutige Bezeichner (IDs, GUIDs, URIs, URNs, Clean URLs)
  • Berechnungsformeln
  • Art der Datenpersistierung und Lebensdauer von Daten
  • Felder, welche für eine Entität benötigt werden
  • Anforderungen an Datentransaktionen (unter Berücksichtigung des CAP-Theorems)
  • Daten für die eine Historie erfasst werden muss
    • Versionsverwaltung
    • Sicherheits- und Konformitäts-Auditing
  • Datenspeicherungsinfrastruktur
  • Datenarchivierung
  • Datenwiederherstellung im Katastrophenfall
  • Lokalität der Daten (z. B. Endgerät, Rechenzentrum, Cloud, Geschäftspartner, Öffentlich, regionale Einschränkungen)
  • Daten-Import-/Exportschnittstellen
• Konfiguration der Anwendung
• Funktionalität aus Benutzersicht
  • Information die eingegeben und angezeigt werden soll
  • Barrierefreiheit
  • Definition der Endgeräte und Infrastruktur des Benutzers
  • Benutzerfreundlichkeit
  • Stilrichtlinien
  • Suchmaschinenoptimierung (SEO)
• Berichterstellung
  • Information die in Business-Intelligence-Berichten benötigt wird (z. B. für Vorhersage, Marketing und Controlling)
  • Infrastruktur für die Business-Intelligence-Berichtserstellung (z. B. ETL/OLTP oder CEP)
• Anforderungen an das Product-Lifecycle-Management (PLM)
  • Auslieferungsstrategien (Continuous Delivery und Rollback)
  • Echtzeit-Monitoring
  • Logging
  • Ablaufverfolgung
  • Operations-Management (z. B. OpsDB)
  • Ausführung von A/B-Tests oder Fault-Injection-Tests
• Performance-Anforderungen
  • Antwortzeiten
  • Durchsatz
  • Statische Kapazitätsgrenzen
  • Dynamische Kapazitätsgrenzen
  • Verfügbarkeitsanforderungen
• Flexibilitätsanforderungen
  • Skalierbarkeit
  • Erweiterbarkeit
  • Unparochialität (Unabhängigkeit von der Infrastruktur)
  • Vielfältigkeit (Bereitstellung von Daten für andere Systeme)
  • Internationalisierung (i18n)
    • Mehrsprachigkeit
    • Umgang mit Zeitzonen, sowie Schaltsekunden und -stunden
    • Währungen
    • Leserichtung
    • Kulturelle Symbolik
    • Regional unterschiedliche gesetzliche Anforderungen
• Zugriffskontrolle und Benutzersicherheit
  • Benutzerregistrierung
  • Benutzerauthentifizierung
  • Benutzerautorisierung
  • spezifische Autorisierung (definierte Berechtigungen für Benutzergruppen/Rollen)
  • konfigurierbare Autorisierung (Konfigurierbarkeit von Berechtigungen)
  • Freigabeprozesse
  • Verschlüsselungsmethoden
  • Föderierte Identität und Zero-Knowledge-Anforderungen
  • Datenschutzrichtlinien
  • Benutzer-Impersonation
  • Firewall und ACL-Anforderungen
  • Sichere Verwahrung und Austausch von Schlüsseln und Zertifikaten
• Kommerzielle Anforderungen
  • Organisationsformen der Unternehmen, welche das Softwareprodukt einsetzen (z. B. ITIL)
  • Gesetzliche Richtlinien (z. B. Steuerberechnung, SOX)
• Stabilitätsanforderungen und Fehlermigration
  • Verhalten bei Überlastung oder Ausfall eines externen Systems (z. B. Sicherung, Bulkheads und Verbindungs-Pooling)
  • Darstellung von Fehlern oder eingeschränkter Funktionalität aus Benutzersicht
  • Verhalten im Fehlerfall einer Instanz des Systems (z. B. dynamisches Routing)
  • Identifizierung von für die jeweiligen Geschäftsprozesse kritischen Systemen, sowie möglichen Single Point of Failures
  • Durchsatzratenbegrenzungen
• Aufteilung in Teilanforderungen
  • Definition von Mindestanforderungen und Streckzielen (Muss-, Sollte-, Könnte- und Nicht-Anforderungen; siehe auch: RFC 2119, RFC 6919)
  • Priorisierung von Anforderungen
  • Aufteilung der Zuständigkeiten in getrennte Systeme (z. B. Benutzerverwaltung, Bestellung, Warenmanagement, Zustellung, Administration, Business-Intelligence)
• Aufwands- und Kostenabschätzungen inklusive Unsicherheiten

Siehe auch

• Design Thinking

• Projekt Management Body of Knowledge (PMBOK)
• Software Engineering Body of Knowledge (SWEBOK)
• Systems Engineering Body of Knowledge (SEBOK)

Literatur

Siehe auch: Anforderungsmanagement, Softwaretechnik und Liste von Softwareentwicklungsprozessen

• Karl E. Wiegers: More About Software Requirements: Thorny Issues and Practical Advice (= Developer Best Practices). Microsoft Press, 2006, ISBN 0-7356-2267-1 (englisch). 
• Stephen Withall: Software Requirement Patterns (= Developer Best Practices). Microsoft Press, 2007, ISBN 978-0-7356-2398-9 (englisch). 
• A. van Lamsweerde: Requirements Engineering: From System Goals to UML Models to Software Specifications. John Wiley, Chichester, England ; Hoboken, NJ 2009, ISBN 978-0-470-01270-3 (archive.org). 
• Gojko Adzic: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. Neuri Limited, 2009, ISBN 978-0-9556836-1-9 (englisch). 
• Gojko Adzic: Impact Mapping: Making a Big Impact with Software Products and Projects. Hrsg.: Marjory Bisset. Provoking Thoughts, 2012, ISBN 978-0-9556836-4-0 (englisch). 
• Ulrike Hammerschall, Gerd Beneken: Software Requirements. Pearson Studium, 2013, ISBN 978-3-86894-151-7. 
• Ian Sommerville: Software Engineering. 10. Auflage. Pearson, Boston 2016, ISBN 978-0-13-394303-0 (englisch). 
• Michael T. Nygard: Release it! Design and Deploy Production-Ready Software (= The pragmatic programmers). 2. Auflage. Pragmatic Bookshelf, Raleigh, NC 2018, ISBN 978-1-68050-239-8 (archive.org). 
• Gerard O’Regan: Guide to Software Project Management (= Undergraduate Topics in Computer Science). Springer Nature Switzerland, Cham 2025, ISBN 978-3-031-80577-6, doi:10.1007/978-3-031-80578-3 (englisch). 
• Hironori Washizaki (Hrsg.): Guide to the Software Engineering Body of Knowledge (SWEBOK) v4. 4. Auflage. IEEE Computer Society Press, Washington, D. C. 2026 (englisch, computer.org).