Management-Zusammenfassung dieses Beitrags:
Anforderungen / Requirements werden im → Requirements Engineering unterschiedlich klassifiziert. Je nach Verband, → Standard, → Norm oder Autor finden sich unterschiedliche Bezeichnungen.
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)
Eine genaue und allgemein anerkannte Definition mit Abgrenzungen dieser Bezeichnungen gibt es nicht, je nach Standard und Autor werden sie unterschiedlich verwendet.
1. Einleitung und Grundlagen
Anforderungen werden unterteilt / eingeteilt, um sie systematisch und spezifisch 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, Mindestanforderungen, Modulanforderungen, → Nicht-funktionale Anforderungen, Nutzeranforderungen, Produktanforderungen, 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 / Qualitätsanforderungen”)
- 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
Bei Gottesdiener /Got02, Got05/ finden sich ebenfalls drei Anforderungstypen (dort als Requirements Level bezeichnet), die in Form einer Pyramide dargestellt werden (Abbildung 2.3). Hinzugefügt werden folgende Fragestellungen für die einzelnen Typen:
- Business Requirements: Warum wird das Projekt durchgeführt?
- User Requirements: Was können die Nutzer mit dem Produkt machen?
- Software Requirements: Was benötigen die Entwickler für die Entwicklung?
Abbildung 2.3: Anforderungstypen (mit Fragestellungen) nach Gottesdiener /Got02, Got05/
Bei Sophist /#Sophist-RE-Fibel-4te-Auflage-18/ findet sich ein Schema zur Einordnung der Anforderungen mit fünf Ebenen (Abbildung 2.4). Dabei werden den einzelnen Ebenen / Levels Begrifflichkeiten zugeordnet, die häufig zu finden sind.
Abbildung 2.4: Anforderungstypen (mit Detaillierungsgrad) nach Sophist /#Sophist-RE-Fibel-4te-Auflage-18/
Das IREB /IREB-24, IREB21/ unterscheidet fünf Anforderungstypen (ohne den Begriff “Typen” zu verwenden), diese sind in Abbildung 2.5 dargestellt. 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.5: Anforderungstypen nach IREB /IREB-24, IREB21/
Ebert /Ebert19, Ebert22/ verwendet drei Stufen von Anforderungen (Abbildung 2.6) 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.6: Anforderungsstufen nach Ebert /Ebert19, Ebert22/
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.7 dargestellt. Dabei sind in der rechten Spalte korrespondierende Bezeichnungen aus anderen Typisierungen genannt.
Abbildung 2.7: 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 und wird in der Praxis 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 sich die Randbedingungen ä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 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 Ermittlung 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 Requirements-Vorhaben 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
5.3 Zuordnung von Requirements zu Dokumenten
Wiegers /Wiegers23/ benennt Dokumente (wobei dies auch Container sein können), die die einzelnen Anforderungstypen erfassen können (Abbildung 5.3). Dabei werden die vier Anforderungstypen Business Requirements, System Requirements, User Requirements und Solution Requirements betrachtet. Diese können in die vier Dokumente “→ Vision and Scope Document”, “System Requirements Specification”, “User Requirements Document” und “Software Requirements Specification” untergebracht werden.
Abbildung 5.3: Anforderungstypen und dazugehörige Dokumente (nach /Wiegers23/)
Abbildung 5.4: Anforderungstypen und dazugehörige Dokumente (nach /Wiegers23/): Legende
Anmerkung:
Die Solution Requirements in diesem Modell umfassen sowohl die funktionalen Anforderungen als auch die Qualitätsanforderungen (bei Wiegers: Quality Attributes). Damit ist diese Beschreibung mit dem IREB-Ansatz kompatibel.
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: Was ist der Unterschied zwischen User Requirements und Stakeholder Requirements?
A: Generell sind User Requirements und Stakeholder Requirements synonym zu verwenden. In den älteren Normen und Standards findet sich eher User Requirements, in der heutigen Zeit ist Stakeholder Requirements der gängigere Begriff. - 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 einen 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
A.1 Präsentationen
- -
A.2 Literatur
- /BBG15/ IIBA: A Guide to the → Business Analysis Body of Knowledge (BABOK Guide), International Institute of Business Analysis, Marietta, Georgia 3rd Edition 2015, ISBN 978–1‑927584–02‑6
- /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
- /Got05/ Ellen Gottesdiener: The Software Requirements Memory Jogger. A Pocket Guide to Help Software and Business → Teams Develop and Manage Requirements, Goal/QPC, Salem, New Hampshire 2005, ISBN 978–1‑57681–060‑6
- /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
- /Hruschka23/ Peter Hruschka: Business Analysis und Requirements Engineering. Prozesse und Produkte nachhaltig verbessern, Hanser, München 3. Auflage 2023, ISBN 978–3‑446–47692‑9
- /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
- /Wiegers23/ Karl Wiegers, Candase Hokanson: Software Requirements Essentials. Core Practices for Successful Business Analysis, Addison-Wesley Professional, Boston, Massachusetts 2023, ISBN 978–0‑13–819028‑6
A.3 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)
- /#Sophist-RE-Fibel-4te-Auflage-18/ Fa. Sophist: Die kleine RE-Fibel, 4. Auflage 2018 (deutsch, pdf-Datei, 76 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: 04.10.2024 © Peterjohann Consulting, 2005–2024
