Intro to Systems Engineering Roles, Processes & Organization

All About Systems Engineering; Introductory Course
material by Gerrit Muller

presented by
Abstract
This introductory course sketches all fundamentals of Systems Engineering. Starting
at the business contexts, touching Project, Processes, and Organization. The
role of the Systems Engineer is discussed, and the relation with other roles, e.g.
project leader and product manager. The architecting and design tools are shown;
from Stakeholder Needs to Requirements to Modeling and Analysis.
Distribution
This article or presentation is written as part of the Gaud
project. The Gaud project philosophy is to improve
by obtaining frequent feedback. Frequent feedback is
pursued by an open creation process. This document
is published as intermediate or nearly mature version to
get feedback. Further distribution is allowed as long as
the document remains complete and unchanged.
theory and cases
more theory and exercises
introduction to SE,
process, organization
organization and process

in practice
case, phasing, V-Model, spiral model,

relation with other business disciplines
day 1
March 6, 2013
status:
preliminary
draft
version: 0.2
day 2
systems engineer role and

task
exercise and discussion

product families, products vs projects
day 3
capturing customer
understanding
deliverables, responsibilties, activities,

styles, characteristics

customer key drivers, story telling,
scenarios and use cases
system context
creating the big picture
customer context, life cycle context,

stakeholders, needs, concerns,
requirements, story telling, conops, use
cases
system design
concept selection, physical

decomposition, functional
decomposition, qualities, interface
management, budgeting, modeling

roadmapping, key performance
parameters
day 4
design and concept

selection in practice
example case to wrap-up
Introduction Course Program
morning
introduction to SE,
process, organization
case, phasing, V-Model, spiral model,

relation with other business disciplines
morning
system context
customer context, life cycle context,

stakeholders, needs, concerns,
requirements, story telling, conops, use
cases
All About Systems Engineering; Introductory Course

2
Gerrit Muller
day 1
afternoon
systems engineer role and

task
deliverables, responsibilties, activities,
styles, characteristics
day 2
afternoon
system design
concept selection, physical

decomposition, functional
decomposition, qualities, interface
management, budgeting, modeling
version: 0.2
March 6, 2013
SEINTROprogram2day
Project Systems Engineering Introduction; Phasing,

Process, Organization
by Gerrit Muller
Buskerud University College
e-mail: gaudisite@gmail.com
www.gaudisite.nl
Abstract
The fundamental concepts and approach to project oriented Systems Engineering
are explained. We look at project phasing, phase transition, processes, and
organization.
Distribution
This article or presentation is written as part of the Gaud project. The Gaud project
philosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by an
open creation process. This document is published as intermediate or nearly mature version
to get feedback. Further distribution is allowed as long as the document remains complete
and unchanged.
March 6, 2013
status:
preliminary
draft
version: 0.1
order
design and
engineering
tender
offer
installation
operation and
maintenance
acceptance
final payment
disposal
Project Life Cycle
order
design and
engineering
tender
offer
installation
operation and
maintenance
acceptance
final payment
version: 0.1
Project Systems Engineering Introduction; Phasing, Process, Organization
March 6, 2013
PSEIPprojectLifeCycle
4
Gerrit Muller
disposal
Phased Project Approach

tender
0.
feasibility
design and engineering

1.
definition
2.
system
design
3.
engineering
installation
4.
integration
& test
operation and
maintenance
5.
field
monitoring
needs
specification
design
verification
engineering
Legend:
core information
in draft
full under development
50%
most information
available in
concept
preparing or updating work

5
Gerrit Muller
version: 0.1
March 6, 2013
PSEIPphases
information is stable
enough to use
heavier change control
V-Model
needs
validation
specification
verification
system design
system test
subsystem design
component design
subsystem test
component test
component realization

6
Gerrit Muller
version: 0.1
March 6, 2013
TPSEPvModel
All Business Functions Participate
0.
feasibility
1.
definition
2.
system
design
3.
engineering
4.
integration
& test
sales
logistics
production
service
development & engineering:
marketing, project management, design
version: 0.1
March 6, 2013
PCPbusinessPhases
7
Gerrit Muller
5.
field
monitoring
Evolutionary PCP model
test and
evaluate
requirements
specification
2% of budget (EVO)
2 weeks (XP)
up to 2 months
per cyclus
build
design

8
Gerrit Muller
version: 0.1
March 6, 2013
PCPspiral
Reuse and Products
design and
engineering
reuse
spec
s
design and
engineering
tender
operation and
maintenance
installation
operation and
maintenance
reuse
produ
cts
reuse
spec
s
tender
installation
reuse
produ
cts
tender
design and
engineering
installation
operation and
maintenance
disposal
version: 0.1
March 6, 2013
PSEIPreuseAndProducts
9
Gerrit Muller
disposal
disposal
Simplified Process View

customer
supplying business
strategy
customer oriented
(sales,
service, production) process
val
ue
process
product creation
process
people, process and technology

management process
version: 0.1
March 6, 2013
RSPprocessDecomposition
10
Gerrit Muller
Simplified Process; Money and Feedback

customer
fee
bac d
k
supplying business
strategy
customer oriented
val
u
process
short term;
cashflow!
product creation
people, process and technology
mid term;
cashflow
next year!
long term
know how
(soft) assets
version: 0.1
March 6, 2013
RSPprocessDecompositionAnnotated
11
Gerrit Muller
Simplified process diagram for project business
policy and
planning
tender
contract
project
execution
systems architecting
systems
deployment
products or
components
product creation
people, process, and technology management

12
Gerrit Muller
version: 0.1
March 6, 2013
PPSprojectProcess
Decomposition of the Product Creation Process

Product Creation Process
Operational
Management
specification
budget
time
planning
progress control
resource
management
risk management
project log
Design
Control
Marketing
profitability
saleability
technical
customer input
needs
what is needed
customer expectations
specification
what will be realized
commercial structure
design
how to realize
verification
meeting specs
following design
engineering
how to produce
and to maintain

13
Gerrit Muller
product pricing
market introduction
introduction at customer
feedback
version: 0.1
March 6, 2013
PCPDecomposition
Operational Organization of the PCP

operational
entire
portfolio
product
family
single
product
subsystem
module
technical
portfolio
operational
manager
portfolio
architect
family
operational
manager
project
leader
project
leader
marketing
manager
family
marketing
manager
product
product
manager
architect
subsystem
portfolio
family
architect
(single product)
commercial
subsystem
architect
developers
version: 0.1
March 6, 2013
PCPoperationalOrganization
14
Gerrit Muller
Prime Responsibilities of the Operational Leader
Specification
Q uality
Resources
Time
version: 0.1
March 6, 2013
PCPoperationalTriangle
15
Gerrit Muller
The Rules of the Operational Game
business management
define project
update project
project leader
specification, resources, time

