Requirements Engineering Anforderungen entwickeln und verwalten

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 Ideen 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 Psychologie.

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

Wo kann ich Sie unter­stüt­zen?
Falls Sie Ihr Requi­re­ments Engi­nee­ring pro­fes­sio­na­li­sie­ren möch­ten, ste­he ich Ihnen eben­so zur Ver­fü­gung wie bei der unmit­tel­ba­ren Umset­zung Ihres Vor­ha­bens. Refe­ren­zen erhal­ten Sie auf Anfra­ge – ers­te Ein­bli­cke aber bereits hier.

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

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

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 wer­den — 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:

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

Inhalts­ver­zeich­nis Ver­ber­gen

1. Einleitung und Grundlagen

Im Requi­re­ments Engi­nee­ring gibt es eine Rei­he von grund­le­gen­den Begrif­fen, die man ken­nen soll­te, wenn man Requi­re­ments Engi­nee­ring betrei­ben möch­te. Die­se wer­den in die­sem Abschnitt vorgestellt.

1.1 Definitionen

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

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

  • “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 Personen.”
  • “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 erreichen.”
  • “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 wer­den in ers­ter Linie die Pro­dukt­an­for­de­run­gen beschrieben.

1.2 Die Einordnung des Requirements Engineerings

Das Requi­re­ments Engi­nee­rings kann als Teil­dis­zi­plin des Sys­tems Engi­nee­rings oder auch des Soft­ware Engi­nee­rings gese­hen wer­den (Abbil­dung 1.1). Somit ist Requi­re­ments Engi­nee­ring nicht auf die Ent­wick­lung von Soft­ware beschränkt, son­dern umfasst auch die Ent­wick­lung von Sys­te­men, die Hard­ware umfassen.

Die Einordnung des Requirements Engineerings, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 1.1: Die Ein­ord­nung des Requi­re­ments Engi­nee­rings (nach Wie­gers /Wiegers13/)

Auch wenn es in Abbil­dung 1.1 nicht (expli­zit) wie­der­ge­ben ist: Auch die Ent­wick­lung von → Dienst­leis­tun­gen kann durch das Requi­re­ments Engi­nee­ring unter­stützt werden.

1.3 Die Unterteilung des Requirements Engineerings

Hier wird das Requi­re­ments Engi­nee­ring in die Berei­che Anfor­de­rungs­ent­wick­lung (Requi­re­ments Deve­lo­p­ment) und → Anfor­de­rungs­ver­wal­tung (→ Requi­re­ments Manage­ment) unter­teilt, wobei die­se wie­der­um in die vier Haupt­tä­tig­kei­ten (auch Hauptaktivitäten) …

