Glossar

Affinitätsschätzung
Schätztechnik agiler Teams, um schnell eine große Anzahl von Anforderungen (etwa: User Stories) zu schätzen. Dabei ordnet das Team die Stories in aufsteigender Reihenfolge auf einer horizontalen Skala an.
Agile Requirements Engineering
(adaptiert vom IREB): ein kooperativer, iterativer und inkrementeller Ansatz mit vier Zielen:
  1. Kenntnis der relevanten Anforderungen auf einem angemessenen Detaillierungsgrad (zu jedem Zeitpunkt der Systementwicklung),
  2. Erzielung einer ausreichenden Übereinstimmung der relevanten Stakeholder über die Anforderungen,
  3. Erfassung (und Dokumentation) der Anforderungen entsprechend den Vorschriften der Organisation,
  4. Durchführung aller anforderungsbezogenen Aktivitäten nach den Prinzipien des agilen Manifests.
Aktivitätsdiagramm
Ein Ausdrucksmittel der UML (Unified Modeling Language) zur grafischen Darstellung von Prozessschritten. Im Gegensatz zu →Datenflussdiagrammen konzentrieren sich Aktivitätsdiagramme auf die Ablaufreihenfolge von Schritten.
Akzeptanzkriterien
(adaptiert vom IREB): Eine Reihe von Bedingungen (typischerweise mit einer Anforderung verbunden), die von jeder Implementierung erfüllt werden müssen. Solche Bedingungen können z.B. die erwarteten Ergebnisse für die Eingangsdaten der Stichprobe oder die erwartete Geschwindigkeit oder das zu erreichende Volumen sein.
ASR (Architecturally Significant Requirements)
Architekturrelevante Anforderungen sind die Teilmenge der Anforderungen, die einen starken Einfluss auf architektonische Entscheidungen haben (jene Anforderungen, die insbesondere architektonische Entscheidungen prägen oder beeinflussen).
ATDD
Acceptance Test Driven Development
BDD
(Behavior Driven Development) Ein agiler Software-entwicklungsprozess, der die Zusammenarbeit zwischen Entwicklern, der Qualitätssicherung und nicht-technischen oder geschäftlichen Teilnehmern eines Softwareprojekts fördert. Er ermutigt Teams, Gespräche und konkrete Beispiele zu nutzen, um ein gemeinsames Verständnis darüber zu formalisieren, wie sich die Anwendung verhalten sollte, was zu ausführbaren Spezifikationen führt, z.B. in der Syntax von → Gherkin.
Bounded Context
In Domain Driven Design (DDD) ein Begriff für einen inhaltlich stark zusammenhängenden Bereich des Systems, der wenig Schnittstellen zu anderen solchen Bereichen aufweist und daher relativ unabhängig von den anderen implementiert werden kann.
BPMN (Business Process Model & Notation)
Ein von der OMG (Object Management Group) standardisierte Notation zur Beschreibung von Geschäftsprozessen.
Cost-of-Delay (Kosten der Verzögerung)
Eine Schätzgröße, die ausdrückt, wie viel Wert verloren geht, wenn ein Produkt zu spät geliefert wird. Anders ausgedrückt: Was könnten wir einnehmen, wenn das Produkt früher am Markt wäre.
Datenflussdiagramm
Ein Ausdrucksmittel aus der Strukturierten Analyse zur grafischen Darstellung von Prozessabläufen. Im Gegensatz zu →Aktivitätsdiagrammen konzentrieren sich Datenflussdiagramme auf die Ein- und Ausgaben der einzelnen Prozessschritte, den Fluss der Daten.
Definition of Ready
(DoR) (adaptiert vom IREB): eine Reihe von Kriterien, die eine Anforderung erfüllen muss, bevor sie in einer kommende n Iteration implementiert werden.
Domain-Driven Design (DDD)
Eine Methode zur Modellierung komplexer Systeme, die sich maßgeblich auf die umzusetzende Fachlichkeiten der Anwendungsdomäne stützt.
Epic
(adaptiert vom IREB): Eine abstrakte Beschreibung eines Stakeholderbedarfs, der in dem zu entwickelnden Produkt berücksichtigt werden muss. Epics sind typischerweise größer als das, was in einer einzigen Iteration umgesetzt werden kann.
Feature
Die Spezifikation eines Service, das einen Wunsch oder Bedarf eines Stakeholders erfüllt. Jedes Feature sollte eine Aussage über den Nutzen für den Stakeholder, sowie ein Akzeptanzkriterien enthalten.
Fibonacci-Schätzung
→Planning-Poker verwendet (leicht modifizierte) Fibonacci-Zahlen (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100) zur relativen Schätzung der Schwierigkeit von Anforderungen. Bedeutung: 0: Aufgabe bereits erledigt, 100: hoch komplexe Aufgabe, noch keine genauere Schätzung möglich. ½: sehr kleine Aufgabe, 1-5: eher kleinere, 8 und 13 mittlere Aufgaben. 13 oft für Aufgaben, die noch in einen einzigen Sprint passen. 20 und 40: zu umfangreich, brauchen noch Detaillierung der Anforderungen.
Funktionale Anforderung
Eine Anforderung bezüglich eines Ergebnisses, das durch eine Funktion des Systems (oder einer Komponente oder eines Dienstes) bereitgestellt werden soll.
Geschäftsziel (Business Goal)
Ein gewünschter Zustand (den ein Stakeholder erreichen möchte). Geschäftsziele beschreiben Absichten von Stakeholdern. Sie können zueinander in Konflikt stehen.
Gherkin
Eine domänenspezifische Sprache zum Schreiben von →BDD Szenarien in →GWT-Syntax.
GWT-Syntax
Given, When, Then: Eine halbformale Notation zum Schreiben von Testfällen oder Verhaltensspezifikationen. Erfunden von Dan North als Teil von →BDD (behavior-driven development).
INVEST
Ein Akronym für die Eigenschaften eine guten →(User) Story. Sie sollte unabhängig (I = independent), verhandelbar (N = negotiable), wertvoll (V = valuable), schätzbar (E = estimable), klein genug für die Umsetzung in einem Sprint (S = small) und testbar (T = testable) sein.
IREB
International Requirements Engineering Board. Siehe https://ireb.org
iSAQB
International Software Architecture Qualification Board. Siehe https://isaqb.org
MoSCoW-Priorisierung
Ein Akronym für vier Prioritätsstufen von Anforderungen: Must have, Should have, Could have, Won’t Have. Die “o” sind nur Füllbuchstaben, um das Wort aussprechbar zu machen.
Nichtfunktionale Anforderung (NFA)
Ein Sammelbegriff für eine → Qualitätsanforderungen oder eine → Randbedingung.
PAM
Ein Akronym für Purpose, Advantage, Metric, das dabei hilft, sich auf diese drei wichtigen Aspekte beim Formulieren von Geschäftszielen oder Visionen zu konzentrieren.
Planning Poker
Ein agiles Schätzverfahren, mit dem Mitglieder des Software-Entwicklungsteam die Größe von vorgestellten Epics, Features oder Stories schätzt. Vgl. → Wall-Estimation zur Beschleunigung der Schätzungen.
Product Owner
In Scrum die Rolle, die im Rahmen einer Produktentwicklung für die Erhebung, Verwaltung, Verfeinerung und Priorisierung von Anforderungen zuständig ist. Der Product Owner prüft auch am Ende einer Iteration die Erreichung der Anforderungen.
Qualitätsanforderung (Quality Requirement)
(nach IREB) Eine Anforderung, die sich auf eine Qualitätseigenschaft bezieht, die nicht durch funktionale Anforderungen abgedeckt ist.
Randbedingung (Constraint)
Eine Anforderung, die den Lösungsraum mehr einschränkt als es für die Erreichung von funktionalen Anforderungen oder Qualitätsanforderungen nötig wäre.
Scenario
Eine Beschreibung einer möglichen Folge von Ereignissen, die zu einem gewünschten (oder nicht gewünschten) Ergebnis führen.\ Alternativ: eine geordnete Folge von Interaktionen zwischen Partnern, insbesondere zwischen einem System und externen Akteuren.
Scope
Diejenigen Dinge, die Sie bei der Entwicklung eines Systems formen, gestalten und entscheiden können.
SLA (Service Level Agreement)
Ein Rahmenvertrag zwischen Auftraggebern und Dienstleistern für wiederkehrende 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 Einfluss auf die Anforderungen und/oder die Entwicklung eines Systems hat. Indirekter Einfluss umfasst auch Situationen, in denen eine Person oder Organisation durch das System beeinflusst wird.
Story Points
In agilen Schätzmethoden eine (fiktive) Einheit zur Beschreibung der Größe einer User Story.
(User) Story
Eine Beschreibung eines Bedarfs aus der Sicht eines Benutzers zusammen mit dem erwarteten Nutzen, wenn dieser Bedarf erfüllt ist. User Stories werden typischerweise in natürlicher Sprache geschrieben, oft unter Verwendung einer vorgegebenen Satzvorlage.
Use Case (deutsch: Anwendungsfall)
Eine Beschreibung der möglichen Interaktionen zwischen den Akteuren und einem System, die, wenn sie ausgeführt werden, einen Mehrwert bieten.

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. Sie spiegelt die Bedürfnisse wesentlicher Stakeholder wider, sowie die Funktionen, 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 die Wand gehängt wird und das Team rasch alle Epics oder Stories in den entsprechenden Spalten darunter anordnet statt jeweils einzelne Backlog-Items zu schätzen.
WSJF (Weighted Shortest Job First)
Vorschlag zur Priorisierung von Anforderungen aus dem SAFE Framework: Gewichteter kürzester Job zuerst. Die Gewichtung berechnet sich aus →Cost of Delay.

Up next

Literatur