Alle Beiträge zum Requirements Engineering Alphabetisch sortiert

Fol­gen­de Bei­trä­ge zum → Requi­re­ments Engi­nee­ring (oder mit star­kem Bezug zum → Requi­re­ments Engi­nee­ring) sind auf die­ser Web­site zu finden:

  1. Abnah­me­kri­te­ri­en oder Akzep­tanz­kri­te­ri­en? Was ist der Unterschied?
  2. Agi­les Requi­re­ments Engi­nee­ring Die Anfor­de­run­gen im agi­len Kon­text pas­send erfassen
  3. Agi­les Schät­zen Schnell und pas­send Schät­zun­gen vornehmen
  4. Alle Bei­trä­ge zum Requi­re­ments Engi­nee­ring Alpha­be­tisch sortiert
  5. Anfor­de­rungs­at­tri­bu­te Wel­che Attri­bu­te erfasst und ver­folgt wer­den sollten
  6. Anfor­de­rungs­ver­wal­tung — Requi­re­ments Manage­ment Anfor­de­run­gen wert­schöp­fend verwalten
  7. Annah­me oder Rand­be­din­gung? Was ist der Unterschied?
  8. Auf­wand für das Requi­re­ments Engi­nee­ring Ermitt­lung und Bewertung
  9. Begrif­fe im Requi­re­ments Engi­nee­ring Alpha­be­tisch sortiert
  10. Best Prac­ti­ce oder Good Prac­ti­ce? Was ist der Unterschied?
  11. Brain­stor­ming Das Fin­den von Ideen in kur­zer Zeit
  12. Busi­ness Ana­ly­sis oder Requi­re­ments Engi­nee­ring? Was ist der Unterschied?
  13. Das Back­log Anfor­de­run­gen und Ein­trä­ge zen­tral verwalten
  14. Das Chan­ge­log Ände­run­gen an bestehen­den Sys­te­men schnell kommunizieren
  15. Das Doku­men­tie­ren von Anfor­de­run­gen Eine Haupt­tä­tig­keit im Requi­re­ments Engineering
  16. Das Ermit­teln von Anfor­de­run­gen Eine Haupt­tä­tig­keit im Requi­re­ments Engineering
  17. Das Glos­sar Auf­bau und Verwendung
  18. Das IIBA — Inter­na­tio­nal Insti­tu­te of Busi­ness Ana­ly­sis Der inter­na­tio­na­le Fach­ver­band zur Busi­ness Analysis
  19. Das IREB — Inter­na­tio­nal Requi­re­ments Engi­nee­ring Board Der inter­na­tio­na­le Fach­ver­band zum Requi­re­ments Engineering
  20. Das Kano-Dia­gramm Gra­fik des Monats Juni 2014
  21. Das Kano-Modell Kun­den­wün­sche ermit­teln und einordnen
  22. Das Mini­mum Via­ble Pro­duct (MVP) Ers­te wert­schöp­fen­de Pro­dukt­ver­sio­nen schnell ver­füg­bar machen
  23. Das Quiz zum Requi­re­ments Engi­nee­ring 10 Fra­gen zum Basiswissen
  24. Das Review Prü­fen von Produktanforderungen
  25. Das V‑Modell Dar­stel­lung und Verwendung
  26. Das Vali­die­ren von Anfor­de­run­gen Eine Haupt­tä­tig­keit im Requi­re­ments Engineering
  27. Das Was­ser­fall­mo­dell Dar­stel­lung und Verwendung
  28. Defi­ni­ti­on of Done Wann ist eine User Sto­ry fer­tig umgesetzt?
  29. Der “Kor­ri­dor der Unsi­cher­heit” Gra­fik des Monats Dezem­ber 2014
  30. Der Chan­ge Request Ände­run­gen erfas­sen, ver­fol­gen und umsetzen
  31. Der Lehr­plan des IREB zum CPRE-FL 2020 Requi­re­ments Engi­nee­ring struk­tu­riert dargestellt
  32. Der mor­pho­lo­gi­sche Kas­ten Alter­na­ti­ven gegen­über­stel­len und auswählen
  33. Der Pro­duct Owner Auf­ga­ben, Ver­ant­wort­lich­kei­ten und Rollenbeschreibung
  34. Der Requi­re­ments Engi­neer Auf­ga­ben und Rollenbeschreibung
  35. Der Start eines Requi­re­ments-Pro­jekts Die­se ers­ten Schrit­te soll­ten immer durch­ge­führt werden
  36. Der Zusam­men­hang von Pro­jekt­ma­nage­ment und Requi­re­ments Engi­nee­ring Die Gemein­sam­kei­ten und Schnitt­stel­len bei­der Disziplinen
  37. Design Free­ze, Fea­ture Free­ze und Code Free­ze Ände­run­gen ab einem defi­nier­ten Ent­wick­lungs­stand verbieten
  38. Die 10er-Regel der Feh­ler­kos­ten Spät ent­deck­te Feh­ler sind teuer
  39. Die Anfor­de­rungs­lis­te Anfor­de­run­gen struk­tu­riert und schnell erfassen
  40. Die Archi­tek­tur­py­ra­mi­de Die Soft­ware­ar­chi­tek­tur über fünf Schich­ten betrachten
  41. Die Auto­ma­ti­sie­rungs­py­ra­mi­de Ein zen­tra­les Modell in der indus­tri­el­len Leittechnik
  42. Die Base­line Den Stand eines Pro­dukts oder Pro­jekts festlegen
  43. Die DEEP-Kri­te­ri­en Die Qua­li­tät des Pro­duct Back­logs einschätzen
  44. Die INVEST-Kri­te­ri­en User Sto­ries gut und pas­send erfassen
  45. Die Klas­si­fi­ka­ti­on von Anfor­de­run­gen Anfor­de­run­gen rich­tig zuordnen
  46. Die Kom­pe­tenz­stu­fen (und die Kennt­nis­se) Gra­fik des Monats Juli 2016
  47. Die MoSCoW-Prio­ri­sie­rung Ein­zel­ne Anfor­de­run­gen ein­fach priorisieren
  48. Die Pro­dukt­vi­si­on Beschrei­bung der Pro­dukt­lö­sung in kur­zen Worten
  49. Die Pro­jekt­um­feld­ana­ly­se Über­grei­fend den gesam­ten Kon­text des Pro­jekts betrachten
  50. Die Quiz zu mei­nen The­men­be­rei­chen Fra­gen zur Über­prü­fung von Wissen
  51. Die Requi­re­ments Tracea­bi­li­ty Matrix (RTM) Ver­bin­dun­gen zwi­schen Requi­re­ments-Arte­fak­ten erfassen
  52. Die SMART-Kri­te­ri­en Zie­le gut und pas­send formulieren
  53. Die UML — Uni­fied Mode­ling Lan­guage Die wich­tigs­te Model­lie­rungs­spra­che für Anforderungen
  54. Die unbe­kann­ten Unbe­kann­ten Zeit­li­che und bud­ge­tä­re Reser­ven für die Pro­jekt­ri­si­ken vorsehen 
  55. Die Ver­bind­lich­keit von Anfor­de­run­gen und Zie­len Schlüs­sel­wör­ter rich­tig einsetzen
  56. Ent­wick­lung, Ermitt­lung oder Erstel­lung? Was ist der Unterschied?
  57. Ermitt­lungs­tech­ni­ken für das Requi­re­ments Engi­nee­ring Sys­te­ma­ti­sches Zusam­men­tra­gen von Anforderungen
  58. Fea­ture Dri­ven Deve­lo­p­ment (FDD) Über Fea­tures die Ent­wick­lung von Soft­ware steuern
  59. Funk­ti­on oder Fea­ture? Was ist der Unterschied?
  60. Inter­views Ein­satz, Tech­ni­ken und Formen
  61. Ite­ra­tiv oder inkre­men­tell? Was ist der Unterschied?
  62. Klas­si­fi­ka­tio­nen im Requi­re­ments Engi­nee­ring Geziel­tes und struk­tu­riert vorgehen
  63. Kon­fi­gu­ra­ti­ons­ma­nage­ment Die zen­tra­le Dis­zi­plin zur Zusam­men­fas­sung von Pro­dukt- oder Projekteinheiten
  64. Krea­ti­vi­täts­tech­ni­ken Gezielt krea­tiv sein
  65. Las­ten­heft und Pflich­ten­heft Unter­schei­dun­gen und Einsatz
  66. Lis­te, Regis­ter oder Matrix? Was ist der Unterschied?
  67. Merk­re­geln für das Requi­re­ments Engi­nee­ring Leit­li­ni­en für die Umsetzung
  68. Mis­si­on oder Visi­on? Was ist der Unterschied?
  69. Mode­ra­ti­on Ein­satz und Techniken
  70. Nicht-funk­tio­na­le Anfor­de­run­gen Wich­tig und häu­fig unterschätzt
  71. Per­so­nas Anfor­de­run­gen aus typi­schen Nut­zer­pro­fi­len ableiten
  72. Pilot oder Pro­to­typ? Was ist der Unterschied?
  73. Prak­tik oder Prin­zip? Was ist der Unterschied?
  74. Prä­sen­ta­tio­nen Über 2.800 Sei­ten zum pri­va­ten Gebrauch
  75. Prio­ri­sie­ren oder Schät­zen? Was ist der Unterschied?
  76. Prio­ri­tä­ten Prio­ri­sie­run­gen rich­tig vornehmen
  77. Pro­dukt­ma­nage­ment Pro­duk­te sys­te­ma­tisch ent­wi­ckeln und betreuen
  78. Pro­jekt oder Vor­ha­ben? Was ist der Unterschied?
  79. Pro­zes­se im Requi­re­ments Engi­nee­ring Unter­tei­lung des Vor­ge­hens in ein­zel­ne Ablaufschritte
  80. Rah­men­be­din­gung oder Rand­be­din­gung? Was ist der Unterschied?
  81. RE-Tools Anfor­de­run­gen mit Tech­nik und Sys­tem verwalten
  82. Release­plan oder Road­map? Wel­cher Begriff steht wofür?
  83. Requi­re­ments Engi­nee­ring Anfor­de­run­gen ent­wi­ckeln und verwalten
  84. Review oder Audit? Was ist der Unterschied?
  85. Safe­ty oder Secu­ri­ty? Was ist der Unterschied?
  86. Satz­scha­blo­nen Das For­mu­lie­ren von Anfor­de­run­gen mit Schablonen
  87. Schät­zen in Pro­jek­ten Auf­wän­de pas­send zum rich­ti­gen Zeit­punkt ermitteln
  88. Schät­zen, Ver­mu­ten oder Raten? (Esti­mat­ing, Assum­ing or Gues­sing?) Was ist der Unterschied?
  89. Ser­vice Level Agree­ment (SLA) Die Güte und Qua­li­tät eines Diens­tes ver­trag­lich vereinbaren
  90. Share­hol­der oder Stake­hol­der? Was ist der Unterschied?
  91. Sys­tem und Sys­tem­kon­text Die Beschrei­bung, was dazu­ge­hört und was nicht
  92. Tracea­bi­li­ty Ver­bin­dun­gen zwi­schen Anfor­de­run­gen herstellen
  93. Use Case Wesent­lich für die Erfas­sung von Anforderungen
  94. Use Case oder User Sto­ry? Was ist der Unterschied?
  95. User Request oder User Requi­re­ment? Was ist der Unterschied?
  96. UX (User Expe­ri­ence), Usa­bi­li­ty oder UI (User Inter­face)? Was ist der Unterschied?
  97. Vali­die­ren oder veri­fi­zie­ren? Wel­cher Begriff ist richtig?
  98. Versions‑, Vari­an­ten- oder Pro­dukt­li­ni­en­ma­nage­ment? Was ist der Unterschied?
  99. Von der Idee zum Sys­tem Wie aus Visio­nen und Ideen Sys­te­me ent­wi­ckelt werden
  100. Vor­la­gen­ba­sier­tes Doku­men­tie­ren von Anfor­de­run­gen Arbeits­pro­duk­te mit Vor­la­gen entwickeln

Nicht das dabei, was Sie benö­ti­gen?
Spre­chen Sie → mich an oder schau­en Sie bei mei­nen aus­ge­ar­bei­te­ten → Prä­sen­ta­tio­nen!