Erstellung wertvoller Software-Anforderungsspezifikationen für eine bessere Softwareentwicklung

By Kate Eby | 21. Juli 2017

Bei der Entwicklung von Software kann die Definition von Anforderungen vor Beginn der Entwicklung Zeit und Geld sparen. Ein Software-Anforderungsdokument definiert klar alles, was die Software leisten muss, und ist eine Ausgangsbasis für die Definition anderer Elemente eines Produkts, wie Kosten und Zeitpläne. Es gibt keinen Ersatz für gute Anforderungen, aber jede Entwicklungsorganisation verfolgt einen einzigartigen Ansatz für den Prozess, der auf ihren Bedürfnissen basiert.

In der Welt des Projektmanagements gibt es zwei Verwendungen des Akronyms SRS.  Eins steht für Software Requirements Specification (dt.Softwareanforderungsspezifikationen) - dies ist eine groß angelegte mehrgleisige Reihe von Projekten, bei denen die Software-Anforderungsspezifikation, das Thema hier, eine wichtige Rolle spielen kann (wenn das Projekt mit der Softwareentwicklung in Verbindung steht). Dieser Artikel erläutert die Bedeutung von Softwareanforderungen, das Schreiben effektiver Softwareanforderungen und enthält Musterdokumente für Softwareanforderungsspezifikationen (SRS) zur Anleitung.

Was sind Software-Anforderungsspezifikationen?

Softwareanforderungsspezifikationen (SRS) artikulieren schriftlich die erforderlichen Fähigkeiten, Funktionen, Innovationen und Einschränkungen eines Softwareentwicklungsprojekts. Ein SRS ist ein Dokument, das die Wünsche der Entscheidungsträger, alle Elemente (funktionale und nichtfunktionale Bereiche), die Funktionsweise und Interaktion der Software mit den Benutzern sowie die Probleme berücksichtigt, die die Software lösen wird. Dieses Dokument dient dann als "übergeordnetes" Dokument zur Unterstützung des Design- und Entwicklungsprozesses. Das Dokument mit den Spezifikationen für Softwareanforderungen wird dann verwendet, um Zeitpläne und Kostenschätzungen für Design, Tests, Validierung und Lieferung zu erstellen. Das Dokument legt auch fest, was bei der Validierung und dem Testen zu überprüfen ist und wie funktionale Elemente rangiert werden.


Das Recherchieren und Schreiben von SRS wird seit langem bei der Vorbereitung auf den Entwurf, die Entwicklung und die Bereitstellung neuer Software verwendet. Nach umfangreichen Eingaben verschiedener technischer und nichttechnischer Komponenten wird das Dokument so verfasst, dass es einen umfassenden, narrativen Überblick darüber bietet, was die Software erreichen wird und wie sie sich verhält. Eines ihrer Hauptziele besteht in der Förderung eines Konsenses darüber, was für das neue Produkt erforderlich ist, bevor mit dem eigentlichen Design, der Entwicklung und dem Programmieren begonnen wird.

Warum sind Softwareanforderungen wichtig?

Die Bedeutung von SRS wird zuerst durch seine Fähigkeit erkannt, den Entscheidungsträgern klare Kommunikation darüber zu vermitteln, was entwickelt wird und wie es funktionieren wird. Bevor Entwickler eine Codezeile schreiben, wurden alle Elemente des Produkts durch Narrative, Spezifikationen, Visuals wie Grafiken und Tabellen sowie durch Anwendungsfälle und reale Szenarien spezifiziert und artikuliert. Die Entwicklung eines SRS ist bei der internen Entwicklung neuer Software ebenso wertvoll wie die Bereitstellung eines artikulierten Spezifikationsdokuments bei der Vergabe von Softwareentwicklung an externe Entwicklungsressourcen. Einige der Ziele der Softwareanforderungsspezifikationen umfassen:

  • Eine genaue Beschreibung des Umfangs der zu verarbeitenden Arbeiten
  • Klare, leicht zu verwaltende Details für Softwaredesigner und Entwickler
  • Anwendungsszenarien für das Testteam
  • Ausrichtung der Kundenanforderungen an Funktionen
  • Aktualisierbare Single Source of Truth (dt.einzige datenbasierte Wahrheit) für die Softwareentwicklung
  • Enthält Beiträge von einer Vielzahl von Entscheidungsträgern

Vorteile großer Softwareanforderungen

