Die Anforderungsanalyse (engl.: Requirements Engineering, RE) ist ein Teil des Software- und Systementwicklungsprozesses. Sie dient als Teil des Anforderungsmanagements dazu, die Anforderungen des Auftraggebers an das zu entwickelnde System (vielfach ein Anwendungsprogramm) zu ermitteln. Diese Anforderungen werden dabei in einem Dokument, dem sogenannten Anforderungskatalog, schriftlich fixiert. Hierbei kann die Software Requirements Specification zum Einsatz kommen.
Die Anforderungsanalyse erfolgt in einer frühen Phase des Softwareentwicklungsprozesses und hat entscheidenden Einfluss auf den Prozessverlauf und auf die Qualität und Produktivität des dabei entstehenden Systems, letztlich also auf seine Eignung und Akzeptanz aus Sicht des Anwenders und auf die Wartbarkeit aus Sicht des Entwicklers. Deshalb wird hier besondere Sorgfalt empfohlen.
Die Anforderungsanalyse wird normalerweise im Dialog zwischen dem Kunden (im besten Fall dem Endanwender selbst) und den Entwicklern erstellt. Dabei bedarf es eines Entgegenkommens auf beiden Seiten, da der Kunde (Auftraggeber) in den seltensten Fällen mit den Fachbegriffen des Entwicklers etwas anfangen kann, und umgekehrt der Entwickler nicht über tiefgreifende Kenntnisse im Fachgebiet des Kunden verfügt. Somit ist eine Art „Übersetzungsprozess“ zwischen der Sprache des Kunden und der des Entwicklers vonnöten, der im Dialog möglichst iterativ stattfindet.
Die Analyse besteht aus den Schritten Anforderungsaufnahme, Anforderungsstrukturierung und Anforderungsbewertung. Um ein gutes Analyseergebnis zu erzielen, empfiehlt es sich, folgende Kriterien zu berücksichtigen:
Aufnahme und Erfassung
Im Schritt der Anforderungsaufnahme, also der Erhebung, Beschreibung und Dokumentierung der Anforderungen, ist der Übersetzungsprozess zwischen Fachseite und Entwickler von besonderer Bedeutung. Folgende Kriterien sind zu erfüllen:
- vollständig - alle Anforderungen des Kunden müssen explizit beschrieben sein, es darf keine impliziten Annahmen des Kunden über das zu entwickelnde System geben.
- eindeutig definiert / abgegrenzt - präzise Definitionen helfen, Missverständnisse zwischen Entwickler und Auftraggeber zu vermeiden.
- verständlich beschrieben - damit sowohl der Auftraggeber als auch der Entwickler mit vertretbarem Aufwand die gesamte Anforderung lesen und verstehen können.
- atomar - es darf nur eine Anforderung pro Abschnitt oder Satz beschrieben sein. Das Kriterium für ein "Atom" sollte die Entscheidbarkeit einer Anforderung sein.
- identifizierbar - jede Anforderung muss eindeutig identifizierbar sein (z. B. über eine Kennung oder Nummer).
- einheitlich dokumentiert - die Anforderungen und ihre Quellen sollten nicht in unterschiedlichen Dokumenten stehen oder unterschiedliche Strukturen haben.
- notwendig - gesetzliche Vorschriften sind unabdingbar.
- nachprüfbar - die Anforderungen sollten mit Abnahmekriterien verknüpft werden, damit bei der Abnahme geprüft werden kann, ob die Anforderungen erfüllt wurden (Ableitung von Testfällen aus den Abnahmekriterien).
- rück- und vorwärtsverfolgbar - damit 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.
- Konsistenz - Konsistenz 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ängig - Anforderungen 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örig - Anforderungen, die fachlich-logisch zusammengehören, sollten nicht allein realisiert werden.
- rollenbezogen - jede Benutzergruppe hat ihre eigene Sicht auf die Anforderungen, die damit unterstützt werden soll.
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:
- korrekt - die Anforderungen müssen insbesondere widerspruchsfrei sein.
- machbar - die Anforderung muss realisierbar sein.
- notwendig - was nicht vom Auftraggeber gefordert wird, ist keine Anforderung.
- priorisiert - es 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ützlich - auch bei teilweiser Realisierung soll bereits ein produktives System entstehen.
- benutzerfreundlich - die Benutzerfreundlichkeit des Systems muss sichergestellt sein.
Das Ergebnis der Prüfung stellt die Basis für das Pflichtenheft dar.
Siehe auch
- Volere - Ressourcen zur Anforderungsanalyse
Weblinks
- Arbeitskreis "Requirements" der GI/GChACM-Regionalgruppe München. Neben einer ausführlichen Literatur- und Linkliste sind hier auch die Vortragsfolien der monatlich stattfindenden Veranstaltungen zu finden.
- Fachgruppe „Requirements Engineering“ der Gesellschaft für Informatik
- Übersichtliche Einführung in die Analyse und Verwaltung von Anforderungen.
- RE-Tool-Übersicht mit vielen Merkmalen. Paper-Review-Site.
- Volere-Template. Unter Angabe einer gültigen E-Mail-Adresse kann hier das Volere-Template (von Robertson - vgl. Literatur) in der aktuellen Version kostenfrei heruntergeladen werden.
- International Requirements Engineering Conference Homepage der wichtigsten Konferenz im Bereich Requirements Engineering mit Links zu den jeweiligen Veröffentlichungen.
Literatur
- Suzanne Robertson, James Robertson: Mastering the Requirements Process. Addison-Wesley Professional, Boston, Massachusetts 2nd Edition 2006, ISBN 0321419499
- Bruno Schienmann: Kontinuierliches Anforderungsmanagement: Prozesse - Techniken - Werkzeuge. Addison-Wesley, München 2001, ISBN 3827317878
- Karl E. Wiegers: Software Requirements. Microsoft Press, Redmond, Washington 2nd Edition 2003, ISBN 0735618798
- Chris Rupp und die SOPHISTen: Requirements Engineering und Management. Professionelle, iterative Anforderungsanalyse für die Praxis. Hanser Verlag, 4. aktualisierte und erweiterte Auflage, Deutschland, 2007, ISBN 3446405097