header-image

Requirements Engineering Anforderungen entwickeln und verwalten

Arbeitsbereiche Peterjohann Consulting, (C) Peterjohann Consulting, 2017-2019

Das Requi­re­ments Engi­nee­ring (RE) stellt eine eigen­stän­di­ge Dis­zi­plin inner­halb des Sys­tems Engi­nee­rings oder des Soft­ware Engi­nee­rings dar. Das RE setzt sich damit aus­ein­an­der, wie Anfor­de­run­gen an ein (neu zu erstel­len­des) Pro­dukt, eine Dienst­leis­tung oder ein Sys­tem zu ent­wi­ckeln und zu ver­wal­ten sind, um eine mög­lichst effi­zi­en­te Umset­zung zu ermög­li­chen. Das RE ist aber kei­ne exak­te Dis­zi­plin mit genau­en Vor­ge­hens­wei­sen, son­dern ange­rei­chert mit vie­len Ide­en und Betrach­tungs­wei­sen aus ande­ren Gebie­ten wie bei­spiels­wei­se dem Pro­jekt­ma­nage­ment, der Lin­gu­is­tik oder der Psy­cho­lo­gie.

In die­ser Beschrei­bung wird das Requi­re­ments Engi­nee­ring der Busi­ness Ana­ly­sis (auch Busi­ness Ana­ly­se, kurz BA) gleich­ge­setzt. In der Lite­ra­tur wer­den zwar teil­wei­se Unter­schei­dun­gen zwi­schen die­sen Begrif­fen vor­ge­nom­men, die aber hier nicht betrach­tet wer­den.

In der Pra­xis wer­den Sie eine gro­ße Anzahl von Vor­la­gen, Anlei­tun­gen, Bei­spie­len, Check­lis­ten, Mus­tern, Heu­ris­ti­ken etc. fin­den, die Ihnen das Leben mit den Anfor­de­run­gen erleich­tern sol­len. Alle die­se Hilfs­mit­tel müs­sen dann an Ihr kon­kre­tes Vor­ha­ben oder Pro­jekt (ent­spre­chend Ihrer Fir­men- und Pro­jekt­kul­tur) ange­passt wer­den – dies soll­te in der Regel ein erfah­re­ner Requi­re­ments Engi­neer oder Bera­ter vor­neh­men.

Zudem über­schnei­det sich das Requi­re­ments Engi­nee­ring in erheb­li­chem Maße mit den Dis­zi­pli­nen

  • Pro­jekt­ma­nage­ment,
  • Pro­dukt­ma­nage­ment,
  • Qua­li­täts­ma­nage­ment,
  • Risi­ko­ma­nage­ment sowie
  • Pro­zess­ma­nage­ment.

Um erfolg­rei­che Pro­duk­te oder Sys­te­me zu ent­wi­ckeln, benö­ti­gen Sie daher Kennt­nis­se aus allen Berei­chen.
Auf die­ser Sei­te soll nur ein kur­zer Blick auf das Requi­re­ments Engi­nee­ring gewor­fen — die Inhal­te und Dar­stel­lun­gen basie­ren im Wesent­li­chen auf mei­ner Über­sichts­prä­sen­ta­ti­on, die hier her­un­ter­ge­la­den wer­den kann:

InhaltTyp
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 (pdf)

Kleine Einblicke in das Requirements Engineering

Zu fol­gen­den The­men fin­den Sie hier die Beschrei­bung eini­ger Ele­men­te:


1. Einleitung und Grundlagen

An die­ser Stel­le wer­den Ihnen die hier ver­wen­de­ten Defi­ni­tio­nen vor­ge­stellt, da die Begrif­fe (lei­der) in der Pra­xis (und auch in der Lite­ra­tur) mit­ein­an­der ver­mischt wer­den.

Hier wird das Requi­re­ments Engi­nee­ring in die Berei­che Anfor­de­rungs­ent­wick­lung und Anfor­de­rungs­ver­wal­tung unter­teilt, wobei die­se wie­der­um in die vier Haup­tä­tig­kei­ten …

  • Ermit­teln,
  • Doku­men­tie­ren,
  • Prü­fen und Abstim­men und
  • Ver­wal­ten

unter­glie­dert wer­den kön­nen (Abbil­dung 1.1, die blau-hin­ter­leg­ten Num­mern geben die zuge­hö­ri­gen Abschnit­te auf die­ser Sei­te an).

Die Unterteilung des Requirements Engineerings, (C) Peterjohann Consulting, 2006-2019

Abbil­dung 1.1: Die Unter­tei­lung des Requi­re­ments Engi­nee­rings

Der zen­tra­le Begriff im Requi­re­ments Engi­nee­ring sind die Anfor­de­run­gen (auch als Requi­re­ments bezeich­net). Die­se kön­nen fol­gen­der­ma­ßen defi­niert wer­den:

  • “Anfor­de­run­gen sind Aus­sa­gen über eine Eigen­schaft oder Leis­tung eines Pro­duk­tes, eines Pro­zes­ses oder der am Pro­zess betei­lig­ten Per­so­nen.”
  • “Eine Anfor­de­rung ist eine Bedin­gung oder Fähig­keit, die ein Benut­zer benö­tigt, um ein Pro­blem zu lösen oder ein Ziel zu errei­chen.”
  • “Eine Anfor­de­rung ist eine Eigen­schaft, über die ein Pro­dukt ver­fü­gen muss, um für die Inter­es­sen­ver­tre­ter von Nut­zen zu sein.”

Bei den Anfor­de­run­gen selbst kann wie­der­um zwi­schen Pro­dukt- und Pro­zess­an­for­de­run­gen unter­schie­den wer­den. Auf die­ser Sei­te set­ze ich mich nur mit den Pro­dukt­an­for­de­run­gen aus­ein­an­der.

1.1 Die Verbände zum Requirements Engineering und zur Business Analysis

Rund um die Busi­ness Ana­ly­sis und das Requi­re­ments Engi­nee­ring sind eini­ge Ver­bän­de ent­stan­den, die sich um die Defi­ni­ti­on und Struk­tu­rie­rung der Inhal­te bemü­hen.
In Deutsch­land sind vor allem fol­gen­de drei Ver­bän­de rele­vant:

  1. Das Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board (IREB)
  2. Das Inter­na­tio­nal Insti­tu­te of Busi­ness Ana­ly­sis (IIBA)
  3. Das Pro­ject Manage­ment Insti­tu­te (PMI)

Alle drei Ver­bän­de haben jeweils (min­des­tens) ein Basis­werk zur Beschrei­bung des zum RE und zur BA gehö­ren­den Inhalts (IREB: /IREB15/, IIBA: /BBG15/, PMI: /BAPG15/ und /PMG-BA17/) und geben jeweils Per­so­nen­zer­ti­fi­ka­te her­aus, die nach Bestehen einer Prü­fung erlangt wer­den kön­nen.

1.2 Zentrale Begriffe des Requirements Engineerings

Fol­gen­de Begrif­fe zum Requi­re­ments Engi­nee­ring sind :

  • Kun­de (Benut­zer, Anwen­der): der­je­ni­ge, der das Pro­dukt oder die Dienst­leis­tung nut­zen soll – er macht die Vor­ga­ben
  • Sta­ke­hol­der: Einer der belieb­tes­ten Begrif­fe des RE (oder auch der Soft­ware­ent­wick­lung): Inter­es­sen­in­ha­ber oder ‑ver­tre­ter; dies kön­nen sein: der Fach­an­wen­der oder die Fach­ab­tei­lung, der Kun­de, das Mar­ke­ting, der Ver­trieb, das Manage­ment, der Pro­jekt­lei­ter, der Pro­jekt­mit­ar­bei­ter, die Schnitt­stel­len (!), …
  • Requi­re­ments Engi­neer (auch Sys­tem­ana­ly­ti­ker, Anfor­de­rungs­in­ge­nieur, Busi­ness Ana­lyst, Requi­re­ments Ana­lyst): Der­je­ni­ge, der das zu erstel­len­de Pro­dukt, Sys­tem oder die Dienst­leis­tung beschreibt
  • Pro­dukt: Arbeits­er­geb­nis, das aus Pro­zes­sen resul­tiert
  • Pro­zess: Abfol­ge zusam­men­ge­hö­ri­ger Tätig­kei­ten, die der Errei­chung eines Ziels dient
  • Ziel: Ein in der Zukunft lie­gen­der, gegen­über dem Gegen­wär­ti­gen im All­ge­mei­nen ver­än­der­ter, erstre­bens­wer­ter und ange­streb­ter Zustand (Ziel­vor­ga­be)

1.3 Der Requirements Engineer

Der Requi­re­ments Engi­neer ist der Ver­mitt­ler zwi­schen Auf­trag­ge­ber und Auf­trag­neh­mer: Er defi­niert, wie Lösun­gen aus­se­hen könn­ten.

Von der Idee bis zur Lösung, (C) Peterjohann Consulting, 2006-2019

Abbil­dung 1.2: Von der Idee bis zur Lösung

1.4 Charakterisierung von Anforderungen

Anfor­de­run­gen gibt es vie­le – typi­scher­wei­se wer­den in Pro­jek­ten fol­gen­de Anfor­de­run­gen betrach­tet:

  • Funk­tio­na­le Anfor­de­run­gen
  • Nicht-funk­tio­na­le Anfor­de­run­gen
  • Tech­ni­sche Anfor­de­run­gen
  • Anfor­de­run­gen an die Benut­zer­schnitt­stel­le
  • Qua­li­täts­an­for­de­run­gen
  • Anfor­de­run­gen an sons­ti­ge Lie­fer­be­stand­tei­le
  • Anfor­de­run­gen an die Durch­füh­rung der Ent­wick­lung
  • Recht­lich-ver­trag­li­che Anfor­de­run­gen
  • Anfor­de­run­gen an Per­so­nen / Mit­ar­bei­ter
  • Kun­den- oder Geschäfts­an­for­de­run­gen
  • Lösungs‑, Mar­ke­ting- oder Sys­tem­an­for­de­run­gen
  • Pro­dukt- oder Kom­po­nen­ten­an­for­de­run­gen

