Priorisierung von Anforderungen.

Würde man im Schlaraffenland leben, dann hätte dieser Beitrag keine Relevanz, denn sämtliche Ressourcen – vom Personal bis zur Arbeitszeit – ständen in unendlicher Dimension zu Verfügung. Da dem aber nicht so ist, sind die Anforderungen zu priorisieren, um den Erfolg des Softwareprojektes nicht zu gefährden. Dazu gibt es unterschiedliche Ansätze bezüglich Methodik, Granularität und Praxistauglichkeit. Aus vertraglicher Perspektive ist die rechtliche Verbindlichkeit von entscheidender Bedeutung. Wir betrachten diese Aspekte und versuchen uns an einer Systematisierung in dieser Hinsicht.

In diesem Beitrag geht um die Klassifizierung von Anforderungen, primär unter den Gesichtspunkten der rechtlichen Verbindlichkeit und deren Priorität. Das Ziel einer solchen Einteilung ist es, die verfügbaren Ressourcen für die Kernaufgaben des Projektes einzusetzen und im Sinne des Kunden ein Produkt zu entwickeln, welches dessen Ansprüche möglichst weitgehend befriedigt. Ausgangspunkt der Analyse ist das vorliegende Lastenheft und weitere formale und informelle Dokumente zur Beschreibung der gewünschten Leistungsanforderungen. Ergänzende Informationen können und müssen vom Entwicklungsingenieur aus dem Kontext des Projektes entnommen werden. Letzteres bedingt, dass man bereit ist sich intensiv in die Problemdomäne des Kunden zu versetzen, oder anders formuliert: Nur wenn das zugrunde liegende Sachproblem vollumfänglich verstanden wurde, kann man ein Softwaresystem entwickeln, welches den Wünschen der Kunden entspricht und im Idealfall sogar deren Erwartungen übertrifft.

Rechtliche Verbindlichkeit

Die rechtliche Verbindlichkeit gibt darüber Auskunft, welchen Spielraum dem Entwicklerteam bei der Umsetzung bleibt. Es ist die Frage zu beantworten, in welchem Umfang eigene Ideen durch den Programmierer eingebracht werden können. Ein Beispiel: Das Entwicklerteam hat meist einen besseren Überblick über aktuelle Standards zur Gestaltung von Benutzeroberflächen als der Auftraggeber. Werden im Pflichtenheft Vorgaben zur Gestaltung der Oberfläche ausgeführt, ist die Art der Umsetzung zu prüfen. Es kann angebracht sein, mit dem Auftraggeber solche Aspekte beispielsweise anhand eines Prototypens zu diskutieren. Danach sollte das Pflichtenheft bei Bedarf überarbeitet werden. Basis für die spätere Abnahme bleibt auf jeden Fall das Pflichtenheft und ergänzende Vertragsdokumente. Je nach Formulierung ist bezüglich des Grades der rechtlichen Verbindlichkeit wie folgt zu differenzieren:

• Pflicht: Anforderungen, die unbedingt erfüllt werden müssen. Die entwickelten Systeme müssen diese unbedingt leisten. Werden Pflichtanforderungen nicht voll umfänglich umgesetzt, stellt sich aus rechtlicher Perspektive die Frage, ob die Kernleistung erbracht wurde.
• Wunsch: Anforderungen, die einen Wunsch ausdrücken und bedeuten, dass es gut wäre, wenn das Programm diese Eigenschaft aufweist. Die Umsetzung sollte nach Möglichkeit erst dann angegangen werden, wenn die Pflicht-Leistungen erfüllt wurden.
• Absicht: Anforderungen, die nützlich sind um Stellen aufzuzeigen, an denen es bereits Pläne für die Zukunft gibt. Dieser Punkt ist beispielsweise für die Gestaltung der Softwarearchitektur wichtig, um diese bei einem entsprechend geplanten Erweiterungsbedarf offen und allgemeingültig (generisch) zu gestalten. Ggf. sind auch passende Schnittstellen für eine schnelle Erweiterung vorzusehen.
• Vorschlag: Anforderungen, die aus Lösungsvorschlägen stammen, die vom Entwicklerteam selbst erarbeitet wurden. Die Entwicklung einer Fachanwendung erfordert neben der programmiertechnischen Umsetzung meist auch eine mehr oder wenige tiefgehende Einarbeitung in die Fachmaterie. Dabei werden eigene Ideen entwickelt. Diese Vorschläge können durch den Auftraggeber durchaus als positiv aufgefasst werden (Initiative, Engagement), müssen jedoch zwingend abgestimmt werden.
• Kommentare: Es handelt sich um umfangreiche Abschnitte von exakt beschriebenen Anforderungen. Erst dadurch werden die Anforderungsdokumente verständlich. Derartige Beschreibungen sollten allgemein verständlich gehalten werden und damit sicherstellen, dass auch fachfremde Personen das Dokument verstehen. Ein Beispiel: Bei der Programmierung einer Software, welche zur Berechnung von Krediten dient, mach es Sinn die Fachtermini zu erläutern und die wichtigsten Begriffe in einem Glossar aufzunehmen.
• Der Grad der Verbindlichkeit einer Anforderung bemisst sich anhand der beiden folgenden Faktoren, woraus sich vier Kombinationsmöglichkeiten ergeben: mit Vertrag, ohne Vertrag, intern mit vertrag und intern ohne Vertrag.

Der Grad der Verbindlichkeit sollte explizit in den Dokumenten dargestellt werden. Dazu bedient man sich bestimmter Schlüsselworte und Formulierungen z.B.:

• für Verpflichtung verwendet man „Das System muss…“
• für Wünsche „Das System soll…“
• für Absichten „Das System wird“
• für Vorschläge „Das System kann“.

Für Kommentare wird kein Schlüsselwort verwendet. Es ist entscheidend, dass die Anforderungen eindeutig gekennzeichnet sind, nur dann hat man im Streitfall eine (weitestgehend) rechtssichere Basis.

Priorität

Da man von einer stetigen Knappheit der Ressourcen auszugehen hat, ist es zwingend notwendig, die Anforderungen hinsichtlich ihrer Priorität zu gewichten. Der Auftraggeber wird gelegentlich dazu neigen – insbesondere dann, wenn dieser relativ wenige Erfahrungen mit Softwareentwicklungsprojekten hat – ein ganzes „Sammelsurium“ an Wünschen zu formulieren. Dabei ist davon auszugehen, dass nicht jeder Wunsch den Status einer zwingend notwendigen umzusetzenden Anforderung hat. An dieser Stelle ergeben sich Überschneidungen mit dem Thema der rechtlichen Verbindlichkeit. Während man mit der Untersuchung der Rechtsverbindlichkeit die Anforderungen danach untersucht, welche überhaupt zwingend zu realisieren sind, geht es in diesem Abschnitt um die Reihenfolge der Bearbeitung. Nach einer Neuordnung, sollte die daraus resultierende Prioritätenliste nochmalig mit dem Auftraggeber diskutiert werden. Dabei wird klar werden, dass es gar nicht möglich ist, alle formulierten Leistungswünsche simultan in einem ersten Schritt umzusetzen. Vielmehr besteht die Notwendigkeit einer Konzentration auf die Kernaufgaben und einer strikten Zuordnung von Prioritäten. Gleichzeitig ist jedoch auch gegenüber dem Auftraggeber zu signalisieren, dass die Äußerung einer möglichst allumfassenden Anforderungsliste notwendig ist, um die Zukunftsfähigkeit des Projektes (Skalierbarkeit, Erweiterbarkeit) gleich zu Beginn richtig einzuschätzen.

Ein Beispiel: Ein Unternehmen welches über verschiedene Standorte verfügt, beauftragt mit der Konzeption und Umsetzung einer neuen Kundendatenbank. Dabei soll diese Datenbank in einem ersten Schritt nur an einem Standort eingeführt und getestet werden. Mögliche Auswirkungen auf die organisatorischen Prozesse werden im Nachgang untersucht und führen ggf. zu einem nachträglichen Anpassungsbedarf (Modifikation des Lastenheftes). Nach dem Abschluss der Testphase ist ein standortübergreifendes Rollout geplant. Dieses Ziel muss auf jeden Fall bereits bei der Planung des Systems und bei der Auswahl der notwendigen Architekturentscheidungen berücksichtigt werden. Beispielsweise wird dann eher die Entscheidung zugunsten einer Web-Anwendung statt einer klassischen Client-Server-Anwendung getroffen.

Die Diskussion zur Priorisierung der Anforderungen zwischen Auftraggeber und Aufragnehmer führt im Idealfall dazu, dass der Auftraggeber seine Wunschvorstellungen gemäß seinem Lastenhaft nochmalig reflektiert und ggf. anpasst. Die Ergebnisse können dann in das vom Auftragnehmer zu erstellende Pflichtenheft einfließen. Das Pflichtenheft bildet im Regelfall auch die rechtverbindliche Basis der Auftragsentwicklung. Zusammenfassen lassen sich die Ziele einer Priorisierung wie folgt:

• Vereinfachung der Planungen für den Auftragnehmer, d.h. Abschätzung der notwendigen und für das Projekt vorzuhaltenden Ressourcen.
• Erkennung der am dringendsten benötigen Leistungen.
• Einschätzung des Aufwands der Maßnahmen zur Qualitätssicherung.

