Software Engineering in der industriellen Praxis...Requirements in agilen Produktentwicklungen, • Modellierung und Beschreibung fachlicher Lösungen, Domänenmodell, Use Case Modell,

.consulting .solutions .partnership

Software Engineering in der industriellen PraxisRequirements Engineering

Rudolf Koster

SEIP-Vorlesung WS 2019/20

Block B.1: Requirements Engineering

© msg | WS 2019/2020 | Software Engineering in der industriellen Praxis – Block B.1: Requirements Engineering 2

Inhalte:

• Grundlagen: Qualität, Anforderungen,

Funktionale Spezifikationen,

Requirements in agilen Produktentwicklungen,

• Modellierung und Beschreibung fachlicher Lösungen,

Domänenmodell, Use Case Modell, Facharchitektur,

Detaillierung von Requirements im agilen Umfeld,

Werkzeugunterstützung in der Praxis

Rudolf ist Principal IT Consultant im Bereich msg

Applied Technology Research der msg systems ag. Er

unterstützt Projekte bei der Auswahl und Anwendung

geeigneter Vorgehensmodelle und ist verantwortlich für

die msg-weiten Empfehlungen zum Thema

Projektvorgehen.

Der diplomierte Informatiker blickt auf langjährige, auch

internationale Erfahrung in der IT-Branche zurück.

Insbesondere verfügt er über ausgewiesene Expertise

im Requirements Engineering und der Modellierung

komplexer betrieblicher Informationssysteme.

Rudolf Koster

Requirements Engineering

Ein problematisches IT-Projekt…

3© msg | WS 2019/2020 | Software Engineering in der industriellen Praxis – Block B.1: Requirements Engineering


Agenda

Agenda

Grundlagen und Begriffsdefinitionen1

Requirements in agilen Projekten2

Veränderte RE-Rollen im agilen Umfeld3

Domänenmodell4

5

6

Use Case Modell

Detaillierung von Requirements

7 Zusammenfassung


• Qualität (quality) – der Grad, in dem ein Satz inhärenter Merkmale [einer Sache] Anforderungen erfüllt. [ISO 9000:2000]

• Inhärentes Merkmal (inherent characteristic) – eine kennzeichnende Eigenschaft einer Sache (Produkt, Dienstleistung, Prozess, System, Person, Organisation, etc.), welche diese aus sich selbst heraus hat und die ihr nicht explizit zugeordnet ist.

Beispiel:

Ein Medikament

• Inhärentes Merkmal:

Zusammensetzung

• Explizit zugeordnet:

Preis


GrundlagenQualität


GrundlagenAnmerkungen zum (industriellen) Qualitätsbegriff

• Qualität ist Erfüllung von Anforderungen. Die Anforderungen können explizit festgelegt oder

implizit durch gemeinsame Vorstellungen der Beteiligten gegeben sein.

• Qualität ist kein absolutes Maß für die Güte einer Sache.

• Qualität entsteht nicht von selbst. Sie muss definiert und geschaffen werden.

• Qualität bezieht sich sowohl auf Produkte als auch auf Prozesse und Projekte.



GrundlagenAnforderung

Eine Anforderung (requirement) ist:

(1) Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder

System) zur Lösung eines Problems oder zur Erreichung eines Ziels

benötigt wird.

(2) Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen

oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder

andere, formell vorgegebene Dokumente zu erfüllen.

(3) Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft

gemäß (1) oder (2).

(IEEE 610.12-1990)

Anforderungsspezifikation (requirements specification):

• Die Zusammenstellung aller Anforderungen an ein System gemäß

vorgegebenen Kriterien.

• Synonyme: Fachkonzept, Pflichtenheft.



GrundlagenRequirements Engineering (Anforderungstechnik)

1. alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad

verstanden sind,

2. die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten

Anforderungen erzielen,

3. alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu

den Spezifikationsvorschriften spezifiziert sind.

(Pohl: Requirements Engineering, 2007)

Das Requirements Engineering ist ein kooperativer, iterativer,

inkrementeller Prozess, dessen Ziel es ist zu gewährleisten, dass



GrundlagenAnforderungen vs. Ziele

Gemeinsamkeiten: Beide beschreiben etwas zu Erreichendes

Unterschiede:

