Was sind die Metriken für eine gute SRS (Software Requirement Specification)?

Ich habe gesucht, aber alles, was ich gefunden habe, sind die Eigenschaften eines guten SRS (Software Requirement Specification). Welche Metriken könnten Sie verwenden, um sicherzustellen, dass der Satz von Anforderungen gut ist?

Können Sie den Text Ihrer Frage erläutern? Ich bin mir nicht sicher, was Sie mit "alles, was ich gefunden habe, sind die Eigenschaften eines guten SRS" sagen wollen.

Antworten (3)

Einige der Metriken für eine gute SRS unterscheiden sich nicht von den Metriken, die eine gute Spezifikation definieren. Zum Beispiel:

  • Reife : gemessen an der Anzahl der TBXs, Abkürzung für zu bestimmen (TBD), zu prüfen (TBD), zu liefern (TBS) usw.
  • Verifizierungsinformationen : In einer guten Spezifikation hat jede Anforderung eine zugehörige Verifizierungsmethode (dh Test, Inspektion, Demonstration oder Analyse) und eine Methodik (dh welche Maßnahmen ergriffen werden, um die Anforderung zu verifizieren). Die Verifizierungsmethodik muss nicht lang sein, aber sie ist wichtig. Wenn die Anforderung beispielsweise ein System mit einem gewissen Prozentsatz an Betriebszeit ist, wie wird das gemessen? Für wie lange? Was zählt als Down?
  • baselined : Eine Spezifikation, die nicht unter Revisionskontrolle steht, ist nicht sehr nützlich

Weinberg und Gause schlugen in ihrem Buch „Exploring Requirements. Quality before Design“ (Dorset House 1989) eine „ Ambiguity Metric “ vor. Die Idee ist, dass Sie „qualifizierte Personen“ bitten, die Kosten oder den Aufwand für das Entwerfen und Erstellen einer Lösung zu schätzen, die die Anforderungen erfüllt. Wenn die Bandbreite der Schätzungen groß ist, wissen Sie, dass Sie noch viel zu tun haben.

Ich weiß nicht, ob jemand das jemals benutzt hat, aber ich denke, es ist nicht sehr praktisch.

Was Sie tun können, ist Ihren Anforderungstest- oder Überprüfungsprozess zu quantifizieren, was Sie sowieso tun sollten. Beispielsweise haben 17 von 20 Anforderungen die Tests bestanden. Sie können eine allgemeine Zahl berechnen oder je nach den einzelnen Tests detaillierter (z. B. 15/20 sind unvollständig; 3 haben wir noch nicht herausgefunden, wie man testet ...).

Tests einzelner Anforderungen können beliebige oder alle Kriterien für „gute Anforderungen“ sein, die die meisten Lehrbücher zum Requirements Engineering bieten, z

  • Vollständigkeit der Anforderungsvorlage
  • Rückverfolgbarkeit
  • Einheitliche Terminologie
  • Ist es relevant für die Unternehmensziele?
  • Ist es prüfbar
  • Die von Adam vorgeschlagene Fälligkeitszahl ist auch gut
  • Usw.

IEEE 830 verlangt, dass ein SRS korrekt, eindeutig, vollständig, konsistent, nach Wichtigkeit geordnet, überprüfbar, modifizierbar und rückverfolgbar ist.

Jede dieser Qualitäten könnte (und sollte) auf ihre eigene Weise verifiziert werden. Wie genau - hängt vom Format des SRS-Dokuments ab, das Sie verwenden.