accept or reject
assess risks
determine feasibility
accept
execute project
within normal
quality rules
version: 0.1
March 6, 2013
PCPoperationalGame
16
Gerrit Muller
Operational Teams
Sales
Manager
Application
Manager
Requirements
Analyst
Operational Support
(project manager)
Marketing or
Product Manager
Operational Leader
(project leader)
Architect
Test Engineer
Service
Logistics
Quality
Assurance
TechnologySpecific
Architects
Subsystem
Operational
Leaders
Subsystem
Architects
Development
support
version: 0.1
March 6, 2013
PCPconcentricTeams
17
Gerrit Muller
Manufacturing
What Service Level to Deliver?
use results
functional
capability
capability management
technical
capability
facility management
expert support
initial production
customer support
factory
performance-based
or service-level
agreement
conventional
maintenance
contract
product
acceptance
and warranty
version: 0.1
March 6, 2013
PPSservicesOperationalModel
18
Gerrit Muller
Role and Task of the System Architect

by Gerrit Muller
www.gaudisite.nl
Abstract
The role and the task of the system architect are described in this module.
Distribution
and unchanged.
March 6, 2013
status:
preliminary
draft
version: 1.0
The Role and Task of the System Architect

by Gerrit Muller
Buskerud University Collge
www.gaudisite.nl
Abstract
The role of the system architect is described from three viewpoints: deliverables,
responsibilities and activities. This description shows the inherent tension in this
role: a small set of hard deliverables, covering a fuzzy set of responsibilities,
hiding an enormous amount of barely visible day-to-day work.
Blah
Blah
V4aa
Idea
Distribution
March 6, 2013
status: concept
version: 2.0
listen, talk,
walk around
design,
assist project leader
brainstorm, with work breakdown,
explain
schedule, risks
Spec
and unchanged.
think,
analyze
IO
Report
Design
test,
integrate
write,
consolidate,
browse
present,
meet, teach,
discuss
read,
review
travel to
customer,
supplier,
conference
provide
vision and
leadership
Deliverables of the System Architect
Report
Report
Report

21
Gerrit Muller
Design
Design
Design
Spec
Spec
Spec
version: 2.0
March 6, 2013
RSAdeliverables
List of Deliverables
Customer and Life-Cycle Needs
(what is needed)
System Specification (what will be realized)

Design Specification (how the system will be realized)
Verification Specification
(how the system will be verified)
Verification Report (the result of the verification)

Feasibility Report (the results of a feasibility study)
Roadmap

22
Gerrit Muller
version: 2.0
March 6, 2013
RSAdeliverablesSpecific
Responsibilities of the System Architect

Requirement
Spec
Design
Realization
ua
Function
lity
module
modules
subsystem
system
Balance
Consistency
KISS
Elegance
Simple
Decomposition
Integration
system
Overview
satisfied
stakeholders
context
Integrity

23
Gerrit Muller
Fitting
version: 2.0
March 6, 2013
RSAresponsibilities
Examples of Secondary Responsibilities
responsibility
primary owner
business plan, profit
business manager
schedule, resources
project leader
market, salability
marketing manager
technology
technology manager
process, people
line manager
detailed designs
engineers

24
Gerrit Muller
version: 2.0
March 6, 2013
RSAsecondaryResponsibilities
What does the System Architect do?

Blah
Blah
V4aa
Idea
think,
analyze
IO
listen, talk,
walk around
design,
explain
schedule, risks
Spec
Report
Design
test,
integrate
write,
consolidate,
browse

25
Gerrit Muller
present,
meet, teach,
discuss
read,
review
travel to
customer,
supplier,
conference
version: 2.0
March 6, 2013
RSAactivities
provide
vision and
leadership
From Detail to Overview
Quantity
consolidation
in
deliverables
driving views
per year
(order-ofmagnitude)
10
shared issues
10 2
touched details
10 4
architect
time per
item
100 h
1h
meetings
informal
contacts
sampling
scanning
seen details
10 5
10 6
product details
10 7
10 10
real-world facts
26
Gerrit Muller
0.5
10 min
0.1
1 sec
infinite
version: 2.0
March 6, 2013
RSAdetailHierarchy
Reality or Virtuality?
Abstractions only exist for concrete facts.

27
Gerrit Muller
version: 2.0
March 6, 2013
Visible Output versus Invisible Work
Spec
Spec
Spec
Report
Requirement
Spec
Design
Realization
ua
lity
Design
Design
Design
Functio
n
Report
Report
Deliverables
Responsibilities
KISS
module
subsystem
Decreasing
Visibility
From Manager perspective
modules
system
Bla Bla
Idea
V4aa
Spec
IO
Report
Design

28
Gerrit Muller
version: 2.0
March 6, 2013
RSApyramid
Activities
The Awakening of a System Architect

by Gerrit Muller
www.gaudisite.nl
Abstract
The typical phases of a system architect development are described, beginning
at the fundamental technology knowledge, with a later broadening in technology
and in business aspects. Finally the subtlety of individual human beings is taken
into account.
Distribution
and unchanged.
March 6, 2013
status: concept
version: 1.1
root
technical
knowledge
generalist
technical
knowledge
business,
application insight
process insight
psychosocial
skills
Typical Growth of a System Architect
root
technical
knowledge
generalist
technical
knowledge

30
Gerrit Muller
business,
application insight
process insight
version: 1.1
March 6, 2013
MATsystemArchitectGrowth
psychosocial
skills
Generalist versus Specialist

breadth of
knowledge
specialist
depth of
knowledge
generalist

31
Gerrit Muller
root
knowledge
version: 1.1
March 6, 2013
MATgeneralistVsSpecialist
Generalists and Specialists are Complementary

breadth of
knowledge

32
Gerrit Muller
version: 1.1
March 6, 2013
MATcomplementaryExpertises
specialist
specialist
specialist
specialist
specialist
specialist
specialist
depth of
knowledge
specialist
generalist
generalist
Spectrum from Specialist to System Architect
all-round specialist
specialist
depth of
knowledge
breadth of
knowledge

33
Gerrit Muller
systems architect
aspect
architect
root
knowledge
version: 1.1
March 6, 2013
MATfromSpecialistToSystemArchitect
Architecting Interaction Styles

