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