1.4.1 Einteilung der Anforderungen

In der Busi­ness Ana­ly­sis wer­den die Anfor­de­run­gen vier Anfor­de­rungs­ar­ten (Types of Requi­re­ments, Requi­re­ments Types) zuge­ord­net. Nach IIBA und PMI sind dies (Abbil­dung 1.3):

  • 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 kom­men
  • 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 ori­en­tiert
  • 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
    • Func­tio­n­al Requi­re­ments (“Funk­tio­na­le Lösungs­an­for­de­run­gen”)
    • Non-func­tio­n­al Requi­re­ments (“Nicht-funk­tio­na­le Lösungs­an­for­de­run­gen”)
  • 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ög­li­chen

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

Anforderungsarten tabellarisch nach IIBA und PMI, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 1.3: Anfor­de­rungs­ar­ten (tabel­la­risch) nach IIBA und PMI

Die vier Anfor­de­rungssar­ten 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 1.4). 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 ableit­bar.

Die Pfei­le in Abbil­dung 1.4 sym­bo­li­sie­ren Ver­wei­se oder auch Ablei­tun­gen: Hier­über ist es mög­lich, die ein­zel­nen Anfor­de­run­gen in einen Kon­text zu brin­gen, sie wer­den “trace­ab­le” (nach­ver­folg­bar).

Anforderungsarten hierarchisch nach IIBA und PMI, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 1.4: Anfor­de­rungs­ar­ten (hier­ar­chisch) nach IIBA und PMI

Übli­cher­wei­se wer­den alle Lösungs­an­for­de­run­gen an ein Pro­dukt oder Sys­tem (grob) in 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 Bild /IREB15, Ebert19/:

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

Abbil­dung 1.5: Ein­tei­lung von Anfor­de­run­gen

Wäh­rend die funk­tio­na­len Anfor­de­run­gen (ver­gleichs­wei­se) ein­fach zu beschrei­ben sind, berei­tet die Erfas­sung der nicht-funk­tio­na­len Anfor­de­run­gen 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.

1.4.2 Gute Anforderungen

Mit “guter Anfor­de­rung” ist nicht die Anfor­de­rung gemeint, die beson­ders gut gefällt, son­dern die­je­ni­ge, die bei der Erstel­lung des Pro­dukts (beson­ders gut) wei­ter­hilft. Eine gute Anfor­de­rung genügt fol­gen­den Kri­te­ri­en – sie ist:

  • ato­mar
  • iden­ti­fi­zier­bar
  • voll­stän­dig (nach IEEE)
  • kor­rekt (nach IEEE)
  • klas­si­fi­zier­bar
  • kon­sis­tent (nach IEEE)
  • rea­li­sier­bar
  • not­wen­dig
  • prio­ri­siert
  • ein­deu­tig (nach IEEE)
  • ver­steh­bar
  • gül­tig und aktu­ell
  • nach­prüf­bar (nach IEEE)
  • rück- und vor­wärts­ver­folg­bar (nach IEEE)
  • (bewer­tet) (nach IEEE)

Beson­ders die auf die Nach­prüf­bar­keit soll­te größ­ten Wert gelegt wer­den, da hier schnell recht­li­che Kon­se­quen­zen grei­fen: Wenn eine Anfor­de­rung nicht getes­tet und über­prüft wer­den kann, führt dies zwangs­läu­fig zu Unstim­mig­kei­ten zwi­schen Kun­den und Auf­trag­neh­mer.

1.4.3 Die Perspektiven von Anforderungen

Anfor­de­run­gen kön­nen aus drei Sich­ten (Per­spek­ti­ven) beschrie­ben wer­den: Die Struktur‑, die Funk­ti­ons- und die Ver­hal­tens­sicht. Die drei Per­spek­ti­ven hän­gen zusam­men und soll­ten als Gan­zes betrach­tet wer­den.

Die drei Perspektiven von Anforderungen, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 1.6: Die drei Per­spek­ti­ven von Anfor­de­run­gen

Eine Erläu­te­rung der drei Per­spek­ti­ven ist nach­fol­gend dar­ge­stellt (Abbil­dung 1.7). Je nach Per­spek­ti­ve bie­ten sich zur Beschrei­bung unter­schied­li­che Model­le an (drit­te Spal­te in der Abbil­dung).

Die drei Perspektiven von Anforderungen - Erläuterung, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 1.7: Die drei Per­spek­ti­ven von Anfor­de­run­gen — Erläu­te­rung (nach IREB /IREB15/)

1.5 Ein Prozess für das Requirements Engineering

Einen fest vor­ge­ge­be­nen Pro­zess (mit Ein­zel­schrit­ten und Akti­vi­tä­ten) für das RE gibt es nicht. Aller­dings kann die Anfor­de­rungs­ent­wick­lung als Abfol­ge von Tätig­kei­ten betrach­tet wer­den. Bei der Anfor­de­rungs­ent­wick­lung wer­den die Anfor­de­run­gen sys­te­ma­tisch zusam­men­ge­tra­gen und in eine Form gebracht, die die betei­lig­ten Par­tei­en (Auf­trag­ge­ber und Auf­trag­neh­mer) ver­ste­hen und zur Durch­füh­rung ihres Vor­ha­bens ver­wen­den kön­nen.

Die Anforderungsentwicklung nach IREB, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 1.8: Die Anfor­de­rungs­ent­wick­lung (nach IREB /IREB15/)

Die Anfor­de­rungs­ent­wick­lung wird fort­lau­fend durch­ge­führt: Stän­dig müs­sen Anfor­de­run­gen (oder Ände­run­gen dar­an) erfasst, über­prüft und in eine anspre­chen­de und dem Ziel­pu­bli­kum ver­ständ­li­che Form gebracht wer­den. Das RE lie­fert dabei nur Hilfs­mit­tel – zum Ver­fas­sen guter Anfor­de­run­gen und Anfor­de­rungs­do­ku­men­te wer­den ent­spre­chend aus­ge­bil­de­te Mit­ar­bei­ter benö­tigt.


2. Das System und der Systemkontext

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.

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

Abbil­dung 2.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 Defi­ni­ti­on und 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

3. Das Ermitteln von Anforderungen

Bei Anfor­de­rungs­er­mitt­lung wer­den die (mög­li­chen) Anfor­de­run­gen für zu ent­wi­ckeln­de Sys­tem oder Pro­dukt zusam­men­ge­tra­gen. Dabei wer­den nicht von vorn­her­ein Anfor­de­run­gen aus­ge­schlos­sen, son­dern der Ermitt­lung erfolgt zunächst lösungs­neu­tral.
Am Ende der Anfor­de­rungs­er­mitt­lung gibt es eine Samm­lung von Anfor­de­run­gen für das zu ent­wi­ckeln­de Pro­dukt.

3.1 Das Kano-Modell

Das Kano-Modell (nach Noria­ki Kano, 1978) dient der Ana­ly­se von Kun­den­wün­schen und basiert auf Kun­den­be­fra­gun­gen und sta­tis­ti­schen Aus­wer­tun­gen. In die­sem Modell wer­den die Kun­den­an­for­de­run­gen in drei Arten von Anfor­de­run­gen (auch Fak­to­ren oder Merk­ma­le genannt) unter­teilt:

  • Basis­an­for­de­run­gen (expec­ted or basic requi­re­ments) sind selbst­ver­ständ­lich vor­aus­ge­setz­te Sys­tem­merk­ma­le (“unter­be­wuss­tes Wis­sen”)
  • Leis­tungs­an­for­de­run­gen (nor­mal or per­for­mance requi­re­ments) sind expli­zit gefor­der­ten Sys­tem­merk­ma­le (“bewuss­tes Wis­sen”)
  • Begeis­te­rungs­an­for­de­run­gen (delight­ful or exci­te­ment requi­re­ments) sind Sys­tem­merk­ma­le, die der Sta­ke­hol­der nicht kennt, die­se erst wäh­rend der Benut­zung ent­deckt und dann Begeis­te­rung bei ihm her­vor­ru­fen (“unbe­wuss­tes Wis­sen”)

Gra­fisch umge­setzt ergibt sich das Kano-Dia­gramm.

Das Kano-Diagramm: Darstellung, (C) Peterjohann Consulting, 2014-2019

Abbil­dung 3.1: Das Kano-Dia­gramm: Dar­stel­lung

Im Kano-Dia­gramm wird der Erfül­lungs­grad der (Kunden-)Anforderungen der Kun­den­zu­frie­den­heit gegen­über­ge­stellt. Selbst wenn die Basis­an­for­de­run­gen (rote Linie) immer voll­stän­dig erfüllt sind, führt dies nicht zur Erhö­hung der Kun­den­zu­frie­den­heit. Anders die Leis­tungs­an­for­de­run­gen (blaue Linie): Wer­den die­se im Pro­dukt umge­setzt, so kön­nen sie zur Erhö­hung der Kun­den­zu­frie­den­heit bei­tra­gen. Aller­dings führt die unvoll­stän­di­ge Umset­zung die­ser Anfor­de­run­gen zur Unzu­frie­den­heit beim Kun­den. Die Begeis­te­rungs­an­for­de­run­gen (grü­ne Linie) hin­ge­gen tra­gen unmit­tel­bar zur Kun­den­zu­frie­den­heit bei, selbst wenn sie nur unzu­rei­chend umge­setzt wur­den.

Die Begeis­te­rungs­an­for­de­run­gen wer­den im Lau­fe der Zeit zu Leis­tungs­an­for­de­run­gen und schließ­lich zu Basis­an­for­de­run­gen.

