Requirement versus Specification

Apple hat neulich mit dem iPhone 4S ein neues iPhone präsentiert, das von der Fachwelt zerrissen wurde. Im Gegensatz dazu ist das Smartphone jedoch von den Konsumenten sehr gut aufgenommen worden. Fragt sich, welche Rückschlüsse aus dieser Fehleinschätzung abgeleitet werden können.

Gerade heute war die übliche Frage mal wieder ein Thema, die da lautet „Was sollen Anforderungen, Spezifikationen, und Design-Dokumente leisten, und wer liefert sie?“. Heute will ich kurz auf die Rolle von Kundenwünschen, und auf die Rolle der Entwicklungsabteilung und damit auf das Thema „Spezifikationen“ eingehen.

Kunden müssen das Produkt mögen

Zum iPhone 4S-Launch habe ich im →Handelsblatt – MorningBriefing ein interessantes Zitat gefunden. Daraus geht hervor, daß letztendlich die Binsenweisheit doch gilt – die Kunden müssen ein Produkt mögen, und nicht die Analysten:

„Apple hat all seine Kritiker widerlegt. Der Konzern zeigt mit seinem iPhone 4S, das Sprache erkennt und selber spricht, worauf es wirklich ankommt: Die Kunden, nicht die Gemeinschaft der professionellen Technologie-Experten müssen ein Produkt mögen. Unsere Experten spüren in ihrer heutigen Geschichte dem Kundengeschmack nach – und dem eigenen Fehlurteil der vergangenen Wochen.“

In einem Entwicklungsprojekt spielen die sogenannten Requirements die Rolle der Kunden. Requirements beschreiben und quantifizieren die Marktprobleme, und stellen damit dar, welche Bedürfnisse die Kunden haben, und wie diese aussehen sollen. Im folgenden Kapitel geht es um die Frage wie Requirements umgesetzt werden, und wie daraus Spezifikationen entstehen.

Requirements, Spezifikationen, und Designs

Requirements alleine reichen nicht. Bevor eine Entwicklung stattfinden kann, ist es erforderlich die Requirements in eine funktionale Spezifikation umzusetzen. Diese Spezifikation hat die Aufgabe, genau zu beschreiben, wie die Anforderungen abgedeckt werden sollen. Sie behandelt damit das Lösungsdesign aus Kundensicht.

Um den Schritt gehen zu können, die Requirements in eine Spezifikation zu überführen, ist es oft erforderlich, die Anforderungen näher zu klären. Dies liegt daran, daß  die befragten Kunden ja die Lösung bereits kennen müßten, während sie ihre Anforderungen formulieren.

In diesem Schritt ist es daher auch wichtig darauf zu achten, daß man Requirements auf Herz und Nieren prüft. Anforderungen sind erfahrungsgemäß oft inkomplett, und sie können auch Anforderungen beinhalten, die sich so wie gefordert nicht umsetzen lassen. Diese Probleme sollte man erkennen, bevor eine Entwicklung überhaupt beginnt.

Nachdem bekannt ist, was ein Produkt aus Kundensicht leisten soll, muss man dem die technische Ausführung gegenüberzustellen, um zum Produkt zu kommen. Eine technische Spezifikation (manchmal auch „Design“ genannt) behandelt die Frage, wie die funktionelle Spezifikation in eine konkrete Entwicklung umgesetzt wird, und in welcher Technologie. In diesem Schritt sollten die Kundenanforderungen bereits genau geprüft und verstanden worden sein. Daher stehen hier eher die Umsetzungsaspekte im Vordergrund der Betrachtung.

Fehlerhafte Requirements

Requirements beschreiben, was der Markt genau will und erwartet. Fehlerhafte Requirements können demnach einen großen Einfluss auf die Projektkosten haben.

Im folgenden gehe ich auf einige Fehlerquellen ein.

