Pflichtenheft, User Story oder Prototyp: wie du Anforderungen festhältst

Was Anforderungen festhalten überhaupt heisst

Wer Software bauen lässt, steht früh vor einer simplen, aber folgenreichen Aufgabe: das, was im Kopf existiert, so festhalten, dass ein anderer Mensch es bauen kann. Genau hier setzen Pflichtenheft, User Story und Prototyp an. Alle drei beantworten dieselbe Grundfrage, nämlich was soll dieses Produkt tun, aber sie tun es auf völlig verschiedene Weise, mit verschiedenen Stärken und verschiedenen Fallen. Ein Pflichtenheft beschreibt das System in Prosa. Eine User Story beschreibt einen Nutzer und sein Ziel. Ein Prototyp zeigt das fertige Produkt, ohne dass dahinter etwas läuft.

Welchen Weg du wählst, entscheidet mehr, als die meisten erwarten. Er prägt, worüber im Projekt gestritten wird, wann Missverständnisse auffliegen und wie teuer eine Änderung später ist. Gehen wir die drei der Reihe nach durch, schauen uns an, wo jeder glänzt und wo er bricht, und klären am Ende die Frage, die wirklich zählt: was nimmst du für dein Vorhaben?

Das Pflichtenheft: alles aufgeschrieben, bevor es losgeht

Das Pflichtenheft ist der klassische Weg, und für viele klingt er nach Gründlichkeit. Du schreibst auf, was das System können soll, Funktion für Funktion, Regel für Regel, am besten lückenlos. Ein Lastenheft hält dabei fest, was der Auftraggeber will, das Pflichtenheft beschreibt, wie der Auftragnehmer es umsetzt. In der Praxis verschwimmt die Grenze, und übrig bleibt ein dickes Dokument, das den vollständigen Funktionsumfang in Worten beschreibt.

Der Reiz ist offensichtlich. Alles steht schwarz auf weiss, jede Partei kann sich darauf berufen, und bei einer Ausschreibung lassen sich Angebote vergleichen. Für klar umrissene Vorhaben mit stabilen, bekannten Regeln ist das stark. Wenn eine Lohnabrechnung gesetzliche Vorgaben umsetzen muss oder eine Schnittstelle ein dokumentiertes Format bedienen soll, gehören diese Regeln präzise notiert, und ein Pflichtenheft ist dafür das richtige Werkzeug. Was sich exakt sagen lässt, sollte exakt gesagt werden.

Das Problem beginnt dort, wo Software eben nicht aus bekannten Regeln besteht, sondern aus Annahmen darüber, was Nutzer brauchen. Prosa ist ein erstaunlich schlechtes Medium, um ein interaktives Produkt zu beschreiben. Lies den Satz der Nutzer kann seine Buchungen filtern und exportieren. Klingt eindeutig. Filtern nach was, mehrere Kriterien gleichzeitig, was passiert bei keinem Treffer, exportiert wird wohin, in welchem Format, mit welchen Spalten? Jeder dieser Punkte ist eine stille Entscheidung, die der Leser unbewusst trifft, und Auftraggeber und Entwickler treffen sie selten gleich. Das Dokument fühlt sich vollständig an und ist es nie.

Warum ein dickes Pflichtenheft so oft scheitert

Drei Kräfte arbeiten gegen das umfangreiche Pflichtenheft, und sie verstärken sich gegenseitig.

Die erste ist die Scheingenauigkeit. Fünfzig Seiten erzeugen das Gefühl, alles sei geklärt. Tatsächlich verschiebt das Dokument die offenen Fragen nur nach hinten, an die Stelle, wo sie am teuersten zu beantworten sind: in die Umsetzung. Jede Lücke, die beim Schreiben übersehen wurde, taucht beim Bauen wieder auf, und dann diskutierst du nicht mehr über einen Satz, sondern über bereits geschriebenen Code.

Die zweite Kraft ist die Veränderung. Ein Pflichtenheft friert einen Wissensstand ein, der zum Zeitpunkt des Schreibens am kleinsten ist. Du weisst über dein Produkt nie weniger als am Anfang. Sobald die ersten Teile laufen und echte Menschen sie benutzen, lernst du Dinge, die jede Vorabbeschreibung umstossen. Ein starres Dokument macht aus diesem Lernen einen Konflikt: Jede neue Erkenntnis wird zur Änderung am Vertrag statt zum normalen Fortschritt. Wie sehr sich Anforderungen unterwegs verschieben, ist einer der Gründe, warum SaaS-Vorhaben kippen, und warum SaaS-Projekte scheitern geht dem genauer nach.

