Softwareanforderung

Eine Softwareanforderung ist eine Anforderung im Rahmen der Softwareentwicklung. Die Anforderung erfasst hierbei den Zweck und die Absicht eines Softwaresystems, sowie dessen (externen) Verhaltens.

Grundsätzlich unterscheidet man bei Softwareanforderungen zwischen:^[1]

Geschäftsanforderungen

Ziele, welche sich aus der Geschäftstätigkeit des Kunden und den Marktanforderungen ergeben. Geschäftsanforderungen werden durch das Management und Marketing definiert.

Benutzeranforderungen

Die für die Benutzer des Softwaresystems erforderlichen Anforderungen um die Geschäftsanforderungen erfüllen zu können. Hier wird definiert welche Benutzergruppen existieren, welche Geschäftsprozesse sich wie für die jeweiligen Benutzer verändern, sowie geeignete Metriken um diese Ziele zu erfassen. Die Benutzeranforderungen werden durch Geschäftsanalysten, Benutzer oder Vertretern der Benutzer, sowie Produktmanager definiert.

Funktionale Anforderungen

Erfassen das Verhalten, welches ein Softwaresystem besitzen soll, um die Benutzeranforderungen zu erfüllen. Funktionale Anforderungen werden durch Geschäftsanalysten und Produktmanager in Absprache mit der Softwareentwicklung und der Testabteilung definiert.

Projektanforderungen

Die für den Erfolg eines Projekts nötigen Anforderungen um die funktionalen Anforderungen umsetzen zu können und das Produkt im Zuge des Application Lifecycle Managements (ALM) betreuen zu können. Hierzu gehören beispielsweise:

• Hardware, Bereitstellungsumgebungen, Softwarelizenzen für Entwicklungswerkzeuge, Räumlichkeiten
• Mitarbeiter und Schulungen
• Dokumentation des Softwaresystems für Benutzer, Trainings und Supportmitarbeiter
• Qualitätsanforderungen und Service-Level-Agreements (SLAs)
• Rechtliche Anforderungen (u. a. Lizenzen, Patente, Markenrecht, Urheberrecht)

Aufgabe des Anforderungsmanagers ist es, die Anforderungen und Möglichkeiten gemeinsam mit den beteiligten Interessengruppen (z. B. Anwendern oder „Surrogate-Anwendern“, Kunden, sowie Product Owner und Entwicklungsteam) zu erheben und in eine für Softwareentwickler verständliche Form zu übertragen.^[2] Dies erfolgt formal in Form von User-Stories, welche in funktionale Anforderungen aufgeschlüsselt und, mit Hilfe eines Softwareentwicklers, nach Gherkin-Syntax übersetzt werden, sowie in Form von UML-Diagrammen, welche durch einen Softwarearchitekten genauer definiert werden.

Anforderungen, welche lediglich mündlich, durch Voicemail, auf Klebezetteln, E-Mails, Mitschriften von Meetings, oder ähnlich unstrukturiert erfasst sind, gehören nicht zum Anforderungskatalog des Softwaresystems, welche ein Entwickler umsetzen muss. Diese Anforderungen müssen erst durch den Geschäftsanalysten strukturiert erfasst werden.^[1]

Die Anforderung sieht ein Softwaresystem dabei als Black Box und definiert neben dem Zweck der einzelnen Teilanforderungen auch zugehörige Anwendungsbeispiele aus Sicht der unterschiedlichen Benutzergruppen.^[2]

Die Softwareanforderungen müssen in einer lebenden Dokumentation verwaltet werden. Um eine Nachvollziehbarkeit zu ermöglichen, sollte eine Versionsverwaltung eingesetzt werden. Auch sollte für Teilanforderungen ein Ansprechpartner und die zugehörigen Kontaktdaten bekannt sein. Es sollte zudem in einem Issue-Tracking-System erfasst werden, zu welchem Zeitpunkt, von welcher Interessengruppe und aus welchem Grund eine Anforderung gestellt und geändert wurde. Bei Programmfehlern und Änderungsanforderungen (change request) des Systems sollte sowohl Ist-Zustand und -Verhalten als auch Soll-Zustand und -Verhalten dokumentiert sein.

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

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.

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.^[2]

Weitere Schwierigkeiten ergeben sich dadurch, dass bei Spezifikationen im Üblichen:^[2]

