In der Praxis ist es essenziell, Anforderungen zielgerichtet zu erheben und zu bewerten, damit ICT-Lösungen genau das leisten, was das Unternehmen und die Anwender benötigen. Gleichzeitig müssen auch Aspekte wie Qualität, Performance oder Sicherheit berücksichtigt werden. Werden funktionale und nicht-funktionale Anforderungen sauber definiert, lassen sich Projektrisiken reduzieren, die Zufriedenheit der Nutzenden erhöhen und die Projektziele innerhalb des vorgegebenen Zeit- und Budgetrahmens erreichen.
Das Requirements Engineering (RE) beschäftigt sich mit dem systematischen Erheben, Dokumentieren, Prüfen und Verwalten von Anforderungen an Softwaresysteme. Bei Klaus Pohl („Requirements Engineering: Grundlagen, Prinzipien, Techniken“) werden zahlreiche Methoden und Techniken beschrieben, um sowohl funktionale als auch nicht-funktionale Anforderungen zu identifizieren und bewerten, dabei wird wie folgt vorgegangen:
Anforderungserhebung (Elicitation): Interviews, Workshops, Use Cases, Prototypen etc.
| Methode | Kurzbeschreibung | Einsatzgebiet |
| Interviews | Gespräche mit Stakeholdern, um Ziele, Wünsche und Herausforderungen zu ermitteln | Gut für die Klärung detaillierter funktionaler Anforderungen sowie spezieller Wünsche |
| Workshops | Gemeinsame Sitzungen mit Vertretergruppen (Fachabteilungen, Anwender) | Eignet sich zur Priorisierung und Ermittlung nicht-funktionaler Kriterien wie Sicherheit oder Usability |
| Dokumentenanalyse | Auswertung bestehender Unterlagen wie Verträge, Prozessdokumentationen, Richtlinien | Liefert Hintergrundinformationen und legt Rahmen für Leistungs- und Compliance-Anforderungen fest |
| Use Cases | Beschreibung konkreter Nutzungsszenarien, um Abläufe und erwartete Funktionen zu verdeutlichen | Hilft bei der Strukturierung funktionaler Anforderungen und der Identifikation von Schnittstellen |
| Prototyping | Erstellung von Vorab-Versionen oder Mock-ups zum Testen von Funktionen oder Oberflächen | Ermöglicht frühes Feedback für Optimierungen und bessere Sichtbarkeit von Usability-Anforderungen |
| Priorisierungsverfahren (z. B. MoSCoW) | Ordnung der Anforderungen nach Wichtigkeit („Must“, „Should“, „Could“, „Won’t“) | Macht die Bewertung von geschäftskritischen vs. weniger essenziellen Anforderungen sichtbar |
Anforderungsdokumentation (Specification): Formale oder semi-formale Beschreibung (z.B. in User-Story-Form, UML, Text).
Anforderungsprüfung und -abstimmung (Validation & Negotiation): Überprüfung auf Richtigkeit, Vollständigkeit und Konsistenz. Konfliktklärung zwischen Stakeholdern.
| Abschnitt | Beschreibung | Details |
| MoSCoW-Methode | Einfache Einteilung, um Anforderungen nach Wichtigkeit zu clustern | Must (unverzichtbar), Should (wichtig, aber nicht kritisch), Could (wäre nett), Won’t (ausserhalb des aktuellen Scopes) |
| Kano-Modell | Unterscheidet Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren | Basisfaktoren: Selbstverständlichkeiten, deren Fehlen Unzufriedenheit schafft. Leistungsfaktoren: Forderungen, die explizit geäussert wurden. Begeisterungsfaktoren: Unerwartete Anforderungen, die die Zufriedenheit stark erhöhen |
| Pairwise Comparison | Anforderungen werden paarweise verglichen | Das Ergebnis ist ein Priorisierungsranking. Genaue, aber aufwendige Methode zur Gewichtung |
| Bewertung und Validierung nicht-funktionaler Anforderungen | Bewertung durch messbare Kriterien und Definition of Done | Beispiele: Antwortzeit < 2 Sekunden (Performance), max. 0,01% Ausfall pro Jahr (Verfügbarkeit), ISO 27001 Konformität (Sicherheitsstandard) |
| Dokumentation und Konsensbildung | Review-Meetings und Konfliktlösung | Review-Meetings: Anforderungen gemeinsam mit Stakeholdern durchgehen. Konfliktlösung: Priorisierung hilft bei trade-offs. Anforderungsdokument: Zusammenführen aller Anforderungen |
Anforderungsverwaltung (Management): Versionierung, Verfolgbarkeit (Traceability), Änderungskontrolle (Change Management).
Wichtig: Funktionale und nicht-funktionale Anforderungen werden in jedem Schritt konsequent getrennt erfasst, reflektiert und gemanagt, da sie unterschiedliche Auswirkungen auf die Systemarchitektur und die Ressourcenplanung haben.
In Projekten ist es ratsam, diese Anforderungen im Kontext der Unternehmensziele zu bewerten und ihre Relevanz zu gewichten. Neben dem Einsatz strukturierter Bewertungsmethoden sind regelmässige Abstimmungen mit allen relevanten Interessengruppen hilfreich, um sowohl funktionale als auch nicht-funktionale Anforderungen laufend zu validieren und nachzujustieren.
Ein guter Requirements-Engineering-Prozess (nach Klaus Pohl) stellt sicher, dass beide Anforderungstypen systematisch erhoben, priorisiert und validiert werden – denn eine Software kann nur erfolgreich sein, wenn sie sowohl die richtigen Funktionen bietet als auch die erwarteten Qualitätsansprüche erfüllt.