Normalerweise liegt der Fokus der meisten Stakeholder bei der Systementwicklung auf den Funktionalitäten des zukünftigen Systems. Doch die heimlichen Stars sind die nicht-funktionalen Anforderungen, welche einen hohen Einfluss auf die Architektur und die Aufwandsplanung haben, die Kunden glücklich machen, und somit für den Projekterfolg ausschlaggebend sind.
Wir laden Sie ein, uns auf unserer „Blogreise“ durch Themen rund um nicht-funktionale Anforderungen (NFAs) zu begleiten. Dazu widmen wir uns einigen interessanten Fragen:
- Was sind nicht-funktionale Anforderungen?
- Was ist IVENA?
- Wie dokumentiere ich nicht-funktionale Anforderungen?
Na, neugierig geworden? Dann lassen Sie uns gleich beginnen :-).
Was sind eigentlich NFAs und welche Daseinsberechtigung haben sie?
Zuerst sollten Sie wissen: Es existiert keine einheitliche Definition für NFAs. Im Zuge der Projekterfahrung haben sich die SOPHISTen auf eine kurze und pragmatische Definition geeinigt: „Nicht-funktionale Anforderungen sind alle Anforderungen, die … nicht funktional sind.“ Zugegeben, keine schöne Definition. Deshalb erklären wir NFAs besser mittels einer Aufzählung der folgenden Kategorien:
- Qualitätsanforderungen
- Technologische Anforderungen
- Anforderungen an die Benutzungsoberfläche
- Anforderungen an sonstige Lieferbestandteile
- Anforderungen an durchzuführende Tätigkeiten
- Rechtlich-vertragliche Anforderungen
Was sich genau hinter jeder Kategorie verbirgt, erklären wir Ihnen ausführlicher im nächsten Teil unserer Blogserie.
Doch zurück zur Frage, warum NFAs so wichtig sind. Lawrence et al. schreiben in ihrem Buch „The top risks of Requirements Engineering”, dass das Vernachlässigen der NFAs zu den sechs größten Risiken des Requirements Engineerings zählt.
NFAs gehen nämlich häufig über die betrachteten Performance- und Verfügbarkeitsaspekte hinaus (z.B. Wie muss meine Benutzeroberfläche aussehen oder müssen während des Betriebs des Systems irgendwelche Wartungsarbeiten durchgeführt werden etc.).Gerade beim Systems-Engineering (d.h. Systeme inklusive Mechanik und Hardware) müssen besonders viele NFAs neben den Funktionen spezifiziert werden.
Empirische Studien unterstreichen zudem die Bedeutung der NFAs. So haben Untersuchungen ergeben, dass Stakeholder sogar über fehlende Funktionalität hinwegsehen können, sofern die Optik und Bedienung stimmig ist. Letztendlich sind es auch die in Qualitätsanforderungen und in Anforderungen an die Benutzeroberfläche enthaltenen Aspekte, die den Unterschied zwischen einem zufriedenen und einem unzufriedenen Kunden ausmachen.
Um die Bedeutung der NFAs zu unterstreichen und die Dokumentation in Zukunft zu erleichtern hat SOPHIST ein internes Innovationsprojekt gestartet: das IVENA-Projekt.
Innerhalb der Blogserie werden wir kurz auf unsere Arbeitsergebnisse eingehen und unser Vorgehen zum Dokumentieren der NFAs nach Schablone erläutern.
Was es mit IVENA auf sich hat und wie sie nicht-funktionale Anforderungen clever erheben, erklären wir im nächsten Teil unserer Blogserie.
Bis dahin wünschen wir Ihnen alles Gute.
Herzliche Grüße
Ihre SOPHISTen
Teil 2: NFAs clever kategorisieren!