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

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
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 beschrieben.

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 geliefert.

Das The­ma Sys­tem und Sys­tem­kon­text wird in die­sem Bei­trag als ein Teil­ge­biet des → Requi­re­ments Engi­nee­rings verstanden.

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 werden.

Das → IREB (Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board) defi­niert den Sys­tem­kon­text wie folgt /IREB21/:
“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 zu ent­wi­ckeln­den Sys­tems rele­vant ist.”

Das → IIBA ver­wen­det den ähn­li­chen Begriff “Abgren­zungs­mo­dell” und schreibt dazu /BBG17‑d/:
“Abgren­zungs­mo­dell (scope model): Modell, mit dem die Gren­zen eines Geschäfts­be­reichs oder einer Lösung bestimmt werden.”

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

Abbil­dung 1.1: Sys­tem und Systemkontext

Die in Abbil­dung 1.1 ver­wen­de­ten fünf Begrif­fe haben fol­gen­de Bedeutung:

  • Sys­tem: Dies ist der gestalt- oder ver­än­der­ba­re Teil der Realitä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 Aspekten
  • 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 bezeichnet
  • 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 Systemumgebung

Viel­fach wer­den der ein­fa­chen Dar­stel­lung noch Schnitt­stel­len hin­zu­fügt (gerich­te­te Pfei­le oder Lini­en mit Abschluss­punk­ten in Abbil­dung 1.2), die dann im wei­te­ren Ver­lauf einer Aus­ar­bei­tung benannt und kon­kre­ti­siert wer­den können.

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

Abbil­dung 1.2: Sys­tem und Sys­tem­kon­text mit Schnittstellendarstellung