Die dritte Kraft ist die Distanz zur Realität. Niemand kann fünfzig Seiten Prosa im Kopf zu einem laufenden Produkt zusammensetzen, weder der Auftraggeber beim Lesen noch der Entwickler beim Bauen. Beide bilden sich ein Bild, und die beiden Bilder weichen voneinander ab, ohne dass es jemand merkt, bis das Gebaute auf dem Tisch liegt. Genau dann, am Ende, fällt der teuerste Fehler auf. Ein gutes Verfahren legt Missverständnisse so früh wie möglich offen. Das dicke Pflichtenheft tut das Gegenteil.

Die User Story: ein Nutzer, ein Ziel, ein Gespräch

Eine User Story dreht den Blickwinkel. Statt das System zu beschreiben, beschreibt sie einen Menschen und das, was er erreichen will, meist in einem einzigen Satz: Als Disponentin will ich offene Aufträge nach Lieferdatum sortieren, damit ich die dringenden zuerst plane. Drei Teile, eine Rolle, ein Wunsch, ein Grund. Mehr nicht.

Dass eine Story so kurz ist, ist ihre eigentliche Stärke, nicht ihre Schwäche. Sie behauptet gar nicht, vollständig zu sein. Sie ist ein Platzhalter für ein Gespräch, das noch kommt. Wenn die Story dran ist, setzen sich Auftraggeber und Entwickler zusammen und klären die Details, die ein Pflichtenheft vorab zu erschlagen versucht. Der entscheidende Unterschied: Diese Klärung passiert zum spätestmöglichen verantwortbaren Zeitpunkt, wenn das Wissen am grössten und der Kontext frisch ist, nicht Monate vorher auf Vorrat.

Dazu kommt, dass eine Story immer beim Nutzen ansetzt. Sie zwingt zur Frage, wem das eigentlich hilft und wozu. Funktionen ohne erkennbaren Nutzer fallen so früh auf, statt sich durch ein Lastenheft zu mogeln. Und weil jede Story für sich steht, lassen sie sich ordnen: die wertvollsten zuerst, der Rest später oder gar nicht. Das passt genau zu der Arbeit, einen Produktkern zu finden, statt alles auf einmal zu wollen, ein Thema, das die erste Funktion und den Produktkern finden vertieft.

Grenzenlos ist auch dieser Weg nicht. User Stories leben vom Gespräch, und wo dieses Gespräch fehlt, weil der Auftraggeber nicht greifbar ist oder niemand entscheidet, bleiben sie hohle Einzeiler. Für hart geregelte Sachverhalte taugen sie schlecht: Eine steuerliche Berechnung lässt sich nicht in als Nutzer will ich korrekt besteuert werden fassen, da brauchst du die exakte Regel, also ein Stück Pflichtenheft. Und eine Sammlung von Stories ergibt noch kein Gesamtbild. Wie die Teile zusammenwirken, ob der Gesamtablauf stimmig ist, das zeigt eine Liste von Sätzen nicht.

Der Prototyp: zeigen statt beschreiben

Genau diese letzte Lücke füllt der Prototyp. Statt das Produkt zu beschreiben, zeigt er es. Meist ist er ein klickbares Modell aus einem Design-Werkzeug, das aussieht und sich anfühlt wie die fertige Anwendung, dahinter aber leer ist. Keine Datenbank, keine Logik, nur Bildschirme, durch die man sich klickt, als wäre alles schon da.

Die Wirkung ist schwer zu überschätzen. Ein Prototyp beseitigt fast die gesamte Mehrdeutigkeit, an der Prosa scheitert. Der Satz über das Filtern und Exportieren löst Diskussionen aus, der Prototyp zeigt einfach das Filter-Menü, die Ergebnisliste, den Export-Knopf und den leeren Zustand bei null Treffern. Was vorher ausgehandelt werden musste, sieht jeder auf einen Blick gleich. Deshalb gilt: Bei allem, wo es um Bedienung, Abläufe und Form geht, sagt ein Prototyp mehr als fünfzig Seiten Text, und zwar sofort.

Noch wertvoller ist, was er an Lernen ermöglicht. Setz fünf künftige Nutzer vor den Klick-Dummy und schau zu. Wo zögern sie, welchen Knopf finden sie nicht, wo erwarten sie etwas anderes? Diese Missverständnisse fliegen auf, bevor eine Zeile Code existiert, und eine Korrektur kostet hier fast nichts: ein Element verschieben, eine Beschriftung ändern. Im fertig gebauten Produkt kostet dieselbe Korrektur ein Vielfaches, weil Code, Datenmodell und Tests daran hängen. Der Prototyp dreht die teuerste Eigenschaft des Pflichtenhefts um: Er holt das Aufdecken von Fehlern an den Anfang.

