Refsq 2011 03 29 V3

Agile Requirements Engineering
in a Large Platform Project:
g j
Challenges, Solutions
and Best Practices
dB tP ti
REFSQ 2011
Essen
March 29, 2011

© Siemens AG 2011. All rights reserved.

Contents

 Goals

 Brief look on Siemens Healthcare

 Business challenges

 Lean Requirements Engineering

 Business case and key take-aways

 Further Information

Page 2 Arnold Rudorfer, Siemens Healthcare I&T SYNGO

Contents

 Goals







Goals
G l

 Disc ss an agile / lean RE
Discuss
approach for medical device
development
 Present challenges,
solutions, benefits using
agile / lean in RE


Contents

 Goals







Siemens Healthcare
THE Integrated Healthcare Company
I t t d H lth C

in-vivo diagnostics (imaging)

X-Ray Computed Magnetic Molecular Ultrasound Oncology
Tomography Resonance Imaging

syngo.via
in-vitro
in vitro diagnostics (laboratory systems)

Immunodiagnostics Nucleid Acid Clinical Chemistry Hematology Urin Lab Automation Near Patient
Testing Analysis Testing


syngo
The C t l I
Th Central Image Hub In Healthcare W kfl
H b I H lth Workflows

More patient exams Sound diagnoses
in less time* in less time*

Efficient i
Effi i t image Smooth and fast
S th d f t
creation, usage, collaboration
archiving,
and sharing

*Results may vary. Data on file.
syngo. It s all about you.
It’s


Example: syngo.mCT Oncology
Oncology Workflow: Tumor Detection, Staging
O l W kfl T D t ti St i

Automated Case Preparation Disease Oriented
Disease-Oriented Reading Multi Modality
Multi-Modality Access

 Automated bone and bloodpool  Preferred layout applied  Image fusion for CT, PET, and
removal  Automated lesion segmentation MR images, etc.
 Automated sorting of images, etc.  Automatic loading of prior exams, etc.

Courtesy of University Hospital of Munich-Grosshadern/ Munich, Germany © Siemens AG 2011. All rights reserved.
syngo.mCT Oncology is cleared in theRudorfer, Siemens Healthcare
Page 8 Arnold U.S. with syngo.PET&CT Oncology. I&T SYNGO

Siemens Healthcare
Development of S l and Employee Numbers
D l t f Sales d E l N b

Sales according to region1)

Germany
9%
Asia & Australia
17%
Europe
(without Germany)
31% 0.90.7 0.9
1.0 1.1

Americas Employees according to region2)
p y g g
43% Germany
23%

Europe
Asia & Australia
(without Germany)
17%
19%
9.7 11.4 11.3

1) 2)
Americas
Basis: FY 2009 acc. To customer locations. Figures worldwide as of Sept. 30, 2009
41%

Contents

 Goals

 Brief look on Siemens and Vector
Healthcare

 Project syngo.via
Business challenges

 Business challengesEngineering
Lean Requirements

 Lean Requirementskey take-aways
Business case and Engineering

 Results Information
Further and Summary



Business Ch ll
B i Challenges

Environment:
En ironment
 Shorten time-to-market
 Cuts in healthcare budgets
 Continuous product innovation

Product development:
Value-orientation
Flexibility
Risk Orientation


Contents

 Goals

Healthcare

Business challenges

Agile / Lean Requirements
Engineering
y y
 Results and Summary


Disclaimer:
The content discussed in this presentation needs
to be considered as work in progress
progress.


Project:
P j t syngo.via Product
i P d t

Project O
P j t Overview
i
syngo.via: Next generation
imaging software for the entire
g g
reading process

Project data:
 > 5,000 single product requirements
 Several million lines of code
C++/C#
 Several hundred developers in
many locations
 Clinical applications for Radiology,
PACS, X-Ray, CT, PET/SPECT,
Oncology, Particle Therapy and MR
can be developed


RE Issues in the Project
Pressing Pain-Points to look at …
P i P i P i t t l k t

 V-model life-cycle does not allow for  Ambiguity and Lack of Accuracy of
flexible adaptations Specifications
 Engineering artifact structure does  High manual effort for traceability
not facilitate market valuation and auditability


Pain point 1 + 2: V-model & Engineering Artifact
Structure
St t