• Falsche Audienz: Ein Marketing, das an den Bedürfnissen des Kunden vorbei argumentiert, wird sicher nicht sehr erfolgreich sein. Dies ist bei Requirements ähnlich, außer, daß hier die Zuhörer nicht Kunden sondern Entwickler sind. Um gute Requirement-Dokumente zu schreiben, sollte man den Entwickler im Hinterkopf haben, an den diese gerichtet sind. Normalerweise kommen folgende Merkmale gut an:
  • Entwickler sind normalerweise analytisch begabt. Daher ist ein logischer Dokumentenaufbau und Inhalt hilfreich.
  • Das Dokument sollte klar und präzise das gesamte Problem beschreiben und Angaben zu Nutzer und Nutzungkontext liefern. Eine Formulierung im Stil „das Produkt soll xyz tun“ ist hierbei hilfreicher als viele Marketingbuzzwords.
  • Die Anforderungen sollten spezifisch genug sein, damit man hiermit die Entwicklung beginnen kann, und auch im Hinblick auf Ziele und Messkriterien präzise sein. Obwohl es nicht einfach ist, sollten Requirements möglichst eindeutig formuliert sein, um so Quellen für mögliche Irrtümer auszuschliessen.
  • Die notwendigen Aspekte sollte angerissen werden (Funktionalität, Testanforderungen, generelle Qualitäten, etc).
• Anforderungen dienen alle einem Zweck. Insofern muß hinter jeder Anforderung ein konkreter Business Case stehen. Es sollte zudem genau geklärt sein, wie wichtig jedes Feature ist, und was man gegebenenfalls weglassen könnte. Hierzu ist es unerläßlich zu verstehen, „warum“ die Anforderung relevant ist/ was der Nutzer konkret erreichen will.
• Design mit Requirement verwechseln: Requirement sollten sich darauf beschränken zu klären, was die Nutzer erwarten. Konkrete Designanforderungen, welche die Lösung bereits festlegen, haben hier keinen Platz. Dieser Teil gehört dem Entwickler, und es könnte diesem auch jede Kreativität rauben, wenn die Lösung vermeintlich schon vorgegeben ist.
• Form follows function: Da man will, daß Requirements verstanden werden ist auch die Form wichtig. Zum Beispiel sind Grafiken hilfreich, und stören Rechtschreibfehler den Lesefluss.
• Fehlende Überprüfung: Wie jedes wichtige Dokument, sollten aus Requirements gegengelesen werden, um zu vermeiden, daß sich Fehler einschleichen. Solche Fehler, die man wegen eines fehlenden Reviews nicht früh im Prozess erkennt, kosten oft sehr viel Folgeaufwand und Geld.
• Den Überblick verlieren:
  • Falsche Anforderungen entstehen oft dadurch, daß man sich zuwenig mit dem Gesamtkontext des Nutzers beschäftigt hat, und letztendlich nicht verstanden hat, „warum“ und „in welcher Situation“ der Nutzer bestimmte Produktmerkmale fordert.
  • Wer Ursache und Wirkung verwechselt, kommt ebenfalls schnell auf einen falschen Pfad. Dabei ist es oft ganz einfach am Symptom herumzudoktern, und das eigentliche Problem des Nutzers zu vergessen. Hierbei entstehen leicht Komplexitäten im Produkt, die es später erschweren, das Programm einfach zu bedienen.
• Fehlerhafte Anforderungen können auch dadurch entstehen, daß man zu wenig fragt, ob die Anforderungen auch einen Sinn ergeben. Man sollte auch immer Bedenken, daß auch Kunden Fehler machen, bzw daß auch Kunden den Prozess nicht ganz verstanden haben, zu dem sie Anforderungen stellen. Um solche Probleme zu vermeiden, kann es nutzen, wenn man mit Kundengruppen, statt mit einzelnen Kunden spricht, bzw wenn man darauf achtet, daß man unterschiedliche Denkansätze berücksichtigt.

Fehlerhafte Spezifikationen

