6 Schritte zum Schreiben eines SRS-Dokuments, das funktioniert + Vorlage

6 Schritte zum Schreiben eines SRS-Dokuments, das funktioniert + Vorlage

Softwarespezifikationsdokumente werden manchmal als Artefakte angesehen, die nur für Entwickler sinnvoll sind. Ein SRS-Dokument kann jedoch noch weiter gehen und zu einem Leitfaden für Marketingspezialisten, Stakeholder, Designteams und sogar Benutzer werden.

Dieser Artikel erklärt, warum Softwaredokumentation wichtig ist und wie Sie Ihr SRS-Dokument schreiben, um es zu einem praktischen Leitfaden für alle Teamspezialisten zu machen.

Was ist ein SRS-Dokument und warum ist es wichtig?

Ein SRS-Dokument (Software Requirement Specification) ist ein Artefakt, das die Anforderungen, Erwartungen und Standards für ein zukünftiges Produkt enthält. Es kann Textdokumente, Tabellenkalkulationen, Schemata, Präzedenzfälle und andere Elemente abdecken, die die Vision des Produkts verdeutlichen. Mit anderen Worten, ein SRS-Dokument enthält eine detaillierte Beschreibung der Funktionsweise eines Produkts und der Implementierung durch das Produktentwicklungsteam.

Stellen Sie sich vor, Sie bauen ein Schiff. Sie haben eine Vision vom Mast oder Segel und können sich sogar vorstellen, wie es sich durch die Wellen bewegt. Sie benötigen jedoch strengere Details, um das Schiff auf das Wasser zu bringen.

Gleiches gilt für die Produktentwicklung. Sie haben eine klare Vorstellung von einer App, die Sie mit allen Funktionen, Designelementen und Schaltflächen erstellen möchten. Eine verbale Beschreibung der Funktionen reicht Entwicklern jedoch nicht aus, um die Idee umzusetzen.

Damit das Ergebnis mit dem Bild in Ihrem Kopf übereinstimmt, müssen Sie auf dem Papier genau erklären, wie ein Feature funktionieren soll. Ein SRS-Dokument ist ein hervorragendes Instrument zur Beschreibung solcher technischen Details.

Wer schreibt ein SRS-Dokument?

Das Schreiben eines SRS-Dokuments bedeutet, generische Beschreibungen von Funktionen, Aufgaben und Zielen in den detaillierten Plan ihrer technischen Implementierung zu übertragen.

SRS-Dokumente werden in der Regel von Produkt- und Projektmanagern oder Business Analysten verfasst, die direkt mit Kunden kommunizieren oder Benutzerforschung betreiben (die auch an Wireframes arbeiten und wissen, wie sich das Produkt verhalten soll) und zukünftige Produktanforderungen sammeln.

Inzwischen dieses Dokument. Ein gutes SRS-Dokument ist nicht nur technisch, sondern deckt auch Geschäftsziele, Metriken, Benutzerprobleme, Benutzerpersönlichkeiten usw. ab.

3 Gründe, warum ein SRS-Dokument wichtig ist

Der Gesamtwert eines SRS-Dokuments ist also klar. Hier sind die Gründe, warum Software Requirements Specification Dokumente unerlässlich sind:

SRS ist ein Kommunikationspunkt

Als lebendes Dokument dient ein SRS-Dokument als Kommunikationsplattform zwischen allen Spezialisten: entwickler, Marketingspezialisten und Mitbegründer.

Indem Manager Details in einem SRS-Dokument formell oder informell erläutern, stimmen sie mit den Kunden über die Erwartungen der Ergebnisse überein. Wenn die Änderungen an den Anforderungen vorgenommen werden, können ein Kunde und / oder ein Product Owner diese im Dokument überprüfen und validieren. Und die Entwickler sind dafür verantwortlich, diese Erwartungen zu erfüllen.

Endgültige Beschreibung der Funktionen

SRS dokumentiert die endgültigen Versionen der Software, die aus den zuvor mit Kunden diskutierten Annahmen stammen. Bei Meetings und Anrufen, Anwendertests und Interviews können sich die Produktversionen sehr oft ändern. Manchmal können sogar Produktmanager von den bestehenden Produktiterationen überwältigt werden. SRS-Datei hilft, all diese Anforderungen in einem Standard zu vereinheitlichen und Verwirrung in Bezug auf die Produktanforderungen zu beseitigen.