Solutions:
Selected issues to deal with:
 Domain model for imaging A. Feature model
software partially complete
 Scope for release planning difficult B. Value-based ranking of
to define features
 Need to short development C. Incremental requirements
lifecycle – outdated requirements engineering


Solution A F t
S l ti A: Feature Model
M d l

Highest Level Benefits:
 Higher level abstraction of grouping of
requirements into sellable units: From
5,000 product requirements to 800+
features (factor ~ 6)
 Visual domain model for healthcare
workflows (tree & graphical)
 Reduction of (re-) scoping effort by ~
Graphical View
30% (*)
 Reduction in time to understand
aspects of the system
 Hierarchical relationships enable
mapping of stakeholder requests and
visualize dependencies

Hierarchical View

Solution B V l b
S l ti B: Value-based Ranking of Features
d R ki fF t

Characteristics:
 Ranking is used to determine the release
backlog
 Main criteria for ranking are business value,
technical risk and effort

Benefits:
 Only features with the highest business
value (and feasibility) are implemented
 Feature independence assures
parallelization of development
 Simulation of optimal release plan (what-
if analysis)


Solution C: Incremental Requirements
Engineering
E i i

From Feature Model

Characteristics: Benefits:
 High-level features are elaborated  Min 25% reduction of upfront
Min.
when needed – just enough requirement engineering work, just-in-
specification before time (*)
implementation  Elimination of unnecessary hand-offs
hand offs
 Top-ranked features will be refined between development roles
& assigned for implementation  ~ 20% reduction of life-cycle time
(*) Source: MS Team Foundation Server Business Case, May 2010
through concurrent engineering (**)
( )
(**) Source: Experience of agile clinical/ financial information systems projects


Agile / Lean Requirements Engineering
Embedded i th E ti D
E b dd d in the Entire Development Life-cycle
l t Lif l


Process-Adaption:
From V-Model to Agile Development
F V M d l t A il D l t

„Old“ V M d l Process
Old“ V-Model P
D2 D3 D4

Specification Implementation Test System-
+ Plan + Repair test
Design Input

„New“ A il / Lean P
N “ Agile L Process
IT IT
Start Accept End
D2 D3 Commit D4

Plan Implementation Test System-
+ Test + Repair
p + Repair test
Feasibility
F ibilit Design
Input

Readiness Doneness
D


Pain point 3: Ambiguity and Lack of Accuracy of
Specifications
S ifi ti

Level Requts. Manually Manual test
Object Embedded graphs case creation
Issues:
 Textual use case descriptions work only
for smaller projects < ~ 100 Document Requt. 1 Picture / diagram
(text)
requirements
 Natural language subject to Features Requt. 2 Picture / diagram
interpretation, usually inconsistent, (text)
incomplete with inccorrect version (and
p (
conflicting) Paragraph Requt. 3 Picture / diagram
(text)
Root causes:
 T t l requirements engineering d not
Textual i t i i do t
scale for platform projects Solutions:
 Missing versioning
 No direct access to single requirements D.
D Application Use Cases
 Lack of product structure
 Inconsistently executed change
management process


Solution D: Graphical Modeling of Clinical
Workflows
W kfl

C a acte st cs
Characteristics:
 Used to describe clinical workflows that
consist of a collection of steps in a
defined sequence together with
accompanying specification of pre-/post-
conditions, business rules, performance
aspects, etc.

Benefits:

 Increase expressiveness of clinical
workflows t describe d
kfl to d ib dynamic b h i
i behaviors
 Early analysis of stakeholder requests from
customers; joint modeling sessions to
describe th needs f
d ib the d from th customer‘s
the t ‘
point of view
 Reduction of review times due to visual
approach (~ -40%)
40%)


Major Changes - Recap
Lean Requirements Engineering
L R i t E i i

 Feature Model
 Value-based Ranking of Features
 Incremental Requirements
Engineering
 Graphical Modeling of Clinical
Workflows


Some Key Differences: Traditional- and Agile/
Lean R
L Requirements E i
i t Engineering
i

