Requirements Engineering für Ihren Business Value

Selbstverständlich soll mein Requirements Engineering nur einen Zweck erfüllen, nämlich Ihren Geschäftsnutzen optimieren! Einerseits entscheiden die ersten 30% der Sofware-Projektdurchlaufzeit über Ihren Projekterfolg. Andererseits kommen in der Projektlaufzeit bis zu 50% neue Anforderungen hinzu (Requirements Growth). Die Chance über den Requirements Growth Begeisterungsfaktoren für Ihre Kunden zu finden, ist somit potenziell hoch. Iterative Herangehensweisen erhöhen diese Chance nochmal um ein Vielfaches. Grund ist die ständige Überprüfung und Aufwandschätzung der Requirements Liste.

Verbratenes Geld?

Die Fehlerkosten steigen ohne Requirements Engineering jedoch expotentiell zum Zeitverlauf. Wird die Zeit und auch das Budget knapp, können in aller Regel nur (mehr) Basis,- u. Leistungsfaktoren sichergestellt werden. Leider wird damit mehr Porzelan zerschlagen, als ein Elefant im Porzellanladen schafft – denn Begeisterungsfaktoren für Ihre Kunden sind in derartigen Situationen kaum mehr realisierbar. Tatsächlich sind 65% der schwerwiegenden Fehler in Softwareentwicklungen auf mangelnde Requirements Analyse in der Vorprojektphase zurückzuführen.

kano-analyse
Kano Analse Modell, Kobald Agile Expert & IT Projects, 2017

If you don’t get the requirements right, it doesn’t matter how well you do anything else! (Karl Wiegers)

Inkrementell und iterativ zu den Begeisterungsfaktoren

Es ist meine Zielsetzung Sie mit meinem iterativen und inrkementiellen Requirements Engineering dabei zu unterstützen, die ersten 30% als Erfolgsbasis für mögliche Begeisterungsfaktoren für Sie und Ihre Kunden sicherzustellen. Die Methode ist völlig unabhänig davon, ob Sie agil, wasserfallartig oder hybrid in Ihrem Unternehmen arbeiten.

iteratives-user-centered-design
Source: ISO 9241-210:2010, 2016

Wichtige Erfolgskriterien meiner Arbeit für Ihren Nutzen sind:

  1. Iterative Vorgehensweise
  2. Objektorientierte Analyse (OOA)
  3. User Centered Design (menschenzentriertes Design)
  4. Pareto-Prinzip (mit wenig Aufwand größtmöglichen Nutzen erzeugen)
  5. Requirementsbeschreibungen die jeder versteht (Don’t make me think!)
  6. Storyboarding (die richtigen Fragen stellen)
  7. Standardisierte Gruppenentscheidungen
  8. Product Backlog Priorisierung

Ohne iterativem Requirements Engineering kann im Verlauf eines IT-Projekts nur mehr mit hohem Ressourcenaufwand zwischen precision (Zufallsfehler) und accurancy (systemischer Fehler) unterschieden werden. Weiter kann der Requirements Growth nicht als Chance für Begeisterungsfaktoren genutzt werden. Die noch immer vorherrschende Meinung,  dass Requirements Engineering zu kostenintensiv sei, führt zu Verzögerungskosten (Costs of Delay) die den Kostenaufwand des Requirements Egnineering bei weitem übersteigen. Vom Begleitschaden keine Begeisterungsfaktoren erzeugen zu können, ganz zu schweigen. In Wahrheit gehen 70% aller gescheiterten IT-Projekte wegen schwerer Fehler in der Vorprojekt-Phase den Bach runter.

Wie die Abarbeitung der Geschäftsfälle bzw. die in der Softwarelösung umzusetzenden Prozesse auszusehen haben, werden mit Ihnen gemeinsam erarbeitet. Eine sehr treffende Aussage der Qualitätsmerkmale von Software Requirements (SR = User Stories, Use Cases) liefern Chris Rupp et al:

Eine Anforderung ist eine Aussage über eine Eigenschaft oder Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen.

Danach folgt die Ermittlung der detaillierten Anforderungen im Sinne eines IT-Systems (SRS, Software Requirements Spezification = Pflichtenheft u. Lastenheft). Hier liefert Suzanne Robertson eine treffende Qualitätsbeschreibung:

A functional requirement is an action that the product must take if it is to be useful to its users. Functional requirements arise from the work that your stakeholders need to do. Almost every action – calculate, inspect, publish, or most other active verbs – can be a functional requirement. 

Ligthweight Documentation

Aus der agilen und vor allem aus der Leanwelt kommt die Idee der lightweight documentation. Seit vielen Jahren lebe ich das Prinzip. Tom DeMarco nannte überbordende Spezifikationen „Victorian Documents“, weil sie wie alte, langweilige 1000-Seiten-Romane aus der Viktorianischen Zeit sind, die heute niemand gerne lesen will. Heute sind klare, exakte, geschätzte und value orientierte User Stories gefragt. Natürlich heißt lightweight documentation keinesfalls „schlampig“ zu dokumentieren, sondern vielmehr dass man das Richtige zum richtigen Zeitpunkt mit der richtigen Methode (Werkzeug) dokumentiert. Anders ausgedrückt, man dokumentiert des Nutzen-Willens und nicht des Dokumentieren-Willens.

Der Vorteil einer Auftrennung des herkömmlichen Pflichtenhefts in verschiedene Dokumente – insbesondere technische Spezifikation und „allgemeiner Teil“ – liegt darin, diese leichter unterschiedlichen Zielgruppen zugänglich zu machen, und die Dokumente auf deren Sprache und Ziele hin optimieren zu können. Übrigens kenne ich persönlich kein einziges Softwareprojekt bei dem sich die Anforderungen nicht dort und da änderten. Daher garantiert die Lightweight Documentation gleichzeitig die Kontrolle über die Evolution der Software im Lebenszyklus. Bei der Arbeit entlang dem Wasserfallmodell ist es ja auch möglich lightweight zu arbeiten, was ja nicht automatisch bedeutet, dass man „gschlampert arbeitet. Was meine ich damit? Trotz des Konus der Ungewissheit lassen sich mini Requirements verfassen. So weit ich sehe, ist es auch im Wasserfall oder V-Modell nicht zwingend notwendig, dass man ein Konvolut mit ein paar hundert Seiten als Pflichtenheft verfasst und dem Projektleiter vor die Füße knallt. Viel effektiver im Wasserfallmodell ist es, wenn ein Mini Requirements Engineering betrieben wird. Ähnliches gilt für das V-Modell. Der RE kann Mini Testcases liefern, die gleichzeitig den Business Case unterstützen. Ich habe gelernt, dass überschaubare Spezifikationen, die auf Businessnutzen, Testfähigkeit und Kosten-Benefit hin analysiert werden, dazu beitragen spätere Fehlerkosten zu reduzieren. In Summe ergeben sie das Selbe, sind jedoch im Einzelnen besser überprüfbar. Wer liest schon gern ein paar hundert Seiten, um die für Ihn oder Sie relevanten Punkte herauszufiltern? Diese Herangehensweise hat den riesengroßen Vorteil, dass der RE den Projekt Manager bei seinem oder ihrem Business Case und seiner oder ihrer Projektplanung vom Fleck weg bestmöglich unterstützen kann.

Croud Brain: Gruppenentscheidungsprozesse für Ihren Erfolg

Über die Integration von Teammembern, Experten sowie Stakeholdern wird als Kollateralnutzen bereits im Requirements Engineering Process hohe Usability entwickelt. Wir können natürlich Human Bias, die im Verlauf häufig on top Kosten verursachen, vermeiden.

inkrementelles-modell
Inkrementelles Modell: Glinz, 2009

So werden Hidden Champions und Hidden Profiles vermieden. Es kommt kaum zu suboptimale Entscheidungen aufgrund fehlender Informationen, da die Teammember hohe Eigenverantwortung und dennoch Freiraum haben. Der bekannte Mechanismus Need-Them-All wird durch die gemeinsame Priorisierung des Backlog vermieden. Versteckte Decision Bias als Einflussfaktoren werden minimiert. Beispielsweise führt der Attraktionseffekt einzelner zu asymetrischer Dominanz. Werden gemeinsame Metriken zur Priorisierung verwendet, ist dieses Phänomen ausgeschaltet. Aber auch der Kompromisseffekt wird vermieden, da jedes Requirement aufgenommen ist und die Priorisierung der Gruppe entscheidet. Ihre Teammember sind abgeholt, da kein fadenscheiniges Agreement iregendeiner Seite getroffen werden musste (Win-Win-Entscheidung).