• Ziel, Vision: ein zu erreichender Zustand meist in umfassendem Sinn gemeint

• Anforderung meist konkret beschreibt in der Regel eine für die Erreichung eines Ziels notwendige Bedingung oder Eigenschaft



GrundlagenKlassifikation von Anforderungen

Projekt-/Produktziele

Termine Kosten

Funktionale Anforderungen Nicht-funktionale Anforderungen

Funktionen, Verhalten und Daten

Sachziele =

Anforderungen

an das Produkt

Leistungsanforderungen besondere Eigenschaften

RandbedingungenAttribute



GrundlagenAnforderungen priorisieren

• Nicht alle Anforderungen sind gleich wichtig:

Muss-Anforderungen: unverzichtbar

Soll-Anforderungen: wichtig, aber bei zu hohen Kosten verzichtbar

Kann-Anforderungen: schön zu haben, aber nicht essenziell

• Priorisierung nötig bei

harten Terminen

harten Budgetobergrenzen

Beschaffung

• Priorisierung nützlich bei

Festlegung von Inhalt und Umfang der Inkremente bei inkrementeller Entwicklung

Releaseplanung bei der Weiterentwicklung bestehender Systeme



GrundlagenRollendefinitionen im Requirements Engineering

Business Consultant Business Analyst Requirements Engineer

• Spezifisches Domänenwissen

• Marktkenntnisse/Wettbewerb

• Mgmt. Geschäftsprozesse

• Definition grober Prozess-

Anforderungen

• Business Case Ermittlung

• Hohe Domänenkompetenz

• IT-Verständnis

• Konzeptionelles Know-How

• Hohe Methodenkompetenz

• Kommunikationsmethodik

• Domänenwissen

• Detailierung der Prozess-

Anforderungen

• Definition des IT-Systems

• Stakeholder Detailanforderung

• Werkzeugunterstützung

• Modellierungsvorgaben



13

Requirements in agilen Projekten

© msg | WS 2019/2020 | Software Engineering in der industriellen Praxis – Block B.1: Requirements Engineering

Requirements in Agilen ProjektenAnforderungen iterativ bearbeiten im Backlog


• Kontinuierliches RE

• „just in time“, und „just enough“ (Detaillierung

nach Bedarf) statt detaillierte Spezifikation zum

Projektbeginn

• Kontinuierliche Dokumentation

• Auf Änderungen der Projektumgebung flexibel

reagieren

Delete items

Refine items

Reprioritize items

Estimate

SizeItem

Original large item

3

Insert item


Requirements in Agilen ProjektenAnforderungen als User Stories


• Beschreibt aus Perspektive des Nutzers, was

das System tun soll

• Repräsentiert einen eigenständigen Business

Value für den Nutzer

• Definiert keine vollständige Lösung, sondern

fordert Funktionalität

• Card, Conversation, Confirmation:

Versprechen einer Konversation,

Akzeptanzkriterien auf Kartenrückseite

• Erfüllt Kriterien gemäß INVEST

(Independent, Negotiable, Valueable,

Estimatable, Small, Testable)


Requirements in Agilen ProjektenUser Stories – funktionale und nichtfunktionale Anforderungen

• Die User Story beschreibt die funktionale

Anforderung aus Sicht des Anwenders inkl.

Begründung für die Anforderung.

• Nichtfunktionale Anforderungen zur Story

werden als Akzeptanzkriterien formuliert.

• Allgemeine NFA werden in der Definition of

Done formuliert.

Als Stammkunde möchte ich über den Versand

meiner Bücher informiert werden, so dass ich

den Termin nicht verpasse.

• Die Benachrichtigung sollte 10 Min. nach

dem Versand beim Kunden ankommen.

• …

User Story

Nichtfunktionale Anforderung

als Akzeptanzkriterium

Eingeschränkt

durch

DoD:

• Auf Aktionen des Nutzers soll innerhalb

von 200 ms eine Reaktion angezeigt

werden.

• Das System muss 99% für den Nutzer

verfügbar sein.

• Das System muss 100 simultane Nutzer

ohne Leistungseinbrüche unterstützen.



Requirements in Agilen Projekten User Stories und die „passende Größe“

• User Story ist per Definition „Small“ Umsetzung in einer Iteration

• Schwierig Überblick über Zusammenhänge zu

