Derzeit entwerfe ich ein SRS-Dokument (Software Requirement Specification) für ein agiles Projekt, und die Beispiele sind diejenigen, die in einem Wasserfallprojekt verwendet werden. Ich habe viel gegoogelt aber keine richtige gefunden. Ich war zuvor als Entwickler Teil eines agilen Projekts und verstehe auch den Arbeitsmechanismus, habe aber noch nie das Dokument erstellt. Insbesondere Bereiche wie der Umfang, der in Bezug auf Sprints variiert.
Meine Frage ist, ob jemand Muster-SRS für Agile-Projekte teilen kann? Welche Details müssen aus agiler Projektperspektive im Abschnitt Umfang und Meilenstein dargestellt werden?
Update: Obwohl der SRS nicht obligatorisch ist, haben wir ein Festpreisprojekt, das einen festen Zeitplan auf der Grundlage des Aufwandsantrags haben muss. Daher müssen die Anforderungen, die zusammen mit den möglichen Zeitplänen ausgearbeitet werden müssen, dokumentiert werden. Abgesehen von all dem muss das Projekt nach einem agilen Ansatz ausgeführt werden, wie mit dem Management besprochen, daher wird es höchstwahrscheinlich ein nachfolgender Übergang zu einem vollständigen agilen Ansatz von dem Ansatz sein, den wir derzeit ausführen. Allerdings sollte ich mich unter den gegenwärtigen Umständen für ein SRS-Dokument oder etwas Benutzerdefiniertes entscheiden
Viele agile Projekte produzieren keine Softwareanforderungsspezifikation im Sinne eines Dokuments, das eine Reihe von Soll-Aussagen zusammen mit einigen Annahmen und Abhängigkeiten auflistet, wie es in ISO/IEC/IEEE 29148 oder DI-IPSC-81433A beschrieben ist . Das bedeutet jedoch nicht, dass ein solches Dokument nicht erstellt werden kann.
Häufig erfassen agile Projekte „Anforderungen“ in Form von Anwendungsfällen, User Stories, Szenarien oder anderen benutzerzentrierten Formen. Die Anforderungen werden auch tendenziell in diejenigen unterteilt, an denen in der aktuellen Iteration gearbeitet wird, und diejenigen, an denen noch gearbeitet werden muss – in Scrum sind das das Sprint-Backlog und das Product-Backlog. Die einzigen Anforderungen, die gut analysiert, validiert und geschätzt werden, sind diejenigen, an denen in der aktuellen Iteration gearbeitet wird. Der Rest kann sich ändern – Anforderungen können jederzeit hinzugefügt, entfernt oder geändert werden.
Scott Ambler spricht in einem Essay über die Anforderungsmodellierung in einem agilen Umfeld . Auch Karl Wiegers und Joy Beatty diskutieren in ihrem Buch Software Requirements (3rd Edition) über Requirements Engineering in Agile .
Ich denke, eine von Scott Amblers Practices of Agile Modeling ist angemessen:
Wenden Sie das/die richtige(n) Artefakt(e) an. Jedes Artefakt hat seine eigenen spezifischen Anwendungen. Beispielsweise ist ein UML-Aktivitätsdiagramm nützlich, um einen Geschäftsprozess zu beschreiben, während die statische Struktur Ihrer Datenbank besser durch ein physisches Daten- oder Persistenzmodell dargestellt wird. Sehr oft ist ein Diagramm eine bessere Wahl als Quellcode -- Wenn ein Bild mehr als tausend Worte sagt, dann ist ein Modell oft 1024 Codezeilen wert, wenn es unter den richtigen Umständen angewendet wird (ein Begriff, der aus Karl Wiegers Softwareanforderungen entlehnt ist), weil Sie es können Erkunden Sie Designalternativen oft effektiver, indem Sie mit Ihren Kollegen ein paar Diagramme auf Whiteboards zeichnen, als wenn Sie sich hinsetzen und Codebeispiele entwickeln. Die Implikation ist, dass Sie die Stärken und Schwächen jeder Art von Artefakt kennen müssen, damit Sie wissen, wann Sie sie verwenden und wann nicht.
Müssen Sie ein SRS erstellen?
Wenn ja, müssen Sie das Dokument als lebendes Dokument aufbewahren. Herkömmliche planbasierte SRS-Dokumente und -Formate müssen angepasst werden. Wenn Sie dies tun müssten, würde ich empfehlen, eine fortlaufende Liste zu führen, welche Anforderungen welchem Sprint zugewiesen wurden, und sich nicht unbedingt auf den Rückstand zu konzentrieren. Dieses Dokument wird zu einer Beschreibung dessen, wozu die Software nach Abschluss jeder Iteration in der Lage ist, und nicht zu einer Reihe von Anforderungen, die erstellt werden müssen.
Wenn Sie nur einige Anforderungsartefakte erstellen müssen, vielleicht zu Compliance-Zwecken, prüfen Sie, ob Sie anstelle eines SRS ein anderes Artefakt erstellen können. Wenn Sie beispielsweise einen Audit-Trail für Anforderungsänderungen benötigen, kann es ausreichend sein, Besprechungsprotokolle Ihrer Backlog-Grooming-Sitzungen und Anforderungsänderungsanforderungen (zum Hinzufügen, Entfernen oder Neuordnen des Backlogs) zu führen und zu verfolgen, welche Anforderungen in welche Iterationen eingehen .
Wenn Sie eine SRS nicht wirklich benötigen, schauen Sie sich andere Artefakte an, die zum Erfassen und Kommunizieren von Anforderungen verwendet werden, die besser in agile Methoden passen.
Wenn Sie je nach Projekt einen Prototyp, ein Visionsdokument, Personas und einige PBI haben, glaube ich nicht, dass Sie SRS benötigen. Für komplexere oder Unternehmensanwendungen möchten Sie vielleicht ein UML-Dokument hinzufügen, aber ich denke, das Erstellen eines SRS-Dokuments ist ein langwieriger Prozess und nur eine zusätzliche Komplexitätsebene, die vermieden werden kann.
Mudassar