SYSTEM DESIGN

Post Graduite of
Industrial Engineering
Pasundan university
Course Outline – Week 1
1)Introduction to Systems Engineering
2)Systems Engineering and Procurement
3)Concept of Operations
4)Requirements Engineering
5)System Design Practices

5 2
-
Learning Objectives

 Define system design

 List good design practices
 Describe the attributes of design
alternatives

5 3
-
 Systems Engineering Life Cycle

Concept Operations &

of Operations Maintenance
High Level
Requirements System
Detailed Verification
Requirements
High Level Subsystem Integration
Definition Design Verification Verification
and Detailed Integration & and
Decomposition Design Test Validation

Implementation

Time

5 4
-
What is Design??
 Design is the technical information
resulting from translating
requirements for a product into a
complete description of the product.*
 Two major categories of design:
 High Level
 Detailed
*EIA 649 National Consensus
Standard for
5 5 Configuration Management
-
High Level Design
 Transition between requirements
and detailed design.
 From What to How!!
 Definition of architecture
 Sub-system Definition
 Sub-system Verification Plan
development
 Interface Identification
5 6
-
Detailed Design
 Completes the description of the
product at the Component Level
 Configuration Item Identification
 Component Level Specifications
 Code Specifications
 Hardware Specifications
 Verification Procedures

5 7
-
Who Does Design?
 High level Design is primarily a Systems
Engineering Activity – Involvement by the
implementation Team is essential
 Detailed Design is primarily an
Implementation Team activity –
Involvement by the Systems Engineering
team essential

5 8
-
What is System Design?
Appropriate selection of system
components and their
interconnection so as to meet
the system requirements
and
The preparation of specifications
that describe the design
5 9
-
System Design –
Who is Responsible?
Type of Concept of Requirement Design Implement
Contract Ops.
Consultant Agency or Agency or Agency or Contractor
Contractor Consultant Consultant Consultant

Systems Agency or Agency or Contractor Contractor

Manager Contractor Contractor

Design Agency or Contractor Contractor Contractor

Build Contractor

5 10
-
 System Design Process
Allocation of Develop
Requirements to specifications
subsystems
No

Evaluate Will
Analyze
alternative an off-the-
alternative
implementations shelf
designs
solution
Centralized Signs work?
Vs. Detectors Yes
Distributed Comm Routing Develop
etc. system
selection
criteria
5 11
-
Good System Design
Practices
 Are based on requirements
 Consider multiple alternatives
 Use off-the-shelf solutions
wherever possible
 Develop “simple” solutions to
design problems
 Pay attention to integration issues
5 12
-
Why Might a Project Team
Consider Too Few
Alternatives?

 Tendency to “go with what’s

comfortable”
 Lack of knowledge of what’s
available
 Influenced by system suppliers
 Prejudging the answer
5 13
-
Generating Alternatives

 Technology surveys
 Employ professional assistance
 Review of similar systems
 Brainstorming
 Formal requests for information
from system suppliers
5 14
-
Example - Freeway
Management
Alternatives
Summary of requirements:
 Functions include traffic monitoring,
DMS, HAR, ramp metering
 Statewide functions – coordinated
operation of multiple districts
 Interface with legacy systems
5 15
-
Freeway Management
Example - continued
Alternatives:
 Do-nothing
 Off-the-shelf
 Customized system
 Centralized
 Distributed
5 16
-
Centralized vs. Distributed
 A key consideration when
designing a new system
 Centralized – All system control is
located at a single site
 Distributed – System can be
controlled from multiple sites.

5 17
-
A Centralized System for
XYZ
The State of Lincoln I-905

I-994

Control
Center
er
Ri v
a ms
Communication Ad
The State of Harrison
Field
Equipment

5 18
-
A Decentralized System
for XYZ
The State of Lincoln I-905

I-994

er
Ri v
Communication a ms
Ad
Field The State of Harrison
Equipment
Control
Center 5 19
-
Assessing Alternatives
 Outline strengths and weaknesses
 Examine technical and operational
feasibility
 Evaluate institutional compatibility
 Estimate life cycle costs
 Evaluate against constraints
5 20
-
Freeway Management -
Assessing Alternatives
Alternative Level of Risk Comments
Do-nothing No risk No congestion
relief

Off-the-shelf Moderate risk Functionality