behalten

• Prozesse werden segmentiert

• Fachlicher Gesamtkontext verliert sich in

Einzelanforderungen

(Zumindest) Hierarchische Strukturierung

von User Stories notwendig



ThemeFeature

StoryStory

Epic

Story

StoryStory

StoryStory

Priorisiert

Epic

Requirements in Agilen Projekten Agile Artefakte – das sind nicht nur User Stories!

Anforderungen an das Produkt

auf unterschiedlichen

Granularitätsebenen

Zukünftige

Releases

Release

Sprint ready for Sprint

verfeinert, gut

Verstanden

Grobe Ideen,

Komponenten

Vision



Requirements in Agilen Projekten Produktvision

http://www.innovationgames.com/product-box/

http://www.romanpichler.com/tools/vision-board/

• Eine Produktvision stellt die Kernessenz

eines Produkts oder einer Produktlinie dar.

• Sie zeigt die Richtung, die eingeschlagen

werden muss. Sie lässt zugleich genug

Freiraum für Kreativität.

• Leitlinie bei der Identifizierung der

Anforderungen, deren Überprüfung und

Priorisierung

Our job is not to

develop software,

Our job is to change

the world.All my music in my

pocket



http://www.innovationgames.com/product-box/

http://www.romanpichler.com/tools/vision-board/

Requirements in Agilen Projekten Agile Artefakte (Backlog Items)

Epic

User Story

Task

Epic = „Große User Story“, zerlegbar in User Stories, die in Ihrer

Gesamtheit die Anforderung abbilden.

User Story = Anforderung, die für sich alleine einen Mehrwert

darstellt und innerhalb eines Sprints durch das Team umgesetzt

werden kann.

Task = Aufgabe, die einen Teilaspekt einer User Story erledigt

oder eine Voraussetzung hierfür schafft (technisch oder operativ).

Das Entwicklungsteam erstellt die Tasks zu einer User Story.

1..*

0..*

0..1

0..1



Requirements in Agilen Projekten Story Mapping: Big Picture & Planung

Das „Walking Skeleton“ ist eine

Minimalversion des Systems, die einen

kleinen aber kompletten

End-to-End Prozess abbildet.

Buch auswählen Warenkorb Versandarten Zahlung …..

Bücher auflisten

Bücher

auswählen

Bücher

suchen

Bücher

filtern

Notwendig

Zeit

In Warenkorb

legen

Warenkorb

löschen

Standard-

Versand

Versand

Adresse

Rechnung-

Adresse

Zahlen per

Kreditkarte

Pay Pal Zahlung

Walking Skeleton

Nice to

have

Express

Versand

Backbone:

Reihenfolge von

Hauptaktivitäten

User

Stories



Requirements in Agilen Projekten Notwendig für komplexe Produkte / große Teams: Scaled Agile

• Muss z.B. Scrum auf mehrere Teams skaliert

werden, wird es schwieriger.

• Zusätzliche Synchronisations-Events,

Aufwände für die Gesamtsystemintegration...

• Für die Skalierung gibt es verschiedene

Ansätze / Frameworks (siehe rechts).

• Produktteams sollten sich von einem erfahren

agilen Coach beraten lassen

• Eine stark entkoppelte Fach-/IT-Architektur ist

Voraussetzung!

SOS

SM

SM

SM

SM SM

LeSS

Scaled Scrum

Area PO Area PO

DT

SM

Area PO

(Chief)

Product Owner

Product Backlog

...DT

SM

DT

SM




Spannungsfeld Klassische / Agile Vorgehensweise im RE Kontext

Klassisch / Wasserfall Agile Vorgehensweise

• Anforderungslisten und Grobkonzepte

• Umfassende und detaillierte

Fachkonzepte

• Detaillierte und abgestimmte

Beschreibung und/oder Modelle

• Umfassendes Systemdesign und

verfeinerte Modelle gemäß Blueprint

• Übergabe an Umsetzung erfolgt nach

Review und Freigabe aller Artefakte

• Dokumentation als Analysemedium

ANFORDERUNGEN • Backlog wird aus der Vision abgeleitet

und in User Stories formuliert

• „Just enough“ - Source Code ist

primäre Dokumentation

• Ergibt sich sukzessive aus den

umgesetzten User Stories

