Ein Lifecycle sagt mehr als tausend Prozessbeschreibungen – Teil 2

Warum ist der Lifecycle (Workflow) eines Artefaktes, wie einem Requirement, denn so wichtig? Hauptsache die richtigen Attribute stehen zur Verfügung und wir können das Requirement gut verlinken – eine Traceability aufbauen. Wahrscheinlich ist Ihnen diese Fragestellung nicht unbekannt? Zunächst erst einmal unabhängig, ob Sie nun eine ähnliche Meinung haben oder die Sache völlig anders bewerten. Wenn wir uns klassische RE Werkzeuge ansehen, wie IBM Rational Doors® oder Microfocus CaliberRM®, Requirements werden nicht workflow-unterstützt verwaltet. Trifft das auch auf Ihr RE Werkzeug zu? Haben Sie auch festgestellt, oder tun dies gerade jetzt beim Lesen, dass der Umgang mit Ihren Requirements irgendwie nicht optimal ist? Klare Gründe scheinen nicht analysierbar und die Gemengelage vielfältig und unübersichtlich zu sein. Allenfalls stellen Sie grundsätzlich Kommunikationsschwächen fest, was keinen Erkenntniszugewinn bedeutet.

Nun lassen Sie sich einmal mit mir auf ein Gedankenspiel ein. Nehmen wir an, Requirements beschreiben in erster Linie immer eine Schnittstelle, die geforderte Produkteigenschaft oder Produktfunktion ist also sekundär. In dieser Schnittstellenbeschreibung wird also „primär“ das gemeinsame Verständnis von Stakeholder (Client) und Lösungsdienstleister (Supplier) über die „sekundäre“ Forderung des Clients organisiert und dokumentiert. Jetzt nehmen wir weiter an, wir haben mehrere Clients und mehrere Suppliers, auf die wir teilweise keinen Zugriff haben. Wir können also zu dem Zeitpunkt, wenn wir unserer Schnittstellenbeschreibung erstellen, ein gemeinsames Verständnis nicht sofort sicherstellen. Im Übrigen auch – und vor allem – eine Herausforderung bei agilen Entwicklungsvorgehen. Wir nehmen zudem an, dass die Aktivitäten, die zu einem gemeinsamen Verständnis zwischen Clients und Suppliers führen, nicht über einen Zeitraum von mehr als 4 Wochen geplant werden können. In unserem Gedankenspiel liegt es daran, dass die Kompetenzen und Erfahrungen der Suppliers sehr unterschiedlich sind. Außerdem sollen die „sekundären“ Inhalte, die eigentliche Anforderung an das zu entwickelnde Produkt/Dienstleistung, so spät wie möglich konkretisiert werden, um unnötige Spezifikationsaufwände zu vermeiden. Wir stellen uns also vor, dass erst relativ kurz vor einer Lösungserstellung (4 Wochen vorher) verfügbare Suppliers bekannt sind. Je nach Lösungskompetenz der Suppliers sind verschieden Methoden in variierender Intensität nötig, damit ein gemeinsames Verständnis erarbeitet werden kann. Die Bandbreite beginnt bei unerfahrenen Suppliers, die ein Lösungskonzept mit einem unerfahrenen Team das erste Mal realisieren. Auf der anderen Seite sind Suppliers, die mit erfahrenen Teams eine Lösung schon mehrfach erfolgreich realisiert haben.

Unter diesen Voraussetzungen – so meine These – muss der Stand der Schnittstellenbeschreibung sofort nachvollziehbar sein. Jeder – denn wir kennen nicht alle Beteiligten – muss erkennen welche Reife das Requirement hat. Nur mit diesem Kontext kann der Inhalt von den Beteiligten bewertet und eingeordnet werden. Die Reife des Requirements ist deshalb von so zentraler Bedeutung, weil eben die Aktivitäten keine hinreichend zuverlässige Aussage darüber zulassen, in welchen Stand ein gemeinsames Verständnis vorliegt. Die Anzahl durchgeführter Workshops oder erstellter Sichten mit unterschiedlichen Notationen zur Konkretisierung der Requirements geben allenfalls einen Hinweis darauf, wie intensiv eine inhaltliche Auseinandersetzung erfolgt. Das Ergebnis ist entscheidend und muss bei dem Objekt – der Schnittstellenbeschreibung – dokumentiert werden.