unter­glie­dert wer­den kön­nen (Abbil­dung 1.2, 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, 2020-2024

Abbil­dung 1.2: Die Unter­tei­lung des Requi­re­ments Engineerings

Die vier Haupt­ak­ti­vi­tä­ten des Requi­re­ments Engi­nee­rings nach → IREB sind in Tabel­le 1.3 beschrieben.

Die vier Hauptaktivitäten nach IREB, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 1.3: Die vier Haupt­ak­ti­vi­tä­ten nach IREB /IREB21/

1.4 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önnen.

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

Abbil­dung 1.4: Die Anfor­de­rungs­ent­wick­lung (nach IREB /IREB-24/)

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.

1.5 Einige zentrale Begriffe des Requirements Engineerings

Fol­gen­de Begrif­fe zum Requi­re­ments Engi­nee­ring sind von zen­tra­ler Bedeutung:

  • → 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 Vorgaben
  • → Stake­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­ma­na­ger / → Pro­jekt­lei­ter, der Pro­jekt­mit­ar­bei­ter, die Schnittstellen (!), …
  • 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 resultiert
  • 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.6 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 sol­len / könnten.

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

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

In Abbil­dung 1.5 ist bereits ein Kern­pro­blem des Ein­sat­zes von Requi­re­ments mit dar­ge­stellt: Ist der Requi­re­ments Engi­neer mehr auf Kun­den oder auf Ent­wick­ler-Sei­te zu sehen?

1.7 Die 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 betrachtet:

  • Funk­tio­na­le Anforderungen
  • Nicht-funk­tio­na­le Anforderungen
  • Tech­ni­sche Anforderungen
  • Anfor­de­run­gen an die Benutzerschnittstelle
  • Qua­li­täts­an­for­de­run­gen
  • Anfor­de­run­gen an sons­ti­ge Lieferbestandteile
  • Anfor­de­run­gen an die Durch­füh­rung der Entwicklung
  • Recht­lich-ver­trag­li­che Anforderungen
  • Anfor­de­run­gen an Per­so­nen / Mitarbeiter
  • Kun­den- oder Geschäftsanforderungen
  • Lösungs‑, Mar­ke­ting- oder Systemanforderungen
  • Pro­dukt- oder Komponentenanforderungen

1.7.1 Die Klassifikation der Anforderungen

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

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

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

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

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

Die vier Anfor­de­rungs­ty­pen ste­hen in einer hier­ar­chi­schen Bezie­hung zuein­an­der: Die Busi­ness Requi­re­ments ste­hen über den Stake­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 Stake­hol­der oder Solu­ti­on Requi­re­ments zu ermög­li­chen und sind somit nicht aus den ande­ren Requi­re­ments ableitbar.

Die Pfei­le in Abbil­dung 1.7 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 “traceable” (nach­ver­folg­bar).

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

Abbil­dung 1.7: Anfor­de­rungs­ty­pen (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 die → Anfor­de­rungs­ar­ten funk­tio­na­le und nicht-funk­tio­na­le Anfor­de­run­gen unter­teilt. Das IREB geht einen Schritt wei­ter und unter­glie­dert die nicht-funk­tio­na­len Anfor­de­run­gen in Qua­li­täts­an­for­de­run­gen und Rand­be­din­gun­gen. Es ergibt sich fol­gen­des Bild /IREB21, Ebert19/:

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

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

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

1.7.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 aktuell
  • nach­prüf­bar (nach IEEE)
  • rück- und vor­wärts­ver­folg­bar (nach IEEE)
  • (bewer­tet) (nach IEEE)

Beson­ders 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 Auftragnehmer.

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

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

Abbil­dung 1.10: Die drei Per­spek­ti­ven von Anforderungen

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 Abbildung).

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

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

1.8 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 relevant:

  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: /IREB21/, 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önnen.

2. Der Start eines Requirements-Projekts

Der → Start eines RE-Pro­jekts fin­det vor dem “klas­si­schen” Requi­re­ments Engi­nee­ring mit drei Schrit­ten des Requi­re­ments Engi­nee­rings (Ermit­teln, Doku­men­tie­ren, Vali­die­ren) statt (Abbil­dung 2.1).

Einordnung des Starts eines RE-Projekts, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 2.1: Ein­ord­nung des Starts eines RE-Projekts

Der Start eines Requi­re­ments-Pro­jekts oder ‑Vor­ha­bens beginnt mit eini­gen Tätig­kei­ten, die immer durch­ge­führt wer­den sollten.

Dazu gehö­ren:

  1. Bestim­mung der → Visi­on und des Ziels des RE-Vorhabens
  2. Bestim­mung des Sys­tems und des Systemkontexts
  3. Bestim­mung der Stakeholder
  4. Bestim­mung von → Per­so­nas / Szenarios
  5. Anle­gen / Aus­bau­en eines Glossars
  6. Auf­bau eines über­ge­ord­ne­ten → Use Cases
  7. Ein­satz des → Kano-Modells
  8. Zusam­men­stel­len / Berech­nen der “pas­sen­den” → Ermitt­lungs­tech­ni­ken
  9. Beginn mit dem Ermit­teln der Anforderungen

In die­sem Abschnitt wer­den eini­ge die­ser Tätig­kei­ten beleuch­tet. Eine aus­führ­li­che­re Beschrei­bung zum Start eines RE-Pro­jekts fin­den Sie auf die­ser Web­site im Bei­trag “→ Der Start eines Requi­re­ments-Pro­jekts”.

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

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

Abbil­dung 2.2: Sys­tem und → Sys­tem­kon­text

Die 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 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 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

Eine aus­führ­li­che Beschrei­bung zum Sys­tem und Sys­tem­kon­text fin­den Sie auf die­ser Web­site im Bei­trag “→ Sys­tem und Sys­tem­kon­text”.

2.2 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) unterteilt:

  • 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 Wissen”)
  • 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 Wissen”)
  • Begeis­te­rungs­an­for­de­run­gen (delightful or exci­te­ment requi­re­ments) sind Sys­tem­merk­ma­le, die der Stake­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 Wissen”)

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

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

Abbil­dung 2.3: Das Kano-Dia­gramm: Darstellung

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

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

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

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

