1

Decomposition: Functions

Mark E. Sampson

EMIS 8340

Systems Engineering Tool—applying tools to engineering systems

2

Setting Expectations for Modeling

• Modeling is not SystemsEngineering

• Systems Engineering is not Modeling

…modeling is one aspect of SE

…according to analysis at TI & DSMConly 15% of product development tasksrequire systems modeling

Be careful that 15% of tasks don’t take 100% of time & money

[Sampson 1994]

                                                            

SE IPDP Involvement

SE Ownership (21%)

SE Involvement (41%)

non-SE (38%)

Dem/Val Process

SE Ownership (31%)

SE Involvement (64%)

non-SE (5%)

EMD Process

SE Ownership (14%)

SE Involvement (27%)

non-SE (59%)

CE Process

SE Ownership (31%)

SE Involvement (64%)

non-SE (5%)

82% Doc. 49% Req.23% Sim.9% Part.3% CD.10% None

Tool Type

82% Doc. 58% Req.11% Sim.7% Part.2% CD.

17% None

Tool Type

86% Doc. 62% Req.15% Sim.7% Part.2% CD.12% None

Tool Type

90% Doc. 70% Req.15% Sim.7% Part.2% CD.9% None

Tool Type

3

Methodology Wars…

• New modeling methodologies/techniques are added all the time…

• We won’t be able to visit them all…just of few of the most widely used ones

• Methodology Cults……one particular methodology doesnot fit all problems

“To a person with a hammer…Everything looks like a nail”

…find the tool that matches theProblem.

[Armstrong 1993]

                                                            

4

Start with functions/features…

• Why? Allows you to…• Avoid bias that leads to pre-selection errors• Captures behaviors which lead to requirements

• You need to understand functions: • drives out sequence• understand inter-relationships• timing• before deciding on partitions • optimize inputs/outputs

…essentially your requirements elicitation process has also extracted high level functions/features your product should have.

…on going chicken/egg argument about what comes first—requirements or functions-RFAT vs. FRAT

[Lacy 1992]

                                                            

[SE Handbook 9.1]

5

Functional Decomposition…

• Start with higher-level requirements, behaviors, or functions…

• Expressed as two words—a verb, noun pair that…• is measurable/verifiable (…stop vehicle)• is not a part or activity• keeps the viewpoint of the user• is expressed as what the user desires• is active-tense (power vehicle

better than provide power)• is not once thru, it looks at

alternative functions, decomposes to lower levels, and cycles…

[DMSC 1986][SE Handbook 9.2]

6

Functional Analysis: Tools

• Functional Flow Block Diagrams (Cradle-SEE, CORE, TcSE, Visio,Rhapsody, Simulink, Smartdraw,…)

• Requirement tools(Functions as indented lists…problem is that indented listslose a lot of information)

…allocate requirements to functions (that’s how you find holes)…drive out additional functions/requirements

How far down do you go? Until it’s realizable.

[DSMC 1986]

                                                            

7

Functional Analysis: Analysis/Simulation

• Once captured, you maywant to simulate the system

• Some diagramming tools include built-in simulatorslike Cradle-SEE,CORE, Rhapsody, Simulink

• Others only capture diagram & logic (Powerpoint, Visio,…)

• Simulation enginesare available…

                                                            

8

Functional Analysis: Time Lines

…used to depict concurrency,overlaps, & sequential relationships of functions

• Identifies time critical functions (those that affect reaction, downtime, or availability)

• Basis of performance trace studies

[DSMC 1986]

                                                            

NASA:Mission to Planet EarthEarth Observing System

9

Functional Analysis: Time lines cont…

…shows function interaction which drives out additional requirements

• Ground station location• Bandwidth• Storage• Power• Critical Paths—aka project

mgmt.• Race conditions

[DSMC 1986]

                                                            

Earth Observing System

[SE Handbook 9.5]