Principles of

Engineering System Design

Dr T Asokan

asok@iitm.ac.in
 Principles of
Engineering System Design

Lecture 4: System Design Process

Dr T Asokan
asok@iitm.ac.in
044-2257 4707

T Asokan
 • What needs are we trying to fill?
•• FFocus Need
ocus of
ofSSys
ystems
tems • What is wrong with the current s ituation?
• Is the need clearly articulated?
EEngineering
ngineering
• Who are the intended us ers ?
–– FFrom
romOOriginal
riginalNeed
Need Operations Concept • How will they us e our products ?
–– TTooFFinal
inalPProduct
roduct
• How is this different from the pres ent?

•• TThe
heWhole
Whole • What s pecific capability will we provide?
Functional Requirements • T o what level of detail?
SSys tem
ys tem • Are element interfaces well defined?
•• TTheheFFull
ullSSys
ystem
tem
LLife • What is the overall plan of attack?
ifeCCycle
ycle System Architecture • What elements make up the overall approach?
• Are thes e complete, logical, and cons is tent?

• Which elements addres s which requirements ?

Allocated Requirements • Is the allocation appropriate?
• Are there any unneces s ary requirements ?

• Are the details correct?

••FFocus
ocus of
ofCComponent
omponent Detailed Design
• D o they meet the requirements ?
EEngineering
ngineering • Are the interfaces s atis fied?

••OOnnDDetailed
etailedDDes
esign
ign Implementation • Will the s olution be s atis factory in terms
••And
AndImplementation
Implementation
of cos t and s chedule?
• C an we reus e exis ting pieces ?

• What is our evidence of s ucces s ?

Test & Verification
• Will the cus tomer be happy?
• Will the us ers ’ needs be met?
 N e e d • W h a t n e e d s a r e
w e t r y i n g t o f i l l ?
• • F F oo c c uu s s oo f f • W h a t i s w r o n g
S S y y s s t te e m m s s w i t h t h e c u r r e n t
E E n n g g i ni n e e e e r ri ni n g g s i t u a t i o n ?
• I s t h e n e e d c l e a r l y
a r t i c u l a t e d ?
–– F F r ro o m m
O O r ri gi g i ni n a a l l O p e r a t i o n s • W h o a r e t h e
C o n c e p t i n t e n d e d u s e r s ?
NN e e e e d d • H o w w i l l t h e y u s e
o u r p r o d u c t s ?
• H o w i s t h i s
–– T T oo F F i ni n a a l l d i f f e r e n t f r o m t h e
P P r ro o d d u u c c t t p r e s e n t ?

F u n c t i o n a l • W h a t s p e c i f i c
• • T T hh e e R e q u i r e m e n t s c a p a b i l i t y w i l l w e
WW h h o o l el e p r o v i d e ?
S S y y s s t te e m m • T o w h a t l e v e l o f
d e t a i l ?
• A r e e l e m e n t
i n t e r f a c e s w e l l
• • T T hh e e F F u u l ll l d e f i n e d ?
S S y y s s t te e m m
L L i fi fe e C C y y c c l el e S y s t e m • W h a t i s t h e o v e r a l l
A r c h i t e c t u r e p l a n of a t t a c k ?
• W h a t e l e m e n t s
m a k e u p t h e
o v e r a l l a p p r o a c h ?
• A r e t h e s e
c o m p l e t e , l o g i c a l ,
a n d c o n s i s t e n t ?

A l l o c a t e d • W h i c h e l e m e n t s
R e q u i r e m e n t s a d d r e s s w h i c h
r e q u i r e m e n t s ?
• I s t h e a l l o c a t i o n
a p p r o p r i a t e ?
• A r e t h e r e a n y
u n n e c e s s a r y
r e q u i r e m e n t s ?
• • F F oo c c uu s s oo f f
C C o o mm p p o o n n e e n n t t • A r e t h e d e t a i l s
E E n n g g i ni n e e e e r ri n D e t a i l e d
i n g g c o r r e c t ?
• • OO n n D e s i g n • D o t h e y m e e t t h e
D D e e t at a i li el e d d r e q u i r e m e n t s ?
D D e e s s i gi g n n • A r e t h e i n t e r f a c e s
s a t i s f i e d ?
• • AA nn dd
I Im m p p l el e m m e e I m p l e m e n t a t i o n • W i l l t h e s o l u t i o n
n n t ta a t ti oi o n n b e s a t i s f a c t o r y i n
t e r m s
o f c o s t a n d
s c h e d u l e ?
• C a n w e r e u s e
e x i s t i n g p i e c e s ?

