System und Systemkontext Die Beschreibung, was dazugehört und was nicht

Um zu bestim­men, wel­che The­men und Inhal­te in einem Pro­jekt oder einem Requi­re­ments-Engi­nee­ring-Vor­ha­ben betrach­tet wer­den sol­len, soll­te unbe­dingt eine Bestim­mung des Sys­tems und Sys­tem­kon­texts erfol­gen. In die­sem Bei­trag wird eine Über­sicht zum The­ma “Sys­tem und Sys­tem­kon­text” oder auch “Scope Manage­ment” mit ver­schie­de­nen Blick­win­keln gelie­fert.

Manage­ment-Zusam­men­fas­sung zu die­sem Bei­trag:
Das Sys­tem und der Sys­tem­kon­text wer­den zu Beginn eines Vor­ha­bens bestimmt, um abzu­gren­zen, wel­che Inhal­te und The­men in der nach­fol­gen­den Ermitt­lung von Anfor­de­run­gen betrach­tet wer­den sol­len und wel­che nicht.
In die­sem Bei­trag wird der Scope / das Sys­tem und der Sys­tem­kon­text und deren Ein­satz im Requi­re­ments Engi­nee­ring beschrie­ben.

Das The­ma Sys­tem und Sys­tem­kon­text ist ein Teil­ge­biet des Requi­re­ments Engi­nee­rings (RE), wel­ches
hier beschrie­ben wird.


1. Einleitung und Grundlagen

Anfor­de­run­gen die­nen zur Beschrei­bung eines Sys­tems, wel­ches durch einen Kon­text und eine Umge­bung ent­spre­chen­de Gren­zen besitzt. Nur für das Sys­tem rele­van­te Tei­le müs­sen detail­liert erfasst und beschrie­ben wer­den.

Das IREB (Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board) defi­niert den Sys­tem­kon­text wie folgt /IREB15/:
“Der Sys­tem­kon­text ist der Teil der Umge­bung eines Sys­tems, der für die Defi­ni­ti­on und das Ver­ständ­nis der Anfor­de­run­gen des Sys­tems ver­ant­wort­lich ist.”

System und Systemkontext, (C) Peterjohann Consulting, 2018-2020

Abbil­dung 1.1: Sys­tem und Sys­tem­kon­text

Die Begrif­fe haben fol­gen­de Bedeu­tung:

  • Sys­tem: Dies ist der gestalt- oder ver­än­der­ba­re Teil der Rea­li­tät
  • Sys­tem­gren­ze: Die Sys­tem­gren­ze trennt den gestalt­ba­ren und ver­än­der­ba­ren Teil der Rea­li­tät („das Sys­tem“) von den nicht ver­än­der­ba­ren Aspek­ten
  • Sys­tem­kon­text: Der Teil der Umge­bung des Sys­tems, der für die Defi­ni­ti­on und das Ver­ständ­nis der Sys­tem­an­for­de­run­gen rele­vant ist, selbst aber nicht gestalt- oder ver­än­der­bar ist, wird als Sys­tem­kon­text bezeich­net
  • Kon­text­gren­ze: Die Kon­text­gren­ze grenzt den rele­van­ten vom irrele­van­ten Teil der Sys­tem­um­ge­bung ab
  • Umge­bung: Für Anfor­de­run­gen irrele­van­ter Teil der Sys­tem­um­ge­bung

Statt Sys­tem wird häu­fig auch der Begriff Scope (of Pro­duct) oder Pro­dukt­um­fang ver­wen­det, statt Sys­tem­kon­text fin­det man auch Scope of Work oder Arbeits­be­reichs­um­fang.

Viel­fach wer­den der ein­fa­chen Dar­stel­lung noch Schnitt­stel­len hin­zu­fügt (Abbil­dung 1.2), die dann im wei­te­ren Ver­lauf benannt wer­den.

System und Systemkontext mit Schnittstellendarstellung, (C) Peterjohann Consulting, 2018-2020

Abbil­dung 1.2: Sys­tem und Sys­tem­kon­text mit Schnitt­stel­len­dar­stel­lung

Nicht immer sind die Gren­zen des Sys­tems ein­deu­tig zu bestim­men — es gibt Grau­zo­nen, bei denen nicht (von vor­ne­her­ein) klar ist, ob sie zum Sys­tem oder Sys­tem­kon­text gehö­ren. Die­se Grau­zo­nen sind in der nach­fol­gen­den Abbil­dung ein­ge­fügt.
System und Systemkontext mit Grauzonen, (C) Peterjohann Consulting, 2018-2020

