Wie erstellt man ein SRS-Dokument?

In diesem Artikel erklären wir, warum die Spezifikation in der Softwareentwicklung so wichtig ist und warum Sie ihr besondere Aufmerksamkeit widmen sollten.

Was ist eine Software-Anforderungsspezifikation (SRS)?
Eine SRS ist ein Dokument, das die Geschäftsziele und die Softwarefunktionalität definiert. Es legt die Art und Weise fest, wie die Software gemäß den Anforderungen des Benutzers oder des Unternehmens funktionieren soll. Ein SRS-Dokument enthält jedoch nicht nur funktionale, sondern auch nicht-funktionale Anforderungen, wie UI-Design, Leistung und Sicherheit. Kurz gesagt, ist dieses Dokument ein Leitfaden für Entwickler, Tester und andere Teammitglieder in allen Phasen der Konzeption und Entwicklung der Software, weshalb man unbedingt wissen sollte, wie man eine SRS für ein Projekt erstellt und was ein herkömmliches SRS-Dokument enthalten sollte.
Gründe für die Erstellung eines SRS-Dokuments

Zunächst wird eine SRS erstellt, um die Ziele der Anwendung und den Umfang der vom Softwaredienstleister zu erbringenden Arbeit festzulegen. Anhand einer detaillierten Beschreibung verstehen die Entwickler, wie sie die Software implementieren und aufbauen können. Anschließend hilft ihnen die Spezifikation, die entwickelte Software zu testen und zu kontrollieren, ob alle erforderlichen Funktionen implementiert wurden. Mit dem Entwurf eines guten SRS-Dokuments sollte noch vor der eigentlichen Entwicklung begonnen werden. Es kann vorkommen, dass die erstellte Software nicht den notwendigen Anforderungen entspricht, und an diesem Punkt kommt die Spezifikation ins Spiel, denn sie ist die Referenzquelle für die Entwickler. Nach dem Studium der SRS können sie die Arbeit an der Software fortsetzen, um die festgelegten Anforderungen zu erfüllen.

Die Erstellung einer hochwertigen technischen Spezifikation ist somit der erste und wichtigste Schritt in jedem Projekt, der sowohl von den für die Softwareentwicklung Verantwortlichen als auch von den Softwareeigentümern verstanden werden muss. Das SRS-Dokument leitet das Team bei der Konzeption und Entwicklung der Software. Wenn Sie eine vollständige und eindeutige Spezifikation vorlegen, besteht eine hohe Wahrscheinlichkeit, dass für Korrektur, Neudefinition und Neuimplementierung Ihrer Software Zeit gespart werden kann oder gar nicht erst aufgewendet werden muss. Je früher ein Problem entdeckt wird, desto effizienter können Sie die Zeit einteilen, da es einfacher ist, eine Spezifikation zu aktualisieren, bevor Sie mit der Entwicklung beginnen, als eine bereits vorhandene Funktionalität zu ändern. In der Regel ist eine technische Spezifikation das Ergebnis eines ersten Gesprächs zwischen dem Kunden und dem Entwicklungsteam, das als Grundlage für die Schätzung von Zeitaufwand und Projektkosten dient. Ein SRS-Dokument soll zunächst einen detaillierten Überblick über die künftige Software geben und damit eine Schätzung der Projektkosten erleichtern.

Die Entwicklung einer Anwendung ist in der Regel ein fortlaufender Prozess ist, bei dem die Projektmitarbeiter wechseln werden. Wenn das Projekt also an einen anderen Teil des Teams übergeben wird, ist eine Spezifikation unverzichtbar.

Ist das nicht ein guter Grund, sich Zeit zu nehmen, um eine SRS zu erstellen?

Eine hochwertige Spezifikation bedeutet auch, dass es einfacher ist, das Softwareprodukt zu aktualisieren. Die SRS muss jedes Mal aktualisiert werden, wenn eine Änderung nötig wird, wobei alle Mitglieder in die Überlegungen zu künftigen Änderungen einbezogen werden sollten.

Wie wir bereits gesagt haben, ist die Erstellung eines SRS-Dokuments von hoher Qualität ein absolutes Muss. Aber wie schreibt man nun gutes SRS-Dokument? Hier werden wir über die wichtigsten Regeln sprechen, die man beim Verfassen einer Spezifikation beachten sollte.

Die wichtigste Regeln

1. Die Spezifikation sollte nur von einer Person geschrieben werden. Zwar gibt es viele Mitglieder im Team, die ihre wertvollen Ideen zu diesem Dokument beitragen, aber es sollte nur eine Person sein, die alle Gedanken zu einem soliden Vorschlag zusammenfasst.

2. Eine SRS ist kein Handbuch. Natürlich beschreibt eine SRS etwas, das es noch nicht gibt, aber das bedeutet nicht, dass man jedes einzelne Detail ausführen muss. Verlieren Sie sich nicht in Einzelheiten und beziehen Sie nur wichtige Informationen ein.

3. Schreiben Sie keinen ermüdenden Text. Wenn man merkt, dass die Informationen langweilig sind, werden sie andere Personen wahrscheinlich nur ungern lesen.

