Softwareanforderungen

Toll !! Sie haben eine Idee für das nächste sich verändernde Softwareprodukt. Aber wie erklären Sie es den Leuten, die es tatsächlich für Sie bauen werden? Wie können Sie sicherstellen, dass die für Sie erstellte Software tatsächlich alle Ihre Anforderungen erfüllt? Richtig, Sie sollten Ihre Anforderungen in einem formalen Dokument beschreiben, das als „Software Requirements Specification“ -Dokument bezeichnet wird.

In diesem Artikel wird erläutert, was SRS ist, warum Sie es benötigen, worauf es beim Erstellen eines SRS-Dokuments ankommt und wie relevant oder irrelevant es in der heutigen agilen Welt ist.

SRS – Was Sie darüber wissen sollten

Was ist eigentlich ein SRS?

Ein Dokument zur Spezifikation der Softwareanforderungen enthält in erster Linie eine Beschreibung eines zu entwickelnden Softwareprodukts, die dessen funktionale und nicht funktionale Anforderungen abdeckt. Es dient als formelle Vereinbarung zwischen den Stakeholdern und dem Entwicklungsteam, was von dem Softwareprodukt zu erwarten ist, sobald es entwickelt ist.

Ein guter SRS beschreibt, wie das Softwaresystem mit allen internen Komponenten, der Hardware, der Synchronisation mit anderen Programmen und den Interaktionen der Endbenutzer mit einer Vielzahl von realen Zuständen zusammenarbeitet.

Um ein klares, kurzes und einfach zu verfolgendes SRS zu erstellen, müssen Sie die Details des Projekts verstehen. Andererseits müssen Sie auch die SRS-Richtlinien verstehen. Erstellen Sie SRS Schritt für Schritt, indem Sie die Anforderungen untersuchen. Nicht jeder im Team hat dasselbe Verständnisniveau, wenn Sie ein Meeting haben und ein Projekt besprechen.

Um Überraschungen in letzter Minute zu vermeiden, müssen Sie möglicherweise die Ziele und technischen Ziele des Projekts klar und präzise in einer Sprache definieren, die von jedem verstanden werden kann. Es gibt einige Dinge, die Programmierer unternehmen müssen, um in ihr SRS-Dokument Informationen für ein sauberes Entwicklungsprojekt aufzunehmen.

Warum ist ein SRS wichtig?

• Es wird während Überprüfungssitzungen verwendet.
• Es dient als Grundlage für den Vertrag zwischen dem Kunden und dem Entwickler.
• Es dient als Referenzquelle zu jedem Zeitpunkt des Entwicklungsprozesses.
• Das SRS-Dokument bietet dem Kunden und dem Team in der Anfangsphase einen klaren Einblick in das Endprodukt.
• Die gesuchten Ziele werden auf diese Weise unterschieden; der zeit- und kostenaufwand der entwickler wird erheblich reduziert.
• Die Ziele und Zwecke werden zusätzlich zu den erwarteten Ergebnissen angemessen definiert. Es bildet daher den Rahmen für das Softwaredesign.
• Während das Team oder der Product Owner gewechselt wird, muss keines von beiden von vorne beginnen. Dieses Dokument dient diesem Zweck.

Wie sieht eine gute SRS aus?

Das SRS-Dokument gibt an, wie die vorgesehene Software in der vorgesehenen Umgebung funktionieren muss. Ein guter SRS sollte folgende Punkte abdecken:

Einführung

1. Zielsetzung
2. Vereinbarungen dokumentieren
3. Gewünschtes Publikum
4. Informationen hinzugefügt
5. Kontakt Informationen
6. Verweise

Allgemeine Beschreibung

1. Produktausblick
2. Produkt zwecke
3. Benutzerklassen und Funktionen
4. Funktionsumgebung
5. Benutzerumgebung
6. Design- und Implementierungsbeschränkungen
7. Konventionen und Abhängigkeiten

Externe Schnittstellenanforderungen

1. Hardware-Schnittstellen
2. Software-Schnittstellen
3. Benutzeroberflächen
4. Kommunikationskonventionen und Schnittstellen

Systemfeatures

1. Beschreibung und Vorrang
2. Ergebnisse
3. Funktionale Anforderungen

Nicht-funktionale Anforderungen

1. Leistungsanforderungen
2. Sicherheitsanforderungen
3. Sicherheitsanforderungen
4. Software-Qualitätsmerkmale
5. Projektdokumente
6. Benutzerdokumente

Software-Systemattribute

1. Verlässlichkeit
2. Verfügbarkeit
3. Sicherheit
4. Wartbarkeit
5. Portabilität

Andere Vorraussetzungen

Appendix A: Jargon/Glossary/Definitions list

Ist SRS in der Agilen Ära immer noch relevant?

Die Ideologien hinter dem agilen Ansatz bestehen darin, den Kunden einen Mehrwert zu bieten. Dies bedeutet, dass wir uns mehr um die Entwicklung des Produkts bemühen, als Zeit mit unerwünschten Dingen zu verbringen. Dies bezieht sich auch auf die Dokumentation, das Entwicklungsteam folgt „Jetzt entwickeln, später dokumentieren“. Aber auch eine spätere Dokumentation ist aufgrund der Änderungen, die durch Benutzerfeedback hervorgerufen werden können, eine Herausforderung. Bei Sprints werden die User Stories priorisiert und im Product Backlog in die Warteschlange gestellt. Während in einem SRS-Dokument nicht versucht wird, die Anforderungen zu priorisieren.

Die Agile-Methodik ist also im Gegensatz zu einer SRS-basierten Entwicklungsmethodik. Wenn Sie auf Agile umsteigen, denken Sie daran, dass es bei Agile nicht erforderlich ist, die Dokumentation zu überspringen, sondern das Team dazu auffordert, sich mehr darauf zu konzentrieren, dem Kunden einen Mehrwert zu bieten.

Letzte Worte

Obwohl ein SRS zu Beginn des Projekts als ein altmodischer Weg in der Softwareentwicklung angesehen wird, kann Sie ein qualitativ hochwertiges, gut beabsichtigtes und gut geschriebenes SRS-Dokument anführen, wenn Sie ein solides Verständnis für Ihr gewünschtes Produkt haben zu einem erfolgreichen Softwareprodukt.

SRS kann auch als Referenzdokument für die agilen Teams dienen, damit sie nicht die Vision des Gesamtprodukts verlieren, wie sie von den ursprünglichen Stakeholdern vorgesehen war.