by Gerrit Muller
www.gaudisite.nl
Abstract
A system architects needs skills to apply different interactions styles, depending
on the circumstances. This document discusses the following interaction styles:
provocation, facilitation, leading, empathic, interviewing, white board simulation,
and judo tactics.
provocation
facilitation
Distribution
and unchanged.
leading
March 6, 2013
status: draft
version: 0.2
when in an impasse: provoke

effective when used sparsely
especially recommended when new in a field:
contribute to the team, while absorbing new knowledge
provide vision and direction, make choices

risk: followers stop to give the needed feedback
empathic
interviewing
take the viewpoint of the stakeholder

acknowledge the stakeholder's feelings, needs, concerns
investigate by asking questions
whiteboard simulation
judo tactics
invite a few engineers and walk through

the system operation step by step
first listen to the stakeholder and then

explain cost and alternative opportunities
Architecting Styles
when in an impasse: provoke
effective when used sparsely
provocation
especially recommended when new in a field:

contribute to the team, while absorbing new knowledge
facilitation
leading
provide vision and direction, make choices

risk: followers stop to give the needed feedback
empathic
take the viewpoint of the stakeholder

acknowledge the stakeholder's feelings, needs, concerns
interviewing
investigate by asking questions
whiteboard simulation
judo tactics
Architecting Interaction Styles

35
Gerrit Muller
invite a few engineers and walk through

the system operation step by step
first listen to the stakeholder and then

explain cost and alternative opportunities
version: 0.2
March 6, 2013
ASstyles
Exercise Role and Task of the System Architect

Role play with 3 roles and optional observer:
1 operational leader (project leader)
1 system architect
1 marketing manager
1 observer (optional)
Discuss the definition (business relevance, specification, and planning) of a travel
e-mail mate.
Present (max. 2 flips) the result and the process (the relation and interaction of
the three roles).
Exercise Role and Task System Architect

36
Gerrit Muller
version: 0.2
March 6, 2013
MRSAexercise
Role and Task of a System Architect

Deliverables
Responsibilities
Requirement
Spec
Design
Realization
Function
ua
lity
module
modules
subsystem
system
Balance
Report
Report
Design
Design
Design
Spec
Spec
Spec
Report
Daily Activities
KISS
Elegance
Simple
system
design,
explain
schedule, risks
present,
meet, teach,
discuss
consolidation
in
deliverables
Fitting
Spec
Report
read,
review
travel to
customer,
supplier,
conference
sampling
scanning
provide
vision and
leadership

37
Gerrit Muller
architect
time per
driving views
per year
(order-ofmagnitude)
10
shared issues
10 2
1h
touched details
10 4
item
100 h
meetings
informal
contacts
Design
write,
consolidate,
browse
satisfied
stakeholders
Quantity
IO
listen, talk,
walk around
Overview
context
Integrity
V4aa
Idea
test,
integrate
Decomposition
Integration
From detail to overview
Blah
Blah
think,
analyze
Consistency
seen details
10 5
10 6
product details
10 7
10 10
real-world facts
version: 0.2
March 6, 2013
infinite
0.5
10 min
0.1
1 sec
Personal characteristics of a System Architect

Generalist vs Specialist
breadth of
knowledge
Typical growth of a Architect

process insight
psychosocial
skills
Complementary Roles
specialist
business,
application insight
generalist
technical
knowledge
depth of
knowledge
root
technical
knowledge
generalist
root
knowledge
Role Spectrum
breadth of
knowledge

38
Gerrit Muller
specialist
depth of
knowledge
specialist
specialist
specialist
specialist
specialist
specialist
specialist
depth of
knowledge
specialist
generalist
generalist
all-round specialist
breadth of
knowledge
systems architect
aspect
architect
root
knowledge
version: 0.2
March 6, 2013
Module Requirements
by Gerrit Muller
www.gaudisite.nl
Abstract
This module addresses requirements: What are requirements? How to find,
select, and consolidate requirements?
Distribution
and unchanged.
March 6, 2013
status: concept
version: 1.3
Fundamentals of Requirements Engineering

by Gerrit Muller
www.gaudisite.nl
Abstract
Requirements engineering is one of the systems engineering pillars. In this document
we discuss the fundamentals of systems engineering, such as the transformation
of needs into specification, the need to prescribe what rather than how, and the
requirements when writing requirements.
interfaces
system seen as black box
Distribution
and unchanged.
inputs
March 6, 2013
status: concept
version: 0.1
functions
quantified characteristics
restrictions, prerequisites
boundaries, exceptions
standards, regulations
outputs
Definition of Requirement
Requirements describing the needs of the customer:
Customer Needs
Requirements describing the characteristics of the
final resulting product: Product Specification
The requirements management process recursively
applies definition 2 for every level of decomposition.
Requirements describing the needs of the company
itself over the life cycle: Life Cycle Needs

41
Gerrit Muller
version: 0.1
March 6, 2013
REQdefinition
Flow of Requirements
What
choices
trade-offs
negotiations
customer needs:
What is needed by the customer?
What
product specification:
What are we going to realize?
How
system design:
How are we going to realize the product?
What What What
What are the subsystems we will realize?
How How How
How will the subsystems be realized?
What What What

How How How
What What What
up to "atomic" components
How How How

42
Gerrit Muller
version: 0.1
March 6, 2013
REQwhatWhatHow
System as a Black Box

interfaces
system seen as black box

inputs
functions
quantified characteristics
outputs
restrictions, prerequisites
boundaries, exceptions
standards, regulations
43
Gerrit Muller
version: 0.1
March 6, 2013
REQsystemAsBlackBox
Stakeholders w.r.t. Requirements

customer
(purchaser, decision maker, user, operator, maintainer)
company
Policy and Planning
(business, marketing,
operational managers)
Customer-Oriented Process
(sales, service, production,

logistics)
Product Creation Process
(project leader, product

manager, engineers, suppliers)
People, Process, and Technology management process
(capability managers, technology suppliers)

44
Gerrit Muller
version: 0.1
March 6, 2013
REQstakeholders
The Formal Requirements for Requirements
Specific
Unambiguous
Verifiable
Quantifiable
Measurable
Complete
Traceable

45
Gerrit Muller
version: 0.1
March 6, 2013
REQrequirementsForRequirementsList
The Requirements to Enable Human Use
Accessible
Understandable
Low threshold

46
Gerrit Muller
version: 0.1
March 6, 2013
REQrequirementsFromHumans
Short introduction to basic CAFCR model

