Why should we use

the System Engineering?

compiled by Setyo U. Soekarsono

 System Engineering
“Build the right system, build the system right”
 System engineering considers the whole
problem, the whole system, and the whole
system lifecycle - from concept to disposal,
“from lust to dust”

concept Utilization

Support/
evolution
Development
Retirement
Production
System Life Cycle
21/2/06 Setyo U. Soekarsono 2
 Traditional VS Concurrent

Concurrent Engineering (CE)

approach is inherent in
the SE Process

21/2/06 Note:
IPDT = Integrated Product Setyo U. Soekarsono
Development Team 3
 Why should we use SE? The Benefits
 Specific benefits:
 Shorter product development cycle time (reduce by 60%)
 Engineering change orders reduced by 50%
 Redesign and rework effort reduced by as much as 75%
 Manufacturing costs reduced by as much as 40%
 Overall save 10 – 20% of the project budget

• General benefits
– Reduced non-recurring costs
– Reduced life cycle costs
– A more competitive product
– A process that is compliant with the expectations and
requirements of external customers
21/2/06 Setyo U. Soekarsono 4
James Martin, Systems Engineering Guidebook, 1997
 Why should we use SE? The Benefits

 Clear input untuk setiap tahapan

 Setiap bagian bisa bekerja sesuai jadwal
 Output bisa di telusuri kembali.
 Hasil tidak akan menyimpang dari objektif awal
 System pendukung telah siap pada waktunya

21/2/06 Setyo U. Soekarsono 5

 Systems Engineering Contributions
 Systems engineering brings two elements to a
project that are not usually present
 A disciplined focus on the
 end product,
 its enabling products, and
 its internal and external operational environment
(i.e., a System View)
 A consistent vision of stakeholders’ expectations
independent of daily project demands (i.e., the
System’s Purpose)
 Systems engineers work with programme
managers to achieve system and project
success
 System Engineering
 SE is an interdisciplinary approach and means
to enable the realization of successful systems.
 It focuses on
 defining customer needs and required functionality
early in the development cycle,
 documenting requirements, then
 proceeding with design synthesis and system
validation while considering the complete problem:
 Three Elements of The SE
 System Engineering basically consist of three elements
 SE MANAGEMENT plans, organizes, controls and directs
the technical development of system or its products
 REQUIREMENTS & ARCHITECTURE DEFINITION defines
the technical requirements based on the stakeholder
requirements, defines a structure (or an architecture) for the
system components, and allocates these requirements to the
components of this architecture.
 SYSTEM INTEGRATION & VERIFICATION integrates the
componets of the architecture at each level of the
architecture and verifies that the requirements for those
components are met
 The System Engineering Process
REQUIREMENTS & ARCHITECTURE DEVELOPMENT SYSTEM INTEGRATION
SE MANAGEMENT & VERIFICATION (SI&V)
TEAM DEFINITION TEAMS TEAMS
TEAM

URD &
OTHER
STAKESHOLDER
REQTS SEMP
SEMS
SEDS
• RFP
• CONTRACT A/B SPECS
• PROGRAM C/D/E SPECS
PLAN SSDD
• COST
OBJECTIVES ICD
• MARKETING TRS
INFO

PRODUCT CHARACTERISTICS
MGMT DIRECTION & REPORTING

• STAFFING & RESOURCE REQTS

• TECH PROGRAM PROGRESS REPORT INTEGRATED &
QUALIFIED SYSTEM

ILS Integrated Logistic Support A SPECS System Functional Reqts

RFP Request for proposal B SPECS Allocated Development Reqts DEPLOYED SYSTEM
SDP Software Development Plan C SPECS Product Function/Fabrication Reqts
SEDS Systems Eng Detailed Schedule D SPECS Process Reqts
SEMP Systems Eng Mngmnt Plan E SPECS Material Reqts SYSTEM
21/2/06
SEMS
T&E
Systems Eng Master Schedule
Test & Evaluation
Setyo U. Soekarsono
SSDD
ICD
System/Segment Design Document
Interface Control Document
10 DESIGN PACKAGE

URD User Reqts Document TRS Test Reqts Specification

System Engineering Guidebook, James N. Martin, 1997
 Tehnical Process VS Management Process

System Engineering both a technical and a management process

 The technical process is the analytical effort necessary to transform

