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

Business Analysis oder Requirements Engineering? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Dis­zi­pli­nen → Busi­ness Ana­ly­sis und → Requi­re­ments Engi­nee­ring beschäf­ti­gen sich bei­de mit dem Erfas­sen und → Ver­wal­ten von Anfor­de­run­gen.In die­sem Bei­trag wer­den die Busi­ness Ana­ly­sis und das Requi­re­ments Engi­nee­ring kurz ein­ge­ord­net und die Unter­schie­de benannt. Die bei­den Begrif­fe kön­nen fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: Hin­weis:Die hier vor­ge­stell­te Beschrei­bung und Ein­ord­nung stammt von mir und … 

Wei­ter­le­sen …

Releaseplan oder Roadmap? Welcher Begriff steht wofür?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Release­plan und → Road­map wer­den im agi­len und klas­si­schen → Pro­jekt­ma­nage­ment sowie im → Pro­dukt­ma­nage­ment ver­wen­det.In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert und der Unter­schied auf­ge­zeigt. Release­plan und Road­map wer­den im Pro­­dukt- und Pro­jekt­ma­nage­ment genutzt, um im Vor­hin­ein das Ergeb­nis von Ent­wick­lungs­tä­tig­kei­ten zu kenn­zeich­nen. Die bei­den Begrif­fe können … 

Wei­ter­le­sen …

Shareholder oder Stakeholder? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Share­hol­der und → Stake­hol­der wer­den in der Betrieb­s­­wir­t­­schafts- und Manage­ment­leh­re ver­wen­det und bezeich­nen jeweils Per­so­nen­grup­pen. In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die bei­den Begrif­fe kön­nen fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: In der Wiki­pe­dia steht zum Begriff Share­hol­der /#Wiki-Shareholder/:“Share­hol­der (eng­lisch für Anteils­eig­ner) steht für: — all­ge­mein einen Anteils­eig­ner, — speziell … 

Wei­ter­le­sen …

Produktmanagement Produkte systematisch entwickeln und betreuen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das Pro­dukt­ma­nage­ment beschäf­tigt sich mit der sys­te­ma­ti­schen Ent­wick­lung und Betreu­ung von Pro­duk­ten in Unter­neh­men.In die­sem Bei­trag wird das Pro­dukt­ma­nage­ment in Teil­aspek­ten beschrie­ben. “Das Pro­dukt­ma­nage­ment” ist sowohl eine Dis­zi­plin als auch eine Orga­ni­sa­ti­ons­ein­heit, die das Pro­dukt­ma­nage­ment in Unter­neh­men zu ver­ant­wor­ten hat. 1. Ein­lei­tung und Grund­la­gen 1.1 Defi­ni­tio­nen In der Wiki­pe­dia steht zum Pro­dukt­ma­nage­ment /#Wiki-Produktmanagement/: “Pro­dukt­ma­nage­ment …

Wei­ter­le­sen …

Der Zusammenhang von Projektmanagement und Requirements Engineering Die Gemeinsamkeiten und Schnittstellen beider Disziplinen

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:→ Pro­jekt­ma­nage­ment (PM) und → Requi­re­ments Engi­nee­ring (RE) die­nen dazu, Pro­duk­te und → Dienst­leis­tun­gen zu kon­zi­pie­ren. Dabei sind bei­de Dis­zi­pli­nen nicht getrennt, son­dern zusam­men ein­zu­set­zen, um wert­vol­le Ergeb­nis­se zu erzie­len.In die­sem Bei­trag wer­den eini­ge Aspek­te des Zusam­men­hangs von Pro­jekt­ma­nage­ment und Requi­re­ments Engi­nee­ring und der Umgang damit beschrie­ben. 1. Beschrei­bung Gene­rell gibt es einige … 

Wei­ter­le­sen …

Priorisieren oder Schätzen? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe → Prio­ri­sie­ren und → Schät­zen wer­den zur Bewer­tung von Auf­ga­ben oder → Vor­ha­ben ver­wen­det. In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die Begrif­fe Prio­ri­sie­ren und Schät­zen kön­nen für den Ein­satz in Pro­jek­ten oder für die Umset­zung von Auf­ga­ben wie folgt cha­rak­te­ri­siert wer­den: Das → IIBA schreibt zur → … 

Wei­ter­le­sen …

Abnahmekriterien oder Akzeptanzkriterien? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Die Begrif­fe Abnah­me­kri­te­ri­en und Akzep­tanz­kri­te­ri­en wer­den bei der abschlie­ßen­den Bewer­tung von Pro­duk­ten oder → Dienst­leis­tun­gen ver­wen­det, um Pro­duk­te oder Dienst­leis­tun­gen ein­set­zen zu kön­nen. In die­sem Bei­trag wird eine Beschrei­bung der bei­den Begrif­fe gelie­fert. Die bei­den Begrif­fe kön­nen fol­gen­der­ma­ßen cha­rak­te­ri­siert wer­den: Hin­weis:In der Pra­xis wird zwi­schen den bei­den Begrif­fen nicht unter­schie­den, Abnah­me­kri­te­ri­en und Akzeptanzkriterien … 

Wei­ter­le­sen …

Feature Driven Development (FDD) Über Features die Entwicklung von Software steuern

→ Fea­ture Dri­ven Deve­lo­p­ment (FDD) ist ein Ansatz in der → Soft­ware­ent­wick­lung, um das Ent­wick­lungs­vor­ge­hen über Fea­tures zu steu­ern. Ursprüng­lich von Peter Coad und Jeff De Luca /Coad99/ ent­wi­ckelt, erfuhr das FDD in den ers­ten Jah­ren des 21ten Jahr­hun­derts eine gewis­se Bedeu­tung und Ver­brei­tung. In der Wiki­pe­dia steht zum Fea­ture Dri­ven Deve­lo­p­ment /#Wiki-FDD/:“Fea­ture Dri­ven Development … 

Wei­ter­le­sen …

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 …