Use Case Wesentlich für die Erfassung von Anforderungen

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Ein Use Case (deutsch Anwen­dungs­fall) beschreibt mit weni­gen Ele­men­ten eine gro­be Sicht auf Sys­te­me im Requi­re­ments und → Soft­ware Engi­nee­ring.
Es wer­den in die­sem Bei­trag die Use Cases beschrieben.

Use Cases sind ein “→ Stan­dard”-Dia­gramm­typ der → UML / → Uni­fied Mode­ling Lan­guage, wel­ches sehr häu­fig ein­ge­setzt wer­den kann. Da es nur weni­ge Ele­men­te auf­weist, kann es ein­fach und schnell ein­ge­setzt werden.

Der Ein­satz der Use Cases wird häu­fig in den Beschrei­bun­gen zum → Requi­re­ments Engi­nee­ring erläutert.

1. Einleitung und Grundlagen

Gene­rell besteht ein Use Case-Modell aus meh­re­ren Use-Case-Spe­zi­fi­ka­tio­nen und meh­re­ren Use-Case-Dia­gram­men (Abbil­dung 1.1).

Die Bestandteile eines Use-Case-Modells, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 1.1: Die Bestand­tei­le eines Use-Case-Modells

1.1 Definitionen

Die deut­sche Wiki­pe­dia unter­schei­det zwi­schen Anwen­dungs­fall, Anwen­dungs­fall in der UML und Anwen­dungs­fall-Dia­gramm (in der UML) und lie­fert ent­spre­chend drei Definitionen.

Zum Anwen­dungs­fall steht in der Wiki­pe­dia /#Wiki-Use-Case/:
“Ein Anwen­dungs­fall (engl. use case) bün­delt alle mög­li­chen Sze­na­ri­en, die ein­tre­ten kön­nen, wenn ein Akteur ver­sucht, mit Hil­fe des betrach­te­ten Sys­tems ein bestimm­tes fach­li­ches Ziel (engl. busi­ness goal) zu errei­chen. Er beschreibt, was inhalt­lich beim Ver­such der Ziel­er­rei­chung pas­sie­ren kann und abs­tra­hiert von kon­kre­ten tech­ni­schen Lösun­gen. Das Ergeb­nis des Anwen­dungs­falls kann ein Erfolg oder Fehlschlag/Abbruch sein.”

Zum Anwen­dungs­fall in der UML wird aus­ge­führt /#Wiki-Use-Case-UML/:
“Ein Anwen­dungs­fall (engl. use case) ist ein Modell­ele­ment in der Uni­fied Mode­ling Lan­guage (UML), einer Model­lie­rungs­spra­che für Soft­ware und ande­re Systeme.”

Das Anwen­dungs­fall­dia­gramm (der UML) wird wie folgt beschrie­ben /#Wiki-Use-Case-Diagramm/:
“Ein Anwen­dungs­fall­dia­gramm (engl. use case dia­gram), auch Nutz­fall­dia­gramm, ist eine der Dia­gramm­ar­ten der Uni­fied Mode­ling Lan­guage (UML), einer Spra­che für die Model­lie­rung der Struk­tu­ren und des Ver­hal­tens von Soft­ware- und ande­ren Sys­te­men. Es stellt Anwen­dungs­fäl­le und Akteu­re mit ihren jewei­li­gen Abhän­gig­kei­ten und Bezie­hun­gen dar.”

Das → IIBA /BBG17‑d/ benennt den Zweck von Use Cases und Sze­na­ri­en:
“Use Cases und Sze­na­ri­en beschrei­ben, wie eine Per­son oder ein Sys­tem mit der model­lier­ten Lösung inter­agiert, um ein Ziel zu erreichen.”

Das IIBA /BBG17‑d/ schreibt zum Use-Case-Dia­gramm:
“Use-Case-Dia­gramm (use case dia­gram): Gra­fi­sche Dar­stel­lung aus der UML (Uni­fied Mode­ling Lan­guage) zur Abbil­dung aller Akteu­re und Use Cases eines bestimm­ten Sys­tems oder Produkts.”

1.2 Abgrenzung zu anderen Diagrammtypen der UML

Use Cases sind auf­grund der Beschrän­kung auf nur weni­ge Ele­men­te beson­ders ein­fach ein­setz­bar. Sie bil­den häu­fig den Ein­stiegs­punkt bei der Model­lie­rung von Systemen.

1.3 Use-Case-Arten

