[et_pb_section fb_built=”1″ fullwidth=”on” _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_fullwidth_header title=”Requirements for Software Architects” subhead=”Moderne Techniken des Requirement Engineerings” content_max_width_tablet=”” content_max_width_phone=”100%” content_max_width_last_edited=”on|desktop” _builder_version=”4.20.4″ _module_preset=”default” title_font=”|600|||||||” title_font_size=”54px” subhead_font=”|600|||||||” subhead_font_size=”19px” background_enable_color=”off” use_background_color_gradient=”on” background_color_gradient_stops=”rgba(0,63,134,0.81) 0%|rgba(0,63,134,0.47) 100%” background_color_gradient_overlays_image=”on” background_image=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2022\/08\/digitization-g1a284b6fd_1920.jpg” height=”306px” hover_enabled=”0″ title_font_size_tablet=”30px” title_font_size_phone=”27px” title_font_size_last_edited=”on|desktop” global_colors_info=”{}” sticky_enabled=”0″ title_text=”digitization-g1a284b6fd_1920″][\/et_pb_fullwidth_header][\/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_row _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.20.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_text content_tablet=”<\/p>\n<\/p>\n
Herzlich Willkommen zu unserer neuen Blog-Serie, Requirements for Software Architects!
Erfahren Sie in dieser dreiteiligen Reihe etwas \u00fcber die Signifikanz von Anforderungen Ihrer Kunden, die verschiedenen Rollen des Agile Requirement Engineerings und moderne Techniken.<\/p>\n
” content_phone=”<\/p>\n
Herzlich Willkommen zu unserer neuen Blog-Serie, Requirements for Software Architects!
Erfahren Sie in dieser dreiteiligen Reihe etwas \u00fcber die Signifikanz von Anforderungen Ihrer Kunden, die verschiedenen Rollen des Agile Requirement Engineerings und moderne Techniken.<\/p>\n
” content_last_edited=”on|desktop” _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n
<\/p>\n
Herzlich Willkommen zum letzten Teil unserer Blog-Serie, in der wir moderne Techniken des Requirement Engineerings vorstellen.<\/p>\n
\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n
Wir haben nun erkl\u00e4rt, worum es sich bei Anforderungen handelt und wie die Reise einer Anforderung von Erhebung bis zur Architektur aussieht und wer daran beteiligt ist. Wir haben auch gesehen, welche Risiken damit einhergehen, wenn Anforderungen nicht gen\u00fcgend Aufmerksamkeit entgegengebracht wird.
\nIm Folgenden m\u00f6chten wir nun einige Techniken aufzeigen, welche die Arbeit mit Anforderungen vereinfachen oder verbessern k\u00f6nnen.[\/et_pb_text][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n
Die Produktvision ist das langfristige Ziel, das ein Unternehmen anstrebt. Ziel ist es, ein Produkt zu schaffen, das einen Zweck erf\u00fcllt. Produktvision beschreibt, was herauskommen soll also das \u201eWas\u201c.<\/p>\n
Eine von den besten und klar ausformuliertesten Visionen stammt von J.F. Kennedy \u2013 die erste Mondlandung.<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _module_preset=”default”][et_pb_column _builder_version=”4.20.4″ _module_preset=”default” type=”4_4″][et_pb_blurb image=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2023\/09\/Bild1.jpg” _builder_version=”4.20.4″ _module_preset=”default” title_text=”Bild1″ hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n
\u00a0President Kennedy speak to Congress on May 25th, 1961<\/em><\/p>\n [\/et_pb_blurb][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _module_preset=”default”][et_pb_column _builder_version=”4.20.4″ _module_preset=”default” type=”4_4″][et_pb_blurb image=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2023\/09\/Bild2.jpg” _builder_version=”4.20.4″ _module_preset=”default” title_text=”Bild2″ hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n Commander Neil Armstrong working at an equipment storage area on the lunar module, Credits: NASA<\/em><\/p>\n [\/et_pb_blurb][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n Ein Team mit einer guten, klaren, greifbaren Produktvision kann ein besseres Produkt entwickeln als ein Team ohne Vision oder nur mit einer vagen Vorstellung davon, wohin die Reise gehen soll.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n Es ist einer der wichtigsten Aufgaben eines Product Owners (BA, RE), als auch des Softwarearchitekten, diejenigen zu identifizieren, die in einem Projekt involviert sind. Es gibt viele verschiedene Methoden f\u00fcr die strukturierte Stakeholder Analyse. Zur gezielten Stakeholder-Identifikation kann die Stakeholder Matrix ungemein helfen:<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_blurb image=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2023\/09\/Bild3.png” content_max_width=”619px” content_max_width_tablet=”619px” content_max_width_phone=”619px” content_max_width_last_edited=”on|phone” _builder_version=”4.20.4″ _module_preset=”default” header_font_size=”15px” hover_enabled=”0″ global_colors_info=”{}” title_text=”Bild3″ sticky_enabled=”0″]<\/p>\n Stakeholder Gewichtung \u2013 Wie behandle ich meine Stakeholder?<\/em><\/p>\n [\/et_pb_blurb][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _module_preset=”default”][et_pb_column _builder_version=”4.20.4″ _module_preset=”default” type=”4_4″][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n \u00dcberwachung (geringes Interesse, geringe Einfluss und somit Auswirkung):<\/strong><\/p>\n Diese Stakeholder sollten gezielt informiert werden, ohne mit ihnen unrelevante Informationen zu teilen. Eine sorgf\u00e4ltige Abstimmung der Kommunikation mit diesen Partnern ist notwendig, um Relevanz sicherzustellen.<\/p>\n Zufriedenstellen (viel Einfluss, geringes Interesse):<\/strong><\/p>\n Informieren (geringe Wirkung, hohes Interesse):<\/strong><\/p>\n In engem Kontakt bleiben (hohe Wirkung, hohes Interesse):<\/strong><\/p>\n Mithilfe von Personas versucht man einen bestimmten Anwendertyp zu beschreiben. Dabei versetzt man sich in die Person hinein, um seine Situation zu verstehen und daraus seine Bed\u00fcrfnisse zu definieren. Eine Persona ist ein gutes Mittel, um Anforderungen zu erheben. Ihre Nutzung ist oft sinnvoll, wenn Kundenbefragungen (ein Werkzeug f\u00fcr die Anforderungserhebung) unm\u00f6glich sind. Zudem wird Persona bei gro\u00dfen Produkten\/Systemen genutzt, die von einer breiten Gruppe Endnutzern bedient werden.<\/p>\n Beispiel:<\/p>\n Herr Mathias ist 45, verheiratet und hat zwei Kinder. Er arbeitet als Qualit\u00e4tsbeauftragter f\u00fcr die Bundesagentur f\u00fcr Arbeit. Er f\u00e4hrt jeden Morgen Zug von Mannheim nach Frankfurt und ist stolz darauf, seit 15 Jahren einen bedeutenden Beitrag zur Effizienz und Wirksamkeit der Agentur geleistet zu haben. In seiner Freizeit verbringt er Zeit mit seinen Freunden in einer Gastst\u00e4tte in der Altstadt, wo sie lebendige Gespr\u00e4che f\u00fchren und gemeinsame Interessen teilen.<\/p>\n In diesem Beispiel ist die Beschreibung der Persona k\u00fcrzer gehalten. In der Praxis kann diese eine komplette Seite bef\u00fcllen. Wichtig bei der Verfassung von Personas ist die Empathie, also die Ber\u00fccksichtigung von besonderen Details und Emotionen. Nur so kann man einen Kunden oder Endnutzer richtig verstehen.<\/p>\n Use Cases beschreiben eine Anforderung oder Features eines Produktes aus Kundensicht.<\/p>\n Ziel ist, eine (erste) Beschreibung der Funktionalit\u00e4t des zu entwickelnden Produkts in der Sprache des Kunden zu bekommen.<\/p>\n Das hat einige Vorteile:<\/p>\n Nach der Festlegung der verschiedenen Anwendungsf\u00e4lle, die vom Kunden oder mit ihm zusammen formuliert wurden, k\u00f6nnen diese Anwendungsf\u00e4lle weiter detailliert und verfeinert werden.<\/p>\n An dieser Stelle kommen Use Case Dokumente (Name des Anwendungsfalls, Vorbedingungen, Normalablauf, Alternativablauf, Nachbedingungen) und UML (z.B. Anwendungsfall Diagramm, Aktivit\u00e4tsdiagram) ins Spiel, um die Anforderungen an das System zu verdeutlichen und zu visualisieren. In den weiteren Schritten (Softwarearchitekten Rolle) kommen auch weitere Diagramme zur Darstellung und Definition von internen Strukturen und Abl\u00e4ufen, um die Softwarearchitektur zu visualisieren.<\/p>\n User Stories (Nutzergeschichten) sind pr\u00e4gnante Beschreibungen eines Features aus Anwendersicht. Wichtig dabei ist, dass sie in ein bis zwei S\u00e4tzen formuliert werden.<\/p>\n Die Story soll erz\u00e4hlen, warum der Anwender eine bestimmte Funktionalit\u00e4t ben\u00f6tigt und welche Ziele oder Nutzen er damit erzielen kann. Im Gegensatz zu den klassischen Techniken im Requirements Engineering gibt die User Story nicht die L\u00f6sung vor, wie das Feature umgesetzt wird, sondern nur das, was umgesetzt (ben\u00f6tigt) wird. In einer User Story wird kein \u201eWie\u201c, sondern nur das \u201eWas\u201c beschrieben. Dokumentiert werden sollte von der User Story der Hintergrund, Begr\u00fcndung, Ziele oder Nutzen, warum dieses bestimmte Feature implementiert werden soll.<\/p>\n Im agilen Umfeld hat sich ein Satz-Musteretabliert, dass es immer drei Hauptelemente sind, die den Wert einer Funktionalit\u00e4t in ihrer Nutzung abbilden: Rolle<\/strong>, Feature<\/strong> und Begr\u00fcndung<\/strong> (Wert\/Nutzen usw.).<\/p>\n Die Formulierung kann wie folgt aussehen:<\/p>\n Als <Rolle><\/strong> m\u00f6chte ich <Feature><\/strong>, weil <Begr\u00fcndung><\/strong><\/p>\n Als <Rolle><\/strong> m\u00f6chte ich <Feature><\/strong>, um <Nutzen \/ Wert><\/strong> zu bekommen.<\/p>\n <\/p>\n Beispiele:<\/p>\n Priorisierung von Anforderungen und die Pflege von Product Backlog Eintr\u00e4gen (=PBI Product Backlog Items) geh\u00f6ren zu den allt\u00e4glichen Aufgaben eines Product Owners. Story Mapping ist ein sehr gutes Werkzeug, um diese Herausforderung zu meistern.<\/p>\n Die Methode kann man sowohl zu Beginn, um \u00fcberhaupt User Stories ableiten zu k\u00f6nnen, als auch w\u00e4hrend des Entwicklungsprozesses verwenden. Da es im agilen Umfeld in jedem Falle iterativ und schrittweise entwickelt wird, werden nach jedem Kundenfeedback oder erforderlichen Anpassung neue User Stories entstehen.<\/p>\n Eine Story Map besteht aus zwei Dimensionen (horizontale und vertikale). In der ersten horizontalen Dimension stehen die groben Anforderungen. In der zweiten vertikalen Dimension werden diese Anforderungen verfeinert. Je tiefer man geht, desto mehr nimmt der Detaillierungsgrad zu. Ziel ist es, eine Anforderung aus Sicht des Kunden in verfeinerten und kleinen Tasks zu zerlegen, um diese dann umsetzen zu k\u00f6nnen. Das Story Mapping kann daher auch als Verwaltungstechnik verstanden werden.<\/p>\n <\/p>\n Die erstellten User Stories kann man jetzt (oder alternativ in einem Schritt vorher) in Epics zusammenfassen. Diese Epics gruppieren zusammenh\u00e4ngende User Stories. Dabei erfolgt die Zusammenfassung zum Beispiel basierend auf \u00fcbergeordneten Gesch\u00e4ftszielen oder der M\u00f6glichkeit, sie als eigenst\u00e4ndige, bepreiste Dienstleistungen anzubieten. Zum Beispiel k\u00f6nnten User Stories wie \u201eAntragstellung f\u00fcr Kindergeld\u201c, \u201eAntragspr\u00fcfung durch Sachbearbeiter\u201c und \u201eKindergeldauszahlung\u201c unter dem Epic \u201eKindergeldverwaltung\u201c geb\u00fcndelt werden.<\/p>\n Vorteile:<\/p>\n Einige der effektivsten Methoden, um ASRs zu ermitteln, sind:<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n Ein strukturiertes Interview kann helfen blinde Flecken bei der Erhebung von insbesondere nichtfunktionalen Anforderungen zu identifizieren und wird mit Stakeholdern individuell durchgef\u00fchrt. Dennoch m\u00fcssen gefundene Anforderungen nach einem Interview noch hinsichtlich ihrer Relevanz f\u00fcr die Architektur eingesch\u00e4tzt werden. Auch helfen Anforderungen noch nicht zwingend ein messbares und entscheidbares Merkmal (z.B. in Form eines Qualit\u00e4tsszenarios) abzuleiten. Dies kann bei Bedarf allerdings auch als Teil des Interviews mit den Stakeholdern durchgef\u00fchrt werden.<\/p>\n Diese Technik macht sich zunutze, dass es viele Aufstellungen und Kategorisierungen m\u00f6glicher Qualit\u00e4tsanforderungen gibt. Die Befragung anhand von bestehenden Aufstellungen zu gestalten, hilft Stakeholdern oft Bereiche von Anforderungen zu identifizieren, welche sie zuvor nicht in Betracht gezogen haben.<\/p>\n \u00a0Einige Modelle f\u00fcr die Strukturierung von qualitativen Merkmalen sind zum Beispiel<\/p>\n [\/et_pb_text][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n Ein beispielhafter Ablauf f\u00fcr ein Interview kann wie folgt aussehen:<\/p>\n F\u00fcr das Interview wird f\u00fcr jede Kategorie eine beispielhafte Anforderung an das System vorbereitet.<\/p>\n Danach wird dem Stakeholder das Ziel des Interviews und die Methode vorgestellt.<\/p>\n Im Anschluss wird zusammen mit dem entsprechenden Stakeholder das Modell Kategorie f\u00fcr Kategorie durchgegangen. Sind von diesem Stakeholder in dieser Kategorie bereits Anforderungen bekannt, so wird eine Kategorie ggf. ausgelassen.<\/p>\n Dabei werden alle entstehenden Anforderungen aufgenommen. Bei der Aufnahme von Anforderungen wird zus\u00e4tzliche gefragt, wie die Anforderung dem Stakeholder hilft, sein Ziel zu erreichen. So wird die Relevanz der Anforderung verifiziert, da diese Art von Interview die Gefahr birgt eine \u00fcbergro\u00dfe Menge an Anforderungen zu erzeugen. Zudem wird es m\u00f6glich einen \u00dcberblick \u00fcber die unterliegenden Interessen des Stakeholders zu erlangen. Zuletzt wird sich beim Stakeholder f\u00fcr seine Zeit bedankt.<\/p>\n Im Anschluss an das Interview werden die aufgenommenen Anforderungen mit bestehenden Dokumentationen abgeglichen und neue Anforderungen aufgenommen. Sollten Anforderungen im Widerspruch zu bisher erfassten Anforderungen stehen, so wird R\u00fccksprache mit dem Stakeholder und ggf. PO, BA und RE gehalten. Zuletzt werden die Anforderungen hinsichtlich architektureller Signifikanz bewertet.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _module_preset=”default”][et_pb_column _builder_version=”4.20.4″ _module_preset=”default” type=”4_4″][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n <\/strong><\/p>\n <\/p>\n Die verhaltensgesteuerte Entwicklung, auch als anforderungsgetriebene Softwareentwicklung bezeichnet, wurde erstmals 2003 von \u201eDan North\u201c beschrieben und ist seitdem weitergewachsen. Dan North entwickelte auch das erste Framework zur Implementierung von BDD in JBehave.<\/p>\n BDD ist eine weitere agile Softwareentwicklungstechnik, die die Zusammenarbeit zwischen verschiedenen Beteiligten, insbesondere beim Gespann Softwarearchitekt \/ Product Owner \/ Business Analyst, in Softwareentwicklungsprojekten verbessert. Bei der verhaltensorientierten (verhaltensgetriebenen) Entwicklung werden bei der Anforderungsanalyse Softwareaufgaben, Ziele und Ergebnisse in einer definierten textuellen Form erfasst, die sp\u00e4ter als automatisierte Tests durchgef\u00fchrt werden k\u00f6nnen.<\/p>\n Auf diese Weise kann \u00fcberpr\u00fcft werden, ob die Software korrekt implementiert wurde oder weitere Anpassungen ben\u00f6tigt werden.<\/p>\n Die Softwareanforderungen werden in Szenarien formuliert, typischerweise als “Wenn-Dann”-Klauseln\u201c. Dieser Ansatz basiert auf der Sprache des dom\u00e4nengesteuerten Designs (DDD-Domain-Driven Design).<\/p>\n Ziel ist es, ein gemeinsames Verst\u00e4ndnis zu entwickeln und einen \u00dcbergang von den technischen Anforderungen zur Implementierung zu erleichtern.<\/p>\n Gem\u00e4\u00df BDD verwendet man f\u00fcr die Verhaltens-Spezifizierung ein Format, das von User-Story-Spezifikationen (Als Rolle…) \u00a0abgeleitet wird.<\/p>\n Jede User Story sollte in gewisser Weise der folgenden Struktur folgen:<\/p>\n Titel<\/strong><\/p>\n Ein expliziter Titel<\/em><\/p>\n Narrativ \/ Erz\u00e4hlung<\/strong><\/p>\n Eine kurze Einf\u00fchrung mit folgendem Aufbau:<\/em><\/p>\n Als: <\/strong>die Person oder Rolle, die aus der Funktion einen Nutzen zieht;<\/p>\n m\u00f6chte Ich<\/strong>: die Funktion \/ Feature;<\/p>\n damit<\/strong>: der Nutzen oder Wert der Funktion.<\/p>\n Akzeptanzkriterium<\/strong><\/p>\n Eine Beschreibung jedes spezifischen Szenarios der Erz\u00e4hlung mit der folgenden Struktur:<\/em><\/p>\n Gegeben: <\/strong>der Anfangskontext zu Beginn des Szenarios in einem oder mehreren Abschnitten;<\/p>\n Wenn: <\/strong>das Ereignis, das das Szenario ausl\u00f6st;<\/p>\n Dann: <\/strong>das erwartete Ergebnis in einer oder mehreren Klauseln.<\/p>\n Beispiel<\/p>\n Szenario 1: R\u00fcckgegebene Ware kommt wieder ins Lager<\/p>\n Es ist ratsam, dass Softwarearchitekt, Business Analyst und Entwickler zusammenarbeiten, um die Szenarien zu entwerfen und die daraus resultierenden Ergebnisse in einem separaten Dokument festgehalten werden.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _module_preset=”default”][et_pb_column _builder_version=”4.20.4″ _module_preset=”default” type=”4_4″][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n Anforderungen sind ein, wenn nicht der, treibende Faktor der Softwareentwicklung. Deswegen ist die Erhebung, Dokumentation, Spezifikation und Verwaltung der Anforderungen eine der wichtigsten T\u00e4tigkeiten in der Softwareentwicklung.<\/p>\n Trotzdem sind auch gute Anforderungen noch kein Garant f\u00fcr Erfolg, wie wir an der Dynamik zwischen Anforderungserhebung und Deklaration als architekturrelevanter Anforderung erkennen k\u00f6nnen. Offene Kommunikation und ein gemeinsames Verst\u00e4ndnis \u00fcber die Anforderungen und dem was daraus gemacht wird, inklusive entsprechender Abnahmen sind also ebenso essenziell.<\/p>\n Dies zeigt die Notwendigkeit f\u00fcr Requirements Engineer, Product Owner, Business Analyst und Softwarearchitekten zusammenzuarbeiten und eine gemeinsame Sprache und Basis zu finden, um den Anforderungen im Interesse des Projekterfolges Konsistenz zu verleihen, nicht nur einmalig, sondern iterativ und fortw\u00e4hrend.<\/p>\n Damit schlie\u00dft unsere Blog-Serie zu Requirements for Software Architects auch ab. Vielen Dank f\u00fcrs Lesen!<\/p>\n <\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _module_preset=”default”][et_pb_column _builder_version=”4.20.4″ _module_preset=”default” type=”4_4″][et_pb_text _builder_version=”4.20.4″ _module_preset=”default” hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n Abbildung 1: https:\/\/www.nasa.gov\/topics\/history\/features\/kennedy_moon_speech.html<\/a><\/p>\n Abbildung 2: https:\/\/astrobiology.nasa.gov\/missions\/apollo-11\/<\/a><\/p>\nStakeholder Analyse<\/h6>\n
\n
\n
\n
Persona<\/h6>\n
Agile Techniken zum Dokumentieren von Anforderungen<\/strong><\/h6>\n
<\/h6>\n
Anwendungsf\u00e4lle (Use Cases)<\/h6>\n
\n
User Stories<\/h6>\n
\n
Agile Techniken zur Spezifikation von User Stories<\/strong><\/h6>\n
Story Mapping<\/h6>\n
Agile Techniken zur Verwaltung von Anforderungen<\/strong><\/h6>\n
Epics<\/h6>\n
\n
Techniken zur Identifikation von architekturrelevanten Anforderungen<\/strong><\/h6>\n
\n
Strukturiertes Interview<\/h6>\n
\n
Techniken zur Abnahme von Anforderungen<\/strong><\/h6>\n
BDD<\/h6>\n
\n
Fazit<\/strong><\/h6>\n
Quellen<\/strong><\/h6>\n
\n
Abbildungen<\/strong><\/h6>\n