Scrum für das Anforderungs-management im regulierten Umfeld

ReConf 2010 – München – 17. März 2010 

Scrum für Anforderungsmanagement im regulierten Umfeld – 

Darf man das? 

ZWISCHEN AGILITÄT UND REGULIERUNG 

Blaise Rey-Mermet, EVOCEAN GmbH, ©2010

Agenda 

Prinzipien bezüglich agilen Anforderungen mit Scrum 

Agile Anforderungen schreiben 

Agilität und Regulierung ausbalancieren 

2 - © EVOCEAN www.evocean.com

Immer mehr Veränderungen machen die Anforderungen 

Ihrer Kunden schwer vorhersehbar; behalten Sie sie agil! 

Schlanke & 

agile 

Methoden 

Reguliertes Anforderungsmanagement 

• Genügend Informationen für die Produktentwicklung 

Rückverfolgbare 

Produktanforderungen 

Effizient 

& 

Reguliert 

Agiles Anforderungsmanagement 

• Ausprobieren ist im Entwicklungsprozess 

möglich 

• Komplizierte Probleme werden in verständliche 

Fragestellungen aufgeteilt 

• Eine unvollständige Produktdefinition zu 

Projektbeginn ist möglich 

• Rückverfolgbarkeit und Priorisierung 


Prinzipien für agile Anforderungen mit Scrum

Die Prinzipien des Lean Manufacturing in der 

Produktentwicklung 

• Verschwendung eliminieren 

• Qualität einbauen 

• Know-how schaffen 

• Verbindlichkeiten verzögern 

• Schnell liefern 

• Teammitgliedern vertrauen 

• Kontinuierliche Verbesserung 

Verschwendung ist alles, was aus 

Kundensicht keinen Mehrwert 

generiert: 

• Funktionalitäten welche der 

Anwender nicht versteht / braucht 

Referenz: Implementing Lean Software 

Development by Mary & Tom Poppendieck 


Sieben Prinzipien des agilen Anforderungsmanagement 

• Kundenorientierter Ansatz: Der Kunde formuliert und priorisiert die Produktentwicklung 

• Wert orientiert: Der Kunde definiert den Wert seiner Anforderungen 

• Offen gegenüber Veränderungen: Anforderungen sind keine „Verträge“ 

• Unmittelbares Feedback: der Kunde probiert das Produkt aus 

• Just-in-time Anforderungen schreiben; Details bei Bedarf und nicht im Voraus 

zufügen 

• So viele Anforderungen wie notwendig schreiben: bis die Funktionalität verstanden 

ist 

• Mitbestimmung in der Entwicklung fördern: Das Team bestimmt wie die Kundenbedürfnisse 

am besten erfüllt werden können 


Wie Scrum die Agilität von Anforderungen fördert 

Merkmale von Scrum: 

Scrum ist eine agile Entwicklungsmethode welche uns hilft, die für den Kunden 

wertvollsten Funktionalitäten in möglichst kurzer Zeit zu liefern. 

• Sich selbstorganisierende Teams: die einen effizienten Weg suchen, um die 

vom Kunden und Produktmanager gesetzten Prioritäten zu erfüllen. 

• Kurze Iteration: welche ermöglicht, Arbeitsresultate schnell und wiederholt zu 

untersuchen. Alle zwei bis vier Wochen kann jeder Stakeholder lauffähige 

Komponenten sehen, sie freigeben oder sie weiter bearbeiten. 

• Verminderte Anzahl von Artefakten und Rollen: So gibt es beispielsweise mit 

Scrum nur eine Liste von Anforderungen – den Product Backlog. Diese wird dann 

für jede Wiederholung mit Aufgaben erweitert (Sprint Backlog). 

• Scrum schreibt wenig Vorgehensweisen für die Entwicklung vor. 


Product Backlog 

Sprint Backlog 

Übersicht: Scrum Prozess 

Sprint Development 

Envision 

Daily Scrum 

24 hours 

Scrum 

Master 

Team 

S0010 

S0020 

S0030 

S040 

S0050 

S0060 

Product 

Owner 

Sprint Plan 

S0010 