Die Anfor­de­run­gen im Kano-Modell kön­nen fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den:

Die Anforderungen im Kano-Modell, (C) Peterjohann Consulting, 2014-2019

Abbil­dung 3.2: Die Anfor­de­run­gen im Kano-Modell

Bei­spie­le für die drei Anfor­de­rungs­ar­ten im Kano-Modell:

Beispiele für Anforderungen im Kano-Modell, (C) Peterjohann Consulting, 2014-2019

Abbil­dung 3.3: Bei­spie­le für Anfor­de­run­gen im Kano-Modell

3.2 Ermittlungstechniken

Um Anfor­de­run­gen zu ermit­teln, kön­nen ver­schie­de­ne Tech­ni­ken (auch: Werk­zeu­ge und Metho­den, Tools and Tech­ni­ques) ein­ge­setzt wer­den (sie­he Abbil­dung 3.4). Gene­rell wer­den nicht alle Tech­ni­ken inner­halb eines Vor­ha­bens ver­wen­det, son­dern nur die­je­ni­gen, die sinn­voll erschei­nen.

Die Ermittlungstechniken nach IREB, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 3.4: Die Ermitt­lungs­tech­ni­ken (nach IREB /IREB15/)

Die Erläu­te­rung eini­ger Tech­ni­ken erfolgt in der → Basis-Prä­sen­ta­ti­on zum Requi­re­ments Engi­nee­ring.

Eine Zuord­nung von Ermitt­lungs­tech­ni­ken zu dem Vor­wis­sen der Auf­trag­ge­ber und Auf­trag­neh­mer lie­fert Ebert /Ebert19/ (Abb­bil­dung 3.5).
Zuordnung Ermittlungstechniken nach Ebert, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 3.5: Zuord­nung Ermitt­lungs­tech­ni­ken nach Ebert /Ebert19/

Die vier Qua­dran­ten kön­nen wie folgt cha­rak­te­ri­siert wer­den:

  1. Dem Auf­trag­ge­ber sind die­se Anfor­de­run­gen bekannt, dem Auf­trag­neh­mer nicht
  2. Sowohl dem Auf­trag­ge­ber wie auch dem Auf­trag­neh­mer sind die­se Anfor­de­run­gen unbe­kannt
  3. Dem Auf­trag­neh­mer sind die­se Anfor­de­run­gen bekannt, dem Auf­trag­ge­ber nicht
  4. Sowohl dem Auf­trag­ge­ber wie auch dem Auf­trag­neh­mer sind die­se Anfor­de­run­gen bekannt

3.3 Das Glossar

Bei der Ermitt­lung der Anfor­de­run­gen soll­te bereits ein Glos­sar (mit)erstellt wer­den, wel­ches alle (wich­ti­gen) Begrif­fe des betrach­te­ten Fach­ge­biets ent­hält.
In ein Glos­sar gehö­ren:

  • (Kon­text­spe­zi­fi­sche) Fach­be­grif­fe
  • Abkür­zun­gen und Akro­ny­me
  • All­täg­li­che Begrif­fe, die im gege­be­nen Kon­text eine spe­zi­fi­sche Bedeu­tung haben
  • Syn­ony­me (meh­re­re Wor­te haben eine Bedeu­tung); hier soll­te auch fest­ge­legt wer­den, dass nur ein Begriff/Wort ver­wen­det wer­den soll
  • Homo­ny­me (ein Wort hat meh­re­re Bedeu­tun­gen)

Die RE-Fach­ver­bän­de haben jeweils eige­ne Glossa­re für die Begrif­fe zum Requi­re­ments Engi­nee­ring selbst.

Die Glossare der Fachverbände, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 3.6: Die Glossa­re der Fach­ver­bän­de


4. Das Dokumentieren von Anforderungen

Das Doku­men­tie­ren von Anfor­de­run­gen beschäf­tigt sich mit zwei Aspek­ten:

  1. Zum einen mit Ein­zel-Anfor­de­run­gen
  2. Zum ande­ren mit dem Zusam­men­stel­len von (Einzel-)Anforderungen in einem Doku­ment

Aspekte des Dokumentierens, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 4.1: Aspek­te des Doku­men­tie­rens

4.1 Das Dokumentieren von Einzel-Anforderungen

Ein­zel-Anfor­de­run­gen kön­nen ent­we­der …

  • natür­lich­sprach­lich,
  • modell­ba­siert oder
  • als Misch­form beschrie­ben wer­den.

Die Dokumentationsformen nach IREB, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 4.2: Die Doku­men­ta­ti­ons­for­men (nach IREB /IREB15/)

In der Pra­xis wer­den alle For­men ein­ge­setzt.

4.1.1 Die Satzschablone

Satz­scha­blo­nen die­nen der Erfas­sung von Ein­zel-Anfor­de­run­gen: Durch Vor­ga­ben einer for­ma­len (syn­tak­ti­schen) Struk­tur wer­den ein­zel­ne Anfor­de­run­gen in vor­ge­ge­be­ner Art und Wei­se in jeweils einem Satz beschrie­ben.

Bei Rupp /Rupp14/ wird die Satz- oder Anfor­de­rungs­scha­blo­ne wie folgt defi­niert:
“Eine Anfor­de­rungs­scha­blo­ne ist ein Bau­plan, der die Struk­tur eines ein­zel­nen Anfor­de­rungs­sat­zes fest­legt.”

Die Satzschablone, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 4.3: Die Satz­scha­blo­ne

Wenn Satz­scha­blo­nen kon­seu­ent und rich­tig ein­ge­setzt wer­den, redu­ziert sich der Inter­pre­ta­ti­ons­spiel­raum erheb­lich.

4.2 Das Zusammenstellen von (Einzel-)Anforderungen in einem Dokument

Beim IREB /IREB15/ wird ein Ergeb­nis der Doku­men­ta­ti­on als Anfor­de­rungs­do­ku­ment oder Anfor­de­rungs­spe­zi­fi­ka­ti­on bezeich­net und fol­gen­der­ma­ßen defi­niert:
„Eine ist eine sys­te­ma­tisch dar­ge­stell­te Samm­lung von Anfor­de­run­gen (typi­scher­wei­se für ein Sys­tem oder eine Kom­po­nen­te), die vor­ge­ge­be­nen Kri­te­ri­en genügt.“

In der Anfor­de­rungs­spe­zi­fi­ka­ti­on somit wer­den die ermit­tel­ten Anfor­de­run­gen in eine Form gebracht, die es erlaubt sowohl mit den Kunden/Stakeholdern wie auch mit den Ent­wick­lern ein Gesamt­bild des zu erstel­len­den Pro­dukts zu gene­rie­ren. Hier­zu kön­nen Glie­de­rungs­vor­la­gen für Doku­men­te ein­ge­setzt wer­den — in der Pra­xis wer­den (im deutsch­spra­chi­gen Raum) häu­fig enge­setzt:

  • Das Vole­re-Tem­pla­te von Suzan­ne und James Robert­son /VOLERE/
  • Die Struk­tur für Soft­ware Requi­re­ments Spe­ci­fi­ca­ti­on (SRS) nach IEEE 830‑1998
  • Die Doku­men­ten­struk­tur nach dem V‑Modell XT /V‑­Mo­dell-XT/

Im deutsch­spra­chi­gen Raum wer­den Anfor­de­rungs­do­ku­men­te häu­fig auch als Las­ten­heft und Pflich­ten­heft bezeich­net — Eine Beschrei­bung die­ser Begrif­fe fin­den Sie
hier


5. Das Prüfen und Abstimmen von Anforderungen

Das Prü­fen und Abstim­men von Anfor­de­run­gen dient der Zusam­men­stel­lung von abge­stimm­ten Anfor­de­run­gen, die zur Umset­zung gebracht wer­den kön­nen. Dabei müs­sen Inkon­sis­ten­zen besei­tigt und abschlie­ßend die Anfor­de­run­gen mit Hil­fe der Sta­ke­hol­der noch­mals prio­ri­siert wer­den.

Die Ziele beim Prüfen und Abstimmen von Anforderungen nach IREB, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 5.1: Die Zie­le beim Prü­fen und Abstim­men von Anfor­de­run­gen (nach IREB /IREB15/)

Bei Prü­fen und Abstim­men ste­hen drei Qua­li­täts­as­pek­te im Vor­der­grund:

  1. Inhalt
  2. Doku­men­ta­ti­on
  3. Abge­stimmt­heit

Für die drei Qua­li­täts­as­pek­te gibt es jeweils eige­ne Prüf­kri­te­ri­en, die wie eine Art Check­lis­te abge­ar­bei­tet wer­den kön­nen (Abbil­dung 5.2).

Die drei Qualitätsaspekte für Anforderungen nach IREB, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 5.2: Die drei Qua­li­täts­as­pek­te für Anfor­de­run­gen (nach IREB /IREB15/)

Gene­rell gel­ten nach IREB sechs Prin­zi­pi­en der Prü­fung von Anfor­de­run­gen (Abbil­dung 5.3). Die­se soll­ten bei der Pla­nung einer Prü­fung beach­tet wer­den.
Die sechs Prinzipien der Prüfung für Anforderungen nach IREB, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 5.3: Die sechs Prin­zi­pi­en der Prü­fung für Anfor­de­run­gen (nach IREB /IREB15/)

Als Prüf­tech­ni­ken zur (inhalt­li­chen Prü­fung) kön­nen ein­ge­setzt wer­den:
Die Prüftechniken nach IREB, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 5.4: Die Prüf­tech­ni­ken (nach IREB /IREB15/)

Die “manu­el­len” Prü­fun­gen wer­den häu­fig unter dem Begriff Reviews zusam­men­ge­fasst.
Anmer­kung: Die Über­prü­fung der Struk­tur wird als “Audit” bezeich­net.

