Share ZU:
14 February 2012 @ Uwe Valentini

Reif, reifer, aber nicht überreif – Teil 2

This entry is part 2 of 2 in the series HOOD Capability Model

Dies ist der zweite Beitrag einer Blogserie, die sich dem HOOD Capability Model (HCM) widmet. Andere Modelle, wie CMMI® oder SPICE®, haben zwar unsere Fähigkeiten verbessert, Systeme aus Anforderungen zu entwickeln, nicht aber unsere Fähigkeiten, Anforderungen aus Kunden zu entwickeln (siehe Teil 1 – Informationsmodell: welche WARUM-Anforderungen gibt es und wie leite ich die WAS-Anforderungen daraus ab?). Hier setzt HCM an.

Das HCM besteht eigentlich aus zwei Reifegradmodellen, eines für die Anforderungsdefinition (HCM-RD) und eines für das Anforderungsmanagement (HCM-RM). Die folgende Abbildung gibt einen Überblick über die wesentlichen Komponenten dieser beiden Modelle.

HOOD Capability Models

(Abb. 1 – HOOD Capability Models)

In diesem Beitrag werden wir uns das HCM-RD etwas genauer ansehen.

Mit dem HCM-RD können die aktuellen Fähigkeiten und die Reife des Anforderungsdefinitionsprozesses eines Unternehmens bewertet und darauf aufbauend schrittweise Verbesserungen durchgeführt werde. Die Reife eines Unternehmens wird durch das HCM-RD auf einer Skala von eins bis drei (Getting Started – Capable – Expert) eingestuft. Trotz dieser Klassifizierung ist das Modell flexibel und kann an die Gegebenheiten eines Unternehmens angepasst werden. Es gibt keine starre Reihenfolge von Maßnahmen oder Einführungsschritten. Die Praktiken, die den Maßnahmen zugrundliegen, sind allerdings nicht alle voneinander unabhängig, sodass die Nützlichkeit einiger Praktiken von anderen Praktiken oder auch von der Expertise von Spezialisten abhängt. Es gibt damit Basis-Praktiken, deren Einführung am Anfang stehen sollte. Dies sind z.B. Dokumentationsstandards oder Identifizierbarkeit. Fortgeschrittene Praktiken sind oft eher technisch und erfordern substanzielles Expertenwissen, wie z.B. Methoden der konzeptuellen Modellierung.

Neue Methoden und Techniken stellen auch neue Anforderungen an den Anforderungsdefinitions-Prozess; ihre Einführung funktioniert nicht nach dem plug-and-play Prinzip. Die Integration von neuen Methoden und Werkzeugen in einer Organisation gelingt nur, wenn die Menschen, die für ihre Umsetzung zuständig sind, einbezogen und ihre Ängste berücksichtigt werden. Veränderungen erzeugen Barrieren. Die Gründe für diese Barrieren sind vielfältig. Sie reichen von der Angst, überflüssig zu werden, bis hin zur Angst, dass das neue Vorgehen den eigenen Arbeitsprozess transparenter macht. Um erfolgreich zu sein, müssen diese Barrieren aufgelöst werden; dies erreichen wir dadurch, dass wir kleine Schritte machen, anstatt zu versuchen, die Gesamtaufgabe auf einmal zu lösen (big bang – Ansatz). Die Mitarbeiter werden motiviert, wenn sie Fortschritte sehen. Viele kleine Schritte ermöglichen viele kleine (und auch größere) Erfolgserlebnisse in kurzer Zeit.

Dieser Ansatz ist auch motivierender für das Management einer Organisation. Es ist nicht erforderlich, einen kompletten RE-Prozess im Detail zu definieren – ein sehr aufwändiges, schwieriges und teures Unterfangen. Die für viele Organisationen schwierige Frage „Wo sollen wir anfangen?“ ist so leicht zu beantworten, das Kosten-/Nutzenverhältnis der einzelnen Schritte und Praktiken kann rational bewertet, das Risiko minimiert werden. Denn fehlende Managementunterstützung ist der sichere erste Schritt zum Mißerfolg.

