All About Systems Engineering; Introductory Course by Gerrit Muller University of South-Eastern Norway-NISE 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. March 7, 2019 status: preliminary draft version: 0.2 more theory and exercises theory and cases introduction to SE, process, organization case, phasing, V-Model, spiral model, relation with other business disciplines organization and process in practice exercise and discussion product families, products vs projects design and concept selection in practice exercise and discussion example case to wrap-up creating the big picture exercise and discussion roadmapping, key performance parameters capturing customer understanding exercise and discussion customer key drivers, story telling, scenarios and use cases systems engineer role and task deliverables, responsibilties, activities, styles, characteristics system context 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 day 3 day 4 day 1 day 2
100
Embed
All About Systems Engineering; Introductory Course - Gaud System
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
All About Systems Engineering; Introductory Courseby Gerrit Muller
University of South-Eastern Norway-NISE
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 areshown; 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 improveby obtaining frequent feedback. Frequent feedback ispursued by an open creation process. This documentis published as intermediate or nearly mature version toget feedback. Further distribution is allowed as long asthe document remains complete and unchanged.
system contextcustomer context, life cycle context,
stakeholders, needs, concerns,
requirements, story telling, conops, use
cases
system designconcept selection, physical
decomposition, functional
decomposition, qualities, interface
management, budgeting, modeling
day 1
day 2
morning afternoon
morning afternoon
All About Systems Engineering; Introductory Course2 Gerrit Muller
version: 0.2March 7, 2019
SEINTROprogram2day
Project Systems Engineering Introduction; Phasing,Process, Organization
by Gerrit Muller University of South-Eastern Norway-NISEe-mail: [email protected]
www.gaudisite.nl
Abstract
The fundamental concepts and approach to project oriented Systems Engineeringare explained. We look at project phasing, phase transition, processes, andorganization.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: preliminarydraftversion: 0.2
tenderdesign and
engineeringinstallation
operation and
maintenancedisposal
offer
order
acceptance
final payment
Project Life Cycle
tenderdesign and
engineeringinstallation
operation and
maintenancedisposal
offer
order
acceptance
final payment
Project Systems Engineering Introduction; Phasing, Process, Organization4 Gerrit Muller
version: 0.2March 7, 2019
PSEIPprojectLifeCycle
Phased Project Approach
needs
design
verification
engineering
core information
in draft50%
most information
available in
concept
information is stable
enough to use
heavier change control
Legend:
specification
preparing or updating workfull under development
0.
feasibility
1.
definition
2.
system
design
3.
engineering
4.
integration
& test
5.
field
monitoring
tender design and engineering installationoperation and
maintenance
DR DR DR
Project Systems Engineering Introduction; Phasing, Process, Organization5 Gerrit Muller
version: 0.2March 7, 2019PSEIPphases
V-Model
needs
specification
system design
subsystem design
component design
component realization
component test
subsystem test
system test
verification
validation
Project Systems Engineering Introduction; Phasing, Process, Organization6 Gerrit Muller
version: 0.2March 7, 2019TPSEPvModel
All Business Functions Participate
0.
feasibility
1.
definition
2.
system
design
3.
engineering
4.
integration
& test
5.
field
monitoring
sales
logistics
production
service
development & engineering: marketing, project management, design
Project Systems Engineering Introduction; Phasing, Process, Organization7 Gerrit Muller
version: 0.2March 7, 2019
PCPbusinessPhases
Evolutionary PCP model
requirements
specification
designbuild
test and
evaluate
2% of budget (EVO)
2 weeks (XP)
up to 2 months
per cyclus
Project Systems Engineering Introduction; Phasing, Process, Organization8 Gerrit Muller
version: 0.2March 7, 2019
PCPspiral
Reuse and Products
reuse
pro
ducts
reuse
specs
reuse
pro
ducts
reuse
specs
tenderdesign and
engineeringinstallation
operation and
maintenancedisposal
tenderdesign and
engineeringinstallation
operation and
maintenancedisposal
tenderdesign and
engineeringinstallation
operation and
maintenancedisposal
Project Systems Engineering Introduction; Phasing, Process, Organization9 Gerrit Muller
version: 0.2March 7, 2019
PSEIPreuseAndProducts
Simplified Process View
strategyprocess
customer
supplying business
value
product creationprocess
customer oriented (sales,
service, production) process
people, process and technologymanagement process
Project Systems Engineering Introduction; Phasing, Process, Organization10 Gerrit Muller
version: 0.2March 7, 2019
RSPprocessDecomposition
Simplified Process; Money and Feedback
strategyprocess
supplying business
value
people, process and technology
long termknow how
(soft) assets
feed
back
product creation
customer oriented
customer
short term;cashflow!
mid term;cashflow
next year!
Project Systems Engineering Introduction; Phasing, Process, Organization11 Gerrit Muller
version: 0.2March 7, 2019
RSPprocessDecompositionAnnotated
Simplified process diagram for project business
systems architecting
tenderproject
execution
product creation
deploymentcontract systems
products or
components
policy and
planning
people, process, and technology management
Project Systems Engineering Introduction; Phasing, Process, Organization12 Gerrit Muller
version: 0.2March 7, 2019
PPSprojectProcess
Decomposition of the Product Creation Process
Product Creation Process
Operational
Management
Design
ControlMarketing
specification
budget
time
technical profitability
saleability
needs
specification
design
engineering
what is needed
what will be realized
how to realize
how to produce
and to maintain
customer input
customer expectations
market introduction
introduction at customer
feedback
product pricing
commercial structureplanning
progress control
resource
management
risk management
project log
verification
meeting specs
following design
Project Systems Engineering Introduction; Phasing, Process, Organization13 Gerrit Muller
version: 0.2March 7, 2019
PCPdecomposition
Operational Organization of the PCP
subsystem
singleproduct
productfamily
entireportfolio
developersmodule
portfolio
operational
manager
family
operational
manager
(single product)
project
leader
subsystem
project
leader
operational
portfolio
architect
family
architect
product
architect
subsystem
architect
technical
portfolio
marketing
manager
family
marketing
manager
product
manager
commercial
Project Systems Engineering Introduction; Phasing, Process, Organization14 Gerrit Muller
version: 0.2March 7, 2019
PCPoperationalOrganization
Prime Responsibilities of the Operational Leader
Resources Time
Specification
Quality
Project Systems Engineering Introduction; Phasing, Process, Organization15 Gerrit Muller
version: 0.2March 7, 2019
PCPoperationalTriangle
The Rules of the Operational Game
assess risks
determine feasibility
define project
update projectspecification, resources, time
business management project leader
accept or reject
execute project
within normal
quality rules
accept
Project Systems Engineering Introduction; Phasing, Process, Organization16 Gerrit Muller
version: 0.2March 7, 2019
PCPoperationalGame
Operational Teams
Operational Leader
(project leader)
Operational Support
(project manager)
Marketing or
Product Manager
Architect
Application
Manager
Test Engineer
Service Manufacturing
LogisticsSales
Manager Quality
Assurance
Requirements
AnalystSubsystem
Operational
Leaders
Subsystem
ArchitectsTechnology-
Specific
Architects
Development
support
Project Systems Engineering Introduction; Phasing, Process, Organization17 Gerrit Muller
version: 0.2March 7, 2019
PCPconcentricTeams
What Service Level to Deliver?
initial production
expert support
use results
technical
capability
functional
capability
customer support
facility management conventional
maintenance
contract
product
acceptance
and warranty
capability management
performance-based
or service-level
agreement
factory
Project Systems Engineering Introduction; Phasing, Process, Organization18 Gerrit Muller
version: 0.2March 7, 2019
PPSservicesOperationalModel
Systems Engineering Management Plan (SEMP)
How the project will perform the systems engineering process:
· main events and activities
· roles and responsibilities
· work products
· procedures and standards
Bridge between project management and engineering (NASA
2016)
Project Systems Engineering Introduction; Phasing, Process, Organization19 Gerrit Muller
version: 0.2March 7, 2019
PSEIPsemp
Role and Task of the System Architectby Gerrit Muller University of South-Eastern Norway-NISE
The role and the task of the system architect are described in this module.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: preliminarydraftversion: 1.0
The Role and Task of the System Architectby Gerrit Muller Buskerud University Collge
The role of the system architect is described from three viewpoints: deliverables,responsibilities and activities. This description shows the inherent tension in thisrole: a small set of hard deliverables, covering a fuzzy set of responsibilities,hiding an enormous amount of barely visible day-to-day work.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: conceptversion: 2.0
V4aa
IO
design,
brainstorm,
explain
Idea
think,
analyze
listen, talk,
walk around
Blah Blah
write,
consolidate,
browse
present,
meet, teach,
discuss
read,
review
Design
Sp
ec
Report
test,
integrate
assist project leader
with work breakdown,
schedule, risks
travel to
customer,
supplier,
conference
provide
vision and
leadership
Deliverables of the System Architect
Spec DesignReport
Re
po
rt
ReportDesign
Design
SpecSpec
The Role and Task of the System Architect22 Gerrit Muller
version: 2.0March 7, 2019
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
The Role and Task of the System Architect23 Gerrit Muller
version: 2.0March 7, 2019
RSAdeliverablesSpecific
Responsibilities of the System Architect
system
subsystem
Balance Consistency
module
Overview
RequirementSpec
DesignRealization
Decomposition
Integration
modules
FunctionQ
uality
KISS
Elegance
Simple Integrity Fitting
satisfied
stakeholderssystem
context
The Role and Task of the System Architect24 Gerrit Muller
version: 2.0March 7, 2019
RSAresponsibilities
Examples of Secondary Responsibilities
responsibility
business plan, profit
schedule, resources
market, saleability
technology
process, people
detailed designs
primary owner
business manager
project leader
marketing manager
technology manager
line manager
engineers
The Role and Task of the System Architect25 Gerrit Muller
version: 2.0March 7, 2019
RSAsecondaryResponsibilities
What does the System Architect do?
V4aa
IO
design,
brainstorm,
explain
Idea
think,
analyze
listen, talk,
walk around
Blah Blah
write,
consolidate,
browse
present,
meet, teach,
discuss
read,
review
Design
Sp
ec
Report
test,
integrate
assist project leader
with work breakdown,
schedule, risks
travel to
customer,
supplier,
conference
provide
vision and
leadership
The Role and Task of the System Architect26 Gerrit Muller
version: 2.0March 7, 2019RSAactivities
From Detail to Overview
driving views
shared issues
touched details
seen details
real-world facts
10
102
104
107
infinite
Quantityper year
(order-of-
magnitude)
architect
time per
item
100 h
1 h
10 min
meetings
consolidation
in
deliverables
informal
contacts
product details
sampling
scanning
0.1105
0.5
1 sec106
1010
The Role and Task of the System Architect27 Gerrit Muller
version: 2.0March 7, 2019
RSAdetailHierarchy
Reality or Virtuality?
Abstractions only exist for concrete facts.
The Role and Task of the System Architect28 Gerrit Muller
version: 2.0March 7, 2019
Visible Output versus Invisible Work
V4aa
IOIdea
Bla Bla
Design
Sp
ec
Report
system
subsystem
module
Requirement
Spec
Design
Realization
modules
Fun
ctio
nQuality
KISS
Activities
Responsibilities
DeliverablesDec
reas
ing
Vis
ibili
ty
Spec DesignReport
Re
po
rt
Report
Design
Design
Spec
Spec
From Manager perspective
The Role and Task of the System Architect29 Gerrit Muller
version: 2.0March 7, 2019
RSApyramid
The Awakening of a System Architectby Gerrit Muller University of South-Eastern Norway-NISE
The typical phases of a system architect development are described, beginningat the fundamental technology knowledge, with a later broadening in technologyand in business aspects. Finally the subtlety of individual human beings is takeninto account.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: conceptversion: 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
business,
application insight
process insight
psychosocial
skills
The Awakening of a System Architect31 Gerrit Muller
version: 1.1March 7, 2019
MATsystemArchitectGrowth
Generalist versus Specialist
sp
ecia
list
generalist
root
knowledge
breadth ofknowledge
dep
th o
fkn
ow
led
ge
The Awakening of a System Architect32 Gerrit Muller
version: 1.1March 7, 2019
MATgeneralistVsSpecialist
Generalists and Specialists are Complementary
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
generalistgeneralist
breadth ofknowledge
dep
th o
fkn
ow
led
ge
The Awakening of a System Architect33 Gerrit Muller
version: 1.1March 7, 2019
MATcomplementaryExpertises
Spectrum from Specialist to System Architect
all-
rou
nd
sp
ecia
list systems architect
sp
ecia
list
root
knowledge
aspect
architect
breadth ofknowledge
dep
th o
fkn
ow
led
ge
The Awakening of a System Architect34 Gerrit Muller
version: 1.1March 7, 2019
MATfromSpecialistToSystemArchitect
Architecting Interaction Stylesby Gerrit Muller University of South-Eastern Norway-NISE
A system architects needs skills to apply different interactions styles, dependingon the circumstances. This document discusses the following interaction styles:provocation, facilitation, leading, empathic, interviewing, white board simulation,and judo tactics.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: draftversion: 0.2
provocation
facilitation
leading
empathic
interviewing
whiteboard simulation
judo tactics
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
take the viewpoint of the stakeholder acknowledge the stakeholder's feelings, needs, concerns
investigate by asking questions
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
provocation
facilitation
leading
empathic
interviewing
whiteboard simulation
judo tactics
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
take the viewpoint of the stakeholder acknowledge the stakeholder's feelings, needs, concerns
investigate by asking questions
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 Interaction Styles36 Gerrit Muller
version: 0.2March 7, 2019
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 travele-mail mate.Present (max. 2 flips) the result and the process (the relation and interaction ofthe three roles).
Exercise Role and Task System Architect37 Gerrit Muller
version: 0.2March 7, 2019MRSAexercise
Role and Task of a System Architect
Deliverables
Spec DesignReport
Re
po
rt
ReportDesign
Design
SpecSpec
Responsibilities
system
subsystem
Balance Consistency
module
Overview
RequirementSpec
DesignRealization
Decomposition
Integration
modules
FunctionQ
uality
KISS
Elegance
Simple Integrity Fitting
satisfied
stakeholderssystem
context
Daily ActivitiesV4aa
IO
design,
brainstorm,
explain
Idea
think,
analyze
listen, talk,
walk around
Blah Blah
write,
consolidate,
browse
present,
meet, teach,
discuss
read,
review
Design
Sp
ec
Report
test,
integrate
assist project leader
with work breakdown,
schedule, risks
travel to
customer,
supplier,
conference
provide
vision and
leadership
From detail to overview
driving views
shared issues
touched details
seen details
real-world facts
10
102
104
107
infinite
Quantityper year
(order-of-
magnitude)
architect
time per
item
100 h
1 h
10 min
meetings
consolidation
in
deliverables
informal
contacts
product details
sampling
scanning
0.1105
0.5
1 sec106
1010
Exercise Role and Task System Architect38 Gerrit Muller
version: 0.2March 7, 2019
Personal characteristics of a System Architect
Typical growth of a Architectroot
technical
knowledge
generalist
technical
knowledge
business,
application insight
process insight
psychosocial
skills
Generalist vs Specialist
sp
ecia
list
generalist
root
knowledge
breadth ofknowledge
dep
th o
fkn
ow
led
ge
Complementary Roles
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
sp
ecia
list
generalistgeneralist
breadth ofknowledge
dep
th o
fkn
ow
led
ge
Role Spectrum
all-
rou
nd
sp
ecia
list systems architect
sp
ecia
list
root
knowledge
aspect
architect
breadth ofknowledge
dep
th o
fkn
ow
led
ge
Exercise Role and Task System Architect39 Gerrit Muller
version: 0.2March 7, 2019
Module Requirementsby Gerrit Muller University of South-Eastern Norway-NISE
This module addresses requirements: What are requirements? How to find,select, and consolidate requirements?
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: conceptversion: 1.4
Fundamentals of Requirements Engineeringby Gerrit Muller University of South-Eastern Norway-NISE
Requirements engineering is one of the systems engineering pillars. In thisdocument we discuss the fundamentals of systems engineering, such as thetransformation of needs into specification, the need to prescribe what rather thanhow, and the requirements when writing requirements.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: conceptversion: 0.1
system seen as black box
inputs outputsfunctions
quantified characteristics
restrictions, prerequisites
boundaries, exceptions
standards, regulations
interfaces
Definition of “Requirement”
Requirements describing the needs of the customer:
Customer Needs
Requirements describing the needs of the company itself
over the life cycle: Life Cycle Needs
Requirements describing the characteristics of the final
resulting system (product): System (Product)
Specification
The requirements management process recursively
applies this definition for every level of decomposition.
Fundamentals of Requirements Engineering42 Gerrit Muller
version: 0.1March 7, 2019REQdefinition
Flow of Requirements
What
What
How
customer needs:
What is needed by the customer?
product specification:
What are we going to realize?
system design:
How are we going to realize the product?
What
How
What
How
What
How
What are the subsystems we will realize?
How will the subsystems be realized?
What
How
What
How
What
How
What
How
What
How
What
How
up to "atomic" components
choices
trade-offs
negotiations
Fundamentals of Requirements Engineering43 Gerrit Muller
version: 0.1March 7, 2019
REQwhatWhatHow
System as a Black Box
system seen as black box
inputs outputsfunctions
quantified characteristics
restrictions, prerequisites
boundaries, exceptions
standards, regulations
interfaces
Fundamentals of Requirements Engineering44 Gerrit Muller
The basic “CAFCR” reference model is described, which is used to describea system in relation to its context. The main stakeholder in the context is thecustomer. The question “Who is the customer?” is addressed.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: draftversion: 0.4
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
drives, justifies, needs
enables, supports
Customer
objectives
Application Functional Conceptual Realization
The “CAFCR” model
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
drives, justifies, needs
enables, supports
Customer
objectives
Application Functional Conceptual Realization
Short introduction to basic “CAFCR” model49 Gerrit Muller
version: 0.4March 7, 2019
CAFCRannotated
Integrating CAFCR
Customer
objectives
Application Functional Conceptual Realization
intention
constraintawareness
objectivedriven
contextunderstanding
oppor-tunities
knowledgebased
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
Short introduction to basic “CAFCR” model50 Gerrit Muller
version: 0.4March 7, 2019
MSintegratingCAFCR
CAFCR can be applied recursively
System
(producer)
Customer
BusinessDrives
Enables
Customer's
Customer
BusinessDrives
Enables
ConsumerDrives
Enables
Value Chain
larger scope has smaller
influence on architecture
Short introduction to basic “CAFCR” model51 Gerrit Muller
version: 0.4March 7, 2019
CAFCRrecursion
Market segmentation
geographical
business model profit, non profit
examples
economics
USA, UK, Germany, Japan, China
high end versus cost constrained
consumers youth, elderly
segmentation
axis
outlet retailer, provider, OEM, consumer direct
Short introduction to basic “CAFCR” model52 Gerrit Muller
version: 0.4March 7, 2019
BCAFCRcustomerSegmentation
Example of a small buying organization
decision maker(s) purchaser
maintainer
operator
user
CEO
CFO
CTO
CIO
department head
Who is the customer?
CMO
CEO: Chief Executive Officer
CFO: Chief Financial Officer
CIO: Chief Information Officer
CMO: Chief Marketing Officer
CTO: Chief Technology Officer
Short introduction to basic “CAFCR” model53 Gerrit Muller
version: 0.4March 7, 2019
BCAFCRwhoIsTheCustomer
CAFCR+ model; Life Cycle View
Customer
objectives
Application Functional Conceptual Realization
Life cycleoperations
maintenance
upgrades
development
manufacturing
installation
sales, service, logistics, production, R&D
Short introduction to basic “CAFCR” model54 Gerrit Muller
version: 0.4March 7, 2019
BCAFCRplusLifeCycle
Key Drivers How Toby Gerrit Muller University of South-Eastern Norway-NISE
The notion of ”business key drivers” is introduced and a method is described tolink these key drivers to the product specification.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
An elicitation method for needs is described using many different viewpoints. Aselection process with a coarse and a fine selection is described to reduce thespecification to an acceptable and feasible subset.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: draftversion: 0 bottom-up
top-down
key-drivers(customer, business)
roadmap(positioning and trends in time)
competition(positioning in the market)
"ideal" reference design
prototyping, simulation(learning vehicle)
bottom-up(technological opportunities)
existing systems
operational drivers(logistics, production, etc.)
NeedsContinued
Product Creation
Process
Feedback
regulations
Complementary Viewpoints to Capture Requirements
bottom-up
top-down
key-drivers(customer, business)
roadmap(positioning and trends in time)
competition(positioning in the market)
"ideal" reference design
prototyping, simulation(learning vehicle)
bottom-up(technological opportunities)
existing systems
operational drivers(logistics, production, etc.)
NeedsContinued
Product Creation
Process
Feedback
regulations
Requirements Elicitation and Selection61 Gerrit Muller
version: 0March 7, 2019
REQviewpoints
Requirement Selection Process
customer needs
operational needs
roadmap
strategy
competition
selection process
product specification
need
characterization
requirement
phasing
Technology, People, Process
costs and constraints
Requirements Elicitation and Selection62 Gerrit Muller
version: 0March 7, 2019REQselection
Simple Qualification Method
important
urgent
effort
value
do
don't discuss
discuss
do
don't discuss
discuss
Requirements Elicitation and Selection63 Gerrit Muller
version: 0March 7, 2019
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 (don't fall in spreadsheet trap)
Requirements Elicitation and Selection64 Gerrit Muller
version: 0March 7, 2019
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 Capturing65 Gerrit Muller
version: 0March 7, 2019MREQexercise
Needs and Requirements
Needs, Specification, RequirementsRequirements describing the needs of the customer:
Customer Needs
Requirements describing the needs of the company itself
over the life cycle: Life Cycle Needs
Requirements describing the characteristics of the final
resulting system (product): System (Product)
Specification
The requirements management process recursively
applies this definition for every level of decomposition.
A story is an easily accessible story or narrative to make an application live. Agood story is highly specific and articulated entirely in the problem domain: thenative world of the users. An important function of a story is to enable specific(quantified, relevant, explicit) discussions.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: conceptversion: 1.2
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
story caseanalyze
design
designanalyze
design
a priori solution knowledgemarket
vision
Customer
objectives
Application Functional Conceptual Realization
From story to design
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
story caseanalyze
design
designanalyze
design
a priori solution knowledgemarket
vision
Customer
objectives
Application Functional Conceptual Realization
Story How To69 Gerrit Muller
version: 1.2March 7, 2019
SHTfromStoryToDesign
Example story layout
A day in the life of Bob
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.
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.
draft or sketch of
some essential
applianceca. half a page of
plain English text
Yes
or
No
that is the question
Story How To70 Gerrit Muller
version: 1.2March 7, 2019
SHTexampleStoryLayout
Points of attention
• purpose
• scope
• viewpoint, stakeholders
• visualization
• size (max 1 A4)
• recursive decomposition, refinement
What do you need to know for
specification and design?
“umbrella” or specific event?
Define your stakeholder and viewpoint
f.i. user, maintainer, installer
Sketches or cartoon
Helps to share and communicate ideas
Can be read or told in few minutes
Story How To71 Gerrit Muller
version: 1.2March 7, 2019
SHTattentionPoints
Criteria for a good story
• accessible, understandable
• valuable, appealing
• critical, challenging
• frequent, no exceptional niche
• specific
"Do you see it in front of you?"
attractive, important
"Are customers queuing up for this?"
"What is difficult in the realization?"
"What do you learn w.r.t. the design?"
names, ages, amounts, durations, titles, ...
"Does it add significantly to the bottom line?"
Customer
objectives
Application
Functional
Conceptual
Realization
Customer
objectives
Application
Application
Application
Story How To72 Gerrit Muller
version: 1.2March 7, 2019
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 Betty’s 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-folk’s
home. It’s summer now and the tables are outside. With all those people there it’s 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 Mozart’s 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
it’s as if a butcher’s knife cuts through my head. It’s 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.
source: Roland Mathijssen
Embedded Systems Institute
Eindhoven
Story How To73 Gerrit Muller
version: 1.2March 7, 2019
SHTexample
Value and Challenges in this story
Challenges in this story:
Intelligent hearing instrument
Battery life at least 1 week
No buttons or other fancy user interface on the hearing instrument,
other than a robust On/Off method
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
Conceptual
Realization
Customer
objectives
Application
Value proposition in this story:
quality of life:
active participation in different social settings
usability for nontechnical elderly people:
"intelligent" system is simple to use
loading of batteries
Story How To74 Gerrit Muller
version: 1.2March 7, 2019
SHTexampleCriteria
Concept Selection, Set Based Design and Late DecisionMaking
by Gerrit Muller University of South-Eastern Norway-NISEe-mail: [email protected]
www.gaudisite.nl
Abstract
We discuss a systems design approach where several design options aremaintained concurrently. In LEAN Product Development this is called set-baseddesign. Concentioanl systems engineering also promotes the concurrent evalu-ation of multiple concepts, the so-called concept selection. Finally, LEAN productdevelopment advocates to keep options open as long as feasible; the so-calledlate decision making.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
Many stakeholder concerns can be specified in terms of qualities. These qualitiescan be viewed from all 5 “CAFCR” viewpoints. In this way qualities can be usedto relate the views to each other.The meaning of qualities for the different views is described. A checklist ofqualities is provided as a means for architecting. All qualities in the checklistare described briefly.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
The fundamental concepts and approach system partitioning are explained. Welook at physical decomposition and functional decomposition in relation to supplychain, lifecycle support, project management, and system specification anddesign.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
March 7, 2019status: preliminarydraftversion: 0.2
system
subsystem 1
subsystem 2
subsub
system A
subsub
system B
subsub
system A
subsub
system B
subsub
system N
subsub
system N
atomic
part
atomic
part
atomic
part
subsystem n
subsub
system A
subsub
system B
subsub
system N
Parts, Dynamics, Characteristics
parts
characteristics
dynamics
interact
results in
prime interest
of organization
prime interest
of customer
prime system
responsibility
functionality
System Partitioning Fundamentals85 Gerrit Muller
version: 0.2March 7, 2019
SPFpartsDynamicsCharacteristics
Engineering
engineeringsystem specification
system design
parts data base
production procedures
qualification procedures
system documentation
procurement
production
installation
lifecycle
support
quality
assurance
ERP PDMSCMCAD
mechanical
electrical
design
database
source
code
management
resource
planning,
e.g. SAP
product
data
management
doc
DB
project
documents
know-
ledge
DB
source data
engineering knowledge
past
experience
System Partitioning Fundamentals86 Gerrit Muller
version: 0.2March 7, 2019
SPFengineering
Example Physical Decomposition
Fluidic
subsystem
chamber
bottom chuck
electronics
infrastructure
process
power
supply
1
3
2
4
5electronics
infrastructure1 5granite
ZUBA
stage
frame
base frame +
x, y, stage
stage
control
ZUBA
control
optics
stagescoop
cameravision
op
tics s
tag
e
co
ntr
ol
vision
control
6
7
8
9
10
cabling
covers and
hatches
ventilation
air flow
contamination
evacuation
sensors
measurement
frame
machine
control
"remote"
electronics rack
10
11
12
13
14
15
?
back side view front side view integrating
System Partitioning Fundamentals87 Gerrit Muller
version: 0.2March 7, 2019
REPLIsubsystemsAll
Partitioning is Applied Recursively
system
subsystem 1
subsystem 2
subsub
system A
subsub
system B
subsub
system A
subsub
system B
subsub
system N
subsub
system N
atomic
part
atomic
part
atomic
part
subsystem n
subsub
system A
subsub
system B
subsub
system N
System Partitioning Fundamentals88 Gerrit Muller
version: 0.2March 7, 2019SPFrecursion
Software plus Hardware Decomposition
tunerframe-
bufferMPEG DSP CPU RAM
drivers scheduler OS
etc
audio video TXTfile-
systemnetworkingetc.
view PIP
browseviewport menu
adjustview
TXT
hardware
driver
applications
services
toolboxes
domain specific generic
signal processing subsystem control subsystem
System Partitioning Fundamentals89 Gerrit Muller
version: 0.2March 7, 2019
CVconstructionDecomposition
Guidelines for Partitioning
the part is cohesive
the coupling with other parts is minimal
the part is selfsustained for production and qualification
clear ownership of part
functionality and technology belongs together
minimize interfaces
can be in conflict with cost or space requirements
e.g. one department or supplier
System Partitioning Fundamentals90 Gerrit Muller
version: 0.2March 7, 2019
SPFpartitioningGuidelines
How much self-sustained?
main
function
power
conversion
power
distribution
power
stabilization
coolingEMC
shielding
production
support
adjustment
support
qualification
support
control
interface
control
electronics
mechanical
package
control SWapplication
SWHMI SW
cost/speed/space
optimization
How self sustained should a part be?
trade-off:
logistics/lifecycle/production
flexibility
clarity
System Partitioning Fundamentals91 Gerrit Muller
version: 0.2March 7, 2019
SPFselfSustained
Decoupling via Interfaces
part
e.g. pressure
and flow
regulator
part
e.g. pipe
part
e.g. pipe
hydrocarbon
interface
power
interface
control
interface
e.g. CAN
mechanical
mounting interfaceother part with
same interfaces
can replace
original
System Partitioning Fundamentals92 Gerrit Muller
version: 0.2March 7, 2019
SPFinterfaceDecoupling
The Ideal Modularity
System is composed
by using standard interfaces
limited catalogue of variants (e.g. cost performance points)