Requirements Engineering

Das Requi­re­ments Engi­nee­ring (RE) beschäf­tigt sich mit der pro­fes­sio­nel­len Ent­wick­lung und Ver­wal­tung von Anfor­de­run­gen. Gene­rell 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 (sie­he Abbildung).

Eine umfas­sen­de Beschrei­bung fin­det sich auf der Web­sei­te zum → Requi­re­ments Engi­nee­ring.

In die­ser Kate­go­rie-Über­sicht fin­den sich alle Bei­trä­ge nach Ver­öf­fent­li­chungs­da­tum geord­net — die alpha­be­ti­sche Lis­te fin­det sich unter → Alle Bei­trä­ge zum Requi­re­ments Engi­nee­ring.

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

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

Die Requirements Traceability Matrix (RTM) Verbindungen zwischen Requirements-Artefakten erfassen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Requi­re­ments → Tracea­bi­li­ty → Matrix (RTM, sel­te­ner auf Deutsch auch Anfor­de­rungs­nach­ver­fol­gungs­ma­trix) ist eine Matrix, die die Ver­bin­dung von ein­zel­nen Requi­re­ments / Anfor­de­run­gen erfasst.In die­sem Bei­trag wird die Requi­re­ments Tracea­bi­li­ty Matrix kurz beschrie­ben. Die RTM ist ein ein­fa­ches Instru­ment zur Erfas­sung der → Traces. Sie steht damit als tex­tu­el­ler Ansatz neben einer → … 

Wei­ter­le­sen …