an operational need into a system design of the proper size and
configuration, and its documentation in requirements specifications.
 The management process involves
 assessing the risk and cost,

 integrating the engineering specialties and design groups,

 maintaining configuration control, and

 continuously auditing the effort to ensure that cost, schedule,

and technical performance objectives are satisfied to meet the

original operational need.

Source: J. Douglas Sailor

 Viewing a system
new system, derivative system, change based system

Development of new system allows SE to be applied in a “blank slate”

fashion; that is, to start from the inception of the requirements and the
development of initial concepts.

A derivative system utilizes major components of an existing system

as the basis for the development of a system which meets some new
requirements. The challenge is to to develop requirements and to
synthesize and verify solutions to those requirements within the
specified constraints.

A change-based system is a system for a specific customer which

may have a large number of requested changes.

A common misperception is that derivative and change-based designs must

meet less rigorous requirements than new system. On the contrary, all
systems are subject to the top-level requirements.
 Standards & References
(should be updated)
 References
 INCOSE
 Systems Engineering Handbook A “How To” Guide For All Engineers
Release 1.0 January 1998
• Guide to Systems Engineering Body of Knowledge (G2SEBoK)
 Standards
– ANSI/EIA 632; September 2003
• Processes for Engineering a System
– IEEE Std 1220; May 1998
• IEEE Standard for Application and Management of the Systems
Engineering Process
– ISO/IEC 15288; 2002
• Systems Engineering – System Life Cycle Processes
• Framework/Books
– Framework for the application of SE in the Commercial Aircraft Domain, draft
Version 1.2A, 2000
– System engineering guidebook, James N. Martin, 1998
– System engineering and analysis, Blanchard & Fabrycky, 1990
21/2/06 Setyo U. Soekarsono 13
 Additional information

21/2/06 Setyo U. Soekarsono 14

 The First Input Document
into the SE Process:
User Requirement Document, URD:
- Specifies the minimum acceptable performance requirements
of a system stated in terms of operational and performance
capabilities.
- May be prepared by:
- Marketing organization
- User Agency
- User
- Often not stated in technical terms.

21/2/06 Setyo U. Soekarsono 15

 The “Vee” Model of
System Development
User Requirements & System
Concept of Demonstration &
Operations Validation Systems
Engineering
Domain
System
System Integration &
Requirements &
Test
Architecture

Component
Component Design
Integration & Test

Component
Engineering
Procure, Fabricate, & Domain
Assemble Parts
 • What needs are we trying to fill?
•• Focus
Focusof
ofSystems
Systems
Need • What is wrong with the current situation?
• Is the need clearly articulated?
Engineering
Engineering • Who are the intended users?
–– From
FromOriginal
OriginalNeed
Need • How will they use our products?
Operations Concept • How is this different from the present?
–– To
ToFinal
FinalProduct
Product
• What specific capability will we provide?
•• The
TheWhole
Whole • To what level of detail?
System
System Functional Requirements• Are element interfaces well defined?
•• The
TheFull
FullSystem
System • What is the overall plan of attack?
Life Cycle
Life Cycle
• What elements make up the overall approach?
• Are these complete, logical, and consistent?
System Architecture
• Which elements address which requirements?
• Is the allocation appropriate?
• Are there any unnecessary requirements?
Allocated Requirements
• Are the details correct?
• Do they meet the requirements?
• Are the interfaces satisfied?
••Focus Detailed Design
FocusofofComponent
Component • Will the solution be satisfactory in terms
Engineering
Engineering of cost and schedule?
• Can we reuse existing pieces?
•• On
OnDetailed
DetailedDesign
Design Implementation • What is our evidence of success?
•• And
AndImplementation
Implementation • Will the customer be happy?
• Will the users’ needs be met?

Test & Verification

Requirements Life Cycle
Disposal
User Reqts
Reqts

Customer Maintenance
Reqts Reqts

Context use
Reqts Reqts

System Deployment
Reqts Reqts

Development Verification
Reqts Reqts

Fabrication/ Assembly//
Procurement Integration
Reqts Reqts
Flowdown of Reqts from Stakeholders
User Stakeholders
Provide
Provide

User Stakeholder
Reqts Reqts
Flowdown to

Flowdown to
System Flowdown to
Reqts
Flowdown to Task
Reqts
Design - to Provided to
Provided to
Reqts
Flowdown to

Task
Build- to Performers
Reqts
Provided to

Product/
BUILDERS
Service