Management-Zusammenfassung dieses Beitrags:
Anforderungen / Requirements werden im → Requirements Engineering unterschiedlich klassifiziert. Je nach Verband, → Standard, → Norm oder Autor sind unterschiedliche Bezeichnungen zu finden.
In diesem Beitrag wird ein Klassifikationsschema mit den entsprechenden Bezeichnungen vorgestellt, welches in meinen Beiträgen und → Präsentationen durchgängig verwendet wird.
Generell können zur Klassifikation (von Anforderungen) verschiedene Begriffe verwendet werden. Typische Bezeichnungen sind:
- Typen (Types)
- Arten (Kinds)
- Klassen (Classes)
- Kategorien (Categories)
- Stufen (Levels)
1. Einleitung und Grundlagen
Anforderungen werden unterteilt / eingeteilt, um sie so besser und systematischer behandeln zu können.
Die Klassifikation der Anforderungen ist für viele Bereiche im Requirements Engineering wichtig. Dies sind beispielsweise:
- Für den RE-Prozess ist es wichtig, welche Grenzen und Übergabepunkte verwendet werden
- Für die → Traceability ist es entscheidend, welche Typen oder Arten genutzt werden
Werden Tools (→ RE-Tools) oder Anforderungslisten verwendet, so muss unbedingt vorab geklärt werden, welche Klassifikationen verwendet werden sollen.
Namen von Anforderungen gibt es viele — hier sind einige davon gelistet:
Abnahmeanforderungen, Architekturanforderungen, Basisanforderungen, Begeisterungsanforderungen, Betriebliche Anforderungen, Business-Anforderungen, Customer-Anforderungen, Domänenanforderungen, Entwickleranforderungen, Fachliche Anforderungen, Funktionale Anforderungen, Geschäftsanforderungen, Grundanforderungen, Hardware-Anforderungen, High-Level-Anforderungen, Komponenten-Anforderungen, Kundenanforderungen, Leistungsanforderungen, Lösungsanforderungen, Low-Level-Anforderungen, Marktanforderungen, Mid-Level-Anforderungen, Modulanforderungen, Nicht-funktionale Anforderungen, Nutzeranforderungen, Projektanforderungen, Prozessanforderungen, Qualitätsanforderungen, Softwareanforderungen, Stakeholderanforderungen, Systemanforderungen, Technische Anforderungen, Technikanforderungen, Testanforderungen, Transitionsanforderungen, Übergangsanforderungen, Überleitungsanforderungen, Unternehmensanforderungen, User-Anforderungen
2. Anforderungstypen
Der Begriff “Typen” wird für die Abstufung von den “Business Requirements” zu den “Solution Requirements” verwendet (Abbildung 2.1). Diese Unterteilung ist beim → IIBA zu finden /BBG15, BBG17‑d/, aber auch in ähnlicher Form beim → IREB /IREB21/. Es werden dabei vier Anforderungstypen und zwei Unterkategorien benannt:
- Business Requirements (“Geschäftsanforderungen”, “Betriebliche Anforderungen” /BBG17‑d/): Hiermit werden die Anforderungen beschrieben, die aus dem Organisations- / Unternehmenskontext kommen
- → Stakeholder Requirements (“Anforderungen der Stakeholder”, “Stakeholder-Anforderungen” /BBG17‑d/): Anforderungen der Stakeholder; diese Anforderungen sind eher am → Problem und weniger an der Lösung orientiert
- Solution Requirements (“Lösungsanforderungen”): Anforderungen zur Beschreibung der Lösung; diese sind wiederum unterteilt in die Unterkategorien (Sub Categories)
- Functional Requirements (“Funktionale Anforderungen / Lösungsanforderungen”)
- Non-functional Requirements (“Nicht-funktionale Anforderungen / Lösungsanforderungen”)
- Transition Requirements (“Übergangsanforderungen”, “Überleitungsanforderungen” /BBG17‑d/): Anforderungen, um den Übergang zur neuen Lösung zu ermöglichen
Anmerkung:
Es werden im Praxisalltag eher die englischen Begriffe verwendet, die deutschen Übersetzungen sind daher “uneinheitlich”.
Abbildung 2.1: Anforderungstypen nach IIBA und → PMI
Die vier Anforderungstypen stehen in einer hierarchischen Beziehung zueinander: Die Business Requirements stehen über den Stakeholder Requirements und die wiederum über den Solution Requirements (Abbildung 2.2). Die Transition Requirements dienen dazu, die Umsetzung von Stakeholder oder Solution Requirements zu ermöglichen und sind somit nicht aus den anderen Requirements ableitbar.
Abbildung 2.2: Anforderungstypen (hierarchisch) nach IIBA und PMI
Das IREB /IREB-24, IREB21/ unterscheidet fünf Anforderungstypen (ohne den Begriff “Typen” zu verwenden). Als Referenz wird auf die ISO 29148:2018 (“Systems and → software engineering — Life cycle processes — Requirements engineering”) verwiesen. Als Besonderheiten gegenüber dem IIBA- und PMI-Modell können genannt werden:
- Neben den Stakeholder Requirements kennt das IREB noch die User Requirements (Benutzeranforderungen): Diese beschreiben dediziert die Sicht der Benutzer
- Die Solution Requirements des IIBA- und PMI-Modells werden zu System Requirements bei IREB
- Die Domänenanforderungen definieren domänenspezifische Inhalte — diese Betrachtungsebene fehlt beim IIBA- und PMI-Modell
Abbildung 2.3: Anforderungstypen nach IREB /IREB-24, IREB21/
Ebert /Ebert19/ verwendet drei Stufen von Anforderungen (Abbildung 2.4) und benennt den Übergang von Problem- zum Lösungsraum.
Im Einzelnen:
- Marktanforderungen benennen die Bedürfnisse / Anforderungen, die sich aus dem Markt ergeben
- Produktanforderungen liefern eine (erste) grobe Sicht auf die Lösung
- Komponentenanforderungen detaillieren die Produktanforderungen
Abbildung 2.4: Anforderungsstufen nach Ebert /Ebert19/
Dieses Modell mit nur drei Anforderungsstufen ist für praktischen Einsatz nicht ausreichend, in der Regel werden über die RE-Tools mehrere Stufen erfasst.
Eine Einteilung in High‑, Mid- und Low-Level-Anforderungen ist in Bild 2.5 dargestellt. Dabei sind in der rechten Spalte korrespondierende Bezeichnungen aus anderen Typisierungen genannt.
Abbildung 2.5: Anforderungstypisierung High-Mid-Low
3. Anforderungsarten
Das IREB /IREB21/ unterteilt die Anforderungen in die beiden Arten …
- Funktionale und
- Nicht-funktionale Anforderungen (Abbildung 3.1).
Abbildung 3.1: Anforderungsarten nach IREB
Die funktionalen Anforderungen beschreiben — grob gesprochen — das, was umgesetzt werden muss. Die nicht-funktionalen Anforderungen liefern Einschränkungen und Qualitätsmerkmale. Diese Einteilung entspricht den Subkategorien des IIBA für Lösungsanforderungen. Diese Einteilung wird häufig verwendet.
Üblicherweise werden alle Lösungsanforderungen an ein Produkt oder System (grob) in die Anforderungsarten funktionale und nicht-funktionale Anforderungen unterteilt. Das IREB geht einen Schritt weiter und untergliedert die nicht-funktionalen Anforderungen in Qualitätsanforderungen und Randbedingungen. Es ergibt sich folgendes “großes Bild” /IREB21, Ebert19/:
Abbildung 3.2: Einteilung von Anforderungen
Während die Qualitätsanforderungen üblicherweise während der gesamten Projektlaufzeit stabil bleiben, können die Randbedingungen sich ändern und müssen daher regelmäßig überprüft werden.
Die funktionalen Anforderungen sind (vergleichsweise) einfach zu beschreiben. Die Erfassung der nicht-funktionalen Anforderungen bereitet in der Praxis größere Probleme, da sie nicht einfach zu ermitteln sind und dennoch das Gesamtsystem entscheidend definieren. Häufig gibt es aber vordefinierte Listen zu den funktionalen Anforderungen einer Domäne.
4. Weitere Einteilungen von Anforderungen
Anforderungen können je nach Betrachtungsweise auch in andere Kategorien eingeteilt werden. Hier sind beispielsweise zu nennen:
- Implizite und explizite Anforderungen: Wenn Anforderungen genannt werden, so kann es sein, dass sie dennoch implizit vorausgesetzt werden. Für den → Requirements Engineer ist es wichtig, neben den expliziten Anforderungen auch die impliziten zu berücksichtigen. Hilfreich ist hierbei das → Kano-Modell, welches auf die Basisfaktoren und damit auf die impliziten Anforderungen hinweist
- Dokumentierte und undokumentierte Anforderungen: Nicht alle Anforderungen werden in einem Anforderungsvorhaben dokumentiert; Ziel ist es jedoch, eine hohe Quote von dokumentierten Anforderungen zu haben
- Relevante und nicht-relevante Anforderungen: Anforderungen können für das jeweilige → Vorhaben relevant oder auch nicht-relevant sein. Nicht immer ist dies im Vorfeld oder bei der Erhebung zu bestimmen. Daher sollte die Bestimmung, ob eine einzelne Anforderung relevant ist oder nicht, bei einem separaten → Review erfolgen
- Erfasste und nicht-erfasste Anforderungen: Nicht-erfasste Anforderungen, die relevant sind, sollte es in einem Requirements-Vorhaben nicht geben. Erfasste Anforderungen (und auch nur diese) bestimmen den Umfang des zu erstellenden Produkts oder der zu erstellenden Dienstleistung
In Abbildung 4.1 sind einige Unterteilungen von Anforderungen dargestellt.
Abbildung 4.1: Weitere Unterteilungen von Anforderungen
Die Unterteilungen in → Abbildungen verdeutlichen jeweils, dass nicht (immer) alle Anforderungen in eine Anforderungsspezifikation aufgenommen werden.
5. Einsatz der Klassifikation von Anforderungen
Die Klassifikation von Anforderungen kann auch praktisch eingesetzt werden. In diesem Kapitel werden zwei Beispiele genannt.
5.1 Ableitung eines V‑Modells
Aus den Klassifikationstypen für Requirements kann ein → V‑Modell abgeleitet werden (beispielhaft in Abbildung 5.1 nur für Requirements). Dabei werden im linken Zweig die Klassifikationsstufen der Anforderungen und im rechten Zweig die Software- oder Systementwürfe aufgezeichnet. Als Basis dienen die drei Anforderungstypen “Business Requirements”, “Stakeholder Requirements” und “Solution Requirements”, die um “System Requirements” — die technische Implementierungen beschreiben — ergänzt werden.
Abbildung 5.1: Ein V‑Modell für das Requirements Engineering
Anmerkung:
Ein V‑Modell nur für das Requirements Engineering ist in der Praxis selten zu finden, da im Allgemeinen nicht der Übergang von den Requirements zum Entwurf im Vordergrund steht, sondern das Abgleichen von schriftlich fixierten Anforderungen und (in Lösungen) umgesetzten Anforderungen.
5.2 Einsatz von Beschreibungsformen
Über ein Klassifikationsschema kann eine Zuordnung von Anforderungen zu Beschreibungsformen vorgenommen werden. In Abbildung 5.2 sind beispielhaft den drei Anforderungsstufen verschiedene Beschreibungsformen zugeordnet. Generell sollte bei einem Requirementsvorhaben vorab festgelegt werden, welche Beschreibungsformen zum Einsatz kommen sollen und dürfen, was in der Praxis bedeutet, die Anzahl der Beschreibungsformen zu beschränken.
Abbildung 5.2: Anforderungstypen nach High-Mid-Low und Zuordnung von Beschreibungsformen
6. Häufig gestellte Fragen und Antworten (FAQ) zur Klassifikation von Anforderungen
Einige Fragen zur Klassifikation von Anforderungen werden häufig gestellt – diese werden hier wiedergegeben und beantwortet.
- F: Müssen Klassifikationen von Anforderungen immer vorgenommen werden?
A: Ja — dies ist unbedingt empfehlenswert, umso die Sprach- und Vorgehensweise in einem Requirements-Vorhaben zu vereinheitlichen. - F: Welche Klassifikation ist diejenige, die universell genutzt werden kann?
A: Eine universelle, d.h. für alle Requirements-Vorhaben passende Klassifikation gibt es nicht. Je nach Requirements-Vorhaben muss daher eine individuelle Klassifizierung vorgenommen werden. - F: Stehen die System Requirements oberhalb der Solution Requirements?
A: Dies ist nicht eindeutig — weder in der Theorie noch in der Praxis. Auch in diesem Beitrag stehen die System Requirements manchmal oberhalb der Solution Requirements, manchmal unterhalb. - F: Was ist mit der Unterteilung nach Muss‑, Soll- und Kann-Anforderungen?
A: Die Muss‑, Soll- und Kann-Anforderungen geben eine → Priorisierung vor und keine inhaltliche Abstufung wie die in diesem Beitrag beschriebenen Klassifikationsmöglichkeiten. - F: Wie erstellt man eine passende Klassifikation von Requirements?
A: Da dies nicht einfach ist, ist es ratsam, hierfür eine erfahrenen Requirements Engineer / Business Analysten hinzuzuziehen.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
Präsentationen
- -
Literatur
- /BBG17‑d/ IIBA: BABOK v3: Leitfaden zur Business-Analyse BABOK Guide 3.0, Dr. Götz Schmidt, Wettenberg 2017, ISBN 978–3‑945997–03‑1
- /Ebert19/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 6. Auflage 2019, ISBN 978–3‑86490–562‑9
- /Ebert22/ Christof Ebert: Systematisches Requirements Engineering. Anforderungen ermitteln, dokumentieren, analysieren und verwalten, dpunkt, Heidelberg 7. Auflage 2022, ISBN 978–3‑86490–919‑1
- /IREB21/ siehe /Pohl21/
- /Jonasson19/ Hans Jonasson: Determining Project Requirements. Mastering the BABOK and the CBAP Exam, CRC Press, Boca Raton, Florida 2nd Edition 2019, ISBN 978–1‑4987–6725‑5
- /Got02/ Ellen Gottesdiener: Requirements by Collaboration, Addison-Wesley Professional, Boston, Massachusetts 2002, ISBN 978–0‑201–78606‑4
- /Hruschka19/ Peter Hruschka: → Business Analysis und Requirements Engineering: Prozesse und Produkte nachhaltig verbessern, Hanser, München 2. Auflage 2019, ISBN 978–3‑446–45589‑4
- /PMG-BA17/ Project Management Institute: The PMI Guide to Business Analysis, Project Management Institute, Philadelphia, Pennsylvania 2017, ISBN 978–1‑62825–198‑2
- /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 5. Auflage 2021, ISBN 978–3‑86490–814‑9
Weblinks
- /IREB-24/, /#IREB-24/, /#IREB-CPRE-FL-24/ IREB – International Requirements Engineering Board: Lehrplan / Syllabus zum CPRE-FL, Version 3.2.0 vom Februar 2024 (deutsch, pdf-Datei, 51 Seiten)
- /#IREB-→ Glossar-24/ IREB – International Requirements Engineering Board: Glossar des IREB, Version 2.1.1 vom April 2024 (deutsch, englisch, pdf-Datei, 65 Seiten)
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 14.01.2023 © Peterjohann Consulting, 2005–2024