Im Folgenden geben wir einen Überblick, welche Aktivitäten und Qualitätsdimensionen das  HCM-RD beinhaltet, und was die einzelnen Level bedeuten. Dazu benutzen wir die folgende Abbildung, die einen Ausschnitt des HCM-RD als Matrix darstellt.

HOOD Capability Model for Requirements Definition

(Abb. 2 – HCM-RD)

Es sei noch angemerkt, daß nicht alle Aktivitäten eines Levels abgeschlossen sein müssen, um mit Aktivitäten aus einem anderen Level beginnen zu können.

Level 1 – Getting Started

Um Level 1 zu erreichen, brauchen wir ein strukturiertes Vorgehen zur Entdeckung von Anforderungsquellen. Mit einer Stakeholder-Liste schaffen wir Klarheit darüber, welche Rollen für das Erheben und Prüfen von Anforderungen berücksichtigt werden müssen. Indem wir die Systemgrenzen und damit die Schnittstellen definieren, stellen wir sicher, dass alle Beteiligten den Systemumfang kennen.

Da die meisten Systeme ein Vorgängersystem haben, das weiterentwickelt werden soll, sind bestehende Spezifikationen die Grundlage beim Erheben von Anforderungen. Für Level 1 ist es notwendig, Anforderungen zu identifizieren, von anderen Informationen zu trennen und strukturiert abzulegen. Die Struktur muss sicherstellen, dass die Anforderungen von den Betroffenen leicht gefunden werden können.

Nachdem die Anforderungen spezifiziert wurden, müssen sie nach den zuvor festgelegten Qualitätskriterien (identifizierbar, atomar) geprüft werden. Von einem definierten Personenkreis wird in einem Review festgestellt und dokumentiert, ob die Anforderungen gut genug sind, um sie dem Adressaten zu übergeben.

Level 2 – Capable

Zu den Qualitätskriterien von Level 1 kommen nun weitere Qualitätskriterien hinzu. So müssen Anforderungen verständlich sein, also so formuliert, dass der zu erwartende Leserkreis die Aussage der Anforderung in einer der Komplexität der Anforderung angemessenen Zeit und  mit den referenzierten Informationen verstehen kann. Anforderungen müssen auch nachweisbar sein, es muß also möglich sein, im Rahmen der vorgegebenen Projektressourcen (Zeit und Kosten) zu  überprüfen, ob das System die geforderten Anforderungen erfüllt. Hierzu sollten Testfälle erstellt und mit den Anforderungen verlinkt werden.

Für Level 2 müssen Anforderungen außerdem priorisiert werden, um die Planung zu unterstützen und begrenzte Ressourcen besser nutzen zu können.

Level 3 – Expert

Für Level 3 müssen die Anforderungsspezialisten über einen umfangreichen Werkzeugkasten verfügen, in dem z.B. adäquate Erhebnungs- und Spezifikationstechniken (etwa Modellierung) zu finden sind. Außerdem kommen wieder einige zusätzliche Qualitätskriterien hinzu, etwa Vollständigkeit und Verfolgbarkeit. So werden beispielsweise alle abgeleiteten Systemanforderungen zu den Kundenanforderungen verlinkt.

Noch einmal: Sie müssen natürlich nicht warten, bis Sie Level 3 erreicht haben, um endlich die Zusammenhänge zwischen den Anforderungen zeigen zu können. Sobald Sie über die technischen Mittel und die Fähigkeiten verfügen, Anforderungen zu verlinken, tun Sie es, sofort.

Ausblick

Im nächsten Beitrag werden wir uns mit dem zweiten HCM, dem HCM für Anforderungsmanagement, näher befassen.

 

Series Navigation<< Reif, reifer, aber nicht überreif – Teil 1

Uwe Valentini

Kontaktieren Sie Uwe Valentini

Uwe Valentini arbeitet bei Agile-by-HOOD als Berater und Coach mit viel persönlichem Engagement mit Menschen, Teams und Organisationen auf ihrem Weg zu mehr Agilität. Uwe ist leidenschaftlicher Agilist, er lernt jeden Tag etwas Neues und hat viel Spaß daran. Sein Motto: Agilität beginnt im Kopf.