SRS: Basics zu Softwareanforderungsspezifikationen

Software-Anforderungsspezifikationen, auch bekannt als SRS, sind der Begriff, der eine ausführliche Beschreibung eines zu entwickelnden Softwareprodukts beschreibt. Sie gilt als eine der Anfangsphasen des Softwareentwicklungslebenszyklus (SDLC). Betrachten Sie es wie die Karte, die Sie zu Ihrem fertigen Produkt führt. Das Internet bietet viele großartige Beispiele für SRS für Entwickler , die offen fürs Lernen sind. Der Vorbehalt ist, dass SRS wie eine Karte genau befolgt werden muss, damit Sie am richtigen Ziel ankommen. Um klares, prägnantes und leicht verständliches SRS zu schreiben, müssen Sie Ihr Projekt verstehen. Aber Sie müssen auch die SRS-Richtlinien verstehen. Woran erkennen Sie, wann Ihr SRS bereit für die Entwicklung ist? Was macht es außergewöhnlich? Das werden wir in diesem Artikel behandeln.

Merkmale der außergewöhnlichen SRS

Es gibt bestimmte Dinge, die Entwickler in ihrem SRS-Dokument erreichen sollten, um es für ein reibungsloses Entwicklungsprojekt zu ermöglichen. Diese lassen sich in drei Kategorien unterteilen:

• Bedeutende Eigenschaften
• Merkmale, die Zielen erfüllen
• Identifizierbare Anforderungsgeruch

Schauen wir mal.

Bedeutungsvolle Eigenschaften

Die bedeutungsvollen Eigenschaften von SRS sind diejenigen, die dem Entwickler helfen, den gesamten Umfang des Projekts zu verstehen.

• Es wird das Problem aufschlüsseln. Ein gutes SRS zerlegt das Problem in Abschnitte, die leichter gelöst werden können. Das hilft auch, das Verständnis der Probleme zu verbessern und macht sie leichter anzugehen.
• Bietet Design-Input. Ihr SRS sollte Designdetails enthalten, um die Implementierung und Implementierung zu unterstützen.
• Berücksichtigt Komponenten für Feedback. Eine bedeutsame Eigenschaft für Nutzer der fertigen Software ist die Möglichkeit, Feedback zu geben. Dies sollte bei der Entwicklung eines starken SRS berücksichtigt werden.
• Beinhaltet Validierungsstrategien. Validierungsstrategien sollten implementiert werden, um sicherzustellen, dass Anforderungen korrekt formuliert sind und so funktionieren, wie sie vorgesehen sind.
• Anforderungen werden nach Wichtigkeit gerankt. Die Rangordnung der Anforderungen nach Wichtigkeit zeigt sowohl Entwicklern als auch Stakeholdern klar, wo die Prioritäten liegen. Wenn das Projekt eine bestimmte Frist erreicht, wie zum Beispiel das Ende eines Sprints, hilft ein Rangsystem den Entwicklern, Prioritäten leicht zu verschieben.
• Vollständig, prägnant und modifizierbar. Das fertige Produkt sollte so prägnant wie möglich ein Gesamtbild des Entwicklungsprojekts bieten, um das Verständnis zu fördern. Es sollte leicht anpassbar sein, um Feedback und Änderungen zu berücksichtigen.

Merkmale, die Ziele erfüllen

Jedes Entwicklungsprojekt sollte einen vorab festgelegten Zielsatz haben. Diese Eigenschaften werden genutzt, um sicherzustellen, dass die Ziele erreicht werden und das Projekt auf dem richtigen Weg bleibt.

• Beschreibender Arbeitsumfang. Ein klarer Arbeitsumfang zu haben, ist eines der wichtigsten Ziele. Der Umfang leitet die Entwickler durch das Projekt. Er schafft ein Verständnis dafür, wie das fertige Projekt aussehen soll, indem er definiert, wie man dorthin gelangt.
• Definiert Funktionen für den Endnutzer. Kundenanforderungen umfassen bestimmte Funktionen für den Endbenutzer, die im SRS definiert werden müssen.
• Bietet Möglichkeiten zur Überprüfung mit den Stakeholdern. Ein Zweck dieses Dokuments ist es, Transparenz zwischen Projektleitern und Stakeholdern zu gewährleisten. Deshalb sind Überprüfungen des SRS zwischen beiden Parteien ein wichtiger Maßstab für den Gesamterfolg.
• Klare Navigation. Eine klare, prägnante Dokumentstruktur mit Navigation ist ein wichtiger Bezugspunkt für Entwickler.
• Testen und Verfeinern. Ein Ziel jedes Entwicklungsprojekts ist es, ein Framework für das Testen zu haben. Eine weitere Überlegung ist, wie Sie das Framework nach der Implementierung verfeinern werden. Das SRS sollte beides abdecken.
• Schätzt die Kosten. Wichtig ist, dass das SRS in der Lage sein sollte, Entwicklungs- und Implementierungskosten sowie Betriebskosten abzuschätzen.

