Inhalt : Checkliste Anforderungsmanagement

Anforderungsdokument

Ist die Struktur des Anforderungsdokuments standardisiert? *
Wird erläutert, wie das Anforderungsdokument zu benutzen ist? (einleitendes Kapitel)
Wurde eine Zusammenfassung des Projekts im Anforderungsdokument hinterlegt?
Ist ein Glossar zur Unterstützung des einheitlichen Verständnisses von Fachbegriffen verfügbar?
Wurde ein Komponenten-Glossar angelegt? (einheitliche Sprache in großen Projekten mit vielen Mitarbeitern)
Haben alle Stakeholder Zugriff auf die Anforderungen? (Einheitliche Diskussionsgrundlage für Verhandlungen)
Gibt es standardisierte Templates wie Anforderungen zu formulieren sind? (bestimmte Wortgruppen, Schlüsselworte…)
Ist das Anforderungsdokument einfach lesbar? (Layout) *
Ist ein Index / Inhaltsverzeichnis im Anforderungsdokument vorhanden?

Übergreifende Anforderungen (Domain / System / Gesamtprojekt):

Liegt dem Projekt ein Business Case zu Grunde?
Liegt eine Machbarkeitsstudie für das Projekt vor?
Wurden politische / interne Interessen betrachtet?
Wurden alle relevanten Stakeholder einbezogen?
Wurden die Systemgrenzen definiert und dokumentiert?
Wurde die Systemumgebung modelliert? (Schnittstellen, evtl. beteiligte Geschäftsprozesse)
Wurde die Gesamtsystemarchitektur modelliert? (Vogelperspektive, Untersysteme und deren Interaktionen)
- Wurde bei System-Modellierungen eine strukturierte Methode verwendet (z.B. UML, ARIS…)
Wurden alle globalen Systemanforderungen erhoben? (Übergreifende Anforderungen, z. B. keine scharfen Kanten an einer Maschine, 20 MB Hauptspeicherauslastung)
Wurde die Betriebsumgebung genau definiert? Welche Bedingungen sind am Standort vorhanden? (Medien, Räume, Transportmittel, Schwingungen, Temperatur, Luftfeuchte…)
Wurden auf Einschränkungen im Gesamtsystemkontext geprüft? (Lärmschutzanforderungen, Strahlenschutzanforderungen, zu erfüllende Normen?)
Wurde eine Checkliste mit Sicherheitsanforderungen erstellt? Fragen könnten sein:
- Wie hat ein korrekter Start zu erfolgen?
- Welche Initialparameter sollen hinterlegt sein?
- Wie wird auf bestimmte Benutzereingaben reagiert?
- Was passiert wenn ein (Teil-)System offline geht?
- Was passiert wenn unerwartete Eingaben erfolgen?
- Wie erfolgt ein Validitätscheck von Benutzereingaben?
- Was passiert bei Time-Outs / Buffer-Overruns?
- Welche Alarm-Stati / Systeme gibt es?
Werden bereits während der Anforderungsaufnahme evtl. Konflikte / Überschneidungen identifiziert und Lösungen angedacht? (“requirements negitiation meetings”)

Einzelanforderungen