Traditonal Agile
“Lean”
Traditional RE Agile / Lean RE
Specifications are developed upfront Value-based approach; only the top-most
requirments are specified; reduce waste
Text-based requirements specification Comination of user stories and requirements
approach (> 90% of development models (to depict dynamic behaviors of clinical
organization) workflows)
Longer development cycles possible Concurrent engineering for development (Scrum
and feature orientation combined)

Requirements engineering activities only till End-to-end
End to end requirements engineering
„Design Input Complete“ (D3)
Engineering teams detached from clinical Close working relationship of engineering team,
end user product managers and clinical user


Contents

 Goals

Healthcare

Business challenges


Business Case and Key Takeaways

Further and Summary



Business C
B i Case – C t ib ti
Contribution of Levers
fL

Description of Benefit Distribution of
Benefits
Tracing with less effort (based on
g ( 25%
Planning Defnition
Product t

feature model‘s nature, no verticals)
More effective stakeholder management (less scoping
sessions, reduction in review times and effort)
Transparency and easy overview on product functionality 23%
Project
P
P

Reduction of product complexity (transparent modeling of 7%
Design

product lines and product variability)
D

More effective Testing 45%
Test

Easier bug-fixing

Source: OREA Business Case, February 2011

Business C
B i Case – NPV P j ti
Projection

 Benefits are realized across engineering
workflows: Product Definition, Project NPV Projection
Planning, Design and Test
 Break even reached in 2nd year
Break-even
 Hints for other RE practitioners:
 Business case can only be conducted
with a complete technical concept
 Sensitivity analysis on implementation
risks shows that the effort is
worthwhile even if everything goes
wrong.
 Business case will vary depending on
y p g
lccal circumstances

Source: OREA Business Case, February 2011


Key Take-Aways
K T k A

 To mo e from traditional to agile / lean RE approach needs a step
move step-
wise, value-based approach
 Feature orientation brings a focus on what is relevant for the customer
and the pre-condition for concurrent engineering
 The introduction of agile / lean Requirements Engineering is a huge
organizational change management endeavor
 Continuous assessment and verification of business benefits is
necessary t judge what i working and what not
to j d h t is ki d h t t


Thank
Th k you for your attention!
f tt ti !


Contents

 Goals

Healthcare

Business challenges


Business Case and Key Takeaways

Further and Summary



References
R f

 US Food & Drug Administration, Design Control Guidance
for Medical Device Manufacturers; March 11, 1997
 US Food & Drug Administration, Quality System
Regulation,; January 1, 1997,
http://www.fda.org/cdrh/qsr/01qsreg.html
 Beatrice Hwong, Grace Tai, Rajanikanth Tanikella,
Gergana Nikolova, Gilberto Matos, Christopher Nelson,
Bradley Wehrwein, Arnold Rudorfer, Xiping Song, Monica
McKenna: Quality Improvements from Using Agile
Development Methods: Lessons Learned,
e e op e t et ods esso s ea ed,
http://www.51testing.com/ddimg/uploadsoft/20090120/Agile
QualityAssurance.pdf, April 2007
 Brian Berenbach, Daniel Paulish, Arnold Rudorfer,
Juergen Kazmeier, Software Systems Requirements
Engineering; M G
E i i Mc-Graw Hill 2009;
2009
http://www.mhprofessional.com/product.php?isbn=0071605
479
 Arnold Rudorfer, Christof Ebert: Lean Requirements
Engineering in Medical Systems, MedConf 2010 Munich
Systems 2010, Munich,
Germany, October 14, 2010;
http://2010.medconf.de/downloads/abstracts2010/T2_T3_V
1_vector_siemens.pdf
 Arnold Rudorfer, Christof Ebert: Systematisches
Requirements Engineering, QZ, March 2011


Arnold Rudorfer
Director Software Initiative and
Process Improvement
Siemens AG Healthcare Sector

Hartmannstrasse 16
D-91052 Erlangen

Phone: +49 9131 – 82 2299
Fax: +49 9131 – 84 8691
Mobile: +49 174 1537825

E-Mail:
arnold.rudorfer@siemens.com


Refsq 2011 03 29 V3

Recomendados

Recomendados

Más contenido relacionado

Similar a Refsq 2011 03 29 V3

Similar a Refsq 2011 03 29 V3 (20)

Más de Arnold Rudorfer

Más de Arnold Rudorfer (8)

Refsq 2011 03 29 V3