Abbil­dung 1.3: Sys­tem und Sys­tem­kon­text mit Grau­zo­nen


2. Die Bestimmung des Systems und des Systemkontexts

Zur Bestim­mung des Sys­tems und der Sys­tem­gren­zen kön­nen ver­schie­de­ne Quel­len her­an­ge­zo­gen wer­den.
Dies sind bei­spiels­wei­se:

  • Alt­sys­te­me
  • Stakeholder(befragungen)
  • Pro­zes­se und Geschäfts­pro­zes­se
  • Ereig­nis­se
  • Doku­men­ta­tio­nen

Gene­rell soll­te das Sys­tem und der Sys­tem­kon­text mög­lichst früh­zei­tig, d.h.vor der Ermitt­lung der Anfor­de­run­gen, bestimmt wer­den. Dies ist aber nicht immer mög­lich, viel­fach erge­ben sich Sys­tem und Sys­tem­kon­text erst bei der Aus­ar­bei­tung oder der Umset­zung der Anfor­de­run­gen. Eine (mög­li­che) zeit­li­che Ein­ord­nung der Bestim­mung des Sys­tems und des Sys­tem­kon­texts ist in Abbil­dung 2.1 dar­ge­stellt.

System und Systemkontext bestimmen - zeitliche Einordnung, (C) Peterjohann Consulting, 2018-2020

Abbil­dung 2.1: Sys­tem und Sys­tem­kon­text bestim­men — zeit­li­che Ein­ord­nung

Nach /#microTOOL-Systemkontext-15/ beant­wor­tet die Abgren­zung des Sys­tem­kon­texts drei ent­schei­den­de Fra­gen:

  • Was soll ent­wi­ckelt wer­den?
  • Was hat Ein­fluss auf die Ent­wick­lung?
  • Was kann ver­nach­läs­sigt wer­den?

2.1 Schrittweises Vorgehen

Gene­rell kann zunächst das Sys­tem mit sei­nen Schnitt­stel­len benannt wer­den, wobei an Schnitt­stel­len immer Daten “über­ge­ben wer­den”, d.h. in das Sys­tem hin­ein oder aus dem Sys­tem her­aus gelan­gen.

System mit Schnittstellen, (C) Peterjohann Consulting, 2019-2020

Abbil­dung 2.2: Sys­tem mit Schnitt­stel­len

Typi­sche Quel­len für Schnitt­stel­len sind “Nach­bar­sys­te­me” — die­se kön­nen sein:

  • Soft­ware­sys­te­me
  • Hard­ware­sys­te­me
  • Geschäfts­pro­zes­se
  • Sons­ti­ge Pro­zes­se und Ereig­nis­se
  • Per­so­nen / Sta­ke­hol­der
  • Doku­men­te (z.B. mit recht­li­chen Vor­ga­ben)

Trägt man die­se Quel­len auf die ein­fa­che Dar­stel­lung, so ergibt sich fol­gen­des Schnitt­stel­len­dia­gramm:

System mit möglichen Quellen für Schnittstellen (nach /IREB15/), (C) Peterjohann Consulting, 2019-2020

Abbil­dung 2.3: Sys­tem mit mög­li­chen Quel­len für Schnitt­stel­len (nach /IREB15/)

Trägt man die­se Quel­len in die ein­fa­che Dar­stel­lung ein, so ergibt sich fol­gen­des Schnitt­stel­len­dia­gramm:

Beispiel für ein einfaches Systemkontextdiagramm: Bewegungsmelder, (C) Peterjohann Consulting, 2019-2020

Abbil­dung 2.4: Bei­spiel für ein ein­fa­ches Sys­tem­kon­text­dia­gramm: Bewe­gungs­mel­der

An die­sem ein­fa­chen Bei­spiel kann bereits sehr schnell erken­nen, dass die­ser Bewe­gungs­mel­der über einen inte­grier­ten Sen­sor ver­fügt, denn er wird nicht expli­zit im Sys­tem­kon­text ange­ge­ben.

2.2 Prinzipien bei der Bestimmung des Systems und des Systemkontexts

Es soll­ten bei der Bestim­mung des Sys­tems und des Sys­tem­kon­texts immer eini­ge Prin­zi­pi­en beach­tet wer­den. Die­se sind bei­spiels­wei­se:

  • Erken­nen der Sys­tem­ele­men­te
  • Mini­mie­rung der Schnitt­stel­len

