Merkregeln für das Requirements Engineering Leitlinien für die Umsetzung

Manage­ment-Zusam­men­fas­sung die­ses Bei­trags:
Es gibt eini­ge Merkregeln(-Sammlungen) zum → Requi­re­ments Engi­nee­ring, die bei der Umset­zung von Requi­re­ments-Pro­jek­ten beach­tet wer­den soll­ten.
Eini­ge die­ser Merk­re­geln wer­den in die­sem Bei­trag vorgestellt.

Merk­re­geln hel­fen, wesent­li­che Aspek­te eines Requi­re­ments-Pro­jekts oder ‑Vor­ha­bens zu berück­sich­ti­gen. Die Merk­re­geln kön­nen als Check­lis­te betrach­tet werden.

Bei den Merk­re­geln wird häu­fig zwi­schen Erfolgs­fak­to­ren (“das soll­ten Sie unbe­dingt beach­ten”) und Miss­erfolgs­fak­to­ren (“wenn Sie dies tun, wer­den Sie Schwie­rig­kei­ten bekom­men”) unter­schie­den (Abbil­dung 1).

Merkregeln für das Requirements Engineering: Unterteilung, (C) Peterjohann Consulting, 2020-2024

Abbil­dung 1: Merk­re­geln für das Requi­re­ments Engi­nee­ring: Unterteilung

In der Regel wer­den eher die Erfolgs­fak­to­ren genannt.

1. Meine Merkregeln für das Requirements Engineering

Mei­ne Merk­re­geln resul­tie­ren aus mei­nen Erfah­run­gen und den von mir gehal­te­nen Schu­lun­gen / Trai­nings zum Requi­re­ments Engineering.

  • Requi­re­ments Engi­nee­ring kos­tet Zeit und Geld: Dies muss Ihnen (und Ihren Geld­ge­bern) bewusst sein, wenn Sie pro­fes­sio­nel­les Requi­re­ments Engi­nee­ring eta­blie­ren. Erstel­len Sie (als Requi­re­ments-Ver­ant­wort­li­cher) ein Mengen‑, Zeit- und Kos­ten­ge­rüst und ver­su­chen Sie einen Spon­sor aus dem Manage­ment zu fin­den, der Sie bei der Ein­füh­rung unterstützt
  • ABC — “Allo­ca­ti­on Befo­re Com­mit­ment” — “Erst zuord­nen, dann zustim­men”: Ord­nen Sie die Anfor­de­run­gen erst einem Bereich zu, bevor Sie eine Zusa­ge zur Umset­zung geben
  • Beach­ten Sie “die Flug­hö­he”: Es macht einen gro­ßen Unter­schied, ob Sie Anfor­de­run­gen für die Busi­ness-Ebe­ne oder für die tech­ni­sche Ebe­ne ent­wi­ckeln müssen
  • “Requi­re­ments Engi­nee­ring endet nie”: Requi­re­ments Engi­nee­ring ist eine kon­ti­nu­ier­li­che Auf­ga­be und ein Requi­re­ments-Pro­jekt endet erst, wenn das betrach­te­te Objekt (Pro­dukt oder Dienst­leis­tung) aus dem Markt genom­men wird
  • Requi­re­ments Engi­nee­ring geschieht immer in einem Kon­text: Hin­ter­fra­gen Sie daher früh­zei­tig, war­um Requi­re­ments Engi­nee­ring betrie­ben wer­den soll und ob der → Auf­wand / die Kos­ten für das Requi­re­ments Engi­nee­ring gerecht­fer­tigt ist, es also eine Wert­schöp­fung aus dem Requi­re­ments Engi­nee­ring erfolgt

2. Merkregeln anderer Autoren

In eini­gen Büchern / von eini­gen Autoren gibt es Merk­re­geln zum Requi­re­ments Engi­nee­ring. Hier sind eini­ge davon aufgeführt.

2.1 Die neun Prinzipien nach IREB