Nicht immer sind die Gren­zen des Sys­tems ein­deu­tig zu bestim­men — es gibt Grau­zo­nen, bei denen nicht (von vorn­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 1.3 eingefügt.

System und Systemkontext mit Grauzonen, (C) Peterjohann Consulting, 2018-2024

Abbil­dung 1.3: Sys­tem und Sys­tem­kon­text mit Grauzonen

Es wird somit zwi­schen zwei Grau­zo­nen unterschieden:

  1. Sys­tem­grau­zo­ne: Dies ist der Bereich, bei dem nicht klar ist, ob die Ele­men­te zum Sys­tem oder zum Sys­tem­kon­text gehören
  2. Kon­text­grau­zo­ne: Dies ist der Bereich, bei dem nicht klar ist, ob die Ele­men­te zum Sys­tem­kon­text oder zur Umge­bung gehören

Anmer­kung:
Auf den Begriff “Sys­tem­um­ge­bung” soll­te zuguns­ten des Begriffs “Umge­bung” ver­zich­tet wer­den, um dies sprach­lich bes­ser unter­schei­den zu können.

Es kann im Sys­tem­kon­text-Dia­gramm der tech­ni­sche oder der orga­ni­sa­to­ri­sche Aspekt im Vor­der­grund ste­hen (Abbil­dung 1.4). In der Pra­xis soll­ten dafür zwei Sys­tem­kon­text-Dia­gram­me erstellt werden.

Systemkontext: Unterscheidung Technik und Organisation, (C) Peterjohann Consulting, 2021-2024

Abbil­dung 1.4: Sys­tem­kon­text: Unter­schei­dung Tech­nik und Organisation

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 beispielsweise:

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 dargestellt.

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

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

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

  • Was soll ent­wi­ckelt werden?
  • Was hat Ein­fluss auf die Entwicklung?
  • Was kann ver­nach­läs­sigt werden?

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­ge­lan­gen. Die Schnitt­stel­len wer­den — wie schon in Abbil­dung 1.2 — über gerich­te­te Pfei­le symbolisiert.

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

Abbil­dung 2.2: Sys­tem mit Schnittstellen

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 Ereignisse
  • Stake­hol­der / Personen
  • Doku­men­te (z.B. mit recht­li­chen Vorgaben)

Über­trägt man die­se poten­zi­el­len Quel­len auf die ein­fa­che Dar­stel­lung, so ergibt sich fol­gen­des Schnittstellendiagramm:

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

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

Die in Abbil­dung 2.3 ver­wen­de­ten Ele­men­te haben fol­gen­de Bedeutung:

Legende für Schnittstellen-Quellen, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 2.4: Legen­de für Schnitt­stel­len-Quel­len (nach /IREB21/)

Nimmt man als Bei­spiel einen Bewe­gungs­mel­der mit sei­nen Schnitt­stel­len, so kann dar­aus fol­gen­des Sys­tem­kon­text­dia­gramm resultieren:

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

Abbil­dung 2.5: Bei­spiel für ein ein­fa­ches Sys­tem­kon­text­dia­gramm: Bewegungsmelder

An die­sem ein­fa­chen Bei­spiel kann man 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 angegeben.

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 beispielsweise:

  • Erken­nen der Systemelemente
  • Mini­mie­ren der Schnittstellen

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 Ausgaben.”

In der Pra­xis kann die Bestim­mung und Beschrei­bung des Sys­tems und des Sys­tem­kon­texts in einem → Work­shop mit dem gesam­ten Team erfol­gen. Dabei wer­den die Sys­tem­ele­men­te auf ein­zel­nen Zet­teln notiert und gemein­sam den Kate­go­rien 1. Sys­tem, 2. Sys­tem­kon­text und 3. Umge­bung zugeordnet.

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 mit der Beschrei­bung (Ziel, → Visi­on, → Mis­si­on) des Vor­ha­bens oder — falls vor­han­den — mit dem → Pro­jekt­an­trag / ‑ver­trag abge­gli­chen wer­den. In einem zwei­ten Schritt kön­nen die Stake­hol­der (noch­mals) befragt werden.

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 erfolgen.

Dies sind beispielsweise:

  • Ellip­sen oder Kreise
  • Recht­ecke oder Quadrate
  • Wol­ken­for­men
  • Kon­text­dia­gram­me aus der Struk­tu­rier­ten Ana­ly­se (SA) nach Tom DeMarco
  • Use-Case-Dia­gram­me
  • Ande­re → UML-Dia­gram­me
  • Ande­re For­men der Darstellung

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

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

Abbil­dung 3.1: Sys­tem und Sys­tem­kon­text in ver­schie­de­nen Darstellungsformen

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­texts 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-2024

Abbil­dung 3.2: Ele­men­te eines Kontextdiagramms

“Spiel­re­geln” für das Kontextdiagramm:

  • Das Sys­tem wird als Black-Box dargestellt
  • 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 Verdeutlichung.

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

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

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

4. System, Gesamtsystem und Systemelement

Ein Sys­tem, wel­ches in einem RE-Vor­ha­ben betrach­tet wird, kann wie­der­um ein­ge­ord­net und unter­glie­dert wer­den: Es kann über­ge­ord­ne­te Gesamt­sys­te­me oder Sys­tem­ele­men­te geben (Abbil­dung 4.1).

System, Gesamtsystem und Systemelement, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 4.1: Sys­tem, Gesamt­sys­tem und Systemelement

5. Weitere Beispiele zur Verwendung des Systems und des Systemkontexts

In Abbil­dung 5.1 ist — als Bei­spiel für das Sys­tem / den Sys­tem­kon­text einer Dienst­leis­tung — der Umfang einer Schu­lung für das Requi­re­ments Engi­nee­ring angegeben.

Beispiel Systemkontext: Schulung Requirements Engieering, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 5.1: Bei­spiel Sys­tem­kon­text: Schu­lung “Requi­re­ments Engineering”

Anmer­kung:
In Abbil­dung 5.1 sind die Inhal­te mei­ner RE-Ein­füh­rungs­schu­lung dar­ge­stellt. Die­se Schu­lung kön­nen Sie bei mir buchen.

6. Die Verwendung des Systems und des Systemkontexts

Gene­rell soll­te die Beschrei­bung des Sys­tem­kon­texts im eige­nen RE-Vor­ha­ben wei­ter­ver­wen­det wer­den, denn alle dort gemach­ten Anga­ben müs­sen stim­men, ansons­ten ist der Scope / Umfang nicht rich­tig erfasst. 

6.1 Verwendung im Fachglossar

Alle im Sys­tem­kon­text ver­wen­de­ten Begrif­fe soll­ten im → Fachglos­sar auf­ge­führt wer­den. Daher bie­tet es sich an, das Fachglos­sar / → Glos­sar bei der Beschrei­bung des Sys­tem­kon­texts her­an­zu­zie­hen. Dabei gibt es fol­gen­de Möglichkeiten:

  • Falls ein Fachglos­sar bereits vor­liegt, so soll­ten “alle wesent­li­chen” Begrif­fe aus dem Glos­sar auch im Sys­tem­kon­text ver­wen­det werden
  • Falls ein Fachglos­sar noch auf­ge­baut wer­den muss, so kann es bei der Erstel­lung des Sys­tem­kon­texts initi­al befüllt werden

Soll­ten (wesent­li­che) Ände­run­gen am Glos­sar vor­ge­nom­men wer­den, so soll­te der Sys­tem­kon­text / die Sys­tem­kon­text­be­schrei­bung über­prüft und ggf. ange­passt werden.

6.2 Satzschablonen

Durch die Beschrei­bung des Sys­tems und des Sys­tem­kon­texts wird fest­ge­legt, was im RE-Vor­ha­ben erfasst wer­den soll. Mit Hil­fe von → Satz­scha­blo­nen /Rupp20/ kön­nen dann Ein­zel­an­for­de­run­gen benannt wer­den. Hier­zu wird der Sys­tem- oder Sub­sys­tem­na­me her­an­ge­zo­gen und dar­aus eine Ein­zel­an­for­de­rung abge­lei­tet (Abbil­dung 6.1).

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

Abbil­dung 6.1: Die → Satz­scha­blo­ne ohne Bedingung

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 benennen
  2. Recht­li­che → Ver­bind­lich­keit (auch: Ver­bind­lich­keit oder Wich­tig­keit) festlegen
  3. Funk­tio­na­li­tät identifizieren
  4. Art der Funk­tio­na­li­tät bestimmen
  5. Objekt iden­ti­fi­zie­ren

6.3 Übergang zum Systems Engineering und zur Projektplanung

Wenn eine tech­ni­sche und eine orga­ni­sa­to­ri­sche Sys­tem­be­schrei­bung vor­liegt, so kann damit (Abbil­dung 6.2) …

  • die Sys­tem­mo­del­lie­rung (bei­spiels­wei­se mit der UML oder SysML) begon­nen und 
  • und die ers­te Grob­pla­nung für ein Pro­jekt gestar­tet werden.
Systemkontext: Verwendung beim Systems Engineering und bei der Projektplanung, (C) Peterjohann Consulting, 2021-2024

Abbil­dung 6.2: Sys­tem­kon­text: Ver­wen­dung beim → Sys­tems Engi­nee­ring und bei der → Pro­jekt­pla­nung

7. 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 Stake­hol­der anhand der Beschrei­bung von Sys­tem und Sys­tem­kon­text erken­nen kön­nen, was gemacht wer­den soll.

8. 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 wiedergegeben.

  • 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, sodass even­tu­ell nach­ge­bes­sert wer­den muss.
  • 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. Ein Kon­text­dia­gramm leis­tet dies im Allgemeinen.
  • 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 Stake­hol­dern ohne­hin nur das betrach­tet wird, was “im Sys­tem­kon­text” liegt. Mei­ne Emp­feh­lung ist jedoch, den Sys­tem­kon­text sehr früh­zei­tig (“Sprint Null”) mit allen Team­mit­glie­dern zu ent­wi­ckeln, um so ein gemein­sa­mes Ver­ständ­nis für das “gro­ße Gan­ze” zu gewinnen.

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 beschrieben.

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

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

  • /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
  • /IREB21/ sie­he /Pohl21/
  • /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
  • /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

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

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