Zum Hauptinhalt springen

Anforderungsgranularität - Detaillierungsgrad

Level of Detail from Requirements


image-20240103102916897

Stakeholder kommunizieren ihre Bedürfnisse häufig in unterschiedlichen Granularitätsstufen bzw. Detaillierungsgraden: von groben Anforderungen wie allgemeinen Geschäftszielen, bis hin zu detaillierteren Anforderungen, in denen die Einzelheiten zu erwarteten Systemfunktionalitäten festgelegt sind. Funktionale und Qualitätsanforderungen können (und sollten!) daher auf unterschiedlichen Abstraktionsebenen besprochen und dokumentiert werden.

In der Agile-Community gibt es derzeit keinen Konsens über die Terminologie für abstraktere Anforderungen.

image-20230109182210871

Abbildung (Quelle = IREB, Handbuch RE@Agil, V2.0)

IREB hat eine der populäreren Begriffsgruppen für Anforderungen auf verschiedenen Granularitätsstufen gewählt, die drei Begriffe enthält: Epics (für grobgranulare Anforderungen), Features (mittlere Granularität) und User Storys (feingranular).

platinus verwendet folgende Begriffsgruppen bzw. Hierarchiestufen.

Granularitätsstufe-1 = Themen - Domains

Investitionsthemen - Goal-Typ

Investitionsthemen (domains) beschreiben Maßnahmen zur Umsetzung der Ziele eines Unternehmens oder einer Geschäftseinheit. Sie werden im Rahmen der Budgetierung ermittelt, bewertet und mit Budget versehen. Die Budgetzuordnung erfolgt in der Regel für eine Planungsperiode (z. B. ein Jahr) und kann im Rahmen einer rollierenden Planung, z. B. je Quartal, angepasst werden. Investitionsthemen können in Anlehnung an die Projektklassifizierung nach Projektkategorien ( Run the Business, Rationalize the Business, Growth the Business, Transform the Business ) oder einfach nach Schlagworte benannt, wie z. B. „Einführung BPM-System“.

Die Investitionsthemen beschreiben den "Goal-Typ". Folgende Themen sind vordefiniert:

  1. T1 = Run the Business
  2. T2 = Optimize the Business, Rationalisierung
  3. T3 = Growth the Business, Wachstum
  4. T4 = Transform the Business, Innovation, Neugestaltung
  5. T5 = Sonstige Themen

Themengebiete - Demand-Typ

Themengebiete (areas) beschreiben die Kundenbedürfnisse auf hoher Ebene. Sie füllen die Investitionsthemen mit Inhalten, sodass diese grob abgeschätzt und priorisiert werden können. Themengebiete können jeweils unabhängig bewertet und priorisiert werden. Die Umsetzung eines Themengebietes erfolgt über Projekte oder Maßnahmen in einem oder mehreren Releases eines oder mehrerer IT-Systeme. Der Inhalt eines Themengebietes wird in der Regel in wenigen Sätzen oder Aufzählungspunkten beschrieben. Die verfolgten Ziele sollten dabei hervorgehen. Im agilen Umfeld wird häufig der Begriff „Epic“ in diesem Kontext verwendet.

Eine zusätzliche Klassifizierung auf der Ebene 1 kann durch den "Demand-Typ" erfolgen.

  1. D1 = Mandardory-Demand, Zwangsauslöser, Muss-Anforderung.
  2. D2 = Fachbereichs-Demand. Fachbereichs-Auslöser. Bei Bedarf kann eine weitere Unterteilung nach Objekten erfolgen.
    1. Business-Product-Demand
    2. Business-Process-Demand
    3. Business-People-Demand
  3. D3 = Service-Demand. Servicebereichs-Auslöser. Bei Bedarf kann eine weitere Unterteilung nach Inhalten erfolgen.
    1. IT-Product-Demand (End-of-Life)
    2. IT-Process-Demand
    3. IT-Asset-Demand
    4. IT-Security-Demand

Aus den Parametern Goal-Typ und Demand-Typ kann eine Matrix gebildet werden. Diese dient zur Analyse der Themenbereiche.

Granularitätsstufe-2 = Initiativen - Anforderungsgebiete

Requirements Areas oder Capabilties. In Anlehnung an ITILv3 sind folgende Fähigkeiten vordefiniert:

  1. C1 = Product-Capability.
  2. C2 = Process-Capability
  3. C3 = People-Capabilty
  4. C4 = Partner-Capability
  5. C5 = Sonstige Capability

Granularitätsstufe-3 = Anforderungsgruppen - Epics

Requirements Groups bestehen aus Epics. So kann zB. das Anforderungsgebiet Process-Capabilities aus mehrere Anforderungsgruppen bestehen (IT-Prozesse, CRM-Prozesse, SCM-Prozesse, PLM-Prozesse,...). So kann Anforderungsgebiet Product-Capability aus mehrere Anforderungsgruppen bestehen (IT-IS, Facilties). Unter einem Epic versteht man im Kontext des Anforderungsmanagements die Beschreibung einer Anforderung auf einer hohen Abstraktionsebene. Die Beschreibung der Anforderung geschieht dabei in der Alltagssprache. Zur Formulierung werden häufig Satzschablonen angewendet: Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen.

Granularitätsstufe-4 = Anforderungen