S0020 

Sprint 

2 -4 weeks 

Demo & 

Retrospective 

Product Backlog: 

wie vom Product 

Owner priorisiert 

Sprint Backlog: 

mit vom Entwicklungsteam 

bestimmten Tasks 

Task 01 

Task 02 

Task 03 

Transparenz: 

Demo von für den Kunden 

wertvollen Funktionalitäten 

Potentially Shippable 

Product Increment 


Scrum Rollen: Product Owner 

Product Owner 


Sprint Plan 

Code Prio Description Story 

Points 

S0040 1 Set up continuous integration 

system 

S0030 2 Create compilable application 

skeleton 

S0010 3 Display current mode in a 

simplest possible way 

S0120 4 Set up the server to update 

status data 

Status 

10 done 

5 started 

2 accepted 

3 started 

Verantwortlichkeiten 

• Eine gemeinsame Vision fördern 

• Anforderungen definieren 

• Über Release Datum und Inhalt entscheiden 

• Produktrentabilität (ROI) 

• Backlog verwalten und auf Grund des 

Marktwerts Prioritäten setzen 

• Arbeitsresultate akzeptieren oder verwerfen 

Product Backlog: 

wie vom Product 

Owner priorisiert 


Agile Anforderungen schreiben

Anforderungen als User Stories – klare Formulierung des 

Zwecks 

Die User Story beschreibt kurz eine Funktionalität 

des Systems, welche entweder für den 

Anwender oder den Product Owner von 

Nutzen ist. 

Die Formulierung ist standardisiert und stellt 

sicher, dass jede Anforderung einen Nutzen 

für den Anwender hat: 

Als möchte ich dass 

damit ich 

So werden Anforderungen in einer aktiven 

anstelle einer passiven Form geschrieben. 


Die User Story beschreibt … 

Wer (Anwender - 

Rolle) 

Was 

(Funktionalität) 

Warum (Nutzen) 


Warum resultieren User Stories in agilen Anforderungen? 

User Stories 

Herausforderungen bei der Formulierung von 

User Stories: 

• Fördern die klare Formulierung des 

Nutzens 

• Fördern die mündliche Kommunikation 

• Sind für alle Stakeholders verständlich 

• Haben die richtige Grösse für die Planung 

• Können bei der interativen Entwicklung 

eingesetzt werden 

• Verzögern die Definition von Details 

• Fördern die Mitwirkung von 

Teammitgliedern 

• Die Verwaltung von vielen kurzen Stories ist 

anspruchsvoll 

• Deren Rückverfolgbarkeit muss dokumentiert 

werden 

• User Stories ersetzen NICHT die Produktdokumentation 


… was wenn in späteren Sprints Details benötigt werden ? 

Eine User Story mit Kommentaren. 

Story 01: As a patient, I want 

clear indication of the implant 

operating mode, so I can easily 

read it when I am tired or 

confused. 

Details resp. zusätzliche Informationen können 

als Kommentar zur User Story hinzugefügt 

werden. 

Warum Kommentar? Bei User Stories steht 

NICHT die Verbindlichkeit im Vordergrund! 

Kommentare vermeiden den falschen Eindruck 

von Endgültigkeit. 

Priority 4 [10 Story Points] 

(Thomas) up to 7 modes are possible 

depending on the implant type. 






Sind detaillierte Anforderungen in agilen Projekten erlaubt? 

• Detaillierte Spezifikationen sollten nur für sich in Entwicklung befindenden Anforderungen 

geschrieben werden 

• Am Ende des letzten Sprints sind alle Anforderungen vollständig definiert 

• Veränderungen von Anforderungen, welche sich noch NICHT in Entwicklung befinden, 

haben keinen Einfluss 

Sprint 1 

Sprint 2 

Sprint 3 

Sprint N 

Stories 

Product 

Stories 

Product 

Stories 

Product 

Stories 

Product 

S0010 

S0010 

S0010 

S0010 

S0020 

S0020 

S0020 

S0020 

S0030 

S0030 

S0030 

S0030 

S0040 

S0040 

S0040 

S0040 

S0050 

S0050 

S0050 