• Autonomie des Teams erlaubt jegliche

technische Architektur/Technologie

• Jederzeit steht ein Produktstand zur

Verfügung

• Basierend auf Source Code Analyse

DOKUMENTATION

FACHARCHITEKTUR

TECHNISCHE ARCHITEKTUR

TIME-TO-MARKET

WARTUNG / ÄNDERUNGEN




Veränderte RE-Rollen im agilen

Umfeld


RE in agilen IT-Projekten

Agile IT-Projekte sind die Norm

IT-Projekte zur Entwicklung betrieblicher Informationssysteme gehen heute

in der Regel agil vor

Arbeiten in CFTs

Req. Engineers und Business Analysts werden in cross-functional teams

(CFTs) arbeiten

Neues RollenverständnisWelche geänderten Anforderungen stellen CFTs an die die Rollen RE und

BA?

Wechsel zu stabilen Produktteams

Welche Anforderungen stellt der Wandel von Projekt- zu Produktteams (

DevOps) an die Rollen RE und BA?



Cross-functional Teams

Grundidee:

• Organisatorische oder Rollenbasierte Silos

überwinden

• Formale Übergaben von Artefakten (

Verzögerungen) zu vermeiden

http://www.ediblegeography.com/wp-content/uploads/2012/09/steel-silo-460.jpg


http://www.ediblegeography.com/wp-content/uploads/2012/09/steel-silo-460.jpg


Cross-functional Teams

Stattdessen:

• Ein Team verantwortet ein Produkt

• Alle dazu notwendigen Spezialrollen (inkl.

DevOps) sind im Team vorhanden

• Querschnittsrollen werden möglichst vermieden

( Wartezeiten)

Sriram Narayan: Agile IT Organization Design: For Digital Transformation and Continuous Delivery, 2015



Stabile Produktteams statt wechselnder Projektteams

Grundidee:

• Ein Team verantwortet eine

Geschäftsfähigkeit („Business Capability“)

• Eine Capability besteht ggf. aus mehreren IT-

Produkten

gleichzeitig, sich ergänzend

nacheinander, einander ablösend

Vorteile:

• Die Ramp-up-Zeiten von Projekten entfallen

• Ein Team braucht mehrere Monate, bis es

effizient zusammenarbeitet

• Das aufgebaute Fach- und IT-Know-How

bleibt im Team

Höhere Produktqualität zu geringeren Kosten




„T-förmige“ Teammitglieder

Herausforderung:

• Reine Spezialisten („I-Shaped“) sind Experten

nur auf einem Gebiet

• Ihnen fehlt es oft an Verständnis für die

Erfordernisse anderer Spezialisten

• In einem „Cross-functional Team“ kann dies die

Zusammenarbeit erschweren

Lösung:

• Neben seinem Spezialwissen sollte ein „T-

Mitarbeiter“ auch Kenntnisse in anderen

(Team-relevanten) Bereichen besitzen

• Dadurch kann er im CFT mehr als eine

Aufgabe übernehmen

• Manchmal hat ein Mitarbeiter zwei gleich

stark ausgeprägte Expertisen (Pi-shaped)

Kleinere Teams

Bessere Zusammenarbeithttp://en.wikipedia.org/wiki/T-shaped_skills

https://www.solutionsiq.com/learning/blog-post/the-life-of-pi-moving-beyond-t-shaped-skills-for-agile-teams/


http://en.wikipedia.org/wiki/T-shaped_skills

https://www.solutionsiq.com/learning/blog-post/the-life-of-pi-moving-beyond-t-shaped-skills-for-agile-teams/


Staffing nach Skills statt nach Rollen

Grundidee:

• Ein Team startet vielleicht als Gruppe von

„Spezialisten“-Rollen

• Nach längerer Zusammenarbeit werden von den

Mitgliedern „verwandte“ Skills erworben

Ein „poly-skilled“ Team ist agiler als ein Team von

Spezialisten

• Wenn es genügend „T-Mitarbeiter“ gibt, ist ein

Staffing nach Skills statt nach Rollen sinnvoll

Beispiel:

• Person I hat nicht nur die Rolle Analyst, sondern kann auch

UX-Aufgaben übernehmen

• Person E hat nicht nur die Rolle Tester, sondern kann auch

