H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 1 Overview of Systems Engineering Fundamentals - Model-based Systems Engineering - Minneapolis.

H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 1

Overview of Systems Engineering Fundamentals- Model-based Systems Engineering -

Minneapolis 11-08-01

I-Logix Inc.3 Riverside Drive

Andover MA 01810USA

tel: 978-645-3022 . fax: 978-682-5995e-mail: [email protected]

Hans-Peter Hoffmann, Ph.D.Director and Chief Methodologist for Systems Design

Systems & MicroController Division

http://www.ilogix.com


1. Process Overview:

Model-based System Development

• The “V” Development Process • Requirements Capture (“Use Cases”)• Systems Analysis and Architectural Design• Transition to SW Design

2. Modeling Languages

3. Model-based Verification/Validation

4. Documentation in a Model-based Development

Model-based Systems Engineering


Test Engineers

SystemIntegration &

Test

System Acceptance

Shortcomings in System DevelopmentsThe “Throw-it-over-the-Fence” Process

Software Engineers

Electrical Engineers

Mechanical Engineers

HW/SWDesign

HW/SWImplementation

ModuleIntegration &

Test

System Engineers

SystemsAnalysis &

Design

Requirements-Analysis

Costs ofDesign Changes

Time

Cop

yrig

ht I

-Log

ix


Improving the Development Process: “Concurrent Engineering”

System Engineers Test Engineers


Software Engineers


System Engineers

Test Engineers


Software Engineers


SystemIntegration &

Test

System Acceptance

HW/SWDesign

HW/SWImplementation

ModuleIntegration &

Test

SystemsAnalysis &

Design

Requirements-Analysis

Cop

yrig

ht I

-Log

ix


Use Case Models

SystemAcceptance

System Integration & Test

Module Integration & Test

System Modification

Model/Scenario-based System Development

Test Scenarios Test Scenarios

Kn

owle

dge

Bas

e *

* Configuration controlled Knowledge that is increasing in Understanding until Completion of the System:

• Requirements Documentation• Requirements Traceability• Model Data/Parameters• Test Definition/Vectors

Cop

yrig

ht I

-Log

ix

Requirements Analysis

HW / SWImplementation

& Unit Test

HW / SW Design

Systems Analysis &

Design

System- / Performance- Model

Implementation Model

The iterative Process (“Micro-Cycles”)

Iterative Prototype

Implementation

Design

Analysis V&V


Requirements Capture

Basic tools for requirements capture are Use Cases and Scenarios

A Use Case describes a specific usage (“operational thread”) of a system.

• It specifies the behavior as perceived by the user(s) and the message flow between the user(s) and the use case.• It does not reveal the system’s internal structure (“black-box view”)

A Scenario is a specific path through a Use Case .

SystemAcceptance

SystemIntegration & Test

ModuleIntegration & Test

TEST/PARAMETER-DATABASE


& Unit Test

HW / SWDesign

Systems Analysis &

Design


Cop

yrig

ht I

-Log

ix


Languages for Requirements Capture System

Acceptance





& Unit Test

HW / SWDesign

Systems Analysis &

Design


Cop

yrig

ht I

-Log

ix

Actor 2

System Boundary Box

Use Case B

Use Case A

Use Case C

Actor 1

System Boundary Box

<<extend>> <<include>>

Use Case Diagrams

Sequence Diagramscapturing a specific use case scenario

Statechartscapturing all possible use case scenarios

Functional / Non-functionalRequirements


Input_Tray_Sensor

Tray_Detect_Sensor

Puller_Jaws_Solenoid

Puller_X_Stepper

I_Gripper_Jaws_Solenoid

Rail_Assembly_Stepper

PRS

Input_Mag_Y_Stepper

Input_Mag_Z_Stepper

Top_Jaw_Stepper

DC_Motor

LF_Present_Sensor

Jam_Detect_Sensor

Tucker_Assembly

I_Gripper_X_Stepper

Clamp

Output_Mag_Z_Stepper

Materials Handling System

Load Magazine

Eject Magazine

Inject Leadframe

Indexing Leadframe

Eject Leadframe

Materials Handling System

Requirements Capture (Use Case Diagram)Example: Materials Handling System


Requirements Capture (Sequence Diagram)Example: Materials Handling System


Cop

yrig

ht I

-Log

ix


Requirements captured in use cases and respective scenarios may be incomplete, ambiguous or even wrong.