Ein starkes SRS-Dokument kann Zeit bei der mehrschichtigen Kommunikation sparen, einschließlich Benutzer-/Kundeneingaben und Feedback, Design, Validierung, Tests und der allgemeinen Benutzerakzeptanz. Da die wichtigsten Entscheidungsträger Zugriff auf den Inhalt des Dokuments haben und sich der vereinbarten Fähigkeiten und Funktionen bewusst sind, kann das SRS auch dazu beitragen, doppelten Aufwand zu vermeiden und den Design- und Entwicklungsprozess zu optimieren. Wenn sich diese strenge Untersuchung auf Papier gebracht und sich die beteiligten Parteien auf den Umfang und die Funktionen einigen, wird die Notwendigkeit kostspieliger Redesign- oder Änderungen in der Mitte des Projekts minimiert. Das SRS kann auch wertvolle Zeit in der Kommunikation während des Entwicklungs- und Buildprozesses oder beim Hinzufügen neuer Spieler zum Team sparen. Darüber hinaus wird ein umfassendes SRS:

  • Die Genauigkeit von Kosten- und Zeitschätzungen erhöhen
  • Den Übergang von Software von der Entwicklung zur Produktion vereinfachen
  • Handelt als eine einzige Quelle der Wahrheit bezüglich, was in die Softwarelösung enthalten sein soll
  • Verbessert die Kommunikation mit Entscheidungsträgern und Kunden, indem Teile der Spezifikationen geteilt werden
  • Reduziert kostspielige spät Phasenänderungen
  • Dokumentdetails zur zukünftigen Referenz
  • Benutzer mit einer dokumentierten Liste von Anforderungen zur Verfügung stellen
  • Reduzierung des Entwicklungsaufwands und der Aufgabenduplizierung

 

Wer verwendet die Software-Anforderungsspezifikationen?

Das SRS-Dokument enthält narrative Elemente sowie detaillierte Spezifikationselemente. Selbst wenn ein technischer Schreiber das Dokument schreibt, ist es daher wichtig, viele Komponenten in die Planung des SRS mit einzubeziehen. Die Entwicklung eines SRS kann Mitarbeiter aus dem Marketing und Projektmanagement, Support-Personal, Produktmanagement, Kunden und die Entwicklungsingenieure umfassen. Entwickler, ob Vollzeit- oder Auftragnehmer, und Tester nutzen das SRS, um sicherzustellen, dass sie die Softwarelösung entsprechend den Anforderungen entwickeln.


Zu den Methoden, um benötigte Informationen von Entscheidungsträgern zu erhalten, gehören Fragebögen, Interviews, Forschung, Meetings und Fokusgruppen. Die Ermittlung und Untersuchung von Fakten beginnt damit, zu identifizieren, was enthalten sein soll und das übergeordnete Ziel der Software. Es ist auch vorteilhaft zu definieren, was die Software nicht tun wird und ob Branchen-, Unternehmenspolitik- oder Hardwareeinschränkungen bestehen. Wir sollten beachten, dass Sie keine echten Designelemente in das Dokument einarbeiten. Stattdessen enthält die endgültige Version die entsprechenden Narrative und Beschreibungen, Grafiken und andere Visuelles, technische Spezifikationen, Definitionen, Priorisierungs- und Bewertungsprotokolle, Referenzmaterialien, Validierung und Tests sowie Benutzerszenarien, um dann die Lösung zu erstellen. Sie integrieren alle Fragen zu Funktionen mit aktuellen Funktionen, Einschränkungen, Geschäftlichen Bedenken und Kosten.


Rich Graves, Head of Produkt Management bei ServiceAide,verfolgt genau das Agile Framework für die Softwareentwicklung. Er findet, dass die Art des Denkens von Jobs-to-be-Done ihm und seinem Team hilft, ein besseres Produkt zu erstellen. "Jobs-to-be-Done ist eine kundenorientierte Denkweise", sagt Graves. "Es zwingt uns, über den Benutzer und sein Endziel nachzudenken. Wenn wir uns mit dem Benutzer identifizieren und seine Probleme verstehen, können wir Anforderungen schreiben und ein Produkt entwickeln, das wirklich innovativ ist. Anforderungserfassung ist für uns kein Rätselraten, da wir uns auf den Zielbenutzer, seine realen Probleme und wie wir sie besser als alle anderen lösen können, konzentrieren."

 

Best Practices für das Schreiben von Softwareanforderungsspezifikationen

Im Jahr 2011 wurde der lange verwendete IEEE 29148:1998-Standard und die Vorlage aktualisiert und erweitert und ist jetzt als ISO/IEC/IEEE 29148 bekannt. Dieser Anleitungsleitfaden enthält Informationen zur Entwicklung eines starken SRS-Dokuments, das Best Practices in fünf Modulen angibt. Die ersten drei Bereiche beschreiben Elemente, die sich auf Prozesse konzentrieren, um den Umfang zu definieren, mithilfe von richtigen Referenzen und Definitionen festzulegen.


