Ein wesentlicher Teil der Softwareentwicklung ist die Anforderungsanalyse. Dieses Feld, oft auch gern beim englischen Namen „Requirements Engineering“ genannt, wird oft als lästig und unnütz zeitaufwendig empfunden. Auch wenn man es kaum glauben mag, aber eine der häufigsten Ursachen für qualitativ unzureichende Software ist eine unvollständige Analyse der Anforderungen sowie unzureichende Einbeziehung der Nutzer (vgl. [Chaos-Studie 1995]).
Anforderungen vollständig und korrekt zu dokumentieren hat aber auch weitere Zwecke:
- Dokumente können als Vertragsbestandteil zwischen Dienstleistern und Kunden dienen
- ermöglicht eine zuverlässigere Einschätzung des Entwicklungsaufwandes
- Entwickler haben eine genaue und vollständige Liste der umzusetzenden Funktionen
- Softwaretester haben realitätsnahe Qualitätsvorgaben
Kategorisierung von Anforderungen
Betrachten wir übliche Anforderungen genauer, gibt es vor allem zwei Kategorien, die auffallen: „Der Administrator soll neue Nutzer hinzufügen können.“ bezeichnet klar, was das Programm können soll. Hier haben wir eine konkrete Forderung, die der Entwickler umsetzen und abhaken kann. Dem gegenüber stehen weniger klare Forderungen wie „Auch ungeschultes Personal soll die Software effizient einsetzen können.“ Hier steht der Entwickler vor einem Problem, da sich die Anforderung nicht eindeutig prüfen lässt. Zur Vereinfachung wird daher oft versucht, messbare Parameter in solche Formulierungen einzubringen: „Ungeschultes Personal soll innerhalb von drei Minuten einen neuen Nutzer anlegen können.“
Genannte Unterteilung ist auch in der Literatur sehr üblich und wird oft folgendermaßen benannt:
- Funktionale Anforderungen
- Die Anforderung beschreibt, was das Produkt tun soll (eine bestimmte Produktfunktion).
- Nichtfunktionale Anforderungen
- Die Anforderung beschreibt eine Eigenschaft des Produktes oder einer bestimmten Funktion.
Ob Vertragsdetails wie die Entwicklungszeit eine nichtfunktionale Anforderung darstellen ist strittig. Meist werden sie jedoch nicht dazu gezählt.
Was es zu erfassen gilt
Wie und in welchem Umfang Anforderungen dokumentiert werden sollten ist unterschiedlich. Um jedoch nichts wichtiges zu vergessen, bietet sich eine vollständige Liste üblicher Fakten an, die über Produkte erhoben werden können.
Eine Empfehlung des Aufbaus eines Dokuments zur Erfassung von Anforderungen gibt der Standard IEEE 830-199:
Table of Contents
- Introduction
- Purpose
- Scope
- Definitions, acronyms, and abbreviations
- References
- Overview
- Overall description
- Product perspective
- Product functions
- User characteristics
- Constraints
- Assumptions and dependencies
- Specific requirements
- Appendix
aus [IEEE 830-199]
Die Vorgehensweise
Ist man sich nicht klar, wie man zu den gewünschten Ergebnissen kommen kann, ist eine systematische Vorgehensweise empfehlenswert (vgl. [Pfleeger 2001]):
1. | Problemanalyse | Anforderungsgewinnung (Requirements Definition) |
2. | Problembeschreibung | |
3. | Prototyping, Testen | |
4. | Dokumentation, Validierung | Anforderungsspezifikation (Software Requirements Specification, SRS) |
In den benannten Phasen wird im wesentlichen folgendes getan:
- Was soll das Endprodukt leisten? Wer soll es nutzen oder ist anderweitig betroffen und sollte daher befragt werden?
- Hier erfolgt eine konkrete Auflistung der Probleme durch die betroffenen Kunden (von einem Produkt betroffene Menschen werden auch „Stakeholder“ genannt). Dies entspricht einer Liste an Produktfunktionen und -eigenschaften und entspricht somit dem Lastenheft.
- Die Entwickler müssen prüfen, inwieweit die Anforderungen umsetzbar sind.
- Die gesammelten Erkenntnisse werden dokumentiert und überprüft. Dies ergibt ein für Verträge oft maßgebliches Pflichtenheft, in dem der Entwickler konkret aufzählt, welche Leistungen erbracht werden sollen.
Qualitätsansprüche
Eine erfolgreiche Anforderungsanalyse sollte im wesentlichen drei Eigenschaften erfüllen (vgl. [Jarke 1995]). Während und vor allem nach der Fertigstellung der Dokumente, sollte man sich einige Fragen stellen:
- Ist die Spezifikation wirklich vollständig?
- Sind die Anforderungen formal dargestellt und somit allgemein verständlich?
- Habe ich auch wirklich umgesetzt, was der Kunde von mir wollte? Habe ich die Kundensicht beachtet?
Kann man jede dieser Fragen mit einem ehrlichen ja beantworten, sollte einer erfolgreichen Umsetzung nun nichts mehr im Weg stehen.
Quellen
- [Chaos-Studie 1995]
- The Standish Group: „The Standish Group Report“, 1995
- [Pfleeger 2001]
- Shari Lawrence Pfleeger: „Software Engineering“, 2001
- [IEEE 830-199]
- IEEE-SA Standards Board: „IEEE Recommended Practice for Software Requirements Specification“, 1998
- [Jarke 1995]
- Matthias Jarke, Klaus Pohl, Ralf Dömges, Stephan Jacobs, Hans W. Nissen: „Requirements Information Management: The NATURE Approach“, 1995