Anforderungsentwicklung

Anforderungsentwicklung

Das Erheben der Anforderungen (englisch requirements engineering) ist ein Teil des Anforderungsmanagements im Systementwicklungsprozesses. Ziel ist es, die Anforderungen des Auftraggebers an das zu entwickelnde System zu ermitteln.

Inhaltsverzeichnis

Definitionen

IEEE

Laut IEEE kann die Anforderungserhebung in Anforderungsaufnahme (requirements elicitation), Anforderungsanalyse (requirements analysis), Anforderungsspezifikation (requirements specification) und Anforderungsbewertung (requirements validation) unterteilt werden.[1] Diese Schritte überlappen einander und werden oft auch mehrfachiterativdurchgeführt.

SEI, Carnegie Mellon

Das Software Engineering Institute der Carnegie Mellon Universität unterscheidet in ihrem Capability Maturity Model Integration das Management von Anforderungen, und die Entwicklung der Anforderungen [2][3].

Volere

In dem von den Robertsons entwickelten Vorgehensmodell Volere existieren Anforderungsspezifikation, Stakeholder-Analyse, Bedarfsanalyse, Analyse der Priorisierung und die Aufzeichnung der elementaren Anforderungen [4].

Vorgehen

In allen oben genannten Modellen existieren die folgenden Schritte in der einen oder anderen Form. Dabei werden Anforderungen gesammelt (englisch elicitation), es soll durch Analyse ein gemeinsames Verständnis hergestellt werden, die Anforderungen müssen niedergeschrieben oder in Modellen niedergelegt, dh. spezifiziert werden. Danach wird üblicherweise geprüft, ob das Ganze noch stimmig ist (englisch validation). Rund um diese Schritte existiert eine Verwaltung des Prozesses, das Management.

Sammeln, Analysieren

Beim Sammeln der Anforderungen (engl. elicitation) ist der Übersetzungsprozess zwischen Fachseite und Entwickler von besonderer Bedeutung. Folgende Kriterien sind zu erfüllen:

  • vollständigalle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.
  • eindeutig definiert / abgegrenztpräzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.
  • verständlich beschriebendamit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamte Anforderung lesen und verstehen können.
  • atomares darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für einAtomsollte die Entscheidbarkeit einer Anforderung sein.
  • identifizierbarjede Anforderung muss eindeutig identifizierbar sein (zB. über eine Kennung oder Nummer).
  • einheitlich dokumentiertdie Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.
  • notwendiggesetzliche Vorschriften sind unabdingbar.
  • nachprüfbardie Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden. Testfälle werden aus den Abnahmekriterien abgeleitet. Siehe auch Verifizierung.
  • rück- und vorwärtsverfolgbardamit einerseits erkennbar ist, ob jede Anforderung vollständig erfüllt wurde und andererseits für jede implementierte Funktionalität erkennbar ist, aus welcher Anforderung sie resultiert, also nicht Überflüssiges entwickelt wird. Siehe Rückverfolgbarkeit (Anforderungsmanagement).
  • KonsistenzKonsistenz beschreibt den Grad, in dem die definierten Anforderungen untereinander widerspruchsfrei sind.

Das Ergebnis der Anforderungsaufnahme ist das Lastenheft.

Strukturierung und Abstimmung

Nach der Erfassung muss eine Strukturierung und Klassifizierung der Anforderungen vorgenommen werden. Damit erreicht man, dass die Anforderungen übersichtlicher werden. Dies wiederum erhöht das Verständnis von den Beziehungen zwischen den Anforderungen. Kriterien sind hierbei:

  • abhängigAnforderungen müssen daraufhin überprüft werden, ob sie sich nur gemeinsam realisieren lassen oder ob eine Anforderung die Voraussetzung für eine andere ist.
  • zusammengehörigAnforderungen, die fachlich-logisch zusammengehören, sollten nicht allein realisiert werden.
  • rollenbezogenjede Benutzergruppe hat ihre eigene Sicht auf die Anforderungen, die damit unterstützt werden soll. Siehe Benutzerrolle.

Weitere Strukturierungsmöglichkeiten sind

  • Funktionale und nichtfunktionale Anforderungen
  • Fachlich motivierte (fachliche und technische) und technisch motivierte (nur technische) Anforderungen.

