Wie erstellt man eine Software Requirements Specification (SRS) für das MVP eines Startups?

Wir arbeiten im App-Development und treffen täglich Menschen, die mit uns über ihre Geschäftsideen sprechen möchten. Und wie zu erwarten, hat jede Unternehmerin und jeder Unternehmer eine andere Idee, bietet unterschiedlichen Mehrwert und versucht, verschiedene Kundenbedürfnisse zu erfüllen. Trotzdem tauchen immer wieder dieselben Fragen auf: Wie lange dauert es, die App zu entwickeln? Wie viel wird das kosten? Wann kann mit der Arbeit begonnen werden? Das sind Fragen, auf die jedes Team Antworten haben muss, bevor es loslegt.

Was ist eine Software Requirements Specification?

Wir sehen die Software Requirements Specification als Roadmap für die Produktentwicklung. Wenn Sie ein Unternehmen aufbauen, rät Ihnen jeder zu einem Businessplan. Der kann auf dem Weg angepasst werden, aber Sie brauchen ihn, um Ihren Fortschritt zu verfolgen und das Kommende planen zu können. 

Dasselbe gilt für Ihre Software. Sie ist zwar Teil Ihres übergeordneten Businessplans, doch die Entwicklung Ihrer Anwendung ist so komplex, dass sie ihren eigenen Plan verdient. Ohne einen solchen in die Entwicklung zu starten, ist, als würden Sie ein Schiff ohne Karte übernehmen – mit einer klingonisch sprechenden Crew an Bord.

Wie erstellt man eine Software Requirements Specification?

Pro Sekunde werden 3 neue Start-ups gegründet – das sind 11.000 pro Stunde bzw. 260.000 am Tag. Wenn Sie nicht schnell genug entwickeln, fallen Sie sehr wahrscheinlich hinter die neue Konkurrenz zurück. Es ist entscheidend, dem Markt voraus zu sein, und ein guter Plan (sprich: SRS) ist genau das, was Sie brauchen.

Wählen Sie den richtigen Tech-Stack

Eine Spezifikation enthält alle funktionalen Anforderungen Ihres zukünftigen Produkts. Mit diesen Informationen können Sie die richtigen Technologieentscheidungen treffen. Berücksichtigen Sie Performance, Skalierbarkeit, zukünftige Wartungskosten und Integrationen – um Ihre App einerseits nicht unnötig zu verkomplizieren und sie andererseits für rapides Wachstum vorzubereiten.

Wählen Sie das richtige Team

Eine gut geschriebene Software Requirements Specification hilft Ihnen, Ihren Bedarf in Bezug auf Tech-Stack und Projektumfang zu präzisieren – und damit wird auch Ihr Recruiting-Bedarf glasklar. So können Sie ein Team aufbauen, dessen Kompetenzen perfekt zum Projekt passen. Schließlich müssen Sie wissen, worum es bei der Aufgabe geht, bevor Sie die richtigen Leute dafür finden, oder?

Jagen Sie keinen Wasserfällen hinterher...

Wenn Sie bei Google nach ‘Project Specification Template’, ‘SRS example’ oder ‘how to create SRS’ suchen, stoßen Sie höchstwahrscheinlich auf riesige, verwirrende Dokumente mit mehreren Dutzend Seiten Text und Detailbeschreibungen. Das passt so gar nicht zum Lean-Startup-Ansatz, oder? Diese monströsen Dokumente sind in der Regel Relikte des Wasserfallmodells. Dabei musste das Projekt gleich zu Beginn von A bis Z durchgeplant werden. Das führte zu einer Flut an Dokumenten, die sämtliche Features, Nutzerprofile usw. des Endprodukts enthalten mussten.

… bleiben Sie im Fluss

Für ein Lean-Startup ist die perfekte Lösung, eine auf das Nötigste reduzierte Version der Software Requirements Specification zu erstellen. Die über 20 Start-ups, mit denen wir bereits gearbeitet haben, haben es uns ermöglicht, einen Satz von Regeln und Best Practices zu definieren, die für die meisten Softwareprojekte gut funktionieren. Die folgenden Grundregeln sollten die Erstellung Ihrer Software Requirements Specification erheblich vereinfachen.

Best Practices für das Erstellen einer Software Requirements Specification

Jetzt Zeit investieren, später sparen