Use cases may be translated into executable functional models (Executable Use Cases) which then are validated through

• Simulation with stimuli derived from respective use case scenarios (Sequence Diagrams / Statechart) and

• Formal Verification Analysis

SystemAcceptance





& Unit Test

HW / SWDesign

Systems Analysis &

Design



Use Case 1:“Fuel XFR and CG-Control”

Use Case Scenarios:• Normal Operation: - Center to Feed Tank Transfer - Forward Transfers from Trim Tanks - Aft Transfers to Trim Tank

• Operations with Failures: - Valves failed shut - Valves failed open - Pump Failures

X

L

LOT LIT

Center Tank

Trim Tank

RIT ROT

E1

BA BBF HWV

T

X

E2 E3 E4

Use Case 3: “Defueling”

Use Case 2: “Fueling”


Capturing Requirements via Use CasesExample: Aircraft Fuel-/Defuel System

SystemAcceptance





& Unit Test

HW / SWDesign

Systems Analysis &

Design


Cop

yrig

ht I

-Log

ix


Generic Activity

When the Trim Tank contains fuel and the aircraft is not in refuel or defuel mode then both Trim Tank Transfer Pumps shall be commanded ON otherwise they shall be commanded OFF.

Cop

yrig

ht I

-Log

ixValidation of Requirements through

Executable Use Case Model USE Case: XFR_AND_CG_CONTROL (Statemate)

Fuel_Control_System

Fuel_XFR_and_CG_Control

Switches Plant

Fuel_Control_System


Validation of Requirements through Executable Use Case Model

USE Case: XFR_AND_CG_CONTROL – Graphical User Interface (Statemate)


Benefits from Requirements Modeling

Manage complexity by focusing on specific intended operations

Understand requirements relationship

Generate “Derived Requirements”

Perform preliminary validation of requirements, e.g. Eliminate ambiguities through model execution

SystemAcceptance





& Unit Test

HW / SWDesign

Systems Analysis &

Design


Cop

yrig

ht I

-Log

ix


SystemAcceptance

System Integration & Test

Module Integration & Test


Use Case Models

System Modification

System- / Performance- Model

Test Scenarios

Model/Scenario-based System Development


& Unit Test

HW / SW Design

Systems Analysis &

Design

Implementation Model

Kn

owle

dge

Bas

e

Test Scenarios

Validated Requirements

incl. executable Use Case Prototypes

From Requirements Analysis to Systems Analysis & Design

Cop

yrig

ht I

-Log

ix


V&V Cycle

V&V Cycle

• “Conceptual Model”: Functional Decomposition down to the Hierarchy Level where related System States are captured ( Level 3)

SystemFunctional

Design

if System Architecture tbd

HW Design & Build SW Design & Implementation

Requirements

V&V Cycle incl.RAPID PROTOTYPING

V&V Cycle

Subsystem Design *

• HW/SW Partitioning• Subsystem Analysis of HW/SW Collaboration• Definition of Subsystem Interfaces

V&V Cycle

Use Case Scenarios • Requirements Capture and V&V through executable Use Case Models

RequirementsAnalysis

• Use Cases Assignment to Subsystems

SubsystemFunctionalDesign *Subsystem

RequirementsDocument

HW/SW Requirements Specification

Document

The Top-Down System Design Processin Aerospace/Defense

* Concurrent Engineering Task

• Grouping of Functionality• System-Level COTS Analysis• Partitioning into Subsystems

SystemDesign *

Cop

yrig

ht I

-Log

ix

System Requirements

Document

Links providingTraceability of Specs

to original Requirements Test Scenarios /Test Vectors


Functional Decomposition The „Top-Down“ Approach

Hierarchy Level 0(“ Context-Diagram“ )

ExternalData Sink

External Data Source

Hierarchy Level 1Top-Down

Hierarchy Level 2

Cop

yrig

ht I

-Log

ix


Subsystem Functional Design

The Subsystem Design ProcessHW/SW Partitioning (Statemate) V&V Cycle incl.

Rapid Prototyping

SubsystemFunctional

Design

SubsystemDesign

V&V Cycle

Subsystem Design:Definition of Subsystem Interfaces

Interface to other Subsystems

*

Subsystem Design:HW/SW Partitioning

Analysis of HW/SW Collaboration

*

* may have to be partitioned

Cop

