Software-Anforderungen richtig dokumentieren: Prozess und Vorlage!

Können Sie sich noch daran erinnern, wie Sie in der Schule Romane aus dem 19. Jahrhundert gelesen und gedacht haben: „Ist das überhaupt die gleiche Sprache?“ Vielleicht haben Sie sich im Büro bei der Zusammenarbeit mit technikbegeisterten KI-Entwicklern oder webversierten SEO-Analysten schon einmal genau dasselbe gedacht. Wenn es doch nur einen Dolmetscher für Kollegen gäbe.

Manchmal müssen Abteilungen eines Unternehmens zusammenarbeiten, die sonst wenig miteinander zu tun haben – auch wenn sie unterschiedliche technische Sprachen sprechen. Wenn Sie schon einmal in einem funktionsübergreifenden Team gearbeitet haben, wissen Sie, dass es zur Herausforderung werden kann, alle auf dem gleichen Stand zu halten.

Mit Hilfe von Dokumenten zur Spezifikation von Softwareanforderungen können Projektmanager, Produktmanager und Geschäftsanalysten übergeordnete Konzepte in Aktionspunkte unterteilen, denen jedes Teammitglied während des Entwicklungsprozesses folgen kann.

Was ist ein Dokument zur Spezifikation von Softwareanforderungen (SRS)?

Ein Dokument zur Spezifikation von Softwareanforderungen (engl. „Software Requirements Specification“ – SRS) listet die Anforderungen, Erwartungen, das Design und die Standards für ein zukünftiges Projekt auf. Es enthält die übergeordneten geschäftlichen Anforderungen, die das Ziel des Projekts bestimmen, die Anforderungen und Bedürfnisse der Endnutzer sowie die technische Funktionalität des Produkts. Kurz gesagt, ein SRS-Dokument beschreibt im Detail, wie ein Softwareprodukt funktionieren soll und wie Ihre Softwareentwickler es umsetzen sollen. Es zeigt auch, welche Anforderungen das Entwicklungsteam priorisieren sollte, damit die Umsetzung so effizient und praktikabel erfolgt.

Stellen Sie sich vor, Sie haben eine großartige Idee für eine App. Sie haben eine Vision davon, was die App tun und wie sie aussehen soll. Allerdings wissen Sie, dass Sie einem Entwickler nicht einfach eine verbale Beschreibung der Funktionen und Benutzeranforderungen geben und erwarten können, dass er Ihre Erwartungen sofort versteht und umsetzt. An dieser Stelle kommt das SRS-Dokument zur Spezifikation von Softwareanforderungen ins Spiel.

Warum sind Software-Anforderungen so wichtig?

Wenn Sie den Entwicklern Ihres neuen Produkts keine klaren Anweisungen geben, kann es passieren, dass es mehr Zeit und Geld kostet als erwartet, die Software so zu gestalten, wie Sie es sich vorgestellt haben.

Mit einem Dokument zur Spezifikation von Softwareanforderungen können Sie Ihre Idee zu Papier bringen und die Anforderungen klar formulieren. Dieses Dokument dient als übergeordnete Informationsquelle für alle Ihre Teams – vom Marketing bis zur Wartung.

Software-Anforderungsspezifikationen sind lebendige Dokumente und können daher auch als Kommunikationspunkt zwischen allen am Produktentwicklungsprozess Beteiligten dienen. Produktiterationen sind bei jedem Softwareentwicklungsprojekt unvermeidlich. Durch das Festhalten von Änderungen im SRS-Dokument können alle Beteiligten diese im Dokument prüfen. Dadurch können Sie eventuelle Unklarheiten bezüglich der Produktanforderungen vermeiden.

Was beinhaltet ein Dokument zur Spezifikation von Softwareanforderungen?

Ein grundlegendes Dokument für Software-Anforderungen besteht aus vier Teilen: einer Einleitung, den System- und Funktionsanforderungen, den Anforderungen an externe Schnittstellen und den nicht-funktionalen Anforderungen.

1. Einleitung

