SystemsEngineeringCSC595_495Spring2018

HowardRosenthal

1

Notice�  Thiscourseisbasedonandincludesmaterialfromthetext:TheEngineeringDesignofSystems:ModelsandMethods(WileySeriesinSystemsEngineeringandManagement)3rdEditionDennisM.Buede,WilliamD.MillerPublisher:Wiley;3edition(February29,2016)Language:EnglishISBN-13:978-1119027904�  Italsoutilizesinformationfromthesetwoadditionalbooksaswellasmanycitedreferences:PracticalGuidetoSysML,ThirdEdition:TheSystemsModelingLanguage(TheMK/OMGPress)3rdEditionSanfordFriedenthal,AlanMoore,RickSteinerSeries:TheMK/OMGPressPublisher:MorganKaufmann;3rdedition(November7,2014)ISBN-13:978-0128002025SystemEngineeringAnalysis,Design,andDevelopment:Concepts,Principles,andPractices(WileySeriesinSystemsEngineeringandManagement)2ndEditionCharlesS.WassonSeries:WileySeriesinSystemsEngineeringandManagementHardcover:882pagesPublisher:Wiley;2edition(December2,2015)Language:EnglishISBN-13:978-1118442265Othermaterialwasusedfromthesewebsites:http://classes.engr.oregonstate.edu/mime/winter2013/ie366-001/Handouts/01-2a%20WIDGETS%20V2%20all%20text.pdfhttp://www.omgsysml.org/INCOSE-OMGSysML-Tutorial-Final-090901.pdfhttps://sparxsystems.com.au/resources/uml2_tutorial/uml2_usecasediagram.htmlhttps://sparxsystems.com.au/resources/uml2_tutorial/uml2_sequencediagram.html

2

LessonGoals

� UnderstandwhatanIDEFØmodelis� UnderstandhowtoconstructanIDEFØmodel� BuildanIDEFØmodel

3

4

WhatisIDEF?�  IDEF,initiallyabbreviationofICAMDefinition,renamedin1999as

IntegrationDEFinition,referstoafamilyofmodelinglanguagesinthefieldofsystemsandsoftwareengineering.�  Theycoverawiderangeofuses,fromfunctionalmodelingtodata,simulation,

object-orientedanalysis/designandknowledgeacquisition�  TheIDEFmodelsinclude

�  IDEFØ:Functionmodeling�  IDEF1:Informationmodeling�  IDEF1X:Datamodeling�  IDEF2:Simulationmodeldesign�  IDEF3:Processdescriptioncapture�  IDEF4:Object-orienteddesign�  IDEF5:Ontologydescriptioncapture�  IDEF6:Designrationalecapture�  IDEF7:Informationsystemauditing�  IDEF8:Userinterfacemodeling�  IDEF9:Businessconstraintdiscovery�  IDEF10:Implementationarchitecturemodeling�  IDEF11:Informationartifactmodeling�  IDEF12:Organizationmodeling�  IDEF13:Threeschemamappingdesign�  IDEF14:Networkdesign

5

IDEFØOverview�  IDEFØisamethoddesignedtomodelthedecisions,actions,andactivitiesof

anorganizationorsystem�  IDEFØwasderivedfromawell-establishedgraphicallanguage,theStructured

AnalysisandDesignTechnique(SADT)�  TheUnitedStatesAirForcecommissionedthedevelopersofSADTtodevelop

afunctionmodelingmethodforanalyzingandcommunicatingthefunctionalperspectiveofasystem

�  IDEFØwasnotincludedinSYSML,butitstillremainsanimportantandwidelyusedclassicalmodelingtool�  IDEF0isdefinitelynotasufficientmodelingrepresentationfortheengineeringof

systemssinceitisnotpreciseenoughtodefineauniquedynamicrepresentationofthesystem'sdesign

�  EffectiveIDEFØmodelshelptoorganizetheanalysisofasystemandtopromotegoodcommunicationbetweentheanalystandthecustomer�  IDEFØisusefulinestablishingthescopeofananalysis,especiallyfora

functionalanalysis�  Asacommunicationtool,IDEFØenhancesdomainexpertinvolvementand

consensusdecision-makingthroughsimplifiedgraphicaldevices�  Asananalysistool,IDEFØassiststhemodelerinidentifyingwhatfunctions

