Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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 Interatkionsmatrix 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öglist einfache Sprache verwendet und wurden 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 zugehö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 evtl. "zu viel". 
    • 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 Anforderungs-Management 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)  --nach Bedarf--
  • 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 Reviewer 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 vom Fachbereich 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.
      • Anforderung – Quelle
      • Anforderung – Begründung
      • Anforderung – Anforderung (Abhängigkeiten)
      • Anforderung – Subsystem (Architektur)
      • Anforderung – Schnittstelle
    • 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