Die Einleitung Ihrer Spezifikation der Softwareanforderungen gibt einen Überblick über das gesamte Projekt aus der Vogelperspektive. Beschreiben Sie in Ihrer Einleitung den Zweck des Produkts, die Zielgruppe und wie die Zielgruppe das Produkt nutzen wird. Die Einleitung sollte folgende Punkte enthalten:

• Produktumfang: Der Umfang sollte sich auf die allgemeinen Geschäftsziele des Produkts beziehen. Dies ist besonders wichtig, wenn mehrere Teams oder Vertragspartner Zugriff auf das Dokument haben werden. Benennen Sie den Nutzen, die Zielsetzungen und die mit dem Produkt verfolgten Ziele.

• Produktwert: Warum ist Ihr Produkt wichtig? Wie wird es Ihrer Zielgruppe helfen? Welche Funktion wird es erfüllen oder welches Problem wird es lösen? Fragen Sie sich, welchen Nutzen Ihre Zielgruppe aus dem Produkt ziehen kann.

• Zielgruppe: Beschreiben Sie Ihre ideale Zielgruppe. Diese bestimmt das Aussehen Ihres Produkts und die Art und Weise, wie Sie es vermarkten.

• Verwendungszweck: Stellen Sie sich vor, wie Ihre Zielgruppe Ihr Produkt nutzen wird. Listen Sie die verfügbaren Funktionen und alle Möglichkeiten auf, wie Ihre Zielgruppe Ihr Produkt je nach Aufgabenbereich nutzen kann. Sie sollten auch Anwendungsfälle aufführen, um Ihre Vision zu veranschaulichen.

• Definitionen und Abkürzungen: Jede Branche und jedes Unternehmen hat ihre eigenen Abkürzungen und Fachausdrücke. Legen Sie die Definitionen der Begriffe fest, die Sie in Ihrem Dokument zur Spezifikation von Softwareanforderungen verwenden, damit alle Beteiligten verstehen, was gemeint ist.

• Inhaltsverzeichnis: Ein ausführliches SRS-Dokument kann sehr lang werden. Fügen Sie ein Inhaltsverzeichnis ein, damit alle Beteiligten schnell finden können, wonach sie suchen.

Achten Sie darauf, dass Ihre Einleitung klar und prägnant ist. Denken Sie daran, dass Ihre Einleitung der Leitfaden für den Rest des Dokuments sein wird. So können Sie sicherstellen, dass alle Benutzer des Dokuments dasselbe Verständnis davon haben.

2. System- und Funktionsanforderungen

Sobald Sie Ihre Einleitung haben, können Sie konkreter werden: Die funktionalen Anforderungen schlüsseln die Systemeigenschaften und -funktionen auf, die es Ihrem System ermöglichen, wie vorgesehen zu funktionieren.

Verwenden Sie Ihre Übersicht als Referenz, um zu überprüfen, ob Ihre Anforderungen die grundlegenden Bedürfnisse des Nutzers treffen, während Sie die Details ausfüllen. Je nach Produkt gibt es Tausende von funktionalen Anforderungen, die Sie aufnehmen können. Einige der häufigsten sind:

• Wenn/Dann-Verhalten

• Datenverarbeitungslogik

• Systemabläufe

• Transaktionsabwicklung

• Administrative Funktionen

• Regulierungs- und Compliance-Anforderungen

• Leistungsanforderungen

• Details der ausführbaren Aktionen für jeden Bildschirm

Wenn Ihnen das zu viel ist, versuchen Sie, eine Anforderung nach der anderen abzuarbeiten. Je mehr Details Sie in Ihre Anforderungsspezifikation aufnehmen, desto weniger müssen Sie sich später mit der Fehlersuche befassen.

3. Anforderungen an externe Schnittstellen

Die Anforderungen an externe Schnittstellen sind funktionale Anforderungen, die sicherstellen, dass das System ordnungsgemäß mit externen Komponenten kommuniziert, wie zum Beispiel den folgenden:

• Benutzeroberflächen: Dies ist der Schlüssel zur Benutzerfreundlichkeit einer Anwendung und umfasst unter anderem die Darstellung von Inhalten, die Anwendungsnavigation und die Benutzerunterstützung.