areperformed,whatisneededtoperformthosefunctions,whatthecurrentsystemdoesright,andwhatthecurrentsystemdoeswrong

�  IDEFØmodelsareoftencreatedasoneofthefirsttasksofasystemdevelopmenteffort.

6

IDEFØConcepts(1)�  CellModelingGraphicRepresentation

�  The"boxandarrow"graphicsofanIDEFØdiagramshowthefunctionasaboxandtheinterfacestoorfromthefunctionasarrowsenteringorleavingthebox

�  Toexpressfunctions,boxesoperatesimultaneouslywithotherboxes,withtheinterfacearrows"constraining"whenandhowoperationsaretriggeredandcontrolled.

�  IDEFØCommunicationsFeatures�  Diagramsbasedonsimpleboxandarrowgraphics.�  Englishtextlabelstodescribeboxesandarrowsandglossaryand

texttodefinetheprecisemeaningsofdiagramelements.�  Thegradualexpositionofdetailfeaturingahierarchicalstructure,

withthemajorfunctionsatthetopandwithsuccessivelevelsofsubfunctionsrevealingwell-boundeddetailbreakout.

�  A"nodechart"thatprovidesaquickindexforlocatingdetailswithinthehierarchicstructureofdiagrams.Thelimitationofdetailtonomorethansixsubfunctionsoneachsuccessivefunction

7

IDEFØConcepts(2)

8

12

School of Mechanical,

Industrial, & Manufacturing

Engineering

Semantics

Something (matter, energy,

information, system)

transformed by the process

Something that guides,

facilitates, limits, or

constrains the process

Something

that results

from the

process

A means by which

the process is

performed

A reference to

another model.

TheBasicIDEFStructure

IDEFØConcepts(3)�  RigorandprecisionrulesinIDEFØ

�  Controlofthedetailscommunicatedateachlevel(threetosixfunctionboxesateachlevelofadecomposition).

�  BoundedContext(noomissionsoradditionalout-of-scopedetail).�  DiagramInterfaceConnectivity(Nodenumbers,Boxnumbers,C-

numbers,andDetailReferenceExpression).�  DataStructureConnectivity(ICOMcodesandtheuseof

parentheses).�  UniqueLabelsandTitles(noduplicatednames).�  SyntaxRulesforGraphics(boxesandarrows).�  DataArrowBranchConstraint(labelsforconstrainingthedata

flowonbranches).InputversusControlSeparation(arulefordeterminingtheroleofdata).

�  DataArrowLabelRequirements(minimumlabelingrules).�  MinimumControlofFunction(allfunctionsrequireatleastone

control).PurposeandViewpoint(allmodelshaveapurposeandviewpointstatement)

9

10

11

IDEFØGeneralRules&Guidelines

�  Rules�  Conservationofinputs,controls,outputs&mechanisms�  Everyfunctionhasacontrolandoutput

�  Guidelines�  3to6functionsperpagearrangeddiagonally�  Control-orientedfunctionsplacedattopleft�  Majoroutputfunctionsplacedonbottomright�  Arcs&functionsaredecomposable�  Feedbackisdefinedbyarcsmovingfrombottomrighttotopleft

BoxandArrowRules(1)� Boxes

�  Boxesshallbesufficientinsizetoinsertboxname�  Boxesshallberectangularinshape,withsquarecorners�  Boxesshallbedrawnwithsolidlines�  Aboxshallbenamedwithanactiveverborverbphrase�  Eachsideofafunctionboxshallhaveastandardbox/arrowrelationship:�  Inputarrowsshallinterfacewiththeleftsideofabox�  Controlarrowsshallinterfacewiththetopsideofabox�  Outputarrowsshallinterfacewiththerightsideofthebox�  Mechanismarrows(exceptcallarrows)shallpointupwardandshallconnecttothebottomsideofthebox

�  Mechanismcallarrowsshallpointdownward,shallconnecttothebottomsideofthebox,andshallbelabeledwiththereferenceexpressionfortheboxwhichdetailsthesubjectbox

12

BoxandArrowRules(2)

� Box/Nodenumbers�  Singleboxincontext(A-0)diagramnumberedA0(“Activity”0)

�  Boxesincontextdiagram’schildnumberedA1, A2, A3, ... [A6]

�  BoxesinA1’schilddiagramnumberedA11, A12, ...�  BoxesinA2’schilddiagramnumberedA21, A22, ...�  BoxesinA21’schilddiagramnumberedA211, A212, ...�  andsoon...

