Das Stichwort

In der Kate­go­rie “Das Stich­wort” wer­den Ein­zel­be­grif­fe oder klei­ne­re The­men­fel­der beschrie­ben, für die es jeweils eine eige­ne Sei­te zur Erläu­te­rung gibt.

Safety oder Security? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Die Begrif­fe Safe­ty und Secu­ri­ty wer­den bei­de im → Sys­tems Engi­nee­ring, im → Requi­re­ments Engi­nee­ring sowie im → Qua­li­täts­ma­nage­ment (und → Risi­ko­ma­nage­ment) häu­fig benutzt. Um eine Ver­wech­se­lung zu ver­mei­den, soll­te eine Unter­schei­dung die­ser Begrif­fe vor­ge­nom­men wer­den.In die­sem Bei­trag wird eine Kurz­dar­stel­lung dazu gelie­fert. Die bei­den Begrif­fe kön­nen fol­gen­der­ma­ßen kurz cha­rak­te­ri­siert wer­den: Safety …

Safe­ty oder Secu­ri­ty? Was ist der Unter­schied? Weiterlesen »

Liste, Register oder Matrix? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Die sprach­li­che Unter­schei­dung von Lis­te, Regis­ter oder Matrix im → Pro­jekt­ma­nage­ment soll­te vor Pro­jekt­start vor­ge­nom­men wer­den, um Klar­heit zu schaf­fen.In die­sem Bei­trag wird eine kur­ze Beschrei­bung der Begrif­fe gelie­fert. Gene­rell soll­te zwi­schen einer Lis­te, einem Regis­ter oder einer Matrix einem The­men­be­reich unter­schie­den wer­den, um so für Klar­heit bei den Betei­lig­ten zu sorgen. …

Lis­te, Regis­ter oder Matrix? Was ist der Unter­schied? Weiterlesen »

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

Es gibt eini­ge Merkregeln(-Sammlungen) zum → Requi­re­ments Engi­nee­ring, die bei der Umset­zung von Requi­­re­­ments-Pro­­­je­k­­ten beach­tet wer­den sol­len. Eini­ge die­ser Merk­re­geln wer­den in die­sem Bei­trag vor­ge­stellt. 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 wer­den. Abbil­dung 1: Merk­re­geln für das Requi­re­ments Engi­nee­ring: Unter­tei­lung 1. Mei­ne Merk­re­geln für das …

Merk­re­geln für das Requi­re­ments Engi­nee­ring Leit­li­ni­en für die Umset­zung Weiterlesen »

Die Projektumfeldanalyse Übergreifend den gesamten Kontext des Projekts betrachten

Bei der Pro­jekt­um­feld­ana­ly­se (abge­kürzt: PUMA oder PUA, auch als Umwelt­ana­ly­se bezeich­net) wird über­grei­fend der gesam­te Kon­text des Pro­jekts betrach­tet, um so Sta­ke­hol­der zu benen­nen und zu klas­si­fi­zie­ren. In der Wiki­pe­dia steht zu den Zie­len der Pro­jekt­um­feld­ana­ly­se (fett = für das → Sta­ke­hol­der­ma­nage­ment rele­vant) /#Wiki-Projektumfeldanalyse/: “Ziel der Pro­jekt­um­feld­ana­ly­se ist die Erfas­sung aller Ein­fluss­fak­to­ren des Pro­jek­tes: Einflussfaktoren …

Die Pro­jekt­um­feld­ana­ly­se Über­grei­fend den gesam­ten Kon­text des Pro­jekts betrach­ten Weiterlesen »

Mission oder Vision? Was ist der Unterschied?

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Die Begrif­fe Mis­si­on und Visi­on wer­den häu­fig ver­wech­selt. Im Manage­ment und in der Orga­ni­sa­ti­ons­leh­re ist eine genaue Unter­schei­dung aber wesent­lich.In die­sem Bei­trag wird eine Kurz­dar­stel­lung zur Unter­schei­dung der Begrif­fe gelie­fert. Mis­si­on und Visi­on sind für Unter­neh­men von gro­ßer Bedeu­tung, denn aus (gut for­mu­lier­ten) Mis­sio­nen und Visio­nen kön­nen → Zie­le, Pro­jek­te und Produkte …

Mis­si­on oder Visi­on? Was ist der Unter­schied? Weiterlesen »

