Software Architecture Gathering 2024

Software Architecture Gathering 2024

Software Architecture Gathering 2024

We will be there!

Essential for Software Architects!
Get ready! We are proud to announce that we will once again be a sponsor and active participant at the Software Architecture Gathering (SAG) 2024 in Berlin – from November 11-14!

With nearly 40 captivating expert presentations and a host of exciting workshops, you will gain invaluable insights into the secrets of successful software architecture.

ITech Progress won’t just be present at an information stand (Tuesday, November 12 to Wednesday, November 13, 2024); we will also host a workshop on the first day and deliver two engaging expert presentations on the first and second conference days.

Additionally, our Chief Architect Mahbouba Gharbi has once again taken an active role in shaping the event program as a member of the program committee.

Our team will be on-site, ready to connect with like-minded professionals and share the latest trends, challenges, and innovations in the field of software architecture. Whether you’re looking to discuss groundbreaking solutions, network with industry leaders, or simply stop by to say hello – we can’t wait to meet you!

We’re offering an exclusive 20% discount on your SAG 2024 tickets.

Use the promo code ITECHPROGRESS20 when registering for the event. Don’t miss this opportunity to be part of the future of software architecture and profit from a reduced rate!

ITech Progress Jubiläum

ITech Progress Jubiläum

Jahre Jubiläum

𝗜𝗺𝗺𝗲𝗿 𝗮𝗺 𝗣𝘂𝗹𝘀 𝗱𝗲𝗿 𝗜𝗻𝗻𝗼𝘃𝗮𝘁𝗶𝗼𝗻!

Am 07. Juni 2024 haben wir unser 20-jähriges Jubiläum auf unvergessliche Weise gefeiert. Diese besondere Feier war nicht nur ein Rückblick auf unsere Errungenschaften, sondern auch ein Fest der Gemeinschaft, des Feierns und der Inspiration.
Während dieser Feier wurden wir nicht nur von spektakulären Shows beeindruckt, sondern auch von der Vielfalt und Kreativität, die unser Team auszeichnet. Ein Zauberer faszinierte uns mit seinen Künsten, die Lichtkünstler entführten uns in eine Welt magischer Farben und Formen, und die Feuerkünstler entfachten die Leidenschaft und den Ehrgeiz in unseren Herzen.
Diese Auftritte waren mehr als nur Unterhaltung – sie waren Symbole für Kreativität, Innovation und die unbegrenzten Möglichkeiten, die entstehen, wenn Talent und Leidenschaft aufeinandertreffen. Sie spiegelten die Essenz unseres Unternehmens wider – vielseitig, dynamisch und stets bereit, Grenzen zu überschreiten.
Doch das wahre Highlight unserer Feier waren nicht die spektakulären Shows, sondern die Menschen, die sie erlebt haben. Jeder hat durch seine Anwesenheit, sein Engagement und seine Einzigartigkeit dieses Jubiläum zu einem unvergesslichen Erlebnis gemacht. Gemeinsam haben wir gelacht, getanzt und uns inspirieren lassen – und genau das macht uns zu dem Team, das wir sind.

Wir danken jedem Einzelnen für die Teilnahme, die Beiträge und die unermüdliche Leidenschaft, die unser 20. Jubiläum zu einem unvergesslichen Ereignis gemacht hat. Die Begeisterung ist der Antrieb, unser Bestes zu geben, aufregende Wege zu gehen und gemeinsam Großartiges zu erreichen.
Während wir auf die Feierlichkeiten zurückblicken, erinnern wir uns nicht nur an die Showeinlagen, sondern vor allem an die Momente des Miteinanders, der Freude und der Verbundenheit. Diese Erinnerungen werden uns immer begleiten und uns dazu inspirieren, auch in Zukunft gemeinsam nach den Sternen zu greifen.
Auf die nächsten 20 Jahre – möge unser Weg weiterhin magisch, inspirierend und erfolgreich sein!

Web-Sicherheitsmodul von iSAQB – Wir sind akkreditiert!

Web-Sicherheitsmodul von iSAQB – Wir sind akkreditiert!

Web-Sicherheitsmodul von iSAQB - Wir sind akkreditiert!

“Wir sind stolz darauf, die Akkreditierung für das Web-Sicherheit-Modul erhalten zu haben. Diese Zertifizierung ist ein Beweis für die Qualität unserer Ausbildungsprogramme und unser kontinuierliches Bestreben, die Kompetenzen unserer Teilnehmer im Bereich der Web-Sicherheit zu stärken.”

Mahbouba Gharbi, Geschäftsführerin der ITech Progress GmbH