Eine Zuord­nung, wel­che Rol­len / Per­so­nen was prü­fen soll­ten, fin­det sich bei­spiels­wei­se bei Rupp /Rupp14/ (Abbil­dung 5.5).

Die Prüfpersonen und Prüfkriterien nach Rupp, (C) Peterjohann Consulting, 2018-2019

Abbil­dung 5.5: Die Prüf­per­so­nen und Prüf­kri­te­ri­en (nach /Rupp14/)


6. Das Verwalten von Anforderungen

Die bes­te Anfor­de­rungs­ent­wick­lung bringt wenig, wenn die ent­stan­de­nen Anfor­de­run­gen “sta­tisch” blei­ben, d.h. nicht kon­trol­liert und kon­se­quent in das Pro­dukt ein­flie­ßen (kön­nen). Mit die­ser Auf­ga­be setzt sich die Anfor­de­rungs­ver­wal­tung aus­ein­an­der, die wie­der­um in zwei Blö­cke unter­glie­dert wer­den kann:

  • Basis­funk­tio­nen: Umset­zung der Anfor­de­run­gen in ein Pro­dukt
  • Chan­ge Manage­ment: Erfas­sen und Umset­zen von Ände­run­gen

Die gene­rel­len Auf­ga­ben der Anfor­de­rungs­ver­wal­tung sind in der nach­fol­gen­den Gra­fik dar­ge­stellt.

Die Aufgaben der Anforderungsverwaltung, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 6.1: Die Auf­ga­ben der Anfor­de­rungs­ver­wal­tung (nach /Wiegers05/)

6.1 Basisfunktionen

Sind die Anfor­de­run­gen in aus­ge­ar­bei­te­ter Form zusam­men­ge­tra­gen, so soll­ten die­se auch sys­te­ma­tisch in das Pro­dukt ein­flie­ßen. Wich­tig hier­bei ist die Nach­ver­fol­gung der (Umset­zung der) Anfor­de­run­gen, um so das fer­tig­ge­stell­te Pro­dukt tes­ten zu kön­nen und auch vom Kun­den abneh­men zu las­sen.

Fol­gen­de Ana­ly­sen über die Anfor­de­run­gen soll­ten (jeder­zeit) im Pro­jekt erstellt wer­den kön­nen:

  • Ein­fluss­ana­ly­se: Sie zeigt auf, wie sich Anfor­de­run­gen bei der Umset­zung auf die gesam­te Lösung aus­wir­ken
  • Abde­ckungs­ana­ly­se: Sie lie­fert ein Maß für den Pro­jekt­fort­schritt, da die Anzahl der erfüll­ten Anfor­de­run­gen zu der Gesamt­an­zahl der Anfor­de­run­gen in Rela­ti­on gesetzt wird. Lei­der führt die­se Ana­ly­se oft­mals zu Miss­ver­ständ­nis­sen
  • Nut­zen­ana­ly­se: Sie beant­wor­tet die Fra­ge, war­um die ein­zel­nen Anfor­de­run­gen über­haupt in das Pro­dukt auf­ge­nom­men wur­den

Der zen­tra­le Begriff der Anfor­de­rungs­ver­wal­tung ist sicher­lich die Ver­folg­bar­keit (engl. tracea­bi­li­ty), die von der Kun­den­an­for­de­rung bis zur Pro­duk­t­ei­gen­schaft die ein­zel­nen Umset­zungs­schrit­te trans­pa­rent macht. Hier­zu soll­ten pro Anfor­de­rung fol­gen­de Merk­ma­le notiert wer­den:

  • Ein­deu­ti­ge ID
  • Bezeich­nung
  • Zuord­nung zu einem Pro­jekt oder Pro­dukt
  • Quel­le
  • Sta­tus

6.2 Zustände von Anforderungen

Ein­zel­ne Anfor­de­run­gen haben immer einen Sta­tus: Hier­über wird der Bear­bei­tungs­zu­stand fest­ge­hal­ten.

Ein Zustandsmodell für Anforderungen - Generell, (C) Peterjohann Consulting, 2013-2019

Abbil­dung 6.2: Ein Zustands­mo­dell für Anfor­de­run­gen (gene­rell)

In der kon­kre­ten Aus­ge­stal­tung könn­te ein Zustands­mo­dell dann fol­gen­de Aus­ge­stal­tung haben:

Ein Zustandsmodell für Anforderungen - Beispiel, (C) Peterjohann Consulting, 2013-2019

Abbil­dung 6.3: Ein Zustands­mo­dell für Anfor­de­run­gen (Bei­spiel)

Im Nor­mal­fall durch­läuft eine Anfor­de­rung alle Zustän­de von “Ange­legt” bis “Abge­schlos­sen”. Dabei wird an einer Stel­le geprüft, ob die Anfor­de­rung zur Umset­zung gelangt oder ob sie nicht wei­ter betrach­tet wird.

6.3 Change Management

Die Dis­zi­plin, die sich mit den Ände­run­gen an den Anfor­de­run­gen (im Requi­re­ments Engi­nee­ring und auch im Pro­jekt­ma­nage­ment) aus­ein­an­der­setzt, heißt “Chan­ge Manage­ment” oder “Chan­ge Request Manage­ment” (das deut­sche Wort Ände­rungs­ver­wal­tung wird weni­ger häu­fig benutzt; zum Chan­ge Manage­ment als orga­ni­sa­to­ri­sches Ver­än­de­rungs­we­sen gibt es → auf der Chan­ge-Manage­ment-Sei­te die­ser Web­site eini­ge Anmer­kun­gen) – der Begriff deu­tet schon an, dass nicht nur das ein­ma­li­ge Erfas­sen und Wei­ter­rei­chen von Anfor­de­run­gen auf­wen­dig ist, son­dern auch das ziel­ge­rich­te­te Auf­neh­men und Wei­ter­ver­ar­bei­ten von Ände­run­gen an den Anfor­de­run­gen. Tat­säch­lich bedin­gen die Ände­run­gen die eigent­li­chen Schwie­rig­kei­ten inner­halb eines Pro­jekts und sind daher immer “Chef­sa­che”.

Auch für das Chan­ge Manage­ment kann ein Regel­satz ange­ge­ben wer­den:

  • Legen Sie alle Anfor­de­run­gen gesam­melt an einer Stel­le ab
  • Ermög­li­chen Sie eine Ana­ly­se der Ände­run­gen an den Anfor­de­run­gen
  • Auch Ände­run­gen müs­sen – wie die ursprüng­li­chen Anfor­de­run­gen selbst – ermit­telt, ana­ly­siert, vali­diert und spe­zi­fi­ziert wer­den und durch­lau­fen somit den glei­chen Pro­zess
  • Bün­deln Sie die Ände­run­gen, d.h. pla­nen Sie auch die Zeit­punk­te, an denen Ände­run­gen ein­ge­bracht wer­den dür­fen
  • Über die Umset­zung von Ände­run­gen ent­schei­den fest­ge­leg­te Instan­zen, im Zwei­fel der Pro­jekt­lei­ter und der Len­kungs­aus­schuss
  • Set­zen Sie einen Ter­min, ab dem Ände­run­gen nicht mehr akzep­tiert wer­den (kön­nen)
  • Zei­gen Sie auf, wel­chen Ein­fluss die Ände­run­gen auf das Pro­dukt selbst und auf das Pro­jekt haben

Nach Been­di­gung des Pro­jekts soll­ten die nicht mehr umge­setz­ten Ände­run­gen in das Chan­ge Manage­ment des nach­ge­la­ger­ten Teils des Pro­dukt­le­bens­zy­klus ein­flie­ßen, um so die War­tung und (poten­zi­el­le) Wei­ter­ent­wick­lung zu erleich­tern.


7. Anmerkungen zum RE

Das RE ist noch eine recht jun­ge Dis­zi­plin, was die For­schung und wis­sen­schaft­li­che Fun­da­men­tie­rung anbe­trifft. Gleich­zei­tig über­schnei­det sich das RE mit eini­gen ande­ren Gebie­ten – aus die­sen Grün­den wer­den hier eini­ge Aspek­te zum RE auf­ge­führt, die sich nicht unmit­tel­bar aus der rei­nen Theo­rie erge­ben.

7.1 Anforderungen und Software-Vorgehensmodelle

Bei der Soft­ware­ent­wick­lung wer­den inzwi­schen eine gro­ße Anzahl unter­schied­li­cher Vor­ge­hens­mo­del­le ver­wen­det, die sich ins­be­son­de­re dahin­ge­hend unter­schei­den, wie vie­le Doku­men­te erstellt und damit Anfor­de­run­gen auf­ge­nom­men wer­den. Abge­se­hen von dem “agi­len Vor­ge­hens­mo­dell” wer­den jedoch immer Anfor­de­run­gen erfasst, wenn auch zu unter­schied­li­chen Zeit­punk­ten. Die nach­fol­gen­de Abbil­dung ver­deut­licht dies.

Vorgehensmodelle und Anforderungen, (C) Peterjohann Consulting, 2006-2019

Abbil­dung 7.1: Vor­ge­hens­mo­del­le und Anfor­de­run­gen (nach /Ebert14/)

7.2 Die Umsetzung von RE in der Praxis

Nur weni­ge Fir­men betrei­ben ein aus­ge­reif­tes Requi­re­ments Engi­nee­ring. Die Ursa­chen für man­gel­haf­tes Requi­re­ments Engi­nee­ring sind:

  • Das Requi­re­ments Engi­nee­ring soll­te in einem Vor­ge­hens­mo­dell (Erstel­lungs­vor­ga­ben von der Idee zum Betrieb eines Sys­tems) ein­ge­bet­tet sein. Wenn die­ses bereits fehlt, ste­hen die Anfor­de­run­gen im “lee­ren” Raum
  • Der Erfas­sung von Anfor­de­run­gen basiert auf sprach­li­chen, d.h. tex­tu­el­len Metho­den. Nun sind die die meis­ten Tech­ni­ker nicht unbe­dingt Ger­ma­nis­ten und nicht gewohnt, ihre Ide­en klar und all­ge­mein­ver­ständ­lich zu for­mu­lie­ren
  • Die meis­ten am Markt ver­füg­ba­ren RE-Tools ermög­li­chen der­zeit noch kein voll­stän­di­ges Round­trip-Engi­nee­ring (von der Erfas­sung zur Ver­sio­nie­rung, Abän­de­rung bis zum Betrieb) und bie­ten für die Ent­wick­ler nur ein­ge­schränk­ten Nut­zen