S0050 

S0060 

S0060 

S0060 

S0060 

S0070 

S0070 

S0070 

S0070 

S0080 

S0080 

S0080 

S0080 



Sprint Backlog 

Detaillierung von Anforderungen mit Use Cases und 

Nicht-Funktionalen Anforderungen (NFR) 

S0010 

S0020 

The (smallest possible) 

requirements model that 

details the Story 

S0030 

S0040 

TA0014 

S0050 

S0060 

S0070 

S0010 

TA0013 

TA0012 

NFR0036 

NFR0035 

S0080 

S0020 

TA0011 

UC0034 

Stories 

selected for the 

Sprint 

Backlog tasks 

expanded 

by Team 


Agiles Anforderungsmodell (basierend auf D. Leffingwell) 

Critical Goals / 

User Needs 

REQ 

realized by 

Use Case 

elaborates 

Backlog Item 

constrains 

Non-Functional 

Requirements 

REQ 

REQ 

is a kind of 

Epic 

realized 

by 

Feature 

realized 

by 

Story 

REQ 

REQ 

REQ 

verifies 

verifies 

Referenz: Agile Enterprise Requirements Information Model – Subset for Agile 

Project Teams - by Dean Leffingwell 2008 

www.scalingsoftwareagility.wordpress.com 

Acceptance Test 

TST 


Beschreiben Sie vollständige Interaktionen mit Use Cases 

Use Case 

REQ 

elaborates 

Story 

REQ 

Stories und Use Cases haben unterschiedliche 

Ziele: Stories sind kurz – Use Cases 

beschreiben eine vollständige Interaktion: 

• Use Cases sind langlebiger 

• Use Cases beinhalten oft das Einvernehmen 

aller Beteiligten 

• Use Cases sind anfälliger bezüglich der 

Integration von technischen Details 

• Mit Use Cases können Stories, welche 

zusammen eine Sequenz bilden, zusammengefasst 

werden 


Verwenden Sie Nicht-Funktionale Anforderungen als 

Rahmenbedingungen für die Stories 

Backlog Item 

REQ 

constrains 


Requirements 

REQ 

Nicht-Funktionale Anforderungen 

• definieren die Qualität (im weitesten Sinne) 

welche eine Anwendung oder ein System 

erfüllen muss 

• umschreiben das “wie gut” von (z.B. in 

welcher Qualität); 

• Leistung, Sicherheit, Zuverlässigkeit 

• Normen, Standards 

• Designeinschränkungen 

Funktionale Anforderungen hingegen beschreiben 

das „was“ – und kommen auch bei 

Test Cases zum Einsatz. 


Ergänzen Sie die Stories mit Nicht-Funktionalen 

Anforderungen 

Eine User Story mit Nicht-Funktionalen 

Anforderungen 





confused. 


• Acceptance Tests stellen sicher, dass die 

Nicht-Funktionalen Anforderungen eingehalten 

werden 

NFR_1-5 

(Environmental Constraint) 

The control unit display shall be 

clearly legible under an ambient 

luminance. 


Verwenden Sie “Planguage” Stichwörter um die User 

Stories messbar zu machen 

Planguage ist eine informelle, strukturierte, 

stichwortartige Sprache um Anforderungen 

messbar zu formulieren: 

Minimum Goal Outstanding 

“Landing zone” 

Es gibt viel mehr Planguage 

Stichwörter – verwenden Sie 

diejenigen, welche für Ihre 

Story wertvoll sind 

Scale 

Scale: The measurement units used to 

quantify the statement (e.g., „mean time 

between failure‟). 

Meter: A practical method for measuring and 

testing on a defined scale. 

Minimum: level required to avoid failure. 

Goal: The level at which good success can 

be claimed. 

Outstanding: A future desired level, under 

defined [time, place, event] conditions, 

which is designed to challenge people to 

exceed Goal levels. 

Referenz: Tom Gilb - Competitive Engineering: A Handbook For 

Systems Engineering, Requirements Engineering, and Software 

Engineering Using Planguage- August, 2005 - www.gilb.com 


Dokumentieren Sie Annahmen und Risiken bei kritischen 

