IREB RE@Agile Primer

Mit agilen Methoden wird das Ziel verfolgt, dem Endbenutzer kontinuierlich betriebswirtschaftlichen Wert zu liefern. Betriebswirtschaftlicher Wert lässt sich in finanzieller Hinsicht, in einem höheren Marktanteil oder in Bezug auf die Kundenzufriedenheit direkt ausdrücken.

Die Anforderungen, welche den größten betriebswirtschaftlichen Wert versprechen, sollten „bereit für die Implementierung" sein (Definition of Ready). Andere, aus betriebswirtschaftlicher Perspektive weniger dringende Anforderungen werde erst dann verfeinert, wenn die dringenden Anforderungen abgeschlossen sind.

Gute Gründe dafür kennen, weshalb das Requirements Engineering Teil eines kontinuierlichen Prozesses sein sollte:

• Das Requirements Engineering in agilen Entwicklungsprozessen ist keine klar abgegrenzte Phase während der Entwicklung, sondern eine iterative und laufende Aktivität.
• Die Ermittlung und Analyse sämtlicher Anforderungen, bevor das Design und die Implementierung beginnen können, ist nicht das Ziel; Anforderungen und Produkte werden gleichermaßen iterativ und inkrementell erstellt.

Das Requirements Engineering ist daher eine fortlaufende Aktivität, die so lange dauert wie die gesamte Entwicklung des Produkts.

• Gleichwohl hat dieser Prozess gut definierte Zwischenergebnisse: die vorausgesagten Anforderungen, welche den grössten betriebswirtschaftlichen Wert versprechen, sollten „bereit für die Implementierung" sein (Definition of Ready).
• Andere, aus betriebswirtschaftlicher Perspektive weniger dringende Anforderungen werden erst dann verfeinert, wenn die dringenden Anforderungen abgeschlossen sind.

Der „kontinuierliche Prozess" schließt einige wichtige Vorabaktivitäten nicht aus. Selbst wenn für Anforderungen jeweils rechtzeitig auf Basis des Need-to-Know Prinzips geklärt werden, so gibt es einige Aspekte, die dennoch frühzeitig im Projektlebenszyklus behandelt werden müssen. Als Beispiele seien das Definieren von Visionen oder Zielen, das Kennen der Stakeholder und das Erarbeiten des Produktumfangs genannt. Beginnt man die Implementierung ohne diese Aktivitäten, so erhöht sich das Risikolevel erheblich.

Vergleicht man diese beiden Rollen, so zeigt sich, dass sowohl der Requirements Engineer als auch der Product Owner (gemeinsam mit allen Stakeholdern) die zentralen Aufgaben Ermitteln, Dokumentieren, Validieren und Managen von Anforderungen durchführen muss.

Die Notationen und Werkzeuge, die dabei zum Einsatz kommen, sind in agilen Entwicklungsprozessen jedoch in der Regel weniger formell:

• Story-Cards anstelle von Anforderungsdokumenten
• mehr Gespräche und weniger Schreibarbeit
• stärkere Betonung von aktuellen Statusanforderungen, weniger Betonung auf Versionierung und Verlauf

Es ist zwar wichtig, eine Gesamtverantwortung für Anforderungen von hoher Qualität kontinuierlich aufrechtzuerhalten, dabei ist die Rolle des Product Owners breiter gefächert als die eines herkömmlichen Requirements Engineers: Ein Product Owner ist für den Erfolg des Produkts insgesamt, das fortwährende Einholen von Feedback von den Stakeholdern sowie für das entsprechende Aktualisieren und Priorisieren des Backlogs verantwortlich.

Im «Product Backlog» werden die aufgeführten Items resp. Anforderungen gebündelt.

• Je nach Granularität werden die Anforderungen in «Epics», «Features» und «User-Storys» zerlegt.  
• Es wird unterschieden zwischen funktionalen Anforderungen (Fähigkeit), Qualitätsanforderungen (Verhalten) und Randbedingungen (Umgebung)
• Und nach Anforderungsthemen gruppiert.