SRS ist ein Standardhandbuch für Produktentwickler

Neben der Beschreibung der Produktanforderungen führt das SRS-Dokument das Entwicklungsteam über die Schritte, die sie befolgen sollten, um ein Produkt zu erstellen, das ein Kunde wünscht.

Abhängig von der Organisation des Projekts können Entwickler am analytischen Teil des Projekts beteiligt sein oder nicht. In beiden Fällen müssen sie feststellen, wie das System funktionieren soll, die Anforderungen definieren und die Parameter entsprechend codieren.

Ebenso müssen QS-Experten alle technischen Aspekte verstehen, die hinter dem Produktkonzept stehen. Somit dient die SRS-Dokumentation als Standard für die Planung und Durchführung von QS-Tests.

Schließlich erhalten Designer Projekteinblicke durch SRS-Dokumente, um das Design an den Anwendungsfall anzupassen.

6 Schritte zum Schreiben eines guten SRS-Dokuments

Funktionale und nicht funktionale Anforderungen machen einen großen Teil jedes SRS-Dokuments aus. Produktmanager nehmen diese Anforderungen nicht einfach aus dem Nichts. Sie sind das Ergebnis einer genauen Kommunikation mit Kunden und eingehender Benutzer- und technischer Forschung. Hier sind die wichtigsten Schritte zum Schreiben einer hervorragenden SRS-Dokumentation:

Schritt 1. Kommunikation mit einem Stakeholder

Wir entfernen die erste Schicht der Unsicherheit, indem wir die Stakeholder nach ihren Erwartungen an das Produkt fragen. Sicher, ein solches Interview gibt nur ein wenig Verständnis für die Anforderungen. Dies ist jedoch immer noch ein guter Ausgangspunkt für die Forschung.

Bei Uptech sprechen wir zunächst beim Vorverkauf und beim Kick-Off-Call mit dem Kunden, um herauszufinden, ob wir zueinander passen. Wir versuchen, die kleinsten Details über den Kunden zu kristallisieren, um seine Idee zu verstehen.

Einfache Kommunikation liefert jedoch nicht genügend Informationen über die Zielgruppe des Produkts und deren Wünsche und Bedürfnisse. Also fahren wir mit der Entdeckungsphase fort, um es klar zu machen.

Schritt 2. Entdeckungsphase

Die Entdeckungsphase ist entscheidend für das Schreiben der SRS-Dokumentation. In diesem Stadium haben wir die Möglichkeit, das Problem zu untersuchen, das das Produkt lösen soll, Interessen und Bedürfnisse. Unser Ziel ist es, die Probleme der Benutzer zu identifizieren und Hypothesen über mögliche Lösungen zu definieren, um sie anzugehen. Mit einem solchen Ansatz können wir die App für den Benutzer wertvoll machen.

Use Cases vs User Stories

Alle Benutzerdaten werden als Use Cases und User Stories Teil eines SRS-Dokuments. Der Unterschied zwischen diesen beiden Kategorien wird in der Produktentwicklungsgemeinschaft häufig diskutiert.

Einfach ausgedrückt, User Stories konzentrieren sich mehr auf das Ergebnis und die Vorteile, die ein Benutzer bei der Verwendung einer Funktion erhält. Während Anwendungsfälle die Funktion selbst granularer beschreiben.

Nach mehreren Benutzerinterviews im Yaza-Projekt kamen wir beispielsweise zu dem Schluss, dass die App einen Chat haben sollte. Die User Story für einen solchen Fall würde sich also so anhören: „Als Nutzer möchte ich mit einem potenziellen Hausbesitzer chatten.“

In der Zwischenzeit würde der Anwendungsfall für diese Geschichte jeden Schritt eines Benutzers beschreiben, um dieses Ziel zu erreichen – „Als Benutzer muss ich einen Kontakt zu meiner Chat-Liste hinzufügen und ihm / ihr eine Nachricht senden, damit …“.

Schritt 3. Erstellen Sie die Struktur

Sobald die Entdeckung abgeschlossen ist, schreiben wir die SRS-Dokumentation. Erstens brauchen wir eine kurze Struktur des Dokuments. Der Inhalt eines SRS-Dokuments kann erheblich variieren, aber die typische SRS-Dokumentationsstruktur würde folgendermaßen aussehen:

1. Einleitung

Das Intro fasst den Inhalt des Dokuments zusammen. Es soll die folgenden Fragen beantworten:

• Kurze Beschreibung des Inhalts des Dokuments;
• Die beabsichtigten Leser dieses Dokuments;
• Die Idee der Software, die Sie entwickeln;
• Beabsichtigte Leser.

1.1 Geschäftsziele

Richten Sie eine Liste der Ziele ein, die Sie für das Projekt erreichen möchten, z. B. das Erstellen eines MVP, das Erstellen einer mobilen Multiplattform-App oder das Starten einer Website.

Außerdem sollte dieser Abschnitt die Ziele und Erfolgsmetriken Ihres Unternehmens widerspiegeln. Obwohl einige diesen Teil aus dem Dokument ausschließen können, ist es wichtig, diese Dinge anzugeben, da sie Forschung und Entwicklung direkt beeinflussen.

1.3 Verwendungszweck

Wie stellen Sie sich vor, dass eine Person Ihr Produkt verwenden wird? Welche Funktionen stellen Sie für diese Art der Nutzung zur Verfügung? Beschreiben Sie alle Möglichkeiten, wie eine Person Ihr Produkt in jeder Benutzerrolle verwenden kann.

1.4 Geltungsbereich

In diesem Teil wird der Arbeitsumfang beschrieben, den Sie ausführen müssen, um Ihre Idee zum Leben zu erwecken.

1.5 Definitionen und Akronyme

In diesem Dokument werden die Definitionen der Begriffe aufgeführt, die Sie im Dokument verwenden, um ein vollständiges Verständnis für die Benutzer sicherzustellen.

‍

2. Gesamtbeschreibung

Hier ist der Teil, in dem Sie die Idee der App erläutern, woher sie stammt und warum sie für Benutzer interessant sein kann.

2.1 User Needs

Eine Software, die für alle entwickelt wurde, dient niemandem. Wenn Sie jedoch genau wissen, wer Ihre Zielgruppe ist, wo sie arbeitet und welche Probleme sie haben, haben Sie höhere Chancen, eine App bereitzustellen, die von den Benutzern weithin angenommen wird.

‍

3. Systemfunktionen und Anforderungen

Jetzt ist es an der Zeit, die technischen Anforderungen Ihrer zukünftigen Software zu skizzieren. Beschreiben Sie die Funktionen, die Ihr Produkt enthalten wird, zusammen mit den Standards, die die Qualität dieser Produkte definieren.

3.1 Funktionale Anforderungen

Funktionale Anforderungen sind Systemspezifikationen, ohne die die Software nicht ordnungsgemäß funktioniert. Die Definition, die Sie Ihren Softwarefunktionen geben, bestimmt, wie sie weiter implementiert werden.

3.2 Nichtfunktionale Anforderungen

Während funktionale Anforderungen die Funktion des Systems definieren, bestimmen nichtfunktionale Anforderungen, wie das System diese Funktionen implementiert, z. B. die Geschwindigkeit der Fertigstellung.

3.3 Tech Stack

Ein Tech Stack ist ein Pool technischer Lösungen, die zum Erstellen und Ausführen von Software oder eines Projekts verwendet werden. Es ist wichtig, es im SRS-Dokument anzugeben, da es alle anderen technischen Details definiert.

Schritt 4. Machen Sie eine allgemeine Beschreibung

Bevor Sie in die Details Ihres Produkts eintauchen, geben Sie einen allgemeinen Überblick über die wichtigsten Funktionen der App. Erklären Sie einfach den Zweck Ihrer App, ihre Funktionen und wie sie das Problem des Benutzers lösen.

Schritt 5. Definieren Sie funktionale und nicht funktionale Anforderungen

Der Kern Ihres SRS-Dokuments besteht normalerweise aus den funktionalen und nicht funktionalen Anforderungen des Produkts. Mit solchen Spezifikationen fügen Sie der allgemeinen Übersicht mehr Details hinzu und führen das Team so durch die technischen Besonderheiten Ihrer App.

Der Unterschied zwischen funktionalen und nicht-funktionalen Anforderungen ist ein weiterer Knackpunkt in der Produktentwicklung. Wir haben unsere Expertise zu diesem Thema in diesem Artikel geteilt.

Schritt 6. Stellen Sie sicher, dass der Client auf derselben Seite