Stories 





confused. 


• Annahmen: Annahmen und Aussagen 

welche Probleme generieren wenn sie 

falsch sind 

• Risiken: Alles was Fehlfunktionen, 

Verzögerungen oder andere negativen 

Einflüsse auslösen kann 

(Thomas) Up to 7 modes are possible 

depending on the implant type. 

NFR_1-5 

(Environmental Constraint) 

The control unit display shall be clearly legible under an 

ambient luminance. 

Assumptions: 

1) ambient luminance range: 100 to 1000 lux. 

2) Viewing distance: 20cm to 60cm (for alarm signals, 

specific requirements shall apply). 


Wenn Sie über die richtige Menge von Details verfügen 

starten Sie mit dem Design! 

Eine User Story mit Acceptance Tests. 





confused. 

Zusätzliche Erwartungen der Anwender 

können mit acceptance tests abgedeckt 

werden. 


Try it in horizontal screen mode 

Try it in ambient luminance 

range: 100 to 1000 lux. 

Try it for viewing distance: 

20cm to 60cm 


… Überprüfen Sie anschliessend die Story mit dem Team 

und bewerten Sie die Funktionalitäten des Produkts 

Überprüfen der Story auf deren Konformität 

mit den Kundenerwartungen an das Produkt 

sowie mit den Erwartungen des Teams. 

Validieren des (lauffähigen) Produkts um 

sicher zu stellen, dass das Produkt die Ziele 

des Kunden erfüllt (nicht die Anforderungen). 

Die Charakteristiken der Story überprüfen: 

(INVEST model) 

• Independent 

• Negotiable 

• Valuable 

• Estimable 

• Small 

• Testable 

Sprint Review 

Das Team 

• präsentiert das im Sprint Erreichte 

• Erklärt / demonstriert die neuen 

Funktionalitäten 

• Lässt den Product Owner das Produkt 

ausprobieren 

Demo & 

Retrospective 




Agilität und Regulierung ausbalancieren

Standards machen einen definierten Prozess notwendig… 

Konform 

• Rückverfolgbar 

• Dokumentiert 

• Der Entwicklungsprozess muss dokumentiert 

sein 

• „Best Practices“ für ein minimales Produktrisiko 

und eine maximale Zuverlässigkeit 

• Das Produkt ist vollständig spezifiziert 

• Das Produkt ist auf allen Anforderungsstufen 

rückverfolgbar 

Agil 


Standards machen einen definierten Prozess notwendig, 

…Agilität macht ihn flexibel gegenüber Veränderungen 

Konform 

• Rückverfolgbar 

• Dokumentiert 

Agil 

• Flexibel gegenüber 

Veränderungen 

• Kleine Schritte 

• Kreativ 

Agile Prozesse unterstützen Prozesse, 

welche mit „Wasserfallprozessen“ nicht 

abgedeckt wurden: 

• Experimentieren und Feedback aus 

gemachten Erfahrungen müssen integriert 

werden. 

• Menschliche Kreativität ist kein linearer 

Prozess. Verschiedene Aspekte einer 

Entwicklung werden gleichzeitig abgedeckt. 

• Komplexe Probleme müssen in kleine, gut 

handhabbare Schritte aufgeteilt werden. 


Das CMMI ® Modell in einem agilen 

Anforderungsmanagement anwenden 

CMMI 

• Capability Maturity Model Integration 

(CMMI) ist ein Reifegradmodell für die 

Verbesserung von Prozessen zur 

Entwicklung von Produkten und 

Dienstleistungen. 

• CMMI definiert fünf Reifegrade um 

bewährte Entwicklungspraktiken in der 

Organisation zu etablieren. 

• CMMI impliziert NICHT das Wasserfall- 

Modell; es gibt kein Vorgehen vor. 

• CMMI ist auch für kleine 

Entwicklungsteams anwendbar. 

Der nächste Release von CMMI 

(V1.3, erwartet im November 

2010) wird agile Ansätze 

beinhalten. 


• Scrum definiert einige Prinzipien und 

Praktiken, nicht aber ein Prozessmodell. 