Gene­rell kann zwi­schen zwei Arten von Use Cases unter­schie­den wer­den: Zum einen die, die die Sicht­wei­se des Busi­ness und zum ande­ren die, die die Sicht­wei­se des Pro­dukts wiedergegeben.

Arten von Use Cases, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 1.2: Arten von Use Cases

2. Die Elemente der Use-Case-Diagramme

Use-Case-Dia­gram­me kön­nen fol­gen­de Ele­men­te enthalten:

  • Akteur: Dies sind die han­deln­de Per­son oder die han­deln­de Ein­heit (Teil- oder Fremdsystem)
  • Sys­tem: Das zu betrach­ten­de System
  • Use Case: Der Anwendungsfall
  • Die (ein­fa­che) Beziehung
  • Erwei­te­rung (eines Use Cases)
  • Inklu­die­rung (eines Use Cases)
Die Notationselemente für Use-Case-Diagramme, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 2.1: Die Nota­ti­ons­ele­men­te für Use-Case-Diagramme

Wei­te­re Ele­men­te gibt es in der Dar­stel­lung für die UML nicht.

3. Use Cases im Einsatz

Ein ein­fa­ches Bei­spiel eines Use-Case-Modells ist in Abbil­dung 3.1 dar­ge­stellt. Es geht um die Down­load­be­reich die­ser Web­site. Dort wer­den für den Web­site-Besu­cher die ein­zel­nen → Prä­sen­ta­tio­nen auf­ge­lis­tet (ers­ter Use Case) und die Prä­sen­ta­tio­nen kön­nen ange­se­hen wer­den (zwei­ter Use Case).

Ein einfaches Beispiel eines Use-Case-Modells, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 3.1: Ein ein­fa­ches Bei­spiel eines Use-Case-Modells

Aus den Use Cases las­sen sich dann (ein­fach) auch die Ele­men­te des Glos­sars ablei­ten: Dies sind die Sub­jek­te und Ver­ben der Use Cases, also in die­sem Fall “Prä­sen­ta­tio­nen, auf­lis­ten, anse­hen und herunterladen”.

3.1 Varianten der Use Cases

Es gibt Vari­an­ten von Use Cases, die spe­zi­el­le Fäl­le betrach­ten.
Bei­spie­le:

  • Abu­se Cases: Betrach­ten die (gezielt) fal­sche Anwen­dung eines Sys­tems oder einer Kom­po­nen­te, so bei­spiels­wei­se, wenn eine Schnitt­stel­le genutzt wird, um ein Sys­tem zu para­me­trie­ren, obwohl die Schnitt­stel­le dafür nicht vor­ge­se­hen ist
  • Con­fu­se Cases: Beschrei­ben das Ver­hal­ten eines Sys­tems bei feh­ler­haf­ter Eingabe
  • Misu­se Cases: Betrach­ten / Unter­su­chen die (geziel­ten) Miss­brauchs­sze­na­ri­en eines Sys­tems oder einer Kom­po­nen­te, so bei­spiels­wei­se, was pas­siert, wenn man bewusst Daten in ein Sys­tem gibt, um die­ses zu hacken

Anmer­kung:
Der → Busi­ness Case (Geschäfts­fall) ist kein Use Case, son­dern bewer­tet ein zu erstel­len­des Sys­tem wirtschaftlich.

4. Generelle Regeln im Umgang mit Use Cases

Auch wenn es für die Ver­wen­dung von Use Cases kei­ne Vor­ga­ben gibt, so emp­fiehlt es sich, eini­ge Grund­re­geln zu beach­ten. Die­se sind beispielsweise:

  • Ver­su­chen Sie, die Use-Case-Dar­stel­lun­gen ein­fach zu gestal­ten, ins­be­son­de­re, indem Sie die Anzahl der Ele­men­te (Use Cases) beschränken
  • Nut­zen Sie für die Beschrei­bung ent­we­der die Use-Case-Spe­zi­fi­ka­tio­nen oder die Use-Case-Dia­gram­me, aber nicht beides
  • Hrusch­ka /Hruschka19/ emp­fiehlt, Include-Bezie­hun­gen nur für mehr­fach genutz­te Use Cases zu verwenden

5. Häufig gestellte Fragen und Antworten (FAQ) zu den Use Cases