Wenn man die Anforderungen kennt, kann man daraus Spezifikationen ableiten. Eine Spezifikation ist ein umfassender Katalog vertraglich vereinbarter Leistungen und Qualitäten, die die Software liefern muss. Da dieser Katalog alle an der Leistungserstellung beteiligten Faktoren behandeln muss, ist es wichtig, daß man besondere Sorgfalt bei der Erstellung walten läßt, und, daß man regelmäßig die Spezifikation mit den Anforderungen abgleicht, oder indem man Zwischenstände mit den Leuten bespricht von denen die Anforderungen stammen.

Normalerweise erstellt die Gruppe die Spezifikation, die am besten weiss, wie das Ergebnis aussehen soll. Ein Problem hierbei: Oft sind die gewünschte Ergebnisse grundsätzlich bekannt. Es herrscht jedoch manchmal Unklarheit über die Einzelheiten oder Spezialanforderungen lassen sich nicht zweifelhaft klären (unklare Requirements). Darum sind häufige und detaillierte Absprache teamintern, und mit dem Geschäftspartner unerlässlich. Wenn solche Zwischenreviews unterbleiben, sind oft Fehler die Folge.

Während Anforderungen den Nutzer im Blick haben, d.h klären, was erwartet wird, definiert man in der Spezifikation das „Wie“ in einer Tiefe, die die Umsetzung erlaubt. Dabei entstehen normalerweise mehrere Teilspezifikationen. Oft sitzen hier auch mehrere Fakultäten am Tisch (Entwicklung, Design, Projektmanagement, Architekten,…). Eine weiter Fehlerquelle ist, wenn sich hierbei Koordinierungsfehler einschleichen, oder wenn man vergisst, die Arbeitsergebnisse unabhängig zu überprüfen/ im Gesamtzusammenhang zu Reviewen.

Einerseits muss man die Funktionalität und den Aufbau des Produkts spezifizieren, auf der anderen Seite benötigt man eine Beschreibung des User Interface, oder auch ein Testkonzept. Oft entstehen Fehler dadurch, daß man hier zu theoretisch bleibt, oder Teile vergißt.

Eine Möglichkeit, die Theorielastigkeit zu vermeiden ist, daß man Mockups oder Wireframes benutzt, um so dann schneller zu verstehen, wie die Umsetzungsideen funktionieren. Solche Mockups kann man dann z.B. mit Nutzern testen, um so zu verstehen, ob man die Anforderungen richtig verstanden hat. Unterlassene Tests führen gerne zu Fehlern.

Dabei sollten UI Spezifikationen möglichst früh entstehen, bzw eine Fehlermöglichkeit ist, daß die Details bereits feststehen, bevor man richtig weiß, wie man zu einem einfachen UI kommt. Fehler entstehen gerne dadurch, daß nicht das UI die Architektur festlegt, sondern umgekehrt.

Lebende Spezifikation

Neulich habe ich über das Thema „lebende Spezifikation“ geschrieben. Dieses Dokument wird zwischen den Schritten „Requirements“ und „Spezifikation“ verwendet.

Während eine Spezifikation normalerweise in Form eines Dokuments geschrieben wird, besteht eine lebende Spezifikation eher aus einer Art Datenbank, o.ä. in der konkrete Beispiele abgelegt werden, welche die Lösung behandeln.

Weiterführende Informationen

… im Internet

Im Internet finden Sie weiterführende Artikel:

• →Pragmatic Marketing’s On Reqs and Specs
• →What is living specification

… auf www.Produkt-Manager.net

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

• →Was tun wenn man mehr Anforderungen hat, als Zeit….?
• →Anforderungen müssen konkret formuliert sein
• →SSNiF (Stakeholder, Situation, Need, Feature) Analyse

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, Oktober 24th, 2011 at 7:29 pm. It is filed under Agile&Scrum, Innovation, Thema des Tages and tagged with Anforderungen, Rollin, SCRUM. You can follow any responses to this entry through the RSS 2.0 feed.