Satzschablonen Das Formulieren von Anforderungen mit Schablonen

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Satz­scha­blo­nen sind ein Hilfs­mit­tel, um Ein­­zel-Anfor­­de­­run­­­gen so zu struk­tu­rie­ren und zu for­mu­lie­ren, dass Sie eine hohe Qua­li­tät auf­wei­sen.In die­sem Bei­trag Satz­scha­blo­nen und deren beschrie­ben im → Requi­re­ments Engi­nee­ring beschrie­ben. Satz­scha­blo­nen (auch Anfor­de­rungs­scha­blo­nen, eng­lisch Phra­se Tem­pla­tes oder Requi­re­ment Tem­pla­tes) die­nen der natür­­lich-sprach­­li­chen Erfas­sung von (ein­zel­nen) Anfor­de­run­gen. Durch dem Ein­satz von Satz­scha­blo­nen erhal­ten die …

Satz­scha­blo­nen Das For­mu­lie­ren von Anfor­de­run­gen mit Scha­blo­nen Weiterlesen »

Die FMEA — Fehlermöglichkeits- und Einfluss-Analyse Wichtig in allen Bereichen

Die FMEA — Feh­­ler-Mög­­li­ch­­keits- und Ein­­fluss-Ana­­ly­­se — wird als Teil­dis­zi­plin dem → Qua­li­täts­ma­nage­ment wie auch dem → Risi­ko­ma­nage­ment zuge­ord­net. In die­sem Bei­trag wird die FMEA vor­ge­stellt. Die FMEA — Feh­­ler-Mög­­li­ch­­keits- und Ein­­fluss-Ana­­ly­­se (eng­lisch Fail­u­re Mode and Effects Ana­ly­sis) — ist ein Ver­fah­ren zur Vor­her­sa­ge mög­li­cher Schwach­stel­len und deren Aus­wir­kung in noch zu erstel­len­den Pro­duk­ten (oder …

Die FMEA — Feh­ler­mög­lich­keits- und Ein­fluss-Ana­ly­se Wich­tig in allen Berei­chen Weiterlesen »

Die Komfortzone Warum die Komfortzone nicht ideal ist

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Die Kom­fort­zo­ne bezeich­net einen Bereich, in dem sich ein Mensch aus­ge­gli­chen bewegt, da (von außen) kei­ne Ände­rungs­not­wen­dig­keit besteht. Aller­dings sind in der Kom­fort­zo­ne kaum Wei­ter­ent­wick­lun­gen mög­lich.In die­sem Bei­trag wird eine kur­ze Beschrei­bung der Kom­fort­zo­ne gelie­fert. Jeder ein­zel­ne Mensch ist bestrebt, in sei­nem Umfeld aus­ge­gli­chen zu sein: Er bewegt sich in sei­ner Komfortzone. …

Die Kom­fort­zo­ne War­um die Kom­fort­zo­ne nicht ide­al ist Weiterlesen »

Das V‑Modell Darstellung und Verwendung

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Das V‑Modell beschreibt ein Vor­ge­hen bei der Ent­wick­lung von Soft­ware, Sys­te­men oder Pro­duk­ten, wel­ches sich gra­fisch ent­lang eines Vs visua­li­sie­ren lässt.In die­sem Bei­trag wird das V‑Modell und des­sen Ein­satz in ver­schie­de­nen Kon­tex­ten wie dem → Requi­re­ments Engi­nee­ring beschrie­ben. Das V‑Modell beschreibt ein Vor­ge­hen bei der Ent­wick­lung von Soft­ware, Sys­te­men oder Pro­duk­ten, welches …

Das V‑Modell Dar­stel­lung und Ver­wen­dung Weiterlesen »

Use Cases Wesentlich für die Erfassung von Anforderungen

Mana­ge­­ment-Zusam­­men­­fas­­sung zu die­sem Bei­trag:Uses Cases (deutsch: Anwen­dungs­fäl­le) beschrei­ben mit weni­gen Ele­men­ten eine gro­be Sicht auf Sys­te­me im Requi­re­ments und → Soft­ware Engi­nee­ring. Es wer­den in die­sem Bei­trag die Uses Cases beschrie­ben. Use Cases sind ein “Standard”-Diagrammtyp der UML / → Uni­fied Mode­ling Lan­guage, wel­ches sehr häu­fig ein­ge­setzt wer­den kann. Da es nur weni­ge Ele­men­te aufweist, …

Use Cases Wesent­lich für die Erfas­sung von Anfor­de­run­gen Weiterlesen »

Scroll to Top