Course EMIS 8390: Systems Engineering Tools--applying
tools to engineering systems
Course Description:
Computerized tools perform the vital function of capturing and delivering Systems Engineering
information throughout the product development life cycle--with today most information being captured in
Word™, Excel™, and Powerpoint™. This course moves beyond those basic tools to survey the many
tools that are applied to engineering systems across the entire life cycle from inception to disposal. The
course starts at the beginning by applying tools on scope/needs evaluation, moving into requirements
analysis, down to functional and physical allocation, into optimization, wrapping up with test
validation/verification and product management. Since best-of-breed systems engineering tools will be
available to use during this course, students will identify and apply tools as they move through the life
cycle of a product they develop--the end result is an understanding of what tools, methodologies, and
techniques can be applied, to what part of the process, and how they are applied.
Course Objectives:
Whole courses are taught on individual topics and process steps described below. Given the breadth of
the course, the goal is not to dive into the details of those topics but rather explore how tools are applied.
Tools described in this course include methods, techniques, and computerized tools. Since many
different tools apply throughout the product life cycle, the goal is to provide an understanding of what
tools apply, how to apply them to systems engineering problems, as well as when to apply them. As a
result, students will leave this course with a "tool kit" of Systems Engineering tools that can be applied to
engineering systems in their ongoing course work and every-day jobs.




Tools include methods, techniques, and automated tools. Course includes exposing students to
a variety of tools through hands on use and tool application demonstrations.
Understanding of what tools to apply and how to apply them to systems engineering problems.
Since the same tools are used throughout the life cycle--know when to use them.
Leave the course with a tool kit that can be applied through out your systems engineering career
(rather than applying a hammer to everything…)
During my days in systems engineering tool support, I received a call from one systems engineer
informing me that he had run out of cells in his spreadsheet and wanted to know how to get more cells for
his analysis. Having never heard of anyone ever running out of cells in a spreadsheet, I had to see what
he was doing…he was using his spreadsheet to hold coordinate information from a flight test and using
the plotting package to find anomalies in the data…
What's needed for the course:
During this tools applications course we will have a number of systems engineering tools available for use
on class assignments. EDS/UGS is contributing their web-based Teamcenter collaboration environment
for students use. The Teamcenter suite includes systems engineering, requirements management, and
groupware collaboration features that will help students apply what they learn through the use of tools.
Although there are other tools (available to students or otherwise), Teamcenter is available via the
Internet making distribution and application very easy for remote students. To take advantage of the
tools, it is required to have access to the Internet for homework assignments and very helpful during
class. As such, we recommend each team have access to a laptop(s) during class sessions (Internet
access will be available in class).
In addition, you will notice sprinkled throughout the course outline are a number of tool demonstrations
and application discussions. We have lined up a number of systems engineering tools for in class
demonstrations. Some of the tools will be available for you to use others will not. The point is to expose
you to a number of these tools that can be very useful to you as a systems engineer.
Text book:
Since there are no standard references to the wide range of systems engineering tools that will be
covered during this course, we will use standard process documentation that is oriented towards use of
tools. The INCOSE Systems Engineering Handbook Version 2a (available at http://www.incose.org at no
charge for INCOSE members for electronic form
(http://66.34.135.97/membersonly2004/sehandbook/se_hdbk_v2.pdf). For non-members, it is available
for order via the INCOSE site (although we suggest you buy a $10 student membership which gives you
access to the handbook).
The Handbook includes descriptions about each step of the systems engineering process, what inputs
are required, what outputs are delivered, along with descriptions of tools that can be used to address that
step in the process. Throughout the course materials you will notice SE Handbook cross-references (.i.e.
[SE Handbook 4.x]).
Grading:
 Tool Contributions (10%)…contribution of tools that can be applied to SE (a 5-10 minute
presentation on a systems engineering tool, method, or application to educate other class
members). Each student will deliver two of these during the course. Tools are credited that are
not already in the INCOSE general tools database (http://www.incose.org/tools). The instructor
will deliver an example of this during the first class.
 Tool application case studies (10%)…real-world examples of SE problems and how tools could
be used to address them (a 1-2 page summary with a brief presentation on the subject). Each
student will deliver one of these during the course. The instructor will deliver an example of this
during the first class.
 Tool applications paper & presentation (30%) Applying tools to your job (a standard term paper
describing a tool application in your job, hobby, social life,…).
 Tools project (40%) working as a team with tools towards a defined objective (includes
assignment specs, trade studies, and a presentation/debrief about what the tools did/did not do to
assist in this process). During the first class, teams will define a simple problem they wish to
address (for example--a product they want to redesign, a new product idea, or current job related
issue to resolve). This problem will be used throughout the course, with each class building on
the previous one to walk through the systems development process supported by SE tools.
 Final Exam (10%)
The course is divided into five, full-day classes with each level-1 section being covered during that class
(section 1 covered during the 1st class, section 2 covered during the 2 nd, and so on)
1 Class 1: Before requirements…
Define the problem before you solve it
We start with a review of the systems development process to set the context for how we will apply tools
throughout the course…
1.1 Review of the Systems Engineering Process
…as defined by [Lacy 1992] and the SE Handbook 4.x [2004]
1.1.1 Problem Definition
(including requirements extraction, constraints, scope, environment, success criteria…)
Tools are used to capture the problem you are going to solve, what are the constraints, what
are the external influencing factors, and how you know when you've arrived.
1.1.2 Functional Analysis
(functional decomposition, sequence of events, interfaces…)
Tools are used to capture and analyze the functions to be performed by the system
1.1.3 Systems Synthesis
(alternative development, configure components,…)
Since there are an infinite number of possible solutions to a problem, tools are used to identify
the constraints, and evaluate the alternatives that best meet the objectives
1.1.4 Systems Analysis
(evaluate alternatives, choose solutions, optimization, sensitivity,…)
Tools are used to evaluate solutions and how robust those solutions are to changing criteria.
1.1.5 Decomposition
(decompose requirements/functions, allocate requirements, decompose interfaces, …)
Since very few systems are "single-layer", tools help capture and decompose the system layerby-layer as you work down through to the details)
1.1.6 Verification/Validation
Validate the correct set of requirements have been developed and verify they have been met
Tools are used to capture, track, and document V&V efforts
It is not uncommon for SE's to be confused about tools, putting the tools into a process context will
help clarify which tools fit were. [Armstrong 1993] wrote an excellent article on the subject of slotting
tools/methodologies that will let us balance what we visit during this course.
The INCOSE Tools Database Working Group has also spent of lot of time organizing tool information
for us. We will utilize that resource INCOSE Systems Engineering Tools Database
(http://www.incose.org/tools). We will visit and review some of their work. Being good SE citizens
we will add tools to the INCOSE general tools database, present the tools in class, and provide an
example of how it is applied.
With the process set, let's introduce the standard toolset to be used during this course…
1.2 Standard tools…
Let's start with a review of the standard tools you are currently using, including…
1.2.1 Word
1.2.2 Excel
1.2.3 Powerpoint
1.2.4 Databases
1.2.5 Yellow Sticky Notes
Computerized and non-computerized (paper) notes are available.
 3M Postit® Notes
 Electronic version of 3M Postit® Notes
1.2.6 Training on our class SE environment
UGS PLM Solutions, Teamcenter Requirements environment is available to be used during this
and other courses. TcR is the starting member of the Teamcenter life-cycle support
environment that provides a web-based tool kit for systems engineering/requirements
engineering. We chose it because 1) it's freely available to students thanks to EDS/UGS, 2) it
installs and works over the web, and 3) it has a very short learning curve. Students can also
use other tools they have available to them including standard Word, Excel, etc. (it's assumed
students already know about these and have access to them).
1.2.6.1 Configuration requirements
Teamcenter Requirements and Community connect existing desktop tools to a multi-user,
distributed database to create a collaborative systems engineering environment. For
example, when users double click on a requirement, Teamcenter Requirements launches
Word to edit the requirement. Exit/Saving the Word file places the requirement back in the
requirements database. To run Teamcenter requires:



Standard PC running MS Windows 2000, Windows XP
MS Office 2000, XP, 2003 (preferred)
Web access with a standard web browser (MS Internet Explorer 5.5+
recommended)
During the first class we will take a few minutes to set up team web clients and work
through any firewall or proxy issues to access the class Teamcenter server.
Once installed, we will walk through the Teamcenter feature set…
1.2.6.2 Teamcenter Requirements
Requirements/Systems Engineering (TcR Tool Demo/Training)
1.2.6.3 Teamcenter Community
Requirements Collaboration (TcC Tool Demo/Training)
1.3 Scope statements
The course will use a problem throughout the various classes to teach tool application. Teams will
define a simple need they want to address and develop a scope statement to establish a foundation
on which to build requirements (we will use the scope statement outline suggested by [Hooks &
Farry 2001] in their book: Customer Centered Products).
During this first class (given there are no assignments due) we will review/critique each stage of our
initial scope statement development during the first class with the class.
1.3.1 Establish Teams
Establish an agreed to method of communicating, capturing/collaborating
1.3.2 Define needs, goals, & objectives
Start systems database with high level need and start applying tools [SE Handbook 4.1]:
 Brainstorming with sticky notes
1.3.3 Identify Stakeholders
1.3.4 Identify Drivers & Constraints
1.3.5 Develop an operational concept (use cases, scenarios, …)
Capturing concepts in story boards, IDEF OV1's, Powerpoint…
TRIZ, Brainstorming, Delphi,… (TRIZ Demo/presentation by SDI)
Use Cases and Actors…
1.3.6 Define external interfaces
Capturing interfaces for future reference
Context diagrams,…
Applications Study: Ford Explorer Tire Recall
Upon completion of his first automobile in his workshop, Henry Ford was amazed to discover it
didn't fit through the door (Henry Ford, p.30, A. Knopf, 1966)
…or a more recent example from the news…
May 20, 2001--Ford Motor Co. is recalling 50,000 brand new Explorers because an assembly line
conveyor belt that was too narrow for the wider 2002 model may have cut the tire tread
(http://abcnews.go.com/sections/us/DailyNews/tires_recall_wire010520.html)
1.4 Assignments for next class
1.4.1 Deliver Scope statement
Scope statement includes the above developed using the tools introduced in 1.2
1.4.2 Present results
1.4.3 Tool Applications Case Study
1-2 page brief on a systems problem and how it could be addressed by systems engineering
tools. Brief is delivered in presentation form.
1.4.4 Tool contribution
Tool (defined generically as any method, computerized tool, technique, etc.) contribution is brief
presentation on a tool germane to systems engineering. The point is to educate your fellow
students (and instructor) on the tool
2 Class 2: Requirements
Define what "it" is
Assignments from prior class:
 Deliver Tool Application Case Studies
 Scope Statement Review with Class
 Tool Contribution presentations
2.1 Requirements elicitation
Extracting requirements from stakeholders
2.1.1 Surveys
Surveying tools, forms, interviews, focus groups,…
JAD, Delphi
2.1.2 Regulations/Standards
Regulatory/Standards Databases (Information Handling Systems Demo/presentation)
2.1.3 Scenario Generators/Environmental Simulators
TAC, EWSG,…
2.1.4 Data mining
Data analysis/reduction (Matlab, Probe, PV-Wave, …) (Matlab Data Analysis
Demo/Presentation)
Root cause analysis, fish boning…
2.2 Requirements definition
2.2.1 Requirements analysis tools
Automated extraction (parsing/identification)
Consistency checkers/convolvers
Completeness checking
2.2.2 Rationale capture
2.2.3 Requirement Prioritization
2.2.3.1 Weighting/Sensitivity
Priority classes
Stake-holder input
Kano diagrams for needs identification
2.2.3.2 QFD
House of Quality (QFD Tool Demonstration by SDI)
2.2.3.3 Decision Trees
Decision trees, pair-wise techniques
Statistical techniques (Bayesian trees)
2.3 Requirements organization techniques
…driven by what you expect to get out of the tool (output to documents, trace matrices, etc.)
…organized to make it easier to find them later (impact, get your hands on them, etc.)
2.3.1 Word processors
Using Word Processors as requirements databases (cross references, et. al)
2.3.2 Databases
Directory structures
Attributes/properties
Sub-typing
2.3.3 Spreadsheets
2.4 Requirements allocation
2.4.1 Deriving, Decomposition, and Linking
Requirement leveling
Requirement Allocation
2.5 Requirements documentation
2.5.1 Templates, SGML,…
2.5.2 Document Trees
Applications Study: Design Spec. Accuracy
I make it a habit of asking organizations I visit whether they trust the accuracy of their design
documentation/spec. trees. Usually without hesitation, I get "of course not" answers. The design
changes faster than the documentation. In fact, one of the rites of passage for "green" engineers
is a final revisit of the spec's to update them as a training exercise. Which begs the question, if the
spec's are so worthless, why do we spend up to 50% of our time messing around with them.
2.5.3 Web documents
2.5.4 Online requirements databases
2.6 Assignments for next class
2.6.1 Deliver requirements document
Requirements document includes the above developed using the tools introduced in this
session
Document includes QFD or other method of identifying critical requirements documenting
elicitation process
2.6.2 Present results
2.6.3 Tool Applications Case Study
2.6.4 Tool contribution
3 Class 3: Decomposition: Functions, Architecture and
Trade studies
Decide "how" to do it
Assignments from prior class:
 Deliver Tool Application Case Studies
 Requirements document review with Class
 Tool Contribution presentations
We are about to enter the world of systems modeling…first some background:

Modeling is not systems engineering (given the amount of time spent on them, it's easy to get
confused) How important is it? According to TI's Landmark Study [Sampson, et al. 1994], it
represents 15% of the life cycle (although it's very common to find modeling taking more than its
fair share of resources).

New modeling methodologies/techniques are being added all the time, we wont be able to visit
them all, but we will address a few of the more widely used ones.

Systems Engineers may be tempted to apply one modeling technique/methodology to the entire
systems problem, at which point I will remind you about my experience with the SE who ran out of
cells in his spreadsheet (using a hammer for everything) and which is why we will revisit
[Armstrong 1993] Systems Engineering Methods Compared to reset context.
3.1 Functional Analysis
3.1.1 Decomposition
3.1.2 Requirement to function linking
Includes driving out additional requirements, requirements allocation and flowdown
3.1.3 Functional Modeling
Demonstration in functional modeling
3.1.3.1 Functional Block Diagramming
3.1.3.2 Functional Simulation
3.1.3.3 Timelines
3.1.3.3.1 Critical Paths
3.1.3.3.2 Sequence/Overlaps/Concurrence/Race Conditions
3.1.4 Functional Interfaces
3.1.4.1 NxN Charts
3.1.4.2 Functional Threads
3.2 Define Alternatives
3.3 Criteria/Scoring
3.3.1 Utility Functions (constraints, weighting,…)
3.3.2 Converging
Pugh's convergence
3.4 Partitioning/Allocation
3.4.1 Internal Interfaces
Applications Study: Mars Rover Frozen Motors
"As the sun rose for the start of Spirit's 38th workday on Mars, the communications mast assembly
created a shadow on the high-gain antenna gimbal motors…causing the motors to stall from the
cold when trying to point the antenna to face Earth."
(http://www.spaceflightnow.com/mars/mera/040211spirit.html).
3.4.2 ICDs
3.4.3 Data Dictionaries
3.5 Architectural Trade Studies
3.5.1 Frameworks
Since its not possible to cover all possible architectural reference frameworks, we will introduce the idea
and visit several of the more popular ones.
3.5.1.1 Zachman
3.5.1.2 IDEF
3.5.1.3 DoDAF
3.5.2 Math model/simulations
3.5.2.1 Matlab-equations, algorthims,…
3.5.2.2 Excel
3.5.3 Structured & OO Techniques
3.5.3.1 Realtime
3.5.3.2 UML/SySML
…including an introduction of Systems Engineering extensions to UML 2.0 (by Sandy Friedenthal
SySML co-chair)
3.5.4 Statistical methods
3.5.4.1 DOE
3.5.4.2 Six Sigma/DFSS
SDI/UGS PLM, Cognition
3.5.4.3Sensitivity Analysis/Monte Carlo
Crystal Ball, SAS,… (Crystal Ball/Monte Carlo Demo)
3.5.5 Behavior
3.5.6 Performance/Queuing
3.5.7 Control/States
State-transition diagrams (State Diagramming/Simulation Demo by I-Logix/Statemate)
3.5.8 Data Flow
3.6 Assignments for next class
3.6.1 Deliver system design document
Develop functional decomposition, allocate requirements down to functions, allocate functions
down to architecture/physical. Deliver design specification that includes product architecture
descriptions and shows allocation down to architecture (including trace matrix) and interfaces.
Data dictionary (extra credit)
Document includes at least one trade study and one model to validate approach
3.6.2 Present results
3.6.3 Tool Applications Case Study
3.6.4 Tool contribution
4 Class 4: Optimization…
Optimize it
Assignments from prior class:
 Deliver Tool Application Case Studies
 Design document review with Class
 Tool Contribution presentations
4.1 Technical Performance Allocation/Management
4.1.1 Targets/Budgets
4.1.2 Design-to-Cost
4.1.3 Life cycle costing
4.1.3.1 Engineered costing
4.1.3.2 Analogs
4.1.3.3 Parametric costing
(Cosysmo, PRICE-H,…) (Cost-estimation explanation and demonstration)
4.2 Design for xxx
4.2.1 Produceability/Manufacturing
Factory design packages (efactory, Delmea,…)
LEAN
4.2.2 Maintability/Availability/Service
Spares estimators (Spares Analysis Demo)
Markov processes, Maintenance prediction,…
Fault Isolation
4.2.3 Logistics/Supportability
Packaging
Transport
Applications Study: Grating Equipment Transport
Designers of the new, bigger grating machine, neglected to consider the size of tires in their trade
studies. They succeeded in destroying a million dollar machine and bridge on their first delivery,
since it would not fit under standard highway bridges.
Storage
Facilities (Demo/discussion)
4.2.4 Disposability
Regulatory considerations
Design for recyclability
4.2.5 Testability
Coverage
Automated Test Generators
4.2.6 Environmental
EMI/EMC
Weather
Applications Study: Louisiana's Hurricane Proof Power Grid
Louisiana's power grid was upgraded following Hurricane Mitch to "Hurricane Proof" the
system. Since the new stiffer power poles were built in the same right-of-way, the new system was
knocked out in the next hurricane by the old power poles tipping over on the new poles.
4.2.7 Safety, Liability
4.2.7.1Failure Modes
MTBF,
Fault Isolation
DFMEA, MEA (FMEA/Fault Tree Tool Demo)
4.2.8 Reliability
4.2.9 Human Factors/Usability
Usability Testing
4.2.9.1Putting humans in the loop
Human Constraint databases
Human Modeling (Jack demo)
4.2.10
Security
5 Class 4 continued…Test/Validation
Prove we've done it
5.1 Requirement validation
…the right requirements
Validation via simulation
5.2 Requirement verification
…done right
5.2.1 Test Cases/Procedures
5.2.1.1Test Documents
5.2.2 Tracing
Test, back to implementation, back to source
Trace back to use cases, operation concepts, scenarios, etc.
5.2.3 Verification Matrices
5.2.4 Test Automation
Test managers (test equipment automation—Labview or Mercury Interative Demonstration)
Regression testers (such as Mercury Interactive,…)
Data acquisition and analysis
5.3 Assignments for next class
5.3.1 Deliver test document
Test plan/specification that includes product test mapped back to design, functions, and
requirements (including verification matrix)
Document includes at least one trade study and one model to validate approach
Verify/document product meets the requirements
5.3.2 Present results
5.3.3 Tool Applications Case Study
5.3.4 Tool contribution
6 Class 5: Program/Project Management
…manage it
6.1 Risk
6.1.1 Requirements Risk
Requirement volatility
6.1.2 Cost, Schedule, Technical Risk
Risk Impact Matrix, @Risk, ARM,…(Demo Active Risk Manager)
6.2 Project Management
6.2.1 Pert/CPM
6.2.2 Earned Value
Microsoft Project, Primavera, … (Demonstration using MS Project in combination with
systems engineering tools)
6.2.3 Resources/Skills
6.3 Dash boards
6.3.1 Virtual War Rooms
Synergy, EDWS,…(Synergy Demonstration)
6.3.2 Metrics
Quality Metrics and Repositories
Metric's databases (MetricCenter,…)
6.3.3 Data Exchange/Integration
Integration environments…Phoenix Integration, Accellis, BabbelFish,…
ISO STEP Data Exchange Standards (AP-233 Demonstration)
6.4 Requirement Change/CM
6.4.1 Baselining
6.4.2 Configuration management, versioning, Branching,…
CM Systems (ClearCase, Continuus, CVS,…)
Data Management Systems (Metaphase, MatrixOne,…)
Applications Case Study: Lost configuration on worlds-largest flying computer: B-1
"…test flying the worlds-largest flying computer, the B-1 bomber, is postponed 6 months
while, Rockwell verifies which version of which software goes on which version of which
controller." (Personal Interview with B-1 Software Development Mgr., 2001)
6.4.3 Change management
Change Impact
Workflow Engines
Problem tracking systems
6.5 Project Presentation/Final Exam
6.5.1 Tool Applications Case Study
6.5.2 Tool contribution
6.5.3 Deliver/Present Project
Prove product meets requirements via test/verification matrix
Deliver presentation of overall project--include scope, high level requirements, functions,
physical, to test. (30 minutes/team)
6.5.4 Final Exam
7 Bibliography












Customer Centered Products (Hooks & Farry, 2001)
Dept. of Energy (DOE) Systems Engineering & Interface Management; Project Management
Practices (Rev. E, 2003)
Human Performance Engineering (Bailey, 1982)
INCOSE SE Handbook (Version 2a) 2004
Introduction to the Management of Risk (Charette, 1994)
Managing Software Requirements: A Unified Approach (Leffingwell & Widrig, 2000)
Practical Management Science (Winston & Albright, 2000)
Requirements Engineering: A good practice guide (Summervill & Sawyer, 1997)
Systems Engineering Management (Lacy, 1992)
Systems Engineering Management Guide (Defense Systems Management College, 1986)
Systems Engineering Methods Compared (Armstrong, 1993 INCOSE Symposium)
Texas Instruments, DSEG Systems Engineering Design Automation Landmark Study (Sampson,
et al. 1994)
8 Notes