Business Analysis

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 …

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 …

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 …

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­ten 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 …

Die Wirtschaftlichkeitsbetrachtung in Projekten Festlegen, welche wirtschaftlichen Rahmenbedingungen es im Projekt gibt

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:In der Wirt­schaft­lich­keits­be­trach­tung (engl. Eco­no­mic Effi­ci­en­cy Ana­ly­sis) wird zu einem sehr frü­hen → Zeit­punkt unter­sucht, ob ein Pro­jekt­vor­ha­ben gene­rell wirt­schaft­lich sein kann. Hier­bei wird ins­be­son­de­re die finan­zi­el­le Mach­bar­keit über­prüft. In die­sem Bei­trag wird die Wirt­schaft­lich­keits­be­trach­tung beschrie­ben. Die Wirt­schaft­lich­keits­be­trach­tung (auch: Wirt­schaft­lich­keits­un­ter­su­chung, Wirt­schaft­lich­keits­rech­nung oder Wirt­schaft­lich­keits­ana­ly­se) ist ein Instru­ment zur Über­prü­fung der Wirt­schaft­lich­keit in einem Projekt. … 

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 …

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 …

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 …

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 …