Die Klassifikation von Anforderungen Anforderungen richtig zuordnen

Manage­ment-Zusam­men­fas­sung zu die­sem Bei­trag:
Anfor­de­run­gen / Requi­re­ments wer­den im → Requi­re­ments Engi­nee­ring unter­schied­lich klas­si­fi­ziert. Je nach Ver­band, Stan­dard, Norm oder Autor sind unter­schied­li­che Bezeich­nun­gen zu fin­den.
In die­sem Bei­trag wird ein Klas­si­fi­ka­ti­ons­sche­ma mit den ent­spre­chen­den Bezeich­nun­gen vor­ge­stellt, wel­ches in mei­nen Bei­trä­gen und → Prä­sen­ta­tio­nen durch­gän­gig ver­wen­det wird.

Gene­rell kön­nen zur Klas­si­fi­ka­ti­on (von Anfor­de­run­gen) ver­schie­de­ne Begrif­fe ver­wen­det wer­den. Typi­sche Bezeich­nun­gen sind:

  • Typen (Types)
  • Arten (Kinds)
  • Klas­sen (Clas­ses)
  • Kate­go­rien (Cate­go­ries)
  • Stu­fen (Levels)

1. Einleitung und Grundlagen

Anfor­de­run­gen wer­den unter­teilt / ein­ge­teilt, um sie so bes­ser und sys­te­ma­ti­scher behan­deln zu können.

Die Klas­si­fi­ka­ti­on der Anfor­de­run­gen ist für vie­le Berei­che im Requi­re­ments Engi­nee­ring wich­tig. Dies sind beispielsweise:

  • Für die RE-Pro­zess ist es wich­tig, wel­che Gren­zen und Über­ga­be­punk­te ver­wen­det werden
  • Für die → Tracea­bi­li­ty ist es ent­schei­dend, wel­che Typen oder Arten genutzt werden

Wer­den Tools (→ RE-Tools) oder Anfor­de­rungs­lis­ten ver­wen­det, so muss unbe­dingt vor­ab geklärt wer­den, wel­che Klas­si­fi­ka­tio­nen ver­wen­det wer­den sollen.

Namen von Anfor­de­run­gen gibt es vie­le — hier sind eini­ge davon gelistet:

Archi­tek­tur­an­for­de­run­gen, Basis­an­for­de­run­gen, Begeis­te­rungs­an­for­de­run­gen, Betrieb­li­che Anfor­de­run­gen, Busi­ness-Anfor­de­run­gen, Cus­to­mer-Anfor­de­run­gen, Domä­nen­an­for­de­run­gen, Fach­li­che Anfor­de­run­gen, Funk­tio­na­le Anfor­de­run­gen, Geschäfts­an­for­de­run­gen, Grund­an­for­de­run­gen, Hard­ware-Anfor­de­run­gen, High-Level-Anfor­de­run­gen, Kom­po­nen­ten-Anfor­de­run­gen, Kun­den­an­for­de­run­gen, Leis­tungs­an­for­de­run­gen, Lösungs­an­for­de­run­gen, Low-Level-Anfor­de­run­gen, Markt­an­for­de­run­gen, Mid-Level-Anfor­de­run­gen, Modul­an­for­de­run­gen, Nicht-funk­tio­na­le Anfor­de­run­gen, Nut­zer­an­for­de­run­gen, Pro­jekt­an­for­de­run­gen, Pro­zess­an­for­de­run­gen, Qua­li­täts­an­for­de­run­gen, Soft­ware-Anfor­de­run­gen, → Sta­ke­hol­der-Anfor­de­run­gen, Sys­tem­an­for­de­run­gen, Tech­ni­sche Anfor­de­run­gen, Tech­nik­an­for­de­run­gen, Tran­si­ti­ons­an­for­de­run­gen, Über­gangs­an­for­de­run­gen, Über­lei­tungs­an­for­de­run­gen, Unter­neh­mens­an­for­de­run­gen, User-Anforderungen

2. Anforderungstypen

