Kategorie-Archiv: Requirements Engineering

Anforderungsmanagement in KMU

Gerade in kleinen und mittleren Unternehmen (KMU) ticken die Uhren anders als im Konzern. Dies kann von Vorteil sein (z.B. im Sinne höherer Flexibilität) aber auch negativ aufgrund der Tatsache, dass für viele wesentliche Dinge innerhalb eines Projekts und darüber hinaus die Ressourcen zu knapp bemessen sind. Mit einem dieser Aspekte (dem Anfordeurngsmanagement) beschäftige ich mich im Rahmen meiner Dissertation genauer.

Was ist eigentlich Anforderungsmanagement? Im englischen Sprachraum findet der Begriff “Requirements Engineering, Abk. RE” Anwendung, der den Sachverhalt besser beschreibt als das eingedeutschte Anforderungsmanagement. Die folgende Grafik macht deutlich, dass es sich beim Anforderungsmanagement um einen Kreislauf aus Unterprozessen handelt, beginnend bei der Anforderungsaufnahme, über die Analyse und Spezifikation bis schließlich zur Validierung der Anforderungen. Im Zentrum steht das eigentliche Management der Anforderungen, das u.a. das Überwachen von Änderungen sowie die Prüfung deren Auswirkungen auf andere Anforderungen und auf das Projekt beinhaltet.

anforderungsmanagement

Ziel meiner Arbeit ist es, das Zusammenspiel von Anforderungsmanagement, Projektabwicklung und Kundeninegration in KMU der Branche Maschinen- und Anlagenbau zu erforschen. Dafür werde ich in den nächsten Tagen eine erste Online-Befragung starten, deren Ergebnisse als Teil der empirischen Untersuchung Verwendung finden sollen.

Sollten Sie Fragen zum Forschungsthema haben oder sich daran beteiligen wollen (z.B. in Form einer Fallstudie), können Sie mich jederzeit kontaktieren!

Die folgende Fachliteratur zum Thema kann ich empfehlen:

– Pohl, Klaus; Rupp, Chris; 2009, Basiswissen requirements engineering
– Rupp, Chris; 2009, Requirements-Engineering und -Management – Professionelle, iterative Anforderungsanalyse für die Praxis
– Pohl, Klaus; 2008; Requirements Engineering – Grundlagen, Prinzipien, Techniken
– Sommerville, Ian; Sawyer, Pete; 1997; Requirements engineering – A good practice guide
– Kotonya, Gerald; Sommerville, Ian; 1997; Requirements Engineering

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.