1. FOCUS: lean software development
A Business tomography, oncology, and ultrasound
imaging. It enables more patient exams
in less time and accommodates effi-
Case for Feature-
cient image creation, usage, archiving,
and sharing for sound diagnoses. The
syngo.via product has several thousand
Oriented
requirements translating into millions
of C++ and C# LOC.
Like the rest of the medical device
industry, Syngo faces business chal-
Requirements lenges stemming from industry regu-
lations, which require full compliance
in product development (such as trace-
Engineering
ability and auditability of requirements
changes) to ensure patient safety. In ad-
dition, new market entrants, competi-
tors from the BRIC countries (Brazil,
Russia, India, and China), and IT com-
Arnold Rudorfer, Siemens Healthcare Diagnostics
panies moving into Siemens’ traditional
market space are putting pressure on
Tobias Stenzel and Gerold Herold, Siemens Healthcare
cost and cycle time. Moreover, medi-
cal device functionality is increasingly
being realized in software, as has hap-
pened in other industries such as the
automotive sector.1
// Owing to the growing software content in medical To remain competitive amid these
devices, an adequate requirements engineering approach challenges, Syngo must continually in-
crease productivity. Regarding soft-
is necessary to help meet the challenges of engineering ware development, we hope to lever-
efficiency and cost effectiveness. Feature-Oriented age and adapt the principles of Toyota’s
Requirements Engineering offers such a solution. // lean engineering approach3 to
• create customer value,
• reduce waste, and
• optimize value streams, empow-
erment of teams, and continuous
improvement.
Toward that end, Syngo developed
Feature-Oriented Requirements En-
gineering (FORE), a systematic ap-
Syngo, a Siemens business unit, is syngo.via software is the central proach for organizing requirements
an imaging software and medical de- hub in many healthcare workflows according to marketable, customer-
vice provider with several hundred de- (see Figure 1). With it, developers can oriented features. FORE ensures a
velopers across multiple continents. Its build clinical applications for com- business perspective throughout the
projects are geographically distributed puted tomography, x-ray, magnetic product life cycle and is one of the
to leverage engineering talent, speed, resonance, proton emission tomogra- enablers for product line engineer-
and cost. phy, single-photon emission computed ing. Table 1 illustrates some ways that
30 I E E E S o f t w a r e | p u b l is h e d b y t h e I E E E c o m p u t e r s o c ie t y 0 74 0 -74 5 9 / 12 / $ 3 1. 0 0 © 2 0 12 I E E E

2. FORE is helping Syngo meet require-
ments engineering challenges. Here,
we describe FORE and the business
case we developed for it.
The FoRe approach
A feature model is a hierarchical tree
describing the structure, dependen-
cies, commonalities, and variability of
features in a product or product line
(such as platforms for a medical de-
vice).4,5 A feature, in our nomencla-
ture, is a marketable unit as an aggre-
gation of requirements characterizing
a system’s capability or performance
(such as a reporting feature, movie fea- fIGUre 1. Integrated clinical workflows. Syngo.via software enables more patient exams in
ture, or volume-rendering-technique less time and accommodates efficient image creation, usage, archiving, and sharing for sound
feature). A feature is a mere container diagnoses.
for one or more requirements. In other
words, requirements specify features.
The project phase dictates require- Feature Model Benefits abstraction level (instead of dangling
ments’ levels of detail (for example, Using feature models, we can struc- requirements) and graphical overview
considering market requirements ver- ture product requirements along the of the products’ functionality. They
sus software requirements). customer’s domain, achieving a higher also serve as a basis for proper product
Requirements engineering challenges.
taBle 1
Challenge Solutions introduced
by Feature-Oriented Requirements Engineering
Linkage of product • Tedious scoping sessions with customers, owing • Setting up a business-driven feature model from the customer’s
requirements to to many specifications viewpoint
business drivers • Many technology-driven requirements that have • Supporting agile methodologies by integrating the requirements
no business rationale database and a backlog or a project management tool
• Requirements creep or different entry points for • Central collection and evaluation of stakeholder requests
requirements • Early transformation of stakeholder requests into requirements
Relationship of • Nontransparent relations between the problem • Modeling relations between features and components to enable
problem to solution and solution spaces impact analysis
space • Complex product architecture, implementation, • Modeling product variability and product lines by clustering
and testing requirements to features
• No possibility to reuse requirements and
specifications for different product lines
Very large product • Testing without customer perspective (focusing • Testing self-contained features and use cases
scope to test on components) • Continuous synchronization of up-to-date requirements with
• Inefficient testing owing to a heterogeneous test cases
requirements structure
Reduce engineering • A complex tracing methodology with n:m • New techniques to model cross-cutting concerns that impact
overhead relations (too many traces) various features
• Simplifying tracing methods (structure-based tracing and 1:m
relations)
S E p t E m bE r /o c to bE r 2012 | IEEE S o f t wa r E 31