13

BoxandArrowRules(3)�  Arrows

�  Arrowsthatbendshallbecurvedusingonly90degreearcs�  Arrowsshallbedrawninsolidlinesegments�  Arrowsshallbedrawnverticallyorhorizontally,notdiagonally

�  Arrowendsshalltouchtheouterperimeterofthefunctionboxandshallnotcrossintothebox

�  Arrowsshallattachatboxsides,notatcorners�  Arrowsegments,exceptforcallarrows,shallbelabeledwithanounornounphraseunlessasinglearrowlabelclearlyappliestothearrowasawhole

�  A“squiggle”shallbeusedtolinkanarrowwithitsassociatedlabel,unlessthearrow/labelrelationshipisobvious

�  Arrowlabelsshallnotconsistsolelyofanyofthefollowingterms:function,input,control,output,mechanism,orcall

14

BoxandArrowRules(4)

� Whendrawinginterfacearrows�  Thinkcontrolandconstraint,notflow

�  Don’tworryaboutsequence�  Allboxesmaybeactivesimultaneously

�  Bundlegroupsofarrows,whenpossible� Don’tclutterwitharrows.�  Allboxesmusthavecontrolarrows,buttheydon’trequireinputarrows.

�  Givearrowsnounornounphrasenames

15

16

ThereAreThreeFeedbackLoopsInIDEFØ

Mechanism Feedback

Input Feedback

down & under

label

Control Feedbackup & over

label

down & under label

TheTop-LevelContextDiagramInIDEFØ

�  Subjectofmodelrepresentedbysingleboxwithboundingarrows

� CalledA-0 (“Aminuszero”)� Boxandarrowsareverygeneral�  Setsmodelscopeorboundaryandorientation�  Shouldinclude

�  Purpose�  Viewpoint

17

SampleContextDiagram–A-0AssembleWidgets

18

17

School of Mechanical,

Industrial, & Manufacturing

Engineering

Example Context Diagram:A-0 Assemble widgets

Purpose: To illustrate

IDEF0 modeling for the

Work Systems Engineering

process.

Viewpoint:

Industrial/manufacturing

engineer.

SampleContextDiagram–AnotherA-0DiagramWithAdditionalMaterials

19

Fig. 2. A-0 Diagram

The box (or node) in the A-0 diagram is then decomposed (or 'exploded' or 'zoomed') into a diagram with between three and six boxes, as illustrated. This iscalled the 'A0' diagram.

This hierarchical decomposition is repeated for each box in this diagram, then for each box in the resultant diagrams and so on, until the process is fullydescribed.

In any diagram, the boxes are generally laid out from the top left to the bottom right, in order of dominance, where a higher dominance box has a greaterinfluence over a lower dominance box. Boxes are numbered in order of dominance, with the number being used to reference the box on other diagrams. Thusthe first box in the A0 diagram is decomposed in diagram A1, and the third box in that diagram is decomposed as A13.

Arrows carry multiple items, and are merged or split to simplify the diagram. Names next to arrows should describe what they carry; where there are nonames, the arrow contents may be deduced. Arrows which do not connect to a box at one end are those that come from or go to the parent box, from whichthis diagram is decomposed. These arrows are numbered to indicate which ICOM arrow they represent. Thus, C1 represents the leftmost control and I2 is thesecond input down on the parent box. Parentheses (a 'tunnel') at one end of an arrow indicates that this arrow does not appear on the parent or child diagram.

Fig. 3. A0 Diagram

There are only five types of connection that arrows can make between boxes, as indicated in the table below, which show how activities feed, enable orconstrain one another. The mix of connection types in one set of diagram will indicate the overall system type. For example, a process with little feedback mayindicate a lack of control.

TheChildDiagramInIDEFØ

� ThesingleprocessinContextDiagram(A-0)maybedecomposedintosubprocessesandmodeledinachild(A0)diagram.

� EachprocessintheA0diagrammaybedecomposedfurtherintosubprocessesandmodeledin(grand-)child(A1, A2, ... A6)diagrams

�  •Each(grand-)childprocessmaybedecomposedfurtherintosubprocessesandmodeling(great-grand-)childdiagrams

� Remember–only3-6subprocessesperprocess

20

