Der System Footprint – Aufbau und Inhalt

Im letzten Beitrag habe ich die Entwicklungsgeschichte des System Footprints beschrieben. Nun möchte ich mehr in die Tiefe gehen und erläutern, wie das Ganze funktioniert. Zunächst gehe ich im Detail darauf ein, wie der System Footprint aufgebaut ist.

User- und Use-Cases & die Value-Proposition

Im Grunde kann man sich das Ganze als großes Poster vorstellen, welches in mehrere Kästchen aufgeteilt ist, die – ähnlich wie Puzzlestücke – ineinanderpassen.

Auf der rechten Seite des System Footprints platziere ich den Kunden bzw. den Benutzer, der das System hinterher verwendet. In der Mitte findet sich die Value-Proposition, also das Nutzenversprechen, der Grund dafür, dass der Kunde dieses System überhaupt kauft.

Die Value-Proposition sollte unbedingt klar definiert und verstanden werden, denn so können wir später im Requirements Engineering unproblematischer entscheiden, ob eine Anforderung notwendig bzw. wie nützlich sie ist. Manchmal gibt es auch Anforderungen, die einen Nutzen zerstören können. Kenne ich die Value-Proposition eines Systems, kann ich auch hier besser entscheiden, ob diese Anforderung tatsächlich kontraproduktiv ist.

Dieses Nutzenversprechen transportieren wir über zwei Wege zum Kunden: Über die Nutzungsfälle und über die Liefereinheiten. Bei ersterem sind die Key-Use-Cases gemeint, also die Einsatzfälle des Systems. Bei den Liefereinheiten kann es sich entweder um einen ABC-Musterstand handeln oder um Ausprägungen in Basis-, Mittel- und Premium-Varianten.

Beide platzieren wir rechts von der Mitte. Diese beiden Wege sind allein für das Grundverständnis sehr wichtig, denn darüber schafft ein System den essentiellen Wert für den Kunden.

Key Features, Key Components und Schnittstellen

Im mittleren Teil auf der linken Seite des System Footprints setzen wir zwei Aspekte, die den Nutzen erzeugen können: Zum einen die Key-Features bzw. die Hauptfunktionalitäten, die auch in Use-Cases sichtbar werden, und zum anderen die Key Components, also die Hauptkomponenten des Systems. Diese können mechanische, elektronische oder auch Software-Komponenten sein, in denen die Key Features ja häufig verhaftet werden.

Nichtsdestotrotz ist das keine architektonische Vorgabe. Vielmehr ist es oft so, dass es neue Features gibt – schließlich handelt es sich häufig um Entwicklungsprojekte, die noch nicht zwingend ein eigenes Key Component als „Zuhause“ finden.

Dennoch ist diese Trennung wichtig, weil wir aus den Key-Components ja auch die Key-Liefereinheiten, die Key Deliverables darstellen können. Wir können also sagen: „Okay, hier gibt es diesen ABC-Musterstand und da werden diese Key-Components und diese Features einfließen.“

Gleichzeitig kann es diese Ausprägungen für den Markt geben – beispielsweise Basis, Medium, Premium oder Ähnliches -, hierbei sind die Komponenten ebenso notwendig.

Links neben diesem linken Mittelteil finden wir schließlich die Interfaces – also die Schnittstellen des Systems. In jedem Workshop machen wir auch eine große Systemabgrenzung und definieren, was drin und was draußen ist.

Dies ist einer der Schritte, die häufig vergessen werden. Ich kann hier nur nochmals bekräftigen, wie wichtig diese Abgrenzung des Systems und die dazugehörigen Schnittstellen sind.

Der System Footprint im Feinschliff

Das Besondere an diesen Teilen ist, dass wir von links nach rechts quasi einen Wertstrom erstellen: Wir schaffen die Value-Proposition über die Use-Cases und die Liefereinheiten an den Kunden, während wir gleichzeitig dieses Nutzerversprechen über die Schnittstellen, die Features und die Components, also die Funktionen und die Komponenten, erzeugen.

In der Fortentwicklung des System Footprints habe ich die Dimensionen hierbei ein wenig angepasst und die Value-Proposition verkleinert, sodass ich maximal vier Post-Its einfügen kann. In der alten Form war die Value-Proposition in der Mitte ein ziemlich großer Bereich, mit dem die Verlockung wuchs, hier sehr viele Post-Ist einzufügen. Meine Erfahrung über die Jahre ist jedoch, dass zwei, drei Value-Propositions im Kern die beschreibenden Inhalte für ein System abbilden können.

Dies hat zwar die Diskussion um die Value-Proposition noch mal deutlich verschärft, weil ich keinen fünften Post-It zulasse, aber meine Gegenfrage lautet dann: „Wie viele echte KERN-Nutzenversprechen kann es denn realistisch geben?“ Weniger ist auch in diesem Fall mehr.