Details

Requirements Engineering für Dummies


Requirements Engineering für Dummies


Für Dummies 1. Aufl.

von: Marcus Winteroll

26,99 €

Verlag: Wiley-VCH
Format: EPUB
Veröffentl.: 06.01.2021
ISBN/EAN: 9783527823932
Sprache: deutsch
Anzahl Seiten: 384

DRM-geschütztes eBook, Sie benötigen z.B. Adobe Digital Editions und eine Adobe ID zum Lesen.

Beschreibungen

Für den Erfolg von Softwareprojekten ist es entscheidend, sich erstmal klar zu machen, wozu das System überhaupt dienen soll und wie es dafür beschaffen sein muss. Klingt eigentlich selbstverständlich, und doch scheitern Projekte oft gerade an der Anforderungsanalyse. Das Buch "Requirements Engineering für Dummies" beschreibt verständlich und pragmatisch, wie Sie vorgehen sollten - und zwar sowohl für klassische als auch für agile Projekte. Es liefert Ihnen Techniken, wie Sie Ziele bestimmen und Releases sinnvoll zusammenstellen, wie Sie Anforderungen erheben und verstehen, wie Sie mit Änderungen umgehen und wie Sie Fallstricke vermeiden. Das Buch ist auch geeignet zur Vorbereitung auf die CPRE-FL-Prüfung.
<p>Über den Autor 13</p> <p><b>Einleitung 25</b></p> <p>Über dieses Buch 25</p> <p>Konventionen in diesem Buch 26</p> <p>Was Sie nicht lesen müssen 26</p> <p>Törichte Annahmen über die Leser 26</p> <p>Wie dieses Buch aufgebaut ist 26</p> <p>Teil I: Requirements Engineering verstehen 27</p> <p>Teil II: Vorgehen im Requirements Engineering 27</p> <p>Teil III: Anforderungsanalyse 27</p> <p>Teil IV: Requirements Management 27</p> <p>Teil V: Der Top-Ten-Teil 27</p> <p>Symbole, die in diesem Buch verwendet werden 27</p> <p>Wie es weitergeht 28</p> <p><b>Teil I: Requirements Engineering verstehen 29</b></p> <p><b>Kapitel 1 Das ist Requirements Engineering 31</b></p> <p>Warum uns Requirements Engineering weiterhelfen kann 31</p> <p>Aufgaben im Requirements Engineering 34</p> <p>Wer das Requirements Engineering macht 36</p> <p>Der Requirements Engineer 37</p> <p>Wer sonst noch das Requirements Engineering macht 37</p> <p>Viele Arten von Anforderungen 38</p> <p>Funktionale Anforderungen 38</p> <p>Nichtfunktionale Anforderungen 39</p> <p>Randbedingungen 40</p> <p>Abstraktionsstufen von Anforderungen 41</p> <p>Möglichkeiten der Zertifizierung 42</p> <p>Zertifikate des IREB 43</p> <p>Zertifikate des IIBA 44</p> <p>PMI Professional in Business Analysis (PMI-PBA) 45</p> <p><b>Kapitel 2 Einbettung des Requirements Engineering</b> <b>47</b></p> <p>Das Zusammenspiel mit den übrigen Beteiligten 47</p> <p>Die Kunden des Requirements Engineering 48</p> <p>Wer sonst noch so wichtig ist: die Stakeholder 48</p> <p>Die Basis vieler Anforderungen: die Geschäftsprozesse 49</p> <p>Das Anforderungsdokument: eines für alle? 50</p> <p>Requirements Engineering im klassischen Vorgehen: alles klar 52</p> <p>Was zu erwarten ist 52</p> <p>Was nicht zu erwarten ist 52</p> <p>Requirements Engineering in agilen Projekten: just in time 53</p> <p>Beliebte Missverständnisse beim agilen Requirements Engineering 53</p> <p>Was agiles Vorgehen vom klassischen unterscheidet 54</p> <p>Klassisch, agil, Festpreis, Aufwandspreis –nicht jede Kombination ist sinnvoll 56</p> <p>Klassisch und Festpreis 56</p> <p>Agil und Aufwandspreis 56</p> <p>Agil und Festpreis 57</p> <p>Klassisch und Aufwandspreis 57</p> <p>Alles im Überblick 57</p> <p><b>Kapitel 3 Fallstricke</b> <b>59</b></p> <p>Was wir von den Kunden erwarten dürfen – und sie von uns 59</p> <p>Wer nimmt die Anforderungen auf? 60</p> <p>Der Projektleiter als Requirements Engineer 60</p> <p>Der Product Owner als Requirements Engineer 61</p> <p>Entwickler als Requirements Engineers 61</p> <p>Kunde und Nutzer als Requirements Engineers 62</p> <p>Die richtige Detaillierung von Anforderung 63</p> <p>Umgang mit Änderungen 64</p> <p>Dokumentation von Anforderungen 66</p> <p><b>Teil II: Vorgehen im Requirements Engineering 69</b></p> <p><b>Kapitel 4 Vorgehen in klassischen Projekten</b> <b>71</b></p> <p>Einordnung in den Projektablauf 71</p> <p>Der Ablauf 73</p> <p><b>Kapitel 5 Vorgehen in agilen Projekten</b> <b>77</b></p> <p>Direkte Kommunikation statt Dokumentation 78</p> <p>Der Wert gibt den Takt an 79</p> <p>Das Ziel immer vor Augen 80</p> <p>Die Vorbereitungsphase 80</p> <p>Requirements Engineering in Scrum 82</p> <p>Scrum kurz erklärt 82</p> <p>Wo das Requirements Engineering in Scrum stattfindet 84</p> <p>Das Product Backlog weiterentwickeln: Refinement 86</p> <p>Fertig heißt fertig: die Definition of Done 88</p> <p>Welche Rolle für die Anforderungen zuständig ist 89</p> <p>Wenn mehrere Teams an einem System arbeiten 90</p> <p>Fortwährende Analyse statt Änderungsmanagement 91</p> <p>Die Unterschiede zwischen klassischem und agilem Requirements Engineering 92</p> <p><b>Kapitel 6 Anpassung des Requirements-Engineering-Prozesses</b> <b>93</b></p> <p>Einflussfaktoren 93</p> <p>Facetten des Requirements-Engineering-Prozesses 94</p> <p>Zeitfacette 95</p> <p>Zweckfacette 96</p> <p>Zielfacette 96</p> <p>Konfiguration des Prozesses 97</p> <p><b>Teil III: Anforderungsanalyse 99</b></p> <p><b>Kapitel 7 An die Anforderungen herankommen</b> <b>101</b></p> <p>Stakeholderanalyse 102</p> <p>Stakeholder identifizieren 103</p> <p>Stakeholder verstehen 105</p> <p>Maßnahmen zur Einbindung der Stakeholder 110</p> <p>Zusätzliche Anforderungsquellen 111</p> <p>Anforderungen ermitteln 112</p> <p>Von geheimen und selbstverständlichen Anforderungen: das Kano-Modell 113</p> <p>Wer fragt, gewinnt: die Befragungstechniken 115</p> <p>Anforderungen gemeinsam erheben: Kooperationstechniken 121</p> <p>Schauen Sie genau hin: Beobachtungstechniken 123</p> <p>Systemarchäologie und der Blick zurück: artefaktbasierte Techniken 126</p> <p>Recycling im Requirements Engineering: die Wiederverwendung von Anforderungen 127</p> <p>Seien Sie kreativ: Entwurfs- und Ideenfindungstechniken 128</p> <p>Hypothesen bilden und ausprobieren 133</p> <p>Techniken, die Sie zusätzlich unterstützen 134</p> <p>Welche Technik Ihnen weiterhilft 135</p> <p>Konflikte und der Umgang damit 138</p> <p>Analyse von Konflikten 138</p> <p>Auflösung von Konflikten 139</p> <p><b>Kapitel 8 Was uns zu Beginn klar sein sollte 145</b></p> <p>Wohin soll die Reise gehen? Das Ziel klar vor Augen 145</p> <p>Auf die Verpackung kommt es an: der Produktkarton 147</p> <p>Alles auf einem Blick: das Product Vision Board 150</p> <p>Auf die Schnelle: das Fahrstuhlgespräch 152</p> <p>Den Überblick gewinnen 153</p> <p>Den Kontext des Systems verstehen 154</p> <p>Wie das System verwendet werden soll: Anwendungsfälle 156</p> <p>Der Überblick über die ganze Geschichte: Story Map 159</p> <p>Releases schneiden 164</p> <p>Werden Sie zum Minimalisten: das Minimale Marktfähige Release 164</p> <p>Von der Story Map zum Releaseplan 167</p> <p><b>Kapitel 9 Funktionale Anforderungen verstehen und beschreiben</b> <b>175</b></p> <p>Die Systemverwendung mit Anwendungsfällen beschreiben 176</p> <p>Wer das System zu welchem Zweck verwendet: das Anwendungsfalldiagramm 178</p> <p>Anwendungsfälle Schritt für Schritt: Abläufe beschreiben 180</p> <p>Anwendungsfälle mit Anwendungsfällen erweitern 192</p> <p>Die Geschichten der Nutzer: User Stories 196</p> <p>Die Akzeptanzkriterien einer User Story 198</p> <p>Wie kleine User Stories große ersetzen 201</p> <p>Anwendungsfälle oder User Stories? 205</p> <p>Anwendungsfälle klassisch 205</p> <p>Von der Story Map über Anwendungsfälle zu den User Stories 205</p> <p><b>Kapitel 10 Weitere Aspekte funktionaler Anforderungen</b> <b>209</b></p> <p>Fachliche Begriffe begreifen 210</p> <p>Alle wichtigen Begriffe auf einem Blick: das Glossar 210</p> <p>Der Zusammenhang zwischen den fachlichen Gegenständen im Fachklassenmodell 212</p> <p>Das sind ja Zustände 220</p> <p>Die Zustände fachlicher Gegenstände 220</p> <p>Das System bekommt Zustände 225</p> <p>Wie das Geschäft zu regeln ist 232</p> <p>Prototypen 243</p> <p>Die natürliche Sprache 247</p> <p>Man kann nicht alles verstehen 248</p> <p>Tipps zum Umgang mit der Sprache 248</p> <p>Ein Bausatz für Sätze: Satzschablonen 250</p> <p>Die Sprache und nichts als die Sprache 254</p> <p><b>Kapitel 11 Nichtfunktionale Anforderungen und Randbedingungen</b> <b>257</b></p> <p>Die Bedeutung der nichtfunktionalen Anforderungen 258</p> <p>Nichtfunktionale Anforderungen verstehen 260</p> <p>Nichtfunktionale Anforderungen ermitteln 265</p> <p>Nichtfunktionale Anforderungen in der agilen Entwicklung 270</p> <p>Was schon vorher feststeht: die Randbedingungen 273</p> <p><b>Kapitel 12 Wer weiß, ob das auch so stimmt – Anforderungen prüfen</b> <b>277</b></p> <p>Was gibt es denn da zu prüfen? 278</p> <p>Vorgehen im klassischen Requirements Engineering 279</p> <p>Qualitätskriterien zur Verifikation und Validierung 279</p> <p>Vorgehen im agilen Requirements Engineering 281</p> <p>Techniken für die Prüfung 282</p> <p>Reviewtechniken 282</p> <p>Explorative Validierungstechniken 284</p> <p>Prinzipien der Überprüfung 286</p> <p><b>Kapitel 13 Anforderungen festhalten</b> <b>289</b></p> <p>Zweck der Dokumentation 289</p> <p>Der richtige Zeitpunkt 292</p> <p>Hilfreiche Regeln 294</p> <p>Arten der Dokumentation 295</p> <p>Dokumente 296</p> <p>Modelle 302</p> <p>Anforderungssammlungen im Requirements-Management-Tool 304</p> <p>Product Backlog 305</p> <p>Story Map 306</p> <p>Formularvorlagen für Anforderungen 306</p> <p><b>Teil IV: Requirements Management 309</b></p> <p><b>Kapitel 14 Anforderungen organisieren</b> <b>311</b></p> <p>Requirements Management im agilen Vorgehen 312</p> <p>Der Lebenszyklus einer Anforderung 314</p> <p>Versionierung 316</p> <p>Attribute einer Anforderung 317</p> <p>Kann man so oder so sehen: Sichtweisen 318</p> <p>Konfigurationen 320</p> <p><b>Kapitel 15 Ist das wirklich wichtig? – Priorisierung von Anforderungen</b> <b>323</b></p> <p>Was wichtig ist 324</p> <p>Ad-hoc-Priorisierungstechniken 325</p> <p>Priorisierung mittels Stufen 325</p> <p>Ranking 326</p> <p>Top-Ten-Technik 326</p> <p>Kauf dir ein Feature 326</p> <p>Analytische Priorisierungstechniken 327</p> <p>Wiegers’sche Priorisierungsmatrix 327</p> <p>Kano-Modell 330</p> <p>Vorgehen 330</p> <p><b>Kapitel 16 Die Anforderungen verfolgen 333</b></p> <p>Zweck der Verfolgbarkeit 333</p> <p>Verfolgbarkeit darstellen 335</p> <p>Methodisches Verfolgen 338</p> <p><b>Kapitel 17 Umgang mit Änderungen</b> <b>341</b></p> <p>Ganz normal und doch unbeliebt 341</p> <p>Der Änderungsprozess und seine Bestandteile 342</p> <p><b>Kapitel 18 Werkzeuge im Requirements Engineering: Unterstützung und Last</b> <b>347</b></p> <p>Arten von Werkzeugen 348</p> <p>Office-Tools 348</p> <p>Requirements-Management-Tools 349</p> <p>Modellierungstools 350</p> <p>Was schon da ist: Bugtracker und Wiki 351</p> <p>Lowtech-Tools 351</p> <p>Kombinationen von Tools 352</p> <p>Einführung von Werkzeugen 352</p> <p><b>Teil V: Der Top-Ten-Teil 355</b></p> <p><b>Kapitel 19 Zehn Prinzipien des Requirements Engineering</b> <b>357</b></p> <p>Zusammenarbeit: Requirements Engineering allein funktioniert nicht 357</p> <p>Wertorientierung: Anforderungen sind kein Selbstzweck 358</p> <p>Stakeholder: Es geht darum, ihren Bedarf zu erfüllen 358</p> <p>Gemeinsames Verständnis: Die Basis für erfolgreiche Systementwicklung 358</p> <p>Kontext: Notwendig, um Systeme zu verstehen 359</p> <p>Problem, Anforderung, Lösung: Eine untrennbare Verbindung 359</p> <p>Validierung: Ungeprüfte Anforderungen sind nutzlos 360</p> <p>Evolution: Änderungen sind normal 360</p> <p>Innovation: Mehr vom Gleichen reicht nicht 361</p> <p>Systematische und disziplinierte Arbeit: Ohne geht es nicht 361</p> <p><b>Kapitel 20 Zehn beliebte Fehler im Requirements Engineering 363</b></p> <p>Die Suche nach dem Schuldigen 363</p> <p>Lösungen beschreiben anstatt Probleme zu verstehen 364</p> <p>Anforderungen einfach vom Altsystem übernehmen 364</p> <p>Die Nutzer beschreiben die Anforderungen 364</p> <p>Wir arbeiten agil und dokumentieren nichts 365</p> <p>Entweder keine oder unverständliche Systemdokumentationen 365</p> <p>User Stories sind allein dazu da, die bestehenden Anforderungen in das Backlog aufzunehmen 365</p> <p>Agil und Modellierung geht nicht zusammen 366</p> <p>Fachleute und Entwickler sprechen nicht miteinander 366</p> <p>Das Requirements Engineering läuft nicht, also brauchen wir ein Tool 366</p> <p><b>Kapitel 21 Zehn Online-Quellen</b> <b>369</b></p> <p>IREB-Lehrpläne, Handbücher und Glossar 369</p> <p>Requirements Engineering Magazine 369</p> <p>Scrum-Guide 369</p> <p>Online Browsing Platform der ISO 370</p> <p>V-Modell 370</p> <p>UML-Spezifikation 370</p> <p>UML-Übersicht 371</p> <p>DMN-Spezifikation 371</p> <p>Übersicht über Requirements-Tools 371</p> <p>Übersicht über UML-Tools 371</p> <p>Stichwortverzeichnis 375</p>
Dr. Marcus Winteroll ist Mitglied der oose Innovative Informatik eG, einem Anbieter von Schulungen und Workshops zu Software & Systems Engineering in Hamburg. Als Trainer und Berater beschäftigt er sich mit der Analyse sowie Verbesserung von Geschäfts- und Entwicklungsprozessen. Dazu setzt er auf agile Methoden; aber auch die klassischen Vorgehensweisen sind ihm aus seiner langjährigen Erfahrung als Requirements Engineer, Projektleiter, Prozessmanager, Qualitätssicherer und Entwickler vertraut. Seine gesammelten Erfahrungen teilt er auf Konferenzen und als Autor von Fachartikeln.

Diese Produkte könnten Sie auch interessieren: