Simplified Requirements Management

Requirements Management ist ein recht komplexes Thema in Projekten. In der Fachliteratur wird es oft sehr akademisch beschrieben, so dass es für viele Projekte unangemessen kompliziert und insofern nur schwer handhabbar ist. Häufig ist das unzureichende Managen von Anforderungen eine der Hauptursachen für Projektkrisen. Der CHAOS Report der Standish Group spricht in diesem Zusammenhang unter anderem von „Lack of User Input“, „Incomplete Requirements & Specifications“, „Changing Requirements & Specifications“, „Unclear Objectives“ und „Lack of Executive Support“.

Gerne möchte ich Ihnen einen Anforderungsmanagement-Ansatz erläutern, der in jedem Projekt funktioniert; zumindest besser funktioniert, als ein unterlassenes oder vollkommen unzureichendes Requirements Management, das man leider in vielen Projekten immer noch sehr häufig antrifft. Das Simplified Requirements Management führt zu einer effektiven Risk Mitigation, denn durch die Anwendung des Ansatzes lassen sich die Wahrscheinlichkeit und die Größe eines potentiellen Schadens deutlich verringern.

Das unzureichende Managen von Anforderungen

Stellen wir uns einfach einmal folgende Frage: Warum werden Anforderungen in Projekten oftmals unzureichend gemanagt? Der typische Ursachencocktail ist allzu menschlich:

• Aufwand
  Anforderungsmanagement bedeutet Aufwand, teilweise viel zeitlichen und personellen Aufwand und damit Kosten. Hier wird gerne „gespart“, Anforderungen werden im Zeit- und Kostendruck des Projektes kurzerhand schnell implementiert ohne vorher gründlich analysiert und ordentlich dokumentiert zu werden. Man spart die Arbeit der Analyse und der Dokumentation, oft geschieht dies sogar unter dem Deckmantel bzw. sogar mit Missbrauch der „agilen Vorgehensweisen“, die ich übrigens sehr schätze, wenn sie klug angewandt werden. Dass dies ein aufwandstechnischer Bumerang ist, der spätestens im User Acceptance Test zurückkommt, versteht sich von selbst.
• Prozesse
  Es gibt keine festgeschriebenen Prozesse für Requirements Management im Unternehmen, oder die vorhandenen Prozesse sind überholt oder unzureichend und werden deshalb umgangen oder gar ignoriert.
• Skills
  Im Projektteam verfügt niemand über das erforderliche Wissen und Können, um Anforderungen der Projektsituation angemessen zu managen; es mangelt an Ausbildung und Erfahrung bzw. Führung.
• Tools
  Es fehlen brauchbare Tools wie RM-Datenbanken; die Verwendung von Word, Excel und Sharepoint aus der Not heraus führt schnell zur Frustration, teils bis in ein Chaos, und damit zur völligen Aufgabe des Requirements Managements, insbesondere bei vielen Änderungen.
• Komplexität
  Die IT-Anforderungen, die dokumentiert sind, sind so komplex bzw. so kompliziert und unanschaulich beschrieben, dass die Stakeholder auf der Kundenseite sie nicht verstehen und sich deshalb auch nicht damit auseinandersetzen.

Versetzen wir uns nun in eine Situation, in der alle misslichen Umstände zusammenkommen. Das Projekt steht unter Zeitdruck, verbindliche Prozesse gibt es nicht, niemand weiß so recht wie man vorgehen sollte und eine RM-Datenbank gibt es auch nicht. Was sollte man in einer solchen Situation mindestens tun? Hier hilft der Simplified Requirements Management Ansatz.

Die Regeln im Simplified Requirements Management

Simplified Requirements Management besteht aus wenigen Regeln, die unbedingt eingehalten werden müssen:

1. Attribute für Anforderungen werden festgelegt, zwingend erforderliche und optionale.
2. Jede Anforderung wird in einer Datenbank dokumentiert, mit Hilfe dieser Attribute.
3. Prozessschritte für Anforderungen werden festgelegt und ausgeführt, zwingend erforderliche und optionale.
4. Jede Ausführung eines Prozessschrittes wird in der Datenbank dokumentiert.

Ok, wir haben ein Problem: es gibt in unserem Szenario keine Datenbank! Dieses Problem müssen Sie – so Leid es mir tut – lösen. Ohne RM-Datenbank sind Sie verloren! Sie benötigen unbedingt eine Datenbank, die n:m-Beziehungen, auch Many-to-Many-Relations genannt, abbilden kann; Ohne dieses Merkmal kann man Anforderungen nicht ordentlich managen. Mit Excel ist das schwierig, mit Access geht es schon besser und mit einer beliebigen SQL Datenbank geht es normalerweise hervorragend. Bevor Sie also beginnen, Anforderungen in Worddateien oder einfachen Excel Sheets zu erfassen, stellen Sie sicher, dass Sie eine Datenbank zur Hand haben. Mit o.g. Regeln formt sich in unseren Köpfen nun sehr schnell ein einfaches Datenmodell für unsere Datenbank, bestehend aus einigen wenigen Kernentitäten für die Datensätze der Datenbank.

Die Entität „Requirement“

Bevor wir beginnen Anforderungen zu dokumentieren, müssen wir festlegen wie die Anforderungen dokumentiert werden. Das Business Analyse Body of Knowlege –  BABOK¹ – schlägt hier folgende Attribute vor. Ich zitiere diese Beschreibungen 1:1 in englischer Sprache, da eine Übersetzung meiner Meinung nach keinen Mehrwert bietet:

• Absolute reference: provides a unique identifier. The reference is not altered or reused if the requirement is moved, changed, or deleted.
• Author: provides the name of the person who needs to be consulted should the requirement later be found to be ambiguous, unclear, or in conflict.
• Complexity: indicates how difficult the requirement will be to implement.
• Ownership: indicates the individual or group that needs the requirement or will be the business owner after the solution is implemented.
• Priority: indicates relative importance of requirements. Priority can refer to the relative value of a requirement or to the sequence in which it will be implemented.
• Risks: identifies uncertain events that may impact requirements.
• Source: identifies the origin of the requirement. The source is often consulted if the requirement changes or if more information regarding the requirement or the need that drove the requirement has to be obtained.
• Stability: indicates the maturity of the requirement.
• Status: indicates the state of the requirement, whether it is proposed, accepted, verified, postponed, cancelled, or implemented.
• Urgency: indicates how soon the requirement is needed. It is usually only necessary to specify this

Ob diese Attribute für Ihre Anforderungen in Ihrem Projekt geeignet bzw. ausreichend sind, sollten Sie gemeinsam mit Ihrem Team und Ihren Stakeholdern beurteilen. Natürlich dürfen Sie auch eigene Attribute festlegen, stellen Sie lediglich sicher, dass im Projekt klar ist, wie Anforderungen dokumentiert werden. Auch das nachträgliche Hinzufügen von neuen Attributen der Entität „Requirement“ ist möglich.

Die Entität „Task“

Eine Task, d.h. eine Aufgabe, ist einfach ein Schritt in einem Anforderungsmanagement-Prozess. Sie können eine Task natürlich auch Action, Step oder Process nennen, die verwendete Terminologie sollte nur eindeutig sein und im Unternehmen verstanden werden. Eine Task, wie zum Beispiel „Verify Requirements“ wird in diesem Kontext immer für oder mit einer Anforderung oder einer Anforderungsgruppe ausgeführt, d.h. die Task ändert das Requirement, sie bringt das Requirement ein Stück weiter in seiner Entwicklung. Zwischen den Entitäten Requirement und Task besteht nun eine n:m Relation, d.h. eine Task kann auf viele Requirements angewendet werden und ein Requirement kann mit vielen Tasks behandelt werden.

Requirement Task Relation in der Crowfoot Notation

Das BABOK liefert auch eine erste Liste von Attributen für eine Task:

• Purpose
• Description
• Inputs
• Elements
• Guidelines/Tools
• Techniques
• Stakeholders
• Outputs

Auch hier gilt, dass Sie in Ihrem Unternehmen verbindlich festlegen sollten, mit welchen notwendigen und optionalen Attributen eine Task dargestellt wird. Wie viele Tasks Sie in Ihrem Unternehmen vorsehen, ist Ihre Entscheidung. Im BABOK gibt es 30 Tasks, „Verify Requirements“ ist eine davon. Sie ist bestimmt ein guter Startpunkt für einen Anforderungsmanagement-Prozess, aber sicherlich anpassungsbedürftig für die konkreten Gegebenheiten im Unternehmen. Auch hier gilt es festzulegen, welche Tasks „mandatory“ und welche „optional“ sind.

Weitere Aspekte des Requirements Management

Traceability

Es gibt unterschiedliche Requirements, das Project Management Institute – PMI – und das International Institute of Business Analysis – IIBA – sind sich im Wesentlichen einig und kategorisieren Requirements in vier bis sechs verschiedene Hauptgruppen, ich reduziere das hier auf die Wichtigsten:

• Business Requirements
• Stakeholder Requirements
• Solution Requirements
• Transition Requirements

Diese Requirements stehen natürlich in einer Beziehung zueinander, d.h. dass Solution Requirements die Umsetzung, also die „Lösung“ für Business oder Stakeholder Requirements sind. Auch hier haben wir eine n:m Beziehung, dieses Mal sogar von Requirements untereinander. Spätestens hier steigt Excel übrigens aus, diese Zusammenhänge sind in Excel nicht mehr abbildbar. Mit Traceability ist hier die Verfolgbarkeit von Requirements gemeint, sowohl ausgehend vom Business Requirement um alle relevanten Solution Requirements zu identifizieren, als auch ausgehend von einem Solution Requirement um die betroffenen Business Requirements zu finden. Traceability wird in vielen Situationen im Anforderungsmanagement benötigt, für die Planung, die Priorisierung, ein Impact Assessment bei Änderungen und viele weitere Anwendungsfälle bis hin zum Testmanagement, bei dem Testcases mit den Requirements in Beziehung gesetzt werden.

Requirements and Traceability, Quelle: BABOK, masVenta Business Analysis Curriculum

Requirements Lifecycle

Besondere Betrachtung verdient das Requirement-Attribut „Status“. Während die meisten von uns bei dem Wort Status sofort an einen Zustandsautomaten (engl. State Machine) denken, ist der Status von Requirements kein Übergangsstatus. Am besten vergleicht man die RM-Statuswerte mit Bitleisten, d.h. einer Reihe von Flags, die gesetzt oder nicht gesetzt sind. Ein Requirement kann beispielsweise gleichzeitig die Statusbits „Verified“ und „Validated“ besitzen, das ist kein Übergang. So entwickelt man Requirements im RM-Prozess, in dem man eine nach der anderen Task ausführt (übrigens in einer nicht fest vorgeschriebenen Reihenfolge) und damit das jeweilige Statusbit setzt, solange bis alle notwendigen Bits gesetzt werden können, das Requirement also „fertig“ ist. Konkret könnte das heißen, die Anforderung ist implementiert, getestet und läuft in Produktion, abhängig von der Definition Ihres RM-Prozesses.

Fazit

Mit den wenigen Regeln des Simplied Requirements Management Ansatzes können Sie mit Hilfe einer einfachen Datenbank, der Definition von ein paar Kernentitäten und einem definierten Satz von Tasks in Ihren Unternehmen ein einfaches Requirements Management als Prozess aufbauen. So vermindern Sie die Risiken signifikant im Gegensatz zu einem fehlenden, nicht vorhandenen Management. Der Simplified Requirements Management Ansatz beschreibt die wenigen Kernprinzipien von Requirements Management, die jeder, der mit Anforderungen zu tun hat, kennen sollte. Dieser Ansatz ist unabhängig von der Tatsache wie „agil“ ein Projekt und das Requirements Management in ihm ist. Statt Requirement kann eine Entität auch Epic oder User Story heißen, die Prinzipien bleiben identisch. In einem agilen Projekt beinhaltet die Datenbank dann das Product Backlog, das Nachvollziehen der ausgeführten Tasks erfolgt in Burn-Down-Charts. Im Prinzip kein Unterschied.

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Unter der Leitung von Herrn Wendt veranstaltet die masVenta Business GmbH eine jährliche Konferenz für Business Analysis und Requirements Engineering in Frankfurt, den European Business Analysis Day, kurz (BA-Day). Im Unterschied zu anderen Konferenzformaten in diesen Bereichen ist diese Veranstaltung konsequent international ausgelegt und bietet neben Vorträgen von exzellenten Speakern aus ganz Europa, Amerika und Kanada, viele Möglichkeiten zum Networking mit der internationalen BA und RE Community.

[1] Business Analysis Body of Knowledge BABOK® v3, International Institute of Business Analysis IIBA®, Toronto 2015

Rainer Wendt hat im t2informatik Blog zwei weitere Beiträge veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.