Epic bestehe aus mehreren Features, Use Cases, Anwendungsfällen, Geschäftsfällen. (Grobgranulare Anforderungen). Der BABOK Guide definiert ein Feature als “ein Unterscheidungsmerkmal einer Lösung, die einen zusammenhängenden Satz von Anforderungen implementiert und die einen Wert für eine Reihe von Stakeholdern liefert.” Aus dieser Definition lassen sich zwei Erkenntnisse ableiten: Ein Feature beschreibt, was ein Produkt hat oder tut. Und es ist größer als User Storys.

Features

Features (groups) sind Funktionalitäten eines oder mehrerer Systeme oder Produkte, die für den Anwender einen unmittelbaren Wert darstellen. Sie werden vom Anwender als ein sinnvolles Ganzes wahrgenommen. Bei (Software-)Produkten wird häufig bei der Bestimmung der Features hinterfragt, ob dieses für den Käufer kaufentscheidend ist. Ein Feature wird über ein Projekt oder eine Wartungsmaßnahme eines Release in einem oder mehreren miteinander verbundenen IT-Systemen umgesetzt. Für die Priorisierung und Umsetzungsplanung werden Features häufig in Teilfeatures zerlegt, wenn eines von ihnen nicht in einer Iteration umgesetzt werden kann. Ein Feature wird immer in einem Release, ggf. über mehrere Iterationen, umgesetzt. Der Umsetzungsaufwand für ein Feature sollte unter 100 Personentagen (PT) liegen. Liegt der Umsetzungsaufwand über 100 PT, muss für die Releaseplanung eine weitere Detaillierung auf Teilfeatures erfolgen.

Granularitätsstufe-5 = Teilanforderungen - User-Story

Feature bestehen aus User Stories (Anforderungen mittlerer Granularität). User Story - Issues in Github (Feingranulare Anforderungen). "User-Storys“ sind kurze, einfache Beschreibungen eines Features. Diese werden aus der Perspektive der Person dargestellt, die die neue Funktion wünscht, also gewöhnlich ein Benutzer oder Kunde des Systems. Die Beschreibung erfolgt in der Regel nach einer einfachen Schablone: Als "Art des Benutzers" möchte ich "ein Ziel", um "ein Grund/Nutzen". Im wörtlichen Sinne beschreibt eine User Story eine Geschichte eines Anwenders. User bedeutet Anwender oder Benutzer und Story bedeutet Geschichte. Im agilen Projektmanagement und in der agilen Produkt- und Softwareentwicklung ist eine User Story somit ein Werkzeug, um gewünschte Funktionalitäten eines Systems aus Sicht des Anwenders zu beschreiben. Zur Formulierung werden häufig Satzschablonen angewendet: Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen.

Eine Realisierungsanforderung ist eine Aussage über eine Eigenschaft oder eine Leistung, die ein IT-System aus Sicht des Systemnutzers erbringen muss. Eine Realisierungsanforderung bezieht sich immer auf ein System oder Produkt. Eine Realisierungsanforderung wird über ein Projekt oder eine Wartungsmaßnahme in einer Iteration umgesetzt. Im agilen Umfeld wird häufig stattdessen die Einheit einer User Story verwendet. Der Umsetzungsaufwand sollte kleiner gleich 10 PT sein. Damit der Businessanalyst den Umsetzungsfortschritt in Projekten bzw. Wartungsmaßnahmen beurteilen kann, muss jede Realisierungsanforderung einem (Teil-)Feature zugeordnet sein.

Granularitätsstufe-6 = Task

Eine Task ist eine Tätigkeit zur Implementierung einer User Story. Der Fortschritt der Implementierung wird häufig per Taskboard visualisiert.

Dieser Prozess arbeitet mit dem anderen IT-Prozessen zusammen, um sicherzustellen, dass der Service-Provider ausreichend Kapazität bereitstellt, um den Bedarf zu erfüllen. Eine wesentliche Inputquelle für die Beschreibung des IT-Bedarfes ist u.a. der IT-Servicekatalog.

Im Prozess der Anforderungsermittlung und -dokumentation kann die Granularitätshierarchie auf verschiedene Weise erstellt werden. Wie zuvor angemerkt, nennen die Stakeholder üblicherweise ihre Wünsche auf unterschiedlichen Stufen. Sie können also versuchen, „top-down“ zu arbeiten (von Visionen und/oder Zielen ausgehend zu Anforderungen einer niedrigeren Stufe), „bottom-up“ (Gruppierung von Anforderungen mit hohem Detaillierungsgrad in größere Blöcke) oder „middle-out“ (beginnend mit Anforderungen der mittleren Stufe, wobei einige detaillierter unterteilt und andere zusammengefasst werden).

image-20230109184059743

Abbildung Granularitätsbaum (Quelle = IREQ)

Die Zerlegung und Gruppierung von Stories resultiert in Anforderungshierarchien. Oberhalb der Trennlinie werden größere Gruppierungen (wie große Storys, Epics und Features) so ausgerichtet, dass die gesamte Bandbreite der Funktionalität des Produkts abgedeckt ist. Das hilft dabei, den Überblick über die Anforderungen zu behalten. Unterhalb der Trennlinie können alle Informationen zu den größeren Gruppen detaillierter hinzugefügt und wie in einem linearen Backlog für die Zuordnung zu Sprints und Releases geordnet werden. Mit anderen Worten: In der Story-Map werden Backlogs pro Feature oder Epic dargestellt, wobei die Anforderungsstruktur auf höherer Ebene beibehalten wird.

image-20230109184630996

Abbildung Story Maps (Quelle = IREQ)

Verweise