1 Introduction to Systems Engineering SAGE Pilot Teacher Workshop Aug 4 th 2008 Eirik Hole School Of Systems and Enterprises Stevens Institute of Technology.

1

Introduction to Systems Introduction to Systems EngineeringEngineering

SAGE Pilot Teacher Workshop Aug 4SAGE Pilot Teacher Workshop Aug 4thth 2008 2008

Eirik HoleSchool Of Systems and Enterprises

Stevens Institute of [email protected] Tel: (201) 216 8308

2

Let’s Engineer a Drive Let’s Engineer a Drive ShaftShaft

Design Loads

EnvironmentalConditions

GeometricEnvelopes

Functions

Interfaces

External DesignStandards

Internal DesignStandards

Geometry

Materials

Coatings

SpecialProcesses

ProductionQA-Procedures

R&D

$

Manuf.

$Time

Resources

3

An Aileron Drive Shaft in a An Aileron Drive Shaft in a Wing AssemblyWing Assembly

Handling

Characteristics

OperationalScenarios

EnvironmentalConditions

FlightPerformance

WeightLimitations

External DesignStandards

Internal DesignStandards

Main Elements

AllocatedFunctions

DecomposedEnvironment

DecomposedLoads

Geometric

Envelopes

Interfaces

4

Why Are We Why Are We Engineering a New Engineering a New

Drive Shaft?Drive Shaft?Capacity

Range

Cruise Speed

Cost of Ownership

Availability

OperationalArea

Image

Standards

RegulationsRegulations

RegulationsRegulations

StandardsStandards

StandardsStandards

Part of a larger system…Part of a larger system…

5

Which is part of a even larger Which is part of a even larger systemsystem

6

7

What is a System?What is a System?Mil-Std 499B: An Mil-Std 499B: An

integrated composite of integrated composite of people, products, and people, products, and

processes that provide a processes that provide a capability to satisfy a capability to satisfy a

stated need or objective.stated need or objective.INCOSE Fellows Consensus: A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system level qualities, properties, characteristics, functions, behavior and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected (Rechtin, 2000).

The V-Model of System The V-Model of System DevelopmentDevelopment

8

Gather & DefineRequirements

System Design

Detailed Design

Fabricate&

Code

Component Test

System Integration& Verification

OperationalAcceptance

Decom

pose

&

Defin

eIn

tegr

ate

&V

erify

Feedback

Component Engineering

Systems Engineering

Systems Engineering Systems Engineering • Systems Engineering addresses the dual

problem of:(1) translating stakeholder needs into system

requirements(2) specifying components that, when integrated, will

satisfy those requirements

• In other words:stating the problem (i.e., defining the problem domain)

- and -

solving it (i.e., defining the solution domain)

“Systems Engineering is really about creating and delivering the courseware for the remaining 90% of the project”

Jack Ring6/3/08

10

Gather and Define Gather and Define RequirementsRequirements

• Identify the problem or need• Understand its context• What constraints are we

bound by?• What are the characteristics

and capabilities of a system that could satisfy this need within the constraints?

Context System (S1)

Realization System (S3)

Intervention System (S2)

Competing System (S7)

Modified Context System (S1’)

Deployed System (S4)

Sustainment System (S6)

Problem (P1)

Problem (P2)

may cause

Collaborating System (S5)

collaborates with

intended to address

becomes

may address

competes with

becomes

sustains

may need to develop or modify

needs to understand

needs to understand

The 7 Samurai, James N. Martin, INCOSE 2004

6/3/08

12

Have you considered the Have you considered the needs of all stakeholders? needs of all stakeholders?

• Users

• Purchasers

• Trainers

• Maintainers

• Distributors

• Sales outlets

• Company policies (and office politics)

• Developers

• Manufacturers

• Testers

• Others?

13

• Toyota launched its luxury automobile project in 1983• Japanese designers lived in California while creating initial designs

– Rented home in upscale neighborhood– Rented and drove luxury cars– Lived target buyer lifestyle

• After 5 months, team returned to Japan with exterior and interior design proposals

• Lexus vehicles an immediate success – well received by target buyersRef. Presentation by Donald Brown, Toyota Sales, USA, April 1, 1996

How Far Do We Go to How Far Do We Go to Understand the Need?? Understand the Need??

14 Copyright 2007 -- Stevens Institute of

Technology

Fat luxury………Fat luxury………

15

Stakeholder Needs – Stakeholder Needs – Capabilities and Capabilities and CharacteristicsCharacteristics• Capabilities – requirements that reflect

functions desired by the stakeholders – Examples for an Automatic Teller Machine: deposit or withdraw

money 24 hours a day; check account balances; transfer funds between accounts, etc.

• Characteristics –requirements that reflect system attributes – Examples for an Automatic Teller Machine: quality, reliability,

safety, security, cost, schedule, usability, aesthetics, performance, compliance with standards and protocols, technology preferences or constraints, etc.

– Others: size, weight, “look and feel”, durability...

16

ATM System

XYZ BankCustomer

UnfriendlyCustomer