Eini­ge Fra­gen zu den Use Cases wer­den häu­fig gestellt – die­se wer­den hier wiedergegeben.

  • F: Kann man die Use Cases auch für die Kom­mu­ni­ka­ti­on mit Nicht-ITlern (Fach­be­rei­che) ver­wen­den?
    A: Gene­rell sind Use Cases “ein­fach” zu lesen und zu ver­ste­hen. Den­noch kann nicht davon aus­ge­gan­gen wer­den, dass alle Fach­be­reichs­mit­ar­bei­ter Use Cases verstehen.
  • F: Wenn man → Requi­re­ments Engi­nee­ring ernst­haft betrei­ben möch­te: Muss man dazu Use Cases ken­nen?
    A: Ja. Das Use-Case-Dia­gramm soll­te man auf jeden Fall kennen.
  • F: Kön­nen Use Cases in einem Pro­jekt wei­ter­ver­wen­det / mehr­fach genutzt wer­den?
    A: Ja. Auf der Basis von Use Cases kön­nen Test Cases ent­wi­ckelt werden.

Haben Sie noch wei­te­re Fra­gen oder möch­ten Sie Ergän­zun­gen an der FAQ vor­neh­men? Am bes­ten schrei­ben Sie mir hier­zu eine E‑Mail an: kontakt@peterjohann-consulting.de.

A. Präsentationen, Literatur und Weblinks

Use Cases wer­den in mei­ner Prä­sen­ta­ti­on zum Requi­re­ments Engi­nee­ring kurz erwähnt.

Inhalt Typ
Requi­re­ments Engi­nee­ring (und Busi­ness Ana­ly­sis) – Eine Ein­füh­rung (RE-Basis­prä­sen­ta­ti­on)
pdf

Use Cases wer­den in der Regel in den Wer­ken zur UML beschrie­ben / behan­delt. Eigen­stän­di­ge Bücher zu den Use Cases gibt es kaum. Die­se Bücher beschrei­ben (in Tei­len) die UML und die SysML oder deren Ver­wen­dung im RE-Kontext:

  1. /BBG15/ IIBA: A Gui­de to the → Busi­ness Ana­ly­sis Body of Know­ledge (BABOK Gui­de), Inter­na­tio­nal Insti­tu­te of Busi­ness Ana­ly­sis, Mari­et­ta, Geor­gia 3rd Edi­ti­on 2015, ISBN 978–1‑927584–02‑6
  2. /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
  3. /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
  4. /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
  5. /IREB21/ sie­he /Pohl21/
  6. /Kecher17/ Chris­toph Kecher, Alex­an­der Sal­va­nos, Ralf Hoff­mann-Elbern: UML 2.5: Das umfas­sen­de Hand­buch, Rhein­werk, Bonn 6. Auf­la­ge 2017, ISBN 978–3‑8362–6018‑3
  7. /Oestereich13/ Bernd Oes­te­reich, Axel Scheit­hau­er: Ana­ly­se und Design mit der UML 2.5. Objekt­ori­en­tier­te → Soft­ware­ent­wick­lung, De Gruy­ter Olden­bourg, Mün­chen 11. Auf­la­ge 2013, ISBN 978–3‑486–72140‑9
  8. /Oestereich21/ Bernd Oes­te­reich, Axel Scheit­hau­er: Ana­ly­se und Design mit der UML 2.5.1. Objekt­ori­en­tier­te Soft­ware­ent­wick­lung, De Gruy­ter Olden­bourg, Mün­chen 12. Auf­la­ge 2021, ISBN 978–3‑11–062621‑6
  9. /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
  10. /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
  11. /Rupp12/ Chris Rupp, Ste­fan Queins: UML 2 glas­klar. Pra­xis­wis­sen für die UML-Model­lie­rung, Han­ser, Mün­chen 4. Auf­la­ge 2012, ISBN 978–3‑446–43057‑0
  12. /Rupp20/ Chris Rupp: Requi­re­ments-Engi­nee­ring und ‑Manage­ment. Das Hand­buch für Anfor­de­run­gen in jeder Situa­ti­on, Han­ser, Mün­chen 7. Auf­la­ge 2020, ISBN 978–3‑446–45587‑0
  13. /Weilkiens14/ Tim Weil­ki­ens: → Sys­tems Engi­nee­ring mit SysML/UML. Anfor­de­run­gen, Ana­ly­se, Archi­tek­tur, dpunkt, Hei­del­berg, 3. Auf­la­ge 2014, ISBN 978–3‑86490–091‑4

Fol­gen­de Web­links lie­fern wei­te­re Infor­ma­tio­nen zur UML (und zur SysML):

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

Letz­te Aktua­li­sie­rung: 26.04.2021 © Peter­jo­hann Con­sul­ting, 2005–2024

Ähnliche Beiträge