Abbil­dung 2.4: 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-2024

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

Eine aus­führ­li­che Beschrei­bung zum Kano-Modell fin­den Sie auf die­ser Web­site im Bei­trag “→ Das Kano-Modell”.

2.3 Das Glossar

Spä­tes­tens bei der Ermitt­lung der Anfor­de­run­gen soll­te 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) Fachbegriffe
  • Abkür­zun­gen und Akronyme
  • 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
  • Hom­ony­me (ein Wort hat meh­re­re Bedeutungen)

Wei­te­re Infor­ma­tio­nen fin­den Sie auf der Web­sei­te zu den → Glos­sa­ren.

3. Das Ermitteln von Anforderungen

Bei der → Anfor­de­rungs­er­mitt­lung wer­den die (mög­li­chen) Anfor­de­run­gen für ein zu ent­wi­ckeln­des 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 Produkt.

3.1 Vor dem Start des Ermittelns

Vor dem Start der Anfor­de­rungs­er­mitt­lung muss der → Auf­wand, die → Dau­er und die → Qua­li­tät der Ermitt­lungs­tä­tig­kei­ten bestimmt wer­den. Dar­über sind auch die Kos­ten für die Anfor­de­rungs­er­mitt­lung festgelegt.

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

Die Ermittlungstechniken nach IREB, (C) Peterjohann Consulting, 2021-2024

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

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/ (Abbil­dung 3.5).

Zuordnung Ermittlungstechniken nach Ebert, (C) Peterjohann Consulting, 2021-2024

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

  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 als auch dem Auf­trag­neh­mer sind die­se Anfor­de­run­gen unbekannt
  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 als auch dem Auf­trag­neh­mer sind die­se Anfor­de­run­gen bekannt

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 aus­führ­li­che Beschrei­bung zu den Ermitt­lungs­tech­ni­ken fin­den Sie auf die­ser Web­site im Bei­trag “→ Ermitt­lungs­tech­ni­ken für das Requi­re­ments Engi­nee­ring”. Das Ermit­teln selbst wird aus­führ­lich in dem Bei­trag “→ Das Ermit­teln von Anfor­de­run­gen” beschrie­ben.

4. Das Dokumentieren von Anforderungen

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

  1. Zum einen mit Einzelanforderungen
  2. Zum ande­ren mit dem Zusam­men­stel­len von (Einzel-)Anforderungen in einem Dokument
Aspekte des Dokumentierens, (C) Peterjohann Consulting, 2018-2024

Abbil­dung 4.1: Aspek­te des Dokumentierens

4.1 Das Dokumentieren von Einzelanforderungen

Ein­zel­an­for­de­run­gen kön­nen entweder …

  • natür­lich­sprach­lich,
  • modell­ba­siert oder
  • als Misch­form beschrie­ben werden.
Die Dokumentationsformen nach IREB, (C) Peterjohann Consulting, 2021-2024

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

In der Pra­xis wer­den alle For­men eingesetzt.

4.1.1 Die Satzschablone

→ Satz­scha­blo­nen die­nen der Erfas­sung von Ein­zel­an­for­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 beschrieben.

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

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

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

Wenn Satz­scha­blo­nen kon­se­quent und rich­tig ein­ge­setzt wer­den, redu­ziert sich der Inter­pre­ta­ti­ons­spiel­raum erheb­lich — die Anfor­de­run­gen wer­den eindeutiger.

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 Anfor­de­rungs­spe­zi­fi­ka­ti­on 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 Kun­den / Stake­hol­dern als 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 verwendet:

  • Das Vole­re-Tem­p­la­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 in dem Bei­trag “→ Las­ten­heft und Pflich­ten­heft”.

Eine ver­tie­fen­de Beschrei­bung des Doku­men­tie­rens von Ein­zel­an­for­de­run­gen fin­den Sie auf die­ser Web­site im Bei­trag “→ Das Doku­men­tie­ren von Anfor­de­run­gen”.

5. Das Validieren von Anforderungen

