Business Analysis

Das Glossar Aufbau und Verwendung

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Im → Requi­re­ments Engi­nee­ring (RE) ist das Glos­sar die zen­tra­le Instanz, um Begrif­fe zu erfas­sen, zu beschrei­ben und zu ver­ein­heit­li­chen. Ohne ein Glos­sar kann ein Requi­­re­­ments-Engi­­nee­ring-→ Vor­ha­ben kaum erfolg­reich sein.In die­sem Bei­trag wird das Glos­sar beschrie­ben. 1. Ein­lei­tung und Grund­la­gen Im Requi­re­ments Engi­nee­ring soll­te unter­schie­den wer­den zwi­schen den Glos­sa­ren der betrach­te­ten Fach­do­mä­ne (“Fachglos­sa­re”) …

Wei­ter­le­sen …

Das Backlog Anforderungen und Einträge zentral verwalten

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Das Back­log ist eine Samm­lung von The­men, die bear­bei­tet wer­den sol­len. Meis­tens sind dies Anfor­de­run­gen, die im agi­len Kon­text in Form von → User Sto­ries notiert wer­den.In die­sem Bei­trag wird eine Kurz­dar­stel­lung zum Back­log gelie­fert. Erläu­te­run­gen zum Back­log sind häu­fig in den Beschrei­bun­gen von → Scrum oder den → User Sto­ries ent­hal­ten. Im … 

Wei­ter­le­sen …

Lastenheft und Pflichtenheft Unterscheidungen und Einsatz

Mana­ge­­ment-Zusam­­men­­fas­­sung die­ses Bei­trags:Las­ten­heft und Pflich­ten­heft wer­den im deutsch­spra­chi­gen → Pro­­jek­t­­ma­­na­ge­­ment-Umfeld häu­fig benutzt.Den­noch sind die Bedeu­tung und der Ein­satz nicht immer klar und füh­ren zur Ver­wir­rung.In die­sem Bei­trag wer­den die Begrif­fe “Las­ten­heft und Pflich­ten­heft” beschrie­ben und eine Klä­rung der Unter­schie­de vor­ge­nom­men. Ein Dau­er­the­ma in der deutsch­spra­chi­gen Pro­­jek­t­­ma­­na­ge­­ment-Gemein­­schaft ist der Gebrauch von Las­ten­heft und Pflich­ten­heft. Die­ser Beitrag … 

Wei­ter­le­sen …

Von der Idee zum System Wie aus Visionen und Ideen Systeme entwickelt werden

Um eine Idee – bei­spiels­wei­se die Ein­füh­rung eines ver­bes­ser­ten Ablaufs oder eines neu­en Soft­ware­sys­tems – erfolg­reich zur Umset­zung zu brin­gen, soll­ten gene­rell Kennt­nis­se in den Berei­chen ein­ge­bracht wer­den. Doch das allein reicht noch nicht – um die­se Berei­che wie­der­um zu koor­di­nie­ren, bedarf es eines (über­ge­ord­ne­ten) → Pro­jekt­ma­nage­ments (PM), wel­ches mit den drei ande­ren Berei­chen verbunden … 

Wei­ter­le­sen …

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

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 exakte … 

Wei­ter­le­sen …

Der Korridor der Unsicherheit

Der “Korridor der Unsicherheit” Grafik des Monats Dezember 2014

1. Beschrei­bung Wer­den Schät­zun­gen der Kos­ten und der → Dau­er (für ein Pro­jekt) durch­ge­führt, so sind die­se immer mit einer Unsi­cher­heit behaf­tet. Genaue Schät­zun­gen sind auf­wen­dig (und damit teu­er) und wer­den daher meis­tens erst durch­ge­führt, wenn das Pro­jekt wei­ter kon­kre­ti­siert wird. Es ergibt sich somit ein “Kor­ri­dor der Unsi­cher­heit” (eng­lisch: Cone of Uncer­tain­ty, ande­re Bezeichnung … 

Wei­ter­le­sen …

Das Kano-Diagramm Grafik des Monats Juni 2014

1. Beschrei­bung 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) unter­teilt: Gra­fisch umge­setzt ergibt sich das Kano-Dia­gramm. Abbil­dung 1.1: Das Kano-Dia­­gramm: Dar­stel­lung Im Kano-Dia­­gramm wird der Erfüllungsgrad … 

Wei­ter­le­sen …