Innerhalb des Sprints gibt es das Backlog Refinement bei dem Anforderungen besprochen und verfeinert werden.

Mit der «Definition of Done» (DoD) entwickelt das Team ein gemeinsames Verständnis davon, wann ein Product Backlog Item vollständig und bereit für die Produktionsfreigabe ist.

Die wichtigsten Verantwortlichkeiten eines Product Owners sind:

• Sicherstellen, dass das Entwicklungsteam konstanten betriebswirtschaftlichen Wert liefert: Das bedeutet, dass der Product Owner die längerfristige Vision für das Produkt und kurzfristige Bedürfnisse ins Gleichgewicht bringen muss, und er das Product Backlog aus betriebswirtschaftlicher Sicht priorisieren und die Ergebnisse des Entwicklungsteams zusammen mit den Stakeholdern am Ende jedes Sprints prüfen muss.
• Managen aller Stakeholder: Der Product Owner ist dafür verantwortlich, konsistente Anforderungen an das Team weiterzuleiten. Er muss Anforderungen aller Stakeholder erfassen und sicherstellen, dass sich die Anforderungen nicht widersprechen. Es muss etwaige Meinungsverschiedenheiten zwischen Stakeholdern lösen, um das Entwicklungsteam davon zu entlasten.
• Kontinuierliche Versorgung des Entwicklungsteams mit den hochrangigen Einträgen aus dem Backlog: Die Granularität dieser Anforderungen muss klein genug sein, damit sie sich für einen Sprint eignet. Für alle Fragen, die nach dem Sprint-Planungsmeeting entstehen, muss der Product Owner zur zügigen Klärung zur Verfügung stehen.

Im Scrum werden keine Requirements-Engineering-Techniken eingesetzt. Trotzdem ist es für RE relevant. Denn im «Product Backlog» werden die aufgeführten Items resp. Anforderungen gebündelt.

Das Backlog sollte „DEEP" (Detailed appropriately, Estimated, Emergent, Prioritized, d. h. angemessen detailliert, geschätzt, dynamisch, priorisiert) sein.

Alternativ gilt die «INVEST»-Regel:

I: „Independent of each other" - unabhängig voneinander

N: „Negotiable" - verhandelbar

V: „Valuable" - wertvoll, nützlich

E: „Estimable" - schätzbar

S: „Small enough to fit into one sprint" - klein genug für einen Sprint

T: „Testable" - testbar

Im RE werden ähnliche Kriterien für gute Anforderungen genannt:

• abgestimmt
• Eindeutig
• Notwendig
• Konsistent
• Prüfbar
• Realisierbar
• Verfolgbar
• Vollständig
• Verständlich

Scrum ist ein schlankes Framework zur Entwicklung von Produkten in komplexen Umgebungen. Es gibt 3 Rollen (Scrum Master, Product Owner und Entwicklungsteam), 4 Ereignisse (Sprint-Planung, Daily-Scrum-Meeting, Sprint Review und Sprint-Retrospektive) und Artefakte (Product Backlog, Sprint Backlog, Sprint Goal/Sprint-Ziel und Definition of Done). Scrum empfiehlt keinerlei Engineering-Verfahren.

Scrum entwickelt Produkte iterativ und inkrementell in einer Folge von Sprints (max. 1 Monat). Jeder Sprint resultiert in einem Produktinkrement: Das ist ein Teilprodukt, das Endkunden in einer Produktionsumgebung potenziell verwenden können.

Der Sprint ist ein iterativer 'Plan-Do-Check-Act' Prozess. Jeder Sprint beginnt mit der Sprint-Planung, einem Ereignis, bei dem das Scrum-Team gemeinsam definiert, was im nächsten Produktinkrement ausgeliefert und wie das erreicht werden kann (Zerlegung).

Der Plan basiert auf dem Product Backlog (eine priorisierte und dynamische Liste aller Bedarfe für das Produkt). In der Sprint-Planung wird das Sprint-Ziel und Sprint Backlog (Auswahl der Items und deren Zerlegung für den Sprint) erstellt. Anschliessend beginnt das Scrum-Team mit der Implementierung des Produktinkrements.