ITech Progress freut sich die offizielle Akkreditierung für das Modul Web-Sicherheit von iSAQB® – International Software Architecture Qualification Board bekannt zu geben. Diese bedeutende Anerkennung unterstreicht unser Engagement für exzellente Bildungsstandards und unsere Expertise im Bereich der Web-Sicherheit.

In der heutigen digitalen Welt ist Web-Sicherheit ein entscheidender Faktor für die Geschäftskontinuität und den Schutz von Daten. Das Internet, als offenes System, bietet Hackern zahlreiche Möglichkeiten für Angriffe und den Diebstahl sensibler Informationen. Unternehmen und Organisationen müssen daher ihre Web-Anwendungen und -Dienste sicher gestalten und regelmäßig auf Schwachstellen überprüfen.
Das Modul Web-Sicherheit des iSAQB richtet sich an Softwarearchitekten und bietet eine umfassende Einführung in die Grundlagen der Web-Sicherheit. Die Teilnehmer lernen wichtige Sicherheitsmaßnahmen wie die Implementierung von Firewalls, die Verwendung von Verschlüsselungstechniken und die Identifizierung und Behebung von Schwachstellen kennen. Durch die richtige Kombination dieser Maßnahmen kann das Risiko von Angriffen und Datenverlusten erheblich reduziert werden.
Das Modul behandelt auch die Implementierung von Sicherheitsmaßnahmen wie Authentifizierung und Autorisierung, um die Zugriffsrechte auf Web-Anwendungen und -Dienste zu regeln. Die Teilnehmer lernen, wie sie diese Maßnahmen effektiv in ihre Systeme integrieren können, um die Sicherheit weiter zu erhöhen.
Zusammenfassend bietet das Web-Sicherheit-Modul eine umfassende Einführung in die Web-Sicherheit und befähigt die Teilnehmer, ihre Web-Anwendungen und -Dienste sicherer zu gestalten und regelmäßig auf Schwachstellen zu überprüfen.

Logo ITech Academy in grauer Schrift

Für weitere Informationen über unsere neuen Web-Sicherheit-Schulungen und melden Sie sich bitte hier.

Die ersten Termine werden in Kürze veröffentlich und selbstverständlich auch hier bekannt gegeben.

OOP 2024 – wir sind dabei!

OOP 2024 – wir sind dabei!

OOP digital 2024 – wir sind dabei!

H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH

Es ist gut, unseren Geist gegen den von anderen zu reiben und zu polieren.

Michel Eyquem de Montaigne

Wir blicken auf eine Woche voller interessanter und bereichernder Gespräche bei der OOP in München zurück!

Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.
H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH
Was ist die OOP? SOFTWARE MEETS BUSINESS – eine führende Fachkonferenz für Softwarearchitekten mit angeschlossener Messefläche die immer Januar in München stattfindet. Immer? Dies war das erste Jahr nach der Pandemie in dem die Messe wieder zu gewohnter Zeit stattfand. Sie ist der ideale Ort, um auf dem Laufenden zu bleiben, Inspiration zu sammeln und wertvolle Kontakte zu knüpfen.
Neben neuen Kontakten haben wir uns aber auch insbesondere gefreut, alte Bekannte widerzutreffen – es ist einfach ein grandioser Event des Austausches!
Ein besonderes Highlight am Stand war natürlich das Gewinnspiel für eine iSAQB-lizensierte Schulung!
Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.

Wir freuen uns jetzt schon auf nächstes Jahr!

Requirements for Software Architects

Requirements for Software Architects

Requirements for Software Architects

Moderne Techniken des Requirement Engineerings

 

Herzlich Willkommen zum letzten Teil unserer Blog-Serie, in der wir moderne Techniken des Requirement Engineerings vorstellen.

Techniken

Wir haben nun erklärt, 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ügend Aufmerksamkeit entgegengebracht wird.
Im Folgenden möchten wir nun einige Techniken aufzeigen, welche die Arbeit mit Anforderungen vereinfachen oder verbessern können.

Agile Techniken zum Erstellen, Pflegen und Priorisieren von Funktionalen Anforderungen
Produktvision

Die Produktvision ist das langfristige Ziel, das ein Unternehmen anstrebt. Ziel ist es, ein Produkt zu schaffen, das einen Zweck erfüllt. Produktvision beschreibt, was herauskommen soll also das „Was“.

Eine von den besten und klar ausformuliertesten Visionen stammt von J.F. Kennedy – die erste Mondlandung.

 President Kennedy speak to Congress on May 25th, 1961

Commander Neil Armstrong working at an equipment storage area on the lunar module, Credits: NASA

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.

Stakeholder Analyse

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ür die strukturierte Stakeholder Analyse. Zur gezielten Stakeholder-Identifikation kann die Stakeholder Matrix ungemein helfen:

Stakeholder Gewichtung – Wie behandle ich meine Stakeholder?

Überwachung (geringes Interesse, geringe Einfluss und somit Auswirkung):

Diese Stakeholder sollten gezielt informiert werden, ohne mit ihnen unrelevante Informationen zu teilen. Eine sorgfältige Abstimmung der Kommunikation mit diesen Partnern ist notwendig, um Relevanz sicherzustellen.

Zufriedenstellen (viel Einfluss, geringes Interesse):

  • Es ist wichtig, ausreichend Zeit in diese Anspruchsgruppen zu investieren, um ihre Zufriedenheit zu gewährleisten, ohne jedoch ein Gefühl der Überlastung zu erzeugen.

Informieren (geringe Wirkung, hohes Interesse):

  • Informieren Sie diese Stakeholder entsprechend. Und sammeln Sie relevante Daten, um größere Probleme zu vermeiden. Stakeholder dieser Kategorie stehen Projektdetails oft kritisch gegenüber.

In engem Kontakt bleiben (hohe Wirkung, hohes Interesse):

  • Diese Stakeholder sind Hauptakteure. Sie sollten vollständig in das Projekt eingebunden werden. Nehmen Sie sich genug Zeit, um sie zufrieden zu stellen.
Persona

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ürfnisse zu definieren. Eine Persona ist ein gutes Mittel, um Anforderungen zu erheben. Ihre Nutzung ist oft sinnvoll, wenn Kundenbefragungen (ein Werkzeug für die Anforderungserhebung) unmöglich sind. Zudem wird Persona bei großen Produkten/Systemen genutzt, die von einer breiten Gruppe Endnutzern bedient werden.

Beispiel:

Herr Mathias ist 45, verheiratet und hat zwei Kinder. Er arbeitet als Qualitätsbeauftragter für die Bundesagentur für Arbeit. Er fährt 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ätte in der Altstadt, wo sie lebendige Gespräche führen und gemeinsame Interessen teilen.

In diesem Beispiel ist die Beschreibung der Persona kürzer gehalten. In der Praxis kann diese eine komplette Seite befüllen. Wichtig bei der Verfassung von Personas ist die Empathie, also die Berücksichtigung von besonderen Details und Emotionen. Nur so kann man einen Kunden oder Endnutzer richtig verstehen.

Agile Techniken zum Dokumentieren von Anforderungen
Anwendungsfälle (Use Cases)

Use Cases beschreiben eine Anforderung oder Features eines Produktes aus Kundensicht.

Ziel ist, eine (erste) Beschreibung der Funktionalität des zu entwickelnden Produkts in der Sprache des Kunden zu bekommen.

Das hat einige Vorteile:

  • Kundenbedürfnisse können besser und richtig verstanden werden, da sie in seinen eigenen Worten ausgedrückt werden
  • Es ist eine gute Entscheidungsbasis für die Priorisierung von Anforderungen
  • Missverständnisse verringern sich, sodass keine unerwünschten Anforderungen in das Produkt aufgenommen werden.
  • Scope: Nur das aufzunehmen, was auch zum System gehören sollte

Nach der Festlegung der verschiedenen Anwendungsfälle, die vom Kunden oder mit ihm zusammen formuliert wurden, können diese Anwendungsfälle weiter detailliert und verfeinert werden.

An dieser Stelle kommen Use Case Dokumente (Name des Anwendungsfalls, Vorbedingungen, Normalablauf, Alternativablauf, Nachbedingungen) und UML (z.B. Anwendungsfall Diagramm, Aktivitätsdiagram) 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äufen, um die Softwarearchitektur zu visualisieren.

User Stories

User Stories (Nutzergeschichten) sind prägnante Beschreibungen eines Features aus Anwendersicht. Wichtig dabei ist, dass sie in ein bis zwei Sätzen formuliert werden.

Die Story soll erzählen, warum der Anwender eine bestimmte Funktionalität benötigt 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ösung vor, wie das Feature umgesetzt wird, sondern nur das, was umgesetzt (benötigt) wird. In einer User Story wird kein „Wie“, sondern nur das „Was“ beschrieben. Dokumentiert werden sollte von der User Story der Hintergrund, Begründung, Ziele oder Nutzen, warum dieses bestimmte Feature implementiert werden soll.