Der Begriff “Typen” wird für die Abstu­fung von den “Busi­ness Requi­re­ments” zu den “Solu­ti­on Requi­re­ments” ver­wen­det (Abbil­dung 2.1). Die­se Unter­tei­lung ist beim → IIBA zu fin­den /BBG15, BBG17‑d/, aber auch in ähn­li­cher Form beim → IREB /IREB21/. Es wer­den dabei vier Anfor­de­rungs­ty­pen und zwei Unter­ka­te­go­rien benannt:

  • Busi­ness Requi­re­ments (“Geschäfts­an­for­de­run­gen”, “Betrieb­li­che Anfor­de­run­gen” /BBG17‑d/): Hier­mit wer­den die Anfor­de­run­gen beschrie­ben, die aus dem Orga­ni­sa­ti­ons- / Unter­neh­mens­kon­text kommen
  • Sta­ke­hol­der Requi­re­ments (“Anfor­de­run­gen der Sta­ke­hol­der”, “Sta­ke­hol­der-Anfor­de­run­gen” /BBG17‑d/): Anfor­de­run­gen der Sta­ke­hol­der; die­se Anfor­de­run­gen sind eher am → Pro­blem und weni­ger an der Lösung orientiert
  • Solu­ti­on Requi­re­ments (“Lösungs­an­for­de­run­gen”): Anfor­de­run­gen zur Beschrei­bung der Lösung; die­se sind wie­der­um unter­teilt in die Unter­ka­te­go­rien (Sub Cate­go­ries)
    • Func­tio­n­al Requi­re­ments (“Funk­tio­na­le Anfor­de­run­gen / Lösungsanforderungen”)
    • Non-func­tio­n­al Requi­re­ments (“Nicht-funk­tio­na­le Anfor­de­run­gen / Lösungsanforderungen”)
  • Tran­si­ti­on Requi­re­ments (“Über­gangs­an­for­de­run­gen”, “Über­lei­tungs­an­for­de­run­gen” /BBG17‑d/): Anfor­de­run­gen, um den Über­gang zur neu­en Lösung zu ermöglichen

Anmer­kung:
Es wer­den im Pra­xis­all­tag eher die eng­li­schen Begrif­fe ver­wen­det, die deut­schen Über­set­zun­gen sind daher “unein­heit­lich”.

Anforderungstypen nach IIBA und PMI, (C) Peterjohann Consulting, 2018-2022

Abbil­dung 2.1: Anfor­de­rungs­ty­pen nach IIBA und → PMI

Die vier Anfor­de­rungs­ty­pen ste­hen in einer hier­ar­chi­schen Bezie­hung zuein­an­der: Die Busi­ness Requi­re­ments ste­hen über den Sta­ke­hol­der Requi­re­ments und die wie­der­um über den Solu­ti­on Requi­re­ments (Abbil­dung 2.2). Die Tran­si­ti­on Requi­re­ments die­nen dazu, die Umset­zung von Sta­ke­hol­der oder Solu­ti­on Requi­re­ments zu ermög­li­chen und sind somit nicht aus den ande­ren Requi­re­ments ableitbar.

Anforderungstypen hierarchisch nach IIBA und PMI, (C) Peterjohann Consulting, 2018-2022

Abbil­dung 2.2: Anfor­de­rungs­ty­pen (hier­ar­chisch) nach IIBA und PMI

Das IREB /IREB-20, IREB21/ unter­schei­det in fünf Anfor­de­rungs­ty­pen (ohne den Begriff “Typen” zu ver­wen­den). Als Refe­renz wird auf die ISO 29148:2018 (“Sys­tems and → soft­ware engi­nee­ring — Life cycle pro­ces­ses — Requi­re­ments engi­nee­ring”) ver­wie­sen. Als Beson­der­hei­ten gegen­über dem IIBA- und PMI-Modell kön­nen genannt werden: 

  • Neben den Sta­ke­hol­der Requi­re­ments kennt das IREB noch die User Requi­re­ments (Benut­zer­an­for­de­run­gen): Die­se beschrei­ben dedi­ziert die Sicht der Benutzer
  • Die Solu­ti­on Requi­re­ments des IIBA- und PMI-Modells wer­den zu Sys­tem Requi­re­ments bei IREB
  • Die Domä­nen­an­for­de­run­gen defi­nie­ren domä­nen­spe­zi­fi­sche Inhal­te — die­se Betrach­tungs­ebe­ne fehlt beim IIBA- und PMI-Modell
Anforderungstypen nach IREB, (C) Peterjohann Consulting, 2020-2022

Abbil­dung 2.3: Anfor­de­rungs­ty­pen nach IREB /IREB-20, IREB21/

Ebert /Ebert19/ ver­wen­det drei Stu­fen von Anfor­de­run­gen (Abbil­dung 2.4) und benennt den Über­gang von Pro­blem- zum Lösungsraum.