ATM Admin

ATM Servicers

Customer Account

DB

NYCENetwork

HW Maint. CIRRUSNetwork

PLUSNetwork

Fraud / Break-inTransactionRequest

TransactionRequest

TransactionRequest

TransactionRequest

Response

Response

Response

Response

Log in /Service

Response

Reports

Log in /Request

RetrieveDeposits

DiagnosticResponse

Fill up w/ Cash

Service

DiagnosticResponse

Credit CardCustomer

Response

Log in /Request

BankManagement

Another Bank'sCustomer

Log in /Request

Log in /Request

Response

Context diagram example: Context diagram example: Automatic Teller MachineAutomatic Teller Machine

17

Capabilities Example: Develop Use Capabilities Example: Develop Use Cases for a Clinic Management SystemCases for a Clinic Management System

Requirements LayersRequirements Layers

Dr. Dinesh Verma

6/3/08

Technical System Technical System RequirementsRequirements

• Functional - necessary tasks, actions, or activities• Performance - extent to which mission or task must be

performed• Physical – constraints on size, weight, materials, etc.• Environmental – conditions like temperature, humidity, shock,

vibration, etc.• Interface – interactions between systems, users, environment • Modes and States – operational conditions of system• Quality characteristics – measures of system’s effectiveness/

efficiency in performing mission • Production – processes, facilities or tooling to produce a

product• Qualification – demonstrate conformance to stakeholder

needs and technical requirements

Requirements must be necessary and sufficient, verifiable, and well-written

“Don’t specify what you can’t verify.”

Characteristics of Good Characteristics of Good RequirementsRequirements

• Necessary and sufficient – defines essential capabilities, characteristics, constraints, quality

• Complete – contains everything pertinent• Feasible – technically possible within cost & schedule • Unambiguous – the language used can only be interpreted

one way • Verifiable – the means exist to show requirement is

satisfied• Consistent – free of conflicts with other requirements• Correct – accurately specifies what is required• What, not How – states problem only, no solutions• Simple – focuses on only one subject• Objective – No room for subjective interpretation or opinion

21

System DesignSystem Design

1. Everything goes somewhere

2. Everything interacts with everything else

3. There is no such thing as a free lunch

Dave F. McClinton

…or getting a balanced architecture that fulfils the requirements

22 Copyright 2007 -- Stevens Institute of

Technology

Generally Increasing Generally Increasing InterdependenceInterdependence

Source: Negele et. al. INCOSE Symp 2006

Take a functional and a physical Take a functional and a physical viewview

23

The carburetor manufacturers disappeared because they saw themselves as carburetor makers, not as providers of mixing fuel and air.

W. Edward Deming

24

Functional View Functional View

• A function is a process that transforms INPUTS into OUTPUTS

• A function describes an ACTION taken by the system or by one of its elements

• A function is represented by a VERB or verb-noun pair

Functional View of a Functional View of a DistillerDistiller

25

26

Physical ViewPhysical View• Provides the system resources to perform its functions

– Hardware– Software– Facilities– People– Procedures

• Generic physical architecture: description of the partitioned elements of the physical architecture without any specification of the performance characteristics of the physical resources that comprise each element

• Instantiated physical architecture: generic physical architecture to which complete definitions of the performance characteristics of the resources have been added

27

Physical View for a DistillerPhysical View for a Distiller

28 Copyright 2007 -- Stevens Institute of

Technology

Expensive fireworks…Expensive fireworks…

29

Derive and Trace Derive and Trace Requirements Requirements

• Every high level requirement will have to be developed into lower level requirements.

• Are subsystem/component requirements consistent with system level requirements?

• Where do the Requirements come from, and where do they go?• Why are they the way they are?• What are the consequences of a proposed change?

Operational EffectivenessOperational Effectiveness

30 04/18/23 Copyright 2007 -- Stevens Institute of

Technology

Reliability/

Supportability/ Maintainability/

Design “Cause”

Operational “Effect”

Operation

Logistics Maintenance

Time toSupport (TTS)

Time toMaintain (TTM)

Time toFailure (TTF)

System DowntimeSystem Uptime

OperationalOperationalEffectivenessEffectiveness

Cost as an Independent Variable (CAIV)/TOC

PerformanceFunctions

Requirements

PrioritiesReliability

MaintainabilitySupportability Availability

Technical

Effectiveness

ProducibilitySystem

EffectivenessOperationMaintenance

LogisticsProcess

EfficiencyProduction

31

The charts here are based on data collected from a recent study analyzing project defects by type and phase. Here ISM defects by phase is compared to 46 similarly sized IBM projects

not utilizing SE.

Total defect counts for non-SE projects exhibited 53.4% of total project defects during

the Test Phase of the project. On ISM defects were detected earlier in the project life-cycle.

In fact 56% of ISM detects were detected in Plan Phase.

The chart on the left illustrates the cost implications of early defect

detection as found with ISM 2.0.

In effect ISM 2.0 expended 2.4 times less than what would have

normally been required for the non-SE oriented projects compared to in

the study.

It Works! It Works!