System-Footprint – Version 4.2

Beispiel eines System-Footprint anhand des iPhone 5

Übersicht

Wenn wir ein Lastenheft erstellen und darin Anforderungen beschreiben, ist es an einem bestimmten Punkt essentiell zu entscheiden, ob eine Anforderung für das System sinnvoll ist oder nicht. Diese Entscheidungen können wir einfacher fällen, wenn wir den Kernnutzen des Systems und die wesentlichen Bestandteile im Blick haben. Dies lässt sich auf einer „Canvas“ als System Footprint sehr effektiv visualisieren: Auf einer großen, weißen Fläche, die in verschiedene Bereiche eingeteilt ist, können Teile z.B. im Rahmen eines Workshops mit Inhalten gefüllt werden.

Der System-Footprint dient zur Abgrenzung des System-of-Interest gegenüber dem Umfeld und schafft mit dem Canvas-System eine Basis zur Erhebung der Anforderungen an Dein System.

Features des System-Footprint

visuelle Darstellung
erfasst technische, logistische, soziale und weitere Aspekte
Basis für die Erstellung weiterer Dokumente
einfach anwendbar
schnell erlernbar
online und offline nutzbar

Hinweistexte und Hilfreiche Fragen zu den Canvas-Feldern

Der Benutzer

Die Frage, wer eigentlich der Benutzer ist, scheint trivial – oft ist sie es aber nicht. Bei einem Kaffeemaschinenhersteller beispielsweise sind Händler die Kunden – oder doch die Nutzer der Kaffeemaschine? Ist für einen Fahrkartenhersteller die Bahngesellschaft der Kunde? Oder der Fahrgast, der das System benutzt, um eine Fahrkarte zu kaufen? Ist in der Autobranche der Kunde des Zulieferers immer der Autohersteller? Der wirkliche Benutzer ist doch schließlich der Autofahrer, er benutzt das System und entscheidet, ob er das Auto kauft.

Das Produkt wird für den Endkunden entwickelt, also für die Käufer des Produkts bzw. die Nutzer des Systems – und das ist entsprechend auch die zu fokussierende Zielgruppe.

Hilfreiche Fragen

Wer ist eigentlich der Benutzer?

Gibt es mehrere Benutzergruppen?

Der Kernnutzen unseres Produkts

Der Kernnutzen einer Kaffeemaschine ist nicht immer nur das Herstellen eines Kaffees: Es gibt beispielsweise ein paar entscheidende Gründe, warum Kunden eine Premium-Kaffeemaschine kaufen, nämlich Qualität, Status, Design etc. Das ist das Nutzenversprechen des Produkts und führt zu einer sehr emotionalen Kaufentscheidung, die auf keinen Fall zerstört werden darf.

Hilfreiche Fragen

· Welchen Nutzen hat das System für den Kunden?

· Sind weitere Nutzen neben dem Hauptnutzen vorhanden?

· Werden Premium-Varianten des Produktes hergestellt?

Warum sollte der Kunde diese kaufen?

Nutzungsfälle

Mit den Anwendungsfällen wird beschrieben, wie der Kunde das System benutzt. Die Idee kommt aus dem SysML, dort wird von „Use-Cases“ gesprochen. Das Wissen um die Nutzungsfälle hilft uns, später einen Systementwurf zu definieren, der das Nutzenversprechen in jedem dieser Fälle erfüllt.

Hilfreiche Fragen

Wie wird der Kunde das System benutzen?
Ist ein erster Schritt in die Systemarchitektur
Hilft beim Entwurf des Systems

Liefereinheiten

Wenn wir ein Produkt ausliefern, haben wir verschiedene Varianten und auch verschiedene Musterstände, die wir in einem Entwicklungsprojekt berücksichtigen müssen. Bei dem Beispiel Kaffeemaschine könnten das die Varianten „Premium Classic“, „Premium Gold“ und „Premium Future“ sein. Alle drei sind Kaffeemaschinen, die auf dem gleichen Systemdesign basieren, aber unterschiedliche funktionale Ausprägungen haben.

