Zum Inhalt springen

Softwareanforderung

aus Wikipedia, der freien Enzyklopädie

Vorlage:Hinweisbaustein

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

Arten von Softwareanforderungen[Bearbeiten]

Grundsätzlich unterscheidet man bei Softwareanforderungen zwischen:<ref name="softwarerequirements" />

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:

Format[Bearbeiten]

Datei:Softwareanforderungsprozess.svg
Softwareanforderungsprozess

Aufgabe des Anforderungsmanagers ist es, die Anforderungen und Möglichkeiten gemeinsam mit den beteiligten Interessengruppen (z. B. Anwendern oder „Surrogate-Anwendern“, Kunden, Product Owner und Entwicklungsteam) zu erheben und in eine für Softwareentwickler verständliche Form zu übertragen.<ref name="gap" /> Dies erfolgt beispielsweise formal in Form von User-Stories, Feature Dateien oder UML-Diagrammen.

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.<ref name="softwarerequirements" />

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.<ref name="gap" />

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 ({{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value)) des Systems sollte sowohl Ist-Zustand und -Verhalten als auch Soll-Zustand und -Verhalten dokumentiert sein.

Softwareanforderung aus Kundensicht[Bearbeiten]

In dem Buch Software Requirements definiert Karl Wiegers Rechte und Pflichten des Kunden, welche bei der Erstellung von Anforderungen eingehalten werden sollen:<ref name="softwarerequirements" />

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[Bearbeiten]

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.<ref name="gap" />

Weitere Schwierigkeiten ergeben sich dadurch, dass bei Spezifikationen im Üblichen:<ref name="gap" />

  • 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.<ref name="jerm" /> Alleine im Jahr 2004 wurden in der Europäischen Union 142 Milliarden Euro aufgrund fehlgeschlagener Softwareprojekte verloren.<ref name="impactmapping" /> 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.<ref name="impactmapping" /> Zudem kommt, dass 30 % bis 50 % der Projektkosten durch Änderungen der Anforderungen und damit einhergehenden Produktänderungen entstehen.<ref name="fightingdefects" /><ref name="gao" /> Von diesen Änderungen werden 70 % bis 85 % durch Fehler in der Anforderung verursacht.<ref name="roi" />

Agile Softwareentwicklung reduziert diese Probleme mittels einer regelmäßigen Kommunikation der Interessengruppen, ist jedoch von denselben Effekten betroffen.<ref name="gap" />

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[Bearbeiten]

Softwareanforderungen umfassen:<ref name="srp" />

  • Programmierschnittstellen
    • Beschreibungen (englisch: {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value))
    • Verhalten
    • Bindung (englisch: {{Modul:Vorlage:lang}} Modul:Multilingual:153: attempt to index field 'data' (a nil value); 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
  • 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
  • Berichterstellung
  • Anforderungen an das Product-Lifecycle-Management (PLM)
  • 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
  • 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,<ref>Vorlage:RFC-Internet</ref> RFC 6919<ref>Vorlage:RFC-Internet</ref>)
    • 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

Implizite Softwareanforderung[Bearbeiten]

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).

Literatur[Bearbeiten]

Einzelnachweise[Bearbeiten]

<references> <ref name="srp"> </ref> <ref name="gap"> </ref> <ref name="softwarerequirements"> </ref> <ref name="jerm"> </ref> <ref name="impactmapping"> </ref> <ref name="fightingdefects"> 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 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)). </ref> <ref name="gao"> 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 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)). </ref> <ref name="roi"> 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 (Lua-Fehler in Modul:Multilingual, Zeile 153: attempt to index field 'data' (a nil value)). </ref> </references>

Abgerufen von „https://wiki.kertz.ch/index.php?title=Softwareanforderung&oldid=3933581“