Qualitätskriterien, Kategorien und Richtlinien festlegen

Bevor die Anforderungen dokumentiert werden, müssen Qualitätskriterien an die Dokumentation festgelegt werden. Die Qualitätskriterien definieren, in welcher Form die Dokumentation zu erfolgen hat. Qualitätskriterien können die Art der Dokumentation definieren (z.B. ob natürlichsprachig mit einer Satzschablone oder stark modellbasiert dokumentiert wird).

Werkzeugkoffer mit diversen Tools der Anforderungsfabrik

In einigen Projekten bestehen meist umfangreichere Vorgaben an die Qualität von Dokumenten. Hierbei sind häufig Templates für Lasten- und Pflichtenhefte, Satzschablonen, usw. definiert. In agilen Projekten werden die Qualitätsanforderungen in der Definition of Ready (DoR) festgehalten. Die richtige Verwendung von Kategorien hilft beim Umgang mit Anforderungsspezifikationen. Kategorien gruppieren thematisch zusammenhängende Anforderungen und können dazu verwendet werden, bestimmte (Stakeholder-) Sichten auf Anforderungen zu erzeugen und zielgerichteter mit Anforderungsspezifikationen zu arbeiten.

Empfehlung

Zuerst sollten Sie die Dokumentationsrichtlinien des Projekts bzw. des Unternehmens identifiziert werden (z.B. welche Vorlagen oder Tools sollen wie verwendet werden?). Danach sollten Sie die anzuwendenden Kategorien auswählen (z.B. Funktionale und Nicht-Funktionale Anforderungen). Nachfolgend müssen die gültigen Qualitätsanforderungen für das Projekt festgelegt und die Qualitätskriterien an die Dokumentation definiert werden. Im agilen Kontext werden die Qualitätskriterien oft als „Definition of Ready“ (DoR) bezeichnet.

Werkzeuge

Analyse und eine Recherche (informell)

Checkliste: Hilfreich da Sie die wesentlichen Qualitatskriterien enthalten sollte.

Allgemeingültige Hilfsmittel: Die Verwendung von allgemeingültigen Hilfsmitteln (INVEST-Kriterien, ISO/IEC/IEEE 29148-2011 Standard) ist ebenso hilfreich, wie eine Checkliste.

Textverarbeitungprogramme: Ebenfalls sinnvoll, wenn eine Anpassung des einzusetzenden Tools notwendig ist, falls dieses den Dokumentationsvorgaben nicht gerecht wird.

Ergebnis

Ziel ist es, dass die Dokumentationsrichtlinien bekannt sind, die Qualitätskriterien definiert sind und eine projektspezifische Vorlage einer Anforderungskategorisierung vorhanden ist. Ergebnis-Artefakte können ein „Attributierungsschema“ (z.B. „Definition of Ready“ oder „Vorlagen für Anforderungen“) sein.

Hinweis

Die Qualitätskriterien an die Dokumentation sowie die Dokumentationsrichtlinien werden in agilen Projekten im sogenannten Definition of Ready (DoR) festgehalten. Die DoR beschreibt, wann eine Anforderung (User Story) ausreichend dokumentiert ist.

Epics gruppieren in agilen Projekten Anforderungen (User Stories) zu einem Thema. Sie können eingesetzt werden, um Sichten zu erzeugen und Anforderungskategorien abzubilden. In klassischen Projekten kann der IEEE-Standard sowie die Anwendung von Satzschablonen helfen, um hochwertige Anforderungen zu beschreiben.

Innere Regeln

  1. Haben Sie eine Einzelanforderung in einem Satz formuliert?
    Beispiel: Der Anwender muss den Buchungsprozess innerhalb von fünf Klicks abschließen können.
    Nicht: Der Anwender muss den Buchungsprozess innerhalb von fünf Klicks abschließen und ausdrucken können.

  2. Haben Sie ihre Anforderung im Aktiv formuliert?
    Beispiel: Das System muss dem Benutzer eine Eingabemöglichkeit zur Verfügung stellen.
    Nicht: Eine Eingabemöglichkeit muss durch das System zur Verfügung gestellt werden.

  3. Haben Sie Ihre Anforderung in einem Hauptsatz formuliert?
    Nebensätze nur zur Vervollständigung (mit wem, unter welchen Bedingungen etc.)
    Beispiel: Das System zeigt eine rote Ampel (wenn der Buchungsprozess einen Fehler verursacht)
    Nicht: Das System signalisiert mithilfe einer roten Ampel, die auf dem Bildschirm ausgegeben und angezeigt werden soll, dass das System einen Fehler verursacht hat.

  4. Haben Sie für Verben, die Prozesse beschreiben, eine feste Bedeutung festgelegt?
    Beispiel: Speichern = Persistieren der Daten in der Datenbank

  5. Haben Sie nur Begriffe verwendet, die im Glossar definiert sind?
    Beispiel: VVL = Vertragsverlängerung = Prozess zur Verlängerung der Vertragslaufzeit

  6. Haben Sie unspezifizierte Nomen hinterfragt und durch spezifische ersetzt oder ergänzt?
    Beispiel: „Die Daten“ ersetzt durch „Die Daten des aktuell im System eingeloggten Benutzers“ oder durch „Die Benutzerdaten“, „Die Buchungsdaten“

  7. Haben Sie Normalisierungen hinterfragt und aufgedeckt?
    Beispiel: Es sollen Datenverluste gemeldet werden.
    Nicht: Wo gehen die Daten verloren? Welche Daten gehen verloren?

Äußere Regeln

  1. Hat Ihre Anforderung einen eindeutigen Identifizierer/Identifier?
    Beispiel: ID 4711

  2. Hat Ihre Anforderung einen eindeutigen Besitzer/Anforderer/Owner?
    Beispiel: Herr Müller aus dem Fachbreich „Marketing“ hat die Anforderung mit der ID 4711 gestellt.

  3. Hat Ihre Anforderung ein Versionsdatum und/oder eine Versionsnummer?
    Beispiel: Version vom 11.11.2010 oder Version 1.0

  4. Hat Ihre Anforderung eine eindeutige Herkunft?
    Beispiel: Fachseiten Workshop vom 11.11.2010

  5. Gibt es eine übergeordnete Anforderung und haben Sie diese in der Anforderung referenziert?
    Beispiel: Anforderung ID 1234 resultiert aus Anforderung ID 4711

  6. Hat Ihre Anforderung einen Status?
    Beispiel: „in Bearbeitung“, „abgestimmt“, „Nicht relevant“, „gestrichen“

  7. Haben Sie ihre Anforderung auf konkurrierende oder verhindernde Anforderungen / Rahmenbedingungen geprüft?
    Beispiel: Fachbereich „Marketing“ fordert mit der Anforderung ID 0815 eine zusätzliche Schaltfläche mit Logo an. Die „GUI-Richtlinie“ erlaubt jedoch keine weitere Schaltfläche.

Sie möchten mehr über uns erfahren?

WordPress Cookie-Hinweis von Real Cookie Banner