Im agilen Umfeld hat sich ein Satz-Musteretabliert, dass es immer drei Hauptelemente sind, die den Wert einer Funktionalität in ihrer Nutzung abbilden: Rolle, Feature und Begründung (Wert/Nutzen usw.).

Die Formulierung kann wie folgt aussehen:

Als <Rolle> möchte ich <Feature>, weil <Begründung>

Als <Rolle> möchte ich <Feature>, um <Nutzen / Wert> zu bekommen.

 

Beispiele:

  1. Als pendelnder Passagier möchte ich häufig gebuchte Zugsstrecken möglichst schnell wieder buchen können, um Zeit beim Buchen zu sparen.
  2. Als Personalleiter möchte ich die beantragten Urlaubsanträge direkt im System unterschreiben können, um den Urlaub genehmigen zu können, ohne die Urlaubsanträge herunterladen zu müssen.
Agile Techniken zur Spezifikation von User Stories
Story Mapping

Priorisierung von Anforderungen und die Pflege von Product Backlog Einträgen (=PBI Product Backlog Items) gehören zu den alltäglichen Aufgaben eines Product Owners. Story Mapping ist ein sehr gutes Werkzeug, um diese Herausforderung zu meistern.

Die Methode kann man sowohl zu Beginn, um überhaupt User Stories ableiten zu können, als auch während 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.

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önnen. Das Story Mapping kann daher auch als Verwaltungstechnik verstanden werden.

 

Agile Techniken zur Verwaltung von Anforderungen
Epics

Die erstellten User Stories kann man jetzt (oder alternativ in einem Schritt vorher) in Epics zusammenfassen. Diese Epics gruppieren zusammenhängende User Stories. Dabei erfolgt die Zusammenfassung zum Beispiel basierend auf übergeordneten Geschäftszielen oder der Möglichkeit, sie als eigenständige, bepreiste Dienstleistungen anzubieten. Zum Beispiel könnten User Stories wie „Antragstellung für Kindergeld“, „Antragsprüfung durch Sachbearbeiter“ und „Kindergeldauszahlung“ unter dem Epic „Kindergeldverwaltung“ gebündelt werden.

Vorteile:

  • Divide et impera“: Das gesamte zu entwickelnde System kann zu Beginn des Projektes in Teilbereiche erfasst werden.
  • Projektstrukturierung, das heißt, es können Teile des Systems zu Projektbeginn abstrakt beschrieben werden, ohne früher ins Detail gehen zu müssen.
  • Ein wichtiger Vorteil bei der Verwendung von Epics ist die Kontrolle über das Fachkonzept oder Product Backlog (User Stories Liste). Ansonsten kann man bei größeren Projekten, verbunden mit einem Product Backlog mit hunderten User Stories, schnell den Überblick verlieren.
Techniken zur Identifikation von architekturrelevanten Anforderungen

Einige der effektivsten Methoden, um ASRs zu ermitteln, sind:

  • Fragebogen / Checkliste
  • Stakeholder-Befragungen
  • Qualitätsattribut-Workshops (QAW)*
Strukturiertes Interview

Ein strukturiertes Interview kann helfen blinde Flecken bei der Erhebung von insbesondere nichtfunktionalen Anforderungen zu identifizieren und wird mit Stakeholdern individuell durchgeführt. Dennoch müssen gefundene Anforderungen nach einem Interview noch hinsichtlich ihrer Relevanz für die Architektur eingeschätzt werden. Auch helfen Anforderungen noch nicht zwingend ein messbares und entscheidbares Merkmal (z.B. in Form eines Qualitätsszenarios) abzuleiten. Dies kann bei Bedarf allerdings auch als Teil des Interviews mit den Stakeholdern durchgeführt werden.

Diese Technik macht sich zunutze, dass es viele Aufstellungen und Kategorisierungen möglicher Qualitätsanforderungen 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.

 Einige Modelle für die Strukturierung von qualitativen Merkmalen sind zum Beispiel

Ein beispielhafter Ablauf für ein Interview kann wie folgt aussehen:

Für das Interview wird für jede Kategorie eine beispielhafte Anforderung an das System vorbereitet.

Danach wird dem Stakeholder das Ziel des Interviews und die Methode vorgestellt.

Im Anschluss wird zusammen mit dem entsprechenden Stakeholder das Modell Kategorie für Kategorie durchgegangen. Sind von diesem Stakeholder in dieser Kategorie bereits Anforderungen bekannt, so wird eine Kategorie ggf. ausgelassen.