Das 4. Modul, das am längsten ist, bezieht sich auf Methoden zur Bestimmung der Art, der vorherrschenden Umgebung und der allgemeinen Merkmale für die Entwicklung eines guten SRS-Dokuments und -Plans.  Die Artikulation dieser Eigenschaften zu meistern, kann zu einem hochwertigen und nutzbaren SRS führen.
Das Dokument sollte sein:

  • Richtig: Eine Analysemethode, die sicherstellt, dass die Software die ermittelten Anforderungen erfüllt.
  • Eindeutig: Es gibt nur eine Interpretation, wofür die Software verwendet wird, und sie wird in einer gemeinsamen Sprache kommuniziert.
  • Komplett: Es gibt eine Darstellung für alle Anforderungen an Funktionalität, Leistung, Designeinschränkungen, Attribute oder externe Schnittstellen.
  • Konsistent: Sie müssen mit anderen Dokumentationen, einschließlich einer Systemanforderungenspezifikation und anderen Dokumenten, im Einvernehmen sein.
  • Rangiert nach Wichtigkeit und/oder Stabilität: Da alle Anforderungen nicht von gleichem Gewicht sind, sollten Sie eine Methode verwenden, um Anforderungen angemessen zu rangieren.
  • Überprüfbar: Verwende messbare Elemente und definierte Terminologie, um Unklarheiten zu vermeiden.
  • Modifizierbar: Eine klar definierte Organisationsstruktur des SRS-Dokuments, die Redundanzen vermeidet, kann eine einfache Anpassung ermöglichen.
  • Nachvollziehbar: Möglichkeit, den Ursprung der Entwicklung zurück zu verfolgen und zu den dokumenten zu kommen, die aus dem SRS erstellt wurden.

Zane Bond,Senior Produkt Manager bei Cisco, sagt: "Anforderungen stehen im Mittelpunkt jedes neuen Entwicklungsprojekts. Zu verstehen, was tatsächlich erforderlich ist, ist sowohl eine Wissenschaft als auch eine Kunst. Unabhängig von Ihrer Entwicklungsmethodik, Kultur oder Lieferarten ist das Schreiben klarer und verständlicher Anforderungen oft ein entscheidender Faktor für den Erfolg Ihres Projekts. Sie wissen, dass Sie sie richtig gemacht haben, wenn sie so einfach sind, sie fragen sich, warum es so viele Kundeninteraktionen, Marktanalysen, Design-Meetings und mehr brauchte, um sie zu schreiben."
Bond bietet ihnen folgende Tipps zum Komponieren eines SRS:

  • Je einfacher die Anforderungen sind, desto weniger schränken Sie Ihr Team ein, dinge auf eine bestimmte Weise zu tun. Es besteht immer ein Gleichgewicht zwischen dem Sicherstellen, dass das Team über genügend Kontext verfügt, um das Richtige zu tun, und dem Diktieren, was durch zu spezifische Anforderungen erforderlich ist. Dieses Zitat von Antoine de Saint-Exupéry kommt mit Anforderungen in den Sinn: 'Es scheint, dass Perfektion nicht erreicht wird, wenn es nichts mehr hinzuzufügen gibt,sondern wenn es nichts mehr zu entfernen gibt .' Perfektion ist nicht wirklich das Ziel, sondern der Geist, mit dem zu beginnen, was Sie wollen, und sie dann auf das Wesentliche zu paaren.
  • Die Anforderungen müssen sich auch klar auf das Problem beziehen, das Sie lösen - wer dies braucht, warum sie dies benötigen und mehr. Den Kontext hinter einer Reihe von Anforderungen zu kennen, hilft einem Team wirklich, bessere Entscheidungen im Prozess zu treffen.
  • Die SMART-Kriterien helfen Ihnen, sicherzustellen, dass Ihnen keine wichtige Elemente fehlen. Wie weit Sie dazu gehen, hängt von der Größe des Gebäudes ab. Einige wirklich kleine Dinge können mit minimalen Anforderungen erledigt werden, mittlere bis größere strategische Gegenstände, erfordern gründlichere Anforderungen.

 

So erstellen Sie Software-Anforderungsspezifikationen

Seit 1998 wird die IEEE-Vorlage zum Schreiben von Softwarespezifikationsanforderungen in zahlreichen Branchen verwendet. Einige der gängigsten Vorlagen verwenden heute die Standardsprache und die inkrementelle Einrichtung, die in Modul fünf der ISO/IEC/IEEE 29148 enthalten ist, einschließlich:


i. Einführung
Dieser Bereich umfasst Umfang, Zweck, Definitionen, Referenzen und einen Übersicht.


