ventureworks blog

Die Kunst der Spezifikation

by maxdiez

Die Entscheidung ist also gefallen. Ein Unternehmer ist mit einer Idee für eine mobile App zu uns gekommen, wir haben gemeinsam das Geschäftsmodell durchleuchtet, noch eine Konkurrenzanalyse durchgeführt und sind endlich zu dem Schluss gekommen, dass eine Durchführung realistisch ist und wirtschaftlich lohnend sein könnte. Ein Budget wurde festgesetzt, das eine Umsetzung der Idee in Form eines Minimum Viable Product (MVP) erlaubt. Ein MVP ist eine erste Version des Produkts, die sich auf den nötigsten Umfang beschränkt – also den Kernnutzen für den Kunden in sich trägt, aber darüber hinaus auch nicht viel mehr. Aufgrund der damit verbundenen, überschaubaren Entwicklungskosten kann ein solches MVP einen Proof of Concept der Idee liefern, ohne gleich riesige finanzielle Aufwände zu erzeugen. Um letztere konsequent klein zu halten, wurde darüber hinaus entschieden, die Entwicklung in einem Drittland – also offshore – durchzuführen. Neben der Auswahl des passenden Entwicklers ist hierbei jedoch die Spezifizierung des zu entstehenden Produkts eine der grossen Achillesfersen des Softwareprojekts.

Die Projektspezifikation bei ventureworks

Der Umfang und die Form der Spezifikation eines Softwareprojekts variiert bei uns von Projekt zu Projekt und von Entwicklungspartner zu Entwicklungspartner. Im Regelfall gehören zu den Spezifikationsdokumenten:

1. „High Level Requirements“ – vereinfacht gesagt eine umfassende Liste mit den Anforderungen an die zu entwickelnde Software in Stichpunktform.
2. „Screens“ – ein Entwurf der Benutzeroberfläche, der anzeigt, welche Steuerelemente wo platziert sein sollen. 
3. Ablaufdiagramme – eine schematische Übersicht über die Abläufe in dem Programm und die entsprechend benötigten Benutzereingaben sowie die erwarteten Reaktionen der Software.
4. „Use Cases“ – eine Beschreibung des Funktionsumfangs der zu schaffenden Software in Form strukturierten Fliesstexts. Use Cases basieren auf den High Level Requirements und binden die Screens wie die Ablaufdiagramme ein. 
5. Ein Prototyp – eine interaktive, jedoch nicht voll funktionsfähige Abbildung des Funktionsspektrums und der Abläufe. Erstellt beispielsweise mit Axure – Simon berichtete.

Insider mögen nun schmunzeln – der eine oder andere vorgenannte Begriff ist auch in einschlägigen IT-Beraterkreisen bekannt. Grosse IT-Unternehmen setzen nämlich auf ganz ähnliche Dokumente, allerdings natürlich merklich bürokratisierter Form.

So sehen High Level Requirements (HLRs) aus

An dieser Stelle soll heute im Besonderen von den HLRs die Rede sein. Dies, weil diesen Spezifikationen aus vielerlei Hinsicht eine wichtige Rolle zukommt (siehe hierzu der Abschnitt „Die Rolle der High Level Requirements“ weiter unten).

Normalerweise stehen am Anfang der Spezifikation einer oder mehrere Workshops mit dem Unternehmer, in deren Rahmen wir gemeinsam die Eckpunkte der Applikation festlegen – was soll sie können, was ist der Kundennutzen, und wie soll das ganze aussehen? Von den Protokollen und Flipcharts dieser Treffen gehen wir aus und machen uns an die Arbeit: Die Rohfassung der HLRs entsteht. Dabei halten wir die gesamten Informationen in einer Exceltabelle fest, wobei Art, Umfang und Inhalt der Spezifikationen abhängig von den technischen Rahmenbedingungen variieren können. Normalerweise sind in einer solchen Tabelle folgende Spalten zu finden:

• Nummer des Requirements – OK, das ist ein Nobrainer!
• Typ der Anforderung – technisch oder funktional: Funktionale Anforderungen treten gegenüber dem Benutzer in Erscheinung. Ein Beispiel hierfür ist das Erscheinen einer Warnmeldung. Die technische Anforderungen bemerkt der Benutzer nicht direkt, aber sicher dann, wenn sie fehlen (Beispiel: welche Daten sollen wo gespeichert werden).
• Gruppierung der Anforderungen: Mehr und mehr Applikationen haben einen Client (also beispielsweise eine App, die der Benutzer bedient) und einen Server (der letztlich bestimmte Funktionen ausführt, wie beispielsweise das Speichern von gewissen Daten). Bei den Anforderungen muss definiert werden, welche serverseitig umgesetzt werden soll, und welche clientseitig. Dies hat grosse Auswirkungen auf die Nutzungsszenarien der Applikation. Beispiel: Wenn wir definieren, dass der Spielstand eines Spielers auf dem Server gespeichert werden soll, dann hat das den Vorteil, dass dieser immer noch verfügbar ist, wenn sich der Benutzer ein neues Gerät zugelegt hat. Ausserdem können die Daten ausgewertet und für die Weiterentwicklung der Software verwendet werden. Ein Nachteil ist aber, dass der Spielstand nicht gespeichert werden kann, wenn der Benutzer gerade keine Internetverbindung hat (eigentlich können die Daten schon gespeichert werden, aber nur mit einem grösseren technischen Aufwand).
• Subgruppierung der Anforderungen: Oftmals besitzen Applikationen mehr als einen Nutzungsmodus. Mittels der Subgruppierung ordnen wir Anforderungen ihrem Nutzungsmodus zu. So ist beispielsweise das „Speichern einer Telefonnummer“ in den Einstellungen etwas ganz anderes als im „Anrufmodus“ einer Applikation.
• Use Case: Manchmal sind Funktionen nur in einem bestimmten Anwendungsszenario sinnvoll. Dann informiert diese Spalte darüber, in welchem Use Case diese Funktion weiter ausspezifiziert ist.
• Bezeichnung der Anforderung: Möglichst konzise Benennung derselben :-)
• Priorität: Hoch, mittel, niedrig. Sehr praktisch, denn so können wir und der Entwickler entscheiden, welche Funktionen als erstes stehen müssen – und welche, sollte das Budget vorher aufgebraucht sein, aufgrund ihrer niedrigen Priorität vorerst unter den Tisch fallen können.
• Release: Oftmals haben wir gemeinsam in unseren Meetings deutlich mehr Ideen und Funktionen erdacht, als sich in einem ersten Schritt umsetzen lassen. Dies gilt umso mehr für MVPs. Mit dem Release wird angezeigt, in welcher Version die Funktionalität umgesetzt werden soll. Damit versteht der Entwickler (in einer idealen Welt), dass auf den jetzt geschaffenen Funktionen noch aufgebaut wird, und kann dies bei der derzeitigen Programmierung berücksichtigen (wie gesagt, in einer idealen Welt :-)). Und wir vergessen die mühsame erfunden genialen Funktionen nicht so leicht :-)
• Beschreibung: Eine möglichst wasserdichte Beschreibung der erwarteten Funktionalität. Hierzu geht Joel on Software sehr gut ins Detail. Dabei wird man sich gar nicht mehr so „high-level“ fühlen, und das ist auch in Ordnung. In dieser Hinsicht ist der Titel zugegebenermassen irreführend!
• Status: Der Stand des Requirements. Approved = alle im Prozess eingebundenen Entscheider haben zugestimmt. Rejected = zurückgewiesen. Und so weiter.

Wie gesagt, gibt es je nach Natur des Produkts mehr oder weniger solcher Spalten und damit mehr oder weniger solcher Daten.

HLRs stehen. Was jetzt?

Haben wir uns mit dem Unternehmer auf die HLRs geeinigt, beginnen wir auf deren Basis, die entsprechenden Funktionalitäten in Use Cases, Screens und den Prototypen umzusetzen. Dabei merkt man dann wieder an zahlreichen Stellen, wo etwas vergessen wurde bzw. nicht genau genug beschrieben wurde. Erfahrungsgemäss ändern wir jedes einzelne Requirement ca. fünfundzwanzig Mal. Dies schliesst zahlreiche Peer Review-Schleifen mit ein. Dann geht es ab an den Entwickler!

Die Rolle der High Level Requirements

Das ganze hört sich jetzt vielleicht sehr bürokratisch und wenig startup-mässig an. Dennoch hat unsere Erfahrung gezeigt, dass die HLRs unersetzbar sind:

1. Sie dienen in der Abstimmung zwischen dem Unternehmer, uns und dem Entwickler als rechtlich bindendes Glied. Sie sind damit die Basis, auf welcher das Projekt durchgeführt wird und schliesslich die Endresultate gemessen werden. Ist eine Funktion dort nicht spezifiziert, haben wir kein Recht auf Nachbesserung gegenüber dem Entwickler – schliesslich war sie nicht angegeben!
2. Die HLRs ist mit den Use Cases die letzte Stufe an Spezifikation, die auch ein Nichttechniker versteht. Damit werden sie für den Gründer im Regelfall zur vorläufigen Manifestation seines gesamten Projekts aus technischer Perspektive.
3. Da die HLRs einzelne Funktionen so schön auftrennen und mit Nummern versehen, können die weiteren Spezifikationen darauf basierend verteilt im Team erstellt werden, ohne dass man sich gegenseitig in die Haare bekommt. PS: Excel hat super Teamarbeitsfunktionen, ohne dass es hierfür einen aufwändigen Server benötigen würde.

Fazit: Nicht perfekt, aber eine gute Annäherung

Auch uns bleibt nichts anderes übrig, als uns heuristisch dem idealen Spezifikationsprozess und der idealen Form mit jedem weiteren Projekt anzunähern. Wir lernen dabei von Mal zu Mal dazu und merken jedes Mal wieder, dass selbst dann, wenn man das Gefühl hat, eine Funktion absolut wasserdicht formuliert zu haben, diese vom Entwickler noch diametral anders verstanden werden kann. Dann ist es wichtig, dass man bereits bei der Auswahl einen Entwickler gefunden hat, der an dieser Stelle Rückfragen stellt, anstatt sich mit seiner eigenen Interpretation zu begnügen.