Was ein Prototyp nicht kann, gehört genauso klar gesagt. Er zeigt die Oberfläche, nicht die Regeln dahinter. Wie eine Berechnung im Detail läuft, welche Datenschutz-Pflichten gelten, wie sich das System bei tausend gleichzeitigen Zugriffen verhält, davon zeigt ein Klick-Dummy nichts. Er kann wunderschön sein und ein Produkt darstellen, das technisch nicht machbar ist. Form geklärt heisst eben nicht Machbarkeit geklärt. Und ein Prototyp verführt: Weil er so fertig aussieht, halten ihn manche für fast fertig, obwohl dahinter noch gar nichts steht. Der Unterschied zwischen sieht fertig aus und ist gebaut ist riesig, und MVP, Prototyp und Proof of Concept trennt diese Begriffe sauber.

Welcher Weg für dein Vorhaben, und warum es selten nur einer ist

Die nüchterne Antwort: Du kombinierst, und zwar nach der Art der Frage, die gerade offen ist. Die drei Werkzeuge konkurrieren nicht, sie decken verschiedene Schichten desselben Produkts ab.

Für harte, geregelte Sachverhalte schreibst du präzise auf, was gilt. Steuerlogik, Schnittstellen-Formate, gesetzliche Pflichten, Berechtigungen, das gehört exakt notiert, ein gezieltes Stück Pflichtenheft. Was sich genau sagen lässt, sagst du genau. Hier ist Prosa stark, weil es um eindeutige Regeln geht, nicht um Bedienung.

Für Bedienung, Abläufe und Form baust du einen Prototyp. Alles, wo es darauf ankommt, dass Menschen sich zurechtfinden, klärst du, indem du es zeigst, nicht beschreibst. Das ist fast immer schneller und führt zu weniger bösen Überraschungen am Ende.

Und für die Frage, was als Nächstes wertvoll ist, nimmst du User Stories. Sie ordnen die Arbeit nach Nutzen und halten das Gespräch am Laufen, während gebaut wird. So entsteht kein eingefrorenes Dokument, sondern ein lebendiger, nach Wert sortierter Plan.

Was du vermeidest, ist der Versuch, eine Schicht mit dem falschen Werkzeug zu erschlagen. Bedienung in Prosa ist Quälerei, Steuerregeln als User Story sind gefährlich, und ein Prototyp ersetzt keine technische Klärung. Die meisten gescheiterten Spezifikationen, die wir sehen, sind kein Mangel an Sorgfalt, sondern Sorgfalt am falschen Ort: ein perfektes Pflichtenheft für etwas, das man hätte zeigen müssen.

Warum wir lieber zeigen als beschreiben

Dass wir Prototyp und kurze, gut sortierte Stories über das dicke Pflichtenheft stellen, ist keine Mode, sondern kommt aus dem eigenen Betrieb. Wir bei Wertstifter bauen unsere Produkte nicht nur, wir betreiben sie selbst. Wortfreunde und Reazon sind beide aus einem bewusst kleinen Kern gewachsen und stehen seither im täglichen Einsatz. In diesem Doppel von Bauen und Betreiben haben wir am eigenen Leib gelernt, dass jede Vorab-Spezifikation an der Realität schrumpft, sobald echte Nutzer das Produkt anfassen. Ein Dokument, das vorgibt, alles vorherzusehen, hält dieser Begegnung nie stand.

Darum klären wir, was sich exakt regeln lässt, präzise und ohne Umschweife, und alles andere zeigen wir früh, in klickbarer Form, an echten Menschen getestet, bevor teurer Code entsteht. Reine Agenturen, die nach dem Start aussteigen, spüren die Folgen einer zu starren Spezifikation selten, weil sie längst weg sind, wenn der Betrieb die Wahrheit ans Licht bringt. Wer baut und bleibt, denkt anders über Anforderungen. Wie diese Haltung in echte Produktarbeit übergeht, steht in unserer SaaS-Produktentwicklung.

Merk dir die Aufteilung, dann wählst du nie wieder das falsche Werkzeug. Schreib präzise auf, was eine feste Regel ist. Zeig, was Menschen bedienen sollen. Und ordne nach Nutzen, was als Nächstes dran ist. Drei Wege, drei Aufgaben, und die Klarheit, in jedem Moment zu wissen, welcher davon gerade zählt.