Zeit ist Geld, aber machen Sie sich nichts vor — kopfüber ohne Vorarbeit oder Planung in ein Projekt zu springen, ist verantwortungslos. Agil sein heißt, den Plan an veränderte Umstände anzupassen, nicht einfach YOLO zu machen und zu sehen, was passiert. Es muss einen Plan geben. Der Lean-Ansatz verlangt, dass wir schnell handeln und bei Bedarf leicht pivoten. Eine Spezifikation vorzubereiten mag anfangs wie Zeitverschwendung wirken, ist aber ein notwendiger Schritt, der Ihnen in der Entwicklungsphase enorm viel Zeit spart. Glauben Sie uns — wir haben es auf die harte Tour gelernt. 

Das Anforderungsdokument ist für Entwickler die zentrale Informationsquelle beim Entwurf Ihrer App, daher muss die Qualität stimmen. Richtig gemacht, ermöglicht es dem Dev-Team, Ihre Idee produktiv umzusetzen — ohne unnötige Arbeit. Ihr MVP wird mit größerer Wahrscheinlichkeit pünktlich geliefert und mit allen erforderlichen Funktionalitäten.

Seien Sie schnell, aber präzise

Ein guter Zeitspartipp: Erstellen Sie den ersten Entwurf Ihrer Spezifikation in 1–2 Stunden und holen Sie so schnell wie möglich Feedback von Ihrem Team ein. Nehmen Sie sich dann weitere 1–2 Stunden, um das Dokument mit dem erhaltenen Feedback zu aktualisieren — und Sie sind startklar. 

Unsere Erfahrung zeigt, dass die zweite Version in der Regel gut genug ist, um mit dem Entwicklungsteam zu starten. Es hat keinen Sinn, ganz am Anfang unnötige Details auszuarbeiten. Ihr MVP sollte so schlank wie möglich bleiben. Und sehr wahrscheinlich ändern Sie das Projekt ohnehin unterwegs. Bleiben Sie bei den Basics, aber stellen Sie sicher, dass Ihre Idee klar beschrieben ist.

Bringen Sie alle auf denselben Stand

Bevor Sie mit der Entwicklung beginnen, müssen Sie sicherstellen, dass Ihr Team auf dasselbe Ziel hinarbeitet und dieselbe Vision für das Projekt teilt. Planen vor dem Coden ist daher der Schlüssel zur Effektivität. Alle müssen das Gesamtprodukt, die benötigten Features, die zu implementierenden Ansichten sowie die anfänglichen Projektziele verstehen.

Machen Sie es zugänglich

Die Spezifikation sollte nicht vom PM im stillen Kämmerlein geschrieben und dem Team dann wie ein Dekret vorgelegt werden. Teilen Sie sie so, dass Ihr Team jederzeit Zugriff auf die aktuelle Version hat. Ob in Google Docs oder wo auch immer — ermöglichen Sie die Zusammenarbeit in Echtzeit. So sind alle auf demselben Stand und viele Probleme werden vermieden.

Seien Sie flexibel

Ein sehr häufiger Fehler von PMs ist, die Spezifikation zu starr zu machen und um jeden Preis an der ersten Iteration festzuhalten. Der Lean-Ansatz erfordert Flexibilität und Beweglichkeit — das gilt auch für Spezifikationen. Nach unserer Erfahrung werden die letzten 20 % (oder mehr) der Spezifikation oft während der Entwicklung vervollständigt. So können Teams ihre Apps an neue Business-Bedürfnisse anpassen, indem sie Features aus ihrem MVP entfernen oder hinzufügen.

Holen Sie Feedback ein

Zeigen Sie die erste Version Ihrer SRS unbedingt mehreren Personen. Bitten Sie sowohl technische als auch nicht-technische Freundinnen und Freunde um ihre Meinung zum Dokument. Ist es klar? Stimmt der Umfang? Sammeln Sie die Anmerkungen, setzen Sie sie in Ihrer Spezifikation um — und los geht’s. Frühes Feedback ist für Start-ups enorm wichtig — es spart Ihnen eine Menge Zeit und Geld! Bleiben Sie offen für Vorschläge und verbessern Sie die SRS kontinuierlich. Bleiben Sie agil!

Wir haben unser eigenes Software Requirement Specification Template veröffentlicht! Sagen Sie uns, was Sie davon halten! Schreiben Sie uns an hello@start-up.house.