• Die “richtige Menge” an Dokumentation ist 

erforderlich 

• Kunden erinnern sich nicht unbedingt 

daran, was sie gefordert haben: Eine 

gewisse Menge von Dokumentation ist 

hilfreich. 

Ref. http://www.sei.cmu.edu/cmmi/ It is developed by the Software Engineering 

Institute (SEI) of the Carnegie Mellon University. CMMI resp. 

CMMI, CMM, and Capability Maturity Model are registered in the U.S. Patent and 

Trademark Office. 


Agiles Anforderungsmanagement mit CMMI ® Praktiken 

abbilden 

CMMI 

Der Zweck des Anforderungsmanagements (REQM) ist, 

die Anforderungen an Produkte und Produktbestandteile des 

Projekts zu verwalten und Inkonsistenzen zwischen diesen 

Anforderungen und den Plänen und Arbeitsergebnissen des 

Projekts zu erkennen. 


Anforderungen sind mit andere Formen dokumentiert – z.B. 

mit User Stories. 

• SP 1.1 Verständnis über Anforderungen erlangen 

• SP 1.2 Zusagen zu Anforderungen einholen 

• SP 1.1 & 1.2 Der Sprint Plan legt fest, dass die 

Stories mit allen Beteiligten besprochen wurden. 

• SP 1.3 Anforderungsänderungen verwalten 

• SP 1.4 Bidirektionale Nachverfolgbarkeit von 

Anforderungen aufrecht erhalten 

• SP 1.3 Für Änderungen an Stories, welche bereits 

implementiert sind, kann ein Configurations & 

Change Management verwendet werden. 

• SP 1.4 Die Rückverfolgbarkeit von Stories kann 

durch Acceptance Tests dokumentiert werden. 

• SP 1.5 Inkonsistenzen zwischen Projektarbeit und 

Anforderungen erkennen 

• SP 1.5 Sprint Reviews decken Inkonsistenzen auf. 

Unterstützend wirken im Voraus definierte Testfälle 

für die Entwicklung von Codes. 

(SP = Specific Practice) 


Agiles Anforderungsmanagement mit CMMI ® typischen 

Arbeitsergebnissen abbilden 

CMMI: Typische Arbeitsergebnisse für 

Anforderungsentwicklung (Requirements 

Development, RD) 


SG1: Kundenanforderungen entwickeln 

• Kundenanforderungen 

• Kundeneinschränkungen für die 

Durchführung der Verifizierung 

• Kundeneinschränkungen für die 

Durchführung der Validierung 

SG2: Produktanforderungen entwickeln 

• Abgeleitete Anforderungen 

• Produktanforderungen 

• Anforderungen an Produktbestandteile 

• Schnittstellenanforderungen 

(SG = Specific Goal) 

• Product Backlog 

• Stories 

• Acceptance Tests für Stories 

• Sprint Backlog 

• Modelle 

• Rückverfolgbarkeit zwischen Produkt und 

NFR 

• Architecture Stories 


In IEC regulierten Systemen verursachen die Validierung 

und Verifikation lange Entwicklungszyklen 

Empfohlenes Vorgehen für den FDA Design 

Guide 

user needs 

reviews 

design 

input 

design 

process 

You built the right thing 

design 

output 

You built it right 

medical device 

validation 

verification 

Der Design Input wird dem Design Output 

gegenüber gestellt und verifiziert. 

• In herkömmlichen Vorgehen finden 

Verifikation und Validierung nicht während 

sonder nach dem Design statt. 

• Es wird davon ausgegangen, dass die 

Validierung für ein fertiges Produkt durchgeführt 

wird. 

• Kurze Iterationen sind daher schwer zu 

erreichen. 


Design 

Input 

Design Output 

Klassisches IEC Anforderungsmodell 

User Needs 

REQ 

validates 

Validation Test 

TST 

realized by 

Product 

Specifications 

REQ 

verifies 

Verification Test 

TST 

•Performance Req. 

•Safety Req. 

•Environmental Req. 

•Biocompatibility Req. 

•Product Durability 

and Shelf Life Req. 

•… 

realized by 

realized by 