Die unbekannten Unbekannten Zeitliche und budgetäre Reserven für die Projektrisiken vorsehen 

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Als unbe­kann­te Unbe­kann­te (Unknown Unknowns) wer­den im → Requi­re­ments Engi­nee­ring und → Pro­jekt­ma­nage­ment The­men bezeich­net, die nicht bekannt sind deren Aus­wir­kun­gen ent­spre­chend nicht ein­ge­schätzt wer­den kön­nen.Es wer­den in die­sem Bei­trag die unbe­kann­ten Unbe­kann­ten und der Umgang damit beschrie­ben. 1. Ein­lei­tung und Grund­la­gen Der Bekannt­heits­grad von Wis­sen kann in vier Berei­che unter­teilt wer­den (Abbil­dung …

Wei­ter­le­sen …

Kreativitätstechniken Gezielt kreativ sein

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Krea­ti­vi­täts­tech­ni­ken sind Metho­den zur För­de­rung von Krea­ti­vi­tät.In die­sem Bei­trag wird eine Beschrei­bung der Krea­ti­vi­täts­tech­ni­ken gelie­fert. Krea­tiv­tech­ni­ken hel­fen dabei, ein krea­ti­ves Vor­ge­hen zu ermög­li­chen. Dies ist ins­be­son­de­re bei Inno­va­ti­ons­pro­zes­sen hilf­reich. In der Lite­ra­tur sind weit über 100 Krea­ti­vi­täts­tech­ni­ken auf­ge­führt, im prak­ti­schen Ein­satz soll­ten dann die “pas­sen­den” her­aus­ge­sucht und genutzt wer­den.  1. Ein­lei­tung und Grundlagen … 

Wei­ter­le­sen …

Funktion oder Feature? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Funk­ti­on und Fea­ture wer­den in der → Soft­ware­ent­wick­lung ver­wen­det, sind aber nicht unbe­dingt iden­tisch ein­setz­bar.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. In der Wiki­pe­dia schreibt zum Begriff Funk­ti­on / Funk­tio­nen eines Objekts /#Wiki-Funktion/:“Als Funk­tio­nen eines Objek­tes bezeich­net man die Auf­ga­ben, die es erfül­len kann. Mit­hil­fe sei­ner Funk­tio­nen kann … 

Wei­ter­le­sen …

Annahme oder Randbedingung? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Annah­me (engl. Assump­ti­on) und Rand­be­din­gung (engl. Cons­traint) wer­den bei­de im → Requi­re­ments Engi­nee­ring benutzt.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die bei­den Begrif­fe kön­nen im Requi­­re­­ments-Engi­­nee­ring-Kon­­­text fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: Die Wiki­pe­dia defi­niert die Annah­me all­ge­mein /#Wiki-Annahme/:“Hypo­the­se, wis­sen­schaft­li­che Aus­sa­ge, deren Gül­tig­keit für mög­lich gehal­ten wird, die aber nicht bewiesen … 

Wei­ter­le­sen …

Das Changelog Änderungen an bestehenden Systemen schnell kommunizieren

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Wenn Ände­run­gen an bestehen­den Soft­ware­sys­te­men durch­ge­führt wer­den, soll­te dies mög­lichst gezielt und trans­pa­rent erfol­gen. Um zu notie­ren, wel­che Ände­run­gen erfolgt sind, wird häu­fig ein Chan­ge­log (Ände­rungs­pro­to­koll) ein­ge­setzt.In die­sem Bei­trag wird eine Beschrei­bung des Chan­ge­logs gelie­fert. Das Chan­ge­log ist in der Regel eine rei­ne Text­da­tei, in der in stich­punkt­ar­ti­ger Form Ände­run­gen von neu herausgegebenen … 

Wei­ter­le­sen …

Die Architekturpyramide Die Softwarearchitektur über fünf Schichten betrachten

Die Archi­tek­tur­py­ra­mi­de beschreibt ein fünf­schich­ti­ges Modell für die → Soft­ware­ar­chi­tek­tur, wel­ches unter­schied­li­che Betrach­tungs­hö­hen auf­weist. Hier­über wird ein (Informations-)System aus ver­schie­de­nen Sich­ten betrach­tet und eine Soft­ware­ar­chi­tek­tur kann abge­lei­tet wer­den. Daher wird die Archi­tek­tur­py­ra­mi­de sowohl der Dis­zi­plin Soft­ware­ar­chi­tek­tur als auch dem → Infor­ma­ti­ons­ma­nage­ment zuge­ord­net. Die fünf Schich­ten der Archi­tek­tur­py­ra­mi­de sind (Abbil­dung 1): Abbil­dung 1: Die Archi­tek­tur­py­ra­mi­de Der Einsatz … 

Wei­ter­le­sen …

Die Automatisierungspyramide Ein zentrales Modell in der industriellen Leittechnik

Die Auto­ma­ti­sie­rungs­py­ra­mi­de beschreibt ein fünf­schich­ti­ges Modell im (Maschinen-)Automatisierungskontext / in der Leit­tech­nik, über das die Daten­gra­nu­la­ri­tät und die Daten­agg­re­gie­rung (Teil-)Systemen zuge­ord­net wer­den kann. Die Auto­ma­ti­sie­rungs­py­ra­mi­de wird in die­sem Bei­trag als Teil des → Sys­tems Engi­nee­ring gese­hen. In der Wiki­pe­dia steht /#Wiki-Automatisierungspyramide/:“Die Auto­ma­ti­sie­rungs­py­ra­mi­de dient der Ein­ord­nung von Tech­ni­ken und Sys­te­men in der Leit­tech­nik und stellt die … 

Wei­ter­le­sen …

Die DEEP-Kriterien Die Qualität des Product Backlogs einschätzen

Die DEEP-Kri­­te­ri­en hel­fen dabei, zu über­prü­fen, ob ein­zel­ne Pro­duct Back­logs “gut” sind. Das Akro­nym DEEP steht für fol­gen­de vier Eigen­schaf­ten: Beim → PMI steht zu DEEP /PMG-BA17/:“Descri­bes the cha­rac­te­ristics that a pro­duct → back­log needs to demons­tra­te to be con­side­red well refi­ned. DEEP is an acro­nym that stands for detail­ed appro­pria­te­ly, esti­ma­ted, emer­gent, and prio­ri­ti­zed.“Eige­ne …

Wei­ter­le­sen …

Vorlagenbasiertes Dokumentieren von Anforderungen Arbeitsprodukte mit Vorlagen entwickeln

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das vor­la­gen­ba­sier­te Doku­men­tie­ren hilft den Inter­pre­ta­tio­nen bei dem Erfas­sen und Beschrei­ben von Anfor­de­run­gen zu redu­zie­ren.In die­sem Bei­trag wird das vor­la­gen­ba­sier­te → Doku­men­tie­ren von Anfor­de­run­gen beschrie­ben. 1. Ein­lei­tung und Grund­la­gen Es gibt nach → IREB drei vor­la­gen­ba­sier­te Arbeits­pro­duk­te /#IREB-CPRE-FL-24/ zur Erfas­sung von Anfor­de­run­gen: Die Ein­ord­nung des vor­la­gen­ba­sier­ten Doku­men­tie­rens ist in Abbil­dung 1 dar­ge­stellt. Neben … 

Wei­ter­le­sen …