DiagramFeatures–ArrowsAsConstraints�  Connectingoutputofaboxrepresentingaprocessthatisinput/control/mechanismtoanotherboxmeansthatthesecondprocessisconstrainedbythefirstinthisA0diagram

21

24

School of Mechanical,

Industrial, & Manufacturing

Engineering

Arrows As Constraints

• Connecting output of a box representing a process that is input/control/mechanism to another box means that the second process is constrained by the first.

DiagramFeatures–ConcurrentOperations�  Boxorderandconnectionsdonotnecessarilyimplysequence!�  Processesmayproceedconcurrently

22

25

School of Mechanical,

Industrial, & Manufacturing

Engineering

Concurrent Operation

• Box order and connections do not necessarily imply sequence!

• Processes may proceed concurrently.

Concurrent

with A32 and

A33

DiagramFeatures–BranchingArrows

23

27

School of Mechanical,

Industrial, & Manufacturing

Engineering

Branching Arrows

A & B

DiagramFeatures–Inter-BoxConnections(2)� ExceptforA-0,diagramscontain3–6boxes� Normallyorganizedondiagonal(“staircase”)� Anyoutputofoneboxmaybeinput,control,ormechanismofanotherbox

�  Ifboxisdetailedonchilddiagram,everyarrowconnectedtotheboxappearsonthechilddiagram(unlessitistunneled)

24

DiagramFeatures–Inter-BoxConnections(2)–NodeA0

25

29

School of Mechanical,

Industrial, & Manufacturing

Engineering

Inter-Box Connections

DiagramFeatures– BoundaryArrows:ArrowsFromParentboxOnParentDiagram–NodeA3

26

31

School of Mechanical,

Industrial, & Manufacturing

Engineering

Boundary Arrows:Arrows from parent box on parent diagram

Coded by prefix

and number

Chapter 3 - Modeling and Process Modeling 27

IDEFØPageStructurePage #’s Function #’s A-1

A-0

A0

A1, A3

A33

A0

A1 A2 A3

A11 A12 A13 A31 A32 A33 A34

A331 A332 A333 A335A334

A-0 A-12A-11 A-13

PageNumber(s)

PageContentA-1

Ancestororexternalsystemdiagram

A-0

Contextorsystemfunctiondiagram(containsA0)A0

Level0diagramwithfirsttierfunctionsspecified

A1,A2,...

Level1diagramswithsecondtierfunctionsspecifiedA11,A12,...,A21,...

Level2diagramswiththirdtierfunctionsspecified

...

…

ExampleOfTheIDEFØPageStructure

� Node List � A-0: Assemble widgets

�  A0: Assemble widgets �  A1: Restock parts �  A2: Get widget parts �  A3: Assemble parts

�  A31: Hold widget base �  A32: Position parts in place �  A33: Secure parts to base �  A34: Release assembled widget

�  A4: Inspect widgets

28

TheIDEFØPageStructureIsAHierarchicalStructure

29

Widgets

A0 Assemble Widgets

A1 Restock Parts

A2 Get Widget Parts

A3 Assemble Part

A31 Hold Widget Base

A32 Position Parts In

One Place

A33 Secure Parts To

Base

A34 Release

Assembled Widget

A4 Inspect Widgets

ExplanatoryMaterialsUsedWithIDEFØ(1)�  TextandGlossary

�  Associatedtextualinformationusedtoclarifymodel.�  Glossaryincludesdefinitionsof

�  Processes(activities,functions)�  Inputs�  Controls�  Outputs�  Mechanisms

�  Examplesintheglossarymightinclude�  Getwidgetparts(process)

�  Theprocessofgettingwidgetpartsfromthestockareassothatwidgetsmaybeassembled

�  Partsforwidgets(output)�  Partsretrievedfromtheworkstationstockareasandreadytobe

usedinassembly30

ExplanatoryMaterialsUsedWithIDEFØ(2)

�  ForExpositionOnlyDiagram(FEO)�  Providessupplementaryinformationtohelpreaderunderstandmodel

� NeednotcomplywithIDEFØrules�  Anexampleisaflowcharttodescribeaprocedure(action/decisionsequence)thatcanbeusedtoperformtheprocess

� AllofthisadditionalmaterialthatexistsoutsidethemodelisoneofthereasonsthatIDEFØisnotinSYSML�  IDEFØwasdevelopedwhenpeoplewerejuststartingtousemodelingtools,andlongbeforeMBSEcameintoplay

