Checkliste Requirements Engineering

Nachdem ich das Buch “Requirements Engineering – a good practice guide” etwas näher vorgestellt habe, möchte ich gerne aus den beschriebenen Guidelines eine Checkliste für das Requirements Engineering ableiten. Es folgt eine Tabelle mit drei Spalten:

Spalte 1 -> Kapitel des o.g. Buches / Guideline-Nr.
Spalte 2 -> Name der Guideline (engl. Original)
Spalte 3 -> (sinnvolle) Ableitung für das Requirements-Engineering im Maschinenbau (Checkliste)

3.1 Define a standard document structure Ist die Struktur des Anforderungsdokuments standardisiert? *
3.2 Explain how to use the document Wird erläutert, wie das Anforderungsdokument zu benutzen ist? (einleitendes Kapitel)
3.3 Include a summary of the requirements Wurde eine Zusammenfassung des Projekts im Anforderungsdokument hinterlegt?
3.4 Make a business case for the system Liegt dem Projekt ein Business Case zu Grunde?
3.5 Define specialized terms Ist ein Glossar zur Unterstützung des einheitlichen Verständnisses von Fachbegriffen verfügbar?
3.6 Lay out the document for readability Ist das Anforderungsdokument einfach lesbar? (Layout) *
3.7 Help readers find information Ist ein Index / Inhaltsverzeichnis im Anforderungsdokument vorhanden?
3.8 Make the document easy to change
4.1 Assess system feasibility Liegt eine Machbarkeitsstudie für das Projekt vor?
4.2 Be sensitive to organizational and political considerations Wurden politische / interne Interessen betrachtet?
4.3 Identify and consult system stakeholders Wurden alle relevanten Stakeholder einbezogen?
4.4 Record requirements sources Wurde die Quelle für jede Anforderung aufgenommen?
4.5 Define the system’s operating environment Wurde die Betriebsumgebung genau definiert? Welche Bedingungen sind am Standort vorhanden? (Medien, Räume, Transportmittel, Schwingungen, Temperatur, Luftfeuchte…)
4.6 Use the business concerns to drive requirements elicitation
4.7 Look for domain constraints Wurden auf Einschränkungen im Gesamtsystemkontext geprüft? (Lärmschutzanforderungen, Strahlenschutzanforderungen, zu erfüllende Normen?)
4.8 Record requirements rationale Wurde eine Begründung für die Anforderung mitgeliefert / dokumentiert?
4.9 Collect requirements from multiple viewpoints Wurden die Anforderungen aus mehreren Perspektiven überprüft / formuliert?
4.10 Prototype poorly understood requirements Wurde versucht unklare Anforderungen anhand eines Prototyps deutlich zu erläutern?
4.11 Use scenarios to elicit requirements Können Szenarios (Anwendungsfälle / Use Case) genutzt werden um weitere (verborgene / bisher nicht bedachte) Anforderungen zu extrahieren?
4.12 Define operational processes
4.13 Reuse requirements Ist die Anforderung identisch / ähnlich zu einer Anforderungen aus einem anderen Projekt? Könnte die Anforderung aus einem anderen Projekt übernommen / modifiziert werden?
5.1 Define system boundaries Wurden die Systemgrenzen definiert und dokumentiert?
5.2 Use checklists for requirements analysis Wird jede Anforderung anhand einer Checkliste geprüft? (Mögliche Fragen:

– 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? (siehe 3.4)

– 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?

5.3 Provide software to support negotiations Haben alle Stakeholder Zugriff auf die Anforderungen? (Einheitliche Diskussionsgrundlage für Verhandlungen)
5.4 Plan for conflicts and conflict resolution Werden bereits während der Anforderungsaufnahme evtl. Konflikte / Überschneidungen identifiziert und Lösungen angedacht? (“requirements negitiation meetings”)
5.5 Prioritise requirements Wurden alle Anforderungen priorisiert?
5.6 Classify requirements using a multi-dimensional approach Wurden die Anforderungen kategorisiert (z.B. System, User Interface, Datenbank, Sicherheit)
5.7 Use interaction matrices to find conflicts and overlaps Wurde eine Interatkionsmatrix benutzt um Anforderungs-Konflikte und Überlappungen zu erkennen?
5.8 Assess requirements risks Wurde jede Anforderung hinsichtlich Risiken überprüft? Wenn ja, wurde Eintrittswahrscheinlichkeit, Auswirkung, Gegenmaßnahme dokumentiert?
6.1 Define standard templates for describing requirements Gibt es standardisierte Templates wie Anforderungen zu formulieren sind? (bestimmte Wortgruppen, Schlüsselworte…)
6.2 Use language simply, consistently and concisely Wurde möglist einfache Sprache verwendet und wurden Begriffe konsistent benutzt?
6.3 Use diagrams appropriately Wurden Diagramme angemessen benutzt? (z. B. um Abläufe, Datenströhme oder schwer in Text zu fassende Anforderungen zu beschreiben)
6.4 Supplement natural language with other descriptions of requirements
6.5 Specify requirements quantitatively Wurden alle quantitativen Anforderungen genau spezifiziert (z. B. Zahlenwerte, Wertebereiche, Toleranzen).
7.1 Develop complementary system models Wurde an geeigneten Stellen ein Modell / Showcase hinterlegt? (z. B. Screenshot einer Benutzeroberfläche, Mockups)
7.2 Model the System’s Environment Wurde die Systemumgebung modelliert? (Schnittstellen, evtl. beteiligte Geschäftsprozesse)
7.3 Model the System Architecture Wurde die Gesamtsystemarchitektur modelliert? (Vogelperspektive, Untersysteme und deren Interaktionen)
7.4 Use structured methods for system modeling Wurde bei System-Modellierungen eine strukturierte Methode verwendet (z.B. UML, ARIS…)
7.5 Use a data dictionary Wurde ein Komponenten-Glossar angelegt? (einheitliche Sprache in großen Projekten mit vielen Mitarbeitern)
7.6 Document the links between stakeholder requirements and system models Wurden Verbindungen zwischen natürlichsprachigen Anforderungen und zugehörigen Systemmodellen hergestellt?
8.1 Check that the requirements document meets your standards Wurden Standards zum Anforderungs-Management festgelegt? Wenn ja, wurden die Standards eingehalten?
8.2 Organize formal requirements inspections Werden die aufgenommenen Anforderungen (regelmäßig) durch Inspektionen von (internem) Fachpersonal überprüft (und ggf. auf Probleme und Inkonsistenzen untersucht)
8.3 Use multi-disciplinary teams to review requirements Werden die Anforderungen auch von Mitarbeitern aus anderen Fachbereichen überprüft? (z. B. aus Sicht des Service, der Inbetriebnahme oder der Fertigung)
8.4 Define validation checklists 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 nachverfolgbar? (einheitliche, eindeutige Bezeichnung, Quelle, betreffende Stakeholder, Änderungen) Enthalten die Anforderungen Verweise zu zusammenhängenden Anforderungen?

(Siehe auch 5.2 -> Checkliste für einzelne Anforderungen)

8.5 Use prototyping to animate requirements (siehe Guideline 4.10)
8.6 Write a draft user manual
8.7 Propose requirements test classes (siehe Guideline 5.2)
8.8 Paraphrase system models
9.1 Uniquely identify each requirement Ist jede Anforderung eindeutig identifizierbar?
9.2 Define policies for requirements management Wurde eine einheitliche Strategie zum Requirements Management definiert? Diese sollte mindestens enthalten:

– Standards für Anforderungsdokumente (siehe 3.1 und 6.1)

– Plan wie Veränderungs-Management (Change Management) zu erfolgen hat

– Plan zum Review von Anforderungen und deren Validierung

– Verbindungen zwischen Anforderungsmanagement und anderen Fachabteilungen

– Plan wie “Traceability” umgesetzt wird (Welche Informationen über Abhängigkeiten von Anforderungen soll erhalten bleiben und wie?)

– ggf. Reports

9.3 Define traceability policies Welche Traceability-Informationen sollen gesammelt werden? z. B.

– Anforderung – Quelle

– Anforderung – Begründung

– Anforderung – Anforderung (Abhängigkeiten)

– Anforderung – Subsystem (Architektur)

– Anforderung – Schnittstelle

9.4 Maintain a traceability manual siehe 9.3
9.5 Use a database to manage requirements
9.6 Define change management policies
9.7 Identify global system requirements Wurden alle globalen Systemanforderungen erhoben? (Übergreifende Anforderungen, z. B. keine scharfen Kanten an der Maschine)
9.8 Identify volatile requirements
9.9 Record rejected requirements Wurden alle verworfenen Anforderungen dokumentiert? (Auch der Grund warum die Anforderung verworfen wurde?)
10.1 Create safety requirements checklist Wurde eine Checkliste mit Sicherheitsanforderungen erstellt? Fragen könnten sein:

– Wie hat ein korrekter Maschinen-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?

10.2 Involve external reviewers in the validation process - Könnten externe Reviewer in den Validierungsprozess integriert werden?
10.3 Identify and analyze hazards
10.4 Derive safety requirements from hazard analysis
10.5 Cross-check operational and functional requirements against safety requirements Wurden alle Anforderungen anhand des Sicherheitkonzepts überprüft?
10.6 Specify systems using formal specifications
10.7 Collect incident experience
10.8 Learn from incident experience
10.9 Establish an organizational safety culture

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

Ein Gedanke zu „Checkliste Requirements Engineering

  1. Pingback: Projektmanagement im Maschinenbau » Checkliste Projektstart

Hinterlasse eine Antwort