Professional Documents
Culture Documents
Systems Engineering: Understand The Problem That Systems Engineering Aims To Solve
Systems Engineering: Understand The Problem That Systems Engineering Aims To Solve
Real-world companies
that benefit from systems
engineering
How to build the right
system with validation
and verification
Ways to generate smarter
products
Systems Engineering
Systems
g
n
i
r
e
e
n
i
g
En
Learn:
What systems engineering is
Go to Dummies.com
Shamieh
ISBN: 9781118100011
Not for resale
n
IBM Limited Editio
Cathleen Shamieh
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
01_9781118100011-ffirs.indd i
5/16/11 11:27 AM
Systems
Engineering
FOR
DUMmIES
Cathleen Shamieh
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
01_9781118100011-ffirs.indd i
5/16/11 11:27 AM
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise,
except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the
prior written permission of the Publisher. Requests to the Publisher for permission should be
addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Trademarks: Wiley, the Wiley Publishing logo, For Dummies, the Dummies Man logo, A Reference
for the Rest of Us!, The Dummies Way, Dummies.com, Making Everything Easier, and related trade
dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the
United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. Wiley Publishing, Inc., is not associated with any
product or vendor mentioned in this book.
LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE
NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES,
INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE.
NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS.
THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT
ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL
PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE
FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS
REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER
INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE
INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT
MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN
THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.
For general information on our other products and services, please contact our
Business Development Department in the U.S. at 317-572-3205. For details on how to
create a custom For Dummies book for your business or organization, contact info@
dummies.biz. For information about licensing the For Dummies brand for products or
services, contact BrandedRights&Licenses@Wiley.com.
ISBN: 978-1-118-10001-1
Manufactured in the United States of America
10 9 8 7 6 5 4 3 2 1
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
01_9781118100011-ffirs.indd ii
5/16/11 11:27 AM
Publishers Acknowledgments
Were proud of this book and of the people who worked on it. For details on how to
create a custom For Dummies book for your business or organization, contact info@
dummies.biz. For details on licensing the For Dummies brand for products or services, contact BrandedRights&Licenses@Wiley.com.
Some of the people who helped bring this book to market include the following:
Acquisitions, Editorial, and
Media Development
Project Editor: Carrie A. Burchfield
Editorial Manager: Rev Mengle
Sr. Acquisitions Editor: Katie Feltman
Business Development Representative:
Sue Blessing
Custom Publishing Project Specialist:
Michael Sullivan
Composition Services
Sr. Project Coordinator: Kristie Rees
Layout and Graphics: Melanee Habig
Proofreader: Jessica Kramer
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
01_9781118100011-ffirs.indd iii
5/16/11 11:27 AM
Contents at a Glance
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Chapter 1: Generating Smarter Products . . . . . . . . . . . . .3
Chapter 2: Taming the Tiger with
Systems Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . .13
Chapter 3: Revolutionizing Requirements . . . . . . . . . . . .23
Chapter 4: Getting Abstract with System Modeling . . .35
Chapter 5: Ensuring Tip-Top Quality . . . . . . . . . . . . . . . .43
Chapter 6: Enabling Large Teams to Collaborate
and Manage Changes . . . . . . . . . . . . . . . . . . . . . . . . . .51
Chapter 7: Ten Ways to Win with
Systems Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . .61
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
02_9781118100011-ftoc.indd iv
5/16/11 11:27 AM
Introduction
mart products are everywhere. They track your packages, control traffic lights, fly aircraft, and guide you to
your destination. Theyre at the heart of the systems and services you use every day from smartphones to smart cars,
to medical systems, and to aerospace and defense systems.
Intelligent, instrumented, and interconnected products are
revolutionizing the way we interact with each other and perform everyday tasks. Through a combination of electronics,
software, sensors, and other hardware, we have the technology to create multifunctional customized products. And with
our unlimited imaginations, we have the potential to define
hundreds of innovative, value-driven, and personalized systems and services.
The real challenge in creating smart products is one of organization: how can we effectively and efficiently integrate a
complex combination of technologies to create an intelligent
system of systems that fulfills its promises and lives up to
its potential? The solution lies with systems engineering.
Systems Engineering For Dummies, IBM Limited Edition,
explains what systems engineering is and how it can help you
harness the complexity inherent in developing smart, connected products. If youre looking for ways to expedite timeto-market, ensure business agility, and deliver high-quality
smart products while cutting costs, Systems Engineering For
Dummies, IBM Limited Edition, is the book for you.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
03_9781118100011-intro.indd 1
5/16/11 11:27 AM
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
03_9781118100011-intro.indd 2
5/16/11 11:27 AM
Chapter 1
Generating Smarter
Products
In This Chapter
Dealing with the demand for intelligent, interconnected systems
Recognizing challenges on the road to success
Shifting gears to encompass a broader landscape
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 3
5/16/11 11:28 AM
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 4
5/16/11 11:28 AM
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 5
5/16/11 11:28 AM
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 6
5/16/11 11:28 AM
Catering to Customers
A sizable chunk of the worlds population consists of experienced users of smart products.
In 2010 alone, roughly 40 million personal navigation devices
were sold throughout the world, and in 2008, over 55 million
people snatched up iPods.
If youre a frequent flyer, you dont fret if the weather turns
ugly during a cross-country flight because you know the airplane youre flying on is equipped with smarts that ensure
your safe passage. Savvy users are well aware of the capabilities of todays smart products and are driving demand for
even smarter ones.
Todays customers are demanding reliable, real-time, interactive products and they want them now! And if youre lucky
(and smart) enough to deliver on time, dont rest yet, because
before you know it, your customers will already be expecting
an upgrade!
By incorporating personalization and integration capabilities into your designs, you create products that cater to the
users individual needs and adapt to the users environment.
Customers want products that promise to make their lives
easier and more enjoyable, yet each of them has a unique way
of getting things done, and a distinct set of values, pet peeves,
and idiosyncrasies. Customers want smart products as easy
to customize as downloading the latest smartphone app!
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 7
5/16/11 11:28 AM
Smart grid
hybrid/electric
vehicle recharging
Emergency services,
vehicle diagnostics,
GPS/location services
Integration of mechanical,
electronic, software, and
electrical engineering
Driver assisted
safety alarms
360degree
surround vision
Hybrid & electric
vehicle control
Predictive collision
avoidance
Software-intensive
subsystems
Intelligent
navigation
Adaptive cruise
control
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 8
5/16/11 11:28 AM
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 9
5/16/11 11:28 AM
10
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 10
5/16/11 11:28 AM
11
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 11
5/16/11 11:28 AM
12
Planning
Requirements
Analysis
Requirements
Design
CAD design
BOM
Development
Integration
and Test
Implementation
Operations
and
Maintenance
Figure 1-2: Sequential product development.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
04_9781118100011-ch01.indd 12
5/16/11 11:28 AM
Chapter 2
ave you ever wondered how NASA successfully managed to develop as complex a system as the Apollo
spacecraft? How disparate teams of design engineers, programmers, third-party manufacturers, and others worked
together to pull off the first manned flight to the moon?
Well, they couldnt have done it without the help of systems engineering.
Systems engineering is an interdisciplinary approach to creating large, complex systems that meet a defined set of business and technical requirements. The aerospace and defense
industries have been using systems engineering for a long
time, and much of what theyve learned is now being applied
in other industries. As transport systems, powergrids, and
telephone and network systems become smarter, you need
space-age methods to build them.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 13
5/16/11 11:28 AM
14
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 14
5/16/11 11:28 AM
15
System
System
System
Systems Engineering
Process
System
Subsystem
Electrical
Component
Subsystem
Software
Component
Mechanical
Component
Subsystem
Software
Component
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 15
5/16/11 11:28 AM
16
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 16
5/16/11 11:28 AM
17
Acceptance
Testing
System
Testing
De
System
Specication
pos
itio
Verifying the
Units/Devices
om
tion
com
n
Detailed
Design
Rec
De
Subsystem
Testing
and
Unit/Device
Testing
gra
and
High-Level
Design
Inte
tion
pos
fini
itio
Concept of
Operations
(ConOps)
Software/Hardware
Development
Implementation
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 17
5/16/11 11:28 AM
18
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 18
5/16/11 11:28 AM
19
Managing Complexity
with Models
Some models are useful, especially when youre working on
a complex engineering project. If you can develop relatively
inexpensive ways of designing, testing, and verifying your
system before you go and build it, you can save yourself a
lot of time and money maybe even your job! One way to
do this is to use models to design and refine your system
throughout the development process.
System models allow you to capture complexity at many different levels, including system-of-systems (also known as
ecosystem), system, subsystem, and component levels. They
enable you to explore the details of each of these levels,
known as levels of abstraction independently and hide or
expose details as appropriate.
Models can take many different forms. At the simplest level
it may just be a simple spreadsheet used to calculate some
empirical system property. One the other hand, it may be a
highly complex, interactive computer simulation.
For instance, say you want to understand how the automotive
system (translation: car) that youre developing captures and
forwards crash impact data to an emergency response system.
You need to explore information about the cars sensors and
how the car interacts with the external system, but you probably dont want to be distracted by extraneous details, such as
wiring diagrams and component placement. The right model
can show you what you need without extra detail.
Models also afford you the following benefits:
They allow you to focus on the relevant information for
the issue at hand, while ensuring consistency throughout
your design.
They capture both the structure (architecture) and
behavior (functionality) of a system, illustrating relationships and interactions between system elements.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 19
5/16/11 11:28 AM
20
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 20
5/16/11 11:28 AM
21
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 21
5/16/11 11:28 AM
22
Driver
Car
Global
Positioning
System
Home
Security
System
Figure 2-3: A simple context diagram for a car.
You use a context diagram to define the boundaries, or context, of your system. In this case, the system is the car, and
it interacts with three actors outside the system: the driver,
the GPS system, and the home security system. An actor is
anything a system interacts with, whether it is a user, another
system, or the environment. You use a context diagram to
scope out the system under consideration.
By defining the system and its actors, you identify significant
relationships, and thus, requirements and interfaces. You can
then begin to map out interface specifications and data flows
between the system and its actors.
Without a context diagram, you may overlook an actor or
two and come up short on your system requirements. For
instance, if you failed to define the home security system as
an actor in your cars ecosystem, your smart car wont be
smart enough to arm your alarm system.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
05_9781118100011-ch02.indd 22
5/16/11 11:28 AM
Chapter 3
Revolutionizing
Requirements
In This Chapter
Acknowledging that change is good
Covering all the requirements bases by including use cases
Cascading requirements through the development process
Analyzing the impacts of change
Getting a grip (on requirements management)
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 23
5/16/11 11:28 AM
24
Embracing a Philosophy
of Change
In this new age of smarter products, you have to be able to
respond quickly to market dynamics, such as changing customer needs, new competitive threats, or the latest regulatory standard. Product developers have also noticed over the
years that requirements should change as your understanding
of the need gets better through the development process. To
the traditional system development process, however, change
is the enemy. So what should you do?
Come up with a new process.
You may be happy to know that others have walked before
you and have established an entirely new requirements engineering process. Consisting of much more than just upfront
analysis and requirements definition, requirements engineering defines a soup-to-nuts process for establishing requirements, tying them in to testing, and facilitating change.
Requirements work best when they are engineered with
change in mind. The philosophy of requirements engineering
is that change is welcome. Change is, in fact, a goal!
Understanding Context
Before you begin to establish an initial set of requirements
for a smart product or system, it pays to take some time to
think about the problem your product is trying to solve. For
instance, if you set out to build a car, its critical that you
understand exactly how it will be used and by whom. Will
the car be used for city driving, highway driving, or racetrack
driving? Does the target market consist primarily of elderly
drivers, young men, or stay-at-home parents? Will the car be
subject to harsh conditions, such as severe cold, salted roads,
extreme heat, mountainous terrain, or high altitudes?
Understanding context is critical to developing systems that
achieve marketing and business goals. By context, we mean
the set of actors (for instance, users, other systems, and the
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 24
5/16/11 11:28 AM
25
environment) with which the system interacts, and how interactions between the system and its actors take place.
Figure 3-1 shows a context diagram for a car with a built-in
navigation system and a remote home security control system
that is intended for use in winter climates. In this diagram, the
car is treated as a black box that interacts with the following
actors: the driver, the GPS system, the home security system,
and the winter environment. Defining context helps you
understand what functionality is required of the system and
what exchanges occur between the system and its actors.
Driver
Car
Home
Security
System
Winter
Environment
Global
Positioning
System
Understanding context also helps ensure that you have considered all the necessary requirements, relationships, and
interfaces before you begin the development process. For
instance, if you omit the winter environment actor for your
car, you may fail to specify requirements for a weather convenience package that includes heavy-duty battery cables
and a protective chassis coating.
At the highest level of abstraction, your system is a black
box that interacts with an external set of actors. If you take
a peek inside that black box, you see a set of interconnected
subsystems (for instance, anti-lock brakes, navigation system,
and so forth) that together make up your system. You can further decompose each subsystem into a set of interconnected
components (and, perhaps, sub-subsystems). At every level of
decomposition (for instance, system, subsystem, component)
within your system, the context shifts.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 25
5/16/11 11:28 AM
26
Driver
Navigation
Subsystem
Global
Positioning
System
Electrical
Subsystem
Figure 3-2: Context changes as you explore different levels within the
system.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 26
5/16/11 11:28 AM
27
System/Subsystem Requirements. These are the requirements that define what the system must be able to do.
They start at a high systems level and are analyzed and
decomposed to produce requirements for lower level
subsystems. They may be expressed in common shall
statements or in more advanced forms such as models
and diagrams.
At each level of abstraction, requirements define what a
system should do and how it should do it, but not how it
should be implemented. With the ever-increasing complexity
of todays smart systems, its nearly impossible for you to nail
down system requirements right from the start. And in a climate, such as consumer electronics, in which change trumps
stability, you really dont want to freeze your requirements
early in the development process.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 27
5/16/11 11:28 AM
28
RenedBy
Requirement:
EcoFriendly
Use cases
Accelerate
Requirement:
Performance
Requirement:
Power
Requirement:
Emissions
Meets ultralow
emission standard
Requirement:
Fuel Efciency
Requirement:
Braking
Requirement:
Acceleration
Veried by
Test case
MaxAcceleration
derived
Reqt
Satised by
Power
Subsystem
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 28
5/16/11 11:28 AM
29
As you can see, the definition of requirements is expanding, as the lines between requirements and design become
blurred, and as the linkages between testing and design
become critical. Your final set of requirements is a combination of the initial high-level system requirements and requirements derived during the design process.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 29
5/16/11 11:28 AM
30
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 30
5/17/11 4:21 PM
31
If you overlook a requirement, you may run into real problems. For instance, you can design the most phenomenal
automobile cup holder in the world, but if you locate it
just below the car stereo so your grande latte blocks the
controls because you failed to relate an allow ample
clearance requirement to your design, youll miss the mark.
Mistakes like this can really cost you.
Juggling Requirements
and Designs
For the airplane collision avoidance example in the previous section, say you select the transponder system design
option. This semi-automated option involves air traffic control
monitoring transponder signals from aircraft in the area. Your
design choice triggers sub-requirements for a transponder
subsystem design and a subsystem test plan.
Youre well into your subsystem design, when you receive a
requirement change request. The new requirement specifies
that the aircraft must be able to independently avoid collisions. Your design choice doesnt satisfy the new requirement, so you must set aside your design choice and begin
working with an alternative design option, the radar system.
Certain changes may produce derived requirements in a subsystem design that propagate back up to the system design.
For instance, cost constraints may limit the choice of a system
component, which may in turn constrain subsystem functionality, impacting the original requirements. In the old days (like
a few years ago!) this change propagation process consumed
many hours or even weeks, as engineers tracked down and
modified the relevant documents and designs residing in
word processing documents, presentation slides and spreadsheets. The introduction of models into the process helps a
lot, as discussed in Chapter 4.
Establish a formal requirements change process so you can
easily understand the impact of changes to your system
design.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 31
5/16/11 11:28 AM
32
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 32
5/16/11 11:28 AM
33
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 33
5/16/11 11:28 AM
34
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
06_9781118100011-ch03.indd 34
5/16/11 11:28 AM
Chapter 4
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
07_9781118100011-ch04.indd 35
5/16/11 11:28 AM
36
Minivan
Structure
Anti-lock
Braking
System (ABS)
Rotor
Anti-Lock
Controller
Traction
Detector
Brake
Modulator
Chassis
Hub
Assembly
Tire
Sensor
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
07_9781118100011-ch04.indd 36
5/16/11 11:28 AM
37
Sensor
Traction
Detector
Brake
Modulator
Anti-Lock Controller
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
07_9781118100011-ch04.indd 37
5/16/11 11:28 AM
38
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
07_9781118100011-ch04.indd 38
5/16/11 11:28 AM
39
Off
start
engine
stop
engine
Operate
Idling
engage
accelerator
when speed = 0
release brake
Accelerating
Braking
engage brake
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
07_9781118100011-ch04.indd 39
5/16/11 11:28 AM
40
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
07_9781118100011-ch04.indd 40
5/16/11 11:28 AM
41
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
07_9781118100011-ch04.indd 41
5/16/11 11:28 AM
42
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
07_9781118100011-ch04.indd 42
5/16/11 11:28 AM
Chapter 5
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
08_9781118100011-ch05.indd 43
5/16/11 11:31 AM
44
Unit testing
Testing at the lowest system level is tightly coupled with the
implementation of your design. You test each hardware or
software component, fix defects, and redo your implementation. For software, this may involve several iterative cycles
of coding, testing, and recoding until youve thoroughly
debugged the software.
After youve addressed known defects, youre ready to verify
that the component satisfies the requirements allocated to it.
Remember when you developed the detailed design of your
system? Well, part of that detailed design phase involved
defining specific component-level requirements and creating
a Unit Verification Plan. Now, you use the test cases defined
in that Unit Verification Plan to verify whether the component
satisfies the allocated requirements. If defects are discovered,
go back to your implementation and fix the defects. After the
components have been thoroughly vetted, they are ready to
be integrated into higher-level assemblies or subsystems.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
08_9781118100011-ch05.indd 44
5/16/11 11:31 AM
45
Subsystem integration
and verification
Fully-verified hardware and software components are ready
to be integrated into modules or subsystems. If youve tested
out the interfaces first, this should proceed fairly smoothly.
The goal of this stage of testing is to ensure that all of the
interfaces between components and assemblies have been
properly implemented and that all subsystem requirements
and constraints have been fulfilled.
Depending on the complexity of your subsystem, you may
need to develop an integration plan that defines the order
in which you integrate lower-level components and subassemblies. Plan your integration so pieces that need to work
together are ready for integration at the same time, if possible. At each integration step, verify the functionality of the
subassembly against the appropriate set of requirements,
using the Subsystem Verification Plan you defined during the
design phase.
Be careful not to ignore the tests you performed to verify
requirements at the component level, since many requirements are cascaded through multiple levels of system decomposition. For instance, if a system requirement specifies that a
display screen should go blank when a user presses a button,
you need to verify that the screen component can blank itself
(component-level test), and you need to verify that pressing
the button triggers the blanking of the screen (subsystemlevel test).
System testing
Through progressive iteration, you integrate, test, and verify
subsystems until you reach the system level (see Figure 5-1).
Each iteration consists of careful, thorough testing with
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
08_9781118100011-ch05.indd 45
5/16/11 11:31 AM
46
subsubsystems
Integration
subsystems
veried
subsystems
Verication
veried
system
If all goes well, youll have a verified system that you can demonstrate to stakeholders. Youre able to prove that all system
requirements have been satisfied, confirming that the system
was built correctly.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
08_9781118100011-ch05.indd 46
5/16/11 11:31 AM
47
designed and implemented perfectly, satisfying all the requirements and then some, but if it doesnt fulfill its intended use,
its bound to be a flop.
Take, for instance, the case of a well-engineered traffic light
control system. Expertly designed to control the sequence of
traffic lights in a large city, this system might fail to meet its
intended purpose to reduce congestion by streamlining the
flow of traffic if no one bothered to study the citys typical traffic patterns and map them to system requirements for
timing sequences.
The goal of system acceptance testing is to validate that the
system fulfills its intended purpose.
During the conceptual phase of your project, you identified
key stakeholder needs, overall system capabilities, usage
scenarios (CONOPS and use cases) and performance measures for system validation. You defined a System Validation
Plan, and, if you were smart, you put it in a safe and didnt
let anyone modify it to accommodate rogue objectives like
skimping on quality to save a buck or two. Your System
Validation Plan is the rock upon which you shall prove that
your system achieves its intended goals.
Conduct system validation with real live users, and measure
performance as defined by your plan, possibly including
customer satisfaction. Validation may require data collection
before, during, and after system deployment. After carefully
documenting system performance, meet with stakeholders,
analyze all the data, and assess project success.
When a system problem is observed during testing, usually
theres a fault in the system that can be corrected by making a
change to the system. Notice, however that the problem could
be something else. If your verification plan or test procedure
is wrong or outdated, then the test may fail due to no fault in
the system. Similarly, if a requirement is wrong, ambiguous or
incomplete (especially an interface requirement), that may be
the source of the problem all the more reason to focus on
getting requirements and test plans correct early in the game.
When verification testing turns up a problem, go back and
check your requirements and design, make the necessary
adjustments, and repeat the testing.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
08_9781118100011-ch05.indd 47
5/16/11 11:31 AM
48
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
08_9781118100011-ch05.indd 48
5/16/11 11:31 AM
49
$7,600/defect
After product
release
$960/defect
During the
QA/testing phase
$240/defect
$80/defect
During the
requirements phase
Figure 5-2: The cost of correcting defects increases dramatically throughout the development process.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
08_9781118100011-ch05.indd 49
5/16/11 11:31 AM
50
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
08_9781118100011-ch05.indd 50
5/16/11 11:31 AM
Chapter 6
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 51
5/16/11 11:31 AM
52
Getting Everyone on
the Same Page
It takes a heck of a lot more than just brilliant engineering
to create a smart product that is successful in the marketplace. Research shows that a third of all produced devices
do not meet performance or functionality requirements,
and that 24 percent of all projects are canceled due to
unrecoverable schedule delays. Many times, the reason for
a catastrophic system failure is not related to the systems
engineering design; rather, it is due to failures of knowledge
or communication.
Its no wonder large systems development efforts suffer from
poor communications. Most large development teams are
widely dispersed across cities, companies, and countries.
Language and cultural barriers make communication difficult,
and time differences often hamper collaboration. Even for
employees within the same company, organizational silos can
impede communication, reduce productivity, and propagate
the blame game.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 52
5/16/11 11:31 AM
53
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 53
5/16/11 11:31 AM
54
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 54
5/16/11 11:31 AM
55
Tracking changes
When engineering a system, critical information is constantly
changing by design. Systems engineering involves (among
other things) iterative design and test processes: You design
your system, develop models, test the models, redesign to fix
defects, and so forth. So youre constantly updating models,
test results, and other information. Requirements can change,
too, as market and business needs evolve.
Traditionally, large engineering teams have relied on textbased documentation as the source of all project-related
information. File cabinets full of requirements documents,
high-level architecture documents, design documents, and
other documents often serve as the foundation for all system
knowledge. But documents are limiting in that they simply
record information and dont easily allow you to change the
information. If you rely solely on documentation, your documents will be obsolete before theyve been approved!
Systems development teams need a consistent, flexible
mechanism for capturing critical information and facilitating
updates while maintaining integrity.
Communicating changes
The traditional method of creating a few dozen critical documents and exchanging information via email just doesnt work
well in the complex development environments of today.
With the number of requirements for complex systems in the
hundreds, or even thousands, relying on e-mail exchange only
results in chaos and confusion.
Systems development teams need a vehicle that facilitates
effective exchanges among distributed team members. A
robust platform for sharing information is the only way to
avoid the problems that result when multiple versions of critical documents are floating around all over the place.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 55
5/16/11 11:31 AM
56
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 56
5/16/11 11:31 AM
57
Reqmts
Publishing
System
Requirements
Data
Models
Models
Driver
Car
Tests
Templates
Global
Positioning
System
Home
Security
System
Test results
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 57
5/16/11 11:31 AM
58
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 58
5/16/11 11:31 AM
59
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 59
5/16/11 11:31 AM
60
Table 6-1
Type of Tool
Requirements Management and
Traceability
Key Capabilities
End-to-end live traceability to
source, mission, and system/
subsystem requirements
Model-based Systems
Model requirements, system funcDevelopment
tionality, realization, trade studies,
execution, and validation
Change and Configuration
Manage collaboration,
Management
change, shared repository, and
configuration
Automated Documentation
Generate requirements, design,
Generation
and specification documents
Integrated Systems and Software Flow-down of requirements and
Engineering
models, embedded development
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
09_9781118100011-ch06.indd 60
5/16/11 11:31 AM
Chapter 7
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
10_9781118100011-ch07.indd 61
5/16/11 11:29 AM
62
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
10_9781118100011-ch07.indd 62
5/16/11 11:29 AM
63
Engineering a Flexible
Business Model
If youre planning to start a new business, or enter a new
market, the smartest thing you can do is develop a flexible
business infrastructure designed to be the poster child of systems engineering. Thats exactly what Atlanta-based Hughes
Telematics, Inc. (HTI) did when it entered the red-hot telematics market several years ago.
HTI saw an opportunity to outrun the veterans in the industry by setting up its business infrastructure in a way that
would allow it to adapt business relationships and service
delivery models quickly. With a flexible process framework
built on open technology, HTI reasoned it would be able to
jump on new service opportunities before the existing telematics providers with their proprietary technology and
rigid business models could react.
HTI designed all of its core business processes including
front office, back office, and operations with one goal in mind:
launching new services quickly. Whats more, to streamline the
development of new services, HTI installed a common systems
development platform and a host of collaboration tools. HTIs
systems development infrastructure enabled it to manage work
products and deliverables, store deliverables in a central repository, facilitate collaboration among globally distributed teams,
maintain version control, and rapidly communicate updates.
With a combination of open systems, flexible processes, and
enhanced collaboration, HTI is able to bring new services to
market in less than 30 days. As the focal point of telematics
continues to shift from the technology itself to innovative services that use vehicle data in new ways, HTI is, indeed, wellpositioned to win the race.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
10_9781118100011-ch07.indd 63
5/16/11 11:29 AM
64
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
10_9781118100011-ch07.indd 64
5/16/11 11:29 AM
65
The organization deployed a unified requirements management solution designed to support requirements analysis
throughout the company. By providing ubiquitous access to a
centralized requirements repository, the solution eliminates
confusion, costly rework, and duplication of effort. Most
importantly, the solution facilitates end-to-end requirements
traceability ensuring that the product rolling out the door
fulfills the customers needs.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
10_9781118100011-ch07.indd 65
5/16/11 11:29 AM
66
Streamlining Development
with Collaboration Tools
Companies that develop complex, intelligent, highly instrumented products know that success depends as much on
managing the technical work as it does on superior engineering. Without a system-level discipline coordinating the efforts
of diverse engineering groups, complex products are destined
to become newsworthy failures.
When General Motors (GM) set out to design the Chevy Volt,
it put a tremendous effort into establishing best practices
for systems engineering. GM examined both its development
practices and its technical work management practices with
an eye to improving both.
Traditionally, GM systems engineers spent the majority
of their time checking on developers workloads and
making sure that everyone had the same version of requirements and other documents. To free up the engineers to
focus more on functionality and quality, GM decided to
deploy a commercial tool to coordinate development teams
and manage a single version of requirements and other
documentation.
GM then deployed model-driven systems development practices to help manage complexity (the Volt runs on about 10
million lines of code). GM developers used models to visualize
the interactions between embedded systems and ran simulations in order to test the models.
The combination of collaboration tools and model-driven
systems development really paid off: GM completed the Volts
development in just 29 months a record for GM, where new
car development typically takes five years or more.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
10_9781118100011-ch07.indd 66
5/16/11 11:29 AM
67
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
10_9781118100011-ch07.indd 67
5/16/11 11:29 AM
68
Sharing Requirements to
Save Time and Money
Its common for large development organizations to have
two or more geographically dispersed development teams
working on parallel releases with shared requirements. A lot
of time and effort could be saved if these teams had a mechanism for sharing requirements.
A Michigan-based company is a leading global supplier of
mobile electronics and transportation systems. One of the
companys goals was to improve communication among its
global development teams so they would be more productive
as they worked on parallel releases with shared requirements.
Implementing a requirements management tool made it easy
for the companys developers to share requirements. They
can import requirements from a repository to re-use in a new
project, avoiding unnecessary duplication of effort, saving
time, and reducing development costs. Because the requirements management tool promotes consistency and enhances
collaboration, the company is able to deliver higher quality
products in a shorter amount of time.
These materials are the copyright of Wiley Publishing, Inc. and any
dissemination, distribution, or unauthorized use is strictly prohibited.
10_9781118100011-ch07.indd 68
5/16/11 11:29 AM