Anforderung (Informatik)

aus Wikipedia, der freien Enzyklopädie

In der (Software-)Technik ist eine Anforderung (häufig engl. requirement) eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Produktes, Systems oder Prozesses. Anforderungen werden üblicherweise in einem Lastenheft zusammengefasst, können in der Realität aber auch in nahezu beliebigen anderen Dokumenten zu finden sein, oder sind nicht dokumentiert.

Inhaltsverzeichnis 1 Anforderungsdefinition (Prozess) 2 Arten von Anforderungen 2.1 Klassifikation nichtfunktionaler Anforderungen 3 Struktur einer Anforderung 4 Einzelnachweise 5 Siehe auch

[Bearbeiten] Anforderungsdefinition (Prozess)

Die Anforderungsdefinition folgt auf den Schritt der Anforderungsanalyse und stellt somit den zweiten Schritt in einem Entwicklungsprozess dar, auf dem die komplette nachfolgende Entwicklung aufbaut. Es ist deshalb enorm wichtig genügend Projektzeit dafür einzuplanen: Jeder Fehler, der hier gemacht wird, benötigt zur Korrektur ein Vielfaches der Zeit, die es kostet, eine umsichtige Anforderungsdefinition zu erstellen.

In dem so mit dem Kunden entstandenen Anforderungsdokument müssen die Aufgaben, die das zu entwickelnde System aus Hardware und/oder Software lösen soll, die zu erreichenden Ziele des Entwicklungsprojekts sowie der Benutzerkreis für den das System entwickelt wird, festgehalten sein.

Das so aus der Anforderungsdefinition hervorgegangene Anforderungsdokument (Konsens) ist Grundlage für das Softwaredesign.

Auch in Deutschland verwendet man oft den englischen Begriff Requirement und bezeichnet die damit verbundenen Aktivitäten als Requirements Management und Requirements Engineering.

[Bearbeiten] Arten von Anforderungen

Es existieren unterschiedliche Ansätze zur Klassifikation von Anforderungen. Am verbreitetsten ist die Unterteilung in funktionale und nicht funktionale Anforderungen.

Eine funktionale Anforderung legt fest, was das Produkt tun soll.^[1] Ein Beispiel:

„Das Produkt soll den Saldo eines Kontos zu einem Stichtag berechnen.“

Eine nichtfunktionale Anforderung legt fest, welche Eigenschaften das Produkt haben soll.^[1] Ein Beispiel:

„Das Produkt soll dem Anwender innerhalb von einer Sekunde antworten.“

Häufig werden neben diesen beiden Typen auch Randbedingungen (englisch Constraints) als Anforderungen beschrieben. Häufige Randbedingungen sind eine Obergrenze für Kosten und eine einzuhaltender Termin für den Abschluss des Projekts..

[Bearbeiten] Klassifikation nichtfunktionaler Anforderungen

Während funktionale Anforderungen je nach Projekt unterschiedlich geordnet werden, gibt es für nichtfunktionale Anforderungen typische Gliederungen, beispielsweise Volere^[2] oder DIN 66272^[3]. Die folgende Liste zeigt typische Arten nichtfunktionaler Anforderungen.

• Zuverlässigkeit (Systemreife, Wiederherstellbarkeit, Fehlertoleranz)
• Aussehen und Handhabung (Look and Feel)
• Benutzbarkeit (Verständlichkeit, Erlernbarkeit, Bedienbarkeit)
• Leistung und Effizienz (Antwortzeiten, Ressourcenbedarf)
• Betrieb und Umgebungsbedingungen
• Wartbarkeit, Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit)
• Portierbarkeit und Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
• Sicherheitsanforderungen (Vertraulichkeit, Datenintegrität, Verfügbarkeit)
• kulturelle und politische Anforderungen
• rechtliche Anforderungen

[Bearbeiten] Struktur einer Anforderung

Typischerweise besteht eine einzelne Anforderung aus folgenden Bestandteilen.

Identifikator (Requirement Number)

Identifiziert die Anforderung eindeutig.^[4][5]

Beschreibung (Description)

Beschreibt die Anforderung kurz und prägnant. Schienmann^[4] trennt Kurz- und Langbeschreibung („Anforderungsbeschreibung“), während Robertson und Robertson^[5] nur ein Feld vorsehen, das der Kurzbeschreibung entspricht.