Das → IREB – Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board — benennt neun Prin­zi­pi­en für das (gute) Requi­re­ments Engi­nee­ring /IREB-24/:

  1. Wert­ori­en­tie­rung: Anfor­de­run­gen sind Mit­tel zum Zweck, kein Selbstzweck
  2. → Stake­hol­der: Im RE geht es dar­um, die Wün­sche und Bedürf­nis­se der Stake­hol­der zu befriedigen
  3. Gemein­sa­mes Ver­ständ­nis: Erfolg­rei­che Sys­tem­ent­wick­lung ist ohne eine gemein­sa­me Basis nicht möglich
  4. Kon­text: Sys­te­me kön­nen nicht iso­liert ver­stan­den werden
  5. → Pro­blem – Anfor­de­rung – Lösung: Ein unaus­weich­lich inein­an­der­grei­fen­des Tripel
  6. Vali­die­rung: Nicht-vali­dier­te Anfor­de­run­gen sind nutzlos
  7. → Evo­lu­ti­on: Sich ändern­de Anfor­de­run­gen sind kein Unfall, son­dern der Normalfall
  8. Inno­va­ti­on: Mehr vom Glei­chen ist nicht genug
  9. Sys­te­ma­ti­sche und dis­zi­pli­nier­te Arbeit: Wir kön­nen im RE nicht dar­auf verzichten

2.2 Die Top-10-Tipps nach Ebert

Ebert /Ebert19/ benennt fol­gen­de Top-10-Tipps zum Requi­re­ments Engineering:

  1. Arbei­ten Sie pro­fes­sio­nell bei allem, was Sie tun
  2. Schaf­fen Sie kla­re Ver­ant­wor­tun­gen für Ergebnisse
  3. Ver­wen­den Sie stan­dar­di­sier­te → Vor­la­gen
  4. Schaf­fen sie Wert: “Wow” statt unnö­ti­ger Funktionen
  5. Ska­lie­ren Sie agi­le Tech­ni­ken für Ihre Umgebung
  6. Good enough: Lie­fern Sie hin­rei­chend gute → Qua­li­tät
  7. ABC: Ent­wi­ckeln Sie nur ver­ein­bar­te Anforderungen
  8. Ver­fol­gen Sie den Sta­tus der Anforderungen
  9. Lie­fern Sie → inkre­men­tell mit prio­ri­sier­ten Anforderungen
  10. Ler­nen Sie von ande­ren und ver­bes­sern Sie sich messbar

Anmer­kung:
Die ABC-Regel bedeu­tet “Allo­ca­ti­on Befo­re Com­mit­ment”: Wenn Anfor­de­run­gen auf­tau­chen, soll­te der → Requi­re­ments Engi­neer die­se erst einem Kon­text zuord­nen, bevor eine Umset­zungs­zu­sa­ge erfolgt.

In der 7. Auf­la­ge des Buchs von Ebert /Ebert22/ wur­den eini­ge Tipps ersetzt.
Nun wer­den als Top-10-Tipps genannt:

  1. Pro­fes­sio­na­li­tät: Arbei­ten Sie pro­fes­sio­nell bei allem, was Sie anpa­cken. Hal­ten Sie Ihre Ver­pflich­tun­gen ein und lie­fern Sie Qualität
  2. → Zie­le: “Begin with the end in mind.” Set­zen Sie her­aus­for­dern­de Zie­le und lie­fern Sie mess­ba­re Ergebnisse
  3. Ver­ant­wor­tung: Schaf­fen Sie kla­re Ver­ant­wor­tun­gen mit Geschäfts­nut­zen. Kei­ne kom­ple­xen Ver­ant­wor­tungs­ta­bel­len, son­dern ver­läss­li­che Abstimmungen
  4. → Effi­zi­enz: Ver­wen­den Sie Stan­dards und Vor­la­gen. “First time right”
  5. Wert­ori­en­tie­rung: Schaf­fen Sie Wert. “Wow” statt unnö­ti­ger Funktionen
  6. RACE: Redu­ce Acci­dents, Con­trol Essence: Die → Pro­duk­ti­vi­tät wird ver­bes­sert, wenn Unfäl­le, → Feh­ler und unnö­ti­ge Ände­run­gen ver­rin­gert wer­den und das Wesent­li­che kon­trol­liert gelie­fert wird. Das Ebert-Gesetz fokus­siert auf Wert statt → Kom­ple­xi­tät
  7. Agi­li­tät: Lie­fern Sie hin­rei­chend gute Qua­li­tät. Ska­lie­ren Sie agi­le Tech­ni­ken für Ihre Umge­bung. Arbei­ten Sie inkre­men­tell mit prio­ri­sier­ten Anforderungen
  8. → Risi­ko­ma­nage­ment: Ver­fol­gen Sie die Anfor­de­run­gen im Pro­jekt und Pro­dukt. Ent­wi­ckeln Sie nur ver­ein­bar­te Anforderungen
  9. Win-win: Ändern Sie die Per­spek­ti­ve: Der ande­re könn­te recht haben. Suchen Sie nach Lösun­gen, die bei­den Par­tei­en helfen
  10. Ler­nen: Sei­en Sie nie­mals zufrie­den. Blei­ben Sie ehr­gei­zig und pro­bie­ren Sie neue Din­ge. Ler­nen Sie von ande­ren. Ver­bes­sern Sie sich ständig