Dabei werden alle entstehenden Anforderungen aufgenommen. Bei der Aufnahme von Anforderungen wird zusätzliche 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 übergroße Menge an Anforderungen zu erzeugen. Zudem wird es möglich einen Überblick über die unterliegenden Interessen des Stakeholders zu erlangen. Zuletzt wird sich beim Stakeholder für seine Zeit bedankt.

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ücksprache mit dem Stakeholder und ggf. PO, BA und RE gehalten. Zuletzt werden die Anforderungen hinsichtlich architektureller Signifikanz bewertet.

Techniken zur Abnahme von Anforderungen

BDD

 

Die verhaltensgesteuerte Entwicklung, auch als anforderungsgetriebene Softwareentwicklung bezeichnet, wurde erstmals 2003 von „Dan North“ beschrieben und ist seitdem weitergewachsen. Dan North entwickelte auch das erste Framework zur Implementierung von BDD in JBehave.

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äter als automatisierte Tests durchgeführt werden können.

Auf diese Weise kann überprüft werden, ob die Software korrekt implementiert wurde oder weitere Anpassungen benötigt werden.

Die Softwareanforderungen werden in Szenarien formuliert, typischerweise als “Wenn-Dann”-Klauseln“. Dieser Ansatz basiert auf der Sprache des domänengesteuerten Designs (DDD-Domain-Driven Design).

Ziel ist es, ein gemeinsames Verständnis zu entwickeln und einen Übergang von den technischen Anforderungen zur Implementierung zu erleichtern.

Gemäß BDD verwendet man für die Verhaltens-Spezifizierung ein Format, das von User-Story-Spezifikationen (Als Rolle…)  abgeleitet wird.

Jede User Story sollte in gewisser Weise der folgenden Struktur folgen:

Titel

Ein expliziter Titel

Narrativ / Erzählung

Eine kurze Einführung mit folgendem Aufbau:

Als: die Person oder Rolle, die aus der Funktion einen Nutzen zieht;

möchte Ich: die Funktion / Feature;

damit: der Nutzen oder Wert der Funktion.

Akzeptanzkriterium

Eine Beschreibung jedes spezifischen Szenarios der Erzählung mit der folgenden Struktur:

Gegeben: der Anfangskontext zu Beginn des Szenarios in einem oder mehreren Abschnitten;

Wenn: das Ereignis, das das Szenario auslöst;

Dann: das erwartete Ergebnis in einer oder mehreren Klauseln.

Beispiel

Szenario 1: Rückgegebene Ware kommt wieder ins Lager

  • Gegeben ist, dass ein Kunde eine schwarze Hose gekauft hat
  • Und wir daraufhin 3 schwarze Hosen im Lager hatten,
  • Wenn er die Hose zurückgibt und dafür einen Gutschein erhält,
  • Dann werden wir 4 schwarze Hosen im Lager haben.

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.

Fazit

Anforderungen sind ein, wenn nicht der, treibende Faktor der Softwareentwicklung. Deswegen ist die Erhebung, Dokumentation, Spezifikation und Verwaltung der Anforderungen eine der wichtigsten Tätigkeiten in der Softwareentwicklung.

Trotzdem sind auch gute Anforderungen noch kein Garant für Erfolg, wie wir an der Dynamik zwischen Anforderungserhebung und Deklaration als architekturrelevanter Anforderung erkennen können. Offene Kommunikation und ein gemeinsames Verständnis über die Anforderungen und dem was daraus gemacht wird, inklusive entsprechender Abnahmen sind also ebenso essenziell.

Dies zeigt die Notwendigkeit für 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ährend.

Damit schließt unsere Blog-Serie zu Requirements for Software Architects auch ab. Vielen Dank fürs Lesen!

 

Quellen
  • Sommerville, Ian (2009). Softwareengineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
  • Andreas Wintersteiger, Scrum Schnelleinstieg
  • McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
  • https://t2informatik.de/
  • North, Introducing Behaviour Driven Development
  • Dan North et al.: Question about Chapter 11: Writing software that matters. (Nicht mehr online verfügbar.) Archiviert vom Original am 7. November 2009; abgerufen am 9. November 2011 (englisch): „The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition“
  • Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
  • “Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
  • Ken Schwaber; Jeff Sutherland. “The Scrum Guide”. Scrum.org. Retrieved October 27, 2017.
  • https://www.scrum.org/
  • http://agilemanifesto.org/
  • https://www.isaqb.org/
  • https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/
Abbildungen

Abbildung 1: https://www.nasa.gov/topics/history/features/kennedy_moon_speech.html

Abbildung 2: https://astrobiology.nasa.gov/missions/apollo-11/

Abbildung 3: Stakeholder Gewichtung — Wie behandle ich meine Stakeholder? | FelixKlauke (medium.com)