Wie­vie­le Ele­men­te (Nach­bar­sys­te­me und Schnitt­stel­len) soll­ten bestimmt wer­den? In der Regel soll­ten etwa 5 bis 100 Ele­men­te erfasst wer­den. Hrusch­ka /Hruschka19/ schreibt dazu: “Das aller­größ­te, was wir jemals gezeich­net haben, war ein Sys­tem mit 150 Nach­bar­sys­te­men und 400 Ein­- und Aus­ga­ben.”

2.3 Zur Überprüfung des bestimmten Systems und des Systemkontexts

Ist das Sys­tem und der Sys­tem­kon­text bestimmt, so stellt sich die Fra­ge, ob es “gut und rich­tig” ist — eine Über­prü­fung soll­te die­se Fra­ge beant­wor­ten. In einem ers­ten Schritt soll­te der Sys­tem­kon­text gegen die Beschrei­bung des Vor­ha­bens oder — falls vor­han­den — gegen den Pro­jekt­an­trag / ‑ver­trag abge­gli­chen wer­den. In einem zwei­ten Schritt kön­nen die Sta­ke­hol­der (noch­mals) befragt wer­den.


3. Die Darstellung des Systems und des Systemkontexts

Die Beschrei­bung kann tex­tu­ell, über ver­schie­de­ne gra­fi­sche For­men oder spe­zi­el­le Dar­stel­lun­gen erfol­gen.

Dies sind bei­spiels­wei­se:

  • Ellip­sen oder Krei­se
  • Recht­ecke oder Qua­dra­te
  • Wol­ken­for­men
  • Kon­text­dia­gram­me aus der Struk­tu­rier­ten Ana­ly­se (SA) nach Tom deMar­co
  • Use-Case-Dia­gram­me
  • Ande­re UML-Dia­gram­me
  • Ande­re For­men der Dar­stel­lung

In Abbil­dung 3.1 sind drei ein­fa­che gra­fi­sche For­men gegen­über­ge­stellt; die­se sind gleich­wer­tig.

System und Systemkontext in verschiedenen Darstellungsformen, (C) Peterjohann Consulting, 2018-2020

Abbil­dung 3.1: Sys­tem und Sys­tem­kon­text in ver­schie­de­nen Dar­stel­lungs­for­men

3.1 Das Kontextdiagramm

Häu­fig wird ein Kon­text­dia­gramm zur Beschrei­bung des Sys­tems und Sys­tem­kon­texts ver­wen­det. Das Kon­text­dia­gramm ist das Daten­fluss­dia­gramm aus der Struk­tu­rier­ten Ana­ly­se (SA) nach Tom deMar­co aus den 1970er Jah­ren /#Wiki-Kontextdiagramm/, wel­ches auf­grund sei­ner Ein­fach­heit zur Dar­stel­lung des Sys­tems und des Sys­tem­kon­tex­tes häu­fig her­an­ge­zo­gen wird.

Dabei wird das zen­tra­le Sys­tem als Kreis in den Mit­tel­punkt gestellt und die direkt umge­ben­den Nach­bar­sys­te­me (aus dem Sys­tem­kon­text) als Recht­ecke. Zwi­schen den die­sen bei­den Ele­men­ten wer­den beschrif­te­te gerich­te­te Pfei­le zur Visua­li­sie­rung des Daten­flus­ses ein­ge­setzt (sie­he Abbil­dung 3.2).

Elemente eines Kontextdiagramms, (C) Peterjohann Consulting, 2019-2020

Abbil­dung 3.2: Ele­men­te eines Kon­text­dia­gramms

“Spiel­re­geln” für das Kon­text­dia­gramm:

  • Das Sys­tem wird als Black­box dar­ge­stellt
  • Alle Nach­bar­sys­te­me wer­den benannt
  • Alle Schnitt­stel­len zu den Nach­bar­sys­te­men wer­den als gerich­te­te Pfei­le ein­ge­tra­gen und benannt

Die Far­ben haben kei­ne Bedeu­tung und die­nen hier nur der Ver­deut­li­chung.

In Abbil­dung 3.3 ist für ein Buch­be­stell­sys­tem ein Kon­text­dia­gramm ange­ge­ben.

Beispiel eines Kontextdiagramms nach /Hruschka19/, (C) Peterjohann Consulting, 2019-2020

Abbil­dung 3.3: Bei­spiel eines Kon­text­dia­gramms nach /Hruschka19/


4. Die Verwendung des Systems und des Systemkontexts

Durch die Beschrei­bung des Sys­tems und des Sys­tem­kon­tex­tes wird fest­ge­legt, was zum im RE-Vor­ha­ben erfasst wer­den soll. Mit­hil­fe von Satz­scha­blo­nen /Rupp14/ kön­nen dann Ein­zel­an­for­de­run­gen benannt wer­den.