2.3 Die zehn Prinzipien des Requirements Engineerings nach Winteroll

Win­teroll /Winteroll21/ lis­tet zehn Prin­zi­pi­en zum Requi­re­ments Engi­nee­ring auf, die auf den neun Prin­zi­pi­en des IREB-Lehr­plans /IREB-24/ basieren: 

  1. Zusam­men­ar­beit: Requi­re­ments Engi­nee­ring allein funk­tio­niert nicht 
  2. Wert­ori­en­tie­rung: Anfor­de­run­gen sind kein Selbstzweck 
  3. Stake­hol­der: Es geht dar­um, ihren Bedarf zu erfüllen 
  4. Gemein­sa­mes Ver­ständ­nis: Die Basis für erfolg­rei­che Systementwicklung 
  5. Kon­text: Not­wen­dig, um Sys­te­me zu verstehen 
  6. Pro­blem, Anfor­de­rung, Lösung: Eine untrenn­ba­re Verbindung 
  7. Vali­die­rung: Unge­prüf­te Anfor­de­run­gen sind nutzlos 
  8. Evo­lu­ti­on: Ände­run­gen sind normal 
  9. Inno­va­ti­on: Mehr vom Glei­chen reicht nicht 
  10. Sys­te­ma­ti­sche und dis­zi­pli­nier­te Arbeit: Ohne geht es nicht

2.4 Zehn wichtige Ratschläge zur erfolgreichen Anforderungsermittlung nach Sommerville

Som­mer­ville /Sommerville97/ gibt zehn Rat­schlä­ge zur erfolg­rei­chen → Anfor­de­rungs­er­mitt­lung, die dann zu einem guten Anfor­de­rungs­do­ku­ment führen: 

  1. Defi­nie­re eine → Stan­dard-Glie­de­rung für das Dokument 
  2. Gestal­te das Doku­ment änderungsfreundlich 
  3. Gib jeder Anfor­de­rung eine ein­deu­ti­ge Bezeichnung
  4. Defi­nie­re eine Vor­ge­hens­wei­se bei Ände­rung der Anforderungen 
  5. Defi­nie­re Stan­dard-Vor­la­gen für die Beschrei­bung von Einzelanforderungen 
  6. Ver­wen­de eine ein­fa­che, kon­sis­ten­te und knap­pe Sprache 
  7. Orga­ni­sie­re for­mel­le Begut­ach­tun­gen der Anforderungen 
  8. Defi­nie­re → Check­lis­ten für die Begut­ach­tung von Anforderungen 
  9. Benut­ze Check­lis­ten zur Anforderungsanalyse 
  10. Rech­ne von vorn­her­ein mit Kon­flik­ten und pla­ne die Konfliktauflösung

2.5 Die 16 Lektionen nach Wiegers

Wie­gers /Wiegers21/ benennt 16 Les­sons / Lek­tio­nen zum Requi­re­ments Engi­nee­ring, die auf sei­ner lan­gen Erfah­rung als Requi­re­ments Engi­neer beruhen:

  1. If you don’t get the requi­re­ments right, it does­n’t mat­ter how well you exe­cu­te the rest of the project
  2. The key deli­ver­a­bles from requi­re­ments deve­lo­p­ment are a shared → visi­on and understanding
  3. Nowhe­re more than in the requi­re­ments do the inte­rests of all the stake­hol­ders intersect
  4. A usa­ge-cen­tric approach to requi­re­ments will meet cus­to­mer needs bet­ter than a → fea­ture-cen­tric approach
  5. Requi­re­ments deve­lo­p­ment demands iteration
  6. Agi­le requi­re­ments are­n’t dif­fe­rent from other requirements
  7. The cost of recor­ding know­ledge is small com­pared to the cost of acqui­ring knowledge
  8. The over­ar­ching objec­ti­ve of requi­re­ments deve­lo­p­ment is clear and effec­ti­ve communication
  9. Requi­re­ments qua­li­ty is in the eye of the beholder
  10. Requi­re­ments must be good enough to let con­s­truc­tion pro­ceed at an accep­ta­ble level of risk
  11. Peo­p­le don’t sim­ply gather requirements
  12. Requi­re­ments eli­ci­ta­ti­on must bring the customer’s voice clo­se to the developer’s ear
  13. Two com­mon­ly used requi­re­ments eli­ci­ta­ti­on prac­ti­ces are tele­pa­thy and cle­ar­voy­an­ce. They don’t work
  14. A lar­ge group of peo­p­le can’t agree to lea­ve a bur­ning room, let alo­ne agree on exact­ly how to word some requirement
  15. Avo­id deci­bel prio­ri­tiza­ti­on when deci­ding which fea­tures to include
  16. Wit­hout a docu­men­ted and agreed-to pro­ject scope, how do you know whe­ther your scope is creeping?