Genehmigung ist ein mit Spannung erwarteter Teil der Entwicklung. Die Änderungen des Kunden können jedoch manchmal den gesamten Arbeitsaufwand zunichte machen, der zu einem bestimmten Zeitpunkt im Projekt abgeschlossen wurde.

Um den Druck zu vermeiden, empfehlen wir, kleinen Teilen der ausgefüllten SRS-Dokumentation zuzustimmen, anstatt ein ganzes Paket von Dokumenten auf einmal einzureichen. Dies hilft, bestimmte Probleme schnell zu beheben und ist weniger störend.

Expertentipps zum Schreiben einer großartigen SRS-Dokumentation

Es braucht Zeit, um die Fähigkeit zu verbessern, eine hervorragende SRS-Dokumentation zu schreiben. Wir haben aus unserer Erfahrung eine Liste mit Expertentipps zum Schreiben von SRS-Dokumentationen zusammengestellt. Hier sind einige Einblicke, die Ihre SRS-Dokumentation effektiv machen:

Mach es einfach

Dies ist kaum ein Geheimnis, aber einfache Dinge regieren die Welt. Dies gilt sicherlich für jede Art von Dokumentation, an der Sie arbeiten. Ihr SRS ist eine einheitliche Beschreibung des zukünftigen Produkts für Ihr gesamtes Team. Dies bedeutet, dass Sprache, Struktur und Formulierungen Ihres SRS-Dokuments so lakonisch wie möglich sein sollten.

Geschäftsziele einschließen

Obwohl sich ein SRS-Dokument hauptsächlich auf die technischen Merkmale konzentriert, ist das Einschließen von Geschäftszielen eine gute Praxis. Ein SRS-Dokument ist eine Anleitung für das Entwicklungsteam und die Produktübersicht für Nicht-Tech-Spezialisten, die sich auf das Produkt beziehen. Darüber hinaus wird Ihr SRS durch die Einbeziehung von Geschäftsanforderungen wie Metriken und Zwecken zu einem einheitlichen Instrument für das gesamte Team.

Benutzerdaten hinzufügen

Die Entdeckungsphase enthüllt normalerweise die wertvollsten Informationen über einen Benutzer. Das Hinzufügen dieser Informationen zum SRS-Dokument macht es zu einem hilfreichen Papier für das Design- und Entwicklungsteam.

Behandeln Sie Ihr SRS als lebendiges Dokument

Das SRS-Dokument sollte nicht statisch sein, auch wenn Sie alle erforderlichen Pakete für Ihr Projekt kompiliert haben. In agilen Ökosystemen erwerben Projekte mit jeder Iteration neue Funktionen. Alle diese Änderungen und Modifikationen sollten im SRS-Dokument angegeben und mit dem Kunden vereinbart werden.

Fazit

Das Schreiben von SRS-Dokumenten erfordert tiefgreifende Recherchen, Analysen und Anstrengungen. Ein umfassendes SRS-Dokument, das Geschäftsmerkmale, technische Details und Benutzerdaten abdeckt, zahlt sich jedoch mit einem beeindruckenden Produkt aus, das sowohl die Erwartungen der Kunden als auch der Benutzer erfüllt.

Uptech verfügt über fünf Jahre Erfahrung in der Entwicklung von Produkten für erfolgreiche Startups. Wir wissen, wie man die Bedürfnisse des Benutzers untersucht und SRS Document zu einem effektiven Projektmanagement-Instrument macht und nicht zu einem Stapel staubbedeckter Papiere.

FAQ

Was ist SRS?

Ein SRS ist ein Dokument, das eine detaillierte Beschreibung der technischen Spezifikationen und Anforderungen einer App oder Software enthält. Ein SRS weist Entwickler auch an, wie die Produktidee umgesetzt werden kann, um den Erwartungen des Kunden zu entsprechen.

Was ist der Zweck eines SRS-Dokuments?

Der Zweck eines SRS-Dokuments besteht darin, die technischen Merkmale eines Produkts zu beschreiben, technische und nichttechnische Anforderungen bereitzustellen und das Entwicklungsteam bei der Implementierung zu unterstützen.

Wer schreibt SRS-Dokumente?

Abhängig von der Zusammensetzung des Teams werden SRS-Dokumente normalerweise von:

• Produktmanager;
• Projektmanager;
• Business Analyst;
• Technischer Ingenieur.