Visure Solutions Keynote06222009 V3

Requirements Engineering at a Large Scale
The Requirements Week, El Arte de navegar con requisitos

Copyright © Siemens AG 2009. All rights reserved.

Table f C t t
T bl of Contents

 Goals of this talk
 Industrial requirements engineering challenges
 Project setting: Public address and information system
 Challenges and lessons learned
C
 Key success factors in large scale RE projects
 Q&A
 Curriculum vitae
 References

Page 2 Arnold Rudorfer, Siemens Healthcare Siemens Healthcare

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

Healthcare IT
in-vitro diagnostics (l b t
i it di ti (laboratory systems)
t )

Immunodiagnostics Nucleid Acid Clinical Chemistry Hematology Urinalysis Lab Automation Near Patient
Testing Testing


Siemens Healthcare
Global
Gl b l presence

Llanberis Sudbury
 DX  DX
Hoffman Estates Marburg
(Chicago) Dublin Oxford  DX
 MI  DX  MR, MI
Piscataway Erlangen/Forchheim
 AX, RS  AX, SP, CT, MR, A, RS
Elkhart  AU Seoul
 DX New Jersey  HS, CV, RV, IKM, CS  US
 DX Kemnath
Deerfield Flanders Kyongju-si
Issaquah  DX  CV  US
 US  DX Wales
Tarrytown Rudolstadt
 DX
Concord  DX  RV Suzhou
 OCS Malvern Heidelberg A
 HS  OCS Wuxi
Los Angeles Walpole Madrid
 DX Cary Goa  RV
 CS  DX  SP Shanghai
 CV
Mountain View  CT, AX, CV
 US Shenzhen
Knoxville  MR
 MI Bangalore Indonesia
 HS, IKM A
Divisions/Headquarters
q Singapore
Major manufacturing sites A

~49,000 employees worldwide


Siemens Healthcare
Development of sales and employee numbers
D l t f l d l b

Sales according to region
Germany
y
9%

Europe
Asia (without Germany)
17% %
31%

Employees according to region1)

Americas Germany Europe
43% 23% (without Germany)
17%

Asia Americas
17% 43%

1) Employees worldwide as of Sept. 30, 2008


IKM:
IKM syngo


Requirements Engineering Global Technology Field (RE GTF)

Excellence in RE is determinant for Siemens’
Global Competitiveness. A l
Gl b l C titi large majority of
j it f Princeton Beijing

businesses are challenged by: 2004/8
CoC Europe

CoC Americas

 Embedded software content strongly 2003 CoC China
2007
CoC India

increasing in complex systems (e.g. medical
2009

engineering, power generation systems)
Munich Erlangen

 RE i a k di i li f Si
is key discipline for Siemens b i a
being
Bangalore
g

technology trendsetter
The RE GTF is a group of key
 Increased speed-to-market is a must e.g.
p g experts and provides best-practice,
75% of products sold in e.g. medical Siemens-specific and high
engineering are less 3 years old productivity technology assets
(approach, methods, techniques/
 Ad
Advanced RE t h l i are needed t
d technologies d d to tools) to master challenges and
manage complexity of mechatronics make sure that projects are
systems delivered with success.


Requirements Engineering Global Technology
Field T h l
Fi ld Technology Areas
A

RE
Reference
Approach
A h

RE
RE
Awareness
Methods
& Skills RE
Excellence

RE
RE
Improvement
Tooling
Framework


Goals f thi T lk
G l of this Talk

 Share some experiences and lessons learned from large scale RE
projects
 Outline key success factors necessary for delivering successful
projects in complex environments


Industrial R
I d t i l Requirements Engineering Challenges
i t E i i Ch ll

Challenges Business Impact
RE basics not well understood High likelihood of project failure
and executed  Quality of single requirements not sufficient, unrealistic product scope
 Increased rework (> 50% project effort)
Lack f d
L k of end-to-end upstream/
d / Mismatch with market needs
Mi h ih k d
downstream integration  Difficult to manage system development from a portfolio perspective;
 Process interfaces well integrated
 Prioritization of features across products error prone
 T i is labor intensive and difficult to manage
Tracing i l b i t i d diffi lt t
 Requirements do not support business goals
Lack of productive/ scalable Lowered development staff productivity, high injection rate of RE
requirements methods
q defects
 Inefficient modeling and analysis of product requirements
 Roadblock for automating development tasks
