Requirements Engineering
Verschwendung bereits zu Beginn eines Projektes…
Ein überfülltes Materiallager ist Verschwendung pur. Lebensmittel vergammeln, Werkstoffe korrodieren und Anforderungen verlieren ihre Gültigkeit.
Unter dem Begriff “The 7 Mudas“ (Verschwendung, japanisch) finden sich deren 7 Arten:
Überproduktion- hohe Lagerbestände
- Wartezeit
- unnötige Bewegung
- unnötige Transporte
- Überbearbeitung
- Fehler
Ich widme mich hier dem Thema “hohe Lagerbestände“. Ich will Antworten liefern, wie explizites Wissen (niedergeschriebene Anforderungen) in Anlehnung an die 7 Mudas, tief gehalten werden können.
“Meine Mittel will ich so verwalten, dass wenig weit soll reichen“ [William Shakespeare]
Was William Shakespeare bereits vor ein paar hundert Jahren erkannt hat, gilt auch heute noch. Schauen wir uns ein paar Fakten an, um der Frage über das “Wenige“ etwas näher zu kommen:
- Unsere Ressourcen sind beschränkt:
Faktoren Zeit und Geld: Es ist eine Verschwendung, Unnötiges zu dokumentieren.
- Man kann nicht alles spezifizieren:
Es ist ein Mythos zu glauben, wir könnten eine SW vollumfänglich spezifizieren. Aufgeblasene Dokumente sind unsinnig. Sie werden überflogen statt gelesen.
- Spezifikationen müssen verwaltet und gepflegt werden:
Changes können einen Rattenschwanz von Änderungen erzeugen. Je weniger Text, desto weniger Tipp-Ex!
Spätestens jetzt drängt sich die Frage auf, was soll ich nun spezifizieren, damit das “Wenige weit soll reichen“? Die Antwort ist so einfach wie banal:
- Nur spezifizieren, was relevant ist und entsprechend einen Mehrwert erzeugt.
- Vorsicht beim spezifizieren von allgemeinem Wissen (implizites Wissen). Dies ist eine Verschwendung von Ressourcen und Zeit. Die Herausforderung ist hier eine gute Balance zu finden.
Noch Fragen? Vermutlich ganz viele. Hier 3 Beispiele:
- Wenn für eine schweizer Heizungsfirma eine Buchhaltung-Software entwickelt wird, dann muss nirgend die Sprache definiert werden. Logisch läuft das Programm in Deutsch. Definieren müsste man erst eine Mehrsprachigkeit. Einen echten Mehrwert hingegen erzeugt ein Mockup, welches die UI visualisiert und die Buttons festlegt.
- In einem Feld soll ein Monat (Integer 1-12) eingebeben werden können. Logisch, dass bei einer inkorrekten Eingabe eine Fehlermeldung nicht spezifiziert werden muss. Das ist implizites Wissen, gemeinsames Verständnis dafür ist vorhanden. Wir erwarten, dass die Gültigkeit der Eingabewerte überprüft wird.
- Eine Maschinensteuerung hat folgende Verhaltensregeln:
A1: Detection Error => repeat 3x
E1: Hardware Error => re initialize
E11: E1 in Kombination A1 => re initialize AND repeate 2x
Es ist meine Erfahrung, dass Detailspezifikationen oft unnötig die allgemeinen Anforderungen konkurrieren. Man kann es technisch sicher begründen, warum in diesem Beispiel, die Kombination von A1 und E1 die goldene Exzeption E11 aufrufen soll. Jedoch – die Frage hängt in der Luft: Ist diese wirklich nötig? Oder wurde sie nur der vollständigkeitshalber definiert? Denn, einen Mehrwert in Bezug auf die Funktionalität wird mit E11 nicht erreicht, sondern nur eine Zeiteinsparung.
– Jede zusätzliche Anforderung erzeugt einen Mehraufwand für das Requirements-Engineering, die Entwicklung und das Testing.
– Auch sollte man nicht vergessen, jede zusätzliche Anforderung macht die SW anfälliger für Bugs.
Vorsicht
Grosse Projekte brauchen nach wie vor viele Anforderungen in unterschiedlichen Abstraktionen, verwaltet in Tools oder ganzen Tool Suiten. Tabellen, Diagramme und sonstige Visualisierungen sind wichtig.
Lean Requirements-Engineering soll kein Freipass sein, Anforderungen willkürlich zu kürzen. Gerade mit dem impliziten Wissen muss mit grosser Vorsicht umgegangen werden. Da spielt das Domain Wissen im Team eine entscheidende Rolle.
Quick-Wins:
- Steigerung der Effizienz indem “das Wenige“ bewusst gemacht wird.
- Das Ausmerzen der Verschwendung erfolgt elegant ohne viel Staub aufzuwirbeln. Prozesse und Strukturen müssen nicht umgekrempelt werden.