In der Literatur werden unterschiedliche Ansätze zur Priorisierung diskutiert. Dabei kann kein Patentrezept empfohlen werden, vielmehr gilt es einen praktikablen Weg für das vorliegende Projekt zu entwickeln. Einige Ansätze werden in den kommenden Textabschnitten näher vorgestellt. Die Techniken unterscheiden sich im Wesentlichen durch den zur Priorisierung benötigten Aufwand, sowie der angewendeten Kriterien und Merkmale. Das Methodenspektrum reicht von einfachen Verfahren auf der Basis eines Kriteriums bis hin zu aufwändigen analytischen Methoden [Pohl, 2010].

• Ranking: beim Ranking wird – ohne Bezugnahme auf ein konkretes Kriterium – durch die Stakeholder eine Rangfolge der Anforderungen festgelegt. Natürlich muss intern ein Kriterium zur Entscheidung verwendet werden.
• Top-Ten-Technik: Es werden für eine zuvor festgelegte Anzahl (n) im Hinblick auf ein Kriterium die n wichtigsten Anforderungen ausgewählt. Für diese Anforderungen muss dann in einem zweiten Schritt die Reihenfolge festgelegt werden.
• Ein Kriteriums-Klassifikation: Anforderungen werden in Klassen Mandatory, Optional und Nice-to-have eingeordnet. Die Praxis hat dabei gezeigt, dass die Unterscheidung bzw. Einordnung in die Klassen Optional und Nice-to-have nicht immer zweifelsfrei möglich ist.
• Zwei-Kriterien-Methode: Es werden zwei Kriterien für eine Bewertung herangezogen. Die Darstellung könnte dann mit Hilfe des Eisenhower-Schemas erfolgen (Abbildung 1). In diesem Beispiel werden die Dimensionen Wichtigkeit und die Dringlichkeit einer Anforderung simultan dargestellt.

• Kano-Klassifizierung: Die Anforderungen werden in Bezug auf ihre Marktwirkung klassifiziert. Mögliche Merkmalsklassen sind Basismerkmale, Leistungsmerkmale und Begeisterungsmerkmale. Basismerkmale sind diejenigen, die das System zwingend aufweisen muss, um in den Markt zu kommen. Leistungsmerkmale dienen dazu, den Kunden von den Funktionen eines Produktes zu überzeugen. Begeisterungsmerkmale sorgen dafür, dass der Kunde durch Zusatzfunktionen Spaß an der Bedienung hat.

• Wiegers’sche Priorisierungsmatrix: Es handelt sich um ein analytisches Priorisierungsverfahren. In Abbildung 2 ist das Prinzip anhand eines sehr einfachen Beispiels dargestellt. Grundsätzlich ist im Hinblick auf analytische Verfahren anzumerken, dass diese einen deutlich höheren Aufwand verursachen, als die einfachen (qualitativen) Verfahren. Der Benutzer wird jedoch mit größerer Objektivität und einer höheren Nachvollziehbarkeit belohnt.

Hat man die Anforderungen – primär nach den Kriterien der rechtlichen Verbindlichkeit und der Priorität – neu bewertet, macht es Sinn diese in einer zusammenfassenden Übersicht zu präsentieren.

Fazit

Der Beitrag hat sich intensiv einigen speziellen Facetten der Anforderungsanalyse gewidmet. Im Fokus der Betrachtungen stand der Versuch der Systematisierung, u.a. nach dem Grad der rechtlichen Verbindlichkeit und der Priorität. Das Thema ist vielschichtig und eine saubere Anforderungsanalyse ist notwendig, um ein komplexes Entwicklungsvorhaben erfolgreich durchzuführen. Zusammenfassend kann der Prozess der Klassifizierung und Priorisierung gemäß dem Schema in Abbildung 7 dargestellt werden.

Ausgehend von den Informationen im Pflichtenheft werden die Anforderungen einer rechtlichen Bewertung und einer Analyse der Wichtigkeit unterzogen. Nach einer detaillierten Diskussion mit dem Auftraggeber entsteht das Pflichtenheft, welches letztendlich auch die rechtverbindliche Basis des folgenden Entwicklungsprozesses darstellt. Im nächsten Teil wird es um die Unterstützung der Anforderungsanalyse durch Software gehen. Das anzustrebende Ziel ist eine effektive und saubere Dokumentation. Es ist zu untersuchen, was die bekannten Tools in diesem Bereich leisten können.

Literatur und Links

Balzert, H.: Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, Spektrum Akademischer Verlag, 2009
Pohl, K.: Requirements Engineering, Springer-Verlag Berlin Heidelberg 2010     
Rupp, C; SOPHIST GROUP: Requirements-Engineering und Management: Professionelle, iterative Anforderungsanalyse für die Praxis C.-Hanser-Verlag, München,Wien, 2009