Die Satzschablone ohne Bedingung, (C) Peterjohann Consulting, 2018-2020

Abbil­dung 4.1: Die Satz­scha­blo­ne ohne Bedin­gung

Die For­mu­lie­rung der ein­zel­nen Anfor­de­run­gen geschieht dann in sepa­ra­ten Schrit­ten, wobei der ers­te Schritt immer die Benen­nung des betrach­te­ten Teil­sys­tems umfasst.
Die­se sind:

  1. Sys­tem benen­nen
  2. Recht­li­che Ver­bind­lich­keit (auch: Ver­bind­lich­keit oder Wich­tig­keit) fest­le­gen
  3. Funk­tio­na­li­tät iden­ti­fi­zie­ren
  4. Art der Funk­tio­na­li­tät bestim­men
  5. Objekt iden­ti­fi­zie­ren

5. Stärken und Schwächen der Beschreibung von System und Systemkontext

Da das Sys­tem und der Sys­tem­kon­text in jedem RE-Vor­ha­ben beschrie­ben wer­den muss, stellt sich die Fra­ge nach “Stär­ken und Schwä­chen” nur indi­rekt. Gene­rell soll­ten die Sta­ke­hol­der anhand der Beschrei­bung von Sys­tem und Sys­tem­kon­text erken­nen kön­nen, was gemacht wer­den soll.


6. Häufige Fragen und Antworten zum Thema “System und Systemkontext”

Eini­ge Fra­gen zu dem Sys­tem und Sys­tem­kon­text wer­den häu­fig gestellt – die­se wer­den hier wie­der­ge­ge­ben.

  • F: Muss ich vor Beginn der Ermitt­lungs­tä­tig­kei­ten den Sys­tem­kon­text bestim­men?
    A: Ja. Dies ist sinn­voll. Lei­der ist häu­fig der Sys­tem­kon­text zu einem frü­hen Zeit­punkt nicht voll­stän­dig bestimm­bar.
  • F: Wel­ches Dia­gramm ist zur Dar­stel­lung des Sys­tem­kon­texts am bes­ten geeig­net?
    A: Im Zwei­fel das­je­ni­ge, das “von allen” ver­stan­den wird.
  • F: Muss bei agi­ler Vor­ge­hens­wei­se (Agi­les RE) der Sys­tem­kon­text bestimmt wer­den?
    A: Nein — nicht unbe­dingt, da durch die Kom­mu­ni­ka­ti­on mit den Sta­ke­hol­dern ohne­hin nur das betrach­tet wird, was “im Sys­tem­kon­text” liegt.

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

Das Sys­tem und der Sys­tem­kon­text wird (kurz) in der Prä­sen­ta­ti­on zum Requi­re­ments Engi­nee­ring beschrie­ben. Eine sepa­ra­te Aus­ar­bei­tung im pdf-For­mat ist auf Anfra­ge ver­füg­bar.

InhaltVer­si­onStandSei­tenGrö­ßeTyp
Requi­re­ments Engi­nee­ring (und Busi­ness Ana­ly­sis) – Eine Ein­füh­rung (RE-Basis­prä­sen­ta­ti­on)0.9603/20172481,3 MB pdf (pdf)

In fol­gen­den Büchern wer­den als Teil­aspekt das Sys­tem und der Sys­tem­kon­text erläu­tert:

  • /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
  • /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
  • /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
  • /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
  • /IREB15/ sie­he /Pohl15a/
  • /Pohl15a/ 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 4. Auf­la­ge 2015, ISBN 978–3‑89864–771‑7
  • /Pohl15b/ Klaus Pohl, Chris Rupp: Requi­re­ments Engi­nee­ring Fun­da­men­tals: A Stu­dy Gui­de for the Cer­ti­fied Pro­fes­sio­nal for Requi­re­ments Engi­nee­ring Exam – Foun­da­ti­on Level – IREB com­pli­ant, Rocky Nook, San­ta Bar­ba­ra, Cali­for­nia 2nd Edi­ti­on 2015, ISBN 978–1‑937538–77‑4
  • /Rupp14/ Chris Rupp: Requi­re­ments-Engi­nee­ring und ‑Manage­ment. Aus der Pra­xis von klas­sisch bis agil, Han­ser, Mün­chen 6. Auf­la­ge 2014, ISBN 978–3‑446–43893‑4

Auf fol­gen­de Web­links (zu dem Sys­tem und Sys­tem­kon­text) wird hier Bezug genom­men:

Legen­de zu den Web­links
/ / 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 Web­site
/#V/ Ver­weis auf ein Video auf einer Web­site


Scroll to Top