Identifizierbare Anforderungsgeruch

Ähnlich wie Code-Gerüche sind Anforderungsgerüche Hinweise darauf, dass eine Anforderung problematisch sein könnte. Entwickler sollten auf diese Eigenschaften achten und gegebenenfalls Änderungen vornehmen. Die Lösung erfolgt im Einzelfall, da sie in der Regel nicht zu fatalen Fehlern im Anforderungsartefakt führen. Deshalb gehören sie zu den Eigenschaften eines außergewöhnlichen SRS. Die Entwicklung einer fein abgestimmten Nase für diese Gerüche verbessert Ihre Arbeit. Beispiele für Anforderungsgerüche sind:

• Mehrdeutige Adverbien und Adjektive
• Subjektive Sprache
• Superlative
• Negative Aussagen

Richtlinien für eine außergewöhnliche SRS

Der Inhalt eines SRS kann von Projekt zu Projekt variieren. Dennoch sollte jedes Projekt, egal wie unterschiedlich, einem vorgeschriebenen Satz von Richtlinien folgen. Diese Richtlinien sind leicht zu merken, da ihr Akronym das Wort FACTS schreibt.

• Funktionale Anforderungen. Die Funktion des SRS ist von der des Entwicklungsprojekts selbst getrennt. Die funktionalen Anforderungen dieses Dokuments, um einen Rahmen für die Implementierung zu schaffen, sollten im gesamten Dokument klar sein.
• Analysemodell. Das Analysemodell ermöglicht es Ihnen, in die Spezifikation bestimmter Anforderungen einzutauchen. Ein Beispiel ist, wenn die Anforderung "Produkt in den Warenkorb hinzufügen" lautet, ein Befehl, der andere Details wie Größe und Menge nicht berücksichtigt. Diese können mit dem Analysemodell erweitert werden, da es funktionale Anforderungen mit dem Design verknüpft.
• Kognitives Modell. Dies ist das Entwicklungsmodell, das Entwicklern hilft zu verstehen, wie ein System von anderen, typischerweise Endnutzern, wahrgenommen wird.
• Der Inhalt und die Struktur der Spezifikation. Dies ist auch als Datenwörterbuch bekannt. Es sollte alle Daten rund um jede Entität sowie Organisationsflussdiagramme enthalten.
• Spezifikation. Die Richtlinien für die Spezifikation selbst müssen robust genug sein, um eine Geschichte des Entwicklungsprojekts zu erzählen, und flexibel genug, um Änderungen im Umfang und im Umfang zuzulassen.

Die Struktur der außergewöhnlichen SRS

Es gibt keinen einzigen Weg, dein SRS zu strukturieren, obwohl es mehrere Modelle als Beispiele gibt. Wenn du bisher die Eigenschaften und Richtlinien befolgt hast, bist du auf einem guten Anfang. Wenn es darum geht, das Dokument zusammenzustellen, könnte dein Framework ungefähr so aussehen:

Zweck/Einführung

• Definitionen
• Systemübersicht
• Quellen

Gesamtbeschreibung

• Produktperspektive
  • Systemschnittstellen
  • Benutzeroberflächen
  • Hardware-Schnittstellen
  • Software-Schnittstellen
  • Kommunikationsschnittstellen
  • Speicherbeschränkungen
• Konstruktionsbeschränkungen
  • Betrieb
  • Anforderungen an die Standortanpassung
• Produktfunktionen
• Benutzermerkmale
• Einschränkungen, Annahmen und Abhängigkeiten

Spezifische Anforderungen

• Externe Schnittstellenanforderungen
• Funktionale Anforderungen
• Leistungsanforderungen
• Logische Datenbankanforderung
• Attribute des Softwaresystems
  • Zuverlässigkeit
  • Verfügbarkeit
  • Sicherheit
  • Wartbarkeit
  • Portabilität
• Organisation spezifischer Anforderungen