3. FOCUS: lean software development
Requirements engineering Project and test management
Transformed
info SW feature SW feature
1 2 4
Enhancement Backlog item
Stakeholder
request Sync Tested by
Market req. Grooming and Market req. Test case
Sync incorporation
Mapped to into requirements
SW req. SW req. Test case
Sync
5 6
3 SW req. SW req. Test case
Sync
Architectural
building block
SW req.
Architecture and design
fIGUre 2. Integrating Feature-Oriented Requirements Engineering (FORE) into development. For an explanation of the steps,
see the main article.
line engineering and help manage vari- Architect) and a tool for backlog and product backlog for prioritization
ability and commonality (for example, test management (Microsoft Team and release planning.
defi ning rules about whether a feature Foundation Server). 5. As the assigned software develop-
is mandatory or optional). Further- The following development use case ment Scrum teams further decom-
more, developers can perfectly com- and steps summarize our approach (see pose and groom the backlog items,
bine feature models with lean or agile Figure 2): they incorporate changes on the SW
project management methods (such requirement and design levels.
as Scrum) by fi lling a product backlog 1. Product managers collect, analyze, 6. Both market and SW requirements
with user stories. and decide on stakeholder requests sync to the test management suite to
from various sources, such as end enable tracing to test cases.
Integrating Feature customers or internal stakeholders.
Models into Development 2. If a requirements engineer ac- Introducing FORE and integrat-
Feature models’ seamless integration cepts the stakeholder requests, he ing it in a Scrum-based development
and application into product develop- or she transforms the requests into setup has provided multiple benefits.
ment processes will be key to achiev- completely new software (SW) fea- The strict distinction of stakeholder
ing higher engineering efficiency. At tures or enhancements to existing requests and SW features and their en-
Siemens Healthcare, we’ve integrated features. hancements avoids redundancies and
FORE with the engineering disciplines 3. Together with architects, the require- inconsistencies in product require-
of architecture and design, project ments engineer maps the SW features ments (such as a stakeholder request
management, and test management. to architectural building blocks to that might address an existing feature
We also introduced a tool chain determine complexity and effort. or enhancement). Besides representing
supporting FORE. It consists of a tool 4. Then, the product manager syn- the formal design input of the medical
for requirements engineering, archi- chronizes the enhancements per device, the feature model serves as the
tecture, and design (Sparx Enterprise feature in parallel as items in the primary input source for the product
32 I E E E S o f t w a r E | w w w. c o m p u t E r . o r G / S o f t w a r E

4. backlog and enables Scrum-based
project management. Mapping archi- Type of investment
tectural building blocks to SW features
provides early information about com- Characteristics
plexity and input for subsequent effort
estimations. Moreover, testers always
Costs
get up-to-date requirements that are
ready to be traced to test cases. In this Discounted cash flow:
“As is” process vs. “to be” process
regard, the feature model is the central net present value NPV)
information hub and provides a col-
laboration basis for various processes
Benefits
and disciplines.
Key benefits areas and levers Discounted cash flow: NPV
The Business Case
Although we already had experience
Risk
doing business cases for software process
improvement, FORE’s business case was Determine critical factors: Determine error limit
one of the most difficult to develop. sensitivity analysis for critical factors
This difficulty was due to the nature of
requirements engineering and the many
relations the discipline has with adjoining fIGUre 3. Our business case approach involved four major steps: assessing the type of
engineering workflows. Figure 3 investment, costs, benefits, and risk.
shows the business case approach’s
four major steps: assessing the type of
investment, costs, benefits, and risk. process (the future state—that is, manner for creating test cases. This is
FORE). This way, we could accurately possible owing to a better overview for
Assessing the Type of Investment record the as-is state’s operating costs. test cases. We spend less time on under-
To investigate the investment’s char- Moreover, we could subsequently es- standing the requirements and their as-
acteristics, we fi rst determined five timate preparation and rollout costs. sociated use cases. Additionally, there’s
questions: This included the costs for needed pro- a much earlier consideration of non-
cess changes (methodology and tool- functional requirements such as scal-
• What’s the savings potential with ing), including staff training and orga- ability and performance. An explicit
FORE? nizational change management. modeling attached with an integrated
• What’s FORE’s return on invest- view lets us detect nonfunctional re-
ment (ROI)? Assessing Benefits quirements issues early in the process.
• By when will we recover the To determine the key benefits and levers, We can quickly detect any omission.
investment? we ran a series of workshops with key
• Which engineering areas contribute stakeholders from development (prod- Transparency. This area relates to
most to the business case? uct managers, architects, test managers, the requirements content. A feature
• Finally, what happens if important and project managers). We identified model, owing to its graphical nature,
levers fail? (Levers are critical suc- four key benefits. The fi rst was more provides a quick overview from a cus-
cess factors that will help us realize effective testing and easier bug fi xing. tomer’s perspective on how product
FORE’s benefits.) The second was transparency and easy requirements are structured. Further-
overview of product functionality. The more, we can trace each feature from
We investigated the answers later, when third was reduced product complexity the business need to the customer re-
assessing benefits and risk. through variability modeling, and the quirement. A business-driven feature
fi nal benefit was easier tracing owing to model has the benefits of allowing us
Assessing Costs fewer trace relationships. to more easily defi ne a product release
Next, we determined an “as is” re- and to more quickly understand the re-
quirements engineering process (the Effective testing and easier bug fixing. quirements content.
current state) and defi ned the “to be” One of FORE’s levers is a simplified First, it’s easier to prepare and
S E p t E m bE r /o c to bE r 2012 | IEEE S o f t w a r E 33