by Gerrit Muller
www.gaudisite.nl
Abstract
The basic CAFCR reference model is described, which is used to describe
a system in relation to its context. The main stakeholder in the context is the
customer. The question Who is the customer? is addressed.
Distribution
drives, justifies, needs

enables, supports
and unchanged.
March 6, 2013
status: draft
version: 0.4
What does Customer need

in Product and Why?
Customer
What
Customer
How
Customer
Application
objectives
Product
What
Functional
Product
How
Conceptual
Realization
The CAFCR model
drives, justifies, needs

enables, supports
in Product and Why?
Customer
What
Customer
How
Customer
Application
objectives

48
Gerrit Muller
Product
How
Product
What
Functional
Conceptual
version: 0.4
March 6, 2013
CAFCRannotated
Realization
Integrating CAFCR
in Product and Why?
Customer Customer
What
How
Customer
Application
Product
How
Product
What
Functional
Conceptual
context
intention
objective
opportunities
constraint knowledge
objectives
understanding

49
Gerrit Muller
awareness
driven
based
version: 0.4
March 6, 2013
MSintegratingCAFCR
Realization
CAFCR can be applied recursively
Consumer
Enables
Drives
Customer's
Customer
Business
larg
Va
infl er sco lue C Enables
uen
hai
p
e
n
ce
h
on as s
arc ma
hite ller
ctu
re

50
Gerrit Muller
Drives
Customer
Business
Enables
version: 0.4
March 6, 2013
CAFCRrecursion
Drives
System
(producer)
Market segmentation
segmentation
axis
examples
geographical
USA, UK, Germany, Japan, China
business model
profit, non profit
economics
high end versus cost constrained
consumers
youth, elderly
outlet
retailer, provider, OEM, consumer direct

51
Gerrit Muller
version: 0.4
March 6, 2013
BCAFCRcustomerSegmentation
Example of a small buying organization
CFO
CIO
CMO
CEO CTO
decision maker(s)
purchaser
Who is the customer?

department head
user
CEO: Chief Executive Officer
CFO: Chief Financial Officer
CIO: Chief Information Officer
CMO: Chief Marketing Officer
CTO: Chief Technology Officer

52
Gerrit Muller
maintainer
operator
version: 0.4
March 6, 2013
BCAFCRwhoIsTheCustomer
CAFCR+ model; Life Cycle View
Customer
Application
Functional
Conceptual
operations
maintenance
upgrades
Life cycle
development
manufacturing
installation
objectives
sales, service, logistics, production, R&D

53
Gerrit Muller
version: 0.4
March 6, 2013
BCAFCRplusLifeCycle
Realization
Key Drivers How To

by Gerrit Muller
www.gaudisite.nl
Abstract
The notion of business key drivers is introduced and a method is described to
link these key drivers to the product specification.
Key-drivers
Safety
Derived application drivers

Reduce accident rates
Enforce law
Distribution
and unchanged.
Effective
Flow
March 6, 2013
status: draft
version: 0.2
Improve emergency
response
Reduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Anticipate on future traffic condition
Smooth
Operation
Ensure traceability
Environment
Reduce emissions
Requirements
Early hazard detection

with warning and signaling
Automatic upstream
accident detection
Maintain safe road

condition
Weather condition
dependent control
Classify and track dangerous

goods vehicles
Detect and warn
noncompliant vehicles
Enforce speed compliance
Traffic speed and

density measurement
Cameras
Deicing
Traffic condition
dependent speed control
Enforce red light compliance

Enforce weight compliance
Ensure proper alarm handling

Ensure system health and fault indication
Note: the graph is only partially elaborated

for application drivers and requirements
Example Motorway Management Analysis

Key-drivers
Safety
Derived application drivers

Reduce accident rates
Enforce law
Effective
Flow
Improve emergency
response
Reduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Smooth
Operation
Anticipate on future traffic condition
Early hazard detection

with warning and signaling
Automatic upstream
accident detection
Maintain safe road

condition
Weather condition
dependent control
Classify and track dangerous

goods vehicles
Traffic speed and

density measurement
Cameras
Detect and warn

noncompliant vehicles
Deicing
Enforce speed compliance
Traffic condition
dependent speed control
Enforce red light compliance

Enforce weight compliance
Ensure traceability
Ensure proper alarm handling
Ensure system health and fault indication
Environment
Requirements
Reduce emissions
Key Drivers How To

55
Gerrit Muller
Note: the graph is only partially elaborated

for application drivers and requirements
version: 0.2
March 6, 2013
COVmotorwayManagementKeyDrivers
Method to create Key Driver Graph
Define the scope specific.
in terms of
Acquire and analyze facts
Key Drivers How To

56
Gerrit Muller
market segments
facts from the product specification

why questions about the specification of existing products
Build a graph of relations between drivers and requirements

by means of brainstorming and discussions
Iterate many times
or
extract
and ask
Obtain feedback
stakeholder
requirements
multiple drivers
where
may have
discuss with
customers , observe
their
reactions
increased understanding often triggers the move of issues

from driver to requirement or vice versa and rephrasing
version: 0.2
March 6, 2013
TCAFkeyDriverSubmethod
Recommendation for the Definition of Key Drivers
Limit the number of key-drivers

Dont leave out the obvious key-drivers
minimal
for instance the well-known
main function
3 , maximal 6
of the product
Use short names, recognized by the customer.

Use market-/customer- specific names, no generic names
for instance replace ease of use by

minimal number of actions for experienced users
,
or efficiency by integral cost per patient
Do not worry about the exact boundary between

Customer Objective and Application
Key Drivers How To

57
Gerrit Muller
create clear
version: 0.2
March 6, 2013
TCAFkeyDriverRecommendations
goal means
relations
Transformation of Key Drivers into Requirements

Customer
What
Customer
How
Product
What
Customer
Application
Functional
Key
(Customer)
Drivers
Derived
Application
Drivers
Requirements
objectives
goal
Key Drivers How To

58
Gerrit Muller
means
may be skipped or
articulated by several
intermediate steps
functions
interfaces
performance figures
version: 0.2
March 6, 2013
REQfromDriverToRequirement
Requirements Elicitation and Selection