Analyse-und Stakeholder Management übernehmen




Skills im Requirements Engineering

• Aus der engen Zusammenarbeit mit anderen

Teammitgliedern ergeben sich folgende

wünschenswerte Kombinationen von Skills

• Dadurch werden aus Spezialisten flexibler

einsetzbare „T-Mitarbeiter“

Skills

First Line Second Line (choose one)

Business Consultant Enterprise Architect,

Legal

Business Analyst Requirements Engineer,

Tester,

User Interface Designer

Requirements Engineer Business Analyst,

Application Architect,

Software Developer




Domänenmodell

Modell:

• Abstrahierendes Abbild einer existierenden

oder Vorbild für eine geplante Realität (z.B. ein

IT-System).

Handbuch der Anforderungsmodellierung nach IREB Standard, Ver. 1.3, 08/2016


DomänenmodellWas ist ein Modell?


1. Wolfgang Keller: IT-Unternehmensarchitektur, 2. Aufl. 2012

• Eine Facharchitektur wird verwendet, um

Entscheidern und Entwicklern ein fachliches

(Referenz-)Modell an die Hand zu geben, damit

Anwendungen nach einheitlichen Grundsätzen

entwickelt werden

Heterogene Anwendungen zu einem sinnvollen, in

der Architektur definiertem Ganzen

zusammengefügt werden können.

• Eine Facharchitektur beschreibt die

komplette spezifische Fachlichkeit einer

Branche oder einer einzelnen Anwendung

ohne dabei Details der technischen

Implementierungen festzulegen


DomänenmodellWas ist (IT-) Facharchitektur?


• Domain: A range of relevant things (for some

given matter)

IREB Glossary of Requirements Engineering Terminology, Version 1.6

May 2014

• Manchmal auch gebraucht im engeren Sinne

(vgl. Domain-Driven Design):

Problem Domain• Core Domain

• Supporting Domains

“Bounded Context” mit “Ubiquitous Language”Scott Millett: Patterns, Principles and Practices of Domain-Driven Design: Wrox, 2015


DomänenmodellWas ist eine fachliche Domäne?


Scott Millett: Patterns, Principles and Practices of Domain-Driven Design: Wrox, 2015


DomänenmodellDomäne, Hauptdomänen, Unterstützende Domänen


Kategorien abgeschlossener

Fachlichkeit

Basis für logische

Strukturierung des

Systems

hohe Kohäsion,

lose KopplungGeeignete Granularität zur

Wiederverwendung

Kann Teams oder

Entwicklern zur

Bearbeitung zugeordnet

werden

Beherrschung der

Komplexität


Domänen in der UML:Fachliche Komponenten


Große Domänen sollten mittels

fachlicher Komponenten gemäß

folgenden Regeln unterteilt werden.

Auf oberster Ebene:

• Hauptdomänen

Auf weiteren Ebenen:

• Unterstützende Domänen

• Minimierung von Abhängigkeiten

zwischen Komponenten

class Domain Model

Auction Seller

MembershipListing Dispute Resolution


DomänenmodellFachliche Komponenten


Ein Domänenmodell

stellt die in der

Domäne

enthaltenen

Entitäten mit deren

Attributen und die

Beziehungen

zwischen den

Entitäten graphisch

dar.

1. https://www.qmethods.de/glossar_domaenenmodell.html


DomänenmodellBeispiel Domänenmodell in UML


Die Unified Modeling Language (UML) ist eine

graphische Notation, eine „visuelle

Modellierungssprache“, die es erlaubt die Artefakte

eines Systems von den Anforderungen über die

Spezifikationen bis hin zum Code

• zu spezifizieren,

• zu visualisieren,

• zu konstruieren,

• zu dokumentieren.

class UML-Diagramm

class Strukturdiagramm

Klassendiagramm

Komponentendiagramm

Verteilungsdiagramm

Objektdiagramm

Paketdiagramm

Strukturdiagramm

Kompositionsstrukturdiagramm

class Verhaltensdiagramm

Verhaltensdiagramm

Aktivitätsdigramm

Use-Case-Diagramm

Interaktionsdiagramm

Zustandsdiagramm

Sequenzdiagramm

Kommunikationsdiagramm

Timingdiagramm

Interaktionsübersicht


Unified Modeling Language (UML)




Use Case Model