Folgen Sie mir nun, meine These an folgenden Beispielen zu verdeutlichen. Ich gebe folgenden Workflow für ein Requirement vor:

Requirement Lifecycle

Der Zustand „Created“: Ein Requirement ist erstellt worden, ein gemeinsames Verständnis zwischen Clients und Suppliers muss erreicht werden. Das Requirement kann definiert werden.

Der Zustand „Defined“: Ein Requirement ist vollständig spezifiziert, das heißt ein gemeinsames Verständnis zwischen Clients und Suppliers ist erreicht. Der Nachweis wurde anhand von Akzeptanzkriterien und logischer Test Cases beschrieben. Das Requirement kann realisiert werden.

Der Zustand „Refined“: Das Requirement wurde abgeleitet und ein gemeinsames Verständnis zwischen Clients und Suppliers ist erreicht. Das Requirement kann im Produkt/Dienstleistung nachgewiesen werden. (ggf. sind weitere Ableitungsschritte bis zur Implementierung notwendig)

Der Zustand „Verified“: Wenn die Verifikationstests auf Basis des Requirements erfolgreich waren, ist der Zustand “Verified” erreicht. Das Requirement der Clients wurde durch die Suppliers umgesetzt. Eine Validierung des Entwicklungsergebnisses ist jetzt möglich.
Werden die Verifikationstests nicht bestanden, wird die Anforderung zur erneuten Realisierung in einem nachgelagerten Entwicklungszyklus im Zustand „Created“ bereitgestellt. Ein gemeinsames Verständnis zwischen Clients und Suppliers über ein geändertes Requirement oder geänderte Ableitungen muss erreicht werden.

Der Zustand „Terminated“: Der Workflow des Requirement ist beendet.

Die Zustände stehen für die Reife des Requirements. Diese Reifezustände sind unabhängig von der Ausgestaltung der Aktivitäten, die notwendig sind, diese Reifestufen zu erreichen. Damit wird für den Entwicklungsfortschritt der Teil der Entwicklung entkoppelt, der durch unterschiedliche Rahmenbedingungen (Kompetenzen, Erfahrung, Komplexität) maßgeblich gestaltet wird. Der Fokus liegt auf den Ergebnissen dieser teilweise stark variierenden Entwicklungsaktivitäten.

Unter diesen Umständen ist es essentiell, die Zustände so zu definieren, dass diese eine starke Aussage zur Reife des Requirements zulassen. Dadurch wird für alle Beteiligten eine mit der Reife notwendige Bewertung der Anforderung im Entwicklungskontext erst möglich. Beispielsweise erkennt der Client, über welche seiner Requirements ein gemeinsames Verständnis erreicht wurde, der Supplier sieht welche Requirements ausreichend abgeleitet/realisiert wurden und der Tester identifiziert, welche Requirement für den Test zur Verfügung stehen. Schwache Zustände wie zum Beispiel „in work“, „in process“ oder „in review“ lassen keine zuverlässige Aussage über die Reife des Requirements zu und sollten deshalb vermieden werden.

Zum Schluss greife ich noch einmal den Gedanken auf, dass Requirements in erster Linie Schnittstellenbeschreibungen sind. Requirements, wenn sie erfolgreich im Produkt oder Dienstleistung umgesetzt werden sollen, machen ein gemeinsames Verständnis über die Forderungen an Produkte notwendig. Der hier vorgeschlagene Workflow begleitet verschiedene Stufen, dieses Verständnis zu erreichen. Angefangen bei der Definition des Requirements aus Sicht des Client über die Lösungsstufe des Supplier bis zum Nachweis im fertigen Produkt oder der Dienstleistung. Aber Requirements sind mehr als ein Entwicklungsversprechen, sie machen auch Produktbezogen nachweisbar, wie ein gemeinsames Verständnis erreicht wurde. So sind sie Artefakte, die für eine Wiederverwendung von Bedeutung sind. Mit jeder neuen Instanz wird der Workflow zurück auf Start gesetzt. Auch wenn die Spezifikation der Requirements unverändert bleibt, das primäre Ziel ist ein gemeinsames Verständnis. Es muss für jede Instanz des Requirements neu erreicht werden. Auch wenn der Weg dahin von den Änderungen der Rahmenbedingungen abhängt, schaffen die wiederverwendeten Requirements mit ihrem „neuen“ Workflow die Basis auf Grundlage der aktuellen Produktlieferung.

Jens Donig

Kontaktieren Sie Jens Donig

Jens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.