31

32

AStepByStepIDEFØTutorial(1)1.  Identifythesystemorprocesstobedescribed.

a. Useanamethatclearlyindicateswhatitis,possiblyaddingfurtherdescriptionofwhatisandwhatisnotincluded.

2.  Identifythepurposeorobjectivesofdescribingtheprocess.a. ThiswillhelptodeterminewhetherIDEFØisanappropriatetool,andwillalsohelpwhenmakingotherdecisions,forexamplewhethertodecomposethesystemfurtheratlowerlevels.

3.  Decideontheviewpointfromwhichtheprocessistobedescribed.a. Forexample,asalesmanagermighthaveabroaderviewofasalesprocessthanasalesperson,asthesalesmanagerincludestheclericalactivitiesinthesalesofficeaswellasthecustomer-salespersonprocess.

b. Theobjectivesfromstep2willhelpwiththisdecision.Forexample,iftheobjectiveistoimprovetheamountofdirectsales,thentheviewpointofthesalespersonmaybemostappropriate.

4.  Identifythedecompositionstrategytobeused.a. Thisisthesetofrulestousewhendecidinghowtobreakdownactivitiesintosub-activities,andmaydependonthetypeofsystembeingdescribedandtheobjectivesfromstep2.Possiblestrategiesinclude:1)  Functionaldecompositionbreaksdownactivitiesaccordingtowhatisdone,ratherthanhowitisdone,

andisprobablythemostcommonstrategy.2)  Roledecompositionbreaksdownthingsaccordingtowhodoeswhat.Itcanbeaneasyanduseful

startingpoint,butislikelytoconstrainimprovementsifitismaintained.3)  Subsystemsdecompositiondividessystemsfirstbymajorsubsystem.

•  Thisisusefulwhenthesesubsystemsarelargelyindependentofoneanother.Lifecycledecompositionbreaksdownasystemfirstbythephasesofactivity.Again,thisismostusefulwhenthesephasesareclearlydefinedandrelativelyindependent.

33

AStepByStepIDEFØTutorial(2)5. Beforestartingtodrawdiagrams,gatherinformationaboutthesystem.a.  Thismaystartwithreadingofexistingdocumentsorobservingtheprocessinaction,butthemostusefulactivityislikelytobeformalinterviewswithselectedpeople.Thisnotonlyisthebestsourceofinformation,butitwillalsohelptogaininvolvementandacceptanceinanylaterimprovements.Usethefollowingprocessforinterviews:1)  Intheinitialinterview,aimfirsttoagreethepurposeandviewpoint,thenfind

sufficientdetailstobeabletodrawthefirsttwolevelsonly(A-0andA0).2)  Beforeeachinterview,reviewexistinginformationandidentifythescopeofwhatis

tobeidentified.3)  Ininterviews,worktoacquirethemostusefulinformation,askingopenquestions,

probinginkeyareasandcheckingthevalidityofassumptions.First,findoutwhatisproducedbyandusedwithintheprocess,includinginputs,controls,outputsandmechanisms.Thiscanbehelpedbyaskingquestionsoftheprocess,startingwithoutputs(Whatisproduced?)andworkbackwards(Whatisneededtoproducethis?).Thiswillresultinalistofitems(oftencalledthedatalist)thatwillformthearrowsinthediagram.

4)  Next,usethedatalisttoidentifythelistofactivitieswithintheprocess,askinghowitemsareusedorproduced.

5)  Thenexplorehowactivitiesanddataitemsrelatetooneanotherandhowtheygrouptogether.Thenotesmaylooklikethefigureonthenextslide.

34

AStepByStepIDEFØTutorial(3)

35

The Psychology of Quality and More

| Menu | Books | Share | Search | Settings |

A Toolbook for Quality Improvement and Problem Solving (contents)

IDEF0: How to do itThe Quality Toolbook > IDEF0 > How to do it

When to use it | How to understand it | Example | How to do it | Practical variations

<-- Previous | Next -->

How to do it1. Identify the system or process to be described. Use a name that clearly indicates what it is, possibly adding further description of what is and what is not

included.

2. Identify the purpose or objectives of describing the process. This will help to determine whether IDEF0 is an appropriate tool, and will also help whenmaking other decisions, for example whether to decompose the system further at lower levels.