Das Entwicklungsteam ist für die Umsetzung der ausgewählten Items in konkrete Ergebnisse verantwortlich, arbeitet mit dem Product Owner an der Verfeinerung der Product Backlog Items zusammen und gibt sein Feedback zur aktuellen Implementierung ab.

Die Mitglieder des Entwicklungsteams bringen sich jeden Tag in den Daily-Scrum-Meetings auf denselben Stand, um den Fortschritt zu beurteilen und das Sprint Backlog zu aktualisieren.

In der „Definition of Done" wird vereinbart, welche Teile einer Anforderung vom Entwicklungsteam erfüllt werden müssen. Wenn die Sprint Timebox vorüber ist, inspiziert das Scrum-Team in einem Sprint Review das Produktinkrement, und die wichtigsten Stakeholder bewerten die Ergebnisse des Sprints und besprechen die weiteren Schritte. Das Product Backlog wird entsprechend aktualisiert.

Der Sprint endet mit der Sprint-Retrospektive, in der das Scrum-Team bespricht, wie der letzte Sprint verlaufen ist, und wie es effizienter werden kann.

• Bei den Crystal Methoden wird für jedes Projekt ein eigens zugeschnittenes Prozessmodell benötigt. Abhängig von Größe, Komplexität und Kritikalität werden verschiedene Rollen, Aktivitäten und Artefakte angewendet. Crystal Clear, eine Methode für kleine und weniger kritische Projekte. Crystal Orange und Crystal Red wurden um einige Formalismen erweitert, um größere Projekte abwickeln zu können. Aus Anforderungsperspektive werden mit wenig formellen Anwendungsfallmodellen und Mock-ups gearbeitet.
• Lean Development und Kanban beruhen auf Prinzipien aus den 1940erJahren. Ziel dieser Ansätze ist es, sieben Arten von Verschwendung im Produktionsprozess aufzudecken (unfertige Vorprodukte, Überproduktion, Mängel,...) und diese bis zur endgültigen Lieferung schrittweise zu beseitigen.
• Scrum ist ein Framework zum Entwickeln und Erhalten komplexer Produkte. Das Framework ist auf eine iterative, inkrementelle Entwicklung ausgerichtet. Es gibt drei Schlüsselrollen: einen Product Owner (zum Managen des Product Backlog), ein Entwicklungsteam, das diese Anforderungen in kurzen Sprints implementiert und einen Scrum Master, der den Prozess überwacht und als Vermittler zwischen den anderen Rollen fungiert.
• TDD (Test Driven Development) beruht auf der Idee, dass vor dem Codieren eines Features zunächst der entsprechende Test verfasst wird. Die Testfälle sind sowohl eine exakte, als auch eine detaillierte Spezifikation der Anforderungen, die das Produkt erfüllen soll.
• XP (eXtreme Programming) Beim XP liegt der Schwerpunkt auf der direkten Kommunikation zwischen einem Kunden und einem Programmierer (der sog. On-Site Customer, der direkt neben dem Programmierer sitzt, ständig Anforderungen bespricht und unmittelbares Feedback in Form von implementierten Features erhält).  

3 Ansätze für Agilität in konzeptueller Arbeit (Kombinationen aus RE Ermittlungs- und Validierungstechniken).

Design Thinking  

