SSNiF (Stakeholder, Situation, Need, Feature) Analyse

Gerade in der Entwurfsphase einer Software hat man auf der einen Seite die Wünsche der „Kunden“. Auf der anderen Seite stehen die einzelnen Realisierungen. Die Analysemethode, um die es heute geht, hilft dabei die Produktanforderungen, und die Featureentwicklung zusammenzubringen.

Die Stakeholder-Stituation-Need-Feature Analyse kann dabei auf verschiedenen Leveln angewendet werden, und sie hilft sowohl bei der Strukturierung, als auch bei der Qualitätsprüfung der Produktanforderungen.

Methodenüberblick

In der Anforderungsphase lautet die Aufgabenstellung, die Situation des späteren Anwenders so aufzunehmen, daß es möglich ist das gesamte Softwareprojekt in einem Design zu beschreiben. In der darauf folgenden Designphase werden den einzelnen Anforderungen die einzelnen Realisierungsmöglichkeiten, bzw Features gegenübergestellt.

Da die Anforderungen letztendlich festlegen, wie das Design aussehen wird, sollten Anforderungen komplett sein. Auf der anderen Seite ist es wichtig, daß sie die Nutzererwartungen adäquat abdecken. Um hierbei nichts zu vergessen, ist eine konsistente Methode notwendig, um die es im folgenden Absatz geht.

Elemente der Methode

In einem Softwareentwicklungsprojekt stellt die Stakeholder-Situation-Need-Feature-Analysemethode folgende Informationen gegenüber:

• Stakeholder (auch Nutzer oder Kunde) – Wer ist der Abnehmer/ Adressat des zu entwickelnden Features?
• Situation – Wie stellt sich die Situation für den Stakeholder dar/ wie lautet seine Aufgabenstellung?
• Need/ Bedürfnis – Welche Bedürfnisse hat der Abnehmer in der konkreten Situation?
• Feature/ Funktionalität – Welche Funktionalität hilft dem Stakeholder in der konkreten Situation bei der Deckung der Bedürfnisse?

Normalerweise fängt man dabei auf einem höheren Level an, und beschreibt das Gesamtsystem auf einer relativ hohen Abstraktionsebene. Auf diesem Level geht es um den Überblick, und um die Komplettheit der Anforderungen. Bei der Prüfung auf Komplettheit hilft das hohe Abstraktionslevel.

In der späteren Designphase steht die einzelne Funktionalität im Vordergrund, und die Zuordnung von Anforderung und Feature. In dieser Phase benutzt man dieselbe Analysemethode auf einem wesentlich feingrannulareren Abstraktionslevel.

Beispiel – Phase „Überblick“

Das folgende Beispiel zeigt das System Urlaubsreise auf einem hohen Niveau:

• Der Autofahrer (Stakeholder) fährt seit mehreren Stunden auf der Autobahn, und möchte eine Pause machen, da er müde ist (Situation). Er hat das Bedürfnis, sich die Beine zu vertreten, und etwas zu essen (Bedürfnis). Er fährt hierfür die nächste Raststätte an (Feature).
• Die Raststätte (Stakeholder) steht in einem harten Wettbewerb mit anderen Raststätten, und ist darauf angewiesen, um seine Kunden zu werben (Situation). Sie benötigt daher eine Küche, die schmackhafte Gerichte zu einem guten Preis anbieten kann, und ein ansprechendes Ambiente (Bedürfnis). Er sucht daher einen gut ausgebildeten Koch (Feature).

Auf diesem Level ist es möglich, die großen „funktionalen“ Bereiche zu identifizieren, und man kann den Überblick über die Gesamtaufgabenstellung behalten, vor der der Stakeholder steht. Gleichzeitig erkennt man die wesentlichsten Informationen, die einen in die Lage versetzen zu verstehen, wer, was warum benötigt, und wie man sein Bedürfnis befriedigen kann.

Jedoch wären die gezeigten Anforderungen noch wesentlich zu abstrakt, um konkrete Produktentwicklungsschritte einzuleiten.

Beispiel – Detail-Phase

Die folgenden Beispiele zeigen „Low-Level-“ Anforderungen, die bereits so detailliert sind, daß man damit konkrete Features entwickeln könnte. Es ist allerdings auch gut zu sehen, daß auf diesem Abstraktionslevel der Überblick verloren geht, und gesondert sichergestellt werden muss.