• Akteure

• Anwendungsfälle

• Fachliche Komponenten


Use Case ModelGrundkonzepte Use Case Model


Ein Actor repräsentiert alles, was mit dem System

interagiert

Ein Use Case ist eine Abfolge von Aktivitäten die

durch ein System ausgeführt werden, welche ein

Ergebnis von messbarem Wert für einen

bestimmten Akteur hervorbringen

Actor

Use Case


Use Case ModelGrundkonzepte Use Case Model


• Die UML hat keine Notation für die

Modellierung von Oberflächen

• Die meisten UML-Tools unterstützen jedoch die

Modellierung bzw. Skizzierung von User

Interfaces

• Auf diese Weise können Domänenmodelle und

Use Cases verknüpft (und verifiziert!) werden

uc Use Case Model

User

Use Case1

Screen1

UI Control

UI Control

Class2

- attribute_A

Class1

Class3

- attribute_B«trace»

«trace»

«trace»


Use Case ModelUI-Skizzen, UI-Mockups



uc Use Case Model

Urlaubsplaner

Mitarbeiter

Vorgesetzter

Urlaub erfassen

Urlaubsantrag

freigeben

SAP-HR

Urlaub beantragen

«trace»

Use Case ModelBeispiel: Urlaubsplaner-App



1. Der MA startet die Funktionalität zum Erfassen eines neuen Urlaubs-Zeitraums

2. Das System zeigt die Erfassungsmaske für einen Urlaubsantrag. Name des MA und Name des Vorgesetzten sind vom System befüllt und nicht änderbar.

3. Der MA gibt als Startdatum den ersten Tag des geplanten Urlaubs ein

4. Der MA gibt als Enddatum den letzten Tag des geplanten Urlaubs ein.

5. Das System berechnet die Anzahl der somit beantragten Arbeitstage und zeigt diese an.

6. Der MA kann optional eine Bemerkung in das Bemerkungsfeld der Erfassungsmaske eintragen.

7. Nach Bestätigung aller Eingaben durch den MA sendet das System die Antrags daten an das SAP-HR System.

uc Urlaub erfassen

Urlaub erfassen

Mitarbeiter SAP-HR

Standard-Szenario:

• Enddatum nach Startdatum

• Genügend Resturlaub vorhanden

Use Case ModelBeispiel: Use Case Ablauf: Urlaub erfassen



custom Urlaub beantragen

Urlaub beantragen

Bemerkungstext

Antragsteller:

Vorgesetzter:

Urlaub von:

Urlaub bis:

Tage gesamt:

Bemerkung:

01.04.2017

08.04.2017

6

Person

- Name: Zeichenkette

- Vorname: Zeichenkette

Urlaubsantrag

- /Anzahl: Ganzzahl

- Bemerkung: Zeichenkette

- Status: Antragsstatus

- Zeitraum: Zeitraum

Mitarbeiter

- UrlaubstageGuthaben: Ganzzahl

Rolle

Vorgesetzter

Rudolf Koster

Bernd Endras

«trace»

«trace»

+Rollen 0..*

+Anträge 0..*

+Antragsteller

«trace»

+Mitarbeiter

1..*

«trace»

«trace»

«trace»

Use Case ModelBeispiel: Urlaub beantragen (Domänenmodell, UI-Skizze)


• Use Case Szenarien haben eine 1:n

Beziehung zu Akzeptanztests

• Beispiel: Use Case: Geld abheben

Szenario: Auszahlung Standardbetrag

Akzeptanztests: Je 1 Test für jeden

Standardbetrag

Szenario in

Cucumber

(Gherkin)

Szenario in

Enterprise

Architect (UML)

Testfälle in

Cucumber


Use Case ModelUse Case Szenarien als Basis für Testfälle


Die Fachlichkeit eines komplexen

Systems sollte auf oberster

Ebene in mehrere fachliche

Komponenten und optional in

Schichten gegliedert werden.


Use Case ModelBeispiel: Facharchitektur (erste Ebene)


Auf zweiter Ebene wird z.B. eine

Einzelkomponente und deren

Abhängigkeiten zu Basis-

Funktionalität gezeigt.


Use Case ModelBeispiel: Facharchitektur (zweite Ebene)


Auf dritter Ebene werden z.B. die