5. FOCUS: lean software development
variability modeling. Applying this in
our project helped reduce redundancy
in the product architecture.
Simplified tracing. The feature mod-
el’s tree structure mirrors the vertical
traces from a business need to product
requirements, design, and code. This
Costs and benefits (Euro)
Benefits implicit tracing mechanism is built
Costs when we construct the feature model.
Cumulative benefits So, we have fewer traces to manage and
fewer opportunities to inject tracing er-
rors when we must retrace. Therefore,
rework also decreases.
Benefits analysis. Equipped with the
benefits data, we can calculate the net
Roll out Operative present value (NPV) and the time of
Preparation payback (see Figure 4 for an example).
We used the time-savings-times-salary
Time method to calculate benefits.7 The NPV
in our case was approximately 15 to 20
percent of an annual RD budget. The
fIGUre 4. FORE benefits calculation. The net present value was approximately 15 to 20 time of payback was approximately
percent of an annual RD budget. The time of payback was approximately two years, resulting two years, resulting in an ROI of ap-
in an ROI of approximately 1:3. proximately 1:3.
Another interesting result was the
distribution of the resulting benefits
development release as we select the across the product development dis-
number of features that fit our resource ciplines: product defi nition, project
and time constraints. Second, we can management, design, and testing (see
25% quickly bring product managers up Figure 5). We could conclude that test-
Product
definition to speed when looking at a graphical ing would be the biggest beneficiary of
model (rather than having them parse applying FORE. Furthermore, to un-
45% through many text-only product re- derstand the total set of benefits, we
Testing
quirements descriptions). In the con- had to look holistically at all product
23%
Product text of our product, we needed to deal development disciplines. It was also
management with more than 5,000 requirements. best to continue reviewing and con-
7% The resulting feature model had more fi rming benefits with stakeholders from
Design than 800 features. Industry practitio- all those disciplines. We’d need those
ners report that using graphical mod- stakeholders as champions to roll out
els in requirements engineering helps FORE and to continue reiterating in-
fIGUre 5. The distribution of benefits reduce the time to understand and re- vestment benefits to development staff.
across engineering disciplines. Testing is the view product requirements by 40 per-
biggest beneficiary of applying FORE. cent. 6 In this case, the product struc- Assessing Risk
ture’s transparency helps us determine Finally, we determined how levers
where to zoom in—for example, when behave. Running a sensitivity analy-
conduct scoping sessions to defi ne reviewing a clinical workflow. sis on the key levers with large ben-
a product release. Given the logi- efits showed that the NPV was still
cal decomposition, early on, we can Reduced complexity. We can reduce positive. So, implementing FORE still
defi ne the boundaries for a product product complexity through product made sense.
34 I E E E S o f t w a r E | w w w. c o m p u t E r . o r G / S o f t w a r E

