Qualität der Softwareanforderungen

Die Qualität der Anforderungen ist Gegenstand einiger Diskussionen unter Fachleuten für Softwareanforderungen. Hier sind vier durchdachte Ansichten zur Qualität von Softwareanforderungen, die ausmachen eine gute Voraussetzung oder ein gutes Anforderungspaket.

Warum ist die Qualität der Anforderungen wichtig?

Oft ist es sinnvoll, die Dinge umgekehrt zu betrachten. Fragen Sie sich: Welche Auswirkungen haben schlechte Anforderungen? Diese Grafik verdeutlicht, dass es aufgrund schlechter Anforderungen zu einem nichtlinearen Anstieg der Nacharbeit kommt.

Die Kosten für minderwertige Softwareanforderungen bei der Generierung von Nacharbeiten
Ein Vergleich von Anforderungen Qualitätsattribute nach verschiedenen Quellen:

Unsere Ansicht

Wir empfehlen etwas, das dem IIBA BABOK sehr nahe kommt, wie folgt

  • Klar: eindeutige funktionale Bedeutung.
  • Prägnant: enthält keine belanglosen und unnötigen Inhalte.
  • Benutzerorientiert: konzentriert sich auf das, was der Benutzer erreichen muss.
  • Vollständig: sowohl intern vollständig (alle Funktionsschritte innerhalb einer Anforderung) als auch als Set, alle CRUD-Ereignisse abgedeckt
  • Konsistent: Benutzer- und Objektnamen sind über eine Reihe von Anforderungen hinweg konsistent
  • Messbar: kann in KOSMISCHEN Funktionspunkten dimensioniert werden
  • Testbar: Wenn es messbar ist, ist es normalerweise auch testbar.
  • Wertvoll : ist für die Bereitstellung wesentlicher Benutzerfunktionen erforderlich.
  • Designfrei: schließt aus, „wie“ es implementiert werden soll.
  • Einzigartig: Keine doppelte Funktionalität im gesamten Anforderungssatz

Und in der IIBA-Übersicht zur Anforderungsqualität heißt es:

Während die Qualität letztendlich von den Bedürfnissen der Stakeholder bestimmt wird, die die Anforderungen oder Designs verwenden, weisen akzeptable Qualitätsanforderungen viele der folgenden Merkmale auf.“

  • Atomar: in sich geschlossen und unabhängig von anderen Anforderungen oder Gestaltungen verständlich.
  • Vollständig: ausreichend, um die weitere Arbeit zu leiten, und mit dem entsprechenden Detaillierungsgrad, damit die Arbeit fortgesetzt werden kann. Der erforderliche Grad der Vollständigkeit unterscheidet sich je nach Perspektive oder Methodik sowie dem Punkt im Lebenszyklus, an dem die Anforderung untersucht oder dargestellt wird.
  • Konsistent: auf die ermittelten Bedürfnisse der Stakeholder ausgerichtet und nicht im Widerspruch zu anderen Anforderungen.
  • Prägnant: enthält keine belanglosen und unnötigen Inhalte.
  • Machbar: angemessen und möglich innerhalb des vereinbarten Risikos, Zeitplans und Budgets oder als machbar genug angesehen, um weitere Untersuchungen durch Experimente oder Prototypen durchzuführen.
  • Eindeutig: Die Anforderung muss klar dargelegt werden, sodass deutlich wird, ob eine Lösung den damit verbundenen Bedarf erfüllt oder nicht.
  • Testbar: Kann überprüfen, ob die Anforderung oder das Design erfüllt wurde. Akzeptable Grade der Überprüfung der Erfüllung hängen vom Abstraktionsgrad der Anforderung oder des Designs ab.
  • Priorisiert: in Bezug auf Wichtigkeit und Wert gegenüber allen anderen Anforderungen eingestuft, gruppiert oder ausgehandelt.
  • Verständlich: dargestellt unter Verwendung der üblichen Terminologie des Publikums.

Abschnitt 4.3 von IEEE Std 830 enthält eine Liste der gewünschten Qualitätsattribute einer Softwarespezifikation:

„Ein SRS sollte sein:

  1.  Richtig;
  2. Eindeutig;
  3. Vollständig;
  4. Konsistent;
  5. Nach Wichtigkeit und/oder Stabilität eingestuft;
  6. Überprüfbar
  7.  Modifizierbar;
  8. Nachvollziehbar.“

Merkmale testbarer Anforderungen Damit die Anforderungen als testbar gelten, sollten die Anforderungen idealerweise alle der folgenden Merkmale aufweisen: Überblick über anforderungsbasierte Tests 8

1. Deterministisch: Bei einem anfänglichen Systemzustand und einer Reihe von Eingaben müssen Sie in der Lage sein, die Ausgaben genau vorherzusagen.

2. Eindeutigkeit: Alle Projektbeteiligten müssen aus den Anforderungen die gleiche Bedeutung ziehen; andernfalls sind sie mehrdeutig.

3. Richtig: Die Zusammenhänge zwischen Ursache und Wirkung werden richtig beschrieben.

4. Vollständig: Alle Anforderungen sind enthalten. Es gibt keine Auslassungen.

5. Nicht-redundant: So wie das Datenmodell einen nicht-redundanten Datensatz bereitstellt, sollten die Anforderungen einen nicht-redundanten Satz von Funktionen und Ereignissen bereitstellen.

6. Geeignet für die Änderungskontrolle: Anforderungen sollten wie alle anderen Ergebnisse eines Projekts der Änderungskontrolle unterliegen.

7. Nachvollziehbar: Anforderungen müssen untereinander, zu den Zielen, zum Design, zu den Testfällen und zum Code nachvollziehbar sein.