Das obige Beispiel stammt aus den IEEE Guide to Software Requirements Specifications (Std 830-1993). Die IEEE ist eine Organisation, die die Industriestandards für SRS-Anforderungen festlegt. Sie ist der am weitesten verbreitete Standardssatz bei der Erstellung eines SRS und kann an die Bedürfnisse jeder Behörde angepasst werden.

Definition der Struktur

Einige Schlüsselkomponenten des obigen Beispiels sind wie folgt:

Zweck/Einführung

Der Zweckabschnitt sollte das gesamte SRS-Dokument zusammenfassen. Er ähnelt der Executive Summary of Business Documents und gibt den Ton für das Projekt vor. In der Regel gehören zu den wichtigsten Bestandteilen dieses Abschnitts Definitionen, Systemübersicht und Referenzen. Diese helfen, wichtige Themen im Entwicklungsprojekt festzulegen.

Gesamtbeschreibung

Die Gesamtbeschreibung gibt einen Überblick über die Anforderungen und andere Unterabschnitte. Die Anforderungen werden im Abschnitt über spezifische Anforderungen ausführlicher beschrieben. Die Funktion der Gesamtbeschreibung besteht darin, Faktoren zu bestimmen, die die Anforderungen beeinflussen. Unterabschnitte der Gesamtbeschreibung sind Produktperspektive, Designbeschränkungen, Produktfunktionen, Benutzereigenschaften und -beschränkungen, Annahmen und Abhängigkeiten. Diese betreffen alle die Vorhersage der Anforderungen und Herausforderungen, die der Erfüllung der Anforderungen im Weg stehen. Designbeschränkungen umfassen beispielsweise alles von der Berücksichtigung der Softwarekonformität bis hin zu Hardware-Einschränkungen.

Spezifische Anforderungen

Der Zweck des Abschnitts spezifische Anforderungen ist es, alle Anforderungen für die Entwicklung detailliert zu beschreiben. Dieser Abschnitt bietet einen Rahmen für Designer, um das Produkt entsprechend den Anforderungen zu erstellen. Im Abschnitt spezifische Anforderungen finden Sie externe Schnittstellenanforderungen, funktionale Anforderungen, Leistungsanforderungen, logische Datenbankanforderungen und Softwaresystemattribute. Jeder dieser Unterabschnitte beschreibt einen Satz von Anforderungen, die für das Gesamtfunktionieren des Programms notwendig sind.

Eine außergewöhnliche SRS schaffen

Jetzt wissen Sie, wie Sie ein außergewöhnliches SRS-Dokument erstellen. Eine schnelle Suche zeigt eine Reihe von Vorlagen, auf die Sie dieses neue Wissen anwenden können, falls Sie sich Ihrer neu erlernten Fähigkeiten noch nicht zu 100 % sicher sind. Es ist wichtig, es gleich beim ersten Mal richtig zu machen, da das SRS die Grundlage für Ihr gesamtes Entwicklungsprojekt bildet. Letztlich sollten Sie daran denken, dass das Ziel dieses Dokuments eine reibungslose Implementierung der Programmentwicklung ermöglicht, anstatt perfekte SRS zu haben. Zu den wichtigsten Komponenten, die wir besprochen haben, gehört, dass Ihr SRS flexibel, anpassungsfähig und skalierbar sein sollte, sodass es sich an die Anforderungen des Projekts anpassen kann. Wenn dies viel Informationen auf einmal zu erfassen scheint, dann ist es so. Dieser Artikel bietet eine übergeordnete Zusammenfassung einer komplexen Praxis. Der beste Ansatz für Ihre SRS-Forschung ist ähnlich wie die Rahmen, alle Ihre Entwicklungsprojekte den Interessengruppen zu präsentieren – in leicht verständlichen Informationen. Nehmen Sie sie in Abschnitten auf, während Sie sich durch jeden Abschnitt des Dokuments bewegen. Wenn es um dein nächstes Entwicklungsprojekt geht, wirst du dir selbst danken, dass du dir die Zeit genommen hast, mehr zu lernen. Wie bei allem wird Übung dein SRS stärken. Aber diese Richtlinien, Eigenschaften und Strukturempfehlungen sind ein guter Anfang.

Zusätzliche Ressourcen

• BMC DevOps Blog
• Bereitstellungspipelines (CI/CD) in der Softwareentwicklung
• Was ist extremes Programmieren?
• Python vs Go: Was ist der Unterschied?
• Wardley Wertschöpfungsketten-Kartierung: Was ist es und wie man seine eigene erstellt

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.