• ein multidisziplinäres Team, das an dem Problem arbeitet; dieses Team bringt ein breit gefächertes Wissen mit, das für die Problemlösung benötigt wird;
• eine Arbeitsumgebung, in der das Team an Ideen arbeiten kann; und
• ein iterativer Prozess, der sich aus folgenden Phasen zusammensetzt: Hineinversetzen („Empathize") / Definieren („Define") / Ideen finden („Ideate as many as possible and choose one» / Prototypen entwickeln („Prototype") / Testen („Test")

Die Phasen des Design Thinking sind skalierbar und im Ablauf. Diese Methode entspricht dem agilen Wert „das Reagieren auf Veränderungen bewerten wir höher als das Befolgen eines Plans", «multidisziplinäre Team und die Arbeitsumgebung sind zentrale Elemente des Prozesses» sind und durch die Entwicklung von kostengünstigen und schlanken Prototyps, dem agilen Prinzip der «Einfachheit».

Der Design-Sprint ist ein 5-tägiger Entwicklungsworkshop mit Endkunden. Gearbeitet wird mit klar definierten «Timeboxes»;

• Wissen des Teams freisetzen / Ideen skizzieren / entscheiden, für welche Ideen Prototypen erstellt werden sollen / die ausgewählten Prototypen erstellen / die Ideen mit realen Kunden testen.
• Der entscheidende Unterschied im Vergleich zu agiler Entwicklung ist, dass der Prototyp keine Software sein muss

Lean Startup ist ein Ansatz zur Entwicklung von Geschäftsideen und zum Managen von Startups.

• Produktentwicklungsansatz „Build - Measure - Learn" führt zu kontinuierlichem Lernen über die Kundenbedürfnisse
• Mit dem Minimum Viable Product ist eine Version eines neuen Produkts gemeint, mit mimalem Aufwand das maximale Kundenfeedback ermöglicht.

Bei Lean Startup wird ein Kurswechsel, d. h. „eine strukturierte Kurskorrektur, um eine neue grundlegende Hypothese über das Produkt, die Strategie und den Wachstumsmotor» aufzustellen. Anstelle einer Ermittlung und Validierung der Anforderungen basierend auf Konzepten oder Dokumenten, werden diese Methoden anhand des realen Produkts durchgeführt. Das MVP muss nicht zwingend eine voll funktionsfähige, vollständige Software sein muss.

Agilität beinhaltet mehr als Scrum. Besonders geeignete Ansätze für Innovationen sind: Design Thinking, Design-Sprint und Lean Startup

Diese Techniken zeigen, dass es Ansätze für konzeptuelle Arbeit in RE@Agile gibt, welche die Denkweise agiler Methoden teilen und daher gänzlich mit agilen, Softwareentwickelnden Unternehmen kompatibel sind. Diese Herangehensweisen sollten als eine neue Form des Wasserfall-Ansatzes berücksichtigt werden.

Sie können als Frameworks von agiler Entwicklung für das Design dedizierter Aspekte eines Systems verwendet werden. Alternativ können sie als Aktivitäten genutzt werden, die der agilen Entwicklung vorangehen. So helfen diese Ansätze, das begrenzte Potenzial für Innovationen in agilen Entwicklungsprozessen zu überwinden. 

Agile und kulturelle Veränderungen sind unvereinbar. Agile Werte verändern die Unternehmenskultur (erfordert Zeit und qualifizierte Mitarbeiter)

Anforderungen als einheitliche Art von Informationen behandeln. Der benötigte Detailierungsgrad und unterschiedlichen Abstraktionsebene pro Anforderungen muss berücksichtigt werden. Z.B. Vision = hohe Abstraktionsebene und lange Gültigkeitsdauer.  Andere Anforderungen sind schnelllebiger – es müssen nicht alle Anforderungen einheitlich spezifiziert werden.

Den Zusammenhang aus den Augen verlieren. Bei agilen Methoden wird der Fokus nur auf Themen gelegt, die unmittelbar umgesetzt werden. Dadurch gerät der Gesamtzusammenhang aus dem Blickfeld. Lang- und mittelfristige Perspektiven schaffen (z. B. Verfeinerungs-Meetings).

Es wird sofort in Lösungen gedacht und spezifiziert. Noch bevor das Problem analysiert und der Nutzen/Bedarf des Stakeholders festgestellt wurde.

Stakeholder mit Informationen überladen. RE-Artefakte weisen eine hohe Informationsdichte auf, die einen grossen Review-Aufwand für Stakeholder darstellt.

Inkrementelle und iterative Ausarbeitung aller Themen. Nicht jedes Anforderungsthema muss detailliert und inkrementell entwickelt werden. Inkrementelle Entwicklungen eignen sich für komplexe Themen (z.B. Einkaufsprozess Onlineshop). Hochkomplexe Themen sind für inkrementelle Entwicklung nicht geeignet, da jede neue Erkenntnis zu einem völlig neuen Verständnis der bereits bekannten Informationen führt (z.B. Berechnungen von Versicherungspolicen).

Inkrementelle Entwicklung unterstützt möglicherweise keine radikalen oder bahnbrechenden Innovationen. Agile Entwicklungen mit inkrementellen Prozessen führen zu kontinuierlichen Innovationen. Radikale Innovationen entstehen, wenn unterschiedliche Ideen berücksichtigt und vorhandene Ideen neu kombiniert werden. Gemäss dem Prinzip «10. Prinzip - Maximieren nicht getaner Arbeit» werden keine alternativen Ideen in agilen Umgebungen entwickelt. Radikale Innovationen benötigt z.B. Lean-Startup-Ideen oder Design-Thinking-Ansätze.

Das RE ist lediglich eine vorab erstellte Analyse. Missverständnis, da RE als Disziplin prozessunabhängig ist und nicht zwingend eine umfassende Vorarbeit erfordert. RE kann in jede Iteration integrierte Aktivität darstellen.

Vorab ist schlecht. Missverständnis, da die Vorbereitung auf eine iterative Entwicklung ein wesentlicher Bestandteil jedes nicht alltäglichen Entwicklungsprojekts ist. Agile Verfahren, die den Wert von Überlegungen im Vorfeld berücksichtigen, sind Story Mapping, Prototyping und das sog. Test Driven Development (TDD).

RE ist gleich Dokumentation. Missverständnis, da Dokumente bei z.B. der Einhaltung rechtlicher Vorgaben (Compliance), Bewahrung nützlicher Informationen, Vereinfachung der Kommunikation und bei gedanklichen Vorgängen unterstützen.

User-Storys sind ausreichend. Missverständnis, da User-Storys eine Methode für die Erfassung der Stakeholder Bedürfnisse sind. Sie zielen jedoch darauf ab, die Kommunikation in Gang zu setzen und stellen nicht die vollständige Spezifikation dar. Ein weit umfassenderes Bild von Anforderungen lässt sich durch eine Kombination von User-Storys mit anderen anerkannten RE Techniken wie Kontextdiagrammen, Prototyping, Anwendungsfällen und User Journeys erreichen.

Dokumentation ist wertlos, nur Code ist von bleibendem Wert. Missverständnis, da die Anforderungsdokumentation ebenso wie die Design-, Test- oder Betriebsdokumentation in bestimmten Kontexten ihre Daseinsberechtigung hat. Die Dokumente sind alle gleichermassen gültige und notwendige Artefakte, die aus dem Entwicklungsprozess für jedes nachhaltige Softwareprodukt entstehen.

Funktionierende Software ist der einzige Weg zur Validierung von Anforderungen: Missverständnis, Software ist als Mittel zur Validierung von Anforderungen zu bevorzugen, wenn die mit einem solchen Validierungsansatz verbundenen Kosten und Risiken verglichen mit dem Ergebnis akzeptabel sind. Sind die Kosten und/oder Risiken hoch, stellt RE verschiedene Tools zur Verfügung, die ein schnelles Feedback und eine rasche Anforderungsvalidierung ermöglichen, bevor auch nur eine einzige Zeile Code geschrieben wurde, beispielsweise Modelle für Benutzeroberflächen oder Story Boards

• RE und Entwicklungskompetenzen im selben Team können den Aufwand für Übergaben verringern
• Wenn RE_ Aufgaben im Team ausgeführt werden, kann das den Bedarf an vorab erstellter, umfassender Anforderungsdokumentation verringern (direkte Klärung innerhalb des Teams)
• Dokumentation von Ergebnissen aus den geführten Gesprächen und die Bewahrung von Wissen
• Inkrementelle Entwicklung ermöglicht die Optimierung vorhandener Ideen (die Qualität der Artefakte und/oder Software wird kontinuierlich verbessert)
• Das Risiko das zwischen den Kundenerwartungen und der Entwicklung grosse Lücken entstehen wird minimiert
• Kontinuierliche Verfeinerung ist ein Prinzip zur Ausreifung und Validierung. In regelmässigen Verfeinerungsmeetings wird mit dem Entwicklungsteam und den Stakeholdern die Anforderungen wiederkehrend durchgesehen und detailliert
• Durch das Verfahren der "Definition of Ready" Als "Quality Gate" wird validiert, dass eine Anforderung einer nachfolgenden Iteration zur Implementierung bereit ist
• Das RE vereinfacht das definieren eines ersten «Product Backlogs». Das RE bietet verschiedene Techniken, um die Stakeholder Anforderungen für das gewünschte Produkt richtig zu verstehen.

Das Manifest für agile Softwareentwicklung hebt den Wert eines Inkrements funktionierender Software (oder eines funktionierenden Produkts) gegenüber einer umfassenden Dokumentation hervor. Eine übertriebene Interpretation hatte den falschen Eindruck zur Folge, dass agile Methoden gänzlich auf Dokumentation verzichten. Diese Interpretation ist falsch: Zweckmäßige Dokumentation ist in agilen Entwicklungsprozessen nach wie vor erwünscht und zu empfehlen, allerdings nur dann, wenn sie die Entwicklung unterstützt oder Bestandteil des Produkts ist. In der Vergangenheit wurde es als Problem empfunden, dass in vielen Projekten Dokumentation ohne klar definierten Zweck oder Mehrwert erstellt wurde - diese Art von Dokumentation ist nach den agilen Prinzipien zu vermeiden. 

• Das Ziel der Auslieferung von Software auf ein klar definiertem Qualitätsniveau
• Dank agiler Methode kann funktionierende Software effizient und schneller ausgeliefert werden (geringere Zykluslaufzeit)
• Da RE stellt geeignete Technikgen bereit, mit deren Hilfe ein Verständnis der Wünsche und Anforderungen von Stakeholdern erlangt und die Software mit dem grössten Gewinn (Zuwachs an Business-Wert oder Liderung akuter Probleme) entwickelt werden kann. 
• RE vereinfacht:

1. Bedürfnisserkennung und Verständnis der Stakeholder für die Softwareentwicklung
2. Marktveränderungen erkennen und für Stakeholder Wettbewerbsvorteile generieren
3. Förderung effizienter Stakeholder Zusammenarbeit durch passende Techniken und Werkzeuge
4. Unterstützung verbaler Kommunikation durch passsende Techniken und Werkezuge
5. Das Verständnis um Stakeholder Anforderungen auf das Minimum reduzieren zu können. 

• Das RE beschäftigt sich mit der systematischen Ermittlung und Dokumentation von Anforderungen als eigenständigen Artefakten, während bei agilen Entwicklungsprozessen die funktionierende Software im Vordergrund steht und nicht eine umfassende Dokumentation; auch werden Personen und Kommunikation höher bewertet als Prozesse und Werkzeuge.
• Ein wichtiger Unterschied zwischen der Anwendung von RE in agilen Entwicklungsprozessen und anderen Entwicklungsmethoden ist die zeitliche Abstimmung und der angewandte Prozess. 
• Das Manifest für agile Softwareentwicklung hebt den Wert eines Inkrements funktionierender Software (oder eines funktionierenden Produkts) gegenüber einer umfassenden Dokumentation hervor.

Differenzierung nach "Prinzipien", "Verfahren" und "Aktivitäten" auf den drei Abstraktionsebenen:

• Ein Prinzip ist eine präskriptive Aussage, die abstrakt und falsifizierbar ist.
• Ein Verfahren/eine Technik ist eine Instanziierung eines Prinzips in einem bestimmten Kontext.
• Eine Aktivität ist eine reale oder geplante Ausführung eines Verfahren

Die wichtigen Begriffe zur Differenzierung der drei Definitionen sind präskriptiv, abstrakt und falsifizierbar. Präskriptiv bedeutet, dass die Aussage eine Aktion steuert, anstatt eine Tatsache oder eine Eigenschaft darzulegen. Ein Prinzip unterscheidet sich von einem Verfahren durch Abstraktheit. Ein Beispiel: „Eine Softwarefunktion vor der Auslieferung testen" ist präskriptiv, wohingegen „einen Unit-Test für jedes Softwarefeature erstellen" ein Verfahren basierend auf dem vorgegebenen Prinzip ist. Eine Aktivität zu diesem Beispiel wäre die Erstellung eines UnitTests für die Suchfunktion eines Bibliotheksystems. Falsifizierbarkeit bedeutet, dass eine Person mit hinreichendem Hintergrundwissen eine andere Meinung zu einem Prinzip haben kann. Das oben angeführte Prinzip („Eine Softwarefunktion...testen") erfüllt dieses Kriterium. 

Agile Prinzipien:

1. Zufriedenstellung des Kunden durch frühzeitige und kontinuierliche Auslieferung
2. Veränderte Anforderungen auch noch in späten Entwicklungsphasen
3. Funktionierende Software regelmässig innert weniger Wochen ausliefern
4. Stakeholder/Entwickler arbeiten täglich zusammen
5. Projekte mit motivierten Einzelpersonen
6. Persönliches Gespräch als effizienteste/effektivste Methode für Informationsvermittlung im Team
7. Funktionierende Software als primäres Mass für Fortschritt
8. Agile Prozesse fördern kontinuierliche Entwicklungen
9. Stetiges Augenmerk auf technischer Excellenz und gutes Design
10. Einfachheit ist wesentlich
11. Beste Architekturen, Anforderungen, Designs aus sich selbst organisierenden Teams
12. In regemässigen Abständen Nachdenken um effizienter zu werden.

In der agilen Entwicklung // Manifest

• Einzelpersonen und Interaktion vor Prozesse/Werkzeuge
• Funktionierende Software vor umfassender Dokumentation
• Zusammenarbeit mit Kunden vor Vertragsverhandlung
• Reagieren auf Veränderungen vor Plan befolgen

• Im RE wird der Begriff "System" bevorzugt, da er die Tatsache betont, dass ein System eine Gruppe von Bestandteilen oder Elementen ist, die zusammen in einer Umgebung funktionieren. Die Umgebung bezeichnet man im RE als Systemkontext
• Die 4 Hauptaktivitäten des RE sind: Ermitteln, Dokumentation, Prüfen, Validierung/Abstimmung und Verwaltung von Anforderungen
• Ein zentraler Wert des IREB ist, dass das RE ein prozessunabhängiger Ansatz ist (= ein grosser Wissensfundus an Methoden und Techniken)
• IREB ist der Überzeugung, dass beide Ansätze (agil und nicht-agil) ihren Wert haben.

Requirement Engineering (RE) ist gemäss IREB Definition: 

Ein systematischer und disziplinierter Ansatz für die Spezifikation und das Management von Anforderungen mit den folgenden Zielen:

• Verstehen und Dokumentieren der Wünsche und Bedürfnisse der Stakeholder
• Kennen der relevanten Anforderungen, Erreichen eines Konsenses der Stakeholder über diese Anforderungen, das Dokumentieren der Anforderungen nach vorgegebenen Standards und das systematische Managen der Anforderungen
• Spezifizieren und Managen von Anforderungen, um das Risiko der Auslieferung eines Systems zu minimieren, das nicht den Wünschen und Bedürfnissen der Stakeholder entspricht. 

• Agile Methoden resp. Agilität sind kein Selbstweck
• Agile Methoden eignen sich, wenn der Markt oder eine Projektsituation schnelle und kontrollierte Änderungen erfordert
• Bei der agilen Methode konzentrieren sich alle Prinzipien letztlich auf häufige Auslieferungen in einer vorgegebenen Qualität
• Passender Entwicklungsansatz ist entschiedener Erfolgsfaktor im digitalen Geschäft
• Systeme und Produkte in IT-orientierten Branchen müssen einer konstanten Anpassung unterzogen werden, damit sie mit den veränderten Bedürfnissen von Kunden oder dem Markt schritthalten können.