Die Begriffe Ziele, Anforderungen oder auch Kriterien etc. werden in der Praxis oft unscharf verwendet. Daher soll hier deren Bedeutung für diese Phase des Problemlösungszyklus festgehalten werden. Diese Begrifflichkeiten können auch als Pyramide grafisch dargestellt werden. Dies darum, weil sie dem Top-Down-Grundsatz folgen, sie werden immer konkreter bzw. spezifischer.
Vision
Beschreibt eine Wunschvorstellung, die noch in Zukunft erreicht werden soll. Man verzichtet daher oft auf eine Angabe des Erreichungstermins, bspw. «Ich will Millionär werden» oder «Wir wollen die Nummer 1 der Käse-Spezialisten werden».
Ziele
Auf welcher Stufe der Granularität (Hauptziele, Detailziele) auch immer, Ziele beschreiben, was erreicht werden soll, aber auf keinen Fall, wie es erreicht werden soll, bspw. «Wir wollen die Betriebskosten bis Ende Jahr um 20% gesenkt haben» oder «Wir wollen uns nächstes Jahr mal wieder ausgiebig erholen». Ziele beschreiben die Wirkung, die erzielt werden soll. Die Formulierung von Zielen hat bestimmten Regeln zu gehorchen, die weiter unten erläutert werden. Man unterscheidet zudem verschiedene Typen von Zielen. Diese werden in einem späteren Kapitel genauer erläutert.
Anforderungen
Sie beschreiben, wie etwas erreicht werden soll. Sie folgen daher im Beschreibungsprozess klar nach den Zielen, denn erst wenn das Was (= Ziele) beschrieben ist, kann auch das Wie beschrieben werden. Man unterscheidet grundsätzlich Anforderungen an die Lösung (Systemanforderungen [System = Lösung]) und Anforderungen an das Vorgehen, bspw. in Anlehnung an die Ziele oben: «Das ERP-System soll die Möglichkeit bieten, die Übersicht der Kundenaufträge pro Kunde jederzeit abrufen zu können» oder «Die Ferien sollen am 1. Juni starten, drei Wochen dauern und nicht mehr als 5’000.– kosten». Das Formulieren klarer und unmissverständlicher Anforderungen hat insbesondere in der ICT-Branche eine zentrale Bedeutung erhalten. Man spricht von Requirements (= Anforderungen). In der ICT hat sich dafür eine Methodik entwickelt, die heute in spezialisierten Seminaren erlernt werden kann (= Requirements Engineering, IREB-Zertifikat).
Kriterien
Um später beurteilen zu können, ob die Ziele oder Anforderungen erfüllt werden, müssen beobachtbare Merkmale beschrieben werden, mit denen der Grad der Erreichung der Ziele bzw. Anforderungen gemessen werden kann. Man spricht daher auch oft von Messkriterien/ Messgrössen o.ä. In Anlehnung an die oben genannten Anforderungen könnten folgende Kriterien formuliert werden: «tatsächliche Kosten der Ferien» oder «tatsächliche Dauer der Ferien» etc.
Ablauf und Grundsätze
Grundsätze
Man kennt verschiedene Grundsätze für die Zielformulierung. Aus den oben beschriebenen Begriffserklärungen leiten sich die wesentlichen ab. Nachstehend die 9 wichtigsten Grundsätze:
1. Zielformulierungen sollen lösungsneutral sein: Sie sollen Wirkungen beschreiben, die durch die noch unbekannten Lösungen hervorgebracht werden.
2. Zielformulierungen sollen vollständig sein, d.h. alle Wirkungen berücksichtigen, die der Auftraggeber wünscht.
3. Zielformulierungen können auch die Vermeidung negativer Wirkungen beinhalten: So kann zum Beispiel «keine Erhöhung der Personalkosten» ein Ziel sein.
4. Ziele müssen strukturiert werden: Es sollen Gruppen mit einem gemeinsamen Oberbegriff gebildet werden, um die Ziele/ Teilziele transparent zu machen.
5. Ziele sollen, wenn immer möglich, operationalisiert werden: Unpräzise Formulierungen wie «der Ablauf soll besser werden» sollen vermieden bzw. präzisiert und mit Kriterien messbar gemacht werden (vgl. SMART-Regel weiter unten).
6. Es soll zwischen Muss- und Kann-Zielen unterschieden werden (Kann-Ziele heissen auch Wunschziele).
7. Alle Ziele müssen vom Auftragnehmer dokumentiert werden; die Ziele werden in der Regel in einem sogenannten Zielkatalog festgehalten.
8. Ziele sind nicht endgültig, sie können – jedoch nur in Absprache mit allen Beteiligten inklusive des Auftraggebers – verändert bzw. angepasst werden.
9. Zielkonflikte müssen aufgedeckt werden, insbesondere muss der Zielkatalog widerspruchsfrei sein.
Zielbeziehungen analysieren
In der Regel werden in einem Zielkatalog viele unterschiedliche Ziele definiert. Diese Ziele ste-hen dann in unterschiedlicher Beziehung zueinander.
Ziele operationalisieren und Präferenzmatrix
Die Präferenzmatrix ist ein einfaches und effektives Hilfsmittel und beruht auf dem Prinzip des paarweisen Vergleiches. Jedes Kriterium wird miteinander verglichen und das jeweils wichtigere Kriterium vermerkt. Der paarweise Vergleich beantwortet die Frage „Was ist wichtiger?“. Durch diese Vorgehensweise erhält man eine strukturierte Rangfolge. Das Kriterium mit den meisten Nennungen ist das wichtigste Kriterium.
Die Erstellung der Präferenzmatrix erfolgt in der Regel nach den folgenden Schritten:
Kriterien sammeln (Brainstorming)
Matrix erstellen
Paarweiser Vergleich
Nennungen (Häufigkeiten) zählen
Rangfolge erstellen
Formulierung von Anforderungen
Funktionale Anforderungen versus nicht-funktionale Anforderungen
Viele Lastenhefte und Pflichtenhefte unterscheiden sogenannte funktionale Anforderungen und nicht-funktionale Anforderungen. Funktionale Anforderungen sind Anforderungen mit Bezug zur Zweckbestimmung des Produkts. Zu den nicht-funktionale Anforderungen zählen Anforderungen wie die Zuverlässigkeit und das Zeitverhalten.
Unterscheidung von funktionalen und nicht-funktionale Anforderungen
Diese Unterscheidung zwischen funktionalen und nicht-funktionalen Anforderungen stammt noch aus Zeiten der ISO 9126 (die inzwischen abgelöst wurde durch die ISO 25010):
Abb. 1: Funktionale Anforderungen und nicht-funktionale Anforderungen unterscheidet die ISO 9126
Die Trennung zwischen den beiden Typen an Anforderungen findet sich v.a. bei stand-alone Software.
a) Funktionale Anforderungen
Funktionale Anforderungen sind die Anforderungen, deren Umsetzung direkt der Zweckbestimmung des Produkts dienen. Sie sind spezifisch für dieses Produkt. Beispiele für diesen Typ an Anforderungen sind:
Die Software muss den Body-Mass-Index basierend auf einer Formel berechnen.
Die Software muss vor Arzneimitteln warnen, für die eine Kontraindikation oder Wechselwirkung vorliegt.
b) Nicht-funktionale Anforderungen
Nicht-funktionale Anforderungen hingegen sind meist unspezifisch für ein Produkt. Beispiele für nicht-funktionale Anforderungen sind:
Zeitverhalten: Das System muss innerhalb von 10ms das Ergebnis berechnet haben.
Ressourcenverbrauch: Das System kann 15.000 Transaktionen pro Sekunde bearbeiten ohne, dass die CPU zu mehr als 50% ausgelastet ist.
Robustheit: Das System kann 4 Wochen im Dauerbetrieb ohne ein Neustarten betrieben werden.
IT-Sicherheit: Die Software blockiert nach drei Fehlversuchen die Anmeldung für 30 Sekunden.
Probleme mit funktionalen und nicht-funktionalen Anforderungen
a) Schwierige Unterscheidung
Die Unterscheidung ist oft nicht trivial: Wo würden Sie die Fähigkeit eines Systems, Fehleingaben zu erkennen subsumieren?
Unter Gebrauchstauglichkeit? Eines der Prinzipien der Gebrauchstauglichkeit gemäß ISO 9241 ist die Fehlertoleranz.
Unter Zuverlässigkeit? Die ISO 9126 zählt die Fehlertoleranz explizit dazu.
Unter Funktionalität? Schließlich ist es eine Funktion des System Fehleingabe zu erkennen und darauf zu reagieren.
Auch lässt sich trefflich darüber streiten, ob die Interoperabilität wirklich keine funktionale Anforderung ist. Wie sollte sich denn die Funktionalität eines Systems außer über die UI denn sonst erfahren lassen?
Fazit: Eine Unterscheidung von funktionalen und nicht-funktionalen Anforderungen ist meist überflüssig. Die Software Requirements Specification muss aber sicherstellen, dass beide Typen an Anforderungen spezifiziert sind.