\n3. Bis hierhin…

… reicht unser kleiner Auszug. Auf den folgenden Seiten finden Sie noch unser Glossar sowie die Literatur- und Quellenangaben.

Im gesamten Buch folgen an dieser Stelle noch einige spannende und hilfreiche Kapitel:

Umgang mit funktionalen Anforderungen
Qualitätsanforderungen
Behavior-Driven Development (BDD)
Priorisierung von Anforderungen
Vorgehen
Werkzeuge
Ausblick

",{"_171":172,"_43":44,"_47":16,"_45":46,"_69":70,"_173":174,"_195":169},"previewContent","

Inhaltsverzeichnis

\n Als Entwicklungsteam im Stich gelassen?\n
- \n Unsere Annahmen über Sie\n
- \n Über dieses Buch\n
- \n iSAQB und IREB\n
- \n Danksagung\n
\n
\n 1. Einführung und Ziele\n
- \n Entwicklungsteams benötigen adäquate Anforderungen\n
- \n Lernziele\n
\n
\n 2. Clean Start\n
- \n Visionen und Ziele\n
- \n Stakeholder\n
- \n Scope\n
- \n Weiterer Input\n
- \n Bleiben Sie dran\n
- \n Lernziele\n
\n
\n 3. Bis hierhin…\n
\n Glossar\n
\n Literatur\n
\n Über uns\n
\n Anmerkungen\n

\nAls Entwicklungsteam im Stich gelassen?

\n\n

Sie arbeiten engagiert und gerne als Teil eines Software-Entwicklungsteam an spannenden Systemen oder Produkten. Haben Sie öfter den Eindruck, Ihre Requirements-Engineers, Product-Owner oder Produktmanager haben Sie bezüglich klarer Anforderungen im Stich gelassen? \nLeiden Sie unter fehlenden, vagen oder unklaren Anforderungen, ohne konsistente Prioritäten? \nWillkommen im Club der “Im Stich Gelassenen”.

\n\n

Für Software- und Systemarchitektur stellen „gute” Anforderungen und Randbedingungen die Basis vieler Entscheidungen dar. \nAlle Beteiligten geben vor, das Prinzip “garbage-in, garbage-out” zu kennen, aber von der Anforderungsseite scheinen sich in der Praxis doch eher wenige dran zu halten.

\n\n

Da braucht es konstruktive Abhilfe: \nNehmen Sie als pragmatische Architekt(inn)en das Heft selbst in die Hand! \nNein, Sie wollen auf keinen Fall die Rolle von Product Owner, Business-Analysten und Requirements-Engineers noch zusätzlich übernehmen - \nsondern lediglich die architekturrelevanten Anforderungen so weit klären, dass Sie auf dieser Basis robuste Architekturentscheidungen treffen können.

\n\n

In diesem Buch behandeln wir die Grundsätze von “Anforderungsklärung” für Softwarearchitektur. \nWir starten bei grundlegendem Scoping und der Kontextabgrenzung, kümmern uns um Ermittlung (architekturrelevanter) \nfunktionaler Anforderungen und tauchen dann in die kritischen Qualitätsziele und -anforderungen ab. \nSie bekommen zahlreiche methodische Tipps, gepaart mit Beispielen aus dem echten Leben.

\n\n

\nUnsere Annahmen über Sie

\n\n

Ohne Sie persönlich zu kennen, haben wir beim Schreiben dieses Buches einige Annahmen über Sie getroffen:

\n\n

Sie arbeiten in der Softwareentwicklung, möglicherweise in einer Entwicklungs- oder Architekturrolle. \nIn dieser Rolle haben Sie schon mal unter schlechten Anforderungen gelitten. Vermutlich waren Sie der klassischen Regel „Garbage-in, Garbage-out“ ausgeliefert.
Sie arbeiten als Product-Owner, Business-Analyst(in) oder im Requirements-Engineering, und möchten gerne besser verstehen, \nwelche Anforderungen Ihr Entwicklungsteam genau benötigt, wann, in welcher Form, und in welchem Detailgrad.
Sie tragen Verantwortung für die Erstellung eines softwareintensiven Systems, und möchten sicherstellen, dass Ihre fachlichen und technischen Stakeholder (Fachseite und Entwicklungsteam) sich bezüglich Anforderungen bestens verstehen.

\n\n

\nÜber dieses Buch

Wir Autoren, Peter und Gernot, arbeiten seit vielen Jahren als Consultants, Coaches und Trainer in der praktischen Softwareentwicklung und -architektur. \nAllzu oft mussten wir erleben, dass trotz großartiger, kreativer und kundiger Entwicklungsteams dabei Produkte entstanden, \ndie leider nicht die wahren Bedürfnisse der BenutzerInnen erfüllt haben.

\n\n

Dieses Buch orientiert sich von Struktur und Inhalt am iSAQB Advanced-Modul „Req4Arc“ (Requirements for Architects). \nDeswegen finden Sie in den Kapiteln jeweils einen Extrakt der zum Kapitel gehörigen Lernziele dieses Lehrplans.

\n\n

Sie können Requirements-Engineering auch in Trainings von uns lernen.

\n\n

Peter bietet unter https://req42.de Seminare und Consulting an.\nPeter und Gernot veranstalten gemeinsam (als „dynamisches Duo“) interaktive Workshops zu Req4Arc, siehe https://arc42.de

\n\n

\niSAQB und IREB

