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

Requirements Engineering – a good practice guide


Kurzbewertung:
ISBN: 978-0471974444

Im Zuge meiner Recherchen bin ich heute auf einen Schatz der Requirements Engineering Literatur gestoßen. Ian Sommerville und Pete Sawyer trugen 1997 auf knapp 390 Seiten in einem “good practice guide” die ihrer Meinung nach wichtigsten Praktiken rund um das Thema Anforderungen zusammen. Ich meine, der Großteil des Buches ist aktueller denn je!

Inhalt

Nach Kapitel 1 (Einführung) gehen die Autoren direkt auf die praktische Prozessverbesserung ein. Dazu wird gezeigt wie der Reifegrad der Prozesses gemessen werden kann und welche die Top 10 Guidelines sind. Von Kapitel 3 bis 10 werden die insgesamt 66 Guidelines untergliedert in:

(3) Das Anforderungsdokument
(4) Anforderungsaufnahme
(5) Anforderungsanalyse und -verhandlung
(6) Anforderungen beschreiben
(7) System Modellierung
(8) Anforderungsüberprüfung
(9) Anforderungs-Management
(10) Anforderungs-Management für kritische Systeme
näher erläutert.
Kapitel 11 gibt einen Überblick über Modellierung mit strukturierten Methoden. Die Vor- und Nachteile einer formalen Spezifikation werden in Kapitel 12 näher betrachtet. Abschließend wird in Kapitel 13 auf verschiedene Sichtweisen (Viewpoints) von Anforderungen eingegangen.

Stil


Das Buch ist in allen Belangen extrem praxisnah. Sehr viele Stichpunkte, übersichtliche Struktur und viele Zusammenfassungen machen es geradezu spielerisch möglich, sich einen bestimmten Aspekt des Buches heraus zu greifen und innerhalb weniger Minuten zu durchschauen. Die englische Sprache ist dabei kein Hindernis – alles ist recht einfach formuliert. Eine deutsche Übersetzung habe ich nicht gefunden. Die einzelnen Guidelines sind immer gleich aufgebaut: erst kommt eine Zusammenfassung in Tabellenform, in der Name, Hauptnutzen, eine Einschätzung des Aufwands zur Einführung und der zu erwartenden Kosten sowie der Guideline-Typ (Basic, Intermediate, Advanced) aufgeführt sind. Dann wird etwas detaillierter erläutert, welche Vorteile die Guideline mit sich bringt, wie sie implementiert werden kann und was bei der Umsetzung für Aufwände und Probleme zu erwarten sind.

Fazit


Auch wenn das Buch für Software-Entwickler geschrieben wurde und die Erstauflage bereits 15 Jahre in der Vergangenheit liegt, kann dieses Buch ohne Einschränkung auch an jeden Maschinenbauer empfohlen werden, der sich mit dem Management von Anforderungen auseinander setzen muss. Lediglich die beschriebenen Modelle und strukturierten/formalen Methoden sind etwas in die Jahre gekommen. Wer ein günstiges Second-Hand Exemplar erwerben kann, wird den Kauf keinesfalls bereuen! Die knapp 80 EUR Neupreis sind allerdings doch etwas happig.

Checklisten zur Erstellung eines Projektmanagement-Handbuchs

Ich bin ein sehr großer Check-Listen Fan! Neulich schwebte mir die Idee vor, warum nicht einmal eine Check-Liste entwickeln, mit deren Hilfe sich ein Projektmanagement-Handbuch gestalten lässt? Ein solches Handbuch sollte quasi in jedem Unternehmen verfügbar sein, das im Projektgeschäft tätig ist. Es ermöglicht neuen Kollegen das nötige Wissen zu vermitteln, wie ein Projekt abgewickelt wird und dem Unternehmen an sich, die Qualität des PMs messbar zu machen. Natürlich ist jedes Unternehmen unterschiedlich und daher wird es nie den heiligen Gral der Projektmanagement-Handbücher geben.

Die Idee ist die, einen großen Haufen intelligenter Fragen zum Thema Projektmanagement zu formulieren. Je vollständiger die Liste, desto unwahrscheinlicher ist es, dass ein essentieller Teil vergessen wurde. Punkte die für das Unternehmen weniger wichtig erscheinen oder in der Implementierung zu aufwändig sind, können einfach gelöscht werden. So ergibt sich ein individuelles Set von Fragen, deren Beantwortung das PM-Handbuch ergeben.

Ein kleines Beispiel:

Projektphase -> Zieledefinition

– Wie sind zu Beginn eines Projekts die Projektziele systematisch zu erfassen?
– Wie sind die Zuständigkeiten für die Festlegung von Projekten geregelt?
– In welcher Form werden in den Projektzielen Kostenziele, Terminziele und Qualitätsziele erfasst?

usw…

Die Quantität und Qualität der Antworten bleiben natürlich jedem PM-Verantwortlichen selbst überlassen. Es gibt bekanntlicher weise viele Wege nach Rom und in der heutigen Zeit ist reichhaltiges Methoden-Wissen nur einen Maus-Klick entfernt.

Die Inspiration zu den Fragen werde ich aus verschiedenen Quellen (z.B. Reifegradmodelle, Fachliteratur, eigene Erfahrungen) beziehen. Sobald mein erster Entwurf fertig ist, wird er an dieser Stelle veröffentlicht.

Open PM

Ich möchte heute alle Leser auf ein Projekt hinweisen, welches ich nach einigen Wochen skeptischen Beobachtens und Abwartens, für einen sehr guten Ansatz halte!

Um die Erklärung zu vereinfachen, copy-und-paste ich hier einfach mal das Mission Statement:

“Open-PM (#openpm) ist eine offene, frei zugängliche, unabhängige und nicht kommerzielle Plattform für Projektmanagement und alle, die an Projekten arbeiten. Aus der Praxis für die Praxis werden qualitativ hochwertige, interdisziplinäre, vielfältige und unter einer freien Lizenz nutzbare Tools und Prozesse als zentral verfügbares Know-How gesammelt, bereitgestellt und gemeinsam weiter entwickelt.

Werte

Aus der Praxis für die Praxis.
Wertschätzender Umgang mit Meinungs- und Ideenvielfalt.
Offen und frei zugänglich und unter einer freien Lizenz nutzbar.
Kollegiale Zusammenarbeit und Bereitschaft zum Teilen.”

Quelle: OpenPM

Projektmanagement für technische Projekte


Kurzbewertung:
ISBN: 978-3-8348-0724-3

Wer ab und an im Fachmagazin der GPM (PM aktuell) blättert , der findet diese tollen Checklisten zum Heraustrennen und Sammeln. Der inhaltliche Ursprung lässt sich in dem Werk von Roland Felkai und Arndt Beiderwieden “Projektmanagement für technische Projekte – Ein prozessorientierter Leitfaden für die Praxis” finden. Im Vorwort heißt es: “Das Buch wendet sich an alle Führungskräfte und Projektmitarbeiter in technischen Projekten, insbesondere an Ingenieure. Es dient ebenso der beruflichen Vorbereitung für Studenten der Ingenieur- und Wirtschaftswissenschaften sowie für Studenten der Physik.”


Inhalt


Das reichlich 300 Seiten starke Werk ist in zwei Hauptteile gegliedert: Teil 1 – Schritt für Schritt durch das Projekt und Teil 2 – Unterstützende Management-Techniken. Im ersten Hauptteil gehen die Autoren zunächst auf den Begriff “Projekt” ein. Die zuletzt heiß geführte Diskussion über die Begriffsdefinition von “Projekt” wird hier, ausgehend von der Def. der DIN, auf 11 spezifische Projektmerkmale kondensiert. Weiter geht es mit der Beschreibung von Projektphasen – vom allgemeinen Phasenmodell nach DIN zu Projektphasen technischer Projekte, inklusive der zu erwartenden Ergebnisse. (z.B. nach der Angebotsphase sollte eine detaillierte Durchführbarkeitsanalyse fertiggestellt worden sein). Nach der Beleuchtung der Projektphasen gehen die Autoren näher auf die Prozesse ein, sowohl nach DIN als auch nach PRINCE2. Interessant sind auch die Ausführungen zur Installation eines Berichtswesens (Protokolle, Berichte), insbesondere die Einführung von Aktionslisten (jedes Todo erhält eine laufende Nummer) und das entsprechende Dokumentationssystem. Am Ende jedes Kapitels wird das behandelte Wissensgebiet anhand des fiktiven Projekts “NAFAB” erläutert. Einige Leser werden dieses Exerzieren am Beispielprojekt sicher hilfreich finden, andere werden sich daran nicht lange aufhalten und schnell eine Seite weiter blättern.

Das zweite Kapitel trägt die Überschrift “Analysieren und Formulieren von Projektzielen”. Unter anderem wird hier auf den Unterschied zw. Lasten- und Pflichtenheft sowie den angelsächsischen Begriffen “specification” (technische Anforderungen) und “statement of work” (Leistungsbeschreibung) eingegangen. Sehr interessant sind die Ebenen der technischen Anforderungen (Systemanforderungen, Subsystem~, Geräte~, Komponenten~, Einzelteil~, Schnittstellen~), untersetzt mit einem Beispiel-Katalog (S.55 ff).
Kapitel 3 (“Analysieren der Durchführbarkeit”) beschreibt vier Teilanalysen (1) technisch im vorgegebenen Zeitrahmen machbar (2) rentabel und finanzierbar (3) Risiken und Chancen und (4) Interessen von Stakeholdern. Ein kurzer BWL-Exkurs erklärt Rentabilität, Liquidität, ROI und Liqui-Plan. Es folgt eine genaue Beschreibung von Risikoarten (technische Risiken, Lagerung & Transport, Planungsrisiken, Vertragliche ~, Kaufmännische ~, Personelle ~, Politik und Umwelt ~).
Kapitel 4 (Bilden eines Teams) empfiehlt eine Trennung zwischen Angebotsteam und Projektteam. Die Projektrollen sind sehr differenziert, es fehlt allerdings das PMO. Kapitel 5 (Erstellen eines Angebots) erläutert die Definition und den Aufbau eines Angebots. Hier ist der Leser ganz klar in der Welt eines Konzerns angelangt, da im KMU-Bereich selten derart detaillierte Angebotsunterlagen erstellt werden. Dennoch werden wichtige Themen wie Berichtswesen, Dokumentenmanagement, QM, Konfigurationsmanagement, Änderungs~ und Nachforderungsmanagement (Claims-Management) erörtert.
Die weiteren Kapitel “Entwickeln eines technischen Lösungskonzepts” (6), “Erstellen eines Entwicklungskonzepts” (7), “Erstellen eines Verifikationskonzepts” (8), “Planen des gesamten Projekts” (9), “Verhandeln und Abschließen des Vertrags” (10), “Managen der Realisierung” (11) und “Abschließen des Projekts” (12) enthalten viel Grundlagen- und Methodenwissen zu den entsprechenden Themen. Mein Lieblings-Zitat lautet: “Das Projektmanagement sollte die Projektplanung niemals am grünen Tisch entwickeln, sondern stets die betreffenden Projektmitarbeiter in Planungsentscheidungen einbeziehen.” (S. 189)

Teil 2 des Buchs gibt noch ein paar (mehr oder weniger nutzbare) Extrakte aus diversen Management-Ratgebern (Leiten von Besprechungen, Führen und Motivieren von Mitarbeitern sowie Informieren und Überzeugen durch Präsentationen)

Stil


Das Buch ist einfach lesbar und für Praktiker gedacht. Fußnoten und Quellenverweise werden auf das aller nötigste beschränkt. Am Ende jeden Kapitels werden praktische Werkzeuge und Checklisten im Stil von Kopiervorlagen dargestellt – wer schnell ein paar Anregungen zu einem bestimmten Gebiet sucht, ist hier genau richtig. Durch die sehr gute Strukturierung findet man sich jederzeit im Buch zurecht.

Fazit


Projektmanagement für technische Projekte” ist tatsächlich ein Leitfaden für die Praxis und bringt durch die knackigen Zusammenfassungen am Ende jeden Kapitels schnell Mehrwert. Je kleiner jedoch die Projekte und Organisation des Lesers, desto weniger relevant werden einige Inhalte des Buches sein. Der mittelständige Projektleiter wird daher viele Werkzeuge als unnötig und über-bürokratisch empfinden – einige Passagen sind nur auf Konzern-Ebene wirklich zu gebrauchen.
Für alle Fans von Checklisten ist dieses Buch aus den o.g. Gründen besonders empfehlenswert. Einige der Checklisten sind allerdings nur bedingt hilfreich, wenn z.B. Fragen wie “Sind alle übergreifenden Projektziele erfasst?” oder “Liegen alle Anforderungen hinsichtlich… vor?” oder “Ist Risiko XYZ begrenzt?” enthalten sind. Was, wenn eine Anforderung vergessen wurde? Wie sicher ist sicher? Wie ist ein Risiko begrenzbar?

Unter dem Strich ist das Buch sein Geld auf jeden Fall wert und kann sowohl Anfängern als auch Profis empfohlen werden! Ein Hoch auf die Check-Listen!