Nachdem ich das IEEE-Standarddokument (IEEE 830-1998) darüber durchgesehen habe, was eine Softwareanforderungsspezifikation enthalten sollte, suche ich nun nach einer Anleitung für die nächsten Schritte nach der Erstellung eines SRS
Meiner Meinung nach soll ein SRS sicherstellen, dass das Entwicklungsteam und der Kunde auf derselben Seite sind, wenn es darum geht, die Funktionalität und den Umfang des Projekts herauszufinden. Was ich jetzt tun möchte, ist, von diesem Dokument wegzugehen und aufzuschreiben, wie das Projekt für das Entwicklungsteam implementiert wird.
Im Wesentlichen suche ich den nächsten Schritt nach Abschluss einer SRS. Mir ist klar, dass dies im Großen und Ganzen "das Projekt implementieren" bedeutet, aber wie konvertiert man ein SRS in etwas, das ein Entwickler verwenden kann? dh woher wissen sie, welche Tests geschrieben werden müssen?
Wenn Sie einem sequentiellen Prozess folgen, besteht der nächste Schritt wahrscheinlich darin, das Produkt zu entwerfen. Es gibt verschiedene Tools und Notationen, die dafür verwendet werden können, aber wenn Ihr Prozess Dokumente als Output oder Abschlussnachweis erwartet, wäre das Dokumentartefakt eine Software Design Description (SDD) . IEEE Std 1016 IEEE STandard for Information Technology – Systems Design – Software Design Descriptions liefert die Gliederung für ein solches Dokument. Die letzte Überarbeitung dieses Dokuments wurde 2009 veröffentlicht.
Der Standard schreibt keine spezifischen Entwurfswerkzeuge oder -methoden vor, aber Tabelle 1 enthält Beispiele für Entwurfssprachen, die verwendet werden können, um jeden der im Dokument vorgestellten Gesichtspunkte zu erfüllen, die von verschiedenen UML-Diagrammen über IDEF-Modelle bis hin zu IDL und Entscheidungstabellen reichen . Zusätzliche Beispiele dafür, was erwartet werden kann, sind im Text dieser Norm enthalten.
Beachten Sie, dass Design oft ein iterativer Prozess ist. Das SDD-Format wurde entwickelt, um sowohl High-Level- (Architektur) als auch Low-Level- (Detail-) Design zu erfassen. In einem iterativen Prozess wäre dies ein lebendiges Dokument, insbesondere die Detaildesignabschnitte auf niedrigerer Ebene.
Während das Design- und Entwicklungsteam das SDD erstellt (und möglicherweise Prototypen erstellt oder sogar einen Teil des Frameworks für das Projekt implementiert), wird das SRS meiner Erfahrung nach auch vom Testteam verwendet, um Akzeptanztests für die Software zu entwickeln. Dies sind die anforderungsbasierten Tests, die am Ende der Implementierung verwendet werden, um sicherzustellen, dass die Software die beabsichtigte Funktionalität erfüllt. Das Entwicklungsteam wird während des gesamten Designprozesses gleichzeitig an den Unit- und Integration-Level-Tests arbeiten (möglicherweise in Abstimmung mit den Testteams).
Ich stimme Thomas zu. Ich möchte nur hinzufügen, dass meiner Erfahrung nach der nächste Schritt nach Fertigstellung des Designs darin besteht, das Design mit den Beteiligten zu teilen. Dieses Design soll zeigen, WIE das System das WAS, das in der SRS ausgedrückt ist, umsetzen wird. Das Teilen des Designs mit den Stakeholdern gibt ihnen die Möglichkeit, mögliche Missverständnisse zu lokalisieren, was Ihnen die Möglichkeit gibt, sie zu beheben, bevor Sie mit der Implementierungsphase beginnen.
Das hängt natürlich von der Komplexität der Anforderungen ab. Außerdem könnte das Projekt an dieser Stelle gestoppt werden, wenn das Design eine Implementierung vorschlägt, die das Budget überschreitet.
Todd A. Jacobs
James Pudney