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.

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.

Empfehlung

Zuerst sollten Sie die Dokumentationsrichtlinien des Projekts bzw. des Unternehmens identifizieren. Danach sollten Sie die anzuwendenden Kategorien auswählen. Nachfolgend müssen die gültigen Qualitätsanforderungen für das Projekt festgelegt und die Qualitätskriterien an die Dokumentation definiert werden.

Werkzeuge

Als Werkzeuge ist eine Analyse und eine Recherche (informell) zu empfehlen. Hilfreich ist sowohl die Verwendung einer Checkliste, die die wesentlichen Qualitatskriterien enthält, als auch die Verwendung von allgemeingültigen Hilfsmitteln (INVEST-Kriterien, ISO/IEC/IEEE 29148-2011 Standard). Des Weiteren sind Textverarbeitungprogramme sinnvoll. Evtl. ist eine Anpassung des einzusetzenden Tools notwendig, falls dieses den Dokumentationsvorgaben nicht gerecht wird. Ein Attributierungsschema darf nicht vergessen werden.

Ergebnis

Ziel ist es, dass die Dokumentationsrichtlinien bekannt sind, die Qualitätskriterien definiert sind und eine projektspezifische Vorlage einer Anforderungskategorisierung vorhanden ist.

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.

Sie brauchen Hilfe? Lassen Sie sich von uns unverbindlich beraten.