Use Cases einer Einzelkomponente

gezeigt.


Use Case ModelBeispiel: Facharchitektur (dritte Ebene)


Artefakte für die Modellierung einer

Facharchitekur eines IT-Systems auf oberen

Ebenen (Hybrid = Klassisch + Agil)


class Big Picture

Facharchitektur

eines IT-Produkts

Fachliche

Komponente

Use Case Fachklasse

Epic

Zieldefinition Vision

0..*

0..*

include/extend

0..*

1..*

erfüllt0..1

0..*

associate

0..*

Use Case ModelMetamodell Facharchitektur („Big Picture“)




Detaillierung von Requirements

in agilen Produktentwicklungen

• Use Case ÜberblickLink zu Cluster/ Domäne

• Wenn sinnvoll werden zusätzlich Aktivitätsdiagramme für die Use Cases modelliert


Detaillierung von RequirementsVom Use Case über die User Story bis zum Testfall



Detaillierung von RequirementsVom Use Case über die User Story bis zum Testfall


• Use Case Beschreibung

Artefakte für die Modellierung

detaillierter Requirements eines

IT-Systems

(Hybrid = Klassisch + Agil)


class Details

Use Case Fachklasse

Use Case Flow

(Scenario)

Use Case Step

Fachliches Attribut

Akzeptanztest

User StoryTask

User Interface

1..*

0..*

0..*

include/extend

0..*

nutzt

0..*

1..*

Ablauf

1..*

1..*

zeigtvisualisiert

0..*

associate

Detaillierung von RequirementsMetamodell Facharchitektur („Details“)




Zusammenfassung,

Literatur

Hier nochmals zusammenfassend

• unsere wichtigsten Empfehlungen

• für eine effektive Kombination von

Facharchitektur und Agilität

• insbes. in komplexen betrieblichen

Informationssystemen

• Eine tragfähige IT-Architektur kann nur auf der

Basis einer durchdachten Facharchitektur

entstehen

• Eine zeitgemäße Facharchitektur ist stark

entkoppelt, um skalierbar mit agilen Teams in

modernen IT-Strukturen umgesetzt zu werden

• Komplexe Facharchitekturen benötigen

Modellierung und angemessene Dokumentation

• Epics und User Stories als Planungs- und

Umsetzungseinheiten alleine bieten keine

ausreichende Strukturierung

• Überblick und Orientierung gewinnt und behält

man vor allem durch Fachliche Komponenten

Domänenmodelle

Use Case-Modelle

• Testfälle müssen vor allem von Use-Case-

Szenarien ausgehen. Akzeptanztests einzelner

User Stories sind meist nicht ausreichend, um

wirklichen Mehrwert nachzuweisen


ZusammenfassungModernes Requirements Engineering



Literatur


• Pohl, K., Rupp, C.: Basiswissen Requirements Engineering. dpunkt Verlag, 4. Auflage, 2015.

• Rupp, C.: UML 2 glasklar: Praxiswissen für die UML-Modellierung. Carl Hanser Verlag, 4. Auflage,

2012.

• Patton, J.: User Story Mapping - Nutzerbedürfnisse besser verstehen als Schlüssel für

erfolgreiche Produkte. O'Reilly Verlag, 2015

• Vigenschow, U.: APM - Agiles Projektmanagement : Anspruchsvolle Softwareprojekte erfolgreich

steuern. dpunkt Verlag, 2015.

• Narayan, S.: Agile IT Organization Design: For Digital Transformation and Continuous Delivery.

Addison-Wesley Professional, 2015.

• Millett, S.: Patterns, Principles and Practices of Domain-Driven Design. Wrox, 2015.



Fragen?

.consulting .solutions .partnership

Rudolf Koster

Principal IT-Consultant

+49 (151) 17443281

[email protected]

msg systems ag (Headquarters)

Robert-Buerkle-Str. 1, 85737 Ismaning/Munich

Germany

Phone: +49 89 96101-0

Fax: +49 89 96101-1113

[email protected]

www.msg-systems.com

Vielen Dank für Ihre Aufmerksamkeit!

Documents

Software Engineering in der industriellen Praxis...Requirements in agilen Produktentwicklungen, • Modellierung und Beschreibung fachlicher Lösungen, Domänenmodell, Use Case Modell,