7.3 Die deutsche Sprache

Das Requi­re­ments Engi­nee­ring hat viel mit (der rich­ti­gen Ver­wen­dung) der deut­schen Spra­che zu tun. Ent­spre­chend beschäf­tig­ten sich eini­ge Autoren (in Deutsch­land ins­be­son­de­re Chris Rupp /Rupp14/) mit dem adäqua­ten Ein­satz von lin­gu­is­ti­schen Metho­den im RE. Aber auch ein gene­rel­les Ver­ständ­nis der deut­schen Spra­che kann bei der Erstel­lung von guten Anfor­de­run­gen hilf­reich sein. Ergän­zend kön­nen hier­für eini­ge “Deutsch­bü­cher” der Lite­ra­tur­lis­te unter
Hob­byrun­de (Rubrik “|Deutsch für …”) auf der pri­va­ten Web­site des Autors hin­zu­ge­zo­gen wer­den.

7.4 Verwandte Themen

Der Zweig der (tech­ni­schen) Doku­men­ta­ti­on setzt sich mit ähn­li­chen Auf­ga­ben­stel­lun­gen wie das RE aus­ein­an­der. Zwar gibt es inzwi­schen sogar einen eigen­stän­di­gen Stu­di­en­gang “Tech­ni­sche Doku­men­ta­ti­on”, aber ansons­ten wird die­ser Bereich kaum wahr­ge­nom­men.

Die Ver­wandt­schaft des RE zum Gebiet der tech­ni­schen Doku­men­ta­ti­on ermög­licht es aber, auch inter­es­san­te Metho­den zur Dar­stel­lung zu ver­wen­den, so z.B. das XML-basier­te DITA. Wei­te­re Infor­ma­tio­nen fin­den sich auch unter www.doku.info. Als Lite­ra­tur kann bei­spiels­wei­se

  • /Juhl15/ Diet­rich Juhl: Tech­ni­sche Doku­men­ta­ti­on: Prak­ti­sche Anlei­tung und Bei­spie­le, Sprin­ger, Ber­lin 3. Auf­la­ge 2015, ISBN 978–3‑662–46864‑7

her­an­ge­zo­gen wer­den.


8. Anmerkungen zu den Fachverbänden

Rund um die Busi­ness Ana­ly­sis und das Requi­re­ments Engi­nee­ring sind eini­ge Fach­ver­bän­de ent­stan­den, die sich um die Defi­ni­ti­on und Struk­tu­rie­rung der Inhal­te bemü­hen. Hier wer­den eini­ge Gegen­über­stel­lun­gen vor­ge­nom­men, Bewer­tun­gen jedoch nicht: Die­se kön­nen aber beim Autor abge­fragt wer­den.

8.1 Die Strukturierung der Aufgaben zum RE und zur BA

Die drei Fach­ver­bän­de unter­tei­len die Auf­ga­ben im Requi­re­ments Engi­nee­ring und im in der Busi­ness Ana­ly­sisin ein­zel­ne Berei­che. Die­se hei­ßen …

  • beim IREB Haupt­ak­ti­vi­tä­ten,
  • beim IIBA Know­ledge Are­as (Über­set­zung: Wis­sens­ge­bie­te) und
  • beim PMI Domains (eige­ne Über­set­zung: Domä­nen).

Die Aufgabenunterteilung der drei Fachverbände zum RE und zur BA, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 8.1: Die Auf­ga­ben­un­ter­tei­lung der drei Fach­ver­bän­de zum RE und zur BA

Auf den fol­gen­den drei Gra­fi­ken sind die Unter­tei­lun­gen des REs und der BA der Fach­ver­bän­de dar­ge­stellt. Die Zah­len in den grü­nen Krei­sen geben jeweils das Buch­ka­pi­tel des dazu­ge­hö­ri­gen Basis­werks wie­der.

Hier­zu:

  • Die Unter­tei­lung in die Berei­che ist nicht als stren­ger Ablauf zu inter­pre­tie­ren
  • Jedem Bereich sind meh­re­re Werk­zeu­ge und Metho­den (Tools and Tech­ni­ques) zuge­ord­net
  • Bei allen drei Fach­ver­bän­den ist das Basis­werk zuletzt 2015 erschie­nen
  • Die Unter­tei­lun­gen sind nicht “gleich gewich­tet”: Bei allen Fach­ver­bän­de steht die Ermitt­lung (Eli­ci­ta­ti­on) im Vor­der­grund

Die vier Hauptaktivitäten im RE nach IREB, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 8.2: Die vier Haupt­ak­ti­vi­tä­ten im RE nach IREB /IREB15/

Beim IREB fehlt eine vor­ge­la­ger­te oder über­ge­ord­ne­te Pla­nungs­stu­fe, die fest­legt, wel­che Werk­zeu­ge und Metho­den im kon­kre­ten Ein­zel­pro­jekt ver­wen­det wer­den sol­len.

Die sechs Wissensgebiete nach IIBA, (C) Peterjohann Consulting 2017-2019

Abbil­dung 8.3: Die sechs Wis­sens­ge­bie­te nach IIBA /BBG15/

Das IIBA beschäf­tigt sich stark mit der Ein­bet­tung der Anfor­de­run­gen in den Orga­ni­sa­ti­ons­kon­text, die kon­kre­te Umset­zung wird weni­ger stark adres­siert.

Die fünf Domänen in der BA nach PMI, (C) Peterjohann Consulting, 2017-2019

Abbil­dung 8.4: Die fünf Domä­nen in der BA nach PMI /BAPG15/

Die fünf Domä­nen der BA nach PMI ähneln den sechs Wis­sens­ge­bie­ten des IIBA sehr stark. Auch die Tasks mit den Werk­zeu­gen und Metho­den sind ähn­lich auf­ge­baut.

8.2 Die Zertifizierungen der Fachverbände

Die drei Fach­ver­bän­de ver­ge­ben Zer­ti­fi­ka­te an Per­so­nen. Zu die­sen Zer­ti­fi­zie­run­gen gibt es eine Über­sicht → hier auf die­ser Web­site unter der Rubrik “Extras | Zer­ti­fi­zie­run­gen”.


9. Häufige Fragen und Antworten zum Requirements Engineering und zur Business Analysis

Eini­ge Fra­gen zum Requi­re­ments Engi­nee­ring und zur Busi­ness Ana­ly­sis wer­den häu­fig (nicht nur von Ein­stei­gern) gestellt – die­se wer­den hier wie­der­ge­ge­ben.

  • F: Ist die Nut­zung von RE nach den Stan­dards (IREB, CBAP, PMI-PBA) kos­ten­frei?
    A: Ja – es fal­len kei­ne Lizenz­ge­büh­ren an.
  • F: Kann ich RE und BA außer­halb von Soft­ware­ent­wick­lungs­pro­jek­ten ein­set­zen?
    A: Ja.
  • F: Ist eine Schu­lung zum RE und zur emp­feh­lens­wert?
    A: Ja.
  • F: Ab wann “lohnt” sich Requi­re­ments Engi­nee­ring?
    A: Fra­gen Sie mich.
  • F: Wel­che Lite­ra­tur ist emp­feh­lens­wert?
    A: Fra­gen Sie mich.
  • F: Wie füh­re ich (pro­fes­sio­nel­les) Requi­re­ments Engi­nee­ring ein?
    A: Fra­gen Sie mich.
  • F: Muss ein Requi­re­ments-Engi­nee­ring-Hand­buch oder Requi­re­ments-Engi­nee­ring-Leit­fa­den vor­han­den sein?
    A: Soll­ten Sie Requi­re­ments Engi­nee­ring pro­fes­sio­nell betrei­ben wol­len, so müs­sen die Regeln und Vor­ga­ben schrift­lich fixert wer­den — hier­für bie­tet sich ein Requi­re­ments-Engi­nee­ring-Hand­buch an.

A. Ressourcen

A.1 Meine Präsentationen und Veröffentlichungen

A.1.1 Meine öffentlichen RE-Präsentationen

Die nach­fol­gen­de Basis-Prä­sen­ta­ti­on gibt Ihnen einen ers­ten Ein­blick in das Requi­re­ments Engi­nee­ring. Wei­te­re, umfang­rei­che­re Prä­sen­ta­tio­nen und Schu­lungs­un­ter­la­gen wer­den nur auf Nach­fra­ge wei­ter­ge­reicht.

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)
Requi­re­ments Engi­nee­ring: Spe­zi­fi­ka­tio­nen – Eine Über­sicht1.5012/2016440,3 MB pdf (pdf)
Requi­re­ments Engi­nee­ring: Werk­zeu­ge und Metho­den – Eine Über­sicht0.2012/2018320,4 MB pdf (pdf)
Requi­re­ments Engi­nee­ring: Die Literatur(liste)0.5007/2019280,3 MB pdf (pdf)
Agi­li­tät: Agi­les Requi­re­ments Engi­nee­ring – Eine Über­sicht0.1005/2014840,8 MB pdf (pdf)
Sta­ke­hol­der­ma­nage­ment (in Pro­jek­ten) – Eine Über­sicht0.1003/20151380,8 MB pdf (pdf)
Agi­li­tät: Per­so­nas – Eine Über­sicht0.2006/2018480,5 MB pdf (pdf)

A.1.2 Meine Veröffentlichungen und Vorträge zum RE

Requirements Engineering – die Entwicklungen seit 2000 und ein Blick in die Zukunft (Vortrag am 07.10.2015)

/AK-REQ-2015-Sta­tus-Quo/ Requi­re­ments Engi­nee­ring & die Ent­wick­lun­gen seit 2000:
Prä­sen­ta­ti­on, 44 Sei­ten pdf

Wie kommen die Anforderungen auf die Website? Requirements Engineering für WordPress-Entwickler (Vortrag am 15.02.2017)

/WP-Meet­up-RE-und WP-17/ Wie kom­men die Anfor­de­run­gen auf die Web­site? Requi­re­ments Engi­nee­ring für Word­Press-Ent­wick­ler: Prä­sen­ta­ti­on, 22 Sei­ten pdf


A.2 Literatur

Die Anzahl an ver­füg­ba­rer Lite­ra­tur (Bücher) zum Requi­re­ments Engi­nee­ring ud zur Busi­enss Ana­ly­sis ist in den letz­ten Jah­ren gewach­sen, was ein Indiz für das stei­gen­de Inter­es­se an die­sem The­men­ge­biet ist.

  1. /Alexander02/ Ian Alex­an­der, Richard Ste­vens: Wri­ting Bet­ter Requi­re­ments, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2002, ISBN 978–0‑321–13163‑8
  2. /Alexander09/ Ian Alex­an­der, Lje­r­ka Beus-Dukic: Dis­co­vering Requi­re­ments: How to Spe­ci­fy Pro­duc­ts and Ser­vices, John Wiley & Sons, Hobo­ken, New Jer­sey 2009, ISBN 978–0‑470–71240‑5
  3. /BAPG15/ Pro­ject Manage­ment Insti­tu­te: Busi­ness Ana­ly­sis For Prac­ti­tio­ners: A Prac­tice Gui­de, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2015, ISBN 978–1‑62825–069‑5
  4. /Balzert08/ Hel­mut Bal­zert: Lehr­buch der Soft­ware­tech­nik: Soft­ware­ma­nage­ment, Spek­trum Aka­de­mi­scher Ver­lag, Hei­del­berg 2. Auf­la­ge 2008, ISBN 978–3‑8274–1161‑7
  5. /Balzert09/ Hel­mut Bal­zert: Lehr­buch der Soft­ware­tech­nik: Basis­kon­zep­te und Requi­re­ments Engi­nee­ring, Spek­trum Aka­de­mi­scher Ver­lag, Hei­del­berg 3. Auf­la­ge 2009, ISBN 978–3‑8274–1705‑3
  6. /Balzert11/ Hel­mut Bal­zert: Lehr­buch der Soft­ware­tech­nik: Ent­wurf, Imple­men­tie­rung, Instal­la­ti­on und Betrieb, Spek­trum Aka­de­mi­scher Ver­lag, 3. Auf­la­ge Hei­del­berg 2011, ISBN 978–3‑8274–1706‑6
  7. /BBG09/ 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 2009, ISBN 978–0‑9811292–1‑1
  8. /BBG12‑d/ IIBA: Leit­fa­den zum Busi­ness Ana­ly­sis Body of Know­ledge: BABOK 2.0, Dr. Götz Schmidt, Wet­ten­berg 2012, ISBN 978–3‑921313–81‑7
  9. /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
  10. /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
  11. /Beatty12/ Joy Beat­ty, Antho­ny Chen: Visu­al Models for Soft­ware Requi­re­ments, Micro­soft Press, Red­mond, Washing­ton 2012, ISBN 978–0‑7356–6772‑3
  12. /Bergsmann14/ Johan­nes Bergs­mann: Requi­re­ments Engi­nee­ring für die agi­le Soft­ware­ent­wick­lung: Metho­den, Tech­ni­ken und Stra­te­gi­en, dpunkt, Hei­del­berg 2014, ISBN 978–3‑86490–149‑2
  13. /Bergsmann18/ Johan­nes Bergs­mann: Requi­re­ments Engi­nee­ring für die agi­le Soft­ware­ent­wick­lung: Metho­den, Tech­ni­ken und Stra­te­gi­en, dpunkt, 2. Auf­la­ge Hei­del­berg 2018, ISBN 978–3‑86490–485‑1
  14. /Blais11/ Ste­phen Blais: Busi­ness Ana­ly­sis: Best Prac­tices for Suc­cess, John Wiley & Sons, Hobo­ken, New Jer­sey 2011, ISBN 978–1‑118–07600‑2
  15. /Cadle14a/ James Cad­le, Mal­colm Eva, Keith Hind­le, Debra Paul: Busi­ness Ana­ly­sis BCS, The Char­te­red Insti­tu­te for IT, Lon­don 3rd Edi­ti­on 2014, ISBN 978–1‑78017–277‑4
  16. /Cadle14b/ James Cad­le, Debra Paul, Paul Tur­ner: Busi­ness Ana­ly­sis Tech­ni­ques: 99 Essen­ti­al Tools for Suc­cess, BCS, The Char­te­red Insti­tu­te for IT, Lon­don 2nd Edi­ti­on 2014, ISBN 978–1‑78017–273‑6
  17. /Carkenord09/ Bar­ba­ra A. Car­kenord: Seven Steps to Mas­te­ring Busi­ness Ana­ly­sis, J. Ross Publi­shing, Fort Lau­derda­le, Flo­ri­da 4th Edi­ti­on 2009, ISBN 978–1‑60427–007‑5
  18. /Carkenord16/ Bar­ba­ra A. Car­kenord: PMI-PBA Exam Prep, Pre­mier Edi­ti­on, RMC Publi­ca­ti­ons, Burns­vil­le, Min­ne­so­ta 2nd Edi­ti­on 2016, ISBN 978–1‑943704–01‑9
  19. /Cockburn00/ Alista­ir Cock­burn: Wri­ting Effec­tive Use Cases, Addi­son-Wes­ley Long­man, Ams­ter­dam 2000, ISBN 978–0‑201–70225‑5
  20. /Davis05/ Alan M. Davis: Just Enough Requi­re­ments Manage­ment: Whe­re Soft­ware Deve­lop­ment Meets Mar­ke­ting, Dor­set House Publi­shing, New York 2005, ISBN 978–0‑932633–64‑4
  21. /Dick17/ Jere­my Dick, Eli­sa­beth Hull, Ken­neth Jack­son: Requi­re­ments Engi­nee­ring, Sprin­ger, Ber­lin 4th Edi­ti­on 2017, ISBN 978–3‑319–61072‑6
  22. /Ebert14/ 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 5. Auf­la­ge 2014, ISBN 978–3‑86490–139‑3
  23. /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
  24. /Fitzpatrick13/ Rob Fitz­pa­trick: The Mom Test: How to talk to custo­mers & learn if your busi­ness is a good idea when ever­yo­ne is lying to you, Crea­tespace Inde­pen­dent Publi­shing Plat­form, North Charles­ton, South Caro­li­na 2013, ISBN 978–1‑4921–8074‑6
  25. /Fitzpatrick16/ Rob Fitz­pa­trick: Der Mom Test: Wie Sie Kun­den rich­tig inter­view­en und her­aus­fin­den, ob Ihre Geschäfts­idee gut ist – auch wenn Sie dabei jeder anlügt, Crea­tespace Inde­pen­dent Publi­shing Plat­form, Leip­zig 2016, ISBN 978–1‑5336–9725‑7
  26. /Gause89/ Donald C. Gau­se, Gerald M. Wein­berg: Explo­ring Requi­re­ments. Qua­li­ty befo­re Design, Dor­set House Publi­shing, New York 1989, ISBN 978–0‑932633–13‑2
  27. /Gause93/ Donald C. Gau­se, Gerald M. Wein­berg: Soft­ware Requi­re­ments. Anfor­de­run­gen erken­nen, ver­ste­hen und erfül­len, Han­ser, Mün­chen 1993, ISBN 978–3‑446–17113‑8
  28. /Gerstbach15/ Ingrid Gerst­bach, Peter Gerst­bach: Basis­wis­sen Busi­ness-Ana­ly­se: Pro­ble­me lösen, Chan­cen nut­zen, Red­li­ne, Mün­chen 2015, ISBN 978–3‑86881–574‑0
  29. /Gilb05/ Tom Gilb: Com­pe­ti­ti­ve Engi­nee­ring: A Hand­book for Sys­tems Engi­nee­ring, Requi­re­ments Engi­nee­ring, and Soft­ware Engi­nee­ring Using Plan­guage, But­ter­worth-Hei­ne­mann, Bur­ling­ton, Mas­sa­chu­setts 2005, ISBN 978–0‑7506–6507‑0
  30. /Girvan17/ Lyn­da Gir­van, Debra Paul: Agi­le and Busi­ness Ana­ly­sis: Prac­ti­cal gui­d­ance for IT Pro­fes­sio­nals, BCS, The Char­te­red Insti­tu­te for IT, Lon­don 2017, ISBN 978–1‑78017–322‑1
  31. /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
  32. /Got05/ Ellen Got­tes­die­ner: The Soft­ware Requi­re­ments Memo­ry Jog­ger: A Pocket Gui­de to Help Soft­ware and Busi­ness Teams Deve­lop and Mana­ge Requi­re­ments, Goal/QPC, Salem, New Hamp­shire 2005, ISBN 978–1‑57681–060‑6
  33. /Grady06/ Jef­fry O. Gra­dy: Sys­tem Requi­re­ments Ana­ly­sis, Aca­de­mic Press, Bur­ling­ton, Mas­sa­chu­setts 2006, ISBN 978–0‑12–088514‑5
  34. /Grady13/ Jef­frey O. Gra­dy: Sys­tem Requi­re­ments Ana­ly­sis, Ele­vier Sci­ence, Lon­don 2nd Edi­ti­on 2013, ISBN 978–0‑12–417107‑7
  35. /Grady16/ Jef­frey O. Gra­dy: Sys­tem Veri­fi­ca­ti­on: Pro­ving the Design Solu­ti­on Satis­fies the Requi­re­ments, Aca­de­mic Press, Bur­ling­ton, Mas­sa­chu­setts 2nd Edi­ti­on 2016, ISBN 978–0‑12–804221‑2
  36. /Grady18/ Jef­frey O. Gra­dy: Sys­tem Requi­re­ments Ana­ly­sis, Else­vier Sci­ence, Lon­don 3rd Edi­ti­on 2018, ISBN 978–0‑12–417107‑7
  37. /Grande14/ Mar­cus Gran­de: 100 Minu­ten für Anfor­de­rungs­ma­nage­ment: Kom­pak­tes Wis­sen nicht nur für Pro­jekt­lei­ter und Ent­wick­ler, Sprin­ger View­eg, Wies­ba­den 2. Auf­la­ge 2014, ISBN 978–3‑658–06434‑1
  38. /Haber15/ Rein­hard Haber­fell­ner, Oli­ver L. de Weck, Ernst Fri­cke, Sieg­fried Vöss­ner: Sys­tems Engi­nee­ring: Grund­la­gen und Anwen­dung, Orell Füss­li, Zürich 13. Auf­la­ge 2015, ISBN 978–3‑280–04068‑3
  39. /Hammer13/ Ulri­ke Ham­mer­schall, Gerd Bene­ken: Soft­ware Requi­re­ments, Pear­son Stu­di­um, Mün­chen 2013, ISBN 978–3‑86894–151‑7
  40. /Hanschke16/ Inge Hansch­ke, Gun­nar Gie­sin­ger, Dani­el Goe­t­ze: Busi­ness Ana­ly­se – ein­fach und effek­tiv, Han­ser, Mün­chen 2. Auf­la­ge 2016, ISBN 978–3‑446–44345‑7
  41. /Herrmann12/ Andrea Herr­mann, Eric Knauss, Rüdi­ger Weiß­bach: Requi­re­ments Engi­nee­ring und Pro­jekt­ma­nage­ment, Sprin­ger, Ber­lin 2012, ISBN 978–3‑642–29431‑0
  42. /Hood05/ Colin Hood, Rupert Wie­bel: Opti­mie­ren von Requi­re­ments Manage­ment & Engi­nee­ring mit dem HOOD Capa­bi­li­ty Model, Sprin­ger, Ber­lin 2005, ISBN 978–3‑540–21178‑5
  43. /Hood07a/ Colin Hood, Chris Rupp, Susan­ne Mühl­bau­er, Ger­hard Vers­tee­gen (Hrsg.): ix-Stu­die Anfor­de­rungs­ma­nage­ment, Hei­se, Han­no­ver 2. Auf­la­ge 2007, kei­ne ISBN
  44. /Hood07b/ Colin Hood, Simon Wie­de­mann, Ste­fan Fich­t­in­ger, Urte Pautz: Requi­re­ments Manage­ment: The Inter­face Bet­ween Requi­re­ments Deve­lop­ment and All Other Sys­tems Engi­nee­ring Pro­ces­ses, Sprin­ger, Ber­lin 2007, ISBN 978–3‑540–47689‑4
  45. /Hossenlopp07/ Rose­ma­ry Hos­sen­lopp, Kath­le­en B. Hass: Uneart­hing Busi­ness Requi­re­ments: Eli­ci­ta­ti­on Tools and Tech­ni­ques, Manage­ment Con­cepts, Washing­ton D.C. 2007, ISBN 978–1‑56726–210‑0
  46. /Hruschka14/ 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 2014, ISBN 9978–3‑446–43807‑1
  47. /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
  48. /Hull10/ Eli­sa­beth Hull, Jere­my Dick, Ken­neth Jack­son: Requi­re­ments Engi­nee­ring, Sprin­ger, Ber­lin 3rd Edi­ti­on 2010, ISBN 978–1‑84996–404‑3
  49. /IREB15/ sie­he /Pohl15a/
  50. /Jonasson12/ Hans Jonas­son: Deter­mi­ning Pro­ject Requi­re­ments. Mas­te­ring the BABOK and the CBAP Exam, Auer­bach Publi­ca­ti­ons, New York 2nd Edi­ti­on 2012, ISBN 978–1‑4398–9651‑8
  51. /Jonasson16/ Hans Jonas­son: CBAP Cer­ti­fi­ca­ti­on and BABOK Stu­dy Gui­de, Tay­lor & Fran­cis, Lon­don 2016, ISBN 978–1‑4987–6725‑5
  52. /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/li>
  53. /Kotonya98/ Gerald Kotonya, Ian Som­mer­vil­le: Requi­re­ments Engi­nee­ring, John Wiley & Sons, Hobo­ken, New Jer­sey 1998, ISBN 978–0‑471–97208‑2
  54. /Kuper13/ Kupe Kupers­mith, Paul Mul­vey, Kate McGoey: Busi­ness Ana­ly­sis For Dum­mies, John Wiley & Sons, Hobo­ken, New Jer­sey 2013, ISBN 978–1‑118–51058‑2
  55. /Larson15/ Eliza­beth Lar­son, Richard Lar­son: PMI-PBA Cer­ti­fi­ca­ti­on Stu­dy Gui­de, Water­mark Lear­ning, Min­nea­po­lis, Min­ne­so­ta 2015, ISBN 978–0‑578–15547‑0
  56. /Larson16/ Eliza­beth Lar­son, Richard Lar­son: CBAP Cer­ti­fi­ca­ti­on Stu­dy Gui­de v3.0, Water­mark Lear­ning, Min­nea­po­lis, Min­ne­so­ta 2016, ISBN 978–0‑692–69145‑8
  57. /Leffing03/ Dean Lef­fingwell, Don Wid­rig: Mana­ging Soft­ware Requi­re­ments. A Use Case Approach, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2nd Edi­ti­on 2003, ISBN 978–0‑321–12247‑6
  58. /Leffing07/ Dean Lef­fingwell: Sca­ling Soft­ware Agi­li­ty: Best Prac­tices for Lar­ge Enter­pri­ses, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2007, ISBN 978–0‑321–45819‑3
  59. /Leffing10/ Dean Lef­fingwell: Agi­le Soft­ware Requi­re­ments: Lean Requi­re­ments Prac­tices for Teams, Pro­grams, and the Enter­pri­se, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2010, ISBN 978–0‑321–63584‑8
  60. /Moore06/ James W. Moo­re: The Road Map to Soft­ware Engi­nee­ring: A Stan­dards-Based Gui­de, John Wiley & Sons, Hobo­ken, New Jer­sey 2006, ISBBN 978–0‑471–68362‑9
  61. /Naumann18/ Axel-Bru­no Nau­mann: Busi­ness-Ana­ly­se – Sys­te­ma­ti­sches Anfor­de­rungs­ma­nage­ment für nut­zer­ori­en­tier­te Lösun­gen, Dr. Götz Schmidt, Wet­ten­berg 2018, ISBN 978–3‑945997–11‑6
  62. /Niebisch13/ Tho­mas Nie­bisch: Anfor­de­rungs­ma­nage­ment in sie­ben Tagen: Der Weg vom Wunsch zur Kon­zep­ti­on, Sprin­ger, Ber­lin 2013, ISBN 978–3‑642–34856‑3
  63. /Nielsen16/ Klaus Niel­sen: Achie­ve Busi­ness Ana­ly­sis Cer­ti­fi­ca­ti­on: The Com­ple­te Gui­de to PMI-PBA, CBAP and CPRE Exam Suc­cess, J. Ross Publi­shing, Fort Lau­derda­le, Flo­ri­da 2016, ISBN 978–1‑60427–111‑9
  64. /Partsch10/ Hel­muth Partsch: Requi­re­ments-Engi­nee­ring sys­te­ma­tisch: Modell­bil­dung für soft­ware­ge­stütz­te Sys­te­me Sprin­ger, Ber­lin 2. Auf­la­ge 2010, ISBN 978–3‑642–05357‑3
  65. /Patton14/ Jeff Pat­ton: User Sto­ry Map­ping: Dis­co­ver the Who­le Sto­ry, Build the Right Pro­duct, O’Reil­ly Media, Cam­bridge, Mas­sa­chu­setts 2014, ISBN 978–1‑4919–0490‑9
  66. /Patton15/ Jeff Pat­ton: User Sto­ry Map­ping: Nut­zer­be­dürf­nis­se bes­ser ver­ste­hen als Schlüs­sel für erfolg­rei­che Pro­duk­te, O’Reil­ly, Köln 2015, ISBN 978–3‑95875–067‑8
  67. /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
  68. /Pohl08/ Klaus Pohl: Requi­re­ments Engi­nee­ring. Grund­la­gen, Prin­zi­pi­en, Tech­ni­ken, dpunkt, Hei­del­berg 2. Auf­la­ge 2008, ISBN 978–3‑89864–550‑8
  69. /Pohl10/ Klaus Pohl: Requi­re­ments Engi­nee­ring, Sprin­ger, Ber­lin 2010, ISBN 978–3‑642–12577‑5
  70. /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
  71. /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
  72. /REPG16/ Pro­ject Manage­ment Insti­tu­te: Requi­re­ments Manage­ment: A Prac­tice Gui­de, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2016, ISBN 978–1‑62825–089‑3
  73. /Robertson04/ Suzan­ne Robert­son, James Robert­son: Requi­re­ments-Led Pro­ject Manage­ment. Dis­co­vering David’s Slingshot, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2004, ISBN 978–0‑321–18062‑9
  74. /Robertson06/ Suzan­ne Robert­son, James Robert­son: Mas­te­ring the Requi­re­ments Pro­cess, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2nd Edi­ti­on 2006, ISBN 978–0‑321–41949‑1
  75. /Robertson12/ Suzan­ne Robert­son, James Robert­son: Mas­te­ring the Requi­re­ments Pro­cess, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 3rd Edi­ti­on 2012, ISBN 978–0‑321–81574‑3
  76. /Robertson18/ Suzan­ne Robert­son, James Robert­son: Busi­ness Ana­ly­sis Agi­li­ty: Sol­ve the Real Pro­blem, Deli­ver Real Value, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2018, ISBN 978–0‑13–484706‑1
  77. /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
  78. /Rupp13/ Chris Rupp: Sys­tem­ana­ly­se kom­pakt, Sprin­ger View­eg, Ber­lin 3. Auf­la­ge 2013, ISBN 978–3‑642–35445‑8
  79. /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
  80. /Rupp15/ Chris Rupp (und die Sophis­ten): Requi­re­ments-Engi­nee­ring: Die klei­ne RE-Fibel, Han­ser, Mün­chen 2015, ISBN 978–3‑446–44450‑8
  81. /Rupp16/ Chris Rupp (und die Sophis­ten): Requi­re­ments-Engi­nee­ring: Die klei­ne RE-Fibel, Sophist, Nürn­berg, 3. Auf­la­ge 2016, kei­ne ISBN
  82. /Rüping13/ Andre­as Rüping: Doku­men­ta­ti­on in agi­len Pro­jek­ten: Lösungs­mus­ter für ein bedarfs­ge­rech­tes Vor­ge­hen, dpunkt, Hei­del­berg 2013, ISBN 978–3‑86490–040‑2
  83. /Schien01/ Bru­no Schien­mann: Anfor­de­rungs­ma­nage­ment: Pro­zes­se – Tech­ni­ken – Werk­zeu­ge, Addi­son-Wes­ley, Mün­chen 2001, ISBN 978–3‑8273–1787‑2
  84. /Schmidt14/ Götz Schmidt: Orga­ni­sa­ti­on und Busi­ness Ana­ly­sis – Metho­den und Tech­ni­ken, Dr. Götz Schmidt, Wet­ten­berg 15. Auf­la­ge 2014, ISBN 978–3‑921313–93‑0
  85. /Schmied08/ Jür­gen Schmied, Paul-Roux Went­zel, Micha­el Ger­dom: Mit CMMI Pro­zes­se ver­bes­sern! Umset­zungs­stra­te­gi­en am Bei­spiel Requi­re­ments Engi­nee­ring, dpunkt, Hei­del­berg 2008, ISBN 978–3‑89864–538‑6
  86. /Schwinn11/ Hans Schwinn: Requi­re­ments Engi­nee­ring: Model­lie­rung von Anwen­dungs­sys­te­men, Olden­bourg Wis­sen­schafts­ver­lag, Mün­chen 2011, ISBN 978–3‑486–58893‑4
  87. /Sommer97/ Ian Som­mer­vil­le, Pete Sawy­er: Requi­re­ments Engi­nee­ring. A Good Prac­tice Gui­de, John Wiley & Sons, Hobo­ken, New Jer­sey 1997, ISBN 978–0‑471–97444‑4
  88. /Tremp18a/ Hans­rue­di Tremp: Lehr­buch Requi­re­ments Engi­nee­ring Teil 1: Agi­ler und klas­si­scher Werk­zeug­bau­kas­ten zur Pla­nung, Ermitt­lung und Doku­men­ta­ti­on von Anfor­de­run­gen, Books on Demand, Nor­der­stedt, 3. Auf­la­ge 2018, ISBN 978–3‑7448–2055‑4
  89. /Tremp18b/ Hans­rue­di Tremp: Lehr­buch Requi­re­ments Engi­nee­ring Teil 2: Agi­ler und klas­si­scher Werk­zeug­bau­kas­ten zur Ver­wal­tung, Objekt­ori­en­tier­ten Ana­ly­se und Qua­li­täts­si­che­rung von Anfor­de­run­gen, Books on Demand, Nor­der­stedt 2018, ISBN 978–3‑7460–6357‑7
  90. /Tremp19/ Hans­rue­di Tremp: Lehr­buch Requi­re­ments Engi­nee­ring: Agi­ler und klas­si­scher Werk­zeug­bau­kas­ten zur Pla­nung, Ermitt­lung, Ana­ly­se, Model­lie­rung, Doku­men­ta­ti­on und Qua­li­täts­si­che­rung von Anfor­de­run­gen, Books on Demand, Nor­der­stedt 2019, ISBN 978–3‑7392–2783‑2
  91. /Unterauer14/ Mar­kus Unter­au­er: Work­shops im Requi­re­ments Engi­nee­ring. Metho­den, Check­lis­ten und Best Prac­tices für die Ermitt­lung von Anfor­de­run­gen, dpunkt, Hei­del­berg 2014, ISBN 978–3‑86490–231‑4
  92. /Unterauer19/ Mar­kus Unter­au­er: Work­shops im Requi­re­ments Engi­nee­ring. Metho­den, Check­lis­ten und Best Prac­tices für die Ermitt­lung von Anfor­de­run­gen, dpunkt, Hei­del­berg 2. Auf­la­ge 2019, ISBN 978–3‑86490–695‑4
  93. /Versteeg01/ Ger­hard Vers­tee­gen, Knut Salo­mon, Rai­ner Hun­dold: Chan­ge Manage­ment bei Soft­ware-Pro­jek­ten, Sprin­ger, Ber­lin 2001, ISBN 978–3‑540–67809‑0
  94. /Versteegen03/ Ger­hard Vers­tee­gen (Hrsg.), Alex­an­der Heße­ler, Colin Hood, Chris­ti­an Miss­ling, Rena­te Stü­cka: Anfor­de­rungs­ma­nage­ment, Sprin­ger, Ber­lin 2003, ISBN 978–3‑540–00963‑4
  95. /Weese17/ Susan A. Wee­se, Ter­ri Wag­ner: CBAP / CCBA Cer­ti­fied Busi­ness Ana­ly­sis Stu­dy Gui­de, John Wiley & Sons, Hobo­ken, New Jer­sey 2nd Edi­ti­on 2017, ISBN 978–1‑119–24883‑5
  96. /Weilkins14/ Tim Weil­kins: 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
  97. /Wiegers03/ Karl E. Wie­gers: Soft­ware Requi­re­ments, Micro­soft Press, Red­mond, Washing­ton 2nd Edi­ti­on 2003, ISBN 978–0‑7356–1879‑4
  98. /Wiegers05/ Karl E. Wie­gers: Soft­ware-Requi­re­ments, Micro­soft Press Deutsch­land, Mün­chen 2005, ISBN 978–3‑860–63594‑0
  99. /Wiegers06/ Karl E. Wie­gers: More About Soft­ware Requi­re­ments: Thor­ny Issu­es and Prac­ti­cal Advice, Micro­soft Press, Red­mond, Washing­ton 2006, ISBN 978–0‑7356–2267‑8
  100. /Wiegers13/ Karl E. Wie­gers, Joy Beat­ty: Soft­ware Requi­re­ments, Micro­soft Press, Red­mond, Washing­ton 3rd Edi­ti­on 2013, ISBN 978–0‑7356–7966‑5
  101. /Williamson17/ Bri­an Wil­liam­son: PMI-PBA Exam Prac­tice Test and Stu­dy Gui­de, CRC Press, Boca Raton, Flo­ri­da 2017, ISBN 978–1‑138–05447‑9
  102. /Winter19/ Helen Win­ter: The Busi­ness Ana­ly­sis Hand­book, Tech­ni­ques and Ques­ti­ons to Deli­ver Bet­ter Busi­ness Out­co­mes, Kogan Page, Lon­don 2019, ISBN 978–0‑7494–9706‑4
  103. /Withall07/ Ste­phen J. Wit­hall: Soft­ware Requi­re­ment Pat­terns. Best Prac­tices, Micro­soft Press, Red­mond, Washing­ton 2007, ISBN 978–0‑7356–2398‑9
  104. /Young01/ Ralph R. Young: Effec­tive Requi­re­ments Prac­tices, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2nd Edi­ti­on 2001, ISBN 978–0‑201–70912‑4
  105. /Young03/ Ralph R. Young: The Requi­re­ments Engi­nee­ring Hand­book, Artech House Publishers, Nor­wood, Mas­sa­chu­setts 2003, ISBN 978–1‑5805–3266‑2
  106. /Young06/ Ralph R. Young: Pro­ject Requi­re­ments: A Gui­de to Best Prac­tices, Manage­ment Con­cepts, Washing­ton D.C. 2006, ISBN 978–1‑56726–169‑8

A.3 Weblinks

Fol­gen­de Web­links sind für die Busi­ness Ana­ly­sis und das Requi­re­ments Engi­nee­ring nütz­lich:

A.3.1 Fachorganisationen und ‑verbände

A.3.2 Allgemeine Informationen

A.3.3 Regelmäßig stattfindende Messen und Kongresse

A.3.4 Firmen, die Dienstleistungen anbieten

Hier sind nur Fir­men auf­ge­führt, die neben ihren eige­nen Dienst­leis­tun­gen auch einen “neu­tra­len Inhalt” auf ihrer Web­site haben.

A.3.5 Tools

Hier wer­den nur weni­ge Tools gelis­tet; am Markt sind eini­ge Dut­zend ver­tre­ten — eine aus­führ­li­che Lis­te (von Andre­as Birk und Gerald Hel­ler) fin­det sich auf der Web­site Making­of­soft­ware.

  • /DOORS/ DOORS, Tool der Fir­ma IBM
  • /Jama/ Jama, Tool der Fir­ma jama­soft­ware
  • /objectiF/ objec­tiF RM, Tool der Fir­ma micro­TOOL
  • /Polarion/ Pola­ri­on, Tool der Fir­ma Sie­mens

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