Im Ein­zel­nen:

  • Markt­an­for­de­run­gen benen­nen die Bedürf­nis­se / Anfor­de­run­gen, die sich aus dem Markt ergeben
  • Pro­dukt­an­for­de­run­gen lie­fern eine (ers­te) gro­be Sicht auf die Lösung
  • Kom­po­nen­ten­an­for­de­run­gen detail­lie­ren die Produktanforderungen
Anforderungsstufen nach Ebert, (C) Peterjohann Consulting, 2020-2022

Abbil­dung 2.4: Anfor­de­rungs­stu­fen nach Ebert /Ebert19/

Die­ses Modell mit nur drei Anfor­de­rungs­stu­fen ist für prak­ti­schen Ein­satz nicht aus­rei­chend, in der Regel wer­den über die RE-Tools meh­re­re Stu­fen erfasst.

3. Anforderungsarten

Das IREB /IREB21/ unter­teilt die Anfor­de­run­gen in die bei­den Arten …

  • Funk­tio­na­le und
  • Nicht-funk­tio­na­le Anfor­de­run­gen (Abbil­dung 3.1).
Anforderungsarten nach IREB, (C) Peterjohann Consulting, 2018-2022

Abbil­dung 3.1: Anfor­de­rungs­ar­ten nach IREB

Die funk­tio­na­len Anfor­de­run­gen beschrei­ben — grob gespro­chen — das, was umge­setzt wer­den muss. Die nicht-funk­tio­na­len Anfor­de­run­gen lie­fern Ein­schrän­kun­gen und Qua­li­täts­merk­ma­le. Die­se Ein­tei­lung ent­spricht den Sub­ka­te­go­rien des IIBA für Lösungs­an­for­de­run­gen. Die­se Ein­tei­lung wird häu­fig verwendet.

Übli­cher­wei­se wer­den alle Lösungs­an­for­de­run­gen an ein Pro­dukt oder Sys­tem (grob) in die Anfor­de­rungs­ar­ten funk­tio­na­le und nicht-funk­tio­na­le Anfor­de­run­gen unter­teilt. Das IREB geht einen Schritt wei­ter und unter­glie­dert die nicht-funk­tio­na­len Anfor­de­run­gen in Qua­li­täts­an­for­de­run­gen und Rand­be­din­gun­gen. Es ergibt sich fol­gen­des “gro­ßes Bild” /IREB21, Ebert19/:

Einteilung der Anforderungen, (C) Peterjohann Consulting, 2017-2022

Abbil­dung 3.2: Ein­tei­lung von Anforderungen

Wäh­rend die Qua­li­täts­an­for­de­run­gen übli­cher­wei­se wäh­rend der gesam­ten Pro­jekt­lauf­zeit sta­bil blei­ben, kön­nen die Rand­be­din­gun­gen sich ändern und müs­sen daher regel­mä­ßig über­prüft werden.

Die funk­tio­na­len Anfor­de­run­gen sind (ver­gleichs­wei­se) ein­fach zu beschrei­ben. Die Erfas­sung der nicht-funk­tio­na­len Anfor­de­run­gen berei­tet in der Pra­xis grö­ße­re Pro­ble­me, da sie nicht ein­fach zu ermit­teln sind und den­noch das Gesamt­sys­tem ent­schei­dend defi­nie­ren. Häu­fig gibt es aber vor­de­fi­nier­te Lis­ten zu den funk­tio­na­len Anfor­de­run­gen einer Domäne.

4. Weitere Einteilungen von Anforderungen