3. Decide on the viewpoint from which the process is to be described. For example, a sales manager might have a broader view of a sales process than asales person, as the sales manager includes the clerical activities in the sales office as well as the customer-salesperson process.

The objectives from step 2 will help with this decision. For example, if the objective is to improve the amount of direct sales, then the viewpoint of thesalesperson may be most appropriate.

4. Identify the decomposition strategy to be used. This is the set of rules to use when deciding how to break down activities into sub-activities, and maydepend on the type of system being described and the objectives from step 2. Possible strategies include:

Functional decomposition breaks down activities according to what is done, rather than how it is done, and is probably the most common strategy.Role decomposition breaks down things according to who does what. It can be an easy and useful starting point, but is likely to constrainimprovements if it is maintained.Subsystems decomposition divides systems first by major subsystem. This is useful when these subsystems are largely independent of one another.Lifecycle decomposition breaks down a system first by the phases of activity. Again, this is most useful when these phases are clearly defined andrelatively independent.

5. Before starting to draw diagrams, gather information about the system. This may start with reading of existing documents or observing the process inaction, but the most useful activity is likely to be formal interviews with selected people. This not only is the best source of information, but it will alsohelp to gain involvement and acceptance in any later improvements. Use the following process for interviews:

In the initial interview, aim first to agree the purpose and viewpoint, then find sufficient details to be able to draw the first two levels only (A-0 andA0).Before each interview, review existing information and identify the scope of what is to be identified.In interviews, work to acquire the most useful information, asking open questions, probing in key areas and checking the validity of assumptions.First, find out what is produced by and used within the process, including inputs, controls, outputs and mechanisms. This can be helped by askingquestions of the process, starting with outputs (What is produced?) and work backwards (What is needed to produce this?). This will result in a listof items (often called the data list) that will form the arrows in the diagram.Next, use the data list to identify the list of activities within the process, asking how items are used or produced.Then explore how activities and data items relate to one another and how they group together. This will result in a list something like Fig. 1.

Fig. 1. Sketch of data, activities and ICOM

Free Flowchart Software

AStepByStepIDEFØTutorial(4)6.  Fromtheinformationgainedinstep5,drawasetofdiagrams.DrawtheA0diagram

first,asillustrated,thensummarizethisintheA-0 diagram.Whendrawingadiagram,usethefollowingsequenceofactions:a.  Usethedecompositionstrategyfromstep4toidentifybetweenthreeandsixactivitiesthat

willbeshownonthediagram(aroundfourisoftenbest).Itcanbeusefultotryseveraldifferentdecompositionsbeforesettlingonone.

b.  Sorttheseactivitiesintotheorderofdominance.Themoredominantofapairofactivitiesisonewhichhasthegreatestinfluenceovertheother.Forexample'produceplan'hashigherdominancethan'buildproduct'.

c.  Placetheactivityboxesonthediagram,usingthegenerallayoutstrategyofputtingmostdominantactivityinthetopleft,withsubsequentactivitiesalongthediagonal,suchthattheleastdominantactivityendsupinthebottomrightcorner.Whenpositioningtheactivities,trytothinkaheadtowherearrowswillgo.Putthenameofeachactivityinitsbox.

d.  Drawthearrowsforeachdataitem,startingwithinputsandoutputs,thenaddingcontrolsthenmechanisms.1)  Combineandsplitlinestohelpsimplifythediagram.2)  Whenthelinesaredrawn,writeinthelabelsforeachline,beingcarefulthatthelabelcannot

mistakenlybeconfusedwithanotheritem.3)  Ifalabelisnotclearlyassociatedwithasingleline,drawashortsquigglylinebetweenitandtheline.

e.  Addparentheses('tunnel'marks)totheendofanylinewhichwillnotbeshowninitsparentorchilddiagram,asillustrated.Tunnelitemsthatwillnotaddusefulinformationelsewhere.

f.  Identifythediagramwithanodename,titleandC-number,asillustratedonnextslide.1)  Itmayalsobeusefultoaddotherdata,suchasthedateandthestatusofthediagram(e.g.initial,

draft,final).Usealog,asillustrated,toensurethatallC-numbersareunique.g.  Reviewthecompleteddiagramforcorrectness,consistency,completenessandclarity.

Checkitagainstthepurpose(step2),viewpoint(step3),decompositionstrategy(step4)andavailableinformation(step5).Reviseandrepeattheabovestepsasnecessary.

