8 Schritte für eine strukturierte Systementwicklung und warum keiner davon ausgelassen werden kann
In dieser Case-Study erfährst Du,
✅ welche Phasen eine strukturierte Entwicklung durchlaufen sollte
✅ welche Methoden Du anwenden kannst um die Ziele der Phasen zu erreichen
✅ Du siehst den gesamten Ablauf von der Idee bis zur Übergabe
An konkreten Anforderungen und Beispielen wirst Du sehen, wie aus der Idee einer Kaffeemaschine nach und nach ein reales Produkt wird. Ich zeige Dir Wege auf, wie die Methoden und Ergebnisse ineinandergreifen und keine dieser Aufgaben als reiner Papiertiger endet.
Einleitung
Die Entwicklung eines Systems ist kein Hexenwerk: Das ist eine Aussage, die ich in den über 20 Jahren im Berufsleben kennengelernt habe. Es ist harte Arbeit und es erfordert ein gutes Verständnis von dem, was entwickelt werden soll. Vor allem solltst Du immer wieder den Blick auf das Große und Ganze lenken. So merkst Du nämlich, was wirklich wichtig ist im Projekt und worauf der Fokus liegen muss.
In dieser CaseStudy gebe ich Dir die Möglichkeit Schritt für Schritt an der Entwicklung eines Systems teilzuhaben. Du wirst sehen, wie ich vorgehe, eine Systementwicklung so aufzustellen, dass Du den Überblick nicht verlierst und immer über den Stand Bescheid weißt. Du erhältst am Ende der Systementwicklung Spezifikationen, die als Inputs für die Fachdomänen gelten können oder aber als Lastenhefte an Zulieferer herausgegeben werden können.
Die Systemabgrenzung
Auf dem Weg zu einer strukturierten Systementwicklung ist es wichtig, dass Du Kenntnisse darüber hast, was zu dem System dazugehört und was eben nicht. Dadurch schaffst Du ein klares Verständnis für Dich und kannst dies mit dem Entwicklungsteam kommunizieren, um eine einheitliche Basis zu erhalten.
Wichtig ist dabei, auf der obersten Ebene ✈️ zu bleiben und das System aus Sicht des Kunden zu betrachten, also das zu beschreiben, was der Kunde auch sieht.
Dazu habe ich hier mein Lieblingsbeispiel modelliert – eine Kaffeemaschine. ☕
Warum dieser Schritt? Viel oft kommt es vor, dass immer irgendetwas von der Systemabgrenzung schon bekannt war. Sei es nun die Umgebung, in die das System eingebettet werden soll oder die Subsystemelemente, die das System selbst bilden. Super hilfreich ist es immer gewesen, wenn Du dann vorher einmal die Systemabgrenzung gemacht hast. Das machst idealerweise gemeinsam mit Deinem Team, damit alle ein gleiches Verständnis aufbauen können. Machst Du das nicht, hängt jeder im Meeting und den weiteren Entwicklungsschritten an seinen Vorstellungen und es gibt immer wieder Diskussionen. Diese kannst Du Dir sparen, wenn vorher eine Grundstruktur steht.
Und ja, auch daran kann dann nochmal gerüttelt, ergänzt und umgebaut werden.
Der System-Footprint
Der nächste Schritt dient dazu, in einem Workshop alles zusammenzutragen, was als Anforderungen an Dein Produkt aufgenommen werden muss.
Bring alle Projektbeteiligten dazu, bei der Erstellung des System-Footprints mitzuarbeiten. Diese visuelle Methode ist wunderbar dazu geeignet. Die Canvas-Felder geben dem Workshop Struktur ohne, zu streng bei der Findung der daran festhalten zu müssen.
Am Ende des Workshop-Tages hast Du eine Sammlung aller wichtigen Anforderungen – zwar nicht ausformuliert, aber als Stichpunkte und visuell – was vielen Menschen einfacher bei der kognitiven Erfassung fällt.
Das Ergebnis des System-Footprint Workshops dient als Einstieg in die Erstellung Deines Lastenheftes.
Das Lastenheft
Mit den Angaben aus diesen ersten beiden Schritten kannst Du nun eine erste Version des Lastenheftes erstellen. Du hast eine Grundlage vorliegen, die folgende Fragen klärt:
- Was gehört alles zum System dazu? Und was eben auch nicht?
- Welchem Zweck soll das System dienen?
- Wie soll es angewendet werden?
- Aus welchen wichtigsten Teilen wird es bestehen?
Die Auszüge aus dem Lastenheft zeigen Dir den Aufbau eines guten Lastenhefts. Die Kapitel sind exakt die Canvas-Felder aus dem System-Footprint. Und die Unterkapitel sind die gelben Post-Its, die im Workshop gefunden und aufgehängt wurden.
Schritt für Schritt bin ich nun durchgegangen und habe Anforderungen in jedem Unterkapitel formuliert. Du kannst die Anforderungen des Nutzerversprechens dort wiederfinden.
Tipp: Ein Klick unten rechts auf die kleinen Bilder zeigen diese größer in einer Lightbox an.
Die System-Architektur
kommt noch
Übergabe in Fachteams
kommt noch
Integration der Gewerke zu einem Gesamtsystem
kommt noch
Test des Gesamtsystems
kommt noch
Übergabe an den Kunden
kommt noch
Kommuniziere für den Nutzer, argumentiere für den Entscheider (Martins Vortrag)