predefined
Centralized High risk Simplest
design
Distributed Highest risk Statewide
applicability
5 21
-
 Freeway Management –
Assessing Cost
Cost tion
Im p le m e n ta

Operations and
Maintenance

Alternatives
Do Nothing Off-the- Custom Custom
Shelf Centralized Distributed

5 22
-
Consider the “ilities”
 Reliability - How often do failures occur?
 Maintainability - How long does it take
to repair failures?
 Availability - What % of the time is the
system operational?
 Affordability – Is the system scaled to the
agency’s resources (staffing, budget,
etc.)?
5 23
-
Reasons for Using Off-the-
shelf Systems
 Ensures acquisition of a more mature
product
 Decreases risk in operating and maintenance
stages
 May reduce life cycle costs
 Access to support from supplier
 Availability of upgrades and bug fixes

5 24
-
The Truth About the Off-
The-Shelf System
Alternatives
 Developers will use previously
developed software
 Off-the-shelf systems invariably
require modification:
 New drivers
 Tailored user interfaces
 Legacy interfaces
 Off-the-shelf software still has bugs
5 25
-
The Answer is to Select
the Appropriate Developer
 Select an experienced developer
 Require a proven knowledge of systems
engineering techniques

 Ignore cosmetic factors (friendship, local

presence, traffic engineering expertise,
etc.)

 Use appropriate selection technique (avoid

low bid)
5 26
-
Keep It Simple
 Use off-the-shelf
 Avoid unique features unless they
are REALLY needed
 Consider the “ilities”
 Reliability
 Maintainability
 Availability
5 27
-
 Open Discussion

Comparing System Design

Alternatives for the XYZ
System
Consider Operating
Conditions

 Modes of operation
 Available facilities (space, HVAC, etc.)
 Staff capabilities and availability
 Environment (weather)
 Concept of operations
 Training and documentation needs
5 29
-
Consider Standards
 ITS standards are being developed for
 Communication with field equipment
 Communication between computers
 Definition of database contents
 Can minimize the number of unique
interfaces required
 Assist in connections with other systems

5 30
-
The Bridge between
Requirements and
Specifications
Alternatives
Analysis
(requirements)

(specifications)
How
What

5 31
-
Rules for Developing
Specifications

 At least one (sometimes more)

specification for each requirement
 Organize according to system and
subsystem
 Same rules of grammar as those
used for the requirements.

5 32
-
Functional Specifications

 Functional specifications should be

used for low-bid procurements
 Non-functional specifications
should be used for all other types
of procurements

5 33
-
Example of Decomposition
 High level requirement – The system shall be
capable of measuring traffic volumes in each
lane.
 Specifications – This requirement influences
the following specifications:
 Detector type
 Field equipment software
 Central software
 Graphic displays
 Reports
 Database

5 34
-
Typical High Level
Specifications
 The system shall be managed by
the Microsoft NT operating system.
 Oracle shall be used as
the
database management system.
 Traffic monitoring data shall be
collected using radar detectors.

5 35
-
Design Specifications

 Specifications are developed

based on requirements and the
system design
 Specifications define the “how”
 Specifications follow the same
rules of “grammar” as the
requirements
5 36
-
Differentiating Between
Requirements and
Specifications
 The system shall monitor average
speeds on all freeways.
 The system shall display the status of
all field equipment.
 All computers shall be connected to a
single local area network.
 The user interface shall permit
zooming using mouse and keyboard
controls.
5 37
-
 System Design and the
Timeline
Analyze Evaluate Develop
Make vs. Buy
Alternative Alternative Specifications
Decisions
Architectures Implementations

Concept of High Level Detailed Develop & Acceptance

OperationsReq.’ments
Design Design Deploy Test

Time

5 38
-
Documenting the Design
 Scope
 Referenced Documentation           
 Overview of Design
 Detailed Design Specifications
 Systems Engineering Processes

See Appendix A for detailed outline

5 39
-
Learning Objectives

 Define system design

 List good design practices
 Describe the attributes of design
alternatives

5 40
-
 Systems Engineering Life Cycle

Concept Operations &

of Operations Maintenance
High Level
Requirements System
Detailed Verification
Requirements
High Level Subsystem Integration
Definition Design Verification Verification
and Detailed Integration & and
Decomposition Design Test Validation

Implementation

Time

5 41
-