www.wikidata.de-de.nina.az

Anforderung Informatik In der Software Technik ist eine Anforderung häufig englisch requirement eine Aussage über eine z

Anforderung (Informatik)

In der (Software-)Technik ist eine Anforderung (häufig englisch requirement) eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Produktes, Systems oder 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 Tabellenkalkulationssystem dokumentiert werden. In agiler Softwareentwicklung kommt Anforderungsmanagement-Software zum Einsatz, die das Anforderungsmanagement unterstützt (Backlog in Scrum, Jira etc.).

Arten von Anforderungen Bearbeiten

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 klassifiziert werden.

Am verbreitetsten ist die Unterteilung in funktionale und nichtfunktionale Anforderungen.

Eine funktionale Anforderung legt fest, was das Produkt tun soll. Ein Beispiel:

Eine nichtfunktionale Anforderung (englisch non-functional requirement, NFR) ist in der Literatur nicht einheitlich definiert. Gemeinsamer Nenner ist, dass sie über die funktionale Anforderung hinausgeht. Die nichtfunktionalen Anforderungen beschreiben, wie gut das System die Leistung erbringen soll; sie werden vielfach als Randbedingungen und Qualitätseigenschaften verstanden. Ein Beispiel:

Häufig werden neben diesen beiden Typen auch Randbedingungen (englisch 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 Bearbeiten

Während funktionale Anforderungen je nach Projekt unterschiedlich geordnet werden, gibt es für nichtfunktionale Anforderungen typische Gliederungen, beispielsweise Volere oder DIN 66272.

Nichtfunktionale Anforderungen können in zwei Hauptkategorien unterteilt werden:

Ausführungsqualität Bearbeiten

Dies ist während des Betriebs (zur Laufzeit) beobachtbar.

Weiterentwicklungsqualität / Evolutionsqualität Bearbeiten

Dies ist in der statischen Struktur des Systems verkörpert.

  • Betrieb und Umgebungsbedingungen
  • Wartbarkeit, Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit, Erweiterbarkeit)
  • Portierbarkeit und Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
  • Flexibilität (Unterstützung von Standards)
  • Skalierbarkeit (Änderungen des Problemumfangs bewältigen)
  • Randbedingungen

Struktur einer Anforderung Bearbeiten