8. Für alle Projektteammitglieder lesbar: Die Projektbeteiligten, einschließlich der Benutzer, Entwickler und Tester, müssen alle zum gleichen Verständnis der Anforderungen gelangen.

9. In einem einheitlichen Stil verfasst: Anforderungen sollten in einem einheitlichen Stil verfasst sein, um sie leichter verständlich zu machen.

10. Verarbeitungsregeln spiegeln einheitliche Standards wider: Verarbeitungsregeln sollten einheitlich formuliert sein, um sie leichter verständlich zu machen.

11. Explizit: Anforderungen dürfen niemals impliziert werden.

12. Logisch konsistent: Es sollte keine logischen Fehler in den Beziehungen zwischen Ursachen und Wirkungen geben.

13. Geeignet für die Wiederverwendbarkeit: Gute Anforderungen können für zukünftige Projekte wiederverwendet werden.

14. Prägnant: Anforderungen sollten kurz und mit möglichst wenigen Worten formuliert werden.

15. Anmerkung zur Kritikalität: Nicht alle Anforderungen sind kritisch. Bei jeder Anforderung sollte angegeben werden, wie stark sich ein Fehler auf die Produktion auswirken würde. Auf diese Weise kann die Priorität jeder Anforderung bestimmt und der richtige Schwerpunkt auf die Entwicklung und das Testen jeder Anforderung gelegt werden. In den meisten Systemen benötigen wir keinen Null-Fehler. Wir brauchen ausreichend gute Tests.

16. Machbar: Wenn das Softwaredesign die Anforderungen nicht erfüllen kann, sind die Anforderungen nicht realisierbar.

Auszug aus der Übersicht über den anforderungsbasierten Testprozess

Das Akronym „INVEST“ kann Sie daran erinnern, dass gute Geschichten:

  • ICH - Unabhängig
  • N - Verhandelbar
  • V - Wertvoll
  • E – Schätzenswert
  • S - Klein
  • T – Testbar

Es gibt keinen einheitlichen Standard dafür, was eine qualitativ hochwertige Softwareanforderung ausmacht. Darüber hinaus kann eine gute Voraussetzung dafür angesehen werden Anwendungssoftware wird wahrscheinlich von einem Gut abweichen Systemsoftware Erfordernis.

Anforderungen an Qualitätsmerkmale

Automatisierte Qualitätssicherung von Anforderungen

ScopeMaster testet Anforderungen. Wie SonarQube Bei Anforderungen untersucht ScopeMaster jede Anforderung (oder User Story), um die funktionale Absicht zu ermitteln, und bewertet jede Anforderung anhand der oben aufgeführten Qualitätskriterien. Es können nicht alle Fehler erkannt werden, aber etwa 50% davon. Nachdem es die Anforderungen einzeln analysiert hat, untersucht es die Anforderungen im Kontext des Anforderungspakets. Dies liefert Einblicke, die mit Tools wie … einfach nicht möglich sind Jira Und Azure DevOps, ScopeMaster interpretiert und analysiert Anforderungen, es speichert sie nicht nur. So haben Sie Zeit, sich mit anderen wichtigen Aspekten Ihrer Anforderungen zu befassen. Dadurch wird die Verbesserung der Anforderungsqualität schneller und einfacher. Es nimmt Ihnen die harte Arbeit ab.

Anforderungen Qualität auf einen Blick
Testet die Ergebnisse der Login-User-Story

In der angezeigten Tabelle bedeuten die Spalten:

  1. Der Qualitätsfaktor Prüfung der individuellen Anforderungen (unter Berücksichtigung des Kontexts) anhand von mehr als 350 Wörtern, Phrasen und Sprachmustern zur Verdeutlichung.
  2. Klar und funktional Enthält eindeutige Aussage(n) zur Funktionalität (Beschreibung der Datenbewegungen).
  3. Benutzerorientiert Als Subjekt innerhalb der Anforderung wird ein Benutzer identifiziert, der eine Aktion mit Daten durchführt.
  4. Prägnant das Verhältnis von Wörtern zur funktionalen Größe, innerhalb vernünftiger Grenzen
  5. Messbar und prüfbar Wenn eine funktionale Absicht erkannt wird, ist sie messbar und überprüfbar. Auch hier stellen wir fest, ob eine klare funktionale Absicht vorlag.
  6. Komplett (im Set) bedeutet, dass Objekttypen, die in dieser Anforderung identifiziert werden, über ergänzende CRUD-Aktionen verfügen, um einen vollständigen Satz von Wartungsaktivitäten über den Satz von Anforderungen hinweg sicherzustellen.
  7. Vollständig (vergrabene Funktionalität) In den Notizen/Annahmekriterien erkannte Funktionalität, die in der Anforderung selbst hätte enthalten sein sollen.
  8. Vorteile Wurde versucht, den Nutzen oder Wert dieser Anforderung zu beschreiben?

Qualitätsbewertung

ScopeMaster ist sich bewusst, dass Anforderungen nicht für sich allein existieren. Es versteht den Kontext einer Reihe von Anforderungen Daher werden Qualitätswerte auf zwei Ebenen ermittelt:

  1. Qualitätsfaktor für jeden individuelle Anforderung
  2. Qualitätsfaktor für a Reihe von Anforderungen

ScopeMaster führt für jede Anforderung Hunderte von statischen und möglicherweise Tausende von dynamischen Tests durch und gibt dem Autor sofortiges Feedback. Also du Lernen Sie, bessere Anforderungen zu schreiben wenn du gehst.

Anforderungsqualitätsbewertung