realized by 

Mechanical 


Electrical 


REQ 

REQ 

verifies 

Software Requirement 


REQ 

Functional 

Requirements 

REQ 

constrains 


Requirements 

REQ 


Agile Anforderungen und IEC 62304 

ANSI/AAMI/IEC 62304:2006 

Medical Device Software – Software Process 

Life cycle process 

Software requirements should include 

• functional requirements; 

• physical characteristics 

• performance 

• computing environment. 

• software systems inputs and outputs; 

• data characteristics 

• Ranges & limits 

• Etc.. 

“NOTE 7: All of these 

requirements might not be 

available at the beginning of 

the software development.” 

Agile Anforderungen 

• Stories sind teilweise nicht ausreichend und 

müssen z.B. mit NFR präzisiert werden 

• Entwicklung starten ohne auf vollständige 

Anforderungen zu warten 

• Die Komponenten werden mit den Stories 

validiert 

• Hardware- und Embedded Komponenten 

mit langen Entwicklungszeiten werden 

modelliert 

• Stories werden dokumentiert und ergänzt 

• Rückverfolgbarkeit zwischen Produkt und 

Stories wird sicher gestellt 


Agiles Anforderungsmodell und IEC 62304 

Sprint Development / Design Output 

Use Case 

REQ 

verifies 

Acceptance Test 

TST 


Requirements 

Envision / Design Input 

Backlog Item 

User needs 

REQ 

Models (Electrical, 

Mechanical, 

Software) 

validation of user 

goals & intended 

use by actually 

using the product 

realized by 

REQ 

Story 

REQ 

Sprint Plan 

implemented by 

Task 

Demo & 

Retrospective 

Validation Record 

TST 




Fazit: Man darf! … nach einer Anpassung an Ihre Projekte 

Was können Sie mitnehmen, anpassen und in 

Ihrem Unternehmen implementieren: 

• Sieben Prinzipien für ein agiles Anforderungsmanagement 

– passen Sie sie an und 

wenden Sie sie diszipliniert an 

• Ein agiles Anforderungsmodell 

• Techniken, um den Nutzen in den Vordergrund 

zu stellen 

• Techniken, um Stories zu präzisieren (wenn 

notwendig) 

• Eine Abbildung von agilen Anforderungsmodellen 

für regulierte Projekte 


Referenzen 

Literatur zum Thema Scrum und agile 

Anforderungen 

• Agile Project Management with Scrum by Ken 

Schwaber (Microsoft Press 2004) 

• Agile Software Development with Scrum by 

Ken Schwaber and Mike Beedle (Prentice Hall 

2002) 

• User Stories Applied for Agile Software 

Development by Mike Cohn 

• Implementing Lean Software Development by 

Mary and Tom Poppendieck (Addison Wesley 

2006) 

• Agile Enterprise Requirements Information 

Model – Subset for Agile Project Teams- 2008 

by Dean Leffingwell 

www.scalingsoftwareagility.wordpress.com 

• Implementing Lean Software Development 

(Addison Wesley 2006) by Mary and Tom 

Poppendieck 

• Competitive Engineering: A Handbook For 

Systems Engineering, Requirements 

Engineering, and Software Engineering Using 

Planguage - by Tom Gilb, Aug.2005 

www.gilb.com 

Literatur zum Thema agile Anforderungen 

und Regulation 

• Software Development Resolving the Conflict 

Between Speed and Compliance – by D. 

Jennings, Medical Devices May/June 2009 - 

http://www.devicelink.com/mdt/archive/09/05/0 

08.html 

• Hillel Glazer, Jeff Dalton and other. - CMMI® 

or Agile: Why Not Embrace Both! CMU/SEI- 

2008-TN-003 

http://www.sei.cmu.edu/reports/08tn003.pdf 

• Process Improvement for All: What to Expect 

from CMMI Version 1.3 by M. Phillips, 

S.Shrum – Jan.2010 CrossTalk 

http://www.stsc.hill.af.mil/CrossTalk/2010/01/1001PhillipsS 

hrum.html

Scrum für das Anforderungs-management im regulierten Umfeld

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?