yrig

ht I

-Log

ix


• Power Mirror• Power Window• Seat Heating• Memory Store/Recall. . . . . . . . . .

Platform independent Feature Library

FeatureModels

FA

F

F

FeatureModels

FA

F

F

FeatureModels

F

FeatureModels

F

Process Buffer

Vehicle System

. . .

Test Scenariosderived fromRequirements

Recorded System Behavior

“Feature-based” System Design Approach (Automotive)

Capturing Vehicle-specific Features in a Conceptual System ModelFunctional Requirements

H

AF

FP

AF

FM

F

S

F

K

AF

FB

F

X

F

L

F

. . .

FeatureModels

FA

F

F

FeatureModels

FA

F

F

FeatureModels

FA

F

F

FeatureInteraction

Models• Exterior Light ( Front, Back, Fog, Wiper/Washer )• Seat Control ( Positioning, Heating, Venting ). . . . . . . . . . . . . . . . . . . . .

Cop

yrig

ht I

-Log

ix


started/SH_S1_CMD:=SH_LVL1_CMD;SH_S2_CMD:=SH_LVL2_CMD;SH_LOW_VOLTG:=KL30_LOW_VOLTG;;--ch(SH_LVL1_CMD) or ch(SH_LVL2_CMD) orfs(KL15C or KL15X orKL30_HIGH_VOLTG or KL30_LOW_VOLTG)/if not KL15C and not KL15X and not KL30_HIGH_VOLTG and not KL30_LOW_VOLTG then SH_S1_CMD:=SH_LVL1_CMD; SH_S2_CMD:=SH_LVL2_CMD; SH_LOW_VOLTG:=KL30_LOW_VOLTGend if;;--tr(KL15C or KL15X or KL30_HIGH_VOLTG or KL30_LOW_VOLTG)/fs!(SH_S1_CMD);fs!(SH_S2_CMD);SH_LOW_VOLTG:=KL30_LOW_VOLTG;;

Feature Model (Statemate):Seat Heating

Cop

yrig

ht I

-Log

ix


Feature Interaction Model (Statemate):Seat Controller

Cop

yrig

ht I

-Log

ix


. . .

Process Buffer

Vehicle System

H

AF

FP

AF

FM

F

S

F

. . .

K

AF

FB

F

X

F

L

F


Process Buffer

ECU_1 Functions ECU_N Functions

Vehicle System

ECU Test Vector Recording

“Feature-based” System Design ApproachSystem Partitioning, Parsing of Features/Feature Sub-Functions, and

Validation of logical Interfaces

B

FK

AF

FH

AF

F

X

FH

AF

FM

F

. . .

Cop

yrig

ht I

-Log

ix


. . .

Process Buffer

Vehicle System

InputFilter

OutputFilter

Process Buffer

Bus Interface

ECU_N


Definition of HW Interfaces and Validation through Rapid Prototyping

ECU_1 Functions

B

FK

AF

FH

AF

F

ECU_N Functions

X

FH

AF

FM

F

ECU_N Functions

X

FH

AF

FM

F

H/W Test Vectorsderived from recordedlogical ECU Test Vectors

Cop

yrig

ht I

-Log

ix


SystemAcceptance


Test Scenarios

System Modification

HW/SW RequirementsSpecification

Test ScenariosRequirementsAnalysis T

EST

DBSystems

Analysis & Design

function/data-orientedSystems Engineering

RequirementsSpecification

A-D-I-T Cycles

A-D-I-T Cycles

From Function/Data-oriented Systems Engineeringto Object-oriented SW Design

A-D-I-T : Analysis-Design-Implementation-Testing

Design

Implementation

Testing

MechanisticDesign

DetailedDesign

Coding

UnitTesting

IntegrationTesting

ValidationTesting

IterativePrototypes

object-oriented SW Design










User Interface View

Panel

TargetPilot

Use Case 1

UC_1_1_3 Select Weapon

UC_1_1_4 Perform prerelease calcsUC1_1_1 Process

and store TGT position data

UC1_1 TGT Acquisition

UC1_1_12 Groundstab LDP

to TGT

Use Case 1

<<include>>

<<include>>

Use Case View

Use

Cas

e D

iagr

am

Use Case Scenario View

Sequ

ence

Dia

gram

Time-continuous Behavioral View

Time-

cont

inuo

us D

iagr

am