Die deut­sche Über­set­zung der 16 Lek­tio­nen stammt von mir:

  1. Wenn Sie die Anfor­de­run­gen nicht rich­tig erfül­len, spielt es kei­ne Rol­le, wie gut Sie den Rest des Pro­jekts durchführen
  2. Die wich­tigs­ten Ergeb­nis­se der Anfor­de­rungs­ent­wick­lung sind eine gemein­sa­me Visi­on und ein gemein­sa­mes Verständnis
  3. Nir­gend­wo sonst als bei den Anfor­de­run­gen über­schnei­den sich die Inter­es­sen aller Beteiligten
  4. Ein nut­zungs­ori­en­tier­ter Ansatz für die Anfor­de­run­gen wird den Kun­den­be­dürf­nis­sen bes­ser gerecht als ein fea­ture-ori­en­tier­ter Ansatz
  5. Anfor­de­rungs­ent­wick­lung erfor­dert Iteration
  6. Agi­le Anfor­de­run­gen sind nicht anders als ande­re Anforderungen
  7. Die Kos­ten für die Auf­zeich­nung von Wis­sen sind gering im Ver­gleich zu den Kos­ten für den Erwerb von Wissen
  8. Das über­grei­fen­de Ziel der Anfor­de­rungs­ent­wick­lung ist eine kla­re und effek­ti­ve Kommunikation
  9. Die Qua­li­tät der Anfor­de­run­gen liegt im Auge des Betrachters
  10. Die Anfor­de­run­gen müs­sen so gut sein, dass die Kon­struk­ti­on / Umset­zung mit einem akzep­ta­blen Risi­ko durch­ge­führt wer­den kann
  11. Men­schen sam­meln nicht ein­fach Anforderungen
  12. Die Anfor­de­rungs­er­he­bung muss die Stim­me des Kun­den nahe an das Ohr des Ent­wick­lers bringen
  13. Zwei häu­fig ver­wen­de­te Metho­den zur Anfor­de­rungs­er­he­bung sind Tele­pa­thie und Hell­se­hen. Sie funk­tio­nie­ren nicht
  14. Eine gro­ße Grup­pe von Men­schen kann sich nicht dar­auf eini­gen, einen bren­nen­den Raum zu ver­las­sen, geschwei­ge denn, sich auf den genau­en Wort­laut einer Anfor­de­rung zu einigen
  15. Ver­mei­den Sie eine “→ Prio­ri­sie­rung nach Laut­stär­ke”, wenn Sie ent­schei­den, wel­che Funk­tio­nen auf­ge­nom­men wer­den sollen
  16. Wie kön­nen Sie ohne einen doku­men­tier­ten und ver­ein­bar­ten Pro­jekt­um­fang wis­sen, ob sich Ihr Umfang schlei­chend verändert?

A. Präsentationen, Literatur und Weblinks

A.1 Präsentationen

  • -

A.2 Literatur

  1. /Ebert19/ Chris­tof Ebert: Sys­te­ma­ti­sches Requi­re­ments Engi­nee­ring. Anfor­de­run­gen ermit­teln, doku­men­tie­ren, ana­ly­sie­ren und ver­wal­ten, dpunkt, Hei­del­berg 6. Auf­la­ge 2019, ISBN 978–3‑86490–562‑9
  2. /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
  3. /Hruschka19/ Peter Hrusch­ka: → Busi­ness Ana­ly­sis und Requi­re­ments Engi­nee­ring. Pro­zes­se und Pro­duk­te nach­hal­tig ver­bes­sern, Han­ser, Mün­chen 2. Auf­la­ge 2019, ISBN 978–3‑446–45589‑4
  4. /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
  5. /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
  6. /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
  7. /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

A.3 Weblinks

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

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

Ähnliche Beiträge