Ihr Nutzen: Tuning-Effekt für Begeisterungsfaktoren

3d-des-re
Source: Fehrer, 2008
  1. Requirements sind frühzeitig strukturiert aufgenommen, definiert, geschätzt und dokumentiert
  2. Frühes evaluieren der Kosten
  3. Flexibler in der Entwicklung sein (Tuning-Effekt für Begeisterungsfaktoren)
  4. Die Priorisierung vermeidet teure “Leerläufe”
  5. Es werden kostenintensive last minute changes verhindert
  6. Reduzieren des Konfliktrisiko durch ein priorisiertes Backlog
  7. Reduzieren von Schätzfehlern durch gruppenbasierte Intervallsschätzungen (Konus der Ungewissheit)
  8. Möglichst viele Fehler frühzeitig erkennen (precision vs accurancy)
  9. Eliminieren von Redundanzen in der Dokumentation (Folgekosten)

So analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult. In a word, it is fascinating. Once you‘re hooked, the old easy pleasures of system building are never again enough to satisfy you. (Tom DeMarco)

Requirements-Schätzungen am Anfang eines Softwareprojekts sind entscheidend für den SDLC

Natürlich hat jeder RE die Pflicht zumindest im Schätzprozess dabei zu sein, wenn es darum geht, Risiken und Aufwände für die zu entwickelnde technische Lösung zu liefern. Für mich ist das Modell von Steve McConnell seit vielen Jahren ein „treuer Begleiter“, weil McConnells Modell einfach, klar und aussagekräftig ist. Vor allem aber auch deshalb, weil es Brook’s Law in die Schranken weist („Adding manpower to a late software project makes it later.” (Brooks 1995). Oft wird man als Projektleiter entgegen bessern Wissens von Stakeholdern quasi gezwungen, wenn es bei Releasedates immer enger und enger wird, Ressourcen aufzustocken, weil man meint, dadurch Zeit wieder gut machen zu können. Dieser Prozess verzögert das Projekt jedoch meistens um weitere Wochen, da die frischen Kräfte im Projekt „angelernt“ werden müssen. Diese Mehrkosten lassen sich vermeiden, wenn man die Requirements Estimations in den ersten 30% des Projekts ernst nimmt und iterativ aktualisiert.

konus-der-ungewissheit-steve-mcconnell-2006
Konus der Ungewissheit: Steve McConnell, 2006

In diesem Zusammenhang ist der spannende Aspekt des Konus der Ungwissheit die Eindeutigkeit der Wichtigkeit der ersten 30% eines SDLC.  In dieser frühen Phase des Projekts werden wenige, jedoch sehr entscheidende Fragen mit großem Einfluss auf den SDLC  analysiert unt beantwortet, oder noch unklare definiert werden.

Die Unsicherheit über Kenngrößen reduziert sich in diesen 30% des Projektfortschritts von einem Faktor 4 auf einen Faktor 1,25, was anders ausgedrückt bedeutet, dass dieser Effekt den möglichen Fehler-Bereich von 16-fach auf 1,56-fach reduziert! Das heißt, dass sich die Risiken teurer Auswirkungen von Fehlschätzungen im weiteren SDLC bereits in dieser Phase durch gute Schätzungen vermeiden lassen.

Die Unsicherheit über Kenngrößen reduziert sich in den ersten 30% des SDLC von einem Faktor 4 auf einen Faktor 1,25, was anders ausgedrückt bedeutet, dass dieser Effekt den möglichen Fehler-Bereich von 16-fach auf 1,56-fach reduziert! Natürlich entstehen in jedem, aber insbesondere im Scrum-SDLC-Verlauf ständig neue Fragen und Probleme, deren Auswirkung jedoch weit weniger Kostenauswirkung haben als jene, die unzureichenden Schätzungen zu Beginn des SDLC, zu grunde liegen – beruhend auf dem Gesetz der großen Zahl.

Sie haben weitere Fragen? Ich kann Sie bei einer Problemlösung unterstützen? Dann kontaktieren Sie mich bitte!

 

Roland Konrad Kobald

Certified Professional for Requirements Engineering (Certificat ID: 1369)