T e s t & • W h a t i s o u r
V e r i f i c a t i o n e v i d e n c e o f
s u c c e s s ?
• W i l l t h e c u s t o m e r
b e h a p p y ?
• W i l l t h e u s e r s ’
n e e d s b e m e t ?
 Six functions of Design Process

1. Define system level design problem :

Originating requirements development
2. Develop the system functional architecture
3. Develop the system physical architecture
4. Develop the system operational architecture

5. Develop the interface architecture

6. Define the qualification system for the system
 Define
Define
Requirements

Retirement, Requirements
Disposal &
Replacement Investigate
Alternatives
Retirement, The system
Disposal &
Replacement Operation,
life cycle Investigate
Maintenance Alternatives
The system
& Evaluation
Full-Scale
Design

life cycle
Integration
& Test Implementation

Operation,
LifeMaintenance
cycle Full-Scale
& Evaluation
Development phase, manufacturing phase, Design
deployment
phase, training phase, operation or maintenance phase,
refinement, retirement phase.
Integration
& Test Implementation
 Define System Level Design Problem

• Operational Concept
• External Systems
• Originating Requirements
• Objectives hierarchy
• Documentation
• Requirement management
1. Define System Level Design Problem

Major Input: Stake holders’ inputs

Major output: Originating requirements,

Operational concept
• An operational concept is a vision for what the system
is (in general terms). It is a statement of mission
requirements, and a description of how the system will
be used.

It includes:
•Information about how the system will be developed,
operated and retired (from the perspective of the system’s
stakeholders).
•A collection of scenarios.
•Systems interaction with other systems.
Operational concepts for landing
on the moon

T Asokan ED309
 Operational Concept Scenario-
Example: Passenger lift
Scenario 1
Passengers (including mobility, hearing, visually challenged)
request up service, receive feed back that their request was
accepted, receive input that the elevator car is
approaching, and then that an entry opportunity is
available, enter elevator car, request floor, receive feedback
that their request was accepted, receive feedback that the
door is closing, receive feedback about what floor the
elevator is stopping, receive feedback that an exit
opportunity is available, and exit elevator with no physical
impediments.

T Asokan ED309
Scenario 2 Emergency
situation

Scenario 3 Fire
Auto-close

Scenario 4 Breakdown
Overload

Scenario 5 maintenance
 Scenario Description
Input/Output Trace Passenger Elevator
Up service request

feedback
Floor request

Input/output
trace for Exit
T Asokan ED309
scenario 1 opportunity
 External Systems Diagram

It is the Model of the interaction of the system with other

systems (external) in the relevant contexts, thus providing
a definition of the system’s boundary in terms of the
system’s inputs and outputs.

Purpose: Explicitly define the systems boundary and

needed interfaces.

T Asokan ED309
Systems/Mechanisms System Function
1. Elevator System Provide elevator services
2. Passengers Request and use elevator services
3. Maintenance personnel Maintain elevator services
4. Building Provide structural support
 External Systems Diagram
Building regulations
Request
Elevator
Services

Provide
Use Elevator Elevator
Services Services
Maintain Provide
Elevator structural
Services support

Elevator Maintenance Building

Passengers system Personnel
T Asokan ED309
 Objectives Hierarchy

The hierarchy of objectives that are important to the

system’s stakeholders in a value sense.

• Stakeholders would be willing to pay to obtain

increased performance on any of these objectives.
• Developed by defining the natural subsets of the
fundamental objectives

T Asokan ED309
• Usually has two to five levels. Additional information
like value weights, value curves etc. are added for
each objective.

• Acts as a corner stone for trade-off studies

• To be developed for each phase of the life cycle of

the system.

• An important tool in the decision making process

T Asokan ED309
 Requirements categories
Originating requirements (OR):
Derived from operational needs, operational requirements
are those top-level statements defined in language that is
understandable to stakeholders, leaving substantial room
for design flexibility.
Derived requirements
Defined by system engineering team in engineering terms
during the design process.

Mission
requirements
Originating
requirements
T Asokan ED309
Implied Requirements
Requirements not specifically identified in the OR but can
be inferred based upon the available information.

Emergent Requirements
Requirements that are not even hinted at in the OR
but whose presence is made known by stakeholders
later in the system engineering process.

System

requirements
Derived
Requirements
Component
Requirements
Configuration Item
Requirements
 Mission
requirements
Originating
requirements
System

requirements
Derived
Requirements
Component
Requirements
Configuration Item
Requirements