Distributed teams interact Product requirements mismatch with market expectations
inefficiently  Requirements difficult to communicate/ interpret
 Missing tool integration leads to work errors, lowered productivity
Benefits of reuse not realized Product-line/ platform efforts are challenged
 Existing requirements need to be redefined
 No reuse of architectural, testing and coding artifacts

Project Setting: Public Address Information
System f a L
S t for Large City Somewhere in the World
Cit S h i th W ld

3/2007 7/2007 11/2008 Time

Specification set Specification set Specification set
#1 approved #2 approved #3 approved

Project description:
Deliverables:
•Project value: 160 million $ •9 system requirements specifications
•80 staff project team 6 full time requirements engineers
team, full-time •RE M
RE Management Pl
Plan
to deal with 4,000 contract requirements •Traceability reporting tool for project manager
•Project work in 4 different countries/ continents

Project objectives: Unique Value Add:

•To develop high quality system requirements •Approved specifications enable development team to

specifications streamline system development

• Refining requirements engineering approach (process, •Dramatic business risk reduction of not delivering the

methods, tools)
) project on time


Challenges Faced in Projects
Ch ll F di P j t

 C1.
C1 Large number of customer
requirements
 C2. Formal interface to customer
 C3. Management of customer
expectations
 C4. Changing technologies
 C5. Distributed teams
 C6. Traceability
 C7. Scope change and creep
 C8. Resource fluctuation


Requirements Development

Lesson 1: D
L 1 Develop a well-structured feature list
l ll t t df t li t

 Challenges:
C1. Large number of customer requirements
C1 L b f i
C5. Distributed teams

 Lesson learned:
 Feature lists often frozen for planning, budgeting, staffing, etc.
 Changes to a feature list late in the development lifecycle are
expensive
 Changes require approval by customer, rework of documentation,
updated tracing, etc.
 Time and effort needs to be spent to create a well-structured feature list
 U d t di the feature complexities and interdependencies i
Understanding th f t l iti di t d d i is
important
 Several iterations should be conducted
 Features should be arranged in a domain-logical hierarchy

Lesson 2: Obtain a good understanding of
customer requirements
t i t

 Challenges:
C1. Large number of customer requirements
C1 L b f t i t
C2. Formal interface to customer
C3. Management of customer expectations
g p
C7. Scope change and creep

 Lesson learned:
 Large number of customer requirements; customer often did not have
proper understanding
 Customer requirements need to be clarified early in the development
process
 Concepts of operation
 Prototypes
 Management of customer expectations crucial
 Cl if what t expect f
Clarify h t to t from a prototype
t t


Lesson 3: U specification approaches that scale
L 3 Use ifi ti h th t l

 Challenges:
C1.
C Large number of customer requirements
f

 Lesson learned:
 "shall" statements are insufficient for capturing system requirements
of complex software systems
 Grey box use cases have proven to be successful
 White box on the system level
 Black box on subsystem level
 Approach g
pp greatly increased readability and manageability of
y y g y
requirements specifications
 Validated by feedback from customer and software validation test
team

Lesson 4: Separate requirements and design
decisions
d i i

 Challenges:
C4. Changing technology

 Lesson learned:
L l d
 Requirements engineering is a wicked problem
 Creation of a solution affects perception of problem
 Requirements keep changing as solutions are prototyped and shown
to the customer
 Cost of change to requirements should be minimized
 Reduce number of avoidable changes to requirements by removing
unnecessary d i d t il
design details
 Technology of solutions is changing
 Tradeoff between abstraction and detail

Requirements Management

Lesson 5: E t bli h a traceability model
L 5 Establish t bilit d l
 Challenges:
C6.
C6 Traceability
C7. Scope change and creep

 Lesson learned:
 Ad-hoc tracing is of low quality and requires significant rework
 Tracing should be done with a purpose
 Artifacts to be traced, tracing granularity, tool support, people
responsible, etc.
 Establishing traceability model early
 Enables project members to understand the tracing strategy and
their responsibilities
 SSupports impact analysis, progress t ki
t i t l i tracking, t ti
testing, and
d
budgeting
 Traceability model needs to be properly documented and
communicated
i t d

Lesson 6: Define a traceability measurement
process

 Challenges:
C6. T
C6 Traceability
bili

 Lesson learned:
 Traceability measurement process enables
tracking of tracing progress
 M Meaningful measurement objectives and corresponding measures