Hilfreiche Fragen

Gibt es verschiedenen Versionen des Produktes? Varianten: Basic, Premium
Welche Zwischen-Releases sollen erstellt werden? Musterstände: A-, B-, C-Muster
Wie wird das Produkt ausgeliefert? Umfänge: einfach, mit Zwiebeln, mit Zwiebeln und scharf

Kernkomponenten

Ein System wird heutzutage selten aus dem Nichts entwickelt und ist in sich absolut neu. Vielmehr arbeiten Firmen bewusst oder unbewusst mit einem Baukastensystem, in dem man als Systemingenieur immer wieder eine grundlegende System-Architektur definieren kann. Da man hierbei getestete Komponenten verwendet, werden Zeit und Risiko reduziert.

Hilfreiche Fragen

Welche Komponenten sind jetzt schon bekannt?
Was kann aus vorhergehenden Produkten übernommen werden?
Existiert ein Baukastensystem?

Kernfunktionen

Um mit unserem System einen Kernnutzen zu erzeugen, muss das Projekt die wichtigen Kernfunktionen kennen und beschreiben. Die Kernfunktionen können sich über eine oder mehrere Komponenten verteilen und sollten auch deshalb im System Footprint explizit betrachtet werden. Bei diesen Themen sind intensive Diskussionen mit den Entwicklern von großem Vorteil, denn dadurch bekommen alle ein besseres Systemverständnis.

Hilfreiche Fragen:

Welche Kernfunktionen werden benötigt, um die Anwendungsfälle auszuführen?

System-Schnittstellen

Wenn wir über Produkte reden, dann ist eine Systemabgrenzung wichtig. Nur so kann für alle Beteiligten klar festgelegt werden, über welches System geredet wird. Gleichzeitig sind Schnittstellen auch typischerweise die Stellen, an denen die meisten Fehler entstehen. An realisierten Komponenten haben die Entwickler selbst ein großes Interesse und möchten ein positives Ergebnis schaffen – die Schnittstellen zwischen Systemen jedoch bleiben meiner Erfahrung nach sehr oft schlecht abgestimmt.

Systeme können über ihre Schnittstellen Informationen, Energie oder Stoffe austau-schen – Schnittstellen sind also sehr essentiell: Bei unserer Kaffeemaschine sind nicht nur der Stecker für das Netz und die Übertragung von Energie eine Schnittstelle. Wir haben auch die Schnittstelle zur Wasserleitung, über die der Stoff Wasser ausgetauscht wird. Und schließlich gibt es auch Schnittstellen zum Menschen: Bedienknöpfe sind eine Schnittstelle in Form von Druckenergie, und auch das Display stellt eine Schnittstelle dar, an der Informationen ausgetauscht werden. Oft sind es genau diese Schnittstellen zum Menschen, die gerne vergessen werden.

Hilfreiche Fragen:

Welche Schnittstellen zeigt die Systemabgrenzung?
externe Schnittstellen des Systems sind oft schlecht abgestimmt
transportieren Stoffe, Energie oder Informationen

Bestehende Vorgaben

Auch Vorgaben an das System müssen klar definiert sein. Das können beispielsweise Vorgaben zur Versorgungsspannung sein, doch auch Vorgaben zu Standards und Normen, Klima¬bedingungen, Gewicht, Größe, (Software-)Architektur, Hap¬tik, Ergonomie, Verpackung usw. sollen hier beschrieben werden. In der Regel sind Constraints nicht-funktionale Anforderungen, die man weiter in technische Vorgaben und Stakeholder-Vorgaben aufteilen kann, um sie besser auseinanderzuhalten.

Hilfreiche Fragen:

Welche nicht verhandelbare Vorgaben des Auftraggebers existieren?
- Beispiele: Versorgungsspannung, Größe, Gewicht, logische Protokolle
Was schreibt der Gesetztgeber vor, was eingehalten werden muss?
- Beispiel: Standards und Normen