36

AStepByStepIDEFØTutorial(5)

37

Fig. 2. A-0 Diagram

The box (or node) in the A-0 diagram is then decomposed (or 'exploded' or 'zoomed') into a diagram with between three and six boxes, as illustrated. This iscalled the 'A0' diagram.

This hierarchical decomposition is repeated for each box in this diagram, then for each box in the resultant diagrams and so on, until the process is fullydescribed.

In any diagram, the boxes are generally laid out from the top left to the bottom right, in order of dominance, where a higher dominance box has a greaterinfluence over a lower dominance box. Boxes are numbered in order of dominance, with the number being used to reference the box on other diagrams. Thusthe first box in the A0 diagram is decomposed in diagram A1, and the third box in that diagram is decomposed as A13.

Arrows carry multiple items, and are merged or split to simplify the diagram. Names next to arrows should describe what they carry; where there are nonames, the arrow contents may be deduced. Arrows which do not connect to a box at one end are those that come from or go to the parent box, from whichthis diagram is decomposed. These arrows are numbered to indicate which ICOM arrow they represent. Thus, C1 represents the leftmost control and I2 is thesecond input down on the parent box. Parentheses (a 'tunnel') at one end of an arrow indicates that this arrow does not appear on the parent or child diagram.

Fig. 3. A0 Diagram

There are only five types of connection that arrows can make between boxes, as indicated in the table below, which show how activities feed, enable orconstrain one another. The mix of connection types in one set of diagram will indicate the overall system type. For example, a process with little feedback mayindicate a lack of control.

A-0 Diagram

AStepByStepIDEFØTutorial(6)7.  Foreachdiagram,itisusefultowriteaGlossarypagethatfurtherdescribeseachdata

item,asillustrated.Thiscancontainanytextthatwillhelptheunderstandingofindividualitemsortheoverallsystem,althoughitshouldbekeptbrief,toavoidan'informationoverload'.

38

6. From the information gained in step 5, draw a set of diagrams. Draw the A0 diagram first, as illustrated, then summarize this in the A-0 diagram, asillustrated.

When drawing a diagram, use the following sequence of actions:

a. Use the decomposition strategy from step 4 to identify between three and six activities that will be shown on the diagram (around four is often best). Itcan be useful to try several different decompositions before settling on one.

b. Sort these activities into the order of dominance. The more dominant of a pair of activities is one which has the greatest influence over the other. Forexample 'produce plan' has higher dominance than 'build product'.

c. Place the activity boxes on the diagram, using the general layout strategy of putting most dominant activity in the top left, with subsequent activitiesalong the diagonal, such that the least dominant activity ends up in the bottom right corner. When positioning the activities, try to think ahead towhere arrows will go. Put the name of each activity in its box.

d. Draw the arrows for each data item, starting with inputs and outputs, then adding controls then mechanisms. Combine and split lines to help simplifythe diagram. When the lines are drawn, write in the labels for each line, being careful that the label cannot mistakenly be confused with another item.If a label is not clearly associated with a single line, draw a short line between it and the line, as illustrated.

e. Add parentheses ('tunnel' marks) to the end of any line which will not be shown in its parent or child diagram, as illustrated. Tunnel items that will notadd useful information elsewhere. It is common to tunnel mechanisms at higher levels, so they do not appear on lower level diagrams.

f. Identify the diagram with a node name, title and C-number, as illustrated. It may also be useful to add other data, such as the date and the status ofthe diagram (e.g. initial, draft, final). Use a log, as illustrated, to ensure that all C-numbers are unique.

g. Review the completed diagram for correctness, consistency, completeness and clarity. Check it against the purpose (step 2), viewpoint (step 3),decomposition strategy (step 4) and available information (step 5). Revise and repeat the above steps as necessary.

7. For each diagram, it is useful to write a Glossary page, as Fig. 2, that further describes each data item, as illustrated. This can contain any text that willhelp the understanding of individual items or the overall system, although it should be kept brief, to avoid an 'information overload'.

Fig. 2. Glossary page

Identify each page of the glossary with a title the same as its diagram, but with 'Gn' added to the node name, where 'n' is the page number in theglossary, and '(Glossary)' appended to the title. Use a unique C-number, adding each page to the C-number log.