Das Vali­die­ren (frü­her: 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 Stake­hol­der noch­mals über­prüft und prio­ri­siert werden.

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

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­aspek­te im Vordergrund:

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

Für die drei Qua­li­täts­aspek­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 von Anforderungen nach IREB, (C) Peterjohann Consulting, 2021-2024

Abbil­dung 5.2: Die drei Qua­li­täts­aspek­te von Anfor­de­run­gen (nach IREB /IREB21/)

Das IREB benennt vier Aspek­te der → Anfor­de­rungs­va­li­die­rung (Abbil­dung 5.3). Die­se soll­ten bei der Pla­nung und Durch­füh­rung der Vali­die­rung beach­tet werden.

Die vier Aspekte der Anforderungsvalidierung, (C) Peterjohann Consulting, 2021-2024

Abbil­dung 5.3: Die vier Aspek­te der Anfor­de­rungs­va­li­die­rung (nach IREB /IREB21/)

Als Vali­die­rungs­tech­ni­ken zur (inhalt­li­chen Prü­fung) kön­nen ein­ge­setzt wer­den (Abbil­dung 5.4):

  • → Reviews
  • Explo­ra­ti­on (Prü­fung durch Pro­to­ty­pen oder ande­re greif­ba­re Artefakte)
  • Pro­be-Ent­wick­lung
Die Techniken zur Validierung von Anforderungen, (C) Peterjohann Consulting, 2021-2024

Abbil­dung 5.4: Die Tech­ni­ken zur Vali­die­rung von Anfor­de­run­gen (modi­fi­ziert nach IREB /IREB21/)

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

Eine ver­tie­fen­de Beschrei­bung des Vali­die­rens von Anfor­de­run­gen fin­den Sie auf die­ser Web­site im Bei­trag “→ Das Vali­die­ren von Anfor­de­run­gen”.

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 (Requi­re­ments Manage­ment) 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 Produkt
  • → Chan­ge Manage­ment: Erfas­sen und Umset­zen von Änderungen

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

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

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

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

  • Ein­fluss­ana­ly­se (Impact Ana­ly­sis): Sie zeigt auf, wie sich Anfor­de­run­gen bei der Umset­zung auf die gesam­te Lösung auswirken
  • Abde­ckungs­ana­ly­se (Covera­ge Ana­ly­sis): 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
  • Nut­zen­ana­ly­se (Bene­fit Ana­ly­sis): 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 wurden

Der zen­tra­le Begriff der Anfor­de­rungs­ver­wal­tung ist sicher­lich die → Ver­folg­bar­keit (→ Tracea­bi­li­ty), die von der Kun­den­an­for­de­rung bis zur Pro­duk­tei­gen­schaft die ein­zel­nen Umset­zungs­schrit­te trans­pa­rent macht. Hier­zu soll­ten pro Anfor­de­rung zumin­dest fol­gen­de → Anfor­de­rungs­at­tri­bu­te notiert werden:

  • Ein­deu­ti­ge ID
  • Name / Bezeichnung
  • Zuord­nung zu einem Pro­jekt, einem Vor­ha­ben oder einem Produkt
  • 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 festgehalten.

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

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

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

  • 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 Anforderungen
  • 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 Prozess
  • 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ürfen
  • Über die Umset­zung von Ände­run­gen ent­schei­den fest­ge­leg­te Instan­zen, im Zwei­fel der Pro­jekt­ma­na­ger / 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 erleichtern.

Eine ver­tie­fen­de Beschrei­bung des Ver­wal­tens von Anfor­de­run­gen fin­den Sie auf die­ser Web­site im Bei­trag “→ Anfor­de­rungs­ver­wal­tung — Requi­re­ments Manage­ment”.

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

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

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

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 meis­ten Tech­ni­ker nicht unbe­dingt Ger­ma­nis­ten und nicht gewohnt, ihre Ideen klar und all­ge­mein­ver­ständ­lich zu formulieren
  • 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 Nutzen

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

(Rubrik “|Deutsch für …”) auf der pri­va­ten Web­site des Autors hin­zu­ge­zo­gen werden.

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

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 beispielsweise

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

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

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 in der Busi­ness Ana­ly­sis in ein­zel­ne Berei­che. Die­se hei­ßen bei …

  • dem IREB Haupt­ak­ti­vi­tä­ten /IREB-24, IREB21/,
  • dem IIBA Know­ledge Are­as (Über­set­zung: → Wis­sens­ge­bie­te) /BBG5, BBG17‑d/ und
  • dem PMI Domains (eige­ne Über­set­zung: Domä­nen) /BAPG15/.
Die Aufgabenunterteilung der drei Fachverbände zum RE und zur BA, (C) Peterjohann Consulting, 2017-2024

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 oder den Buch­ab­schnitt des dazu­ge­hö­ri­gen Basis­werks wieder.

Hier­zu:

  • Die Unter­tei­lung in die Berei­che ist nicht als stren­ger Ablauf zu interpretieren
  • Jedem Bereich sind meh­re­re Werk­zeu­ge und Metho­den (Tools and Tech­ni­ques) zuge­ord­net
  • Beim IREB ist das zen­tra­le Basis­werk zuletzt 2021, bei den bei­den ande­ren Fach­ver­bän­den 2015 erschienen
  • Die Unter­tei­lun­gen sind nicht “gleich gewich­tet” — Aber: Bei allen Fach­ver­bän­den steht das Ermit­teln / die Ermitt­lung (Eli­ci­ta­ti­on) von Anfor­de­run­gen im Vordergrund

Das IREB benennt vier Haupt­ak­tivä­ten (Abbil­dung 8.2), es fehlt jedoch 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 sollen.

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

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

In Abbil­dung 8.3 sind die Wis­sens­ge­bie­te des IIBA dar­ge­stellt. Gene­rell beschäf­tigt sich das IIBA 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 adressiert.

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

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

Die fünf Domä­nen der BA nach PMI ähneln den sechs Wis­sens­ge­bie­ten des IIBA sehr stark. Auch die dar­un­ter­lie­gen Tasks (hier in Abbil­dung 8.4 nicht dar­ge­stellt) mit den Werk­zeu­gen und Metho­den sind ähn­lich wie beim IIBA aufgebaut.

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

Abbil­dung 8.4: Die fünf Domä­nen in der Busi­ness Ana­ly­sis nach PMI /BAPG15/

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 auf die­ser Web­site im Bei­trag den “→ 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 wiedergegeben.

  • 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. Hier ist ins­be­son­de­re das → Sys­tems Engi­nee­ring zu nennen.
  • F: Ist eine Schu­lung zum RE und / oder zur BA emp­feh­lens­wert?
    A: Ja. Da das RE kein abge­schlos­se­nes The­men­ge­biet dar­stellt, ist es schwie­rig her­aus­zu­fin­den oder her­aus­zu­fil­tern, wel­che RE-Ele­men­te in dem eige­nen Kon­text benö­tigt wer­den. Ent­spre­chend soll­ten die Schu­lun­gen an den eige­nen Kon­text ange­passt werden.
  • 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 star­te ich ein Requi­re­ments-Engi­nee­ring-Pro­jekt rich­tig?
    A: Sie kön­nen ein Requi­re­ments-Engi­nee­ring-Vor­ha­ben oder ‑Pro­jekt mit Ein­zel­schrit­ten begin­nen, die auf mei­ner Web­sei­te “→ Start eines Requi­re­ments-Pro­jekts” beschrie­ben sind.
  • F: Wie füh­re ich (pro­fes­sio­nel­les) Requi­re­ments Engi­nee­ring ein?
    A: Fra­gen Sie mich.
  • F: Wie bestim­me ich den Rei­fe­grad mei­nes Requi­re­ments Engi­nee­rings?
    A: Fra­gen Sie mich.
  • F: Gibt es ein­fa­che Merk­re­geln / Tipps für das Requi­re­ments Engi­nee­ring, die unbe­dingt beach­tet wer­den sol­len?
    A: Ja — bei unter­schied­li­chen Fach­ver­bän­den und Autoren gibt es Merk­re­geln oder Tipps, die auf mei­ner Web­sei­te “→ Merk­re­geln für das Requi­re­ments Engi­nee­ring” beschrie­ben sind.
  • F: Muss ein Requi­re­ments-Engi­nee­ring-Hand­buch oder Requi­re­ments-Engi­nee­ring-Leit­fa­den in mei­ner Orga­ni­sa­ti­on / in mei­nem Unter­neh­men 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 fixiert wer­den — hier­für bie­tet sich ein Requi­re­ments-Engi­nee­ring-Hand­buch an.

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

A.1 Meine Präsentationen und Veröffentlichungen

Zum Requi­re­ments Engi­nee­ring habe ich eini­ge → Prä­sen­ta­tio­nen, Aus­ar­bei­tun­gen und Bei­trä­ge ver­fasst, von denen ein Teil hier für den pri­va­ten Gebrauch zur Ver­fü­gung gestellt werden.

A.1.1 Meine öffentlichen RE-Präsentationen

Die nach­fol­gen­de RE-Basis­prä­sen­ta­ti­on gibt Ihnen einen ers­ten Ein­blick in das Requi­re­ments Engi­nee­ring. Zusätz­lich wer­den hier eini­ge wei­te­re Prä­sen­ta­tio­nen ergän­zend zur Ver­fü­gung gestellt.

Inhalt Ver­si­on Stand Sei­ten Grö­ße 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)

