Wonach suchen Sie zuerst, wenn Sie den Entschluss fassen, sich ein neues technisches Gerät zuzulegen? Sie fragen sich vollkommen nachvollziehbarerweise zunächst „Was kann es denn?“ bzw. „Was muss es können, damit ich es kaufe?“ Sie hinterfragen also die Funktionalität, denn das ist auch genau das, was uns auf sämtlichen Werbeflächen schon fast penetrant präsentiert wird.
Neuentwicklungen waren schon seit jeher ein Wettlauf darum, wer zuerst die neuesten, besten, innovativsten oder kreativsten Funktionen bietet. Ein Nebeneffekt davon, der sich uns auch immer wieder in unserem Tagesgeschäft offenbart, ist, dass dabei die nicht-funktionalen Aspekte auf der Strecke bleiben und kaum bis keine Beachtung finden.
Dieser Effekt wird durch die extrem kurzen Releasezyklen, wie Sie ja mittlerweile en vogue sind, noch zusätzlich unterfüttert. Von Release zu Release wird versucht, neue Funktionen zu entwickeln ohne zu viele Gedanken an Anforderungen wie die Qualität zu verschwenden. Leider wird oft vernachlässigt, dass es sich dabei um Kriterien handelt, die eine zentrale Rolle für die Kaufentscheidung des Kunden spielen und maßgeblich zum Produkterlebnis des Kunden beitragen. Es gibt sogar Untersuchungen, die ergeben, dass Stakeholder stellenweise über fehlende Funktionalitäten hinwegsehen, insofern das Look & Feel, also ein anderer nicht-funktionaler Aspekt, stimmig ist.
Wird den nicht-funktionalen Merkmalen eines Systems nicht ausreichend Beachtung geschenkt, leiden darunter häufig für den Kunden eminent wichtige Eigenschaften wie Performance oder Usability. Die logische Konsequenz ist ein unzufriedener Kunde. Leider werden derartige Defizite in der Entwicklung häufig erst zu spät identifiziert, so dass sich eine Nachbesserung extrem ressourcenaufwendig gestaltet.
Darüber hinaus tragen nicht-funktionale Anforderungen (kurz: nfAs) erheblich zur Vollständigkeit Ihrer Spezifikation bei. Denn nfAs dienen nicht ausschließlich der Ergänzung von funktionalen Anforderungen – ganz im Gegenteil.
Sie sind außerdem ein Indikator dafür, dass Funktionalitäten nur lückenhaft spezifiziert sind oder dienen als Begründung bzw. Verfeinerung für weitere funktionale Anforderungen.
Doch wie handhaben Sie am besten Ihre nfAs? Wie kann man dieser Problematik effektiv entgegen wirken?
Aus unserer Erfahrung wissen wir, dass jeder Stakeholder, der funktionale Anforderungen an Ihr System hat, im Allgemeinen auch nicht-funktionale Anforderungen hat. Es liegt an Ihnen als Systems bzw. Requirements Engineer, diese bestenfalls gleich im Prozess der Funktionserhebung mit zu ermitteln. Im Grunde genommen müssen Sie im Umgang mit nfAs die exakt gleichen Schritte durchlaufen, wie auch bei funktionalen Anforderungen. Also ermitteln, dokumentieren, prüfen und abstimmen sowie verwalten.
Kommt Ihnen dieses Problem bekannt vor? Dann haben wir womöglich genau das Richtige Für Sie. In Requirements-Engineering und -Management – Aus der Praxis von klassisch bis agil haben wir Techniken und Hilfsmittel inklusive deren Anwendung im Realprojekt beschrieben, die Sie dabei unterstützen können mit Ihren nfAs fertig zu werden (z.B. das Vorgehen IVENA [Integriertes Vorgehen zur Erhebung nicht-funktionaler Anforderungen]). Die IVENA-Gliederung für nicht-funktionale Anforderungen finden Sie zum kostenfreien Download hier. Auch die MASTeR-Schablonen für nicht-funktionale Anforderungen, die Sie in unserer MASTeR-Broschüre finden, könnten für Sie ein wichtiges Hilfsmittel sein.
Vielen Dank und viele Grüße,
Ihre SOPHISTen
Teil 1: Herausforderungen in Systems-Engineering-Projekten
Teil 2: Herausforderungen in Systems-Engineering-Projekten –Architektur und Kontextabgrenzung
Teil 3: Herausforderungen in Systems-Engineering-Projekten – Dokumentation von Systemarchitektur
Teil 5: Herausforderungen in Systems-Engineering-Projekten – Safety-Anforderungen