[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=”Agile Requirements Engineering und seine Rollen” 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=”25px” background_enable_color=”off” background_image=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2022\/08\/AdobeStock_370451866-scaled.jpeg” height=”306px” title_font_size_tablet=”30px” title_font_size_phone=”27px” title_font_size_last_edited=”on|desktop” subhead_font_size_tablet=”25px” subhead_font_size_phone=”17px” subhead_font_size_last_edited=”on|desktop” global_colors_info=”{}”][\/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 column_structure=”1_2,1_2″ _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”1_2″ _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” global_colors_info=”{}”] <\/p>\n
<\/p>\n
Willkommen zur\u00fcck zum zweiten Artikel in unserer Blog-Serie \u201eRequirements for Software Architects\u201c. Wir widmen uns in diesem Beitrag dem agilen Requirements Engineering und seinen Rollen.<\/p>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=”1_2″ _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_image src=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2023\/06\/shutterstock_2171688145-scaled.jpg” title_text=”Software Architect” _builder_version=”4.20.4″ _module_preset=”default” border_radii=”on|5px|5px|5px|5px” global_colors_info=”{}”][\/et_pb_image][\/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
<\/strong><\/p>\n <\/strong><\/p>\n Es befinden sich zahlreichen Definitionen von Softwarearchitektur. Wir beschr\u00e4nken uns deshalb nur auf zwei davon:<\/p>\n Softwarearchitekten haben die Aufgabe die Softwarearchitektur aktiv zu gestalten und ihre Umsetzung und Wirksamkeit sicherzustellen. Dabei sollen sie im Wesentlichen die folgenden Ziele in einem Projekt erreichen:<\/p>\n Die Arbeit eines Architekten kann dabei in sechs T\u00e4tigkeiten gegliedert werden:<\/p>\n Der erste Schritt \u201eAnforderungen kl\u00e4ren\u201c stellt dabei die Schnittstelle unter anderem zum Requirements Engineering dar. Hierbei probiert der Architekt herauszufinden, welche Anforderungen architektonisch relevant sind.<\/p>\n Architecturally Significant Requirements (ASRs) umfassen die wichtigsten architektonischen Anforderungen. Dabei ist es egal, ob es sich um Funktionale oder nicht Funktionale Anforderungen handelt. Somit sind ASRs Anforderungen, die sich direkt auf das Architekturdesign auswirken.<\/p>\n Ein Architekt sollte alle NFRs mit den Stakeholdern abgestimmt und dokumentiert haben. Es ist \u00fcblich, dass eine funktionale oder nichtfunktionale Anforderung in unterschiedlichen Phasen des Software-Lebenszyklus den Status einer ASR erlangen oder verlieren kann.<\/p>\n Sein Entwurf und insbesondere seine Entwurfsentscheidungen sollten daher transparent machen auf Basis welcher ASRs eine Entscheidung oder ein Entwurf beruht, um Nachvollziehbarkeit zu erlangen und eine wirksame Architektur sicherzustellen.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _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_image src=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2023\/06\/Abbildung-9.png” title_text=”Abbildung 9″ show_in_lightbox=”on” align=”center” _builder_version=”4.20.4″ _module_preset=”default” width=”100%” max_width=”100%” global_colors_info=”{}”][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _module_preset=”default” background_color=”#F3F3F3″ use_background_color_gradient=”on” background_color_gradient_stops=”#ffffff 1%|#ffffff 99%” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_blurb title=”Abbildung 9: Architecture in Technical Perspective View” _builder_version=”4.20.4″ _module_preset=”default” header_font_size=”15px” global_colors_info=”{}”][\/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” global_colors_info=”{}”]<\/p>\n Um diese zu erreichen, sollen Softwarearchitekten diese Anforderungen stets \u00fcberpr\u00fcfen und die Unterschiede und Besonderheiten erkl\u00e4ren. Insbesondere der PO, RE und BA, aber auch andere Akteure, sollten f\u00fcr ein besseres Verst\u00e4ndnis und eine bessere Kommunikation sensibilisiert werden .<\/p>\n Einige g\u00e4ngige Quellen f\u00fcr ASRs sind,<\/p>\n \u00a0Solange ASRs in der Dokumentation vorhanden sind, k\u00f6nnen sie von Softwarearchitekten analysiert und verbessert werden. Sind sie jedoch nicht oder unvollst\u00e4ndig dokumentiert, so besteht das Risiko einer unwirksamen Architektur. Eine unwirksame Architektur ist nicht in der Lage die funktionalen und nichtfunktionalen Anforderungen zu erf\u00fcllen und stellt nicht nur ein signifikantes Projektrisiko dar, sondern ist mit fortschreitender Projektlaufzeit zudem teuer zu \u00e4ndern.<\/p>\n Architecturally Significant Requirements (ASRs) m\u00fcssen deshalb Vorrang bei der Identifizierung und Dokumentation haben, um das Architekturdesign in die richtige Richtung zu leiten.<\/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” global_colors_info=”{}”]<\/p>\n Wie bereits zuvor etabliert sollen Anforderungen nicht nur korrekt erhoben werden, sondern auch verst\u00e4ndlich kommuniziert und ihre Erreichung gepr\u00fcft werden. Dabei sind Anforderungen stetig um Wandel und bed\u00fcrfen Pflege.<\/p>\n Agile Requirements Engineering ist ein kooperativer, iterativer und inkrementeller Ansatz, der dies erreichen soll. Er gliedert sich gro\u00df in zwei Phasen: Die Definitionsphase (Anforderungserstellung) und die eigentliche Umsetzungsphase (Entwicklung). Im Gegensatz zu den herk\u00f6mmlichen Vorgehensweisen laufen die beiden Phasen, Definition und Implementierung, parallel ab.<\/p>\n Daraus ergeben sich viele Vorteile. Zu diesen Vorteilen geh\u00f6rt die schnelle und flexible Reaktion auf ver\u00e4nderte oder neue Gegebenheiten.<\/p>\n Dies wird dadurch gew\u00e4hrleistet, dass die Anforderungsbeschreibung nie abgeschlossen und w\u00e4hrend der gesamten Entwicklungsdauer st\u00e4ndig neu erfasst und angepasst wird. Das hei\u00dft, wenn einzelne Aspekte eines Prozesses von den akzeptablen Grenzen abweichen oder das resultierende Produkt nicht akzeptabel ist, muss der Prozess oder die erzielten Ergebnisse angepasst werden. Eine Anpassung sollte so schnell wie m\u00f6glich erfolgen, um weitere Abweichungen zu reduzieren. Dieser Ansatz folgt vier Zielen:<\/p>\n Requirements Engineering Aktivit\u00e4ten sind sehr weit gef\u00e4chert und von der Art des zu entwickelnden Systems und der Organisationsspezifikation abh\u00e4ngig. Nichtsdestotrotz geh\u00f6ren auch im agile Requirements Engineering folgende vier zentrale T\u00e4tigkeiten, die von IREB etabliert wurden, dazu:<\/p>\n <\/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” global_colors_info=”{}”]<\/p>\n \u00a0Die Begriffe Requirements Engineering und Requirements Management werden oft f\u00e4lschlicherweise als Synonym verwendet. Wenn man von einem ganzheitlichen Requirements-Engineering-Ansatz spricht, muss man das streng genommen immer im Sinne des Anforderungsmanagements tun. R\u00fcckblickend auf die bereits genannten vier zentralen Aktivit\u00e4ten bezieht sich Requirements Engineering haupts\u00e4chlich auf die ersten drei Punkte. Requirement Engineering, was ins Deutsche \u00fcbersetzt wird, bedeutet Anforderungsmanagement und umfasst damit die vierte zentrale Aktivit\u00e4t.<\/p>\n Die beiden Fachtermini sind jedoch untrennbar miteinander verbunden und gehen Hand in Hand mit Requirements Management: Ohne Ermittlung gibt es keine Verwaltung und ohne effiziente Verwaltung und Aufbereitung hat die Ermittlung von Anforderungen keinen Nutzen.<\/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” global_colors_info=”{}”]<\/p>\n \u00a0Agiles Requirements Engineering geschieht nicht ad-hoc, sondern \u00fcber unterschiedlichen Rollen. In der Praxis kommt es oft vor, dass es nur eine Rolle gibt (wie PO, BA, RE oder alle zusammen). Unabh\u00e4ngig davon wie viele Rollen in der Praxis vorhanden sind, kann die Unterteilung genutzt werden, um die unterschiedlichen T\u00e4tigkeiten und Verantwortlichkeiten des Requirements Engineering und Management gewinnbringend zu gliedern und die eigene Arbeit zu strukturieren.<\/p>\n Der Product Owner ist f\u00fcr die Wertsteigerung, genauer gesagt die Rentabilit\u00e4t (= ROI, Return of Investment) verantwortlich, nicht nur was das Produkt angeht, sondern auch in Bezug auf das Projektteam. Es handelt sich also um eine anspruchsvolle Aufgabe. Hierbei sind ihm drei zentrale Aufgaben zugeordnet:<\/p>\n Dabei sollte er die richtige Funktionalit\u00e4t in der richtigen Priorit\u00e4t ins Projekt bringen. Daraus abgeleitet sollte er die folgenden Skills und Aufgaben meistern k\u00f6nnen:<\/p>\n \u00c4hnlich zur PO-Rolle sollte der Business Analyst (BA) \u00fcber Kreativit\u00e4ts- und Erhebungstechniken verf\u00fcgen. Zudem unterst\u00fctzt er den Product Owner bei der Erhebung fachlicher Anforderungen, deren Akzeptanzkriterien und der Pr\u00fcfung, ob und wie die Anforderungen zu den Gesch\u00e4ftsprozessen passen.<\/p>\n Zu guter Letzt k\u00fcmmert sich der Requirements Engineer (RE) f\u00fcr die nachhaltige Spezifizierung von Anforderungen und ihre \u00dcbersetzung in das technische Umfeld.<\/p>\n Alle drei Rollen sollten \u00fcber die folgenden Skills verf\u00fcgen:<\/p>\n Alle diese Skills k\u00f6nnen je nach Bedarf und Aufgabengebiet verwendet werden.<\/p>\n <\/p>\n Welche verschiedenen modernen Techniken in Requirement Engineerings eingesetzt werden k\u00f6nnen, sehen wir uns im n\u00e4chsten und letzten Teil der Blog-Serie an. Wir freuen uns schon Sie wiederzusehen.<\/p>\n <\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.20.4″ _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 _builder_version=”4.20.4″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n <\/p>\n <\/p>\n<\/a>Definition<\/h6>\n
\n
Aufgaben von Softwarearchitekten<\/h6>\n
\n
\n
<\/a>ASR: Architektonisch bedeutende Anforderungen<\/h6>\n
\n
Agile Requirements Engineering<\/strong><\/h6>\n
\n
\n
<\/a>Der Unterschied zwischen Requirements Engineering und Requirements Management<\/h6>\n
<\/a>Die Product Owner (PO), Business Analyst (BA) und Requirements Engineer (RE) Rollen<\/h6>\n
\n
\n
\n
Quellen<\/strong><\/strong><\/h6>\n
\n
Abbildungen<\/strong><\/strong><\/h6>\n
![https:\/\/media.geeksforgeeks.org\/wp-content\/uploads\/20200704172739\/Untitled-Diagram160.png<\/a><\/p>\n[\/et_pb_text][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" Willkommen zur\u00fcck zum zweiten Artikel in unserer Blog-Serie \u201eRequirements for Software Architects\u201c. Wir widmen uns in diesem Beitrag dem agilen Requirements Engineering und seinen Rollen. Grundbegriffe von Softwarearchitektur Definition Es befinden sich zahlreichen Definitionen von Softwarearchitektur. Wir beschr\u00e4nken uns deshalb nur auf zwei davon: Die grundlegenden Konzepte oder Eigenschaften eines Systems in seiner […]<\/p>\n","protected":false},"author":1,"featured_media":35565,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"","_et_gb_content_width":"2880","footnotes":""},"categories":[549,833,565,547,557],"tags":[],"class_list":["post-35548","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-methodisch","category-softwarearchitektur","category-softwareentwicklung","category-technisch","category-trainings-und-workshops"],"_links":{"self":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/35548","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/comments?post=35548"}],"version-history":[{"count":10,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/35548\/revisions"}],"predecessor-version":[{"id":53567,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/posts\/35548\/revisions\/53567"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/media\/35565"}],"wp:attachment":[{"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/media?parent=35548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/categories?post=35548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itech-progress.com\/en\/wp-json\/wp\/v2\/tags?post=35548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"https:\/\/media.geeksforgeeks.org\/wp-content\/uploads\/20200704172739\/Untitled-Diagram160.png\"){kind=link}