4. Versuchen Sie nicht, die Spezifikation um jeden Preis fertig zu stellen. Es ist in Ordnung, die Beschreibung einiger Abschnitte als TBD in die Zukunft zu verschieben. Informieren Sie die Leser darüber, dass dies zu tun bleibt, und stellen Sie sicher, dass alle Gedanken vor dem Start der Entwicklung abgeschlossen sind.

5. Berücksichtigen Sie, dass es keine zweite Version geben wird. Manche Leute machen den häufigen Fehler, eine kurzfristige Lösung vorzuschlagen, da sie davon ausgehen, dass es ohnehin bald eine Neufassung geben wird. Leider ist das sehr unwahrscheinlich, da die Systeme selten ersetzt werden, sondern in der Regel im Laufe der Zeit nur verbessert und erweitert werden. Sie können einige Komponenten und Prozesse aufführen, die später überarbeitet werden könnten, aber vergessen Sie nicht, dass die wichtigsten Designentscheidungen für lange Zeit Bestand haben werden.

Wie schreibt man ein SRS-Dokument?
1. Einleitung

Man sagt, gut begonnen ist halb getan. Wenn Sie also eine gute Einleitung schreiben, sind Sie auf halbem Weg zum Erfolg. Als erstes müssen Sie Ihr Produktziel definieren. Die Einleitung gibt eine Zusammenfassung des gesamten Dokuments, beschreibt die Projektidee und ist somit ein wesentlicher Bestandteil der Softwarespezifikation.

Bevor Sie mit der Entwicklung der Anwendung beginnen, müssen Sie sich über die Marktsituation der Nische, die Sie besetzen wollen, im Klaren sein. Vergessen Sie auch nicht, die Wettbewerbssituation zu recherchieren, da verschiedene Faktoren, einschließlich der oben genannten, die Anforderungen beeinflussen können. Ihre Leser sind wahrscheinlich die gegenwärtigen und zukünftigen Experten, die sich mit Ihren Aufgaben befassen, und sie müssen das Unternehmensumfeld verstehen. Wenn der Kontext klar ist, können Sie die Prioritäten festlegen und den Softwareentwicklungsprozess organisieren.

Ein weiterer Punkt, der in der Einleitung aufgeführt werden sollte, ist der Arbeitsaufwand für das Projekt. Hier sollten Sie über die Produktspezifikationen sprechen: Vorteile, einzigartige Merkmale, Ziele und so weiter. Dies ist wichtig, um eine Projektschätzung vornehmen zu können und die Zusammenarbeit mit Ihrem Dienstleister produktiv zu gestalten.

Ein weiterer wichtiger Punkt, der in der Einleitung erwähnt werden sollte, ist Ihre Zielgruppe: wer soll diese Software nutzen, was sind ihre Erwartungen und Vorlieben. Eine gute Idee wäre es, über einen eingeschränkten Zugang für bestimmte Nutzergruppen, die Geräte, die die Nutzer verwenden, und deren Standort nachzudenken.

Wenn Sie möchten, können Sie auch einen Abschnitt mit Abkürzungen und Definitionen einfügen, um Verwirrung zu vermeiden, das ist ganz Ihnen überlassen. In der Regel unterstützen sie damit die Entwickler, wenn die Anwendung für eine spezielle Branche wie das Gesundheitswesen oder die Automobilindustrie bestimmt ist.

2. Ein allgemeiner Überblick über das System

Denken Sie daran: In der Spezifikation sollte die Beschreibung vom Allgemeinen zum Speziellen erfolgen. Bevor Sie also zu den technischen Einzelheiten des Produkts übergehen, sollten Sie einen allgemeinen Überblick über das System geben. Ein guter Anfang wäre die Information, ob es sich um eine neue Anwendung oder eine aktuelle Anwendung handelt, die geändert werden muss.

Danach sollten die wichtigsten Schnittstellen und Strukturelemente erwähnt werden. Sie können gerne visuelle Inhalte verwenden, um den Text zu illustrieren und die Leser zu unterstützen.

Dann können Sie zu den Modi und Zuständen des künftigen Systems übergehen, zu den allgemeinen Anforderungen, was es können sollte und was seine Grenzen sind. Eine ausführliche Beschreibung ist hier nicht erforderlich, da Sie später in Ihrem Dokument auf diesen Punkt zurückkommen werden.

Achten Sie darauf, Vermutungen und Abhängigkeiten einzubeziehen (die Elemente, die sich auf die Relevanz dieser SRS-Variante auswirken könnten). Sie sollten erwähnt werden, um potenzielle Gefahren zu reduzieren. Nicht zuletzt geht es um Einsatzszenarien, d. h. darum, wie die Elemente des Systems miteinander, mit der Umgebung und mit dem Benutzer interagieren. Eine gute Möglichkeit, ihre Interaktion darzustellen, besteht darin, eine Kette von Ereignissen zu erstellen, mit denen der Nutzer konfrontiert wird.

3. Systemfähigkeiten, Bedingungen und Beschränkungen