State-based Behavioral View

Statechart

Cop

yrig

ht I

-Log

ix

Statemate

Functional / Architectural View

Activity Chart

Modeling Languages (Statemate)The different “Views” to a System


+ Hierarchy:Structure:A state may consist of states which consist of states …Priority rule for transitions:Priority is given to the transition whose source and target states have a higher common ancestor state.

Modeling Languages Definition of Statecharts

Finite State Machine (FSM):A virtual machine that can be in any one of a set of finite states and whose next states and outputs are functions of input and current states.

+ Concurrency:Description of independent - or almost independent – parts of system behavior (e.g. subsystems) in a single Statechart.

Synchronization through Broadcasting.

Cop

yrig

ht I

-Log

ix


The Statechart LanguageDescribing Interrupt Priorities through Hierarchies


Modeling Languages Functional Description through Activity Charts

Activity Chart

Statechart

Cop

yrig

ht I

-Log

ix


Activity ChartsEncapsulation of Activities

Statechart

Activity Chart

Cop

yrig

ht I

-Log

ix


Activity ChartsDescribing Basic Function-Blocks (“Basic Activities”)

Mini-Spec Continuous Diagrams

Truthtables

(Legacy) C-Code

Statemachines(Statechart)

Cop

yrig

ht I

-Log

ix


started/ACCEL_CMD:=GAIN_ACC*ACCEL_DEFLECTION;;tm(wr(ACCEL_CMD),0.1)/ACCEL_CMD:=GAIN_ACC*ACCEL_DEFLECTION;;

PI_Controller

Modeling Languages (Statemate)“Hybrid” ( = state-based & time-continuous/time-discrete) Modeling

(Example: Simplified Model of a Cruise Control )

Vehicle_Dynamics_Kinematics

Cop

yrig

ht I

-Log

ix










Executable Specification (Statemate)

Example: Mission Computer Symbol Generator (UFCP)

Cop

yrig

ht I

-Log

ix


Seat-Heating Module (Functional Model)

Test-Data Generation

via GUI

Model Verification / Validation through Simulation (Statemate)

Simulation Output: Waveform Diagram

Requirements Scenario SH-005

Cop

yrig

ht I

-Log

ix


Model Verification / Validation

Test-Script Generation and Re-Use of Tests

S/W Requirements Specification

Test Patterns

1. FUNCTIONAL DESCRIPTION

2. BEHAVIORAL DESCRIPTION

Requirements related Test-Vectors ( Playback File)

Actual Output

OutputAnalysis

ECU

RQOutput

TestInput

Testbench for Unit-Test i.e. HP ECUTESTC

opyr

igh

t I-L

ogix



Extended System Analysis

A system specified by means of a Formal Specification Language, may be amenable to Formal Verification.

Formal Verification increases the safety of a design by mathematically

• Proving that disastrous situations never happen Based on the description of an unwanted situation the algorithm will check for the respective safety bug

• Ensuring expected situations are reachable “Drive to State / Drive to Configuration”

Formal Verification may also be used to automatically generate test cases for unit, module, and integration testing



Code Generation

A system specified by means of a Formal Specification Language may be amenable to Code Synthesis , e.g. C-Code or VHDL-Code

During the Requirements Analysis Phase a “Soft Prototype” together with a graphical User Interface may be used as a first “Proof of Concept” or for marketing purposes

During the System Design Phase, code generation may help to

• Validate Hardware/Software partitioning (“Hardware/Software Co-Design”)

• Validate the design in its real environment by porting it to some prototyping hardware (“Rapid Prototyping”)

Cop

yrig

ht I

-Log

ix


MIL 1553B

parallel/ serial

TCP/IP

Model (Back-) Animation

UNIX / NT

Prototype Target Unit

Statemate MAGNUM generated code running on RTOS (e.g. VxWorks)

Functional Model Verification / Validation

Rapid Prototyping

Cop

yrig

ht I

-Log

ix










Documentation in a Model-based Development

A system specified by means of a Formal Specification Language implies a paradigm shift in documentation.

Since by definition the system under design is described unambiguously, no additional “descriptive” text is needed.

The additional information should be restricted to remarks like

• Quality of Service Requirements or

• Requirements Traceability information.


1 APPLICABLE DOCUMENTS

2 SYSTEM OVERVIEW

3 SMS NEW

3.1 OUTPUT PROC3.2 NORMAL OPERATIONS