ii. Gesamtbeschreibung
Dokumentieren Sie in diesem Abschnitt die Bereiche Produktperspektive und Funktionalität, Benutzermerkmale, Einschränkende Elemente (wie Annahmen und Abhängigkeiten) und Aufteilung der Anforderungen.


iii. Spezifische Anforderungen (der größte und wichtigste Bereich)
Enthalten alle Anforderungen, Funktionen, Schnittstellen, Leistungs- und Datenanforderungen, Designeinschränkungen, Sicherheit, Anpassungen, die für die Implementierung, Wartung, Features und Systemattribute, Prioritäten und Release-Pläne erforderlich sind.


iv. Unterstützende Informationen
Schließen Sie alle Indizes, Grafiken, Anhänge und speziellen Anweisungen ein, die in diesem Abschnitt noch nicht behandelt wurden.


Obwohl alle Bereiche des SRS den gleichen Wert haben, wird in der eigentlichen Gliederung geschätzt, dass Sie etwa ein Viertel der Zeit dem Abschnitt Spezifische Anforderungen widmen sollten, wobei der Schwerpunkt auf der Priorisierung von Funktionen und Anforderungen, Validierung und Tests für die Veröffentlichung liegt.

 

Top 10 Tipps zum Schreiben von Softwareanforderungen

Das Schreiben von Softwareanforderungen erfordert Zeit, aber die Auszahlung ist enorm, wenn sie richtig ausgeführt wird. Im Folgenden finden Sie 10 Tipps, die Ihnen helfen, ein effektives SRS zu schreiben:

  • Nehmen Sie sich Zeit, um Anforderungen genau und gründlich zu schreiben, insbesondere wenn es sich um eine große, robuste, langfristige Softwarelösung handelt
  • Der Autor sollte nicht der Entwickler sein, sondern eine Person, die die Bedürfnisse der Entscheidungsträger und die Entwicklungssprache versteht
  • Stellen Sie sicher, dass der Autor über starke Kommunikationsfähigkeiten verfügt
  • Fügen Sie Bilder, Grafiken, Diagramme und Diagramme ein, um Anforderungen zu artikulieren
  • Aktualisieren Sie das SRS, wenn Sie Änderungen vornehmen oder Anforderungen neu priorisieren
  • Bewahren Sie das SRS an einem online oder freigegebenen Ort, auf den das Team leicht zugreifen kann
  • Verwenden Sie die Anforderungen für Tests und Validierungen
  • Schreiben Sie den SRS für Ihre Zielgruppe
  • Stellen Sie sicher, dass das SRS alles enthält, was das Entwicklungsteam zum Erstellen des Produkts benötigt
  • Link zu zugehörigen Inhalten und Dokumentationen

Es wird oft gesagt, dass Sie keine großartigen Produkte erstellen können, ohne zuerst einen großartigen Plan zu haben. Dieses "großartige Plan"-Dokument bietet erhebliche Schutzmaßnahmen, Kommunikationsmöglichkeiten und Kosten- und Zeitsparende Vorteile für das Design und die Erstellung oder für den Kauf neuer Software. Durch die Früheinführung der Kunden, Benutzer, technischen Teams, des Managements und anderer Entscheidungsträger in den Prozess können Kommunikation, Budgetierung, Zeitpläne und das wesentliche Zustimmung vor der Einleitung des Designprozesses erfolgreich sein oder zum Erfolg führen, wenn Sie die Software endlich bereitstellen.

 

Verwenden Sie Smartsheet, um Ihr Software-Anforderungsdokument in eine Funktionierende Checkliste zu verwandeln, um die Entwicklung zu verwalten

Befähigen Sie Ihr Team, über sich selbst hinauszuwachsen – mit einer flexiblen Plattform, die auf seine Bedürfnisse zugeschnitten ist und sich anpasst, wenn sich die Bedürfnisse ändern. Mit der Plattform von Smartsheet ist es einfach, Arbeiten von überall zu planen, zu erfassen, zu verwalten und darüber zu berichten. So helfen Sie Ihrem Team, effektiver zu sein und mehr zu schaffen. Sie können über die Schlüsselmetriken Bericht erstatten und erhalten Echtzeit-Einblicke in laufende Arbeiten durch Rollup-Berichte, Dashboards und automatisierte Workflows, mit denen Ihr Team stets miteinander verbunden und informiert ist. Es ist erstaunlich, wie viel mehr Teams in der gleichen Zeit erledigen können, wenn sie ein klares Bild von der geleisteten Arbeit haben. Testen Sie Smartsheet gleich heute kostenlos.

Verbinden Sie Ihre Mitarbeiter, Prozesse und Tools mit einer einfachen, benutzerfreundlichen Plattform.

Smartsheet kostenlos testen Get a Free Smartsheet Demo