• Hardware-Schnittstellen: Die Merkmale der einzelnen Schnittstellen zwischen den Software- und Hardwarekomponenten des Systems, wie z. B. unterstützte Gerätetypen und Kommunikationsprotokolle.

• Software-Schnittstellen: Die Verbindungen zwischen Ihrem Produkt und anderen Softwarekomponenten, einschließlich Datenbanken, Bibliotheken und Betriebssystemen.

• Kommunikationsschnittstellen: Die Anforderungen an die Kommunikationsfunktionen, die Ihr Produkt nutzen wird, wie E-Mails oder eingebettete Formulare.

Eingebettete Systeme sind auf externe Schnittstellenanforderungen angewiesen. Sie sollten daher Aspekte wie Bildschirmlayouts, Tastenfunktionen und eine Beschreibung der Abhängigkeit Ihres Produkts von anderen Systemen einbeziehen.

4. Nicht-funktionale Anforderungen

Der letzte Abschnitt Ihres SRS-Dokuments beschreibt die nicht-funktionalen Anforderungen. Während funktionale Anforderungen einem System vorschreiben, was es zu tun hat, legen nicht-funktionale Anforderungen fest, wie Ihr System diese Funktionen implementieren wird. Eine funktionale Anforderung könnte zum Beispiel lauten, dass Ihr System einen Lieferschein ausdrucken soll, wenn ein Kunde Ihr Produkt bestellt. Eine nicht-funktionale Anforderung stellt sicher, dass der Lieferschein auf weißem Papier im Format 10x15 cm gedruckt wird, dem Standardformat für Lieferscheine.

Ein System kann zwar auch dann funktionieren, wenn Sie die nicht-funktionalen Anforderungen nicht erfüllen, aber Sie gefährden möglicherweise die Erwartungen der Benutzer oder Beteiligten. Diese Anforderungen berücksichtigen die funktionalen Anforderungen, so dass Attribute wie die Erschwinglichkeit und die Benutzerfreundlichkeit des Produkts weiterhin gegeben sind.

Die häufigsten Arten von nicht-funktionalen Anforderungen betreffen folgende Bereiche:

• Sicherheit: Was ist erforderlich, damit alle sensiblen Informationen, die Ihre Software von den Nutzern sammelt, geschützt sind?

• Kapazität: Der aktuelle und künftige Speicherbedarf Ihres Produkts, einschließlich eines Plans, wie Ihr System bei steigenden Volumenanforderungen skaliert werden kann.

• Kompatibilität: Die Mindestanforderungen an die Hardware Ihrer Software, z. B. die Unterstützung von Betriebssystemen und deren Versionen.

• Zuverlässigkeit und Verfügbarkeit: Wie oft werden die Nutzer Ihre Software voraussichtlich verwenden, und wie hoch ist die kritische Ausfallzeit bei normaler Nutzung?

• Skalierbarkeit: Die höchste Arbeitslast, bei der Ihr System noch die erwartete Leistung erbringt.

• Wartungsfähigkeit: Wie Ihre Anwendung kontinuierliche Integration nutzen sollte, damit Sie Funktionen und Fehlerbehebungen schnell bereitstellen können.

• Benutzerfreundlichkeit: Wie einfach es sein soll, das Produkt zu benutzen.

Andere gängige Arten von nicht-funktionalen Anforderungen sind Leistungs-, Regulierungs- und Umweltanforderungen.

Vorlage für ein Dokument zur Spezifikation von Softwareanforderungen

Sind Sie bereit, Ihr eigenes Softwareentwicklungsprojekt zu starten? Unsere Vorlage für ein SRS-Dokument enthält alle vier Schlüsselkomponenten, die Ihnen und Ihrem Team wertvolle Einblicke in das zu entwickelnde Produkt geben. Denken Sie daran, Ihre Anforderungen detailliert, klar und präzise zu formulieren, damit alle Beteiligten die gleiche Vision im Kopf haben.

Bewährte Vorgehensweisen beim Verfassen eines SRS-Dokuments