3.2.1 CALCULATE BALANCE3.2.2 DEFINE SEQUENCE3.2.3 SELECT PACKAGES3.2.4 PERFORM RELEASE GEN

3.3 INVENTORY MANAGEMENT3.3.1 DISPLAY IN AIR3.3.2 DISPLAY LOP3.3.3 DISPLAY ON GROUND3.3.4 DISPLAY RELEASE INFORMATION

3.4 INITIALISATION3.4.1 INIT ON POWER UP3.4.2 RESET INVENTORY

3.5 EMERGENCY OPERATIONS

4 GENERIC ACTIVITY CHARTS

4.1 STATION CONTROL

5 STATECHARTS

5.1 GENERATE RELEASES FUNCTION5.2 INITIALISATION CTRL5.3 NORMAL OPERATIONS CTRL5.4 PERFORM EMERGENCY JETTISON5.5 SMS NEW CTRL5.6 STORE DISPLAY CTRL

6 DATA DICTIONARY

6.1 Actions6.2 Conditions6.3 Simple Data-items6.4 Events6.5 Information Flows6.6 Simple User Defined Types6.7 Enumerated User Defined Types6.8 Structured User Defined Types6.9 Subroutines

7 TREE REPORT

8 APPENDIX

8.1 Truth Tables8.1.1 Truth-Table of Action DETERMINE_RELEASE_TT

9 CHANGE LOG

Model Documentation (Statemate) Example: STORES MANAGEMENT SYSTEM

hierarchical order of Activity Charts

3 . 2 N O R M A L O P E R A T I O N S

O v e r v i e w :T h e n o r m a l o p e r a t i o n s a l l o w t h e o p e r a t o r t o s e l e c t r e l e a s e p a c k a g e s a n d t o p e r f o r m t h e r e l e a s e .

T h e o p e r a t o r i s a l l o w e d t o d e f i n e u p t o t h r e e r e l e a s e p a c k a g e s , e a c h p a c k a g e c o n s i s t i n g o f a s t o r e t y p e ,q u a n t i t y t o r e l e a s e a n d t h e r e l e a s e s e q u e n c e . T h e o p e r a t o r s e l e c t s t h e s t o r e t y p e a n d t h e q u a n t i t y b u t i t i st h e S M S w h i c h d e c i d e s t h e r e l e a s e s e q u e n c e . T h e r e l e a s e s e q u e n c e i s c a l c u l a t e d s u c h t h a t t h e a i r c r a f tb a l a n c e i s m a i n t a i n e d ; i n t h i s c a s e t h e a i r c r a f t w i l l b e b a l a n c e d p r o v i d e d t h a t n e i t h e r w i n g c a r r i e s m o r e t h a to n e s t o r e m o r e t h a n t h e o t h e r .

I n p u t / O u t p u t R e q u i r e m e n t s :

3 . 2 . 1 C A L C U L A T E B A L A N C E

D e s c r i p t i o n :I t i s u n s a f e f o r t h e a i r c r a f t t o b e s i g n i f i c a n t l y o u t o f b a l a n c e . B a l a n c e i s c a l c u l a t e d b y t a k i n g t h e d i f f e r e n c eb e t w e e n t h e n u m b e r o f s t o r e s o n t h e l e f t w i n g a n d t h e n u m b e r o f s t o r e s o n t h e r i g h t w i n g . I n g e n e r a l , t h eb a l a n c e i s g i v e n a p o s i t i v e n u m b e r w h e n t h e r i g h t w i n g c o n t a i n s m o r e s t o r e s .

N O R M A L _ O P E R A T I O N S

@ P E R F O R M _R E L E A S E _G E N

D E F I N E _S E Q U E N C E >

C A L C U L A T E _B A L A N C E >

S E L E C T _P A C K A G E S >

@ N O R M A L _ O P E R A T I O N S _ C T R L

P R O C E S S _ B U F F E RP R O C E S S _ B U F F E R

S E L E C T E D _ P A C K A G E

T E R M I N A T E _R E L E A S E

E N D _P E R F O R M _R E L E A S E

P A C K A G E S _S E Q U E N C E

C U R R E N T _B A L A N C E

P A C K A G E S _ S T O R E _ T Y P E

P A C K A G E S _ Q U A N T I T Y

R E L E A S E _ T Y P E _ A C T