Ist jede Anforderung eindeutig identifizierbar? (ID)
Wurde die Quelle für jede Anforderung aufgenommen?
Ist diese Quelle berechtigt Anforderungen an das Projekt zu stellen?
Wurde eine Begründung für die Anforderung mitgeliefert / dokumentiert?
Wurden die Anforderungen aus mehreren Perspektiven überprüft / formuliert?
Ist die Anforderung identisch / ähnlich zu einer Anforderungen aus einem anderen Projekt? Könnte die Anforderung aus einem anderen Projekt übernommen / modifiziert werden?
Wird jede Anforderung anhand einer Checkliste geprüft? (Mögliche Fragen:Wurden die Anforderungen kategorisiert (z.B. System, User Interface, Datenbank, Sicherheit)
- Sind in der Anforderung bereits technische Informationen zur Umsetzung enthalten? -> lösungsneutral formulieren
- Handelt es sich evtl. um eine kombinierte Anforderung? (Besteht die Möglichkeit der Splittung in zwei oder mehr einzelne Anforderungen)
- Ist die Anforderung unbedingt erforderlich oder handelt es sich um eine „Nice-To-Have“ oder „Gold plating“ Anf.?
- Muss zur Umsetzung der Anforderung eine Eigenentwicklung durchgeführt werden oder kann auf Standard-Soft/Hardware zurückgegriffen werden? (z. B. eigenen Mikrocontroller entwickeln oder kommerzielles Produkt einsetzen?)
- Geht die Anforderung konform mit den Zielen im Business Case des Projekts?
- Ist die Anforderung eindeutig oder kann sie von verschiedenen Lesern verschieden interpretiert werden? Was sind mögliche Interpretationen?
- Ist die Anforderung realistisch mit der zu verwendenden Technologie erfüllbar?
- Kann die erfolgreiche Umsetzung der Anforderung mit einem Testfall überprüft werden?
- Gibt es Abnahmekriterien?
Wurden alle quantitativen Anforderungen genau spezifiziert (z. B. Zahlenwerte, Wertebereiche, Toleranzen).
Wurde an geeigneten Stellen ein Modell / Showcase hinterlegt? (z. B. Screenshot einer Benutzeroberfläche, Mockups)

Anforderungs-Validierung

Können Szenarios (Anwendungsfälle/Use Case) genutzt werden um weitere (verborgene/bisher nicht bedachte) Anforderungen zu extrahieren?
Wurden alle Anforderungen priorisiert?
Wurde eine Interaktionsmatrix benutzt um Anforderungs-Konflikte und Überlappungen zu erkennen?
Wurde jede Anforderung hinsichtlich Risiken überprüft? Wenn ja, wurde Eintrittswahrscheinlichkeit, Auswirkung, Gegenmaßnahme dokumentiert?
Wurde möglichst einfache Sprache verwendet und Begriffe konsistent benutzt?
Wurden Diagramme angemessen benutzt? (Z. B. um Abläufe, Datenströhme oder schwer in Text zu fassende Anforderungen zu beschreiben.)
Wurden Verbindungen zwischen natürlichsprachigen Anforderungen und dazugehörigen Systemmodellen hergestellt?
Wurden Verbindungen zwischen Anforderungen und Lösungskomponenten bzw. Liefergegenständen hergestellt?
- So können Lücken erkannt werden wo es Anforderungen gibt die nicht durch eine Lieferung bedient werden.
- Liefergegenstände, die nicht auf Anforderungen verweisen, sind wahrscheinlich überflüssig.
- Die Abbildung hilft "traceability" herzustellen und bei Änderungen (Changes) anhängige Liefergegenstände und abhängige Anforderungen (evtl. von einer anderen Quelle) zu finden.
Wurden Standards zum Anforderungsmanagement festgelegt? Wenn ja, wurden die Standards eingehalten?
Werden die aufgenommenen Anforderungen (regelmäßig) durch Inspektionen von (internem) Fachpersonal überprüft (und ggf. auf Probleme und Inkonsistenzen untersucht)?
Werden die Anforderungen auch von Mitarbeitern aus anderen Fachbereichen überprüft? (Z. B. aus Sicht des Service, der Inbetriebnahme oder der Fertigung.)
Werden die gesammelten Anforderungen einer Validierung basierend auf einer Checkliste unterzogen? Fragen könnten z. B. sein:
- Sind die Anforderungen komplett? Gibt es aus einer anderen Sichtweise evtl. zusätzliche Anforderungen?
- Sind die Anforderungen konsistent oder gibt es evtl. mehrere Anforderungen, die einen Sachverhalt unterschiedlich beschreiben?
- Sind die Anforderungen verständlich, einheitlich und eindeutig formuliert?
- Sind die Anforderungen nach verfolgbar? (einheitliche, eindeutige Bezeichnung, Quelle, betreffende Stakeholder, Änderungen)
- Enthalten die Anforderungen Verweise zu zusammenhängenden Anforderungen?
- Sind die Anforderungen durch den Projekt-Scope abgedeckt?
Wurden alle relevanten Anforderungen anhand des Sicherheitkonzepts überprüft?
Könnten und sollen externe Reviere in den Validierungsprozess integriert werden?

Unklare Anforderungen / Verworfene Anforderungen

Wurde versucht unklare Anforderungen anhand eines Prototyps deutlich zu erläutern?
Wurden alle verworfenen Anforderungen dokumentiert? (Auch der Grund warum die Anforderung verworfen wurde?)

Requirements Management

Wurde eine einheitliche Strategie zum Requirements Management definiert? Diese sollte mindestens enthalten:
- Standards für Anforderungsdokumente (siehe oben)
- Festlegen des Vorgehens bzw. Prozesses wie mit Anforderungen umgegangen wird bevor es eine Baseline gibt (Initial-Anforderungen)
  - Sind die Anforderungen mit Geld/ Budget hinterlegt vs. Wunschliste
  - Wie erfolgt der Budget-Shift / Verrechnung zum Projekt
  - Festlegen wer die umgesetzte Anforderung abnimmt
- Plan wie Veränderungs-Management (Change Management) zu erfolgen hat - wenn ein Requirement Baseline gesetzt wurde gegen die eine Veränderung erfolgen kann
- Plan zum Review von Anforderungen und deren Validierung
- ggf. Reports (wöchentlich, monatlich)
- Verbindungen zwischen Anforderungsmanagement und anderen Fachabteilungen
  - Holt das Projekt Anforderungen "aktiv" ein oder reagiert auf gestellte Anforderungen?
  - Wer holt die Anforderungen bei welcher Fachabteilung ein?
- Plan wie “Traceability” umgesetzt wird (Welche Informationen über Abhängigkeiten von Anforderungen soll erhalten bleiben und wie?)
- Welche Traceability-Informationen sollen gesammelt werden? z. B.
- Setzen einer Requirements-Baseline
  - Definition wer die Baseline definiert
  - Wer nimmt die Anforderungen ab (via Unterschrift)
    - Anforderer (Alle)
    - Auftragnehmer bzw. Projektteam als die Lieferanten
    - Sponsor oder Steuerkreis
  - Ablegen aller Anforderungsdokumente in einer nicht veränderbaren Form (z.B. PDF) incl. Versionsnummer für späterer Verweise
  - Festlegung einer Reihenfolge bzw. Gültigkeits- oder Rangfolge von Dokumenten um widersprechende Teile vertraglich zu fixieren
  - Anpassen abhängiger Pläne nach setzen der Baseline (Time, Cost, Quality, Ressourcen, Risk) und ebenfalls freigeben und unterschreiben lassen, auch "einfrieren" und Versionieren

*) Anmerkung: erübrigt sich bei Nutzung einer softwarebasierten RE-Lösung

Quelle: http://www.projektmanagement-im-maschinenbau.de/

Basierend auf: Ian Sommerville und Pete Sawyer "Requirements Engineering - a good practice guide" ISBN: 978-0471974444