Die so strukturierten Anforderungen müssen dann zwischen Kunde und Entwickler abgestimmt werden. Diese Abstimmung kann gegebenenfalls zu einem iterativen Prozess werden, der zur Verfeinerung der Anforderungen führt.

Prüfung und Bewertung

Nach der Strukturierung, zum Teil auch parallel dazu, erfolgt die Qualitätssicherung der Anforderungen nach diesen Qualitätsmerkmalen:

  • korrektdie Anforderungen müssen insbesondere widerspruchsfrei sein. Siehe Korrektheit (Informatik).
  • machbardie Anforderung muss realisierbar sein. Siehe Machbarkeit.
  • notwendigwas nicht vom Auftraggeber gefordert wird, ist keine Anforderung.
  • priorisiertes muss erkennbar sein, welche Anforderungen am wichtigsten sind. Ziel der Priorisierung ist es, häufig benötigte Funktionen vor den weniger häufig benötigten bereitzustellen. Man erreicht es über eine Quantifizierung der Funktionszweige.
  • nutzbar, nützlichauch bei teilweiser Realisierung soll bereits ein produktives System entstehen.
  • benutzerfreundlichdie Benutzerfreundlichkeit des Systems muss sichergestellt sein.

Das Ergebnis der Prüfung stellt die Basis für das Pflichtenheft dar.

Einzelnachweise

  1. Alain Abran, James W. Moore (Hrsg.): SWEBOK: Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, Los Alamitos, Kalifornien, USA 2004, ISBN 0-7695-2330-7, S2-2 (online ; Stand: 3. Juni 2007). 
  2. CMMI Product Team; Software Engineering Institute, Carnegie Mellon (Hrsg.): CMMI® for Development, Version 1.2, Improving processes for better products. Pittsburgh, PA 15213-3890, USA 2006 (Requirements Development ; Stand: 2008-01-18). 
  3. CMMI Product Team; Software Engineering Institute, Carnegie Mellon (Hrsg.): CMMI® for Development, Version 1.2, Improving processes for better products. Pittsburgh, PA 15213-3890, USA 2006 (Requirements Management ; Stand: 2008-01-18). 
  4. http://www.volere.co.uk/books.htm

Weblinks

Literatur

  • Christof Ebert: Systematisches Requirements Engineering und Management dpunkt.Verlag, Heidelberg, 2008, ISBN 978-3-89864-546-1
  • Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz: Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007, ISBN 3-540-47689-X
  • Suzanne Robertson, James Robertson: Mastering the Requirements Process. Addison-Wesley Professional, Boston, Massachusetts 2nd Edition 2006, ISBN 0-321-41949-9
  • Bruno Schienmann: Kontinuierliches Anforderungsmanagement: ProzesseTechnikenWerkzeuge. Addison-Wesley, München 2001, ISBN 3-8273-1787-8
  • Karl E. Wiegers: Software Requirements. Microsoft Press, Redmond, Washington 2nd Edition 2003, ISBN 0-7356-1879-8
  • Chris Rupp & die SOPHISTen: Requirements Engineering und Management. Professionelle, iterative Anforderungsanalyse für die Praxis, Hanser 2007, ISBN 3-446-40509-7
  • Klaus Pohl: Requirements Engineering: Grundlagen, Prinzipien, Techniken dpunkt.Verlag, Heidelberg, 2008, ISBN 3-898-64550-9

Wikimedia Foundation.

Игры ⚽ Поможем написать реферат

Schlagen Sie auch in anderen Wörterbüchern nach:

  • CMMI — Das Capability Maturity Model Integration (kurz CMMI) ist eine Familie von Referenzmodellen für unterschiedliche Anwendungsgebiete derzeit für die Produktentwicklung, den Produkteinkauf und die Serviceerbringung. Ein CMMI Modell ist eine… …   Deutsch Wikipedia

  • Capability Maturity Model Integration — Das Capability Maturity Model Integration (kurz CMMI) ist eine Familie von Referenzmodellen für unterschiedliche Anwendungsgebiete – derzeit für die Produktentwicklung, den Produkteinkauf und die Serviceerbringung. Ein CMMI Modell ist eine… …   Deutsch Wikipedia

  • Telelogic — Rechtsform AB Gründung 1983 Sitz Malmö …   Deutsch Wikipedia

Share the article and excerpts

Direct link
https://de-academic.com/dic.nsf/dewiki/79013 Do a right-click on the link above
and select “Copy Link”