Problembeschreibung (Rationale)

Beschreibt das die Anforderung verursachende Problem.^[4][5]

Quelle (Originator)

Identifiziert die anfordernde Person oder ein Dokument, aus dem sich die Anforderung ergibt, beispielsweise eine Rechtsvorschrift.^[4][5]

Abnahmekriterium (Fit Criterion)

Beschreibt eine messbare Bedingung, mit der später geprüft wird, ob die Anforderung erfüllt wurde.^[4][5]

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

Customer Satisfaction („Kundenzufriedenheit“)

Ein nummerischer Wert, der angibt, wie sich die Erfüllung der Anforderung positiv auf die Zufriedenheit des Auftraggebers auswirkt.

Customer Dissatisfaction („Kundenunzufriedenheit“)

Ein nummerischer Wert, der angibt, wie sich die Nichterfüllung der Anforderung negativ auf die Zufriedenheit des Auftraggebers auswirkt.

Priority („Priorität“)

Ein nummerischer Wert, der die Priorität dieser Anwendung definiert und dann wichtig wird, wenn nicht alle Anforderungen erfüllt werden können.

Conflicts („Konflikte“)

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

Produktrelease

Identifiziert die Version des zu erstellenden Produkts, in dem die Anforderung erfüllt werden soll.

Software-Baustein

Identifiziert den Teil der zu erstellenden Software, 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.

Supporting Materials

(„weiterführendes Material“) Dokumente, die zum Verständnis der Anforderung benötigt werden.^[5]

Zielsetzung

Definiert das mit der Anforderung verfolgte Ziel.^[4]

Anmerkung

Bietet Platz für ergänzende Bemerkungen und Klarstellungen.^[4]

Nomenklatur

Verweist auf formal definierte Fachbegriffe, die in der Anforderung verwendet werden.^[4]

Da Anforderungen nicht konstant bleiben, sondern sich im Verlauf eines Projektes weiterentwickeln, werden auch Informationen zu ihrem Lebenszyklus benötigt.

History

Versionsgeschichte der Anforderung: Wann wurde sie von wem erstmals formuliert, wann von wem geändert usw.^[5]

Status

Identifiziert den aktuellen Zustand der Anforderung, beispielsweise ob sie vom Auftragnehmer bereits akzeptiert wurde.^[4]

Offener Punkt

Bietet Platz für noch zu klärende Sachverhalte.^[4]

Im Verlauf der Anforderungsanalyse werden auch Geschäftsprozesse und Geschäftsobjekte modelliert, die zur Formulierung von Anforderungen herangezogen werden können. Außerdem stehen Anforderungen miteinander in Beziehung.

Geschäftsobjekt

Benennt ein in der Anforderungsanalyse beschriebenes Geschäftsobjekt, auf das sich die Anforderung bezieht.^[4]

Geschäftsprozess

Benennt einen von der Anforderung betroffenen Geschäftsprozess.^[4]

Beziehung

Verweist auf andere Anforderungen. Beispielsweise kann eine grobe Anforderung zu mehreren genaueren verfeinert werden.^[4]

[Bearbeiten] Einzelnachweise

1. ↑ ^{a b} Suzanne Robertson, James Robertson: Mastering the Requirements Process. 2. Auflage. Addison Wesley, Harlow 2006, ISBN 0-321-41949-9, S. 9–10.
2. ↑ Suzanne Robertson, James Roberson: Mastering the Requirements Process. 2. Auflage. Addison-Wesley, Harlow 2006, ISBN 0-321-41949-9, S. 171–201.
3. ↑ Chris Rupp, Sophist Group: Requirements Engineering und -Management. Hanser, München 2001, ISBN 3-446-21664-2, S. 264.
4. ↑ ^{a b c d e f g h i j k l m n} Bruno Schienmann: Kontinuierliches Anforderungsmanagement. Addison-Wesley, München 2002, ISBN 3-8273-1787-8, S. 151.
5. ↑ ^{a b c d e f g h} Suzanne Robertson, James Roberson: Mastering the Requirements Process. S. 264.

[Bearbeiten] Siehe auch

• Spezifikation
• Software Requirements Specification