Schon seit langer Zeit bietet das „International Requirements Engineering Board“ (IREB, siehe https://ireb.org) zahlreiche Trainings und Ausbildungen im Bereich „Requirements Engineering“ an. \nMehrere Zig-Tausend Personen arbeiten als IREB zertifizierte Requirements-Engineers. \nTrotzdem kommt in manchen Entwicklungsprojekten von diesem wichtigen Wissen und den zugehörigen praktischen Fähigkeiten zu wenig an.\nDaher haben wir uns entschlossen, das Thema Anforderungen von Seiten der Softwarearchitektur aufzugreifen und es auch in das Portfolio des iSAQB aufzunehmen.

\n\n

Wenn Sie (professioneller) Requirements-Engineer werden möchten, dann führt an der Ausbildung des IREB praktisch kein Weg vorbei: \nIREB deckt im Requirements Engineering sowohl in der Breite wie auch in der Tiefe mehr ab, als wir das im kompakten Req4Arc schaffen. \nFür viele Projekte wäre es jedoch schon ein Erfolg, wenn wenigstens unsere Vorschläge aus diesem Buch Eingang in die Praxis finden würden.

\n\n

\nDanksagung

\n\n

Wir danken allen Freiwilligen, die bei Planung und Entwicklung des Req4Arc-Lehrplans aktiv mitgewirkt \nund sich an der Diskussion über die Inhalte beteiligt haben, insbesondere \nAli Akbarian, Wolfgang Fahl, Mahbouba Gharbi, Sebastian Hirschmeier, Wolfgang Keller, Roger Rhoades, Dr. Michael Sperber, \nProf. Hartmut Schirmacher sowie Stefan Zörner. \nDanke auch an die übrigen Mitwirkenden der Advanced-Level-Working-Group des iSAQB für eure moralische Unterstützung sowie an Sebastian Eberstaller für das Buch-Cover.

\n\n

Peter: Danke an Monika – die schon wieder ein Buchprojekt durch moralischen Beistand, kritische Fragen und Gewährung von Freizeit zum Schreiben unterstützt hat. Danke an meine agileExperts Kollegen Markus Meuten und Dirk Fritsch für die fruchtbringenden Diskussion beim Aufbau des req42.de Portals.

\n\n

Gernot: Danke an meine Traumfrau Cheffe Uli, für unglaublich viel positive Energie und Verständnis – \nund natürlich Deine perfekte Urlaubsplanung. Danke an meine KollegInnen der INNOQ – von Euch lerne ich jeden Tag.

\n\n\n\n

\n1. Einführung und Ziele

\n\n

Softwarearchitekten und Entwicklungsteams leiden häufig unter schlechten\nbeziehungsweise fehlenden Anforderungen für ihre Arbeit. Dabei finden\nEntwicklungsteams für praktisch jedes Problem eine vernünftige Lösung –\nsofern sie wissen, was genau das Problem liegt [Hruschka-19].

\n\n

Gutes Requirements Engineering respektive Business-Analyse zählen nach\nwie vor zu den wichtigen Erfolgsfaktoren für erfolgreiche Systeme und\nProdukte. Hier zeigen wir Ihnen praktische Wege auf, wie Sie Ihre\nAnforderungen in den Griff bekommen.

\n\n

\nEntwicklungsteams benötigen adäquate Anforderungen

\n\n

Unklare Anforderungen führen in der Entwicklung oftmals zu übermäßig\nflexiblen und komplexen Lösungen [Starke&Hruschka-17]. Und wer\nnachfragt, ist feige – oder?

\n\n

Als Architekten und Entwickler sollten Sie eine der beiden Alternativen\naus Abbildung 1.1 wählen: Entweder Sie klären die schlechten\nAnforderungen selbst (Pfeil 2 im Bild), indem Sie das Gespräch mit den\nStakeholdern suchen, die mit dem Produkt arbeiten wollen oder für die es\ngeschäftlichen Wert bringen soll. Alternativ muss das Entwicklungsteam\ndiejenigen Personen identifizieren, die eigentlich dafür zuständig\nwären, klare Anforderungen zu liefern – und diese dann motivieren, ihren\nJob ordentlich zu erledigen. (Pfeil 1 im Bild).

\n\n

Für die Personen, die eigentlich zuständig für gute Anforderungen wären,\ngibt es unterschiedliche Berufsbezeichnungen. Wir verwenden im Folgenden\nden Scrum-Begriff „Product Owner“. Er drückt genau das aus, was wir\nwichtig finden: Jemand fühlt sich als „Eigner“ für ein Produkt oder ein\nSystem verantwortlich. Dieser Rolle obliegt es, das Produkt kurz- und\nlangfristig erfolgreich zu machen. Sie subsummiert, was früher\neinerseits Projektleitung (Entscheider) und andererseits Requirements\nEngineers beziehungsweise Systemanalytiker oder Business-Analysten\ngemeinsam erledigen mussten: Sowohl gute Anforderungen ausarbeiten und\nkommunizieren, aber auch Entscheidungen darüber zu treffen, was früher\noder später implementiert werden sollte.

\n\n\n

\"Abb. — Abb. 1.1: Zwei Möglichkeiten für bessere Anforderungen

\n\n\n

Unsere Präferenz in Abbildung 1.1 lautet recht eindeutig Alternative 1.\nErzieht Eure Product Owner! Im rauen Praxisalltag allerdings finden Sie\nimmer wieder die Notwendigkeit für Alternative 2, wenn Product Owner\nüberfordert sind oder schlichtweg fehlen.

\n\n

\nModernes Requirements Engineering …

\n\n

… ist ein kooperativer, iterativer und inkrementeller Prozess. Alle am\nProdukt Beteiligten arbeiten eng und vertrauensvoll zusammen. Sie sorgen\ndafür, dass in einer Folge von Releases das Produkt immer besser wird.\nDie Zeiten, in denen wir über Monate und Jahre dicke Pflichten- und\nLastenhefte geschrieben haben, sind – zum Glück – für die meisten von\nuns vorbei. Unser Ziel ist es heute, zunächst einen groben Überblick\nüber alles zu bekommen, was das Produkt leisten soll. Anschließend\nwollen wir sehr schnell diejenigen Teile genauer spezifizieren und\nimplementieren, die frühen Geschäftswert (oder Risikoreduzierung)\nversprechen. Das gibt uns Zeit, die weniger wichtigen Themen erst dann\nzu präzisieren, wenn sie aktuell werden.

\n\n

\nDer „geordnete“ Backlog

\n\n

Agile Methoden wie Scrum ersetzen die klassischen Requirements-Dokumente\ndurch einen ständig gepflegten und nach Prioritäten geordneten Product Backlog. \nDas Wichtige und Dringende steht weiter oben und ist hoffentlich bis in die Details verstanden und präzisiert. \nDas weniger Wichtige steht weiter unten und darf durchaus noch vage und unscharf formuliert sein. Job des Product Owners ist es, immer genügend Details zu haben, die das Entwicklungsteam für die nächsten Iterationen oder Releases benötigt (vgl. Abb. 1.2).

\n\n\n

\"Abb. — Abb. 1.2: Product Backlog statt dicker Dokumente

\n\n\n

Der Product Backlog ist ein Arbeitsinstrument, um mit funktionalen\nAnforderungen auf unterschiedlichem Präzisionsgrad arbeiten zu können.\nFür uns als Architekten sind jedoch oft auch die geforderten Qualitäten\nextrem wichtig. Aber Anforderungen wie „Das System soll maximal zweimal\npro Jahr ausfallen und im Falle eines Ausfalls nach zehn Minuten wieder\nvoll funktionsfähig sein“ bzw. „Das Produkt soll alle Bestimmungen der\nDSGVO einhalten“ sind querschnittlicher Natur. Sie lassen sich nicht\neinfach in so einen Backlog irgendwo einordnen. Wir werden Ihnen im\nKapitel 4 noch viele Hinweise geben, wie Sie solche Aspekte erarbeiten\nkönnen.

\n\n

\nViele spannende Themen

\n\n

In den kommenden Kapiteln greifen wir jeweils einen anderen Aspekt für\ngutes Requirements Engineering auf und geben Ihnen praktische und\npragmatische Tipps, wie Sie zu „just enough“ Requirements kommen.

\n\n

Zunächst adressieren wir den „Clean Start“: Die Tatsache, dass auch\nhochgradig agile Projekte wenigstens ihre Ziele explizit kennen sollten\nund wissen, wer wozu etwas zu sagen hat.

\n\n

Dann betrachten wir unterschiedliche Möglichkeiten, funktionale\nAnforderungen auf den Punkt zu bringen. Gutes Verständnis Ihrer\nBusiness-Prozesse und Ihrer Domänen-Objekte, sowie der Trend zu\n„Specification by Example“ stehen im Mittelpunkt.

\n\n

Ausführlich widmen wir uns dem Kernthema „Qualitätsanforderungen“. Sie\nwissen ja, dass diese die Architektur stärker und nachhaltiger\nbeeinflussen können als die funktionalen Anforderungen. Wir zeigen, wie\nman auch im agilen Umfeld damit vernünftig umgehen kann und widmen uns\ninsbesondere auch den Themen Szenarien und Behavior Driven Development\n(BDD).

\n\n

Dann stellen wir dann das engere Zusammenspiel und die stärkere\nVerzahnung zwischen Business und IT vor. Wir sprechen Methoden wie\n„Design Thinking“ oder „Design Sprints“ und „Discover to deliver“\nGottesdiener-12 an.

\n\n

Schließlich bliebt auch die leidige Frage des Toolings: Mit welchen\nWerkzeugen erfassen und kommunizieren wir Anforderungen? Wir geben Ihnen\nin Kapitel 8 einen kleinen Marktüberblick, angefangen von Kärtchen an\nder Wand über Wikis und Modellierungswerkzeuge bis zu spezialisierten\nRequirements-Tools.

\n\n

Innerhalb der folgenden Kapitel vermitteln wir Ihnen als\nArchitekt(inn)en und Entwickler(innen) das passende\nRequirements-Know-how, so dass Sie trotz oftmals schlechtem\n(Requirements-)Input Ihre Produkte zielsicher entwickeln können.\nNebenbei erfahren Sie, wie Sie Ihre Product Owner oder\nRequirements-Verantwortlichen durch gezieltere Nachfragen zu besseren\nVorgaben bewegen können, damit Sie sich noch mehr auf Ihre Kernaufgabe\nkonzentrieren und spannende Produkte bauen können, die dann exakt die\nBedürfnisse Ihrer Stakeholder oder des Marktes treffen.

\n\n

\nRequirements Engineering Skills aufbauen

\n\n

Die gute Nachricht: modernes Requirements-Engineering können Sie lernen.\nUnter anderem hat das International Requirements Engineering Board IREB\n(www.ireb.org) ein Advanced Modul „RE@Agile“\nfreigegeben [IREB], das gutes Requirements-Engineering in einer agilen\nWelt behandelt.

\n\n

Unter www.req42.de finden Sie dazu eine Reihe von\nOnline-Goodies wie Blog-Beiträge, ein Glossar zu den wichtigsten\nREQ4ARC-Begriffen, eine kommentierte Literaturliste, sowie\nausführlichere Beispiele zu den einzelnen Themen.

\n\n

\nLernziele

\n\n

Wir haben dieses Buch anhand des iSAQB Lehrplans¹ „Req4Arc“\n(Requirements for Software Architects) gegliedert.

\n\n

In den folgenden Kapiteln stellen wir Ihnen an dieser Stelle jeweils die\nzugehören Lernziele dieses Curriculum vor. Den kompletten Lehrplan\nfinden Sie unter Req4Arc

\n\n\n

\n2. Clean Start

\n\n

Ein bisschen Input für Ihre Arbeit dürfen Sie als Entwicklungsteam schon\nerwarten. In dem zweiten Kapitel stellen wir Ihnen drei Zutaten vor, die\nSie als Architekt(in) von anderen auf jeden Fall einfordern sollten. Wir\nnennen das zusammenfassend einen „Clean Start“ für Ihr Projekt oder\nIhre Produktentwicklung. Für den Fall, dass das nicht klappt, kennen Sie\nja Ihr Schicksal: dann müssen Sie diese Teile der Analysearbeit auch\nnoch selbst in die Hand nehmen.

\n\n

Jedes Unterfangen sollte eine klare Vision und/oder klare Ziele\nhaben
Die „Mitspieler“ sollten bekannt sein (neudeutsch: Ihre Stakeholder)
Und Sie sollten Ihre Spielwiese kennen, die Gebiete, die Ihr Team\nbeeinflussen kann (neudeutsch: Ihren Scope)

\n\n\n

\"Abb. — Abb. 2.1: Drei Zutaten für den erfolgreichen Start

\n\n\n

Die drei Aspekte beeinflussen einander gegenseitig: Je ehrgeiziger Ihre\nZiele, desto mehr Mitspieler; je größer der Scope, desto vielfältiger\ndie Ziele. Es spielt daher keine Rolle, in welcher Reihenfolge Sie als\nArchitekt(in) das angehen oder einfordern – Sie benötigen grundsätzlich\nalle drei.

\n\n

\nVisionen und Ziele

\n\n

Sie müssen damit leben, dass sich Anforderungen mit durchschnittlich 1 –\n3% pro Monat ändern. Wir definieren Vision oder Ziele als denjenigen\nTeil der Requirements, die sich in dem geplanten Zeithorizont möglich\nNICHT ändern sollen; also als das, was wir in einer Iteration oder\nEntwicklungsphase wirklich anstreben.

\n\n

Ein Projekt kann Ziele für unterschiedliche Zeithorizonte definieren,\ndie aufeinander abgestimmt werden sollten. Für große Systeme haben wir\ndrei unterschiedliche Zeithorizonte kennen gelernt:

\n\n

strategische Ziele gelten für teilweise für 3 – 5 Jahre
Ziele für den Budgetzyklus von Firmen gelten üblicherweise 1 Jahr
Release-Ziele gelten Wochen bis wenige Monate (unter der\nVoraussetzung, dass Sie innerhalb eines Jahres mehrere Releases\nliefern)

\n\n\n

\"Abb. — Abb. 2.2: Änderungstoleranz bis zum Release

\n\n\n

Innerhalb der Iterationen, die zu einem Release führen, sollten Sie\ndafür sorgen, dass die Anforderungen möglichst stabil bleiben. An den Übergängen zwischen Iterationen gibt es jedoch Zeitfenster, in denen Sie Ziele, Inhalte und Umfang den geänderten Wünschen oder Randbedingungen anpassen können. Tom de Marco & Co nennen das in [DeMarco-07] „Zeit für Änderungen“. Die Toleranz gegenüber Änderungen sollte einen Verlauf ähnlich Abbildung 2.2 nehmen: Je näher Sie einem Release kommen, desto stabiler sollten Anforderungen bleiben.

\n\n

\nWie kommuniziert man Visionen und Ziele

\n\n

Die klassische Art ist es Ziele einfach umgangssprachlich festzuhalten.\nDafür hat sich die Formel „PAM“ bewährt. Legen Sie pro Ziel Purpose,\nAdvantage und Metrik fest.

\n\n

„Purpose“ beschreibt, was Sie erreichen wollen,
Advantage motiviert, warum man dieses Ziel anstrebt, und die
Metrik gibt vor, wie man Zielerreichung überprüfen möchte.

\n\n

Ein Projekt sollte höchstens eine Handvoll solcher Ziele haben. Sorgen\nSie also dafür, dass Sie von Ihren Managern oder Analytikern 3 – 5\nsolche Aussagen (natürlich abgestimmt mit den wichtigsten Stakeholdern)\nbekommen. Sie wollen definitiv ohne Zielkonflikte starten können.

\n\n

In der agilen Welt finden Sie einige weitere Spielarten von\nZieldefinitionen. Eine davon ist die Erstellung eines „Produktkoffers“\n(vgl. Abbildung 2.3). Neben dem Namen des Produkts und einem Logo, das\nallen Beteiligten das Gefühl vermittelt „Das sind wir“, „Das ist unser\nBaby“ sollten darauf 3 – 5 Haupteigenschaften des geplanten Produkts\nstehen, möglichst so formuliert, dass die Kunden oder Nutzer das Produkt\nunbedingt haben wollen.

\n\n\n

\"Abb. — Abb. 2.3: Varianten der Zielfestlegung

\n\n\n

Eine Alternative dazu sind die „News from the Future“. Schreiben Sie am Anfang eines Projektes einen kurzen Zeitungsartikel, von dem Sie annehmen, dass er am Tag nach der Freigabe auf der Titelseite Ihrer Lieblingszeitung erscheint. Darin wird – vor Beginn der Entwicklung – festgehalten, was Sie als Lobeshymne auf Ihr Produkt am Tag nach dem Release lesen wollen.

\n\n

Alle drei Arten der Zieldefinition finden Sie in [IREB] ausführlicher beschrieben. Die Notation spielt keine Rolle, aber als Architekt sollten Sie die Ziele des Business auf jeden Fall kennen.

\n\n

\nStakeholder

\n\n

Der zweite wesentlich Einflussfaktor, den Projektmanagement und\nAnalytiker bereits geklärt haben sollen, bevor Sie zu arbeiten beginnen, sind die Stakeholder Ihres Vorhabens. Wer hat welchen Einfluss? Wer kann wobei helfen oder hindern? Und auf dieser Liste sollte viel mehr stehen als nur der Sponsor des Vorhabens und Ihre potentiellen Kunden oder Nutzer. Die allerwichtigsten Ihrer Stakeholder haben erheblichen Einfluss auf die Ziele und den Scope des Vorhabens.

\n\n

Eine solche Liste zu erstellen, ist kein Hexenwerk. Setzen Sie eine\nkleine Gruppe von Projektbeteiligten an einen Tisch und lassen Sie diese 15 Minuten brainstormen. Dann haben Sie wahrscheinlich schon 20 bis 30 Stakeholder identifiziert. Nun schicken Sie diese Liste an alle gefundenen Personen und fragen, wen Sie noch vergessen haben. Mit diesem „Schneeballeffekt“ wird Ihre Stakeholderliste schnell vollständig.

\n\n

Warum ist die Kenntnis der Stakeholder so wichtig? Sowohl für Analyse wie auch für Architektur und Entwicklung gilt: Vergessene Stakeholder sind vergessene Requirements! Damit ist nicht gesagt, dass Sie alle Stakeholder, die Sie finden, auch intensiv am Projekt beteiligten müssen. Wenn Sie alle wichtigen potentiellen Interessenten kennen, dann können Sie aktiv entscheiden, wie viel oder wenig Sie diese in das Projekt einbinden wollen oder müssen.

\n\n

Bezüglich der Form gilt – ähnlich wie für die Ziele: Sie haben\nFreiheiten. Nehmen Sie eine einfache Tabelle und führen Sie untern den Überschriften „Rolle“, „Ansprechpartner“, „Einfluss“,… Ihre\nStakeholder einfach linear auf. Oder zeichnen Sie eine Stakeholder-Map, in der Sie Stakeholder und deren Abhängigkeiten bzw.\nKommunikationskanäle visualisieren. Hilfreich ist oft auch eine\nStakeholder-Matrix (vgl. Abbildung 2.4), um das Verhältnis zwischen\nEinfluss und Interesse auszudrücken.

\n\n

Für Ihre Architekturarbeit kommen dann sicherlich noch viele weitere Stakeholder hinzu: alle, die mit der Lösung zu tun haben bzw. Teilsysteme oder Technologien zuliefern. Diese spielten eventuell für Ihr Management und die Analytiker noch keine Rolle. Als Architekt(in) müssen Sie aber all diese Personen und Organisation identifizieren.

\n\n\n

\n\n\n

Weitere Tipps zum Umgang mit Stakeholdern haben wir online unter\n[Stakeholder] oder in [Starke&Hruschka-16] für Sie zusammengestellt.

\n\n

\nScope

\n\n

Der dritte Bestandteil eines „Clean Start“ wird oft in der Praxis\nignoriert, obwohl doch die Festlegung von Scope und Kontext den weiteren Verlauf des Projekts erheblich beeinflussen. Die Definitionen der beiden Begriffe sind einfach: Scope ist der Bereich, den das Projekt aktiv gestalten kann – ihre Spielweise. Zum Kontext gehören alle Personen und IT-Systeme (evtl. auch Hardware-Sensorik und Aktuatorik), über die Sie nicht alleine entscheiden können (vgl. Abbildung 2.5). Wenn Sie im Kontext bzw. an den Schnittstellen zwischen Scope und Kontext etwas ändern wollen, dann müssen Sie mit den Nachbarn darüber verhandeln. Wenn\nSie nicht verhandeln können oder dürfen, dann gelten die Festlegungen aus dem Kontext für Sie einfach als nicht beeinflussbare Randbedingungen.

\n\n\n

\"Abb. — Abb. 2.5: Abgrenzung von Scope und Kontext

\n\n\n

Die Scope-Festlegung sollte erfolgen, um „innen“ von „außen“\nunterscheiden zu können und die Schnittstellen zwischen „innen“ und\n„außen“ zu identifizieren. Eine einfache Notation dafür ist das\nsogenannte Kontextdiagramm (vgl. [Hruschka-19]), das nur aus drei\nElementen besteht: Ihr System oder Produkt in der Mitte, rundherum alle Personen oder Systeme im Kontext, und allen Informationen, die aus dem Kontext in den Scope fließen bzw. aus dem Scope in den Kontext – kurz gesagt: die Ein- und Ausgaben Ihres Systems. Für Analytiker und Projektmanager reicht es aus, früh im Projekt über die ein- und ausgehenden Daten Bescheid zu wissen. Sie als Architekt(in) werden die Schnittstellen später noch sehr viel genauer betrachten müssen (Technologie, Protokolle, Push- oder Pull, Mengengerüste, Vertrauen in die Schnittstelle, …). Als Einstieg gilt aber: Schnittstelle erkannt, Gefahr halbwegs gebannt. Vergessene Schnittstellen gehören zu den Dingen, die Ihnen als Architekt(in) das Leben erschweren.

\n\n

Erfahrungsgemäß tun sich viele Projekte und/oder Teams schwer damit, diese einfache Abgrenzung präzise vorzunehmen: Was gehört in unseren Scope und mit wem müssen wir verhandeln? Deshalb wollen wir im folgenden genauer auf die Feinheiten der Scope-Festlegung eingehen.

\n\n

\nProduktscope und Projektscope

\n\n

Wenn man von Produkt oder System spricht, ist meist ein IT-Produkt oder\nein IT-System gemeint. Sollte Ihre Aufgaben also darin bestehen, ein\n(einziges) neues IT-System zu schaffen, so sind Produktscope und\nProjektscope identisch. In der Praxis betreffen Projekte manchmal auch\nmehrere vorhandene IT-Systeme. Möglicherweise müssen Sie ein System neu\nentwickeln oder kräftig modifizieren, und im Rahmen dessen auch\nnotwendige Anpassungen anderer IT-Systeme gleich mit erledigen (siehe\nAbbildung 2.6).

\n\n

Wie Sie an der Abbildung 2.6 erkennen müssen Sie sowohl die\nSchnittstellen des neuen (oder zu modifizierenden) Systems zu den\nBenutzern und zu IT-System 2 festlegen, als auch die Leistungen,\nFunktionalität und Schnittstellen innerhalb der IT-Systeme 1, 3 und 4 identifizieren, die angepasst werden müssen.

\n\n

Sollten Sie als Projektverantwortlicher keine Entscheidungsgewalt über die notwendigen Änderungen an den IT-Systemen 1, 3 und 4 haben, so ist Ihr Projekterfolg vom guten Willen dieser drei Nachbarsysteme abhängig: Sie brauchen dort Änderungen, dürfen die aber nicht selbst ausführen oder anordnen, sondern müssen mit den Verantwortlichen dieser Systeme verhandeln.

\n\n

Nutzen Sie in einer für die Scopefestlegung Ihres Projektes eine visuelle Gesamtübersicht („Kontextdiagramm“) des neuen oder zu modifizierenden Systems, zusammen mit den Nachbarsystemen 1 bis 4. \nWir mögen dazu Komponentendiagramme mit einer kurzen (tabellarischen) Erklärung der Funktionalitäten und Schnittstellen. Das erleichtert die Diskussion über alle notwendigen Änderungen und Anpassungen.

\n\n\n

\"Abb. — Abb. 2.6: Projektscope vs. Produktscope

\n\n\n

\nNotationen für Scope und Kontext

\n\n

Requirements-Analysten können Schnittstellen einfach vorgeben – in der Entwicklung bereiten diese den Entwicklungsteams möglicherweise viel Aufwand und beinhalten hohe Risiken.

\n\n

Zur Festlegung der Grenze zwischen Scope und Kontext reicht anfangs die Betrachtung der ein- und ausgehenden Daten Ihres Systems. Die klassische Darstellungsweise dafür ist ein sogenanntes „fachliches\nKontextdiagramm“, [Hruschka-19], wie Sie es als Beispiel für einen Bordcomputer eines PKWs in Abbildung 2.7 sehen. Das System soll den Fahrer mit typischen Informationen wie Durchschnittsgeschwindigkeit, Treibstoffverbrauch, Außentem-peratur, etc. versorgen, wie auch Navigation ermöglichen, einen Tempomaten zur Verfügung stellen, Wartungsintervalle überwachen und den Fahrer über Radiosender und Telefonanrufe informieren.

\n\n

Sie sollten in einem Kontextdiagramm ALLE Nachbarsysteme identifizieren\nund für jedes davon die Ein- und Ausgaben benennen. Eine Aufzählung von\nFunktionen (oder Features und Epics) genügt meist nicht, um den Scope\ndes Produktes festzulegen!

\n\n\n

\"Abb. — Abb. 2.7: Kontextdiagramm mit Ein- und Ausgaben des Systems

\n\n\n

Falls Sie übrigens Diagramme nicht mögen, so schlägt [Hruschka-19]\neine ganze Menge an alternativen Notationen dafür vor, im einfachsten\nFall eine Tabellenmit allen Nachbarsystemen und deren Schnittstellen.

\n\n

Wichtig ist, dass Sie

\n\n

Ihr System klar identifiziert haben,
alle Nachbarn kennen und
die komplette Ein- und Ausgabe auf fachlicher Ebene verstanden haben.

\n\n

\nEntwicklung braucht (Schnittstellen-)Details

\n\n

Als Ergebnis einer Anforderungsanalyse genügt es, Ein- und Ausgaben von\nund zu den Nachbarn zu erkennen. Diese Schnittstellen explizit\nidentifiziert zu haben, bedeutet mehr als die halbe Miete.

\n\n

Bei Entwurf und Entwicklung des Systems müssen Sie bei jeder dieser\nexternen Schnittstellen alle notwendigen Details entweder hinterfragen\noder entscheiden. [Starke&Hruschka-16] gibt dazu viele pragmatische\nHinweise. Sie müssen z.B. festlegen, wer der aktive Partner ist (Push\noder Pull), wie die Handshakes oder Protokolle aussehen, die an der\nSchnittstelle einzuhalten sind, welche zeitlichen, technischen oder\norganisatorischen Randbedingungen einzuhalten sind, etc.

\n\n

Im arc42-Termplate [arc42] haben wir Abschnitt 3 („Kontextabgrenzung“)\nfür diese wichtigen Informationen vorgesehen. Abschnitt 3.1 enthält das\nfachliche Kontextdiagramm. Falls nötig können Sie in Abschnitt 3.2. noch\ndas technische Kontextdiagramm aufnehmen, das die technischen Kanäle\nzeigt, über die fachliche Informationen fließen. Im obigen Beispiel\nwürde man für das Fahrerinterface vielleicht sowohl Spracheingabe wie\nauch Tastatureingabe technisch zulassen. Viele der anderen\nSchnittstellen laufen vielleicht über den CAN-Bus. arc42-Abschnitt 3.2\nenthält dann auch ein Mapping, welcher fachliche Input/Output über\nwelchen technischen Kanal läuft.

\n\n

Alternativ können Sie Details von Schnittstellen auch als technische\noder querschnittliche Konzepte in Abschnitt 8 des Templates beschreiben\n– falls Sie beispielsweise viele Schnittstellen nach demselben Schema\nbehandeln möchten.

\n\n

Falls Sie auf die grafische Variante stehen: Die UML bietet Ihnen viele\nMöglichkeiten, Schnittstellen genauer festzulegen. Abbildung 2.8 zeigt\nzu obigem Beispiel jetzt die Verwendung von Ball- und Socket-Notation,\nbzw. die Einführung von Ports.

\n\n

Wir Autoren vertreten diesbezüglich unterschiedliche Meinungen: Peter\nmag UML, Gernot eher die text- oder tabellenorientierte Beschreibung von\nSchnittstellen. Beides funktioniert.

\n\n\n

\"Abb. — Abb. 2.8: Notation für Schnittstellendetails

\n\n\n

Abbildung 2.8 zeigt noch eine Empfehlung: Wenn ein Produkt viele\nSchnittstellen aufweist, könnten Sie diese als Analyseergebnis bündeln.\nAbbildung 2.8 zeigt nur zwei Sensoren (Temp- und Durchfluss). Stellen\nSie sich aber vor, dass Sie mehrere Dutzend Sensoren als Schnittstellen\nhaben. Dann lohnt es sich, anfänglich in der Analyse nur über ein\nSensorinterface zu sprechen (dargestellt als Sensor-Port) und das erst\nin Laufe der Entwicklung detailliert aufzuspalten. Als weiteres\nBeispiel. Nehmen Sie im Telekommunikationsbereich die Schnittstellen zu\nRoaming Partnern. Das sind vielleicht einige Hunderte, die teilweise\nganz unterschiedliche Protokolle nutzen oder unterschiedliche Formate\nliefern. Trotzdem kann man sie anfangs zu einem\n„Roaming-Partner-Interface“ zusammenfassen. Wie gesagt: Schnittstelle\nerkannt, Gefahr halbwegs gebannt.

\n\n

Damit sind Sie in den weitaus meisten Fällen mit Scope und Kontext\nfertig. Ein i-Tüpfelchen aber hätten wir noch für Sie.

\n\n

\nBusiness- und Produktscope

\n\n

Gründliche Requirements-Engineers unterscheiden zwischen\nBusiness-Scope und Produktscope: Der Business-Scope ist der Bereich\nIhres Unternehmens oder Organisation, in dem Sie im Zuge Ihrer Software-\noder Systementwicklung Entscheidungen treffen oder vorschlagen dürfen,\nalso beispielsweise Ihr Fachbereich oder Ihre Abteilung. Normalerweise\nist der Business-Scope um einiges größer als der Produktscope, weil Sie\nvielleicht nicht alles, was in Ihren Entscheidungsbereich fällt, auch\nautomatisieren wollen. Sie können also in Zusammenarbeit von Analytikern\nund Architekten festlegen, welche Teile von Geschäftsprozessen\nautomatisiert und welche Schritte vielleicht noch längere Zeit\nmanuell durchgeführt werden sollen.

\n\n\n

\"Abb. — Abb. 2.9: Business- und Produktscope

\n\n\n

Abbildung 2.9 zeigt eine solche Situation. „User 1“ und „User 2a“, sowie\n„IT-System 1“ befinden sich außerhalb Ihres Business-Scopes. Dort haben\nSie keinen direkten Einfluss. „User 2b“ und „User 3“, sowie „IT-System\n2“ gehören in Ihren Business-Scope. Daher sollte es relativ leicht sein,\ndiese bei der Neuentwicklung eines Produktes zu berücksichtigen.\n„IT-System n“ gehört Ihnen nicht alleine, sondern es sind auch andere\nVerantwortliche im Business-Kontext mit im Spiel.

\n\n

Für „User 2a“ können Sie zum Beispiel entscheiden, dass Anfragen\nzunächst an „User 2b“ in Ihrer Abteilung gehen und dieser mit dem neuen\nProdukt diesen Request erfüllt. Später erhält „User 2a“ vielleicht\ndirekter Zugriff zu dem neuen System.

\n\n

Unsere Empfehlung ist es, in der Anforderungsanalyse die Scheuklappen\ngrundsätzlich etwas weiter aufzumachen und an die Schnittstellen Ihres\nBusiness zu denken, statt an die möglicherweise eingeschränkten\nSchnittstellen eines Produktes.

\n\n

Sie sehen schon: Scope und Kontextabgrenzung sind in vielen Fällen nicht\ntrivial. Und wenn Sie diesen Input nicht von Requirements-Engineering\noder Business-Analysts bekommen, dann ist das ein ganz wichtiger, früher\nSchritt bei Ihrer Architekturarbeit.

\n\n

\nEmpfehlungen

\n\n

Nehmen Sie die Festlegung von Scope und Kontext ernst. Im\nEntwicklungsteam müssen Sie manchmal „nacharbeiten“, weil die\nAnforderungsanalyse oder Ihre Product-Owner Sie diesbezüglich im Stich\ngelassen haben.

\n\n

Nutzen Sie bereits frühzeitig in Ihrem Projekt oder Vorhaben ein\nKontextdiagramm als Kommunikationshilfsmittel, um Feedback Ihrer\nStakeholder über die wichtigen Außenschnittstellen ihres Systems\neinzuholen – lange bevor Sie interne Entscheidungen treffen. Legen Sie\nbesonderes Augenmerk auf volatile oder kritische Schnittstellen, die\nsich oft und ohne ihr Zutun ändern können.

\n\n

\nWeiterer Input

\n\n

Mit den Klärungen von Zielen, Stakeholdern und Scope haben Sie die\nwichtigsten Voraussetzungen für einen Clean Start erfüllt. Schön wäre es\nauch, wenn Sie einen groben Überblick über die gewünschte Funktionalität\nerhalten würden (z.B. in Form von Epics oder Feature-Listen), wenn man\nIhnen die allerwichtigsten Qualitätsziele für das Produkt verrät (z.B.\ndie Top 3 Qualitätsanforderungen). Sicherlich sollten Sie auch über die\nwichtigsten Randbedingungen klargestellt werden. Das T-Stich-Modelle in\nAbbildung 2.10 fasst das grafisch zusammen. Wenn der Aufwand für die\nkomplette Klärung der Requirements 5% beträgt, dann reichen am Anfang 1\n– 2 % davon aus, um volle Breite vor Tiefe zu eruieren. Parallel zu\ndieser Arbeit der Analytiker können Sie als Architekt(in) ja schon\nwichtige Eckpfeiler der Architektur festlegen (möglichst mit Ihrem Team\nzusammen) und auch schon erste Prototypen oder Minimal Viable Products\n(MVPs) implementieren. Ausgestattet mit dem Wissen bohren Sie dann\niterativ da in die Tiefe, wo es sich am ehesten lohnt.

\n\n\n

\"Abb. — Abb. 2.10: Das T-Modell mit den wichtigsten Artefakten

\n\n\n

\nBleiben Sie dran

\n\n

Lassen Sie uns zusammenfassend unsere Empfehlung wiederholen: Bringen\nSie Ihrem Management, den Product Ownern oder Business Analysts bei,\ndass sowohl Ziele, Scope und Stakeholder auf jeden Fall in deren\nAufgabenbereich fallen. Vielleicht können diese Stakeholder Ihnen\nzusätzlich noch einen groben Überblick über die gewünschte\nFunktionalität des Systems, die dringendsten Erwartungshaltungen\nbezüglich Qualität sowie die härtesten Randbedingungen liefern. Dann\nhaben Sie in Ihrer Rolle als Architekten einen entspannten\nArbeitsbeginn. In diesem Sinne: Keep educating your product owners and business analysts!

\n\n

\nLernziele

\n\n

Der [Req4Arc] Lehrplan sieht zu diesem Themenbereich folgende Lernziele vor:

\n\n

LZ 2-1: Verstehen der Notwendigkeit einiger (begrenzter) Vorleistungen

\n\n

Verstehen, dass selbst bei iterativer Entwicklung einige\nVorleistungen erforderlich sind.
Wissen, dass explizite Kenntnisse über Visionen, Ziele und relevante\nStakeholder erforderlich sind, damit das Entwicklungsteam fundierte\nEntscheidungen über die Systemarchitektur treffen kann.
Verstehen, dass eine Vereinbarung über Umfang und Kontext\nerforderlich ist, insbesondere über die Schnittstellen zwischen\nUmfang und Kontext (d.h. die externen Schnittstellen des Produkts).

\n\n

LZ 2-2: Verständnis für die Notwendigkeit von (high-level) Visionen und Geschäftszielen

\n\n

Verstehen, dass Visionen oder Geschäftsziele Ihre höchsten\nAnforderungen sind, d.h. die Anforderungen, die (hoffentlich)\nwährend eines Projekts nicht geändert werden.
Verstehen, dass Visionen und Ziele quantifiziert und messbar gemacht\nwerden sollten, um den Erfolg in Bezug auf den Geschäftswert\nüberprüfen zu können.

\n\n

LZ 2-3: Verschiedene Möglichkeiten und Notationen, um Visionen und

Unternehmensziele auszudrücken

\n\n

verschiedene Möglichkeiten kennen, um Vision und Ziele zu definieren\n(explizite Zielerklärungen, Wertversprechen für verschiedene\nStakeholder, Visionsfeld, “Neuigkeiten aus der Zukunft”)
Mnemotechnik für Visionen oder Geschäftszielsetzungen kennen (SMART,\nPAM)

\n\n

LZ 2-4: Die Bedeutung der verschiedenen Stakeholder und ihr Einfluss auf das Produkt oder System

\n\n

Wissen, dass die Stakeholder die wichtigsten Quellen für\nAnforderungen sind.
Verstehen, dass fehlende Stakeholder fehlende Anforderungen bedeuten\nkönnen.
Verstehen, dass Architekten sich bewusst sein sollten, dass die\nStakeholder auf spezifische, angemessene Weise angesprochen werden\nmüssen.

\n\n

LZ 2-5: Unterschiedliche Bedürfnisse und Werte der verschiedenen Stakeholder (“Value Propositions”)

\n\n

Verstehen, dass verschiedene Interessengruppen unterschiedliche\nBedürfnisse haben und unterschiedliche Meinungen darüber haben\nkönnen, was an einem Produkt wertvoll ist.
Wissen, dass eine priorisierte Stakeholderliste hilft, Anforderungen\nnach Geschäftswert zu priorisieren
Wissen, dass Architekten mit Zielkonflikten zwischen den\nBedürfnissen der Stakeholder umgehen müssen

\n\n

LZ 2-6: Umfang und Abgrenzung vom Systemkontext

\n\n

Unterscheidung zwischen Geschäfts- und Produktumfang kennen
Wissen über die Bedeutung externer Schnittstellen
Unterscheiden zwischen verschiedenen Ebenen der Externalität (extern\nzum System, extern zur Geschäftseinheit, extern zum Unternehmen)
verschiedene Möglichkeiten und Notationen kennen, um Umfang und\nKontext auszudrücken, z.B. Kontextdiagramme

\n\n\n

\n3. Bis hierhin…

\n\n

… reicht unser kleiner Auszug. Auf den folgenden Seiten finden Sie noch unser Glossar sowie die Literatur- und Quellenangaben.

\n\n

Im gesamten Buch folgen an dieser Stelle noch einige spannende und hilfreiche Kapitel:

\n\n

Umgang mit funktionalen Anforderungen
Qualitätsanforderungen
Behavior-Driven Development (BDD)
Priorisierung von Anforderungen
Vorgehen
Werkzeuge
Ausblick

\n\n\n\n

\nGlossar

\n\n

Affinitätsschätzung

Schätztechnik agiler Teams, um schnell eine große Anzahl von\nAnforderungen (etwa: User Stories) zu schätzen. Dabei ordnet das Team\ndie Stories in aufsteigender Reihenfolge auf einer horizontalen Skala\nan.

Agile Requirements Engineering

(adaptiert vom IREB): ein kooperativer, iterativer und inkrementeller\nAnsatz mit vier Zielen:\n

Kenntnis der relevanten Anforderungen auf einem angemessenen Detaillierungsgrad (zu jedem Zeitpunkt der Systementwicklung),
Erzielung einer ausreichenden Übereinstimmung der relevanten Stakeholder über die Anforderungen,
Erfassung (und Dokumentation) der Anforderungen entsprechend den Vorschriften der Organisation,
Durchführung aller anforderungsbezogenen Aktivitäten nach den Prinzipien des agilen Manifests.

Aktivitätsdiagramm

Ein Ausdrucksmittel der UML (Unified Modeling Language) zur grafischen\nDarstellung von Prozessschritten. Im Gegensatz zu →Datenflussdiagrammen\nkonzentrieren sich Aktivitätsdiagramme auf die Ablaufreihenfolge von\nSchritten.

Akzeptanzkriterien

(adaptiert vom IREB): Eine Reihe von Bedingungen (typischerweise mit\neiner Anforderung verbunden), die von jeder Implementierung erfüllt\nwerden müssen. Solche Bedingungen können z.B. die erwarteten Ergebnisse\nfür die Eingangsdaten der Stichprobe oder die erwartete Geschwindigkeit\noder das zu erreichende Volumen sein.

ASR (Architecturally Significant Requirements)

Architekturrelevante Anforderungen sind die Teilmenge der Anforderungen,\ndie einen starken Einfluss auf architektonische Entscheidungen haben\n(jene Anforderungen, die insbesondere architektonische Entscheidungen\nprägen oder beeinflussen).\n

ATDD

Acceptance Test Driven Development

BDD

(Behavior Driven Development) Ein agiler Software-entwicklungsprozess,\nder die Zusammenarbeit zwischen Entwicklern, der Qualitätssicherung und\nnicht-technischen oder geschäftlichen Teilnehmern eines Softwareprojekts\nfördert. Er ermutigt Teams, Gespräche und konkrete Beispiele zu nutzen,\num ein gemeinsames Verständnis darüber zu formalisieren, wie sich die\nAnwendung verhalten sollte, was zu ausführbaren Spezifikationen führt,\nz.B. in der Syntax von → Gherkin.

Bounded Context

In Domain Driven Design (DDD) ein Begriff für einen inhaltlich stark\nzusammenhängenden Bereich des Systems, der wenig Schnittstellen zu\nanderen solchen Bereichen aufweist und daher relativ unabhängig von den\nanderen implementiert werden kann.

BPMN (Business Process Model & Notation)

Ein von der OMG (Object Management Group) standardisierte Notation zur\nBeschreibung von Geschäftsprozessen.

Cost-of-Delay (Kosten der Verzögerung)

Eine Schätzgröße, die ausdrückt, wie viel Wert verloren geht, wenn ein\nProdukt zu spät geliefert wird. Anders ausgedrückt: Was könnten wir\neinnehmen, wenn das Produkt früher am Markt wäre.

Datenflussdiagramm

Ein Ausdrucksmittel aus der Strukturierten Analyse zur grafischen\nDarstellung von Prozessabläufen. Im Gegensatz zu →Aktivitätsdiagrammen\nkonzentrieren sich Datenflussdiagramme auf die Ein- und Ausgaben der\neinzelnen Prozessschritte, den Fluss der Daten.

Definition of Ready

(DoR) (adaptiert vom IREB): eine Reihe von Kriterien, die eine\nAnforderung erfüllen muss, bevor sie in einer kommende n Iteration\nimplementiert werden.

Domain-Driven Design (DDD)

Eine Methode zur Modellierung komplexer Systeme, die sich maßgeblich auf\ndie umzusetzende Fachlichkeiten der Anwendungsdomäne stützt.

Epic

(adaptiert vom IREB): Eine abstrakte Beschreibung eines\nStakeholderbedarfs, der in dem zu entwickelnden Produkt berücksichtigt\nwerden muss. Epics sind typischerweise größer als das, was in einer\neinzigen Iteration umgesetzt werden kann.

Feature

Die Spezifikation eines Service, das einen Wunsch oder Bedarf eines\nStakeholders erfüllt. Jedes Feature sollte eine Aussage über den Nutzen\nfür den Stakeholder, sowie ein Akzeptanzkriterien enthalten.

Fibonacci-Schätzung

→Planning-Poker verwendet (leicht modifizierte) Fibonacci-Zahlen (0, ½,\n1, 2, 3, 5, 8, 13, 20, 40, 100) zur relativen Schätzung der\nSchwierigkeit von Anforderungen. Bedeutung: 0: Aufgabe bereits erledigt,\n100: hoch komplexe Aufgabe, noch keine genauere Schätzung möglich. ½:\nsehr kleine Aufgabe, 1-5: eher kleinere, 8 und 13 mittlere Aufgaben. 13\noft für Aufgaben, die noch in einen einzigen Sprint passen. 20 und 40:\nzu umfangreich, brauchen noch Detaillierung der Anforderungen.

Funktionale Anforderung

Eine Anforderung bezüglich eines Ergebnisses, das durch eine Funktion\ndes Systems (oder einer Komponente oder eines Dienstes) bereitgestellt\nwerden soll.

Geschäftsziel (Business Goal)

Ein gewünschter Zustand (den ein Stakeholder erreichen möchte).\nGeschäftsziele beschreiben Absichten von Stakeholdern. Sie können\nzueinander in Konflikt stehen.

Gherkin

Eine domänenspezifische Sprache zum Schreiben von →BDD Szenarien in →GWT-Syntax.

GWT-Syntax

\nGiven, When, Then: Eine halbformale Notation zum Schreiben von\nTestfällen oder Verhaltensspezifikationen. Erfunden von Dan North als\nTeil von →BDD (behavior-driven development).

INVEST

Ein Akronym für die Eigenschaften eine guten →(User) Story. Sie sollte\nunabhängig (I = independent), verhandelbar (N = negotiable), wertvoll (V\n= valuable), schätzbar (E = estimable), klein genug für die Umsetzung in\neinem Sprint (S = small) und testbar (T = testable) sein.

IREB

International Requirements Engineering Board. Siehe https://ireb.org\n

iSAQB

International Software Architecture Qualification Board. Siehe\nhttps://isaqb.org\n

MoSCoW-Priorisierung

Ein Akronym für vier Prioritätsstufen von Anforderungen: Must have,\nShould have, Could have, Won’t Have. Die “o” sind nur Füllbuchstaben, um\ndas Wort aussprechbar zu machen.

Nichtfunktionale Anforderung (NFA)

Ein Sammelbegriff für eine → Qualitätsanforderungen oder eine →\nRandbedingung.

PAM

Ein Akronym für Purpose, Advantage, Metric, das dabei hilft, sich auf\ndiese drei wichtigen Aspekte beim Formulieren von Geschäftszielen oder\nVisionen zu konzentrieren.

Planning Poker

Ein agiles Schätzverfahren, mit dem Mitglieder des\nSoftware-Entwicklungsteam die Größe von vorgestellten Epics, Features\noder Stories schätzt. Vgl. → Wall-Estimation zur Beschleunigung der\nSchätzungen.

Product Owner

In Scrum die Rolle, die im Rahmen einer Produktentwicklung für die\nErhebung, Verwaltung, Verfeinerung und Priorisierung von Anforderungen\nzuständig ist. Der Product Owner prüft auch am Ende einer Iteration die\nErreichung der Anforderungen.

Qualitätsanforderung (Quality Requirement)

(nach IREB) Eine Anforderung, die sich auf eine Qualitätseigenschaft\nbezieht, die nicht durch funktionale Anforderungen abgedeckt ist.

Randbedingung (Constraint)

Eine Anforderung, die den Lösungsraum mehr einschränkt als es für die\nErreichung von funktionalen Anforderungen oder Qualitätsanforderungen\nnötig wäre.

Scenario

Eine Beschreibung einer möglichen Folge von Ereignissen, die zu einem\ngewünschten (oder nicht gewünschten) Ergebnis führen.\\\nAlternativ: eine geordnete Folge von Interaktionen zwischen Partnern,\ninsbesondere zwischen einem System und externen Akteuren.

Scope

Diejenigen Dinge, die Sie bei der Entwicklung eines Systems formen,\ngestalten und entscheiden können.

\nSLA (Service Level Agreement)\n

Ein Rahmenvertrag zwischen Auftraggebern und Dienstleistern für\nwiederkehrende Dienstleistungen.

SMART

Ein Akronym (Specific, Measurable, Achievable, Realistic, and Timely), das Hilfestellung bei der Formulierung von Geschäftszielen gibt.

Stakeholders

Eine Person oder Organisation, die einen direkten oder indirekten\nEinfluss auf die Anforderungen und/oder die Entwicklung eines Systems\nhat. Indirekter Einfluss umfasst auch Situationen, in denen eine Person\noder Organisation durch das System beeinflusst wird.

Story Points

In agilen Schätzmethoden eine (fiktive) Einheit zur Beschreibung der\nGröße einer User Story.

(User) Story

Eine Beschreibung eines Bedarfs aus der Sicht eines Benutzers zusammen\nmit dem erwarteten Nutzen, wenn dieser Bedarf erfüllt ist. User Stories\nwerden typischerweise in natürlicher Sprache geschrieben, oft unter\nVerwendung einer vorgegebenen Satzvorlage.

\nUse Case (deutsch: Anwendungsfall)

Eine Beschreibung der möglichen Interaktionen zwischen den Akteuren und\neinem System, die, wenn sie ausgeführt werden, einen Mehrwert bieten.\n

Use Cases spezifizieren ein System aus der Perspektive eines Benutzers (oder eines anderen externen Akteurs): Jeder Use Case beschreibt einige Funktionen, die das System für die am Use Case beteiligten Akteure bereitstellen muss.

Vision

Die Vision ist eine Beschreibung des gewünschten zukünftigen Zustands.\nSie spiegelt die Bedürfnisse wesentlicher Stakeholder wider, sowie die\nFunktionen, die zur Erfüllung dieser Bedürfnisse notwendig sind.

Wall Estimation

Im Gegensatz zu → Planning Poker ein beschleunigtes Schätzverfahren, bei dem eine Skala von Größenordnungen (z.B. Fibonacci, T-Shirt-Sizes) an\ndie Wand gehängt wird und das Team rasch alle Epics oder Stories in den\nentsprechenden Spalten darunter anordnet statt jeweils einzelne\nBacklog-Items zu schätzen.

WSJF (Weighted Shortest Job First)

Vorschlag zur Priorisierung von Anforderungen aus dem SAFE Framework: Gewichteter kürzester Job zuerst. \nDie Gewichtung berechnet sich aus →Cost of Delay.

\n\n\n

\nLiteratur

\n\n

Adzic-11: Goyko Adzic: Specification by Example. Manning, 2011. Mehr Infos:\nhttps://gojko.net/books/specification-by-example/

\n\n

Adzic-12: Gojko Adzic, Impact Mapping.\nhttps://www.impactmapping.org/

\n\n

Adzic-14: Goyko Adzic: 50 Quick Ideas to Improve Your User Stories.

\n\n

arc42: Das freie Portal für Softwarearchitktur: https://arc42.de und https://arc42.org

\n\n

arc42-Quality: Frei verfügbare Beispiele für Qualitätsanforderungen:\nhttps://github.com/arc42/quality-requirements/

\n\n

ATAM: Rick Kazman: ATAM Method for Architecture Evaluation, (Architecture Tradeoff Analysis Method), \nSEI Technical Report, https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5177

\n\n

Banfield-16: Richart Banfield: Design sprint: a practical guidebook\nfor building great digital products, O’Reilly, 2016

\n\n

Brandolini: Alberto Brandolini: Event Storming.\nhttps://leanpub.com/introducing_eventstorming. Schöne Darstellung der\ninteraktiven Workshops zum besseren Verstehen komplexer Domänen.

\n\n

Clegg-94: Dai Clegg and Richard Barker (1994). Case Method Fast-Track: A RAD Approach. Addison-Wesley.

\n\n

Cohn-04: Mike Cohn: User Stories Applied, Addison Wesley, 2004

\n\n

Crunch: Knowledge Crunching, erklärt in Eric Evans: Domain-Driven\nDesign – Tackling Complexity in the Heart of Software. Addison-Wesley,\n2003.

\n\n

Cucumber: Das vermutlich am weitesten verbreitete Toolset für BDD. \nImplementierungen für viele Programmiersprachen verfügbar.\nhttps://cucumber.io/

\n\n

DeMarco-07: Tom DeMarco, et. al: Adrenalin Junkies und Formular\nZombies, Pattern 78, Hanser-Verlag, 2007

\n\n

DomainStories: Domain Storytelling: http://www.domainstorytelling.org/

\n\n

Evans: Eric Evans: DDD Referenz. Überblick über alle DDD-Praktiken\nund Patterns;. Online: https://ddd-referenz.de/, inclusive Links zu\nPrint-Versionen.

\n\n

Gerstbach-16: Ingrid Gerstbach: Design Thinking im Unternehmen: Ein\nWorkbook für die Einführung von Design Thinking, GABAL Verlag, 2016

\n\n

Gherkin: Die Sprache Gherkin definiert die Syntax, in der wir\nFeatures in (fast) ausführbare Szenarien herunterbrechen können. Eine\nEinführung finden Sie unter https://cucumber.io/docs/gherkin/

\n\n

Gottesdiener-12: Ellen Gottesdiener: Discover to Deliver: Agile Product Planning and Analysis, EGB Consulting, 2012

\n\n

Hathaway-19: Angela + Tom Hathaway: Getting and Writing IT-Requirements in a Lean and Agile World.\nSelf-published, https://leanpub.com/lean-requirements-user-stories-agile

\n\n

Hofer: Stefan Hofer und Henning Schwentner: Domain Storytelling \nonline auf jax.de

\n\n

Hruschka-19: Peter Hruschka: Business Analysis und Requirements\nEngineering, 2. Auflage, Hanser Verlag

\n\n

Hruschka+Starke-18: Peter Hruschka und Gernot Starke: Knigge für\nSoftwarearchitekten, 3. überarbeitete und ergänzte Auflage,\nentwickler.press, 2018. Kurzfassungen finden Sie online unter\nhttps://softwareknigge.de

\n\n

IREB: International Requirements Engineering Board: Handbook Advanced Module “RE@Agile”,\nonline: https://www.ireb.org/de/downloads/tag:advanced-level-re-agile

\n\n

iSAQB-Foundation Level: Curriculum: https://isaqb-org.github.io/curriculum-foundation/

\n\n

ISO-25010: Standard for Systems and software Quality\nRequirements and Evaluation (SQuaRE), definiert ein generisches Modell für Software(produkt)qualität. \nhttps://www.iso.org/standard/35733.html

\n\n

ISO-26262: Standard für functional safety for road vehicles. \nhttps://en.wikipedia.org/wiki/ISO_26262

\n\n

ISO-27001: ISO Standard zu Informationssicherheit,\nhttps://en.wikipedia.org/wiki/ISO/IEC_27001

\n\n

Jacobson-11: Ivar Jacobson, Ian Spence, Kurt Bittner: Use-Case 2.0: The Guide to Succeeding with Use-Cases.\nOnline: https://www.ivarjacobson.com/publications/white-papers/use-case-ebook

\n\n

JBehave: JBehave – ein Framework für Behaviour-Driven Development:\nhttps://jbehave.org/.

\n\n

Lawrence: Richard Lawrence: How to split a story, https://agileforall.com/resources/how-to-split-a-story

\n\n

McGreal: Don McGreal, Ralph Jocham: The Professional Product Owner: Leveraging\nScrum as a Competitive Advantage. Addison-Wesley, 2018

\n\n

McMenamin-84: Stephen McMenamin, John Palmer: Structured Design. Yourdon-Press\n1984. Uralt. Immer noch gut, um “Fachlichkeit” sinnvoll zu\nstrukturieren. Nimmt viele Aspekte vorweg, die in der DDD-Community als “Event-Storming” propagiert werden.

\n\n

Millet-17: Scott Millet: The Anatomy of Domain-Driven Design.\nLeanpub, 2017. Grafisch großartig aufgemacht, leider sehr abstrakt und (wie leider die meisten DDD-Bücher ohne durchgängiges Beispiel).

\n\n

North: Dan North: Introducing Behavior Driven\nDevelopment, https://dannorth.net/introducting.bdd

\n\n

Patton-15: Jeff Patton: User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly, 2015

\n\n

Pichler-10: Roman Pichler: Agile Product Management with Scrum:\nCreating Products that Customers Love. Addison-Wesley, 2010

\n\n

Plöd: Michael Plöd: Hands-On Domain-Driven Design by Example.\nhttp://leanpub.com/ddd-by-example. Endlich mal ein DDD-Buch mit\ndurchgängigem Beispiel.

\n\n

Poppendieck-03: Mary und Tom Poppendieck: Lean Software Development: An Agile\nToolkit. Addison-Wesley Professional, 2003.\nOnline

\n\n

Ries-11: Eric Ries: The Lean Startup, Crown Business, 2011

\n\n

Req4Arc: Lehrplan des iSAQB zum Advanced Modul REQ4ARC, \nonline

\n\n

Req42: Das Portal für agiles Requirements Management https://req42.de.

\n\n

Robertson-12: Suzanne und James Robertson: Mastering the Requirements\nProcess: Getting Requirements Right. Addison Wesley; 3rd edition\n2012. Online

\n\n

Robertson-19: Suzanne und James Robertson: Business Analysis Agility. Addison Wesley, 2019

\n\n

SEI: Das Software-Engineering Institute gehört zur Carnegie-Mellon University in USA. \nQualitätsszenarien finden sich u.a. in „Software Architecture in Practice” von Len Bass et al, oder auch in diversen\nTechnical Reports

\n\n

Serenity: Serenity BDD, „automatisierte Akzeptanztests mit Stil“: integriert die Idee von Living-Documentation mit BDD. \nOnline und\nbei thucydides. \nDie von Serenity generierte Dokumentation finden wir super-hilfreich.

\n\n

Smart-14: John Smart: BDD in Action, Behavior-Driven Development for\nthe whole software lifecycle. Manning 2014.\nSiehe https://www.manning.com/books/bdd-in-action

\n\n

Smart-Amigo: John Smart: The Anatomy of a Three Amigo requirements discovery Session. \nSiehe https://johnfergusonsmart.com/three-amigos-requirements-discovery/

\n\n

Spockframework: Spockframework gehört zu unseren persönlichen Favoriten der BDD-Frameworks:\n– Open-Source, auf Basis Groovy: Riesiges Lob und Danke an seinen\nSchöpfer Peter Niederwieser. Damit macht Spezifikationen schreiben\nwirklich Spaß! http://spockframework.org

\n\n

Stakeholder: arc42 gibt einige Tipps zum Umgang mit Stakeholdern in der (technischen) Dokumentation:\nhttps://docs.arc42.org/keywords/#stakeholder

\n\n

Starke-Hruschka-16: Gernot Starke und Peter Hruschka: arc42 in Aktion - Praktische Tipps zur Architekturdokumentation, Hanser 2016. Viele Tipps auch online unter https://docs.arc42.org

\n\n

Starke-Hruschka: Gernot Starke und Peter Hruschka: Communicating Software Architectures: lean, effective and painless documentation.\nLeanpub https://leanpub.com/arc42inpractice

\n\n

Starke-Hruschka-17: Gernot Starke und Peter Hruschka: Der Flexibilisator,\nhttps://jaxenter.de/flexibilisator-51170

\n\n

TDD-BDD: Seb Rose: Introduction to TDD and BDD.\nhttps://cucumber.io/blog/intro-to-bdd-and-tdd/

\n\n

Toth-19: Stefan Toth: Vorgehensmuster in der Softwarearchitektur.\nCarl Hanser Verlag, 3.te Auflage 2019. Geht besonders auf \n“Architekturrelevante Anforderungen” ein.

\n\n

UL: Ubiquitous Language in der DDD-Referenz:\nhttps://leanpub.com/ddd-referenz/read#ubiquitous-language

\n\n

VOLERE: Umfangreiches und ausgereiftes Template für Anforderungen, http://www.volere.co.uk

\n\n

Wake-03: Wake, Bill: INVEST in good stories and SMART Tasks,\nhttp://xp123.com/Articles/invest-in-good-stories-and-smart-tasks, 2003

\n\n

Wlaschin-18: Scott Wlaschin: Domain Modeling Made Functional - Tackle\nSoftware Complexity with Domain-Driven Design and F#. Pragmatic\nProgrammers, 2018. Auf den ersten 50 Seiten dieses Buches stellt Scott\ndie Grundlagen von DDD vor, so kompakt und verständlich wie aus unserer\nSicht sonst bisher keines der (vielen) DDD Bücher. Auch ohne F#\nAmbitionen oder Erfahrungen sehr lesenswert!

\n\n

Why-the-name: Die (nette) Geschichte, warum Cucumber so heisst wie ein Gemüse.

\n\n

Wynn: Matt Wynn: Introducing Example\nMapping: Online

\n\n

Yatspec: YatSpec – ein (moderneres) Framework für BDD, das sich gut\nin eine JUnit Infrastruktur einfügt: https://github.com/bodar/yatspec

\n\n\n

\nÜber uns

\n\n

\nPeter (links) und Gernot (rechts)

\n\n\n

\n\n\n

Gründer und Maintainer/Committer von arc42², dem freien Portal für Softwarearchitektur, -dokumentation und -entwurf. Mitgründer und aktive Mitglieder des International Software Architecture Qualification Board (iSAQB).

\n\n

Gernot wirkt dort in den Arbeitsgruppen „Foundation Level” und “Advanced Level“, \nPeter engagiert sich für Zertifizierungen im Foundation Level.

\n\n

Wir haben mehrere Bücher gemeinsam geschrieben: „arc42 in Aktion“ (Hanser Verlag), „Software-Architektur kompakt“ (Spektrum Verlag), „Knigge für Softwarearchitekten“ (Entwickler Press), “Zertifizierung für Softwarearchitekten” (Entwickler Press) sowie eine Reihe von eBooks.

\n\n

\nDr. Peter Hruschka

\n\n

Informatikstudium an der TU Wien, Promotion über\nEchtzeit-Programmiersprachen.

\n\n

18 Jahre im Rahmen eines großen deutschen Software-Hauses verantwortlich\nfür Software Engineering. Initiator, Programmierer und weltweiter\nPrediger und Vermarkter eines der ersten Modellierungstools.

\n\n

Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten\nSoftware-/System-Architekturen, Business Analysis und Requirements\nEngineering, oft im Umfeld technischer Systeme (Embedded Real-Time\nSystems). Peter ist Gründungs- und Boardmitglied des IREB (International\nRequirements Engineering Board).

\n\n

Gebürtiger Österreicher, aber seit 1976 Wahl-Aachener. In seiner kargen\nFreizeit Nordic-Walker, Kanute, Golfer und Keyboardspieler.

\n\n

Peter ist Fellow von Agile Experts (www.agile-experts.ch), mit denen er\ndas agile Requirements-Portal www.req42.de betreibt. Und er ist\nPrincipal der Atlantic Systems Guild (www.systemsguild.com) – trotz\nseiner moderaten Mitgliederanzahl seit mehr als 40 Jahren wegweisend in\nder Methodenentwicklung. Auf dieser Website finden Sie auch die vielen\nBücher, die Peter und die Gilde in den letzten 40 Jahren geschrieben\nhaben.

\n\n

\nDr. Gernot Starke

\n\n

INNOQ-Fellow. Informatikstudium an der RWTH Aachen, Promotion über\nSoftware-Engineering an der J. Kepler Universität Linz. Langjährige\nTätigkeit bei mehreren Software- und Beratungsunternehmen als\nSoftwareentwickler, -architekt, und technischer Projektleiter.

\n\n

1996 Mitgründer und technischer Direktor des „Object Reality Center“,\neiner Kooperation mit Sun Microsystems. Dort Entwickler und technischer\nLeiter des ersten offizielle Java-Projekts von Sun in Deutschland.\nGründer der Architecture Improvement Method (aim42), dem freien und\nsystematischen Ansatz zur Verbesserung bestehender Systeme.

\n\n

Gernot lebt mit seiner Traumfrau Cheffe Uli in Köln und verbringt\nseine Freizeit mit Kochen, Jogging, Fitness- oder Kraftausdauertraining\n(am liebsten unter Anleitung seiner Frau oder erwachsenen Kinder),\nBücher schreiben oder grillen.

\n\n

Einige Bücher aus seiner Feder:

\n\n

Gernot Starke: „Effektive Software-Architektur – Ein praktischer\nLeitfaden“. Carl Hanser Verlag,
Karl Eilebrecht und Gernot Starke: „Patterns kompakt.“ Spektrum\nAkademischer Verlag,
Gernot Starke, Michael Simons, Stefan Zörner, Ralf Müller: arc42 by\nExample, Leanpub, 2nd Edition 2019,\nhttps://leanpub.com/arc42byexample\n

\nAnmerkungen

1Diesen Lehrplan haben wir, in aller Bescheidenheit, maßgeblich mitgestaltet.↩

\n\n

2Siehe https://www.arc42.de und https://www.arc42.org;↩

\n\n\n

\n\n

\n\n","tocStructure",[175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194],{"_79":80,"_43":81,"_74":-5,"_82":83,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":89,"_74":-5,"_82":90,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":95,"_74":-5,"_82":96,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":98,"_74":-5,"_82":99,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":101,"_74":-5,"_82":102,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":80,"_43":104,"_74":-5,"_82":105,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":108,"_74":-5,"_82":109,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":111,"_74":-5,"_82":112,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":80,"_43":114,"_74":-5,"_82":115,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":118,"_74":-5,"_82":119,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":121,"_74":-5,"_82":122,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":124,"_74":-5,"_82":125,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":127,"_74":-5,"_82":128,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":130,"_74":-5,"_82":131,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":88,"_43":111,"_74":-5,"_82":133,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":80,"_43":135,"_74":-5,"_82":136,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":80,"_43":139,"_74":-5,"_82":140,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":80,"_43":143,"_74":-5,"_82":144,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":80,"_43":147,"_74":-5,"_82":148,"_75":84,"_91":-5,"_92":-5,"_93":-5},{"_79":80,"_43":151,"_74":-5,"_82":152,"_75":84,"_91":-5,"_92":-5,"_93":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]