0.96 03/2017 248 1,3 MB pdf

Requi­re­ments Engi­nee­ring: Spe­zi­fi­ka­tio­nen – Eine Übersicht

1.50 12/2016 44 0,3 MB pdf

Requi­re­ments Engi­nee­ring: Werk­zeu­ge und Metho­den – Eine Übersicht

0.20 12/2018 32 0,4 MB pdf

Requi­re­ments Engi­nee­ring: Die Literatur(liste)

1.00 07/2020 28 0,3 MB pdf

Agi­li­tät: Agi­les Requi­re­ments Engi­nee­ring – Eine Übersicht

0.10 05/2014 84 0,8 MB pdf

Pro­jekt­ma­nage­ment: Stake­hol­der­ma­nage­ment – Eine Übersicht

0.10 03/2015 138 0,8 MB pdf

Agi­li­tät: Per­so­nas – Eine Übersicht

0.20 06/2018 48 0,5 MB 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 Seiten 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 Seiten pdf

A.2 Literatur

Die Anzahl an ver­füg­ba­rer Lite­ra­tur (Bücher) zum Requi­re­ments Engi­nee­ring und zur Busi­ness 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, Ljer­ka Beus-Dukic: Dis­co­ve­ring Requi­re­ments: How to Spe­ci­fy Pro­ducts 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­ti­ce 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. /BAPG15/ Pro­ject Manage­ment Insti­tu­te: Busi­ness Ana­ly­sis For Prac­ti­tio­ners: A Prac­ti­ce Gui­de, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2015, ISBN 978–1‑62825–069‑5
  8. /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
  9. /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
  10. /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
  11. /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
  12. /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
  13. /Bergsmann18/ Johan­nes Berg­s­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­gien, dpunkt, 2. Auf­la­ge Hei­del­berg 2018, ISBN 978–3‑86490–485‑1
  14. /Bergsmann23/ Johan­nes Berg­s­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­gien, dpunkt, Hei­del­berg 3. Auf­la­ge 2023, ISBN 978–3‑86490–929‑0
  15. /Blais11/ Ste­phen Blais: Busi­ness Ana­ly­sis: → Best Prac­ti­ces for Suc­cess, John Wiley & Sons, Hobo­ken, New Jer­sey 2011, ISBN 978–1‑118–07600‑2
  16. /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
  17. /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
  18. /Carkenord09/ Bar­ba­ra A. Car­ken­ord: Seven Steps to Mas­te­ring Busi­ness Ana­ly­sis, J. Ross Publi­shing, Fort Lau­derd­a­le, Flo­ri­da 4th Edi­ti­on 2009, ISBN 978–1‑60427–007‑5
  19. /Carkenord16/ Bar­ba­ra A. Car­ken­ord: PMI-PBA Exam Prep, Pre­mier Edi­ti­on, RMC Publi­ca­ti­ons, Burns­ville, Min­ne­so­ta 2nd Edi­ti­on 2016, ISBN 978–1‑943704–01‑9
  20. /Cockburn00/ Ali­s­ta­ir Cockb­urn: Wri­ting Effec­ti­ve Use Cases, Addi­son-Wes­ley Long­man, Ams­ter­dam 2000, ISBN 978–0‑201–70225‑5
  21. /Davis05/ Alan M. Davis: Just Enough Requi­re­ments Manage­ment: Whe­re Soft­ware Deve­lo­p­ment Meets Mar­ke­ting, Dor­set House Publi­shing, New York 2005, ISBN 978–0‑932633–64‑4
  22. /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
  23. /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
  24. /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
  25. /Ebert22/ 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 7. Auf­la­ge 2022, ISBN 978–3‑86490–919‑1
  26. /Fitzpatrick13/ Rob Fitz­pa­trick: The Mom Test: How to talk to cus­to­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
  27. /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
  28. /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
  29. /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
  30. /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
  31. /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
  32. /Girvan17/ Lyn­da Gir­van, Debra Paul: Agi­le and Busi­ness Ana­ly­sis: Prac­ti­cal gui­dance 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
  33. /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
  34. /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
  35. /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
  36. /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
  37. /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
  38. /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 Vie­w­eg, Wies­ba­den 2. Auf­la­ge 2014, ISBN 978–3‑658–06434‑1
  39. /Haberfellner18/ Rein­hard Haber­fell­ner, Oli­vi­er 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 14. Auf­la­ge 2018, ISBN 978–3‑280–04179‑6
  40. /Haberfellner19/ Rein­hard Haber­fell­ner, Oli­vi­er L. de Weck, Ernst Fri­cke, Sieg­fried Vöss­ner: Sys­tems Engi­nee­ring. Fun­da­men­tals and Appli­ca­ti­ons, Sprin­ger Inter­na­tio­nal Publi­shing, Basel 2019, ISBN 978–3‑030–13430‑3
  41. /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
  42. /Hanschke16/ Inge Hansch­ke, Gun­nar Gie­sin­ger, Dani­el Goet­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
  43. /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
  44. /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
  45. /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
  46. /Hood07b/ Colin Hood, Simon Wie­demann, Ste­fan Ficht­in­ger, Urte Pautz: Requi­re­ments Manage­ment: The Inter­face Bet­ween Requi­re­ments Deve­lo­p­ment and All Other Sys­tems Engi­nee­ring Pro­ces­ses, Sprin­ger, Ber­lin 2007, ISBN 978–3‑540–47689‑4
  47. /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
  48. /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
  49. /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
  50. /Hruschka23/ 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 3. Auf­la­ge 2023, ISBN 978–3‑446–47692‑9
  51. /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
  52. /IREB15/ sie­he /Pohl15a/
  53. /IREB21/ sie­he /Pohl21/
  54. /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
  55. /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
  56. /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
  57. /Kotonya98/ Gerald Kot­onya, Ian Som­mer­ville: Requi­re­ments Engi­nee­ring: Pro­ces­ses and Tech­ni­ques, John Wiley & Sons, Hobo­ken, New Jer­sey 1998, ISBN 978–0‑471–97208‑2
  58. /Kupersmith13/ 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
  59. /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
  60. /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
  61. /Lauenroth16/ Kim Lau­en­roth, Fabi­an Schrei­ber, Felix Schrei­ber: Maschi­nen- und Anla­gen­bau im digi­ta­len Zeit­al­ter. Requi­re­ments Engi­nee­ring als sys­te­ma­ti­sche Gestal­tungs­kom­pe­tenz für die Fer­ti­gungs­in­dus­trie, VDE Ver­lag, Ber­lin 2016, ISBN 978–3‑8007–4154‑0
  62. /Leffingwell03/ Dean Lef­fing­well, 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
  63. /Leffingwell07/ Dean Lef­fing­well: Sca­ling Soft­ware Agi­li­ty: Best Prac­ti­ces 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
  64. /Leffingwell10/ Dean Lef­fing­well: Agi­le Soft­ware Requi­re­ments: → Lean Requi­re­ments Prac­ti­ces 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
  65. /Lovelock19/ Chris­ti­na Love­lock, Debra Paul: Deli­ve­ring Busi­ness Ana­ly­sis. The BA Ser­vice Hand­book, BCS, The Char­te­red Insti­tu­te for IT, Lon­don 2019, ISBN 978–1‑78017–468‑6
  66. /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
  67. /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
  68. /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
  69. /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­derd­a­le, Flo­ri­da 2016, ISBN 978–1‑60427–111‑9
  70. /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
  71. /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
  72. /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
  73. /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
  74. /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
  75. /Pohl10/ Klaus Pohl: Requi­re­ments Engi­nee­ring. Fun­da­men­tals, Prin­ci­ples, and Tech­ni­ques, Sprin­ger, Ber­lin 2010, ISBN 978–3‑642–12577‑5
  76. /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
  77. /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
  78. /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
  79. /REPG16/ Pro­ject Manage­ment Insti­tu­te: Requi­re­ments Manage­ment: A Prac­ti­ce Gui­de, Pro­ject Manage­ment Insti­tu­te, Phil­adel­phia, Penn­syl­va­nia 2016, ISBN 978–1‑62825–089‑3
  80. /Robertson04/ Suzan­ne Robert­son, James Robert­son: Requi­re­ments-Led Pro­ject Manage­ment. Dis­co­ve­ring David’s Slingshot, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2004, ISBN 978–0‑321–18062‑9
  81. /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
  82. /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
  83. /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
  84. /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
  85. /Rupp13/ Chris Rupp: Sys­tem­ana­ly­se kom­pakt, Sprin­ger Vie­w­eg, Ber­lin 3. Auf­la­ge 2013, ISBN 978–3‑642–35445‑8
  86. /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
  87. /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
  88. /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
  89. /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
  90. /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
  91. /Schienmann01/ 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
  92. /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
  93. /Schmidt20/ 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 16. Auf­la­ge 2020, ISBN 978–3‑945997–17‑8
  94. /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­gien am Bei­spiel Requi­re­ments Engi­nee­ring, dpunkt, Hei­del­berg 2008, ISBN 978–3‑89864–538‑6
  95. /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
  96. /Sommerville97/ Ian Som­mer­ville, Pete Sawy­er: Requi­re­ments Engi­nee­ring: A → Good Prac­ti­ce Gui­de, John Wiley & Sons, Hobo­ken, New Jer­sey 1997, ISBN 978–0‑471–97444‑4
  97. /Tremp18a/ Hans­ruedi 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
  98. /Tremp18b/ Hans­ruedi 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
  99. /Tremp19/ Hans­ruedi 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
  100. /Tremp20/ Hans­ruedi 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 2. Auf­la­ge 2020, ISBN 978–3‑7526–0249‑4
  101. /Unterauer14/ Mar­kus Unter­au­er: Work­shops im Requi­re­ments Engi­nee­ring. Metho­den, Check­lis­ten und Best Prac­ti­ces für die Ermitt­lung von Anfor­de­run­gen, dpunkt, Hei­del­berg 2014, ISBN 978–3‑86490–231‑4
  102. /Unterauer19/ Mar­kus Unter­au­er: Work­shops im Requi­re­ments Engi­nee­ring. Metho­den, Check­lis­ten und Best Prac­ti­ces 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
  103. /Versteegen01/ 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
  104. /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
  105. /Weese17/ Sus­an A. Weese, 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
  106. /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
  107. /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
  108. /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
  109. /Wiegers06/ Karl E. Wie­gers: More About Soft­ware Requi­re­ments: Thor­ny Issues and Prac­ti­cal Advice, Micro­soft Press, Red­mond, Washing­ton 2006, ISBN 978–0‑7356–2267‑8
  110. /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
  111. /Wiegers21/ Karl Wie­gers: Soft­ware Deve­lo­p­ment Pearls. Les­sons from Fif­ty Years of Soft­ware Expe­ri­ence, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2021, ISBN 978–0‑13–748777‑6
  112. /Wiegers23/ Karl Wie­gers, Can­da­se Hokan­son: Soft­ware Requi­re­ments Essen­ti­als. Core Prac­ti­ces for Suc­cessful Busi­ness Ana­ly­sis, Addi­son-Wes­ley Pro­fes­sio­nal, Bos­ton, Mas­sa­chu­setts 2023, ISBN 978–0‑13–819028‑6
  113. /Williamson17/ Bri­an Wil­liam­son: PMI-PBA Exam Prac­ti­ce Test and Stu­dy Gui­de, CRC Press, Boca Raton, Flo­ri­da 2017, ISBN 978–1‑138–05447‑9
  114. /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
  115. /Winteroll21/ Mar­cus Win­teroll: Requi­re­ments Engi­nee­ring für Dum­mies, Wiley-VCH, Wein­heim 2021, ISBN 978–3‑527–71635‑7
  116. /Withall07/ Ste­phen J. Wit­hall: Soft­ware Requi­re­ment Pat­terns. Best Prac­ti­ces, Micro­soft Press, Red­mond, Washing­ton 2007, ISBN 978–0‑7356–2398‑9
  117. /Young01/ Ralph R. Young: Effec­ti­ve Requi­re­ments Prac­ti­ces, 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
  118. /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
  119. /Young06/ Ralph R. Young: Pro­ject Requi­re­ments: A Gui­de to Best Prac­ti­ces, Manage­ment Con­cepts, Washing­ton D.C. 2006, ISBN 978–1‑56726–169‑8

Nach­fol­gen­de auf­ge­führ­te Web­links sind für das Requi­re­ments Engi­nee­ring und die Busi­ness Ana­ly­sis nützlich.

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 RE-Tools

Hier wer­den nur weni­ge RE-Tools gelis­tet; am Markt sind eini­ge Dut­zend ver­tre­ten — eine aus­führ­li­che → Lis­te fin­det sich auf der Web­site Making­ofsoft­ware.

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