Medical Systems Quality Requirements

Quality Requirements
Engineering for
Medical Systems
MedConf 2011
Munich, 05. October 2011

© 2011 Siemens Healthcare Diagnostics Inc. All rights reserved.
© 2011 Siemens Healthcare Diagnostics Inc. Arnold Rudorfer, Siemens Healthcare Diagnostics, Christof Ebert, Vector Consulting Page 1

Contents
 Goals
 Brief Look on Siemens and Vector
 Business and Environment
 Quality Requirements Engineering
 Results and Summary
 Further Information


Goals

 Provide an overview on quality
requirements engineering challenges
in a medical device project

 Apply quality requirements
engineering for a critical system

 Share experiences how quality
requirements can be successfully
addressed

 Show lessons learned and achieved
benefits


Contents
 Goals


Siemens Healthcare

In vivo diagnostics (imaging)

X-Ray Computed Magnetic Molecular Ultrasound Oncology
Tomography Resonance Imaging

IT Solutions
In vitro diagnostics (laboratory systems)

Immunoassay Molecular Clinical Chemistry Hematology Urinalysis Lab Automation Point of Care


Vector Consulting Services
Your Partner in Achieving Engineering Excellence

 … offers a comprehensive consulting and
training portfolio as well as process tools for Automotive
optimizing product development
 … serves industries such as automotive, Aviation
aviation, IT and telecom, machinery and & Defense
plants, medical, and railway
IT & Telecom
 … is supporting clients on efficiency
improvement, PLM/ALM, functional safety,
CMMI/SPICE, requirements engineering and Machinery
product management & Plants

 … as a group serves companies across the Medical
world, with over 1000 employees and sales of
well over 150 Mio € pa
Railway
 www.vector.com/consulting


Contents
 Goals


Business Challenges

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


Business Challenges

Product:
Safety-critical: Critical for health and
sustainability
(e.g. bodily injuries, wrong treatment)
Security-critical: Critical for
preserving information integrity
(e.g. access to sensitive data)
Mission-critical: Critical for mission
continuity
(e.g. unavailability)
Business-critical: Critical for
business success
(e.g. damage to image)

Critical need for quality
requirements engineering


Contents
 Goals


Quality Requirements Engineering (QRE):
Overview

Quality Requirements (QR)
 A quality requirement describes a qualitative property that a system
or individual component of the system must exhibit. Sometimes
called: non-functional requirements.
 They extend the functional requirements.
 Examples: Availability, maintainability, security, reliability.

Quality Requirements Engineering (QRE)
 The disciplined and systematic approach to elicit, specify, analyze,
prioritize, commit, verify, validate, assure and manage quality
requirements throughout the life-cycle.
 Focus areas: Systems engineering, processes and product life-
cycle


QRE: Focus on Systems engineering,
processes and product life-cycle

Systems
Engineering

Product
Processes
Life-Cycle

Quality Requirements Engineering (QRE) needs to balance
systems perspective and business needs.


Example: Security

Life-Cycle Perspective Life-Cycle
Security requirements
Environmental analysis Incident / risk alerts
Operational threats Failure analysis
Misuse Cases Risk assessment Patch management
System analysis Architectures,
System design components Security assessments
Verification Test scenarios Design for security System test
Security archi- Guidelines, standards Validation
Subsystem analysis tecture design Common criteria System integration
Subsystem design
Verification Security review
Penetration tests
SW Analysis Subsystem test
SW design Test driven Subsystem integration
Verification development
Checklists
Software- / Hardware SW- / HW- test
Implementation and SW- / HW- integration
Verification Code analysis
Security reviews


Example: Security

Systems
Security architecture and design Engineering
 Develop security architecture on system level
 Keep architecture as simple as possible
 Adaptation of existing building blocks is difficult

Implementation
 Create and use proven software components
 Use coding standards, guidelines
 Employ tools for static analysis, fix compiler warning causes

Consider quality requirements as a system property.
Use different means to prevent critical defects.


Example: Security

Systems
Engineering
Security verification:
 Security reviews on all security-relevant artifacts
 Tests and simulations

Security validation:
 Validation tests (completeness, correctness) – can be
handled in context of “normal” validation
 Penetration tests (vulnerabilities) – high manual effort,
requires specific expertise

Strive for detection of potential weaknesses and insufficient
implementation at the earliest possible point of time.


Example: Security

 Example: Simulation / test of a security protocol
Systems
Engineering

Test Cases

Security
Protocol
Test Results
Design
Specification

Simulation / Test


Example: Security

Activity Benefit Processes
Adapt mature development  Security engineering activities are known,
processes to factor in scheduled, and executed within “normal” development.
security engineering.  Security is not treated as add-on.
 Synergies can be exploited.

Elicit security requirements  Assets to be protected are clearly identified.
in the beginning of the  Basis for realization of security.
project.  Test cases for security validation can be deduced.

Review or test every security  Identification of issues at the earliest possible time.
relevant artifact, use analysis  Automated tools increase confidence and reduce effort.
and test tools.