i f l t bj ti d di
need to be defined
 Automation important for facilitating collection p
p g process
 In our experience, collecting on a weekly basis and assigning action
items on a bi-weekly basis works best
 The best frequency of measurements was determined in small
pilot project
 Adjustments were made as the project progressed



Lesson 7: P
L 7 Provide project status visualizations
id j t t t i li ti

 Challenges:
C5 Di t ib t d t
C6. Traceability

 Lesson learned:
 Visualizations communicate project
status to team members and
t t t t b d
management
 Project status can be visualized
using a dashboard or other project-
specific visualization
 Should be posted in a communal
area
 Resulted in considerable increase
in tracing quality
q alit

Lesson 8: Establish effective documentation
standards and review processes
t d d d i

 Challenges:
C5. Di ib d
C5 Distributed teams
C8. Resource fluctuation

 Lesson learned:
 Establishment of documentation standards important
 Enable consistency of work products
 Industrial standards, e.g., IEEE 830, can be used as a starting
point
 Document templates facilitate enforcing documentation standards
 Documentation standards facilitate the review of work products
 QA manager needs to have authority to ensure that review
process is followed


Key Success F t
K S Factors in Large Scale RE Projects
i L S l P j t

1.
1 Subject matter experts are available as needed
2. The customer is properly managed
3. A qualified full-time architect manages nonfunctional requirements
4. Requirements elicitation starts with marketing and sales
5. An effective requirements management process is in place
6. Requirements reviews are conducted for all new draft requirements
and for all changed requirements or features
7. Requirements engineers are trained and experienced
8. Requirements p
q processes are pproven and scalable
9. Progress and quality indicators are defined
10. The tools increase productivity and quality


¿Preguntas?
P t ?


Our d
O documented experience of about 5 years …
t d i f b t

1.Introduction
1 Introduction
2.Requirements Engineering artifact
modeling
3.Eliciting
3 Eliciting requirements
4.Requirements modeling
5.Quality attribute requirements
6.Requirements management
7.Requirements driven testing
8.Rapid development techniques for
requirements evolution
9.Distributed requirements engineering
10.Hazard analysis and threat modeling
y g
11.Conclusions

Link to web site McGrawHill


References
R f

1. Rudorfer,
1 Rudorfer Arnold; Berenbach Brian: Requirements Engineering Global
Berenbach,
Technology Field Description, SCR, 2009
2. Brian Berenbach, Dan Paulish, Juergen Kazmeier, Arnold Rudorfer: Software
Systems Requirements Engineering in Practice, McGraw Hill 2009
S G
3. Sascha Konrad, Michael Gall: Requirements Engineering in Large Scale
Systems, RE’08, Barcelona, Spain
4. Manfred Broy, Eva Geisberger, Juergen Kazmeier, Arnold Rudorfer, Klaus
Beetz: Ein Requirements Engineering Referenzmodell, Informatikspektrum
03/04-2007
5. Achatz, R., Berenbach, B., Broy, M., Kazmeier, J., Ros, J., Rudorfer, A.,
Subramanyan, R.: Requirements Engineering: A Key to Business Success
for Siemens. Siemens Corporate Research (SCR) Technical Report March
Siemens Report,
2006.


Curriculum Vitae Arnold Rudorfer
C i l Vit A ld R d f

Head Software Engineering Process
Group

Siemens Healthcare Imaging&IT
S &
Image and Knowledge Management

Tel.: +49 9131 84 22 99
Cell: +49 174 1537-825

Email: arnold.rudorfer@siemens.com


Curriculum Vitae A
C i l Vit Arnold R d f (
ld Rudorfer (cont.’d)
t ’d)

1994 -1996
1996 European Software Institute, Managing Director’s Personal
Director s
Assistant, Project Engineer

1996 – 1998 Institutet foer Verkstadeknisk, Center for Software
Engineering, Project Leader

1998 – 2000 Meta4 N.V., Manager User Interface Design and Usability
Engineering

2000 – 2004 Siemens Corporate Research, Manager User Interface
Design Center
D i C t

2004 – 2009 Siemens Corporate Research, Requirements Engineering
Global Technology Field Leader

2009 till today Siemens Healthcare, Head Software Engineering Process
Group


End


Visure Solutions Keynote06222009 V3

Recommended

Recommended

More Related Content

More from Arnold Rudorfer

More from Arnold Rudorfer (19)

Visure Solutions Keynote06222009 V3