imported>Syroger: /* Siehe auch */ Interne Verlinkung ergänzt

2024-01-15T18:22:45Z

Siehe auch: Interne Verlinkung ergänzt

Neue Seite

In der (Software-)Technik ist eine '''Anforderung''' (häufig {{enS|requirement}}) eine Aussage über eine zu erfüllende [[Eigenschaft]] oder zu erbringende Leistung eines [[Produkt (Wirtschaft)|Produktes]], [[System]]s oder [[Geschäftsprozess|Prozesses]].

Anforderungen werden in der [[Anforderungserhebung]] aufgenommen, analysiert, spezifiziert und verifiziert. Der Prozess ist in das [[Anforderungsmanagement]] eingebettet. Anforderungen können beispielsweise in einem Dokument (z. B. [[Lastenheft]]) oder in einem [[Tabellenkalkulation]]ssystem dokumentiert werden. In [[Agile Softwareentwicklung|agiler Softwareentwicklung]] kommt [[Anforderungsmanagement-Software]] zum Einsatz, die das Anforderungsmanagement unterstützt ([[Scrum#Product Backlog|Backlog in Scrum]], [[Jira (Software)|Jira]] etc.).

== Arten von Anforderungen ==
Es existieren unterschiedliche Ansätze zur Klassifikation von Anforderungen.

Anforderungen – als Qualitätskriterien an Systeme und Softwareprodukte verstanden – können nach [[ISO/IEC 25000]], bzw. entsprechend der Qualitätsmodelle aus ISO/IEC 25010<ref>{{Internetquelle |url=http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=35733 |titel=ISO/IEC 25010 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models FINAL DRAFT |abruf=2014-03-24 |format=PDF; 4,0 MB}}</ref> klassifiziert werden.

Am verbreitetsten ist die Unterteilung in ''funktionale'' und ''nichtfunktionale'' Anforderungen.

Eine {{Anker|FA}}'''funktionale Anforderung''' legt fest, was das Produkt tun soll.<ref name="robertson">{{Literatur |Autor=Suzanne Robertson, James Robertson |Titel=Mastering the Requirements Process |Auflage=2. |Verlag=Addison-Wesley |Ort=Harlow |Datum=2006 |ISBN=0-321-41949-9 |Seiten=9–10}}</ref> Ein Beispiel:
:„Das Produkt soll den Saldo eines Kontos zu einem Stichtag berechnen.“

Eine {{Anker|NFA}}'''nichtfunktionale Anforderung''' (englisch ''{{lang|en|non-functional requirement}}'', NFR) ist in der Literatur nicht einheitlich definiert. Gemeinsamer Nenner ist, dass sie über die funktionale Anforderung hinausgeht.<ref>Chris Rupp: ''Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil'', Carl Hanser Verlag GmbH Co KG, 2014, ISBN 978-3-446-44313-6, S. 268–269 [https://books.google.de/books?id=pJKqBAAAQBAJ&pg=PA268]</ref> Die nichtfunktionalen Anforderungen beschreiben, wie gut das System die Leistung erbringen soll<ref>''System-Entwicklung in der Wirtschaftsinformatik'': vdf Hochschulverlag AG, 2002, ISBN 978-3-7281-2762-4, S. 139 [https://books.google.de/books?id=jq0JhnI-TwkC&pg=PA139]</ref>; sie werden vielfach als Randbedingungen und [[Softwarequalität|Qualitätseigenschaften]] verstanden.<ref>Martin Eigner, Florian Gerhardt, Torsten Gilz, Fabrice Mogo Nem: ''Informationstechnologie für Ingenieure'', Springer-Verlag, 2012, ISBN 978-3-642-24893-1, S. 52 [https://books.google.de/books?id=Pn9kvFIO30UC&pg=PA52]</ref> Ein Beispiel:
:„Das Produkt soll dem Anwender innerhalb von einer Sekunde antworten.“

Häufig werden neben diesen beiden Typen auch Randbedingungen (englisch ''{{lang|en|Constraints}}'') als Anforderungen beschrieben. Häufige Randbedingungen sind eine Obergrenze für [[Kosten]] und ein einzuhaltender [[Termin]] für den Abschluss des Projekts.

=== Klassifikation nichtfunktionaler Anforderungen ===
Während funktionale Anforderungen je nach Projekt unterschiedlich geordnet werden, gibt es für nichtfunktionale Anforderungen typische Gliederungen, beispielsweise [[Volere]]<ref>{{Literatur |Autor=Suzanne Robertson, James Robertson |Titel=Mastering the Requirements Process |Auflage=2. |Verlag=Addison-Wesley |Ort=Harlow |Datum=2006 |ISBN=0-321-41949-9 |Seiten=171–201}}</ref> oder [[DIN 66272]].<ref>{{Literatur |Autor=Chris Rupp, Sophist Group |Titel=Requirements Engineering und -Management |Verlag=Hanser |Ort=München |Datum=2001 |ISBN=3-446-21664-2 |Seiten=264}}</ref>

Nichtfunktionale Anforderungen können in zwei Hauptkategorien unterteilt werden:

==== Ausführungsqualität ====
Dies ist während des Betriebs (zur Laufzeit) beobachtbar.

* [[Zuverlässigkeit (Technik)|Zuverlässigkeit]] (Systemreife, Wiederherstellbarkeit, Fehlertoleranz)
* Aussehen und Handhabung ([[Look and Feel]])
* [[Gebrauchstauglichkeit (Produkt)|Benutzbarkeit]] (Verständlichkeit, Erlernbarkeit, Bedienbarkeit)
* [[Leistung (Informatik)|Leistung]] und [[Effizienz (Informatik)|Effizienz]] (Antwortzeiten, Ressourcenbedarf, Wirtschaftlichkeit)
* Sicherheitsanforderungen (Vertraulichkeit, [[Informationssicherheit]], Datenintegrität, [[Verfügbarkeit]])
* [[Korrektheit (Informatik)|Korrektheit]] (Ergebnisse fehlerfrei)

==== Weiterentwicklungsqualität / Evolutionsqualität ====
Dies ist in der statischen Struktur des Systems verkörpert.
* Betrieb und Umgebungsbedingungen
* [[Wartbarkeit]], Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit, Erweiterbarkeit)
* [[Plattformunabhängigkeit|Portierbarkeit]] und [[Übertragbarkeit]] (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
* Flexibilität (Unterstützung von Standards)
* [[Skalierbarkeit]] (Änderungen des Problemumfangs bewältigen)
* Randbedingungen

== Struktur einer Anforderung ==
Typischerweise besteht eine einzelne Anforderung aus folgenden Bestandteilen.
* Identifikator ''({{lang|en|Requirement Number}}):'' Identifiziert die Anforderung eindeutig.<ref name="Schienmann">{{Literatur |Autor=Bruno Schienmann |Titel=Kontinuierliches Anforderungsmanagement |Verlag=Addison-Wesley |Ort=München |Datum=2002 |ISBN=3-8273-1787-8 |Seiten=151}}</ref><ref name="volere">{{Literatur |Autor=Suzanne Robertson, James Robertson |Titel=Mastering the Requirements Process |Datum= |Seiten=264}}</ref>
* Beschreibung ''({{lang|en|Description}}):'' Beschreibt die Anforderung kurz und prägnant. Schienmann<ref name="Schienmann" /> trennt Kurz- und Langbeschreibung („Anforderungsbeschreibung“), während Robertson und Robertson<ref name="volere" /> nur ein Feld vorsehen, das der Kurzbeschreibung entspricht.
* Problembeschreibung ''({{lang|en|Rationale}}):'' Beschreibt das die Anforderung verursachende Problem.<ref name="Schienmann" /><ref name="volere" />
* Quelle ''({{lang|en|Originator}}):'' Identifiziert die anfordernde Person oder ein Dokument, aus dem sich die Anforderung ergibt, beispielsweise eine Rechtsvorschrift.<ref name="Schienmann" /><ref name="volere" />
* Abnahmekriterium ''({{lang|en|Fit Criterion}}):'' Beschreibt eine messbare Bedingung, mit der später geprüft wird, ob die Anforderung erfüllt wurde.<ref name="Schienmann" /><ref name="volere" />
Neben diesen Standardbestandteilen schlagen verschiedene Autoren zusätzliche Strukturelemente vor. Eine wichtige Rolle spielt dabei die Priorisierung von miteinander konkurrierenden Anforderungen um die Reihenfolge der Realisierung festzulegen oder eine Auswahl zu treffen, wenn die zur Verfügung stehenden Ressourcen (Zeit, Geld und Personen) nicht ausreichen, um alle Anforderungen zu erfüllen. Hier schlagen Robertson und Robertson in ihrem Vorgehensmodell [[Volere]] die folgenden Eigenschaften vor.<ref name="volere" />
* Kundenzufriedenheit ''({{lang|en|Customer Satisfaction}}):'' Ein numerischer Wert, der angibt, wie sich die Erfüllung der Anforderung positiv auf die Zufriedenheit des Auftraggebers auswirkt.
* Kundenunzufriedenheit ''({{lang|en|Customer Dissatisfaction}}):'' Ein numerischer Wert, der angibt, wie sich die Nichterfüllung der Anforderung negativ auf die Zufriedenheit des Auftraggebers auswirkt.
* Priorität ''({{lang|en|Priority}}):'' Ein numerischer Wert, der die Priorität dieser Anwendung definiert und dann wichtig wird, wenn nicht alle Anforderungen erfüllt werden können.
* Konflikte ''({{lang|en|Conflicts}}):'' Hier können Anforderungen aufgeführt werden, die dieser Anforderung widersprechen, sodass zwischen ihnen abgewägt werden muss.

Schienmann schlägt folgende Eigenschaften vor, um die Anforderungen bestimmten (Software-)Produkten zuzuordnen.<ref name="Schienmann" />
* Produktrelease: Identifiziert die [[Entwicklungsstadium (Software)|Version]] des zu erstellenden Produkts, in dem die Anforderung erfüllt werden soll.
* Baustein: Identifiziert den Teil des zu erstellenden Produkts, mit dem die Anforderung erfüllt werden soll.

Die eigentliche Beschreibung der Anforderung kann durch folgende Elemente unterstützt werden und somit das Verständnis gefördert und Missverständnisse vermieden werden.
* Weiterführendes Material ''({{lang|en|Supporting Materials}}):'' Dokumente, die zum Verständnis der Anforderung benötigt werden.<ref name="volere" />
* Zielsetzung: Definiert das mit der Anforderung verfolgte Ziel.<ref name="Schienmann" />
* Anmerkung: Bietet Platz für ergänzende Bemerkungen und Klarstellungen.<ref name="Schienmann" />
* Nomenklatur: Verweist auf formal definierte Fachbegriffe, die in der Anforderung verwendet werden.<ref name="Schienmann" />

Da Anforderungen nicht konstant bleiben, sondern sich im Verlauf eines Projektes weiterentwickeln, werden auch Informationen zu ihrem Lebenszyklus benötigt.
* Versionsgeschichte ''({{lang|en|History}})'' der Anforderung: Wann wurde sie von wem erstmals formuliert, wann von wem geändert usw.<ref name="volere" />
* Status: Identifiziert den aktuellen Zustand der Anforderung, beispielsweise ob sie vom Auftragnehmer bereits akzeptiert wurde.<ref name="Schienmann" />
* Offener Punkt: Bietet Platz für noch zu klärende Sachverhalte.<ref name="Schienmann" />

Im Verlauf der [[Anforderungserhebung|Anforderungsanalyse]] werden auch [[Geschäftsprozess]]e und [[Geschäftsobjekt]]e modelliert, die zur Formulierung von Anforderungen herangezogen werden können.
* Geschäftsobjekt: Benennt ein Geschäftsobjekt, auf das sich die Anforderung bezieht.<ref name="Schienmann" />
* Geschäftsprozess: Benennt einen von der Anforderung betroffenen [[Geschäftsprozess]].<ref name="Schienmann" />
Außerdem stehen Anforderungen miteinander und mit anderen Artefakten des Entwicklungsprozesses in [[Rückverfolgbarkeit (Anforderungsmanagement)|Beziehung]] (engl. Requirements Traceability).
* [[Rückverfolgbarkeit (Anforderungsmanagement)|Beziehung]] (engl. Trace Link): Verweist auf andere Anforderungen. Beispielsweise kann eine grobe Anforderung zu mehreren genaueren verfeinert werden oder Anforderungen stehen miteinander in Konflikt.<ref name="Schienmann" /><ref>{{Literatur |Autor=Orlena Gotel, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed |Titel=Traceability Fundamentals |Sammelwerk=Software and Systems Traceability |Verlag=Springer London |Datum=2012 |ISBN=978-1-4471-2238-8 |Seiten=3–22 |Online=http://link.springer.com/chapter/10.1007/978-1-4471-2239-5_1 |Abruf=2016-12-19 |DOI=10.1007/978-1-4471-2239-5_1}}</ref>

== Siehe auch ==
* [[Business-Analyse]]
* [[Nutzungsanforderung|Nutzungsanforderungen]] ([[Human-centered design|Human-Centered Design]])
* [[Spezifikation]]
* [[Software Requirements Specification]]

== Einzelnachweise ==
<references />

[[Kategorie:Softwaretechnik]]
[[Kategorie:Anforderungsmanagement]]

[[ca:Requisit (enginyeria)]]
[[es:Requisito (sistemas)]]
[[fr:Exigence (ingénierie)]]
[[ja:要求仕様]]
[[nl:Requirement]]
[[pl:Wymaganie (inżynieria)]]
[[pt:Requisito]]
[[ru:Требование]]
[[vi:Yêu cầu (kỹ thuật)]]

Anforderung (Informatik) - Versionsgeschichte

imported>Syroger: /* Siehe auch */ Interne Verlinkung ergänzt