Priorisierung von Anforderungen

Die MSCW-Methode ist ein vierstufiges Verfahren der Priorisierung. Meist wird sie zur Kategorisierung von Anforderungen genutzt, grundsätzlich eignet sie sich bspw. auch zur Priorisierung von Zielen, Aktivitäten oder Änderungsanträgen.

M ust (have) – die Kategorie für „Muss“-Anforderungen. Sie gelten als nicht verhandelbar und sollten nicht im Widerspruch zu anderen Muss-Anforderungen stehen. Wendet man den Business Analysis Body of Knowledge – kurz BABOK – an, sollten sie darüber hinaus auch vollständig, einheitlich, richtig, umsetzbar, änderbar, eindeutig und testbar sein.

S hould (have) – die Kategorie für „Soll“-Anforderungen. Idealerweise sollten Anforderungen, die in dieser Kategorie landen, ebenfalls umgesetzt werden. Da die Priorität aber niedriger als bei „Muss“-Anforderungen ist, die zudem immer vorrangig umzusetzen sind, kann es zu einer Implementierung in nachfolgenden Releases oder Projekten kommen.

C ould (have) – die Kategorie für „Kann“-Anforderungen. Sie können umgesetzt werden, nachdem die „Muss“- und „Soll“-Anforderungen umgesetzt wurden. Sie werden daher auch als „nice to have“ bezeichnet. Bei zeitlichen Engpässen oder Ressourcenkonflikten werden diese Anforderungen als erstes verschoben bzw. nicht realisiert.

Won’t (have) – die Kategorie steht für Anforderungen, die nicht umgesetzt werden. Alternativ wird das W auch als Would – wäre schön, wenn es demnächst umgesetzt werden könnte – oder Want – wird gewünscht, aber in einem anderen Vorhaben, Projekt oder Release – interpretiert. Grundsätzlich wird empfohlen, Anforderungen auch innerhalb dieser Kategorie zu dokumentieren, denn so lässt sich nachvollziehen, ob eine scheinbar neue Anforderung evtl. bereits erfasst wurde. Zusätzlich können dokumentierte Anforderungen in zukünftigen Projekten als Quelle dienen.

In der Praxis landen meist sowohl die „Muss“- als auch die „Soll“-Anforderungen in weiterführenden Dokumenten wie Lastenhefte oder Business Cases. Kann-Anforderungen und nicht umzusetzende Anforderungen verbleiben hingegen meist in internen Backlogs, Listen oder Tools.

Das Kano-Modell zeigt den Zusammenhang zwischen der Kundenzufriedenheit und der Erfüllung von Kundenanforderungen. Es beschreibt den Zusammenhang zwischen dem Erreichen bestimmter Eigenschaften eines Produktes / einer Dienstleistung und der erwarteten Zufriedenheit von Kunden.

Das Modell unterscheidet fünf Ebenen der Qualität:

In manchen Situationen sollen mehrere Priorisierungskriterien gleichzeitig betrachtet werden. Das Kosten-Nutzen-Verhältnis ist eine oft verwendete Kombination von Kriterien, um Anforderungen zu priorisieren.

Hierbei ermittelt man für jede Anforderung im ersten Durchgang die Kosten und in einem zweiten Durchgang den Nutzen. Dabei müssen verschiedene Stakeholder befragt werden um valide Aussagen über Kosten und Nutzen zu erfahren. Das Kosten-Nutzen-Verhältnis berechnet sich dann für jede Anforderung aus dem Quotienten zwischen beiden Werten. Die Anforderung mit dem höchsten Nutzen pro investierter Kosteneinheit hat dann die höchste Priorität. Dazu müssen Kosten und Nutzen nicht unbedingt beide in derselben Einheit (z.B. Euro) ermittelt werden. Auch ein Verhältnis in der Einheit „Punkte / Personentag“ ist sinnvoll.

FMEA (engl. Failure Mode and Effects Analysis , deutsch Fehlermöglichkeits- und Einflussanalyse) zielt darauf ab, Fehler von vornherein zu vermeiden, statt sie nachträglich zu entdecken und zu korrigieren. Bereits in der Entwurfsphase sollen potenzielle Fehlerursachen identifiziert und bewertet werden. Damit werden Kontroll- und Fehlerfolgekosten in der Softwareentwicklung oder gar beim Kunden vermieden. Durch die dabei gewonnenen Erkenntnisse wird zudem die Wiederholung von Entwurfsmängeln bei neuen Produkten und Prozessen vermieden.

Die Methodik der FMEA soll schon in der frühen Phase der Produktentwicklung (Planung und Entwicklung) innerhalb des Produktlebenszyklus angewandt werden, da eine Kosten-/Nutzenoptimierung in der Entwicklungsphase am wirtschaftlichsten ist (präventive Fehlervermeidung). Je später ein Fehler entdeckt wird, desto schwieriger und kostenintensiver wird seine Korrektur.

Weitere Informationen zum FMEA-Ansatz finden Sie hier.

Das Ursache-Wirkungs-Diagramm ist die grafische Darstellung von Ursachen, die zu einem Ergebnis führen oder dieses maßgeblich beeinflussen. Alle Problem-Ursachen sollen identifiziert und ihre Abhängigkeiten dargestellt werden. Die bekannteste Form wurde Anfang der 1940er Jahre vom japanischen Wissenschaftler Kaoru Ishikawa entwickelt und später auch nach ihm benannt.

Detaillierte Informationen zum Ursache-Wirkungs-Diagramm finden Sie hier.