Note that ICOM items from the parent diagram are not included in the glossary, as this would result in duplicate glossary entries and consequentsynchronization problems.

8. Decide whether to review the pages produced so far. It is useful to review early, when the A-0 and A0 diagrams (and possibly the level below) are

AStepByStepIDEFØTutorial(7)8.  Decidewhethertoreviewthepagesproducedsofar.

a.  Itisusefultoreviewearly,whentheA-0andA0diagrams(andpossiblythelevelbelow)arecompleted,andsubsequentlywhensignificantchangeshavebeenmade.1)  Ifyoudoholdareviewuntilallpagesarecompleted,thenthiscanresultinsignificant

extraeffortbeingspentinrework.b. Whenholdingareview,firstcreateakit,consistingofallpagesrequiring

review,togetherwithacoverpage,andsendittoappropriatecontributingexpertsforreview.1)  Thecoverpagedetailsthereviewerlist,thecontentsofthekitandwhatisexpectedof

thereviewers,includingwhentoreturnitandanyotherspecialinstructions.c.  Thereviewersreadthepagesinthekitandwritecorrections,inreddirectlyon

thepagesofthekit,beforereturningittotheauthor.Specificitemstoreviewinclude:1)  Thedetailofeachdiagram,includingthetitleandnodename,allactivitiesandarrows,

additionalglossariesandothermaterial.2)  Theoverallsystem,andhowthediagramsfittogether,includinguseofthestated

breakdownstrategy.3)  Howwellthestatedviewpointisrepresented.

d.  Theauthorthenexaminesthereviewer'scorrectionsandwritescommentsinblueink(thusdifferentiatingfromthereviewer'scorrections).1)  Agreementwithreviewercorrectionsareshownwithticksandothercommentsare

writtenalongside.e.  Theauthorandeachreviewerthenmeetanddiscussthecommentsand

corrections.Theyagreetoactualchangeswhichtheauthorthenimplements.1)  Makesurethatwhenanitemischanged,allotherdiagramsaffectedbythechangeare

alsoupdated. 39

AStepByStepIDEFØTutorial(8)9. Foreachboxwhichhasnotyetbeendecomposed,decidewhetheritisworthtakingthisstep,orwhethersufficientdetailexistsatthispoint.Considerationsofwhethertostopdecompositioninclude:a.  Thefinalsetofdiagrams(or'model')shouldcontain

sufficientdetailtosatisfythestatedpurposefromstep2.b.  Agoodpointtostopiswhenboxesstartsaying'how'instead

of'what',orwheretheviewpointchanges.c.  Boxesshoulddescribeactivitiesthataresolidandunique

functions,nottrivialitemsnorduplicatesofotherboxes.d.  Forboxesthataretobedecomposedfurther,theabove

processofinterview,createandreviewisrepeatedasrequired.1)  Generally,theprocessexpertsshouldbefullyinvolved,buttheyshouldnotbeworndownwithtoomanyinterviewsandreviews,asthisislikelytocausethemtobecomeannoyedanddisinterested,withconsequentdamagetothemodelanditsuse.

40

IDEFØClassExercise�  ConsidertheA-0ProcessforSystemLevelDesignasdefinedbelow.DrawtheA0diagramofthisprocess.

41

Design Function Major Inputs Major Outputs

Develop Operational Concept

Stakeholders’ Inputs Objective Hierarchy & Value

Parameters for Meta-System Recommended Concept

Operational Concept System Concept Input-output traces Meta-system MOEs

Define System Boundary with External Systems Diagram

Operational Concept System Boundary, System’s Inputs and Outputs

Develop System Objectives Hierarchy

Operational Concept Stakeholders’ Inputs

System-level Objectives Hierarchy

Develop, Analyze and Refine Requirements (Stakeholders’ and System)

Operational Concept System Boundary, Inputs &

Outputs Objectives Hierarchy

Stakeholders’ Inputs

Stakeholders’ & Systems Requirements

Ensure Requirements Feasibility

Stakeholders’ & Systems Requirements SE Team’s Inputs

Design Feasibility

Define the Test System Requirements

Stakeholders’ & Systems Requirements Stakeholders’ Inputs

Test System Requirements

Obtain Approval of System Documentation

Stakeholders’ & Systems Requirements

Stakeholder’ & System Requirements Documents

FullExample

�  SeeIDEFØForWidgets.pdfinreferences

42