• Der Raststättenbesucher (Stakeholder) stellt sein Auto auf einem Parkplatz ab, den er auch im dunklen finden können sollte (Situation). Er benötigt daher Leitstreifen oder ähnlich, die die Parkfläche markieren (Bedürfnisse). Der Parkplatz wird deshalb beleuchtet (Feature).
• Der Restaurantkunde (Stakeholder), der viele Stunden gefahren ist (Situation) will sich nach dem Parken erst einmal frisch machen, ohne dabei die Restaurantgäste zu stören (Bedürfnis). Das Bad sollte noch vor der Eingangstür zum Restaurant angeordnet sein (Feature).
• Auch die Vegetarier unter den Autofahrern (Stakeholder) haben keine Ausweichmöglichkeit (Situation) und wollen fleischlos, aber geschmackvoll essen (Bedürfnis). Es wird daher jeden Tag mindestens ein vegetarisches Essen angeboten (Feature).

Nutzen

Die ist nur ein kleiner Ausschnitt aus den Charakteristika der Methode. Alles in Allem halte ich sie für sehr empfehlenswert.

• Die vorgestellte Methode hat aus meiner Sicht einen sehr hohen Nutzwert insbesondere, weil es mit derselben Methode gelingt High-, und Low-Level-Anforderungen zu beschreiben, ohne die Methode zu wechseln. Dies unterstützt sehr gut die Realitäten in einem Projekt, wo man ja auch zunächst auf hohem Niveau startet, und sich dann auf die Detailebene vorarbeitet.
• Es ist mit dieser Methode möglich, auch Nicht-Experten einzubinden, sei es nun im Scrumteam, oder sei es im Gespräch mit Kunden. Letztendlich ist sie selbsterklärend, und in sich geschlossen. Sie geht zudem von der Situation der Nutzer aus, und ist deshalb bereits im Grundsatz kundenzentriert. Besonders vorteilhaft ist hierbei, daß die Analysemethode einen eingebauten Reality Check besitzt. Schliesslich werden keine Features ohne konkreten Bedarf entwickelt.
• Die Methode ist zudem schnell und unkompliziert. Dies ist dann wichtig, wenn man zum Beispiel einen konkreten, beobachteten Arbeitsablauf aufnimmt, und darauf angewiesen ist, möglichst nicht zu stören. Dort würde man ggfs mit den Situationen und Bedürfnissen anfangen, um dann später auf die Features zu kommen.
• Dadurch daß man sich durch Situation und Bedürfnis arbeitet, erhält man zudem ein gutes Gefühl zu dem „Warum-Will-der-User-das-Feature-haben„. Dies ist deshalb wichtig, wie ich finde, da es eigentlich am einfachsten ist, wenn man versucht, wie der User zu denken. Dafür muss man aus der Situation verstehen, warum er bestimmte Bedürfnisse hat, und man muss sicher sein, daß diese Bedürfnis sinnvoll ist. Gerade die Überprüfung der Sinnhaftigkeit einer Anforderung hilft einem konkret zu verstehen, ob man es mit einer allgemeingültigen Arbeitsweise zu tun hat, und nicht etwa um einen fehlerhaften Prozess, den man sonst unkritisch nachbauen würde.

Weiterführende Informationen

… im Internet

In einem Blog mit dem Titel →Steal This Idea finden Sie eine Fortsetzungsreihe zu der hier angerissenen Methode, die aus vier Teile besteht, und das Thema im Detail darstellt →Stakeholder Analysis. Der Blogautor Philip Haine arbeitet generell in den Bereichen Requirements, Entwicklung, Produktkonzept, Product Vision, Design, etc. Seine Site lohnt einen weiteren Blick, wie ich finde.

…auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema:

• →Die Güte der Nutzungserfahrung entscheidet über den Erfolg
• →Design Thinking – Hauptphasen
• →Role of the Product Vision when Development goes Agile

Kontakt

Das Original dieses Artikels ist auf →Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

This entry was posted on Montag, Juli 25th, 2011 at 8:45 pm. It is filed under Innovation, Thema des Tages and tagged with Agile Development, Anforderungen, Product-Concept, Rollin, SSNiF, Werkzeuge. You can follow any responses to this entry through the RSS 2.0 feed.