Manage embedded security  Specific embedded security expertise available when necessary.
competencies.
Quality requirements engineering is deeply engrained
in systematic requirements engineering

Large-Scale Medical Device Projects

Project Overview

Several thousand single
product requirements

Several million lines of code

Several hundred developers
in 5+ locations worldwide

Multi-fold clinical applications


Case Study: Embed Quality Requirements
Engineering into an Existing RE process

Selected Issues Solutions

 Feature model
 Difficult mapping of
requirements to existing  Value-based ranking of
platform QR

• Identification of customer  Architecture Model
value Mapping

• Controlling architectural  Quality Tree
complexity

• NFRs difficult to define


Issue 1: Mapping of requirements to
Platform – Solution “Feature Model”

Highest Level
Benefits:
 Higher level abstraction of grouping of
requirements into sellable units: From 5,000
product requirements to 800+ features
(*) Source: Estimates from product managers

(factor ~ 6)
 Visual domain model for healthcare
workflows (tree & graphical)

Graphical View  Reduction of (de-) scoping effort by ~ 30% (*)
 Reduction in time to understand aspects of
the system
 Hierarchical relationships enable mapping of
stakeholder requests and visualize
dependencies
 Basis for introducing variability management

Hierarchical View  Feeds the product backlog


Issue 2: Identification of customer value –
Solution “Forced Ranking”

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)


Issue 3: Controlling – Solution
“Architecture Model Mapping”

F Feature Model Characteristics:
 Identifies links between features and their
F F F
implementation
SWF SWF SWF SWF SWF SWF SWF  Explicit modeling of variability in the architecture

S Architecture Model

Benefits:
SS SS SS

 Architectural decisions motivated by features
C C C C C C and product-line variability
 Enable reduction of architectural complexity

 Support impact analysis for (de-) scoping
sessions
 Early identification of architectural risks

 Improved accuracy of early effort estimates

 Reduction of number of scoping sessions


Issue 4: NFRs difficult to define for
platform – Solution “Quality Tree”

Characteristics:
Example Quality Tree - Extract
 Quality requirements most challenging to
define (subjective, domain-specific)
 Quality Tree provides an effective means
for collecting and prioritizing qualities
 Analysis technique based on business
drivers, key usage scenarios and
international standards

Benefits:
 Identification of key architectural risks to
consider
Example: Learnability
 Transparency of qualities‘ definition to all
 Learning time of an educated physician stakeholders
shall be less than x minutes ...
 Explicit link of business drivers and
platform architecture


Contents
 Goals


Quality Requirements Engineering

Impacts on Requirements
Engineering

 Value orientation 1. Understand valuation of quality
 Global competition requirements
 Cost pressure 2. Consistently prioritize
 Shorter Life-Cycles 3. Address system context
 Reliability
4. Stay agile and lean
 Safety
 Resilience 5. Model quality requirements end-
 Serviceability to-end
 Complexity 6. Systematically build quality
 Auditability 7. Manage knowledge


Results
Quality Requirements Engineering Pays Off

 Improved system availability and
reliability
 Ca. 30% Reduction of review
effort due to early feature reviews
vis-a-vis quality requirements
 Ca. 25% reduction of upfront
requirement engineering work
due to incremental requirements
engineering
 Use of quality tree assures a clear
focus on future customer needs
and elimination of unnecessary
redesigns


Key Take-Aways

 Successful development of critical systems requires a business-driven
requirements engineering approach with specific consideration of quality
requirements

 A value-feature perspective for functional and quality requirements allows
tracing business needs to implementation details

 Introducing a platform concept means to restructure quality requirements
and link them to architecture components

 Continuous assessment and verification of business needs is necessary to
judge priorities of quality requirements

 Consequent quality requirements engineering needs profound organizational
change management to facilitate cross-cutting perspectives, innovative
methodologies and collaboration


Contents
 Goals


Documented Experiences and Best Practices
from various Industry Projects

English language:
Software & Systems
Requirements
Engineering: In Practice
2009
McGrawHill
German language:
Systematisches
Requirements
Engineering
Third edition, 2010
Dpunkt.verlag
Link to web site McGrawHill Link to web site Dpunkt


Arnold Rudorfer
Program Manager Platform
Development
Siemens Healthcare Diagnostics
62 Flanders Bartley Road
Flanders, NJ, 07836

Phone: +1 973 927 28 28
Mobile: +1 609 954 23 84

Email:
arnold.rudorfer@siemens.com


Dr. Christof Ebert
Managing Director
Vector Consulting Services GmbH

Ingersheimerstrasse 24
D-70499 Stuttgart

Phone: +49 711 – 80670-175
Fax: +49 711 – 86070-444

Email:
christof.ebert@vector.com


Medical Systems Quality Requirements

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Similar to Medical Systems Quality Requirements

Similar to Medical Systems Quality Requirements (20)

More from Arnold Rudorfer

More from Arnold Rudorfer (17)

Medical Systems Quality Requirements