Typischerweise besteht eine einzelne Anforderung aus folgenden Bestandteilen.

  • Identifikator (Requirement Number): Identifiziert die Anforderung eindeutig.
  • Beschreibung (Description): Beschreibt die Anforderung kurz und prägnant. Schienmann trennt Kurz- und Langbeschreibung („Anforderungsbeschreibung“), während Robertson und Robertson nur ein Feld vorsehen, das der Kurzbeschreibung entspricht.
  • Problembeschreibung (Rationale): Beschreibt das die Anforderung verursachende Problem.
  • Quelle (Originator): Identifiziert die anfordernde Person oder ein Dokument, aus dem sich die Anforderung ergibt, beispielsweise eine Rechtsvorschrift.
  • Abnahmekriterium (Fit Criterion): Beschreibt eine messbare Bedingung, mit der später geprüft wird, ob die Anforderung erfüllt wurde.

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.

  • Kundenzufriedenheit (Customer Satisfaction): Ein numerischer Wert, der angibt, wie sich die Erfüllung der Anforderung positiv auf die Zufriedenheit des Auftraggebers auswirkt.
  • Kundenunzufriedenheit (Customer Dissatisfaction): Ein numerischer Wert, der angibt, wie sich die Nichterfüllung der Anforderung negativ auf die Zufriedenheit des Auftraggebers auswirkt.
  • Priorität (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 (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.

  • Produktrelease: Identifiziert die 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 (Supporting Materials): Dokumente, die zum Verständnis der Anforderung benötigt werden.
  • Zielsetzung: Definiert das mit der Anforderung verfolgte Ziel.
  • Anmerkung: Bietet Platz für ergänzende Bemerkungen und Klarstellungen.
  • Nomenklatur: Verweist auf formal definierte Fachbegriffe, die in der Anforderung verwendet werden.

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

  • Versionsgeschichte (History) der Anforderung: Wann wurde sie von wem erstmals formuliert, wann von wem geändert usw.
  • Status: Identifiziert den aktuellen Zustand der Anforderung, beispielsweise ob sie vom Auftragnehmer bereits akzeptiert wurde.
  • Offener Punkt: Bietet Platz für noch zu klärende Sachverhalte.

Im Verlauf der Anforderungsanalyse werden auch Geschäftsprozesse und Geschäftsobjekte modelliert, die zur Formulierung von Anforderungen herangezogen werden können.

  • Geschäftsobjekt: Benennt ein Geschäftsobjekt, auf das sich die Anforderung bezieht.
  • Geschäftsprozess: Benennt einen von der Anforderung betroffenen Geschäftsprozess.

Außerdem stehen Anforderungen miteinander und mit anderen Artefakten des Entwicklungsprozesses in Beziehung (engl. Requirements Traceability).

  • Beziehung (engl. Trace Link): Verweist auf andere Anforderungen. Beispielsweise kann eine grobe Anforderung zu mehreren genaueren verfeinert werden oder Anforderungen stehen miteinander in Konflikt.

Siehe auch Bearbeiten

Einzelnachweise Bearbeiten

  1. ISO/IEC 25010 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models FINAL DRAFT. (PDF; 4,0 MB) Abgerufen am 24. März 2014.
  2. Suzanne Robertson, James Robertson: Mastering the Requirements Process. 2. Auflage. Addison-Wesley, Harlow 2006, ISBN 0-321-41949-9, S. 9–10.
  3. 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 [1]
  4. System-Entwicklung in der Wirtschaftsinformatik: vdf Hochschulverlag AG, 2002, ISBN 978-3-7281-2762-4, S. 139 [2]
  5. Martin Eigner, Florian Gerhardt, Torsten Gilz, Fabrice Mogo Nem: Informationstechnologie für Ingenieure, Springer-Verlag, 2012, ISBN 978-3-642-24893-1, S. 52 [3]
  6. Suzanne Robertson, James Robertson: Mastering the Requirements Process. 2. Auflage. Addison-Wesley, Harlow 2006, ISBN 0-321-41949-9, S. 171–201.
  7. Chris Rupp, Sophist Group: Requirements Engineering und -Management. Hanser, München 2001, ISBN 3-446-21664-2, S. 264.
  8. ↑ Bruno Schienmann: Kontinuierliches Anforderungsmanagement. Addison-Wesley, München 2002, ISBN 3-8273-1787-8, S. 151.
  9. ↑ Suzanne Robertson, James Robertson: Mastering the Requirements Process. S. 264.
  10. Orlena Gotel, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed: Traceability Fundamentals. In: Software and Systems Traceability. Springer London, 2012, ISBN 978-1-4471-2238-8, S. 3–22, doi:10.1007/978-1-4471-2239-5_1 (springer.com [abgerufen am 19. Dezember 2016]).
wikipedia, wiki, deutsches, deutschland, buch, bücher, bibliothek artikel lesen, herunterladen kostenlos kostenloser herunterladen, MP3, Video, MP4, 3GP, JPG, JPEG, GIF, PNG, Bild, Musik, Lied, Film, Buch, Spiel, Spiele
Veröffentlichungsdatum:
In der Software Technik ist eine Anforderung haufig englisch requirement eine Aussage uber eine zu erfullende Eigenschaft oder zu erbringende Leistung eines Produktes Systems oder Prozesses Anforderungen werden in der Anforderungserhebung aufgenommen analysiert spezifiziert und verifiziert Der Prozess ist in das Anforderungsmanagement eingebettet Anforderungen konnen beispielsweise in einem Dokument z B Lastenheft oder in einem Tabellenkalkulationssystem dokumentiert werden In agiler Softwareentwicklung kommt Anforderungsmanagement Software zum Einsatz die das Anforderungsmanagement unterstutzt Backlog in Scrum Jira etc Inhaltsverzeichnis 1 Arten von Anforderungen 1 1 Klassifikation nichtfunktionaler Anforderungen 1 1 1 Ausfuhrungsqualitat 1 1 2 Weiterentwicklungsqualitat Evolutionsqualitat 2 Struktur einer Anforderung 3 Siehe auch 4 EinzelnachweiseArten von Anforderungen BearbeitenEs existieren unterschiedliche Ansatze zur Klassifikation von Anforderungen Anforderungen als Qualitatskriterien an Systeme und Softwareprodukte verstanden konnen nach ISO IEC 25000 bzw entsprechend der Qualitatsmodelle aus ISO IEC 25010 1 klassifiziert werden Am verbreitetsten ist die Unterteilung in funktionale und nichtfunktionale Anforderungen Eine funktionale Anforderung legt fest was das Produkt tun soll 2 Ein Beispiel Das Produkt soll den Saldo eines Kontos zu einem Stichtag berechnen Eine nichtfunktionale Anforderung englisch non functional requirement NFR ist in der Literatur nicht einheitlich definiert Gemeinsamer Nenner ist dass sie uber die funktionale Anforderung hinausgeht 3 Die nichtfunktionalen Anforderungen beschreiben wie gut das System die Leistung erbringen soll 4 sie werden vielfach als Randbedingungen und Qualitatseigenschaften verstanden 5 Ein Beispiel Das Produkt soll dem Anwender innerhalb von einer Sekunde antworten Haufig werden neben diesen beiden Typen auch Randbedingungen englisch Constraints als Anforderungen beschrieben Haufige Randbedingungen sind eine Obergrenze fur Kosten und ein einzuhaltender Termin fur den Abschluss des Projekts Klassifikation nichtfunktionaler Anforderungen Bearbeiten Wahrend funktionale Anforderungen je nach Projekt unterschiedlich geordnet werden gibt es fur nichtfunktionale Anforderungen typische Gliederungen beispielsweise Volere 6 oder DIN 66272 7 Nichtfunktionale Anforderungen konnen in zwei Hauptkategorien unterteilt werden Ausfuhrungsqualitat Bearbeiten Dies ist wahrend des Betriebs zur Laufzeit beobachtbar Zuverlassigkeit Systemreife Wiederherstellbarkeit Fehlertoleranz Aussehen und Handhabung Look and Feel Benutzbarkeit Verstandlichkeit Erlernbarkeit Bedienbarkeit Leistung und Effizienz Antwortzeiten Ressourcenbedarf Wirtschaftlichkeit Sicherheitsanforderungen Vertraulichkeit Informationssicherheit Datenintegritat Verfugbarkeit Korrektheit Ergebnisse fehlerfrei Weiterentwicklungsqualitat Evolutionsqualitat Bearbeiten Dies ist in der statischen Struktur des Systems verkorpert Betrieb und Umgebungsbedingungen Wartbarkeit Anderbarkeit Analysierbarkeit Stabilitat Prufbarkeit Erweiterbarkeit Portierbarkeit und Ubertragbarkeit Anpassbarkeit Installierbarkeit Konformitat Austauschbarkeit Flexibilitat Unterstutzung von Standards Skalierbarkeit Anderungen des Problemumfangs bewaltigen RandbedingungenStruktur einer Anforderung BearbeitenTypischerweise besteht eine einzelne Anforderung aus folgenden Bestandteilen Identifikator Requirement Number Identifiziert die Anforderung eindeutig 8 9 Beschreibung Description Beschreibt die Anforderung kurz und pragnant Schienmann 8 trennt Kurz und Langbeschreibung Anforderungsbeschreibung wahrend Robertson und Robertson 9 nur ein Feld vorsehen das der Kurzbeschreibung entspricht Problembeschreibung Rationale Beschreibt das die Anforderung verursachende Problem 8 9 Quelle Originator Identifiziert die anfordernde Person oder ein Dokument aus dem sich die Anforderung ergibt beispielsweise eine Rechtsvorschrift 8 9 Abnahmekriterium Fit Criterion Beschreibt eine messbare Bedingung mit der spater gepruft wird ob die Anforderung erfullt wurde 8 9 Neben diesen Standardbestandteilen schlagen verschiedene Autoren zusatzliche 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 Verfugung stehenden Ressourcen Zeit Geld und Personen nicht ausreichen um alle Anforderungen zu erfullen Hier schlagen Robertson und Robertson in ihrem Vorgehensmodell Volere die folgenden Eigenschaften vor 9 Kundenzufriedenheit Customer Satisfaction Ein numerischer Wert der angibt wie sich die Erfullung der Anforderung positiv auf die Zufriedenheit des Auftraggebers auswirkt Kundenunzufriedenheit Customer Dissatisfaction Ein numerischer Wert der angibt wie sich die Nichterfullung der Anforderung negativ auf die Zufriedenheit des Auftraggebers auswirkt Prioritat Priority Ein numerischer Wert der die Prioritat dieser Anwendung definiert und dann wichtig wird wenn nicht alle Anforderungen erfullt werden konnen Konflikte Conflicts Hier konnen Anforderungen aufgefuhrt werden die dieser Anforderung widersprechen sodass zwischen ihnen abgewagt werden muss Schienmann schlagt folgende Eigenschaften vor um die Anforderungen bestimmten Software Produkten zuzuordnen 8 Produktrelease Identifiziert die Version des zu erstellenden Produkts in dem die Anforderung erfullt werden soll Baustein Identifiziert den Teil des zu erstellenden Produkts mit dem die Anforderung erfullt werden soll Die eigentliche Beschreibung der Anforderung kann durch folgende Elemente unterstutzt werden und somit das Verstandnis gefordert und Missverstandnisse vermieden werden Weiterfuhrendes Material Supporting Materials Dokumente die zum Verstandnis der Anforderung benotigt werden 9 Zielsetzung Definiert das mit der Anforderung verfolgte Ziel 8 Anmerkung Bietet Platz fur erganzende Bemerkungen und Klarstellungen 8 Nomenklatur Verweist auf formal definierte Fachbegriffe die in der Anforderung verwendet werden 8 Da Anforderungen nicht konstant bleiben sondern sich im Verlauf eines Projektes weiterentwickeln werden auch Informationen zu ihrem Lebenszyklus benotigt Versionsgeschichte History der Anforderung Wann wurde sie von wem erstmals formuliert wann von wem geandert usw 9 Status Identifiziert den aktuellen Zustand der Anforderung beispielsweise ob sie vom Auftragnehmer bereits akzeptiert wurde 8 Offener Punkt Bietet Platz fur noch zu klarende Sachverhalte 8 Im Verlauf der Anforderungsanalyse werden auch Geschaftsprozesse und Geschaftsobjekte modelliert die zur Formulierung von Anforderungen herangezogen werden konnen Geschaftsobjekt Benennt ein Geschaftsobjekt auf das sich die Anforderung bezieht 8 Geschaftsprozess Benennt einen von der Anforderung betroffenen Geschaftsprozess 8 Ausserdem stehen Anforderungen miteinander und mit anderen Artefakten des Entwicklungsprozesses in Beziehung engl Requirements Traceability Beziehung engl Trace Link Verweist auf andere Anforderungen Beispielsweise kann eine grobe Anforderung zu mehreren genaueren verfeinert werden oder Anforderungen stehen miteinander in Konflikt 8 10 Siehe auch BearbeitenBusiness Analyse Spezifikation Software Requirements SpecificationEinzelnachweise Bearbeiten ISO IEC 25010 Systems and software engineering Systems and software Quality Requirements and Evaluation SQuaRE System and software quality models FINAL DRAFT PDF 4 0 MB Abgerufen am 24 Marz 2014 Suzanne Robertson James Robertson Mastering the Requirements Process 2 Auflage Addison Wesley Harlow 2006 ISBN 0 321 41949 9 S 9 10 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 1 System Entwicklung in der Wirtschaftsinformatik vdf Hochschulverlag AG 2002 ISBN 978 3 7281 2762 4 S 139 2 Martin Eigner Florian Gerhardt Torsten Gilz Fabrice Mogo Nem Informationstechnologie fur Ingenieure Springer Verlag 2012 ISBN 978 3 642 24893 1 S 52 3 Suzanne Robertson James Robertson Mastering the Requirements Process 2 Auflage Addison Wesley Harlow 2006 ISBN 0 321 41949 9 S 171 201 Chris Rupp Sophist Group Requirements Engineering und Management Hanser Munchen 2001 ISBN 3 446 21664 2 S 264 a b c d e f g h i j k l m n Bruno Schienmann Kontinuierliches Anforderungsmanagement Addison Wesley Munchen 2002 ISBN 3 8273 1787 8 S 151 a b c d e f g h Suzanne Robertson James Robertson Mastering the Requirements Process S 264 Orlena Gotel Jane Cleland Huang Jane Huffman Hayes Andrea Zisman Alexander Egyed Traceability Fundamentals In Software and Systems Traceability Springer London 2012 ISBN 978 1 4471 2238 8 S 3 22 doi 10 1007 978 1 4471 2239 5 1 springer com abgerufen am 19 Dezember 2016 Abgerufen von https de wikipedia org w index php title Anforderung Informatik amp oldid 228450111