#Product Label
Eine Software Requirements Specification (SRS-Dokument) beschreibt, wie ein Softwaresystem entwickelt werden soll. Einfach ausgedrückt, ein SRS bietet allen Beteiligten eine Roadmap für dieses Projekt.
Es bietet hochwertige Definitionen für die funktionalen und nicht funktionalen Spezifikationen der Software und kann auch Anwendungsfälle enthalten, die veranschaulichen, wie ein Benutzer nach Abschluss mit dem System interagieren würde.,
Hinweis: Lassen sie uns helfen sie schreiben eine Software Anforderungen Spezifikation. Fordern Sie einen Anruf bei unserem CTO an, indem Sie dieses Formular ausfüllen.
Inhaltsverzeichnis
Warum ist ein SRS-Dokument Wichtig?
Angenommen, Sie möchten eine Chat-App mit einem bestimmten Erscheinungsbild und einer bestimmten Funktionalität erstellen und möchten, dass sie speziell auf Unternehmen ausgerichtet ist. Sie haben das Gefühl, dass Sie die zusätzlichen Funktionen, mit denen kommerzielle Chat-Apps die Öffentlichkeit ansprechen, ausschneiden und sich auf Funktionen konzentrieren können, die Unternehmen benötigen. Aber Sie sind kein Entwickler.,
Sie müssen also die Entwicklung der App auslagern. Sie müssen aber auch sicherstellen, dass jeder, den Sie einstellen, um Ihre Idee in die Realität umzusetzen, genau weiß, was Sie erreichen möchten. Ohne alle Details, um die App zu beenden, können Zeit und Kosten schnell außer Kontrolle geraten. Entwickler können eine falsche Wendung nehmen und müssen den Code umgestalten, wenn das fertige Produkt nicht mit dem Bild übereinstimmt, das Sie in Ihrem Kopf hatten.
Ein SRS-Dokument zwingt Sie, die Idee auf Papier zu bringen, um all diese Details abzudecken. Sie müssen diese Idee in eine Sprache übersetzen, die Entwickler verstehen., Ein SRS-Dokument beschreibt, was ein Kunde will und was Entwickler zur Verfügung stellen. Es ist die schriftliche Vereinbarung über jedes Detail der App.
Mit einem klaren Satz von Anforderungen stellt sicher, dass ein Entwicklungsteam Software erstellt, die den Anforderungen der Kunden entspricht. Ein SRS hilft bei der Schätzung der Arbeitskosten und deckt den Projektumfang ab. Es gibt Programmierern auch eine Vorstellung von dem Tech-Stack, den sie benötigen, und hilft ihnen bei der Planung ihrer Arbeit, aber das ist noch nicht alles:
- Designer erhalten Projekteinblicke durch SRS-Dokumente, damit sie das Design an den Anwendungsfall anpassen können.,
- Tester erhalten die Richtlinien zum Erstellen von Testfällen, die den Anforderungen des Unternehmens entsprechen.
- Endbenutzer verwenden das SRS, um die Software zu verstehen.
- Es bietet Anlegern einen Überblick über die Funktionen des Systems, damit sie Investitionsentscheidungen treffen können.
Ein SRS ist wichtig, weil es eine einzige Informations – und Erwartungsquelle ist, die Missverständnisse zwischen Projektmanagern, Entwicklern, Designern und Testern verhindert.
Was beinhaltet ein SRS?,
Ein SRS sollte genügend Informationen für Entwickler haben, um die beschriebene Software zu vervollständigen. Es enthält nicht nur die Beschreibung der in der Entwicklung befindlichen Software, sondern auch den Zweck, dem sie dienen soll: Was die Software tun soll und wie sie funktionieren soll.,leistung der Software in einer Produktionssituation
Der Unterschied zwischen funktionalen und nicht funktionalen Anforderungen
Funktionale Anforderungen sind die Ziele des neuen Systems, das Sie entwerfen., Sie beschreiben das System und wie es funktionieren wird, um bei den Aufgaben eines Benutzers zu helfen. Sie definieren, wie das System auf Benutzereingaben reagiert, und enthalten Details zu Berechnungen, Dateneingabe und Geschäftsprozessen. Sie können funktionale Anforderungen eine detaillierte Beschreibung der Funktionen der Anwendung und der Bedürfnisse des Benutzers berücksichtigen. Ohne die funktionalen Anforderungen zu erfüllen, funktioniert das System nicht.
Während funktionale Anforderungen angeben, was ein System tut, beschreiben nicht funktionale Anforderungen, wie das System dies tun wird. Nicht funktionale Anforderungen haben keinen Einfluss auf die Funktionalität der Anwendung., Auch ohne nicht funktionale Anforderungen zu erfüllen, führt das System die gewünschten Aufgaben aus.
Nicht funktionale Anforderungen sind ebenfalls wichtig, da sie die allgemeinen Merkmale definieren, die sich auf die Benutzererfahrung auswirken. Anstatt sich auf die Benutzeranforderungen zu konzentrieren, konzentrieren sie sich auf die Benutzererwartungen und decken Themen wie Leistung, Sicherheit, Zuverlässigkeit, Verfügbarkeit und Benutzerfreundlichkeit ab.,
So schreiben Sie ein Dokument zur Softwareanforderungsspezifikation
Organisieren Sie am besten den Prozess, den Sie zum Schreiben eines SRS-Dokuments verwenden, indem Sie mit einem Skelett und allgemeinen Informationen zu der von Ihnen entwickelten Software beginnen und Details hinzufügen, um Ihren Entwurf zu konkretisieren. Hier sind sechs Schritte beim Erstellen eines SRS-Dokuments:
Get Software Requirements Specification Document
Wir haben mehr als 200 Unternehmen beim Aufbau ihrer Softwareprodukte geholfen. Stellen Sie unseren Business Analyst mit 6 Jahren Erfahrung ein, um ein SRS für Sie zu schreiben.,
SRS anfordern
Erstellen Sie eine Gliederung
Der erste Schritt besteht darin, eine Gliederung für Ihre SRS zu erstellen. Sie können dies selbst erstellen oder eine vorhandene SRS-Vorlage als Ausgangspunkt verwenden. Hier ist ein grundlegendes Beispiel für eine SRS-Gliederung:
Laden Sie das ebook herunter
- Einführung
- Zweck
- Zielgruppe
- Verwendungszweck
- Geltungsbereich
- Definitionen
- Gesamtbeschreibung
- Benutzeranforderungen
- Annahmen und Abhängigkeiten
- Systemfunktionen und-anforderungen
- Funktionsanforderungen
- Externe Schnittstellenanforderungen
- Systemfunktionen
- Nicht funktionale Anforderungen
Definieren Sie den Zweck
Sobald Sie einen Umriss haben, müssen Sie ihn ausarbeiten., Beginnen Sie mit der Definition des Zwecks des Produkts in der Einführung Ihres SRS. Hier beschreiben Sie die Zielgruppe und wie sie das Produkt verwenden. Hier ist, wie Sie den Zweck strukturieren sollten:
- Definieren Sie den Umfang des Produkts
- Beschreiben Sie den Wert, den es liefern wird
- Zeigen Sie, wer die Software verwenden wird
- Detail, wie es bei der beabsichtigten Benutzeraufgabe helfen wird
Geben Sie einen Überblick
Fassen Sie nach der Definition des Zwecks des Produkts zusammen, wie es funktionieren wird., Hier finden Sie eine allgemeine Beschreibung der Funktionen der Software und wie sie den Bedürfnissen des Benutzers entsprechen.
Sie werden auch die Annahmen beschreiben, die Sie über die Funktionalität des Produkts machen und alles, was es im aktuellen Tech-Ökosystem abhängt.
Beschreiben Sie funktionale und nicht funktionale Anforderungen
Nachdem Sie die allgemeinen Informationen geschrieben haben, ist es an der Zeit, spezifischer zu werden. Wenn Sie Ihre Übersicht vervollständigen, bevor Sie an funktionalen und nicht funktionalen Anforderungen arbeiten, erhalten Sie einen Verweis, um sicherzustellen, dass Sie die grundlegenden Anforderungen des Benutzers erfüllen, während Sie die Details ausfüllen.,
Diese detaillierte Beschreibung der Systemanforderungen ist die wichtigste Komponente eines SRS-Dokuments. Beschreiben Sie die funktionalen Anforderungen so detailliert, dass Entwickler an die Arbeit gehen können und die nicht funktionalen Anforderungen wie Sicherheitsspezifikationen und Leistung.
Hier fügen Sie Anwendungsfälle hinzu, um anschaulich zu beschreiben, wie ein Benutzer mit Ihrem System interagiert. Hier werden die Ziele Ihres Projekts detailliert beschrieben und gemessen, wie das Projekt während der Entwicklung voranschreitet.,
Add Supplemental Details
Der letzte Schritt beim Erstellen des Entwurfs Ihres SRS-Dokuments besteht darin, alle Details hinzuzufügen, die Entwicklern helfen könnten, den Job in Form von Anhängen, Glossaren von Begriffen und Referenzen abzuschließen.
Get Approval
Sobald Sie dem SRS genügend Details hinzugefügt haben, um zu beschreiben, was das System tun soll, ist es an der Zeit, dass die Stakeholder das Dokument genehmigen.
Sie müssen höchstwahrscheinlich eine Präsentation vor den am Entwicklungsprozess beteiligten Personen halten., Sie können nach Änderungen fragen, und Sie müssen das SRS-Dokument basierend auf dem Feedback der Stakeholder vor der endgültigen Genehmigung aktualisieren.
Das ist ein gutes Zeichen. Dies bedeutet, dass sowohl Entwickler als auch Stakeholder das Dokument präziser machen, sodass das Projekt weniger von der Strecke geht.
So schreiben Sie Software-Anwendungsfälle in einem SRS
Ein Anwendungsfall beschreibt, wie ein Benutzer mit dem System interagiert. Es wird das Produkt aus der Sicht des Endbenutzers in einem einfachen Story-Format beschreiben. Das Ausschreiben von Anwendungsfällen zwingt Sie, darüber nachzudenken, was Benutzer mit der Software tun und wie sie reagieren wird., Es ist die reale Visualisierung der funktionalen Anforderungen.
Hier sind Schritte, die Sie ausführen können, um einen Anwendungsfall zu schreiben:
- Beschreiben Sie die Endbenutzer Ihres Produkts.
- Konzentrieren Sie sich auf einen dieser Benutzer.
- Teilen Sie die Interaktionen dieses Benutzers in Anwendungsfälle auf. Jede Interaktion ist ein Anwendungsfall.
- Beschreiben Sie die Abfolge der Ereignisse für jeden Anwendungsfall.
- Schreiben Sie eine detaillierte Beschreibung der Aktionen des Benutzers und wie das system reagieren soll.
- Erweitern Sie jeden Anwendungsfall mit alternativen Benutzeraktionen und Systemantworten.
- Wiederholen Sie 1-6 für jeden Endbenutzertyp.,
Was sind die Eigenschaften eines großartigen SRS?
Es gibt spezifische Eigenschaften, die jeder SRS haben sollte. Wenn Sie diese Liste überprüfen und mit Ihren SRS vergleichen, können Sie sicherstellen, dass sie ein nützliches Dokument für alle Stakeholder ist.
Explizit
Ein SRS-Dokument sollte leicht verständlich sein. Nichts sollte vage sein, daher gibt es keine Missverständnisse zwischen den Beteiligten.,
Messbar
Die Anforderungen in Ihrem SRS-Dokument müssen messbar sein, damit das fertige Produkt anhand der Spezifikationen validiert und verifiziert werden kann.
Vollständig
Ein SRS-Dokument sollte genügend Informationen enthalten, damit Ihr Entwicklungsteam das Produkt fertigstellen und Tester überprüfen können, ob das Produkt den Anforderungen des Benutzers ohne Fehler entspricht.
Die Anforderungen sollten der Realität des aktuellen Umfelds entsprechen, einschließlich Budget, Zeitplan und Technologie. Sie sollten nicht auf bevorstehende technologische Durchbrüche angewiesen sein.,
Flexibel
Da sich die Dinge in der Arbeitsumgebung ändern könnten, sollte Ihr SRS-Dokument flexibel genug sein, um Aktualisierungen zuzulassen. Fügen Sie nicht redundante Informationen zu mehreren Abschnitten hinzu, die mit jeder Änderung aktualisiert werden müssen.
Überprüfbar
Jeder im Entwicklungsteam sollte Zugriff auf das Dokument haben, damit er so häufig wie nötig darauf verweisen kann. Die Anforderungen müssen genau sein, damit die Teammitglieder nicht nach weiteren Details fragen müssen. Sie sollten alle im SRS-Dokument verfügbar sein.,
Die Anforderungen sollten zueinander passen. Ein Abschnitt Ihres Anforderungsdokuments sollte nicht mit einem anderen in Konflikt stehen. Das Dokument sollte konsistent formatiert sein und die gleiche Terminologie verwenden.
Keine Implementierungsbeschränkungen
Ein SRS-Dokument sollte detailliert genug sein, um den Job abzuschließen, sollte aber nicht übermäßig spezifisch sein, da dies die Entwicklung einschränken könnte. Eine Menge Entwicklung hängt von Diensten von Drittanbietern ab, über die Entwickler keine Kontrolle haben.,
Genaue
Ziele in einem Anforderungsdokument sollten präzise sein, um Verwirrung zu vermeiden. Vermeiden Sie Folgendes:
- Schlupflöcher: „Die Anwendung sollte in 3 Sekunden geladen werden, wenn dies möglich ist.“
- Ambiguity: „Das MVP-Produkt sollte so schnell wie möglich veröffentlicht werden.“
- Subjektivität: „Die Benutzeroberfläche sollte benutzerfreundlich sein.“
- Superlative: „Dies sollte die beste Anwendung seiner Klasse sein.“
- „: „Diese Anwendung sollte besser sein als Slack.,“
Ein SRS-Beispiel (Software Requirement Specification)
Hier ist ein abgeschnittenes Beispiel für ein SRS-Dokument für eine Enterprise-Chat-App namens eChat:
Einführung
Dieses Dokument beschreibt den Projektplan für die Entwicklung von „eChat.“
Es richtet sich an Entwickler, Designer und Tester, die an „eChat“ arbeiten, sowie an Projektinvestoren., Dieser Plan enthält eine Zusammenfassung von:
- Funktionsweise des Systems
- der Umfang des Projekts aus Sicht der Entwicklung
- die Technologie zur Entwicklung des Projekts und
- die Metriken zur Bestimmung des Projektfortschritts
- Gesamtbeschreibung
Unternehmen benötigen Fernkommunikationstools, insbesondere jetzt, da mehr Menschen von zu Hause aus arbeiten. Das Problem ist, dass die meisten Unternehmen mehrere Anwendungen verwenden, um dies zu erreichen: eine für Text-Chat, eine für Video-Chat und eine für Konferenzen und Meetings., „eChat“ löst dieses Problem, indem diese Funktionen in einer Anwendung kombiniert werden.
Laden Sie das Whitepaper herunter
Kunden
Die Kunden werden Unternehmen sein. Es wird nicht auf die breite Öffentlichkeit abzielen.
Funktionalität
- Benutzer sollten sich mit Enterprise LDAP-Konten anmelden können.,
- Benutzer sollten in der Lage sein, Ad-hoc-Chatgruppen mit Benutzergruppen zu erstellen und private Nachrichten an einzelne Benutzer zu senden.
- Benutzer sollten Text-Chats haben können, die sie in Threads einbrechen können.
- Die Anwendung sollte in der Lage sein, Gruppen-Video-Chat von bis zu 100 Benutzern gleichzeitig zu behandeln.
Plattform
Die Anwendung wird in React Native entwickelt, um die Erstellung einer webbasierten Anwendung, einer mobilen iOS-App und einer mobilen Android-App zu ermöglichen.
Diese Anwendungen stellen eine Verbindung zu einer mit erstellten REST-API her .,NET Core zum speichern und abrufen von Daten aus einer MySQL-Datenbank.
Die Authentifizierung erfolgt über vorhandene LDAP-Installationen.
Entwicklungsaufgaben
Die Entwickler im „eChat“ – Team sind für das Schreiben des gesamten Codes für die Anwendung, die Entwicklung der Datenbank und die Verwaltung von Releases verantwortlich.,
Benutzerklasse und Eigenschaften
Es wird eine Benutzerklasse namens admin geben, die über Berechtigungen für den Zugriff auf alle Funktionen der App verfügt, einschließlich:
- Erstellen von Kanälen, in denen mehrere Benutzer interagieren können
- Diese Kanäle für das gesamte Unternehmen öffentlich oder für eine Gruppe von Personen privat machen können
- Löschen dieser Kanäle
- Archivieren dieser Kanäle
Standardbenutzer haben Zugriff auf alle Funktionen der App mit Ausnahme der oben aufgeführten.,
Systemfunktionen
Funktionsanforderungen
- Benutzer sollten in der Lage sein, Ad-hoc-Chatgruppen mit Benutzergruppen zu erstellen und private Nachrichten an andere Benutzer zu senden.
- Benutzer sollten Text-Chats haben können, die sie in Threads einbrechen können.
- Chats sollten unbegrenzt archiviert werden können, damit Benutzer auf vergangene Chats verweisen können.
- Benutzer sollten Dateien als Referenz in Chats hochladen können.
- Externe Schnittstelle Anforderungen
Benutzeroberflächen
- Front-end-software: Reagieren Native
- Back-end-software: .,s-Betriebssysteme über ihren Standard-Webbrowser
- iPhone
- Android
- Nicht funktionale Anforderungen
Leistungsanforderungen
- Die Anwendung sollte innerhalb von 3 Sekunden geladen und verwendbar sein
- Die Anwendung sollte die Schnittstelle bei Interaktion innerhalb von 2 Sekunden aktualisieren
- Die Datenbank sollte normalisiert werden, um redundante Daten zu verhindern und die Leistung zu verbessern
- Die Datenbank sollte verteilt werden, um Ausfälle zu verhindern
Sicherheitsanforderungen
- Datenbanken sollten Sharding verwenden, um redundant zu sein, um Datenverlust zu vermeiden.,
- Backups der Datenbanken sollten stündlich durchgeführt und eine Woche lang aufbewahrt werden.
Sicherheitsanforderungen
- Alle für die REST-API verwendeten Schlüssel sollten sicher gespeichert werden.
- Nur die REST-API sollte eine Verbindung zu den Datenbanken herstellen können.
- Datenbanken sollten sich hinter einer Firewall befinden.
Softwarequalitätsattribute
- Verfügbarkeit: Da diese Anwendung für die Geschäftskommunikation von entscheidender Bedeutung ist, haben wir ein Ziel von vier Neunen(99,99%) Verfügbarkeit.,
- Korrektheit: Die Anwendung sollte niemals zulassen, dass jemand Nachrichten oder Diskussionen liest, die nicht für diese Person bestimmt sind.
- Wartbarkeit: Die Anwendung sollte eine kontinuierliche Integration verwenden, damit Funktionen und Fehlerbehebungen schnell und ohne Ausfallzeiten bereitgestellt werden können.
- Benutzerfreundlichkeit: Die Benutzeroberfläche sollte ohne Tutorial leicht zu erlernen sein und es Benutzern ermöglichen, ihre Ziele fehlerfrei zu erreichen.
Zusammenfassung
Ein SRS-Dokument ist ein notwendiger Teil des Abschlusses eines Softwareentwicklungsprojekts., Es ist die Roadmap, die allen am Projekt Beteiligten Anweisungen gibt, damit das Endprodukt den Bedürfnissen des Benutzers entspricht.
Ohne ein vollständiges SRS-Dokument, das vorhanden ist, bevor Sie ein Projekt starten, ist es schwierig zu erkennen, wann ein Projekt abgeschlossen ist, und kann die Entwicklung in die Erstellung unbeabsichtigter Funktionen ablenken. Ein SRS-Dokument gibt Ihnen die Möglichkeit, ein Projekt genau zu schätzen und Aufgaben effizient zuzuweisen.
Das Erstellen eines SRS-Dokuments kann zeitaufwändig und akribisch sein., Glücklicherweise hat das Team von Relevant über 200 Unternehmen geholfen, SRS-Dokumente zu erstellen und neue Produkte auf den Markt zu bringen. Wir sind bereit, mit Ihrem nächsten Software-Projekt zu helfen, schreiben Sie uns einfach eine Zeile.