by Gerrit Muller
www.gaudisite.nl
Abstract
An elicitation method for needs is described using many different viewpoints. A
selection process with a coarse and a fine selection is described to reduce the
specification to an acceptable and feasible subset.
top-down
key-drivers
(customer, business)
operational drivers
(logistics, production, etc.)
roadmap
(positioning and trends in time)
competition
Distribution
and unchanged.
(positioning in the market)
March 6, 2013
status: draft
version: 0
regulations
"ideal" reference design
prototyping, simulation
(learning vehicle)
bottom-up
(technological opportunities)
existing systems
bottom-up
Needs
Continued
Product Creation
Process
Feedback
Complementary Viewpoints to Capture Requirements

top-down
key-drivers
(customer, business)
operational drivers
(logistics, production, etc.)
roadmap
(positioning and trends in time)
competition
(positioning in the market)
regulations
"ideal" reference design
prototyping, simulation
(learning vehicle)
bottom-up
Continued
Product Creation
Process
Needs
Feedback
(technological opportunities)
existing systems
bottom-up

60
Gerrit Muller
version: 0
March 6, 2013
REQviewpoints
Requirement Selection Process
strategy
roadmap
competition
product specification
customer needs
selection process
operational needs
need
characterization
requirement
phasing
Technology, People, Process

costs and constraints

61
Gerrit Muller
version: 0
March 6, 2013
REQselection
discuss
do
don't
discuss
effort
important
Simple Qualification Method
don't
discuss
discuss
do
urgent

62
Gerrit Muller
value
version: 0
March 6, 2013
REQqualitativeSelectionMatrix
Examples of Quantifiable Aspects

Value for the customer
(dis)satisfaction level for the customer
Selling value (How much is the customer willing to pay?)
Level of differentiation w.r.t. the competition
Impact on the market share
Impact on the profit margin
Use relative scale, e.g. 1..5 1=low value, 5 -high value
Ask several knowledgeable people to score
Discussion provides insight
63
Gerrit Muller
(don't fall in spreadsheet trap)

version: 0
March 6, 2013
MPBAvalueCriteria
Exercise Requirements Capturing
Determine the key drivers for one particular product family.

Translate these drivers into application drivers and derive from them the requirements.
Exercise Requirements Capturing

64
Gerrit Muller
version: 0
March 6, 2013
MREQexercise
Story How To
by Gerrit Muller
www.gaudisite.nl
Abstract
A story is an easily accessible story or narrative to make an application live. A
good story is highly specific and articulated entirely in the problem domain: the
native world of the users. An important function of a story is to enable specific
(quantified, relevant, explicit) discussions.

in Product and Why?
Product
How
Distribution
and unchanged.
March 6, 2013
status: concept
version: 1.1
Customer
What
Customer
How
Product
What
Customer
Application
Functional
objectives
market
vision
Conceptual
Realization
a priori solution knowledge

story
analyze
design
case
analyze
design
design
From story to design

in Product and Why?
Product
How
Customer
What
Customer
How
Product
What
Customer
Application
Functional
objectives
market
vision
Conceptual
Realization
a priori solution knowledge

story
Story How To
66
Gerrit Muller
analyze
design
case
analyze
design
version: 1.1
March 6, 2013
SHTfromStoryToDesign
design
Example story layout
A day in the life of Bob

ca. half a page of
plain English text
bla blah bla, rabarber music

bla bla composer bla bla
qwwwety30 zeps.
nja nja njet njippie est quo
vadis? Pjotr jaleski bla bla
bla brree fgfg gsg hgrg
mjmm bas engel heeft een
interressant excuus, lex stelt
voor om vanavond door te
werken.
In the middle of the night he
is awake and decides to
change the world forever.
Yes
or
draft or sketch of
some essential
appliance
No
that is the question
The next hour the great

event takes place:
This brilliant invention will change the world foreverbecause it is so unique and
valuable that nobody beliefs the feasibility. It is great and WOW at the same time,
highly exciting.
Vtables are seen as the soltution for an indirection problem. The invention of Bob will
obsolete all of this in one incredibke move, which will make him famous forever.
He opens his PDA, logs in and enters his provate secure unqiue non trivial
password, followed by a thorough authentication. The PDA asks for the fingerprint of
this little left toe and to pronounce the word shit. After passing this test Bob can
continue.
Story How To
67
Gerrit Muller
version: 1.1
March 6, 2013
SHTexampleStoryLayout
Points of attention
purpose
scope
viewpoint, stakeholders
visualization
size (max 1 A4)
recursive decomposition, refinement
Story How To
68
Gerrit Muller
version: 1.1
March 6, 2013
SHTattentionPoints
Criteria for a good story
ustomer
objectives
accessible, understandable
"Do you see it in front of you?"
Application
C
ustomer
objectives
valuable, appealing
Application
Conceptual
critical, challenging
Realization
Application
attractive, important
"Are customers queuing up for this?"
"What is difficult in the realization?"
"What do you learn w.r.t. the design?"
frequent, no exceptional niche

"Does it add significantly to the bottom line?"
Application
specific
names, ages, amounts, durations, titles, ...
Functional
Story How To
69
Gerrit Muller
version: 1.1
March 6, 2013
SHTcriterionsList
Example of a story
Betty is a 70-year-old woman who lives in Eindhoven. Three years ago her husband passed
away and since then she lives in a home for the elderly. Her 2 children, Angela and Robert,
come and visit her every weekend, often with Bettys grandchildren Ashley and Christopher.
As so many women of her age, Betty is reluctant to touch anything that has a technical
appearance. She knows how to operate her television, but a VCR or even a DVD player is
way to complex.
When Betty turned 60, she stopped working in a sewing studio. Her work in this noisy
environment made her hard-of-hearing with a hearing-loss of 70dB around 2kHz. The rest of
the frequency spectrum shows a loss of about 45dB. This is why she had problems
understanding her grandchildren and why her children urged her to apply for hearing aids two
years ago. Her technophobia (and her first hints or arthritis) inhibit her to change her hearing
aids batteries. Fortunately her children can do this every weekend.
This Wednesday Betty visits the weekly Bingo afternoon in the meetingplace of the old-folks
home. Its summer now and the tables are outside. With all those people there its a lot of
chatter and babble. Two years ago Betty would never go to the bingo: I cannot hear a thing
when everyone babbles and clatters with the coffee cups. How can I hear the winning
numbers?!. Now that she has her new digital hearing instruments, even in the bingo
cacophony, she can understand everyone she looks at. Her social life has improved a lot and
she even won the bingo a few times.
That same night, together with her friend Janet, she attends Mozarts opera The Magic Flute.
Two years earlier this would have been one big low rumbly mess, but now she even hears the
sparkling high piccolos. Her other friend Carol never joins their visits to the theaters. Carol
also has hearing aids, however hers only work well in normal conversations. When I hear
music its as if a butchers knife cuts through my head. Its way too sharp!. So Carol prefers to
take her hearing aids out, missing most of the fun. Betty is so happy that her hearing
instruments simply know where they are and adapt to their environment.
Story How To
70
Gerrit Muller
version: 1.1
March 6, 2013
SHTexample
source: Roland Mathijssen

Embedded Systems Institute
Eindhoven
Value and Challenges in this story

Value proposition in this story:
quality of life:
Customer
objectives
Application
active participation in different social settings

usability for nontechnical elderly people:
"intelligent" system is simple to use
loading of batteries
Challenges in this story:
Intelligent hearing instrument
Battery life
at least 1 week
Conceptual
No buttons or other fancy user interface on the hearing instrument,

other than a robust On/Off method
Realization
The user does not want a technical device but a solution for a problem
Instrument can be adapted to the hearing loss of the user
Directional sensitivity (to prevent the so-called cocktail party effect)
Recognition of sound environments and automatic adaptation (adaptive
filtering)
source: Roland Mathijssen, Embedded Systems Institute, Eindhoven
Story How To
71
Gerrit Muller
version: 1.1
March 6, 2013
SHTexampleCriteria
Concept Selection, Set Based Design and Late

Decision Making
by Gerrit Muller
www.gaudisite.nl
Abstract
We discuss a systems design approach where several design options are maintained
concurrently. In LEAN Product Development this is called set-based design. Concentioanl systems engineering also promotes the concurrent evaluation of multiple
concepts, the so-called concept selection. Finally, LEAN product development
advocates to keep options open as long as feasible; the so-called late decision
making.
Distribution
1'
and unchanged.
March 6, 2013
status: planned
version: 0
1"
2'
1"'
2"
3'
4
2"'
3"
4'
3"'
3""
B
4"
5
5'
A'
5"
B'
B"
time
B'"
Problem Solving Approach

vague problem statement
1. Problem understanding
by
exploration and simple models
3. Decision
by
+ review and agree on analysis
+ communicate and document
4. Monitor, verify, validate
by
+ measurements and testing

+ assessment of other decisions
Concept Selection, Set Based Design and Late Decision Making

73
Gerrit Muller
version: 0
March 6, 2013
TORdecisionFlow
invalidated solution
by
+ exploring multiple propositions (specification + design proposals)
+ exploring decision criteria (by evaluation of proposition feedback)
+ assessment of propositions against criteria
insufficient data
no satisfying solution
conflicting other decision
2. Analysis
Examples of Pugh Matrix Application

Swivel concept selection
CBV swivel
evaluation criteria
clamp swivel
weight
Maturity
10
Cost
20
Design robustness
25
Development level
Hardware cost
Development cost
Design life
swivel cycles
pressure cycles
Pressure range
internal
external
Temperature range
Installation
20
Operation
25
Initial installatio/retrieval
Connection/disconnection
Swivel resistance
Spool Length Short
Spool Length Long
Hub loads
points
CBV
EDP-LRP connection
dynamic
swivel
clamp
dynamic
50
20
50
4
5
80
100
2
2
40
40
5
2
100
40
5
5
125
125
3
4
75
100
3
5
75
125
4
2
4
100
50
100
4
5
4
100
125
100
4
2
4
100
50
100
2
2
40
40
3
4
60
80
4
5
80
100
1
1
3
2
25
25
75
50
4
4
5
4
100
100
125
100
5
5
5
5
125
125
125
125
985
1165
two sided
connectors
connectors in
hub
connectors in
hub
with roll-off
wireless
connection
Concepts
Evaluation Criteria
Score
+
+
+
+
+
+
+
+
S
S
S
+
S
-
+
+
+
S
+
+
S
-
S
+
-
S
+
-
S
+
S
S
+
+
S
+
7
1
5
7
3
3
5
4
4
3
3
7
Pos.
Time to connect
Need for ROV
Design
Robustness
Connector design
Number of parts
Handle roll-off
Influence other
Redundancy
Design
Interchangeability
Cost
HW cost
Manufacturing cost
Engineering cost
Service cost
Maturity
1290
from master paper Halvard Bjrnsen, 2009

74
Gerrit Muller
from master paper Dag Jostein Klever, 2009
version: 0
March 6, 2013
CSSBpughExamples
Evolution of Design Options
1'
2
3
1"
2'
1"'
2"
3'
4
2"'
3"
4'
3"'
3""
B
4"
5
5'
A'
B'
5"

75
Gerrit Muller
B"
time
version: 0
March 6, 2013
CSSBsetEvolution
B'"
Conclusions
Evolving multiple concepts increases insight and understanding

(LEAN product development: set-based design, SE: Pugh matrix)
Articulation of criteria sharpens evaluation
The discussion about the Pugh matrix is more valuable than final
bottomline summation
Delaying decisions may help to keep options (Lean Product
Development: late decision making, finance: real options)

76
Gerrit Muller
version: 0
March 6, 2013
CSSBconclusions
Qualities as Integrating Needles

by Gerrit Muller
www.gaudisite.nl
Abstract
Many stakeholder concerns can be specified in terms of qualities. These qualities
can be viewed from all 5 CAFCR viewpoints. In this way qualities can be used
to relate the views to each other.
The meaning of qualities for the different views is described. A checklist of qualities
is provided as a means for architecting. All qualities in the checklist are described
briefly.
Customer
objectives
Distribution
and unchanged.
March 6, 2013
status: finished
version: 1.3
usability
safety
evolvability
Application
Functional
Conceptual
Realization
Quality needles as generic integrating concepts

Customer
objectives
Application
Functional
Conceptual
Realization
usability
safety
evolvability

78
Gerrit Muller
version: 1.3
March 6, 2013
QNneedles
Security as example through all views
Customer
objectives
sensitive
information
trusted
Application
selection
classification
people
information
authentication
badges
passwords
Functional
functions for
administration
authentication
intrusion detection
logging
quantification
Conceptual
cryptography
firewall
security zones
authentication
registry
logging
locks / walls
guards
administrators
Realization
specific
algorithms
interfaces
libraries
servers
storage
protocols
desired characteristics, specifications & mechanisms
not trusted
social contacts
missing
open passwords
functionality
blackmail
wrong
burglary
quantification
fraud
unworkable procedures

79
Gerrit Muller
holes between
concepts
threats
version: 1.3
March 6, 2013
QNsecurityExample
bugs
buffer overflow
non encrypted
storage
poor exception
handling
Quality Checklist
usable
usability
attractiveness
responsiveness
image quality
wearability
storability
transportability
dependable
safety
security
reliability
robustness
integrity
availability
effective
throughput or
productivity
interoperable
connectivity
3rd party extendible
liable
liability
testability
traceability
standards compliance
efficient
resource utilization
cost of ownership
consistent
reproducibility
predictability

80
Gerrit Muller
serviceable
ecological
ecological footprint
contamination
noise
disposability
serviceability
configurability
installability
future proof
evolvability
portability
upgradeability
extendibility
maintainability
down to earth
attributes
logistics friendly
manufacturability
logistics flexibility
lead time
version: 1.3
March 6, 2013
QNchecklist
cost price
power consumption
consumption rate
(water, air,
chemicals,
et cetera)
size, weight
accuracy
System Partitioning Fundamentals

by Gerrit Muller
www.gaudisite.nl
Abstract
The fundamental concepts and approach system partitioning are explained. We
look at physical decomposition and functional decomposition in relation to supply
chain, lifecycle support, project manageemnt, and system specification and design.
system
subsystem 1
Distribution
and unchanged.
March 6, 2013
status:
preliminary
draft
version: 0.1
subsub
system A
subsub
system B
subsub
system N
atomic
part
atomic
part
atomic
part
subsystem 2
subsub
system A
subsub
system B
subsub
system N
subsystem n
subsub
system A
subsub
system B
subsub
system N
Engineering
engineering knowledge
system specification
system design
source data
procurement
parts data base

engineering
production procedures
qualification procedures
system documentation
production
installation
quality
assurance
lifecycle
support
knowdoc
CAD
SCM
ledge
DB
DB
past
project
source
mechanical
experience documents electrical
code
design management
database

82
Gerrit Muller
ERP
PDM
resource
product
planning,
data
e.g. SAP management
version: 0.1
March 6, 2013
SPFengineering
chamber
bottom chuck
optics stage
control
Example Physical Decomposition
Fluidic
subsystem
8
5 electronics
infrastructure
ZUBA
control
vision
control
9 vision
optics
stage
16base frame +
x, y, stage
1
10
0
covers and
hatches
11
cabling
12
ventilation
air flow
13
contamination
evacuation
sensors
measurement
frame
14
machine
control
15
"remote"
electronics rack
7 ZUBA
camera
scoop
stage
control
stage
granite
electronics
infrastructure
frame
process
power
supply
back side view

83
Gerrit Muller
front side view
integrating
version: 0.1
March 6, 2013
REPLIsubsystemsAll
Partitioning is Applied Recursively

system
subsystem 1
subsub
system A
subsub
system B
subsub
system N
atomic
part
atomic
part
atomic
part
subsystem 2
subsub
system A
subsub
system B
subsub
system N
subsystem n
subsub
system A

84
Gerrit Muller
subsub
system B
subsub
system N
version: 0.1
March 6, 2013
SPFrecursion
Software plus Hardware Decomposition
applications
services
toolboxes
view
viewport
audio
tuner
adjust
view
TXT
menu
video
drivers
driver
hardware
PIP
framebuffer
browse
TXT
etc.
networking
scheduler
MPEG
signal processing subsystem
DSP
OS
CPU
RAM
etc
control subsystem
domain specific

85
Gerrit Muller
filesystem
generic
version: 0.1
March 6, 2013
CVconstructionDecomposition
Guidelines for Partitioning
the part is cohesive

functionality and technology belongs together
the coupling with other parts is minimal
minimize interfaces
the part is selfsustained for production and qualification
can be in conflict with cost or space requirements
clear ownership of part
e.g. one department or supplier

86
Gerrit Muller
version: 0.1
March 6, 2013
SPFpartitioningGuidelines
How much self-sustained?
control SW
application
SW
HMI SW
control
electronics
control
interface
cooling
EMC
shielding
main
function
qualification
support
adjustment
support
power
stabilization
power
conversion
power
distribution
production
support
mechanical
package
How self sustained should a part be?

trade-off:
cost/speed/space
optimization

87
Gerrit Muller
logistics/lifecycle/production
flexibility
clarity
version: 0.1
March 6, 2013
SPFselfSustained
Decoupling via Interfaces
power
interface
control
interface
e.g. CAN
part
e.g. pressure
and flow
regulator
part
e.g. pipe
hydrocarbon
interface

88
Gerrit Muller
mechanical
mounting interface
part
e.g. pipe
other part with

same interfaces
can replace
original
version: 0.1
March 6, 2013
SPFinterfaceDecoupling
The Ideal Modularity
System is composed
by using standard interfaces
limited catalogue of variants (e.g. cost performance points)

89
Gerrit Muller
version: 0.1
March 6, 2013
SPFmodularityGame
System Creation
stakeholder
needs
business
objectives
specification
architecting
design
architecture
guidelines
top-level design
rationale
procurement
design
partitioning
interfaces
functions
allocation
production
engineering
documentation
system and parts data

procedures

90
Gerrit Muller
version: 0.1
March 6, 2013
SPFsystemCreation
installation
quality
assurance
lifecycle
support
Simplistic Functional SubSea Example
sensor
signals
measure
pressure,
temp, flow
sensor
data
control
pressure,
temp, flow
settings
transport to
top-side
increase
well
pressure
hydrocarbons
from well
hydro
carbons
prevent
blow-outs

91
Gerrit Muller
regulate
flow and
pressure
combine
multiple
streams
separate
gas, oil,
water, sand
version: 0.1
March 6, 2013
SPFfunctionalExample
water
sand
Functional Decomposition
How does the system work and operate?
Functions describe what rather than how.
Functions are verbs .
Input-Process-Output paradigm.
Multiple kinds of flows:
physical (e.g. hydrocarbons)
information (e.g. measurements)
control
At lower level one part ~= one function
pump pumps, compressor compresses, controller controls
At higher level functions are complex interplay of physical parts
e.g. regulating constant flow, pressure and temperature

92
Gerrit Muller
version: 0.1
March 6, 2013
SPFfunctionalDecomposition
Quantification
Size
2.4m * 0.7m * 1.3m
Weight
Cost
1450 Kg
30000 NoK
Reliability
MTBF 4000 hr
Throughput
3000 l/hr
0.1 s
Response time
Accuracy
+/- 0.1%

93
Gerrit Muller
many characteristics
of a system, function or part
can be quantified
Note that quantities
have unit
version: 0.1
March 6, 2013
SPFquantification
Question Generator
How about the <characteristic>

of the <component>
when performing <function>?
What is the accuracy of
the fuse
when printing
functions
printing
preparing
copying
solving
paper jam
paper path
fuse
PIM
finisher
scanner
accuracy
component
processing load
response time
ch
ara
cte
ris
tics
throughput
memory footprint

94
Gerrit Muller
example from a high volume printer
version: 0.1
March 6, 2013
BS05questionGenerator
Example Technical Budget
global
alignment
accuracy
process
overlay
80 nm
nm
off axis pos.

meas.
accuracy
4 nm
off axis
Sensor
repro
3 nm
stage Al.
pos. meas.
accuracy
4 nm
blue align
sensor
repro
3 nm
system
adjustment
accuracy
2 nm
reticule
15 nm
lens
matching
25 nm
matched
machine
60 nm
single
machine
30 nm
stage
overlay
12 nm
position
accuracy
7 nm
frame
stability
2.5 nm
process
dependency
matching
accuracy
5 nm
stage grid
accuracy
5 nm
alignment
repro
tracking
error X, Y
2.5 nm
sensor
5 nm
interferometer
stability
1 nm
nm
metrology
stability
5 nm

95
Gerrit Muller
tracking
error phi
75 nrad
version: 0.1
March 6, 2013
ASMLoverlayBudget
tracking
error WS
2 nm
tracking
error RS
1 nm
Example of A3 overview
A3 architecture overview of the Metal Printer
throughput in minutes
back-end factory
logistics &
automation
advanced
process
control
wafer
computing &
networking
infrastructure
seed
2. seed sputter
wafer
wafer
metrology
wafer
wafer fab
(front end) wafer
with
ICs
metal
expose
expose
wafer
wafer
printer
stepper
power
chemicals
climate
infrastructure
power, chemicals
consumables, waste
author
version
date last update
3. metal print
4. seed etch
wafer
wafer
REX
3..4
6. exposure or CMP for polymer vias
1..2
design enabling
e.g. CD, separation
throughput
process steps
cost per layer

clean
master
metal
printer
clean wafer
clean
wafer
prefill
prealign
contamination
and climate
X-section control
uptime
reliability
high MTBF
throughput
system cost
integral costs
operational
costs
environmental
impact
robot
consumables
waste
partial graph
many nodes
and connections
are not shown
electric power
clean water
elyte
N2, air
disposal water, air, ...
prealign
customer key drivers
clean
master
master
FOUP
wafer
FOUP
min. line width

overlay
throughput
MTBF
prefill
robot
wafer
FOUP
print
flip
100b
metal printing cell
optics stage
control
chamber
bottom chuck
Fluidic
subsystem
9 vision
3
5 electronics
infrastructure
1
10
0
camera
scoop
stage
control
stage
16base frame +
x, y, stage
granite
electronics
infrastructure
metal printer back side
covers and
hatches
1. Close doors
tprint = t p,prepare + t p,align + t chamber (thickness) + t p,finalize
11
cabling
12
ventilation
air flow
13
contamination
evacuation
4. Process
sensors
measurement
frame
5. Move substrate unloading position
14
machine
control
15
"remote"
electronics rack
frame
process
power
supply
metal printer front side

metal printer subsystems
integrating
subsystems
talign
2. Align
t prepare = t close doors + t move to proximity
3. Move to proximity
tchamber
6. Open doors
tfinalize = t move to unload + t open doors
tprint = t p,overhead + C transfer *thickness
note: original diagram was annotated with actual performance figures

for confidentiality reasons these numbers have been removed
metal printer
functional flow
formula print cycle time
metal printer subsystems, functions, and cycle time model

96
Gerrit Muller
200, 300 mm
x kW
key performance parameters
7 ZUBA
optics
8
stage
wafer size
power
clean room class
floor vibration class
Customer key-drivers and Key Performance Parameters

ZUBA
control
vision
control
a m
b m
c WPH
d hr
200b
metal printing time-line
metal printing cell: systems and performance model
accuracy overlay
early delivery
vs
volume production
7. E-test
back-end factory: systems and process model
system and supersystem

preliminary draft
pattern
resolution
pattern quality
5. coat/develop dielectrics
scope
status
Gerrit Muller
0.1
August 3, 2010
Document meta-information
dual layer only
spin coated
polymer
ICs
stepper
per wafer
1. inspection
Cu
mask
(all numbers have been removed for competitive sensitivity)
version: 0.1
March 6, 2013
LEANoverviewA3

Intro to Systems Engineering Roles, Processes & Organization

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Intro to Systems Engineering Roles, Processes & Organization

Uploaded by

Copyright:

Available Formats

All About Systems Engineering; Introductory Course

material by Gerrit Muller

theory and cases

more theory and exercises

organization and process

case, phasing, V-Model, spiral model,

systems engineer role and

exercise and discussion

deliverables, responsibilties, activities,

exercise and discussion

creating the big picture

customer context, life cycle context,

concept selection, physical

exercise and discussion

design and concept

Introduction Course Program

case, phasing, V-Model, spiral model,

customer context, life cycle context,

All About Systems Engineering; Introductory Course

systems engineer role and

concept selection, physical

Project Systems Engineering Introduction; Phasing,

Project Life Cycle

Phased Project Approach

design and engineering

preparing or updating work

Project Systems Engineering Introduction; Phasing, Process, Organization

Project Systems Engineering Introduction; Phasing, Process, Organization

All Business Functions Participate

marketing, project management, design

Evolutionary PCP model

Project Systems Engineering Introduction; Phasing, Process, Organization

Reuse and Products

Simplified Process View

people, process and technology

Simplified Process; Money and Feedback

people, process and technology

Simplified process diagram for project business

people, process, and technology management

Project Systems Engineering Introduction; Phasing, Process, Organization

Decomposition of the Product Creation Process

Project Systems Engineering Introduction; Phasing, Process, Organization

Operational Organization of the PCP

Prime Responsibilities of the Operational Leader

The Rules of the Operational Game

specification, resources, time

What Service Level to Deliver?

Role and Task of the System Architect

The Role and Task of the System Architect

Deliverables of the System Architect

The Role and Task of the System Architect

Customer and Life-Cycle Needs

System Specification (what will be realized)

(how the system will be verified)

Verification Report (the result of the verification)

The Role and Task of the System Architect

Responsibilities of the System Architect

The Role and Task of the System Architect

Examples of Secondary Responsibilities

business plan, profit

The Role and Task of the System Architect

What does the System Architect do?

The Role and Task of the System Architect