Der Zweck eines Dokuments zur Spezifikation von Softwareanforderungen besteht darin, dass jedes Team in jeder Abteilung auf ein klares Ziel hinarbeitet. Dennoch gibt es einige bewährte Vorgehensweisen, die zu beachten sind, damit Ihr Dokument seinen Zweck erfüllt.

Ergänzen Sie Ihr SRS-Dokument mit visuellen Elementen

Die Einbeziehung visueller Elemente wie Diagramme, Schemata und Modelle hilft den Teammitgliedern, den Prozess besser zu verstehen. Sie sind besonders nützlich, wenn es darum geht, die Hauptfunktionen und die Bedienbarkeit Ihrer Software zu veranschaulichen.

Eine Technik, die Sie beim Brainstorming für Ihr Projekt ausprobieren können, ist das Mind Mapping, bei dem Sie Ideen, Merkmale und Szenarien organisieren und Verbindungen zwischen ihnen herstellen. Erstellen Sie eine Mind Map, um zufällige Gedanken zu strukturieren, während Sie Ihre Ideen ordnen. Diese Darstellung muss nicht besonders detailliert sein – dafür ist Ihr Software-Anforderungsdokument gedacht. Konzentrieren Sie sich stattdessen auf die wichtigsten Funktionen Ihrer Software und wie diese miteinander zusammenhängen.

Seien Sie klar und präzise

Geben Sie Ihren Entwicklern klare und präzise Anweisungen für die Umsetzung des Projekts, um Missverständnisse und Unklarheiten zu vermeiden. Beschreiben Sie Ihre Softwareanforderungen so detailliert wie möglich, und vermeiden Sie Folgendes:

• Verwendung vager Begriffe wie „grundsätzlich“ oder „ungefähr“

• Kombination von Begriffen mit einem „/“, das als „und“ oder „oder“ interpretiert werden könnte

• Verwendung komplizierter Werte für Limits

• Verwendung von doppelten und dreifachen Negativen

Eine formelle Überprüfung durch Kollegen ist eine gute Möglichkeit, um Unklarheiten in Ihrem SRS-Dokument aufzudecken. Planen Sie, das Dokument mit allen Beteiligten einzeln durchzugehen, um deren Verständnis der Anforderungen zu vergleichen und die notwendigen Änderungen vorzunehmen.

Kennen Sie Ihren Endnutzer

Fügen Sie Ihre Marktforschung und Nutzerinterviews in das Dokument zur Spezifikation von Softwareanforderungen ein, um ein klares Verständnis der Anforderungen, Erwartungen und Bedürfnisse Ihrer Endnutzer zu entwickeln. So können Sie sich ein Bild von den Vorgängen machen, die der Endnutzer mit der Software durchführen wird. Berücksichtigen Sie alle möglichen Szenarien und Nuancen, die auftreten könnten, und beziehen Sie sie mit ein. Denken Sie daran, dass Ihre Entwickler genau das implementieren werden, was Sie in das Dokument aufgenommen haben – nicht mehr und nicht weniger.

Planen Sie einen Spielraum für Flexibilität ein

Ihr Dokument zur Spezifikation von Softwareanforderungen ist ein lebendiges Dokument, d. h. Sie werden bei jeder Iteration neue Funktionen und Änderungen hinzufügen. Berücksichtigen Sie dies, indem Sie die Anforderungen flexibel halten, falls das Ergebnis nicht Ihren Erwartungen entspricht. Um Missverständnissen vorzubeugen, sollten Sie auch die Änderungen an dem Dokument aufzeichnen. Die Beteiligten sollten in der Lage sein, jede Anforderung bis zum Original zurückzuverfolgen und zu sehen, wer die Änderung wann und warum vorgenommen hat.

Verwenden Sie SRS-Dokumente, um Ihre Vision zu verdeutlichen

Das Verfassen eines Dokuments zur Spezifikation von Softwareanforderungen ist nicht einfach – aber das gilt auch für die endlose Fehlersuche oder das Ausfechten von Diskussionen zwischen Ihren Teammitgliedern. Die Arbeit, die Sie in ein umfassendes SRS-Dokument stecken, wird sich mit einem beeindruckenden Produkt auszahlen, auf das Sie und Ihre Projektbeteiligten stolz sein können.