Anfor­de­run­gen kön­nen je nach Betrach­tungs­wei­se auch in ande­re Kate­go­rien ein­ge­teilt wer­den. Hier sind bei­spiels­wei­se zu nennen:

  • Impli­zi­te und expli­zi­te Anfor­de­run­gen: Wenn Anfor­de­run­gen genannt wer­den, so kann es sein, dass sie den­noch impli­zit vor­aus­ge­setzt wer­den. Für den → Requi­re­ments Engi­neer ist es wich­tig, neben den expli­zi­ten Anfor­de­run­gen auch die impli­zi­ten zu berück­sich­ti­gen. Hilf­reich ist hier­bei das → Kano-Modell, wel­ches auf die Basis­fak­to­ren und damit auf die impli­zi­ten Anfor­de­run­gen hinweist
  • Doku­men­tier­te und undo­ku­men­tier­te Anfor­de­run­gen: Nicht alle Anfor­de­run­gen wer­den in einem Anfor­de­rungs­vor­ha­ben doku­men­tiert; Ziel ist es jedoch, eine hohe Quo­te von doku­men­tier­ten Anfor­de­run­gen zu haben
  • Rele­van­te und nicht-rele­van­te Anfor­de­run­gen: Anfor­de­run­gen kön­nen für das jewei­li­ge → Vor­ha­ben rele­vant oder auch nicht-rele­vant sein. Nicht immer ist dies im Vor­feld oder bei der Erhe­bung zu bestim­men. Daher soll­te die Bestim­mung, ob eine ein­zel­ne Anfor­de­rung rele­vant ist oder nicht, bei einem sepa­ra­ten → Review erfolgen
  • Erfass­te und nicht-erfass­te Anfor­de­run­gen: Nicht-erfass­te Anfor­de­run­gen, die rele­vant sind, soll­te es in einem Requi­re­ments-Vor­ha­ben nicht geben. Erfass­te Anfor­de­run­gen (und auch nur die­se) bestim­men den Umfang des zu erstel­len­den Pro­dukts oder der zu erstel­len­den Dienstleistung

In Abbil­dung 4.1 sind eini­ge Unter­tei­lun­gen von Anfor­de­run­gen dargestellt.

 Weitere Unterteilungen von Anforderungen, (C) Peterjohann Consulting, 2018-2022

Abbil­dung 4.1: Wei­te­re Unter­tei­lun­gen von Anforderungen

Die Unter­tei­lun­gen in Abbil­dun­gen ver­deut­li­chen jeweils, dass nicht (immer) alle Anfor­de­run­gen in eine Anfor­de­rungs­spe­zi­fi­ka­ti­on auf­ge­nom­men werden.

A. Präsentationen, Literatur und Weblinks

Prä­sen­ta­tio­nen

  • -

Lite­ra­tur

  1. /BBG17‑d/ IIBA: BABOK v3: Leit­fa­den zur Busi­ness-Ana­ly­se BABOK Gui­de 3.0, Dr. Götz Schmidt, Wet­ten­berg 2017, ISBN 978–3‑945997–03‑1
  2. /Ebert19/ Chris­tof Ebert: Sys­te­ma­ti­sches Requi­re­ments Engi­nee­ring. Anfor­de­run­gen ermit­teln, doku­men­tie­ren, ana­ly­sie­ren und ver­wal­ten, dpunkt, Hei­del­berg 6. Auf­la­ge 2019, ISBN 978–3‑86490–562‑9
  3. /IREB21/ sie­he /Pohl21/
  4. /Jonasson19/ Hans Jonas­son: Deter­mi­ning Pro­ject Requi­re­ments. Mas­te­ring the BABOK and the CBAP Exam, CRC Press, Boca Raton, Flo­ri­da 2nd Edi­ti­on 2019, ISBN 978–1‑4987–6725‑5
  5. /Got02/ Ellen Got­tes­die­ner: Requi­re­ments by Col­la­bo­ra­ti­on, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2002, ISBN 978–0‑201–78606‑4
  6. /Hruschka19/ Peter Hrusch­ka: Busi­ness Ana­ly­sis und Requi­re­ments Engi­nee­ring: Pro­zes­se und Pro­duk­te nach­hal­tig ver­bes­sern, Han­ser, Mün­chen 2. Auf­la­ge 2019, ISBN 978–3‑446–45589‑4
  7. /PMG-BA17/ Pro­ject Manage­ment Insti­tu­te: The PMI Gui­de to Busi­ness Ana­ly­sis, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2017, ISBN 978–1‑62825–198‑2
  8. /Pohl21/ auch /IREB21/ Klaus Pohl, Chris Rupp: Basis­wis­sen Requi­re­ments Engi­nee­ring: Aus- und Wei­ter­bil­dung nach IREB-Stan­dard zum Cer­ti­fied Pro­fes­sio­nal for Requi­re­ments Engi­nee­ring Foun­da­ti­on Level, dpunkt, Hei­del­berg 5. Auf­la­ge 2021, ISBN 978–3‑86490–814‑9

Web­links

Legen­de zu den Weblinks
/ / Ver­weis auf eine Web­site (gene­rell)
/*/ Ver­weis auf eine Web­site, die als Buch-Ergän­zung dient
/#/ Ver­weis auf ein­zel­nes The­ma auf einer Website
/#V/ Ver­weis auf ein Video auf einer Website