Priorität
Aus Cascade
Die Priorität einer Anforderung ist ein Maß für die Notwendigkeit der Umsetzung der Anforderung in der Lösung.
Eine erste Priorisierung kann auf der Grundlage des berühmten RfC 2119 vorgenommen werden. Davon abgeleitet können zunächst drei Priorisierungstufen vorgesehen werden: Muss, Sollte und Kann. In der Praxis zeigt sich aber, dass eine solche Priorisierung nicht ausreichend ist, um bei knappen Budgets tatsächlich Entscheidungen zwischen Anforderungen nach objektiven und nachvollziehbaren Maßstäben zu treffen. Deshalb muss vor Beginn der Priorisierungsdiskussion im Projekt ein Verfahren mit klaren Spielregeln verabredet werden
Inhaltsverzeichnis |
Priorisierung nach Muss, Sollte und Kann
Bedeutsam an den folgenden Definitionen ist vor allem die klare und eindeutige Festlegung der Bedeutungen solcher Wörter wie muss, sollte, soll, darf und kann (auf soll und darf sollte grundsätzlich wegen des Interpretationsspielraums verzichtet werden). Abgeleitet vom RfC 2119 können zunächst drei Priorisierungsstufen festgelegt werden:
Muss (Must, Shall)
Diese Anforderung muss unbedingt und zwingend umgesetzt werden. Der RfC 2119 kennt auf der gleichen Stufe die Prioritäten "Must not" und "Shall not". In Anforderungsdokumenten sind diese jedoch nicht nötig: Die entsprechende Anforderung wird als "Muss"-Anforderung so formuliert, dass die verbotene Eigenschaft ausgeschlossen wird.
Die deutsche Entsprechung von "Shall" - Soll - sollte in Anforderungsdokumenten nicht verwendet werden, da sie mit "Sollte" verwechselt werden kann.
Sollte (Should, Recommended)
Es ist gewünscht und empfohlen, dass diese Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Der RfC 2119 kennt auf der gleichen Stufe die Prioritäten "Should not" und "Not Recommended". In Anforderungsdokumenten sind diese jedoch nicht nötig: Die entsprechende Anforderung wird als "Sollte"-Anforderung so formuliert, dass die unerwünschte Eigenschaft ausgeschlossen wird.
Kann (May, Optional)
Die Umsetzung dieser Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. In Anforderungsspezifikationen ist die Kann-Priorität sehr selten anzutreffen, da Anforderungen, die wirklich optional sind, meist schon aus Kostengründen nicht spezifiziert werden.
Genauere Priorisierungen
Wenn man bedenkt, dass die Priorität "Kann" genau genommen bedeutungslos ist, wird klar, dass eine Priorisierung auf Basis des RfC 2119 zu grob ist. Deshalb ist eine feingranularere Priorisierung nötig. Dazu geht man wie folgt vor:
Zunächst werden die Anforderungen in Gruppen eingeteilt, die thematisch zusammengehören. Jede Gruppe sollte 10 bis 20 Einzelanforderungen umfassen. Wichtig ist, dass die Anforderungen nicht nach Typ (funktional, nicht-funktional, Rahmenbedingungen, Einschränkungen) geordnet werden. Sie können z.B. einen Themenkomplex "Reporting" bilden, in dem sowohl die Funktionalen Anforderungen (Welche Berichte werden gebraucht, welche Verdichtungen, welche Übersichten) als auch die Nicht-Funktionalen Anforderungen (z.B. Zeitverhalten) und die Rahmenbedingungen (z.B. Datenschutz-Vorgaben) enthalten sind.
Vergeben Sie nun Prioritäten zwischen 5 ("Muss") und 0 ("Kann") - die Werte 4, 3, 2, 1 entsprechen also alle dem "Sollte" - allerdings in Abstufungen. Folgende Regeln sind bei der Vergabe der Prioritäten einzuhalten:
- Es muss wenigstens so viele Anforderungen mit der Priorität "0" geben wie mit der Priorität "5".
- Die Häufigkeiten der Prioritäten 4, 3, 2, und 1 soll in etwa gleich sein.
Auf diese Weise stellen Sie sicher, dass Anforderungen tatsächlich gegeneinander abgewogen werden, und dass die Wichtigkeit z.B. einer Sicherheits- oder einer Performance-Anforderung mit der eines zusätzlichen Berichts oder einer zusätzlichen Summenzeile verglichen wird.
Kommt es dann nach den ersten Aufwand-Schätzungen zu Diskussionen, kann sehr schnell entschieden werden, welche Anforderungen umgesetzt und welche verschoben werden.