• 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.^[3] Alleine im Jahr 2004 wurden in der Europäischen Union 142 Milliarden Euro aufgrund fehlgeschlagener Softwareprojekte verloren.^[4] 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.^[4] Zudem kommt, dass 30 % bis 50 % der Projektkosten durch Änderungen der Anforderungen und damit einhergehenden Produktänderungen entstehen.^[5][6] Von diesen Änderungen werden 70 % bis 85 % durch Fehler in der Anforderung verursacht.^[7]

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

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.

Softwareanforderungen umfassen:^[8]

• 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^[9]
  • 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,^[10] RFC 6919^[11])
  • 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

Eine implizite Softwareanforderung ist eine Anforderung die zwingend zu implementieren ist, jedoch nicht explizit vom Anforderungsmanagement spezifiziert wurde. Dies betrifft meist Anforderungen an die Testbarkeit (z. B. Testabdeckung durch Unit-Tests), die Sicherheit (z. B. Verschlüsselung) oder das Application Lifecycle Monitoring (z. B. Logging).

• Stephen Withall: Software Requirement Patterns (Developer Best Practices). Microsoft Press, 2007, ISBN 978-0-7356-2398-9 (englisch, 384 S.). 
• Karl E. Wiegers: Software Requirements (Developer Best Practices). 3. Auflage. Microsoft Press, 2013, ISBN 978-0-7356-7966-5 (englisch, 672 S.). 
• Karl E. Wiegers: More About Software Requirements: Thorny Issues and Practical Advice (Developer Best Practices). Microsoft Press, 2006, ISBN 0-7356-2267-1 (englisch, 224 S.). 
• Michael T. Nygard: Release It! Design and Deploy Production-Ready Software. O’Reilly, 2007, ISBN 978-0-9787392-1-8 (englisch, 326 S.). 
• Christine Rupp: Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil. Carl Hanser Verlag GmbH & Co. KG, 2014, ISBN 978-3-446-43893-4 (570 S.). 
• Ulrike Hammerschall, Gerd Beneken: Software Requirements. Pearson Studium, 2013, ISBN 978-3-86894-151-7 (432 S.). 
• Gojko Adzic: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. Neuri Limited, 2009, ISBN 978-0-9556836-1-9 (englisch, 284 S.). 
• 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, 86 S.). 

1. ↑ ^{a b c} Karl E. Wiegers: Software Requirements (Developer Best Practices). 3. Auflage. Microsoft Press, 2013, ISBN 978-0-7356-7966-5 (englisch, 672 S.). 
2. ↑ ^{a b c d e} Gojko Adzic: Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. Neuri Limited, 2009, ISBN 978-0-9556836-1-9 (englisch, 284 S.). 
3. ↑ Alan M. Davis: Just Enough Requirements Management: Where Software Development Meets Marketing. Computer Bookshops, 2005, ISBN 0-932633-64-1 (englisch, 240 S.). 
4. ↑ ^{a b} 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, 86 S.). 
5. ↑ Forrest Shull, Vic Basili, Barry Boehm, A. Winsor Brown, Patricia Costa, Mikael Lindvall, Dan Port, Ioana Rus, Roseanne Tesoriero, Marvin Zelkowitz: What We Have Learned About Fighting Defects. (PDF) Abgerufen am 12. Juni 2017 (englisch). 
6. ↑ Stronger Management Practices Are Needed to Improve DOD's Software-Intensive Weapon Acquisitions. U.S. Government Accountability Office (GAO), 1. März 2004, abgerufen am 12. Juni 2017 (englisch). 
7. ↑ Dean Leffingwell: Calculating the Return on Investment from More Effective Requirements Management. In: American Programmer. Institute for Software Quality (IFSQ), 1997, abgerufen am 12. Juni 2017 (englisch). 
8. ↑ Stephen Withall: Software Requirement Patterns (Developer Best Practices). Microsoft Press, 2007, ISBN 978-0-7356-2398-9 (englisch, 384 S.). 
9. ↑ User Impersonation. Auth0, ehemals im Original (nicht mehr online verfügbar); abgerufen am 10. April 2017 (englisch).@1@2Vorlage:Toter Link/auth0.com (Seite nicht mehr abrufbar. Suche in Webarchiven) 
10. ↑ RFC 2119 (englisch).
11. ↑ RFC 6919 (englisch).