6. F ORE ensures that product re-
aBoUt tHe aUtHors
quirements only get into prod-
uct releases that create cus- aRnoLD RUDoRFeR is the program manager for system platform
tomer value. This avoids unnecessary development at Siemens Healthcare Diagnostics. His research interests
include requirements engineering, organizational change management,
up-front specifications of product re-
software technologies, and business strategy. Rudorfer has an MS in
quirements that won’t be implemented. software engineering and business administration from the University
Thus, engineering effort isn’t wasted. of Technology Graz, Austria. Contact him at arnold.rudorfer@siemens.
The feature model as a central de- com.
velopment artifact helped our devel-
opment organization optimize value
streams in architecture and testing. A ToBiaS STenZeL is a process manager for requirements engineering
key lesson we learned from doing the and product management at Siemens Healthcare. His research interests
requirements engineering- and product management-related topics.
business case is that FORE helps sus-
Stenzel has an MS in computer science from the University of Technol-
tain focus in actual implementation. ogy Munich, Germany. Contact him at tobias.stenzel@siemens.com.
Furthermore, we can develop a busi-
ness case only if we have completely
specified FORE. Changing a key pro-
cess development step requires endur-
ing support from all levels of the or- geRoLD HeRoLD is a program manager for change management
ganization and the involvement of key projects and a process manager for project management at Siemens
Healthcare. His research interests include globally distributed, large
stakeholders.
software development projects from technical and business perspec-
We can take further steps to in- tives. Herold has an MS in computer science and an MS in electrical
crease FORE’s utility through auto- engineering, both from the University of Erlangen-Nürnberg, Germany.
mation. For example, requirements Contact him at gerold.herold@siemens.com.
quality checking via rules in a feature
model would help ensure consistency
and data quality. This would also
help product managers and require-
ments engineers catch requirements
defects early. Furthermore, in product 2010; www.lexjansen.com/pharmasug/2010/
risk management, product risks could ib/ib01.pdf.
3. T. Ohno and N. Bodek, Toyota Production
be linked to requirements in a fea- System: Beyond Large-Scale Production,
ture node. This would help save time Productivity Press, 1988.
in fi nding product risk and the corre- 4. C. Kang and S. Cohen, Feature-Oriented
Domain Analysis (FODA) Feasibility Study,
sponding mitigation. tech. report CMU/SEI-90-TR-021, Software
Eng. Inst., Carnegie Mellon Univ., 1990.
5. B. Berenbach et al., Software Systems Re-
acknowledgments
quirements Engineering, McGraw Hill, 2009. Fill Ad
6. B.A. Berenbach, “Comparison of UML and
We thank Siemens colleagues Christa Schwan- Text Based Requirements Engineering,” Proc.
ninger, Peter Hofman, Klaus Moritzen, Thom- 19th Ann. ACM SIGPLAN Conf. Object-
as Baer, and particularly our master’s student, Oriented Programming, Systems, Languages
Felix Popp, for input, discussion, and reviews. and Applications Conf. (OOPSLA 04), ACM,
We also extend our appreciation to the Syngo 2004, pp. 247–252.
global head of RD, Michael Heinold, for 7. B. Mutschler, N. Zarvic, and M. Reichert, A
providing senior management support to make Survey on Economic-Driven Evaluations of
software development improvement happen. Information Technology, tech. report, Centre
for Telematics and Information Technology,
Univ. Twente, 2007.
References
1. G. Reichart and M. Haneberg, Key Drivers
for a Future System Architecture in Vehicles,
tech. report 2004-21-0025, SAE Int’l, 2004. Selected CS articles and columns
2. C. Smoak, “Medical Device Diagnostic In- are also available for free at
dustry 101,” Proc. PharmaSUG, Pharmaceuti-
cal Industry SAS Users Group, paper 1B01,
http://ComputingNow.computer.org.
S E p t E m bE r /o c to bE r 2012 | IEEE S o f t w a r E 35