S E L E C T E D _ S T _ N O P

R E L E A S E _ Q U A N T I T Y _A C T _ D S

S T _ S T O R E _ F U Z E _N O R M A L _ O P

S T _ S T O R E _ R E L E A S E _N O R M A L _ O P

R E L E A S E _Q U A N T I T Y _ A C T _ S P

S E L E C T E D _ S T A T I O N S

S T O R E _ D A T A

R E L E A S E _ Q T Y _ A C TS T A T I O N S _ S T O R E _ F U Z E

S T O R E _ R E L E A S E _ F R E ER E L E A S E _ D E M A N D

I N V E N T O R Y

L A T E _ A R M

R E L E A S E _ C O N S E N T

R E L E A S E _ Q T Y _ D M DR E L E A S E _ T Y P E _ D M D

S T E P _ P A C K A G E

S T A T I O N S _ S T O R E _ P R E SCop

yrig

ht I

-Log

ix



2 SYSTEM OVERVIEW

3 SMS NEW







4.1 STATION CONTROL

5 STATECHARTS


6 DATA DICTIONARY


7 TREE REPORT

8 APPENDIX


9 CHANGE LOG


5 .5 S M S N E W C T R L

D e scr ip tio n :

T h e o v e ra ll c o n tro ls fo r th e S to re s M an a g em e n t S ys te m a re th e M a s te r A rm S a fe tyS w itch (M A S S ) an d th e E m e rg en c y J e ttiso n b u tto n . T h e s ys te m p o w e r is co n tro lled b yth e M as te r A rm S a fe ty S w itc h (M A S S ) w h ic h h as th re e p o s itio n s : O F F , S T A N D B Y a n dL IV E .

W h en th e M A S S is O F F th e S M S is u n -p o w e re d an d h en c e n o o p e ra tio n is p o ss ib le .

W h en th e M A S S is in S T A N D B Y th e S M S is p o w e re d b u t n o re le a se s a re a llo w ed .T h u s in th is m o d e th e S M S co m p le te s a n y s ta rt-u p b u ilt in te s t, re se ts an y v a ria b le s a n dse ts a ll o u tp u ts to a n o n -a c tiv e s ta te .

W h en th e M A S S is L IV E th e S M S rem a in s p o w e re d an d a ll fu n c tio n s in c lu d in g re le a se sa re a l lo w e d . W h e n in th is s ta te , th e S M S h as tw o o p e ra tin g m o d es : L IV E an dE M E R G E N C Y J E T T IS O N . L IV E is th e n o rm a l ca s e . O p e ra tin g th e e m e rg en c y je ttiso nb u tto n w ill c a u se th e S M S to e n te r th e E M E R G E N C Y JE T T IS O N s ta te w h ich w ill c au s en o rm a l o p e ra tio n s to b e ce a s ed an d s ta r t th e em e rg e n c y o p e ra tio n s seq u en ce .

T h e em erg e n c y o p e ra tio n s se q u e n ce sh a ll co n tin u e u n til th e em e rg en c y je tt iso n b u tto n isre lea s ed .

F u n c tio n :

SMS_NEW_CT RL

SM S_OFF

SMS_ON>

SMS_STANDBY

SMS_EMERGENC Y_JETTISON>

SMS_LIVE>

[not EM ERGENCY_JETTISON][EMERGENCY_J ETTISON]/DESELECT_STA TIONS

[MASS=MASS_ST ANDBY]/DESELECT_STAT IONS

[MASS=MASS_L IVE]

[MASS=MASS_S TANDBY]/ALL_FUZING_S IGNALS_OFF;ALL_RELEASE_ SIGNALS_OFF

[MASS=MASS _OFF]

alphabetical order of Statecharts

Cop

yrig

ht I

-Log

ix



2 SYSTEM OVERVIEW

3 SMS NEW







4.1 STATION CONTROL

5 STATECHARTS


6 DATA DICTIONARY


7 TREE REPORT

8 APPENDIX


9 CHANGE LOG


Optional: alphabetical order

Cop

yrig

ht I

-Log

ix

H-P Hoffmann, Ph.D. Model-based Systems Engineering Page 1 Overview of Systems Engineering Fundamentals - Model-based Systems Engineering - Minneapolis.

Documents

modelbased system development

use cases systems analysis

model implementation

system developments

hp hoffmann

requirements capture

e t e r d

defueling use case