Dieser Abschnitt ist von äußerster Wichtigkeit, daher sollten Sie die Elemente hier ausführlich beschreiben, damit Entwickler, Designer und andere Teammitglieder Ihre Ideen und Anforderungen verstehen.

Hier werden die Anforderungen beschrieben, die in nicht-funktionale und funktionale Anforderungen unterteilt werden können. Die erste Gruppe kann für eine Reihe von Branchen recht ähnlich sein. Sie skizzieren die Systemleistung, wobei die wichtigste Komponente hier das Dokument mit den Geschäftsanforderungen ist, das die Erwartungen und Bedürfnisse der Endnutzer enthält.

Funktionale Anforderungen beschreiben das Verhalten des Systems, also das, was in den verschiedenen Fällen von ihm erwartet wird.

Gehen Sie dann zu den logischen Datenanforderungen über. Falls Sie Schwierigkeiten bei der Beschreibung dieses Abschnitts haben, überlegen Sie sich, wie die Daten im System verarbeitet werden, welcher Art sie sind und wie sie angeordnet und verknüpft werden. Die Erstellung eines visuellen Modells ist ein guter Ansatz.

4. Systemschnittstellen
Es gibt interne und externe Schnittstellen. Sie müssen beschreiben, wie die Systemkomponenten (bestehende, in der Implementierungsphase befindliche und zukünftige) voneinander abhängig sind. Denken Sie daran, sowohl die Personen zu berücksichtigen, die Ihr System benutzen werden, als auch andere Anwendungen, die mit dem System kommunizieren sollen.
5. Rückverfolgbarkeitsmatrix (RTM)

Die RTM (Requirements Traceability Matrix) ist ein spezielles Instrument, mit dem Sie überprüfen können, ob alle Anforderungen für die Tests erfüllt sind. Dieser Abschnitt der SRS garantiert einen reibungslosen Entwicklungsprozess. Die Matrix selbst ist eine Tabelle, die alle Punkte des technischen Dokuments und die Änderungswünsche enthält.

Wie dieses Dokument aussieht, hängt von dem Unternehmen ab, das es erstellt.

6. Referenzen
Vergessen Sie nicht, diesen Abschnitt aufzunehmen, auch wenn es etwas seltsam erscheinen mag, Referenzen anzugeben. Es ist ganz einfach: Fügen Sie die Links zu allen erforderlichen Dokumenten, deren Daten und Autoren sowie Ihre eigenen Kommentare hinzu.
7. Andere optionale Abschnitte
Die Abschnitte, die Sie möglicherweise in Ihrem SRS-Dokument benötigen, sind: 1) Glossar (falls Sie zu viele Akronyme haben, fügen Sie sie alle in die Einleitung ein) 2) Revisionshistorie (falls Ihr Projekt über einen längeren Zeitraum andauert, ist es wahrscheinlich, dass es mehrere Versionen des SRS-Dokuments geben wird, daher sollten Sie alle Versionen in einer Tabelle zusammenfassen) 3) Anhänge (falls es Informationen gibt, die Sie nicht in die anderen Abschnitte aufgenommen haben, können Sie sie in die Anhänge einfügen)
Zusammenfassung

Sobald Sie sich entscheiden, mit der Entwicklung Ihrer Software (Website, mobile Anwendung, usw.) zu beginnen, sollten Sie im ersten Schritt eine hochwertige SRS erstellen. Ihre Spezifikation wird vom zukünftigen Kunden Ihrer Software und dem Entwicklungsteam genutzt, daher muss die SRS klar und präzise sein. Wenn Sie Zeit und Mühe in die Erstellung einer guten Spezifikation investieren, werden Sie Software entwickeln, die Ihr Kunde benötigt und seine Anforderungen erfüllt.

Sollten Sie Probleme beim Erstellen Ihrer SRS haben, wenden Sie sich an uns und wir werden Ihnen gerne weiterhelfen.

Thank you for rating!
Thank you for comment!

Bewerten Sie diesen Artikel:

4/5

4.9/5 (42 bewertungen)

Related content

Haben Sie eine Herausforderung für uns?

Wählen Sie das Thema Ihrer Anfrage

Bitte beachten Sie, wenn Sie auf die Schaltfläche Senden klicken, dass Innowise Group Ihre Datenschutzrichtlinie um Ihnen die gewünschten Informationen zukommen zu lassen.

Wie geht es weiter?

1

Sobald wir Ihre Anfrage erhalten und bearbeitet haben, werden wir uns mit Ihnen in Verbindung setzen, um Ihre Projektanforderungen zu besprechen und eine NDA zu unterzeichnen, um die Vertraulichkeit der Informationen zu gewährleisten.

2

Nach Prüfung der Anforderungen erstellen unsere Analysten und Entwickler einen Projektvorschlag, der Arbeitsumfang, Teamgröße, Zeit- und Kostenschätzung enthält.

3

Wir vereinbaren einen Termin mit Ihnen, um das Angebot zu besprechen und eine Vereinbarung zu treffen.

4

Wir unterzeichnen einen Vertrag und beginnen umgehend mit der Arbeit an Ihrem Projekt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert