DraftFederalInformation

ProcessingStandardsPublication183
1993December21
AnnouncingtheStandardfor
INTEGRATIONDEFINITIONFORFUNCTION
MODELING(IDEF0)
FederalInformationProcessingStandardsPublications(FIPSPUBS)areissuedbythe
NationalInstituteofStandardsandTechnologyafterapprovalbytheSecretaryof
CommercepursuanttoSection111(d)oftheFederalPropertyandAdministrative
ServicesActof1949asamendedbytheComputerSecurityActof1987,PublicLaw
100235.
1.

NameofStandard. IntegrationDefinitionforFunctionModeling(IDEF0).

2.

CategoryofStandard.

SoftwareStandard,ModelingTechniques.

3.
Explanation. ThispublicationannouncestheadoptionoftheIntegration
DefinitionFunctionModeling(IDEF0)asaFederalInformationProcessingStandard
(FIPS).ThisstandardisbasedontheAirForceWrightAeronauticalLaboratories
IntegratedComputerAidedManufacturing(ICAM)Architecture,PartII,VolumeIV
FunctionModelingManual(IDEF0),June1981.
ThisstandarddescribestheIDEF0modelinglanguage(semanticsandsyntax),
andassociatedrulesandtechniques,fordevelopingstructuredgraphicalrepresentations
ofasystemorenterprise.Useofthisstandardpermitstheconstructionofmodels
comprisingsystemfunctions(activities,actions,processes,operations),functional
relationships,anddata(informationorobjects)thatsupportsystemsintegration.
Thisstandardisthereferenceauthorityforusebysystemorenterprisemodelers
requiredtoutilizetheIDEF0modelingtechnique,byimplementorsindevelopingtools
forimplementingthistechnique,andbyothercomputerprofessionalsinunderstanding
theprecisesyntacticandsemanticrulesofthestandard.
4.

ApprovingAuthority.

SecretaryofCommerce.

5.
MaintenanceAgency.
DepartmentofCommerce,NationalInstituteof
StandardsandTechnology,ComputerSystemsLaboratory.
6.

CrossIndex.
a.
ICAMArchitecturePartIIVolumeIVFunctionModelingManual
(IDEF0),AFWALTR814023,MaterialsLaboratory,AirForceWrightAeronautical
1

Laboratories,AirForceSystemsCommand,WrightPattersonAirForceBase,Ohio
45433,June1981.
7.

RelatedDocuments.
a.
FederalInformationResourcesManagementRegulationsSubpart
201.20.303,Standards,andSubpart201.39.1002,FederalStandards.
b.
IntegratedInformationSupportSystem(IISS),VolumeVCommonData
ModelSubsystem,Part4InformationModelingManualIDEF1Extended,December
1985.
c.
ICAMArchitecturePartII,VolumeVInformationModelingManual
(IDEF1),AFWALTR814023,MaterialsLaboratory,AirForceWrightAeronautical
Laboratories,AirForceSystemsCommand,WrightPattersonAirForceBase,Ohio
45433,June1981.
d.
ICAMConfigurationManagement,VolumeIIICAMDocumentation
StandardsforSystemsDevelopmentMethodology(SDM),AFWALTR824157,Air
ForceSystemsCommand,WrightPattersonAirForceBase,Ohio45433,October1983.
8.

Objectives.

Theprimaryobjectivesofthisstandardare:

a. Toprovideameansforcompletelyandconsistentlymodelingthefunctions
(activities,actions,processes,operations)requiredbyasystemorenterprise,
andthefunctionalrelationshipsanddata(informationorobjects)thatsupport
theintegrationofthosefunctions;
b. ToprovideamodelingtechniquewhichisindependentofComputerAided
SoftwareEngineering(CASE)methodsortools,butwhichcanbeusedin
conjunctionwiththosemethodsortools;
c.

Toprovideamodelingtechniquethathasthefollowingcharacteristics:
Generic(foranalysisofsystemsofvaryingpurpose,scopeand
complexity);
Rigorousandprecise(forproductionofcorrect,usablemodels);
Concise(tofacilitateunderstanding,communication,consensusand
validation);
Conceptual(forrepresentationoffunctionalrequirementsratherthan
physicalororganizationalimplementations);
Flexible(tosupportseveralphasesofthelifecycleofaproject).

9.
Applicability.
Theuseofthisstandardisstronglyrecommendedforprojectsthat:
a. Requireamodelingtechniquefortheanalysis,development,reengineering,
integration,oracquisitionofinformationsystems;
b. Incorporateasystemsorenterprisemodelingtechniqueintoabusinessprocess
analysisorsoftwareengineeringmethodology.
2

Thespecificationsofthisstandardareapplicablewhensystemorenterprise
modelingtechniquesareappliedtothefollowing:
a. ProjectsrequiringIDEF0asthemodelingtechnique;
b. DevelopmentofautomatedsoftwaretoolsimplementingtheIDEF0modeling
technique.
Thespecificationsofthisstandardarenotapplicabletothoseprojectsrequiringa
functionmodelingtechniqueotherthanIDEF0.
NonstandardfeaturesoftheIDEF0techniqueshouldbeusedonlywhenthe
neededoperationorfunctioncannotreasonablybeimplementedwiththestandard
featuresalone.Althoughnonstandardfeaturescanbeveryuseful,itshouldbe
recognizedthattheuseoftheseoranyothernonstandardelementsmaymakethe
integrationofmodelsmoredifficultandcostly.
10.
Specifications.
ThisstandardadoptstheIntegrationDefinitionforFunction
Modeling(IDEF0)asaFederalInformationProcessingStandard(FIPS).
11.
Implementation.
Theimplementationofthisstandardinvolvestwoareasof
consideration:acquisitionofimplementationsandinterpretationofthestandard.
11.1AcquisitionofIDEF0Implementations.
Thispublication(FIPS183)
iseffectiveJune30,1994.ForFederalacquisitionsafterthisdate,projectsutilizingthe
IDEF0functionmodelingtechnique,orsoftwareimplementingtheIDEF0modeling
technique,shouldconformtoFIPS183.Conformancetothisstandardshouldbe
consideredwhethertheprojectorsoftwareutilizingtheIDEF0modelingtechniqueis
acquiredaspartofanADPsystemprocurement,acquiredbyseparateprocurement,used
underanADPleasingarrangement,orspecifiedforuseincontractsforprogramming
services.
Atransitionperiodprovidestimeforindustrytodevelopproductsconformingto
thisstandard.Thetransitionperiodbeginsontheeffectivedateandcontinuesforone(1)
yearthereafter.Theprovisionsofthispublicationapplytoordersplacedafterthedateof
thispublication;however,utilizingafunctionmodelingtechniquethatdoesnotconform
tothisstandardmaybepermittedduringthetransitionperiod.
11.2InterpretationofthisFIPS. NISTprovidesfortheresolutionof
questionsregardingtheimplementationandapplicabilityofthisFIPS.Allquestions
concerningtheinterpretationofthisstandardshouldbeaddressedto:
Director,ComputerSystemsLaboratory
ATTN:FIPSIDEF0Interpretation
NationalInstituteofStandardsandTechnology
Gaithersburg,MD20899
3

12
Waivers.
Undercertainexceptionalcircumstances,theheadsofFederal
departmentsandagenciesmayapprovewaiverstoFederalInformationProcessing
Standards(FIPS).Theheadofsuchagenciesmayredelegatesuchauthorityonlytoa
seniorofficialdesignatedpursuanttosection3506(b)ofTitle44,UnitedStatesCode.
Requestsforwaiversshallbegrantedonlywhen:
a. Compliancewithastandardwouldadverselyaffecttheaccomplishmentofthe
missionofanoperatorofaFederalcomputersystem,or
b. Compliancewithastandardwouldcauseamajoradversefinancialimpacton
theoperatorwhichisnotoffsetbygovernmentwidesavings.
Agencyheadsmayapproverequestsforwaiversonlybyawrittendecisionwhich
explainsthebasisuponwhichtheagencyheadmadetherequiredfinding(s).Acopyof
eachsuchdecision,withprocurementsensitiveorclassifiedportionsclearlyidentified,
shallbesentto:
Director,ComputerSystemsLaboratory
ATTN:FIPSWaiverDecisions
NationalInstituteofStandardsandTechnology
Gaithersburg,MD20899
Inaddition,noticeofeachwaivergrantedandeachdelegationofauthorityto
approvewaiversshallbesentpromptlytotheCommitteeonGovernmentOperationsof
theHouseofRepresentativesandtheCommitteeonGovernmentAffairsoftheSenate
andshallbepublishedpromptlyintheFederalRegister.
Whenthedeterminationonawaiverrequestappliestotheprocurementof
equipmentand/orservices,anoticeofthewaiverdeterminationmustbepublishedinthe
CommerceBusinessDailyasapartofthenoticeofsolicitationforoffersofan
acquisitionor,ifthewaiverdeterminationismadeafterthatnoticeispublished,by
amendmentofsuchnotice.
Acopyofthewaiverrequest,anysupportingdocuments,thedocumentapproving
thewaiverrequestandanysupportingandaccompanyingdocuments,withsuchdeletions
astheagencyisauthorizedanddecidestomakeunder5U.S.C.Sec.552(b),shallbepart
oftheprocurementdocumentationandretainedbytheagency.
13.
WheretoObtainCopies. Copiesofthispublicationareforsalebythe
NationalTechnicalInformationService,U.S.DepartmentofCommerce,Springfield,VA
22161.Whenordering,refertoFederalInformationProcessingStandardsPublication
183(FIPSPUB183)andtitle.Paymentmaybemadebycheck,moneyorder,ordeposit
account._

Introduction:
Thisstandardiscomposedofnormativeandinformativesections.Compliancewiththe
normativesections(Sections1through3)isrequired.Theinformativesections(Annexes
A through D) provide additional suggestions and guidance. Compliance with the
informativesectionsisnotrequiredtocomplywiththestandard,unlesssuchcompliance
isstipulatedbyanorganizationadoptingthisstandard.
This informative introduction discusses the background and approach of IDEF0
(pronouncedIdefzero).Itprovidesthereaderwithanorientationandapproachtothe
normativesections.

Background:
During the 1970s, the U.S. Air Force Program for Integrated Computer Aided
Manufacturing(ICAM)soughttoincreasemanufacturingproductivitythroughsystematic
applicationofcomputertechnology. TheICAMprogramidentifiedtheneedforbetter
analysisandcommunicationtechniquesforpeopleinvolvedinimprovingmanufacturing
productivity.
Asaresult,theICAMprogramdevelopedaseriesoftechniquesknownastheIDEF
(ICAMDefinition)techniqueswhichincludedthefollowing:
1.

IDEF0, used to produce a "function model". A function model is a

structuredrepresentationofthefunctions,activitiesorprocesseswithinthe
modeledsystemorsubjectarea.

2.

IDEF1,usedtoproducean"informationmodel".Aninformationmodel
representsthestructureandsemanticsofinformationwithinthemodeled
systemorsubjectarea.

3.

IDEF2, used to produce a "dynamics model". A dynamics model

represents the timevarying behavioral characteristics of the modeled
systemorsubjectarea.

In1983,theU.S.AirForceIntegratedInformationSupportSystemprogramenhanced
the IDEF1 information modeling technique to form IDEF1X (IDEF1 Extended), a
semanticdatamodelingtechnique.
Currently,IDEF0andIDEF1Xtechniquesarewidelyusedinthegovernment,industrial
andcommercialsectors,supportingmodelingeffortsforawiderangeofenterprisesand
applicationdomains.
In1991theNationalInstituteofStandardsandTechnology(NIST)receivedsupportfrom
the U.S. Department of Defense, Office of Corporate Information Management
5

(DoD/CIM),todeveloponeormoreFederalInformationProcessingStandards(FIPS)for
modelingtechniques. ThetechniquesselectedwereIDEF0forfunctionmodelingand
IDEF1X for information modeling. These FIPS documents are based on the IDEF
manualspublishedbytheU.S.AirForceintheearly1980s.

TheIDEF0Approach:
IDEF0(IntegrationDEFinitionlanguage0)isbasedon SADT (StructuredAnalysis
and Design Technique ), developed by Douglas T. Ross and SofTech, Inc. In its
originalform,IDEF0includesbothadefinitionofagraphicalmodelinglanguage(syntax
and semantics) and a description of a comprehensive methodology for developing
models.
IDEF0maybeusedtomodelawidevarietyofautomatedandnonautomatedsystems.
Fornewsystems,IDEF0maybeusedfirsttodefinetherequirementsandspecifythe
functions, and then to design an implementation that meets the requirements and
performsthefunctions.Forexistingsystems,IDEF0canbeusedtoanalyzethefunctions
thesystemperformsandtorecordthemechanisms(means)bywhichthesearedone.
TheresultofapplyingIDEF0toasystemisamodelthatconsistsofahierarchicalseries
of diagrams, text, and glossary crossreferenced to each other. The two primary
modelingcomponentsarefunctions(representedonadiagrambyboxes)andthedataand
objectsthatinterrelatethosefunctions(representedbyarrows).
Asafunctionmodelinglanguage,IDEF0hasthefollowingcharacteristics:
1.

Itiscomprehensiveandexpressive,capableofgraphicallyrepresentinga
wide variety of business, manufacturing and other types of enterprise
operationstoanylevelofdetail.

2.

Itisacoherentandsimplelanguage,providingforrigorousandprecise
expression,andpromotingconsistencyofusageandinterpretation.

3.

It enhances communication between systems analysts, developers and

usersthrougheaseoflearninganditsemphasisonhierarchicalexposition
ofdetail.

4.

Itiswelltestedandproven,throughmanyyearsofuseinAirForceand
othergovernmentdevelopmentprojects,andbyprivateindustry.

5.

Itcanbegenerated byavarietyofcomputergraphics tools;numerous

commercial products specifically support development and analysis of
IDEF0diagramsandmodels.

InadditiontodefinitionoftheIDEF0language,theIDEF0methodologyalsoprescribes
proceduresandtechniques fordevelopingandinterpretingmodels,includingonesfor
data gathering, diagram construction, review cycles and documentation. Materials
relatedsolelytomodelingproceduresarepresentedintheinformativeannexesofthis
document.
7

TableofContents
1.Overview
....................................................................................................................................
1
1.1 Scope
...............................................................................................................
1
1.2 Purpose
...............................................................................................................
1
2.Definitions
....................................................................................................................................
2
3.IDEF0Models
....................................................................................................................................
5
3.1 ModelConcepts
...............................................................................................................
5
3.2 SyntaxandSemantics
...............................................................................................................
6
3.2.1 Syntax
................................................................................................
6
3.2.1.1 Boxes
.................................................................................
6
3.2.1.2 Arrows
.................................................................................
6
3.2.1.3 SyntaxRules
.................................................................................
7
3.2.2 Semantics
................................................................................................
7
3.2.2.1 BoxandArrowSemantics
.................................................................................
7
3.2.2.2 LabelsandNames
.................................................................................
9
8

3.2.2.3
3.3

BoxandArrowSemanticRules
.................................................................................
9

IDEF0Diagrams
...............................................................................................................
10
3.3.1 TypesofDiagrams
................................................................................................
10
3.3.1.1 TopLevelContextDiagram
.................................................................................
10
3.3.1.2 ChildDiagram
.................................................................................
11
3.3.1.3 ParentDiagram
.................................................................................
11
3.3.1.4 TextandGlossary
.................................................................................
13
3.3.1.5 ForExpositionOnlyDiagrams
.................................................................................
14
3.3.2 DiagramFeatures
................................................................................................
14
3.3.2.1 ArrowsasConstraints
.................................................................................
14
3.3.2.2 ActivationsofaBox
.................................................................................
14
3.3.2.3 ConcurrentOperation
.................................................................................
15
3.3.2.4 ArrowsasPipelines
.................................................................................
15
3.3.2.5 BranchingArrows
.................................................................................
16
3.3.2.6 InterBoxConnections
.................................................................................
16
3.3.2.7 BoundaryArrows
9

.................................................................................
18
3.3.2.8 ICOMCodingofBoundaryArrows
.................................................................................
18
3.3.2.9 TunneledArrows
.................................................................................
20
3.3.2.10 CallArrows
...............................................................................
22
3.3.3 DiagramSyntaxRules
................................................................................................
22
3.3.4 DiagramReferenceExpressions
................................................................................................
23
3.3.4.1 BoxNumbers
.................................................................................
23
3.3.4.2 NodeNumbers
.................................................................................
24
3.3.4.2.1 NodeIndex
..................................................................
24
3.3.4.2.2 NodeTree
..................................................................
25
3.3.4.3 NodeReferences
.................................................................................
26
3.3.4.4 ModelNotes
.................................................................................
26
3.3.4.5 ReferenceNotation
.................................................................................
27
3.4 Models
...............................................................................................................
28
3.4.1 IDEF0ModelDescription
................................................................................................
28
3.4.2 ContextDiagrams
10

3.4.3
3.4.4
3.4.5
3.4.6

................................................................................................
28
HighLevelContextDiagrams
................................................................................................
29
FEOs,TextandGlossary
................................................................................................
30
ModelName
................................................................................................
30
PresentationRules
................................................................................................
30

11

ANNEXAIDEF0CONCEPTS
....................................................................................................................................
31
A.1 Background
...............................................................................................................
31
A.2 IDEF0Concepts
...............................................................................................................
32
A.3 DiscussionofIndividualIDEF0Concepts
...............................................................................................................
33
A.3.1 ActivityModelingGraphics
................................................................................................
33
A.3.2 CommunicationbyGradualExpositionofDetail
................................................................................................
34
A.3.3 DisciplinedTeamwork
................................................................................................
36
ANNEXBCREATINGANDINTERPRETINGIDEF0DIAGRAMS
....................................................................................................................................
37
B.1 ReadingIDEF0Diagrams
...............................................................................................................
37
B.1.1 ApproachingaModel
................................................................................................
38
B.1.2 DiagramReadingSteps
................................................................................................
39
B.1.3 SemanticsofBoxesandArrows
................................................................................................
41
B.1.3.1 ConstraintsOmitHowandWhen
.................................................................................
41
B.1.3.2 MultipleInputs,ControlsandOutputs
12

.................................................................................
42
B.2 Author'sGuidetoCreatingIDEF0Diagrams
...............................................................................................................
44
B.2.1 BasicStepsofAuthoring
................................................................................................
44
B.2.1.1 SelectingaContext,ViewpointandPurpose
.................................................................................
45
B.2.1.2 CreatingtheContextDiagram
.................................................................................
45
B.2.1.3 CreatingtheTopMostDiagram
.................................................................................
45
B.2.1.4 CreatingChildDiagrams
.................................................................................
46
B.2.1.5 CreatingSupportingMaterial
.................................................................................
46
B.2.1.6 SelectingaBoxtoDetail
.................................................................................
47
B.2.1.7 AuthorActivities
.................................................................................
47
B.2.1.7.1 DataGatheringPhase
..................................................................
47
B.2.1.7.2 StructuringPhase
..................................................................
47
B.2.1.7.3 PresentationPhase
..................................................................
48
B.2.1.7.4 InteractionPhase
..................................................................
48
B.2.2 DrawinganIDEF0Diagram
................................................................................................
48
B.2.2.1 GeneratingFunctionBoxes
13

.................................................................................
48
B.2.2.2 CreatingInterfaceArrows
.................................................................................
49
B.2.2.3 LevelofEffort
.................................................................................
51
B.2.3 ReDrawinganIDEF0Diagram
................................................................................................
51
B.2.3.1 ModifyingBoxes
.................................................................................
51
B.2.3.2 BundlingArrows
.................................................................................
52
B.2.3.3 ProposingModificationstotheContext
.................................................................................
52
B.2.3.4 ICOMSyntaxforConnectingDiagrams
.................................................................................
53
B.2.4 GraphicLayout
................................................................................................
53
B.2.4.1 ConstraintsontheDiagram
.................................................................................
53
B.2.4.2 ArrowPlacement
.................................................................................
54
B.2.4.3 ArrowLayout
.................................................................................
55
B.2.5 WritingText
................................................................................................
57
B.2.5.1 TextandGlossary
.................................................................................
57
B.2.5.2 NotesandReferences
.................................................................................
58
B.3 DataCollectionforIDEFModeling
14

...............................................................................................................
60
B.3.1 Introduction
................................................................................................
60
B.3.2 TheInterviewProcess
................................................................................................
60
B.3.3 TheInterviewKit
................................................................................................
61

15

ANNEXCREVIEWCYCLEPROCEDURESANDFORMS
....................................................................................................................................
62
C.1 IDEFTeamworkDiscipline
...............................................................................................................
62
C.2 TheIDEFKitCycle
...............................................................................................................
62
C.2.1 PersonnelRoles
................................................................................................
64
C.2.1.1 Author
.................................................................................
64
C.2.1.2 Commenter
.................................................................................
64
C.2.2 GuidelinesforAuthorsandReadersandCommenters
................................................................................................
65
C.2.2.1 ReaderGuidelines
.................................................................................
65
C.2.2.2 Author/CommenterInterchanges
.................................................................................
65
C.2.2.3 MeetingGuidelines
.................................................................................
65
C.3 IDEFKits
...............................................................................................................
66
C.3.1 CompletingaKitCoverSheet
................................................................................................
66
C.3.2 HowtoPrepareaStandardKit
................................................................................................
70
C.4 StandardDiagramForm
...............................................................................................................
70
16

C.4.1 WorkingInformation
................................................................................................
72
C.4.1.1 TheAuthor/Date/ProjectField
.................................................................................
72
C.4.1.2 The"ReaderNotes"Field
.................................................................................
72
C.4.1.3 TheStatusField
.................................................................................
72
C.4.1.4 TheReader/DateField
.................................................................................
73
C.4.1.5 TheContextField
.................................................................................
73
C.4.1.6 TheUsedAtField
.................................................................................
73
C.4.2 TheMessageField
................................................................................................
74
C.4.3 TheNodeField
................................................................................................
74
C.4.4 TheTitleField
................................................................................................
74
C.4.5 TheNumberField
................................................................................................
74
C.4.5.1 TheNumberField(LargeArea)
.................................................................................
74
C.4.5.2 TheNumberField(KitPageNumberSmall
RectangleArea)
.................................................................................
74
C.5 KeepingFiles
...............................................................................................................
75
C.6 TheIDEFModelWalkThroughProcedure
17

...............................................................................................................
75
ANNEXDInformativeDefinitions
....................................................................................................................................
79

18

1. Overview
1.1Scope
Thisstandarddescribesthemodelinglanguage(syntaxandsemantics)which supports
theIDEF0techniquefordevelopingstructuredgraphicalrepresentationsofasystemor
subjectarea.UseofthisstandardpermitstheconstructionofIDEF0modelscomprising
systemfunctions(actions,processes,operations),functionalrelationships,andthedata
andobjectsthatsupportsystemsanalysisanddesign,enterpriseanalysis,and business
processreengineering.
Thisdocumentprovidesthreenormativesections,Sections1,2and3,whichdefinethe
languagethatsupportsIDEF0modeling.Thissection,Section1,providesanoverview
ofthedocument.Section2definesthekeytermsusedinthenormativesections.Section
3definesthesyntaxandsemanticsofthelanguage.
Inadditiontothethreenormativesections,thisdocumentalsoprovidesfourinformative
annexes. Annex A discusses the concepts that underlie IDEF0. Annex B provides
guidelinesforcreating,interpretingandgatheringdataforIDEF0diagrams. AnnexC
describesstructuredteamorientedprocedures(includingforms)forIDEF0modelreview
andvalidation.AnnexDdefinesthekeytermsusedintheannexes.
ThisstandardcoversIDEF0asdefinedbytheU.S.AirForceIntegratedComputerAided
Manufacturing(ICAM)FunctionModelingManual(IDEF0),June1981,andcommonly
practicedbymanyIDEFuserssincethen.

1.2Purpose
Theprimaryobjectivesofthisstandardare:
1.

To document and clarify the IDEF0 modeling technique and how to

correctlyuseit;

2.

To provide a means for completely and consistently modeling the

functionsrequiredbyasystemorsubjectarea,andthedataandobjects
thatinterrelatethosefunctions;

3.

ToprovideamodelinglanguagewhichisindependentofComputerAided
SoftwareEngineering(CASE)methodsortools,butwhichcanbeusedin
conjunctionwiththosemethodsortools;

4.

Toprovideamodelinglanguagethathasthefollowingcharacteristics:
a)

Generic (for analysis of systems and subject areas of varying

purpose,scopeandcomplexity);
1

b)
c)
d)
e)

Rigorousandprecise(forproductionofcorrect,usablemodels);
Concise (to facilitate understanding, communication, consensus
andvalidation);
Conceptual (for representation of functional requirements
independentofphysicalororganizationalimplementations);
Flexible(tosupportseveralphasesofthelifecycleofaproject).

2.Definitions
Thissectioncontainsdefinitionsthatrelatetothenormativesectionsofthisdocument.
SeeAnnexDfordefinitionsfortheinformativeannexes.Aterm,ifdefined,isdefinedin
eitherSection2orAnnexD.
2.1 A0Diagram:ThespecialcaseofaoneboxIDEF0contextdiagram,containing
thetoplevelfunctionbeingmodeledanditsinputs,controls,outputsandmechanisms,
alongwithstatementsofmodelpurposeandviewpoint.
2.2 Arrow:Adirectedline,composedofoneormorearrowsegments,thatmodelsan
openchannelorconduitconveyingdataorobjectsfromsource(noarrowhead)touse
(with arrowhead). There are 4 arrow classes: Input Arrow, Output Arrow, Control
Arrow,andMechanismArrow(includesCallArrow). SeeArrowSegment,Boundary
Arrow,InternalArrow.
2.3 ArrowLabel:AnounornounphraseassociatedwithanIDEF0arroworarrow
segment,specifyingitsmeaning.
2.4 ArrowSegment: Alinesegmentthatoriginates orterminates ataboxside,a
branch(forkorjoin),oraboundary(unconnectedend).
2.5 BoundaryArrow: Anarrowwithoneend(sourceoruse)notconnectedtoany
boxonadiagram.ContrastwithInternalArrow.
2.6

Box:Arectangle,containinganameandnumber,usedtorepresentafunction.

2.7 BoxName:TheverborverbphraseplacedinsideanIDEF0boxtodescribethe
modeledfunction.
2.8 BoxNumber: Thenumber(0to6)placedinsidethelowerrightcornerofan
IDEF0boxtouniquelyidentifytheboxonadiagram.
2.9

Branch:Ajunction(forkorjoin)oftwoormorearrowsegments.

2.10 Bundling/Unbundling: The combining of arrow meanings into a composite

meaning (bundling), orthe separation ofarrow meanings (unbundling),expressedby
arrowjoinandforksyntax.
2.11 CNumber: A chronological creation number that may be used to uniquely
identifyadiagramandtotraceitshistory;maybeusedasaDetailReferenceExpression
tospecifyaparticularversionofadiagram.

2.12 CallArrow:Atypeofmechanismarrowthatenablesthesharingofdetailbetween
models(linkingthemtogether)orwithinamodel.
2.13 ChildBox:Aboxonachilddiagram.
2.14 ChildDiagram:Thediagramthatdetailsaparentbox.
2.15 Context:Theimmediateenvironmentinwhichafunction(orsetoffunctionsona
diagram)operates.
2.16 ContextDiagram: Adiagramthatpresentsthecontextofamodel,whosenode
numberisAn(ngreaterthanorequaltozero).TheoneboxA0diagramisarequired
contextdiagram;thosewithnodenumbersA1,A2,...areoptionalcontextdiagrams.
2.17 ControlArrow:TheclassofarrowsthatexpressIDEF0Control,i.e.,conditions
required to produce correct output. Data or objects modeled as controls may be
transformedbythefunction,creatingoutput.Controlarrowsareassociatedwiththetop
sideofanIDEF0box.
2.18 Decomposition: The partitioning of a modeled function into its component
functions.
2.19 DetailReferenceExpression(DRE):Areference(e.g.,nodenumber,Cnumber,
pagenumber)writtenbeneaththelowerrightcornerofanIDEF0boxtoshowthatitis
detailedandtoindicatewhichdiagramdetailsit.
2.20 Diagram:AsingleunitofanIDEF0modelthatpresentsthedetailsofabox.
2.21 DiagramNodeNumber:Thatpartofadiagram'snodereferencethatcorresponds
toitsparentboxnodenumber.
2.22 ForExpositionOnly(FEO)Diagram: Agraphicdescriptionusedtoexposeor
highlightspecificfactsaboutanIDEF0diagram.UnlikeanIDEF0graphicdiagram,a
FEOdiagramneednotcomplywithIDEF0rules.
2.23 Fork:ThejunctionatwhichanIDEF0arrowsegment(goingfromsourcetouse)
dividesintotwoormorearrowsegments.Maydenoteunbundlingofmeaning.
2.24 Function: Anactivity, process,ortransformation (modeled byan IDEF0box)
identifiedbyaverborverbphrasethatdescribeswhatmustbeaccomplished.
2.25 FunctionName:SameasBoxName.
2.26 Glossary: Alistingofdefinitionsforkeywords,phrasesandacronymsusedin
conjunctionwithanIDEF0nodeormodelasawhole.
4

2.27 ICOMCode: TheacronymofInput,Control,Output,Mechanism. Acodethat

associatestheboundaryarrowsofachilddiagramwiththearrowsofitsparentbox;also
usedforreferencepurposes.
2.28 IDEF0Model:Agraphicdescriptionofasystemorsubjectthatisdevelopedfora
specificpurposeandfromaselectedviewpoint.AsetofoneormoreIDEF0diagrams
thatdepictthefunctionsofasystemorsubjectareawithgraphics,textandglossary.
2.29 Input Arrow: The class of arrows that express IDEF0 Input, i.e., the data or
objectsthataretransformedbythefunctionintooutput.Inputarrowsareassociatedwith
theleftsideofanIDEF0box.
2.30 Interface: A shared boundary across which data or objects are passed; the
connectionbetweentwoormoremodelcomponentsforthepurposeofpassingdataor
objectsfromonetotheother.
2.31 InternalArrow:Aninput,controloroutputarrowconnectedatbothends(source
anduse)toaboxonadiagram.ContrastwithBoundaryArrow.
2.32 Join:ThejunctionatwhichanIDEF0arrowsegment(goingfromsourcetouse)
mergeswithoneormoreotherarrowsegmentstoformasinglearrowsegment. May
denotebundlingofarrowsegmentmeanings.
2.33 MechanismArrow:TheclassofarrowsthatexpressIDEF0Mechanism,i.e.,the
meansusedtoperformafunction;includesthespecialcaseofCallArrow.Mechanism
arrowsareassociatedwiththebottomsideofanIDEF0box.
2.34 ModelNote:AtextualcommentthatispartofanIDEF0diagram,usedtorecorda
factnototherwisedepicted.
2.35 Node: Aboxfromwhichchildboxesoriginate;aparentbox. SeeNodeIndex,
NodeTree,NodeNumber,NodeReference,DiagramNodeNumber.
2.36 Node Index: A listing, often indented, showing nodes in an IDEF0 model in
"outline"order.SamemeaningandcontentasNodeTree.
2.37 NodeNumber: Acodeassignedtoaboxtospecifyitspositioninthemodel
hierarchy;maybeusedasaDetailReferenceExpression.
2.38 Node Reference: A code assigned to a diagram to identify it and specify its
position in the model hierarchy; composed ofthe model name (abbreviated) and the
diagramnodenumber,withoptionalextensions.

2.39 NodeTree:Thegraphicalrepresentationoftheparentchildrelationshipsbetween
thenodesofanIDEF0model,intheformofagraphicaltree.Samemeaningandcontent
asNodeIndex.
2.40 OutputArrow: TheclassofarrowsthatexpressIDEF0Output,i.e.,thedataor
objectsproducedbyafunction.Outputarrowsareassociatedwiththerightsideofan
IDEF0box.
2.41 ParentBox:Aboxthatisdetailedbyachilddiagram.
2.42 ParentDiagram:Adiagramthatcontainsaparentbox.
2.43 Purpose:Abriefstatementofthereasonforamodel'sexistence.
2.44 Semantics:Themeaningofthesyntacticcomponentsofalanguage.
2.45 Squiggle: A small jagged line that may be used to associate a label with a
particulararrowsegmentortoassociateamodelnotewithacomponentofadiagram.
2.46 Syntax:Structuralcomponentsorfeaturesofalanguageandtherulesthatdefine
relationshipsamongthem.
2.47 Text: An overall textual (nongraphical) comment about an IDEF0 graphic
diagram.
2.48 Title: Averborverbphrasethatdescribestheoverallfunctionpresentedonan
IDEF0diagram;thetitleofachilddiagramcorrespondstoitsparentboxname.
2.49 Tunneled Arrow: An arrow (with special notation) that does not follow the
normalrequirementthateacharrowonadiagrammustcorrespondtoarrowsonrelated
parentandchilddiagrams.
2.50 Viewpoint:Abriefstatementoftheperspectiveofthemodel.

3.IDEF0Models
ThissectiondiscussesthebasicelementsoftheIDEF0modelingtechnique,identifiesthe
basiccomponentsofsyntax(graphicalcomponent)andsemantics(meaning),specifies
therulesthatgoverntheuseoftheIDEF0technique,anddescribesthetypesofdiagrams
used.Althoughthecomponentsofsyntaxandsemanticsareveryhighlyinterrelated,each
oneisdiscussedseparatelywithoutregardfortheactualsequenceofconstruction.

3.1ModelConcepts
Amodelisarepresentationofasetofcomponentsofasystemorsubjectarea. The
model is developed for understanding, analysis, improvement or replacement of the
system.Systemsarecomposedofinterfacingorinterdependentpartsthatworktogether
toperformausefulfunction.Systempartscanbeanycombinationofthings,including
people,information, software,processes, equipment,products,orrawmaterials. The
modeldescribeswhatasystemdoes,whatcontrolsit,whatthingsitworkson, what
meansitusestoperformitsfunctions,andwhatitproduces.
IDEF0isamodelingtechniquebasedoncombinedgraphicsandtextthatarepresentedin
anorganizedandsystematicwaytogainunderstanding,supportanalysis,providelogic
for potential changes, specify requirements, or support systems level design and
integrationactivities.AnIDEF0modeliscomposedofahierarchicalseriesofdiagrams
thatgraduallydisplayincreasinglevelsofdetaildescribingfunctionsandtheirinterfaces
withinthecontextofasystem. Therearethreetypesofdiagrams: graphic,text,and
glossary.Thegraphicdiagramsdefinefunctionsandfunctionalrelationshipsviaboxand
arrow syntax and semantics. The text and glossary diagrams provide additional
informationinsupportofgraphicdiagrams.
IDEF0isanengineeringtechniqueforperformingandmanagingneedsanalysis,benefits
analysis,requirementsdefinition,functionalanalysis,systemsdesign,maintenance,and
baselinesforcontinuousimprovement.IDEF0modelsprovidea"blueprint"offunctions
and their interfaces that must be captured and understood in order to make systems
engineering decisions that are logical, affordable, integratable and achievable. The
IDEF0modelreflectshowsystemfunctionsinterrelateandoperatejustastheblueprint
ofaproductreflectshowthedifferentpiecesofaproductfittogether.Whenusedina
systematicway,IDEF0providesasystemsengineeringapproachto:
1.

Performing systems analysis and design at all levels, for systems

composedofpeople,machines,materials,computersandinformationof
allvarietiestheentireenterprise,asystem,orasubjectarea;

2.

Producingreferencedocumentationconcurrentwithdevelopmenttoserve
asabasisforintegratingnewsystemsorimprovingexistingsystems;

3.

Communicatingamonganalysts,designers,users,andmanagers;
7

4.

Allowing coalition team consensus to be achieved by shared

understanding;

5.

Managing large and complex projects using qualitative measures of

progress;

6.

Providing a reference architecture for enterprise analysis, information

engineeringandresourcemanagement.

Furtherdiscussionofconcepts,philosophy,androlesforparticipantsinIDEF0modeling
projectsispresentedintheinformativeannexesofthisdocument.

3.2SyntaxandSemantics
3.2.1Syntax
The structural components and features of a language and the rules that define
relationshipsamongthemarereferredtoasthelanguage'ssyntax. Thecomponentsof
theIDEF0syntaxareboxesandarrows,rules,anddiagrams.Boxesrepresentfunctions,
defined as activities, processes or transformations. Arrows represent data or objects
related to functions. Rules define how the components are used, and the diagrams
provideaformatfordepictingmodelsbothverballyandgraphically. Theformatalso
providesthebasisformodelconfigurationmanagement.
3.2.1.1Boxes
Aboxprovidesadescriptionofwhathappensinadesignatedfunction.Atypicalboxis
showninFigure1.Eachboxshallhaveanameandnumberinsidetheboxboundaries.
Thenameshallbeanactiveverborverbphrasethatdescribesthefunction.Eachboxon
thediagramshallcontainaboxnumberinsidethelowerrightcorner.Boxnumbersare
usedtoidentifythesubjectboxintheassociatedtext.

Figure1.BoxSyntax
3.2.1.2Arrows
Anarrowiscomposedofoneormorelinesegments,withaterminalarrowheadatone
end.AsshowninFigure2,arrowsegmentsmaybestraightorcurved(witha90arc
connectinghorizontalandverticalparts),andmayhavebranching(forkingorjoining)
configurations. Arrowsdonotrepresentfloworsequenceasinthetraditionalprocess
flowmodel.Arrowsconveydataorobjectsrelatedtofunctionstobeperformed.The
functionsreceivingdataorobjectsareconstrainedbythedataorobjectsmadeavailable.

10

11

Figure2.ArrowSyntax
3.2.1.3SyntaxRules
Boxes
1.
2.
3.

Boxesshallbesufficientinsizetoinsertboxname.
Boxesshallberectangularinshape,withsquarecorners.
Boxesshallbedrawnwithsolidlines.

Arrows
1.
2.
3
4.
5.

Arrowsthatbendshallbecurvedusingonly90degreearcs.
Arrowsshallbedrawninsolidlinesegments.
Arrowsshallbedrawnverticallyorhorizontally,notdiagonally.
Arrowendsshalltouchtheouterperimeterofthefunctionboxandshall
notcrossintothebox.
Arrowsshallattachatboxsides,notatcorners.

3.2.2Semantics
Semantics refers to the meaning of syntactic components of a language and aids
correctness of interpretation. Interpretation addresses items such as box and arrow
notationandfunctionalrelationshipinterfaces.
3.2.2.1BoxandArrowSemantics
SinceIDEF0supportsfunctionmodeling,theboxnameshallbeaverborverbphrase,
suchasPerformInspection,thatisdescriptiveofthefunctionthattheboxrepresents.
Theexample"PerformInspection"functiontransformsuninspectedpartsintoinspected
parts. Thedefinitivestepbeyondthephrasenamingoftheboxistheincorporationof
arrows(matchingtheorientationoftheboxsides)thatcomplementandcompletethe
expressivepower(asdistinguishedfromtherepresentationalaspect)oftheIDEF0box.
Standardterminologyshallbeusedtoensureprecisecommunication.Boxmeaningsare
nameddescriptivelywith verbs or verb phrases and are split and clustered in
decomposition diagramming. Arrow meanings are bundled and unbundled in
diagrammingandthearrowsegmentsarelabeledwithnounsornounphrasestoexpress
meanings. Arrowsegment labels are prescriptive, constraining the meaning of their
segmenttoapplyexclusivelytotheparticulardataorobjectsthatthearrowsegment
graphically represents. Arrow meanings are further expressed through fork and join
syntax.
Eachsideofthefunctionboxhasastandardmeaningintermsofbox/arrowrelationships.
Thesideoftheboxwithwhichanarrowinterfacesreflectsthearrow's role. Arrows
12

enteringtheleftsideoftheboxareinputs.Inputsaretransformedorconsumedbythe
functiontoproduceoutputs.Arrowsenteringtheboxonthetoparecontrols.Controls
specify the conditions required for the function to produce correct outputs. Arrows
leavingaboxontherightsideareoutputs.Outputsarethedataorobjectsproducedby
thefunction.
Arrowsconnectedtothebottomsideoftheboxrepresentmechanisms.Upwardpointing
arrowsidentifysomeofthemeansthatsupporttheexecutionofthefunction. Other
meansmaybeinheritedfromtheparentbox. Mechanismarrowsthatpointdownward
arecallarrows.Callarrowsenablethesharingofdetailbetweenmodels(linkingthem
together)orbetweenportionsofthesamemodel.Thecalledboxprovidesdetailforthe
callerbox(seeSection3.3.2.10).
StandardarrowpositionsareshowninFigure3.
Supportinginformationconcerningthefunctionanditspurposeshallbeaddressedinthe
textassociatedwiththediagram.Adiagrammayormaynothaveassociatedtext.When
acronyms,abbreviations,keywords,orphrasesareused,thefullydefinedterm(s)shall
beprovidedintheglossary.

13

14

Figure3.ArrowPositionsandRoles

15

3.2.2.2LabelsandNames
Boxesrepresentfunctionsthatshowwhatmustbeaccomplished.Afunctionnameshall
beanactiveverborverbphrase,suchas:
processparts
monitorperformance
developdetaildesign

planresources
designsystem
fabricatecomponent

conductreview
providemaintenance
inspectpart

Thearrowsidentifydataorobjectsneededorproducedbythefunction.Eacharrowshall
belabeledwithanounornounphrase,suchas:
specifications
designrequirements
designengineer

testreport
detaildesign
boardassembly

budget
directive
requirements

AnexampledepictingtheplacementofarrowlabelsandboxnamesisshowninFigure
4.

16

17

Figure4.LabelandNameSemantics
3.2.2.3BoxandArrowSemanticRules
1.

Aboxshallbenamedwithanactiveverborverbphrase.

2.

Eachsideofafunctionboxshallhaveastandardbox/arrowrelationship:
a)
Inputarrowsshallinterfacewiththeleftsideofabox.
b)
Controlarrowsshallinterfacewiththetopsideofabox.
c)
Outputarrowsshallinterfacewiththerightsideofthebox.
d)
Mechanism arrows (except call arrows) shall point upward and
shallconnecttothebottomsideofthebox.
e)
Mechanismcallarrowsshallpointdownward,shallconnecttothe
bottom sideofthebox,andshallbelabeled withthereference
expressionfortheboxwhichdetailsthesubjectbox.

3.

Arrowsegments,exceptforcallarrows,shallbelabeledwithanounor
nounphraseunlessasinglearrowlabelclearlyappliestothearrowasa
whole.

18

4.

squiggle

19

20

) shall be used to link an arrow wit

5.

Arrow labels shall not consist solely of any of the following terms:
function,input,control,output,mechanism,orcall.

3.3IDEF0Diagrams
3.3.1TypesofDiagrams
IDEF0modelsarecomposedofthreetypesofinformation:graphicdiagrams,text,and
glossary.Thesediagramtypesarecrossreferencedtoeachother.Thegraphicdiagram
is the major component of an IDEF0 model, containing boxes, arrows, box/arrow
interconnectionsandassociatedrelationships.Boxesrepresenteachmajorfunctionofa
subject.Thesefunctionsarebrokendownordecomposedintomoredetaileddiagrams,
untilthesubjectisdescribedatalevelnecessarytosupportthegoalsofaparticular
project. The toplevel diagram in the model provides the most general or abstract
descriptionofthesubjectrepresentedbythemodel.Thisdiagramisfollowedbyaseries
ofchilddiagramsprovidingmoredetailaboutthesubject.
3.3.1.1TopLevelContextDiagram
Eachmodelshallhaveatoplevelcontextdiagram,onwhichthesubjectofthemodelis
representedbyasingleboxwithitsboundingarrows. ThisiscalledtheA0diagram
(pronouncedAminuszero).Thearrowsonthisdiagraminterfacewithfunctionsoutside
the subject area to establish model focus. Since a single box represents the whole
subject, thedescriptive namewrittenintheboxisgeneral. Thesameistrueofthe
interfacearrowssincetheyalsorepresentthecompletesetofexternalinterfacestothe
subject.TheA0diagramalsosetsthemodelscopeorboundaryandorientation.An
exampleA0diagramisshowninFigure5.
The A0 context diagram also shall present brief statements specifying the model's
viewpointandpurpose,whichhelptoguideandconstrainthecreationofthemodel.The
viewpoint determines what can be "seen" within the model context, and from what
perspectiveor"slant".Dependingontheaudience,differentstatementsofviewpointmay
beadoptedthatemphasizedifferentaspectsofthesubject.Thingsthatareimportantin
oneviewpointmaynotevenappearinamodelpresentedfromanotherviewpointofthe
samesubject.
Thestatementofpurposeexpressesthereasonwhythemodeliscreatedandactually
determinesthestructureofthemodel. Themostimportantfeaturescomefirstinthe
hierarchy, as thewholetoplevel functionisdecomposedintosubfunctionpartsthat
composeit,andthoseparts,inturn,arefurtherdecomposeduntilalloftherelevantdetail
of the whole viewpoint is adequately exposed. Each subfunction is modeled
individuallybyabox,withparentboxesdetailedbychilddiagramsatthenextlower
level.Allchilddiagramsmustbewithinthescopeofthetoplevelcontextdiagram.
21

22

23

Figure5.ExampleToplevelDiagram
3.3.1.2ChildDiagram
Thesinglefunctionrepresentedonthetoplevelcontextdiagrammaybedecomposed
intoitsmajorsubfunctionsbycreatingitschilddiagram. Inturn,eachofthesesub
functionsmaybedecomposed,eachcreatinganother,lowerlevelchilddiagram. Ona
givendiagram,someofthefunctions,noneofthefunctionsorallofthefunctionsmaybe
decomposed. Each child diagram contains the child boxes and arrows that provide
additionaldetailabouttheparentbox.
Thechilddiagramthatresultsfromthedecompositionofafunctioncoversthesame
scopeastheparentboxitdetails.Thus,achilddiagrammaybethoughtofasbeingthe
"inside"ofitsparentbox.ThisstructureisillustratedinFigure6.
3.3.1.3ParentDiagram
Aparentdiagramisonethatcontainsoneormoreparentboxes.Everyordinary(non
context)diagramisalsoachilddiagram,sincebydefinitionitdetailsaparentbox.Thus
adiagrammaybebothaparentdiagram(containingparentboxes)andachilddiagram
(detailingitsownparentbox).Likewise,aboxmaybebothaparentbox(detailedbya
childdiagram)andachildbox(appearingonachilddiagram).Theprimaryhierarchical
relationshipisbetweenaparentboxandthechilddiagramthatdetailsit.

24

Figure6.DecompositionStructure

25

Thefactthatachildboxisdetailed,andisthereforealsoaparentbox,isindicatedbythe
presenceofaDetailReferenceExpression(DRE). TheDREisashortcodewritten
belowthelowerrightcornerofthedetailed(parent)boxthatpointstoitschilddiagram.
TheDREshalltakeoneofthefollowingforms:
1.

Achronologicalcreationnumbercalleda"Cnumber"thatshalluniquely
identifyaparticularversionofachilddiagram.

2.

Apagenumberofthechilddiagraminthepublisheddocumentinwhich
themodelappears.

3.

The node number referencing the child diagram. If there are multiple
versionsofachilddiagram,aparticularversioncannotbespecified.

4.

Amodelnotenumberwhosetextspecifiestheconditionsforselectionofa
particularchildversion.

Figure7illustratestheuseofnodenumbersasDREs. Inthefigure,thepresenceof
DREsunderboxes1,2and3indicatesthattheyhavebeendetailedonthespecifiedchild
diagrams.

26

27

Figure7.DetailReferenceExpressionUse
3.3.1.4TextandGlossary
A diagram may have associated structured text, which is used to provide a concise
overviewofthediagram.Textshallbeusedtohighlightfeatures,flows,andinterbox
connectionstoclarifytheintentofitemsandpatternsconsideredtobeofsignificance.
Textshallnotbeusedmerelytodescribe,redundantly,themeaningofboxesandarrows.
Theglossaryshallbeusedtodefineacronymsandkeywordsandphrasesthathavebeen
usedinconjunctionwithdiagramgraphics.Theglossarydefineswordsinthemodelthat
mustconveyacommonunderstandinginordertocorrectlyinterpretthemodelcontent.
3.3.1.5ForExpositionOnlyDiagrams
For Exposition Only (FEO, pronounced feeoh) diagrams shall be used where an
additional level of supplementary knowledge is required to adequately understand
specificareasofamodel.Supplementarydetailingshouldbelimitedtowhatisneededto
achieve thestatedpurposeforaknowledgeable audience. AFEOdiagramneednot
complywithIDEF0syntaxrules.
3.3.2DiagramFeatures
3.3.2.1ArrowsasConstraints
ArrowsonanIDEF0diagramrepresentdataorobjectsasconstraints.Onlyatlowlevels
ofdetailcanarrowsrepresentfloworsequence,whenthemodeledsubjectissufficiently
detailedtotreatspecificchangesmadetospecificdataitemsorobjects.Connectingthe
outputofoneboxtotheinput,control,ormechanismofanotherboxshowsthatthe
functionmodeledbythelatterboxrequires,andthusisconstrainedby,thepresenceof
thecorrespondingoutput oftheformerbox. This typeofconstraintis illustrated in
Figure8. Thearrowsconnectingtoaboxrepresentallthedataandobjectsthatare
neededforthefunctiontobecompletelyperformed.

28

fr
Figure8.MeaningofConstraint
3.3.2.2ActivationsofaBox
Aboxmayperformvariouspartsofitsfunctionunderdifferentcircumstances,using
differentcombinationsofitsinputandcontrolsandproducingdifferentoutputs.These
differentperformancesarecalledthedifferentactivationsofthebox.

29

3.3.2.3ConcurrentOperation
Severalfunctionsinamodelmaybeperformedconcurrently,iftheneededconstraints
havebeensatisfied.AsillustratedinFigure9,anoutputofoneboxmayprovidesomeor
allofthedataandobjectsneededforactivationsofoneormoreotherboxes.
Whenanoutputofoneboxprovidessomeoralloftheinputs,controlsormechanisms
neededbyanotherbox,agivenactivationofthelatterboxmaydependonsequential
performance.However,differentactivationsofthesamebox(es),withpossiblydifferent
requirements,mayoperateconcurrently.

30

O
31

Figure9.ConcurrentOperation
3.3.2.4ArrowsasPipelines
Itisusefultothinkofhighlevelarrowsaspipelinesorconduits. Highlevel arrows
havegenerallabels,whilearrowsonlowerleveldiagramshavemorespecificlabels.If
anarrowsplits,formingtwoormorenewarrowsegments,eacharrowsegmentmayhave
amorespecificlabel,asshowninFigure10.

32

33

Figure10.ArrowPipelinewithForking

34

3.3.2.5BranchingArrows
Anarrowmaybranch(forkorjoin),indicatingthatthesamekindofdataorobjectmay
beneededorproducedbymorethanonefunction.Thebranchesmayrepresenteitherthe
samethingorportionsofthesamething. Sincelabelsspecifywhatarrowsegments
represent,labelsonbranchingarrowsegmentsprovideadetailingofthearrowcontent
justaslowerleveldiagramsprovidedetailingofparentboxes.
All orpartofthecontentsofanarrowmayfollowa branch. Aforkingarrowmay
denotethe"unbundling"ofmeaningsthathadbeencombinedunderamoregenerallabel.
The joining of two arrow segments may denote "bundling", i.e., the combining of
separatemeaningsintoamoregeneralcategory. Allcontentsareprovidedthroughall
branchesunlessotherwiseindicatedbyaspeciallabeloneacharrowsegment. These
conventionsareillustratedinFigure11.

35

36

Figure11.ArrowForkandJoinStructures
3.3.2.6InterBoxConnections
ExceptforthesingleboxA0contextdiagram,agraphicdiagramcontainsaminimumof
threeandamaximumofsixboxes.Boxesarenormallyorganizeddiagonallyfromthe
upperleftcornertothelowerright,i.e.,ina"staircase"configuration.
Anyoutputarrowmayprovidesomeoralloftheinput,control,ormechanismdataor
objectstoanyotherbox.Anoutputarrowmayprovidedataorobjectstoseveralboxes
viatheforkingmechanism,asshowninFigure12.

37

38

Figure12.ConnectionsBetweenBoxes
Ifaboxonadiagramisdetailedbyachilddiagram,eacharrowconnectedtotheparent
boxshallappearonthechilddiagram,unlessthearrowistunnelednexttoitsparentbox
(seeSection3.3.2.9).
Onadiagram,dataorobjectsmayberepresentedbyaninternalarrow,withbothends
(sourceanduse)connectedtoboxes,orbyaboundaryarrow,withonlyoneend(source
or use) connected. Internal arrows and boundary arrows are shown in Figure 13.
BoundaryarrowsarediscussedindetailinSections3.3.2.7and3.3.2.8.

39

40

Figure13.BoundaryandInternalArrows

41

3.3.2.7BoundaryArrows
Boundary arrows on an ordinary (noncontext) graphic diagram represent the inputs,
controls,outputs,ormechanismsofthediagram'sparentbox.Thesourceoruseofthese
boundaryarrowscanbefoundonlybyexaminingthe parentdiagram. Allboundary
arrowsonachilddiagram(exceptfortunneledarrows,Section3.3.2.9)shallcorrespond
tothearrowsthatconnecttoitsparentbox,asshowninFigure14.

42

43

Figure14.BoundaryArrowCorrespondence

3.3.2.8ICOMCodingofBoundaryArrows
ICOMcodesrelateboundaryarrowsonachilddiagramtoarrowsconnectedtoitsparent
box.Aspecificnotation,calledICOMcodes,specifiesthematchingconnections.The
letterI,C,OorMiswrittenneartheunconnectedendofeachboundaryarrowonthe
child diagram. This coding identifies the arrow as an Input, Control, Output or
Mechanismontheparentbox. Thisletterisfollowedbyanumbergivingtherelative
positionatwhichthearrowisshownconnectingtotheparentbox,numberingfromleftto
right ortopto bottom. Forexample, C3written onaboundary arrow onachild
diagramindicatesthatthisarrowcorrespondstothethirdcontrolarrow(fromtheleft)
enteringitsparentbox.
Thiscodingrelateseachchilddiagramtoitsownimmediateparentbox.Ifboxesona
childdiagramaredetailedonsubsequentchilddiagrams,newICOMcodesareassigned
oneachnewchilddiagram,relatingthatdiagram'sboundaryarrowstoarrowsonitsown
immediateparentbox.
Using the letternumbering matching scheme of ICOM coding, arrow roles (input,
control,mechanism)maydifferbetweenparentandchilddiagrams.Figure14showsthe
commoncasewheretherolesdomatch,e.g.,theinputtotheparentboxmatchesthe
inputonthechilddiagram.Asanexampleofchangingroles,acontrolarrowonaparent
boxmaybeeitheraninputoracontrolarrowforboxesonitschilddiagram.Likewise,a
controlforaparentboxmaybeaninputforoneormoreofitschildboxes.Figure15
showsexamplesofchangingarrowroles.

44

45

Figure15.ICOMCodesandChangingArrowRoles

46

3.3.2.9TunneledArrows
Atunneledarrowisusedtoprovideinformationataspecificlevelofdecompositionthat
isnotrequiredforunderstandingatsomeotherlevels.Anarrowcanbetunneledatany
chosenlevel.
Using the parentheses notation illustrated in Figure 16, tunneling an arrow where it
connectstoaboxsidemeansthatthedataorobjectsexpressedbythatarrowarenot
necessaryforunderstandingsubsequentlevel(s)ofdecomposition,andthusshallnotbe
shownonitschilddiagram.However,becausethisarrowdoescorrespondtooneonits
parentdiagram,itisgivenanICOMcode. Thiscodemaybeusedelsewhereinthe
model,e.g.,inareferenceexpressiononadiagramwherethearrowreappears,inorderto
identifythelocationoftheoriginaltunneling. Anarrowtunneledatitsconnectedend
maybeomittedfromoneormorelevelsofdecompositionandthenreappearonanother
level,inoneormoreplaces,tunneledattheunconnectedend.

47

48

Figure16.ArrowsTunneledatConnectedEnd
Tunneling an arrow at the unconnected end means that the data or objects are not
necessaryatthenexthigher(parent)levelandhenceshallnotbeshownconnectingtothe
parentbox.ThisisshowninFigure17.Becausethisarrowdoesnotcorrespondtoone
onitsparentdiagram,itdoesnothaveanICOMcode.Thearrowmayhaveanattached
modelnotecontainingthenodereferenceandICOMcodethatlocatesthe"otherend"of
thetunnel.ICOMcodingforthearrowresumesforanysubsequentchilddiagrams.
Figure18providesanexampleoftunneledarrowsonparentandchilddiagrams.

Figure17.ArrowsTunneledatUnconnectedEnd

49

50

Figure18.ExampleofTunneledArrows
3.3.2.10CallArrows
Acallarrowisaspecialcaseofmechanismarrow.Itsignifiesthatthecallerboxdoes
nothaveitsownchilddiagramtodetailit,butratherisdetailedentirelybyanotherbox
(anditsdescendants)inthesameoranothermodel.Multiplecallerboxesmaycallthe
samebox.
Thecallarrowislabeledwiththenodereferenceofthediagramcontainingthecalled
box,alongwiththecalledboxnumber.Acallerboxmaycallonlyoneboxinagiven
activation.However,dependingonconditionsspecifiedinamodelnoteattachedtoacall
arrow,thecallerboxmayselectoneofseveralpossiblecalledboxes.Inthiscase,the
callarrowlabelshallincludealistofthenodereferencesofallthepossiblecalledboxes.
Thearrowsofthecalledboxmaynotcorrespondexactlywiththoseofthecallerbox,
eitherinnumberorinmeaning.Inthesecases,modelnotesattachedtothecallarrows
shallspecifytherelationshipssothatthecorrectinterpretationmaybegiventotheshared
dataandobjects.
3.3.3DiagramSyntaxRules
1.

ContextdiagramsshallhavenodenumbersAn,wherenisgreaterthanor
equaltozero.

2.

ThemodelshallcontainaA0contextdiagram,whichcontainsonlyone
box.

3.

TheboxnumberofthesingleboxontheA0contextdiagramshallbe0.

4.

Anoncontextdiagramshallhaveatleastthreeboxesandnomorethan
sixboxes.

5.

Eachboxonanoncontextdiagramshallbenumberedinitslowerright
insidecorner,inorder(fromupperlefttolowerrightonthediagram)
from1toatmost6.

6.

Eachboxthathasbeendetailedshallhavethedetailreferenceexpression
(DRE,e.g.,nodenumber,Cnumber,orpagenumber)ofitschilddiagram
writtenbeneaththelowerrightcornerofthebox.

7.

Arrowsshallbedrawnashorizontalandverticalstraightlinesegments.
Diagonallinesegmentsshallnotbeused.

8.

Each box shall have a minimum of one control arrow and one output
arrow.
51

9.

Aboxshallhavezeroormoreinputarrows.

10.

Aboxshallhavezeroormorenoncallmechanismarrows.

11.

Aboxshallhave0or1callarrows.

12.

Controlfeedbacksshallbeshownasupandover.

52

53

Inputfeedbacksshallbeshownasdownandunder.

54

55

Mechanismfeedbacksshallbeshownasdownandunder.

56

57

13.

Theunconnectedendofa boundaryarrowshallhavetheproperICOM
codespecifyingitsconnectiontotheparentbox,orshallbetunneled.

14.

Openendedboundaryarrowsthatrepresentthesamedataorobjectsshall
beconnectedthroughaforktoshowalltheplacesaffected,unlessthis
resultsinanunreadablediagram.Multiplesourcesthatrepresentthesame
dataorobjectsshalljointoformasingleoutputboundaryarrow.

15.

Box names and arrow labels shall not consist solely of the following
words:function,activity,process,input,output,controlormechanism.

3.3.4DiagramReferenceExpressions
Referenceexpressionsusecodesthatareassignedtomodelfeaturessuchasdiagrams,
boxes,arrowsandnotes.Referenceexpressionsthencanbeusedinvariouscontextsto
referpreciselytoanyaspectofthemodel.
The basic unit of reference is the node number, which applies to the place where
functionaldecompositionismodeledbythedetailingofaparentboxonachilddiagram.
Allotherreferencecodesarebasedonnodenumbers.
3.3.4.1BoxNumbers
Eachboxonadiagramshallbenumberedinthelowerinsiderightcornerofthebox.This
numberingsystemisrequiredtouniquelyidentifytheboxeswithinadiagram,andto
generatenodenumbers.Itisalsousedtocrossreferencedescriptiveentriesinthetext
andglossarytotheboxesonadiagram.
TheboxnumberforthesingleboxontheA0contextdiagramshallbe0(zero).Thebox
numbersfortheboxesonallothergraphicdiagramsshallbe1,2,3,toatmost6,to
uniquely identify the three to six boxes on each such diagram. For boxes arranged
diagonally on the diagram from the top left corner to the bottom right corner, box
numbersareassignedinorder,startingattheupperleft.Ifoffdiagonalboxesarealso
used,thenumberingsequencestartswiththeondiagonalboxesandthencontinues,from
thelowerright,incounterclockwiseorder.
58

3.3.4.2NodeNumbers
Anodenumberisbasedonthepositionofaboxinthemodelhierarchy. Normally,a
nodenumberisformedbyappendingaboxnumbertothenodenumberofthediagram
onwhichitappears.Forexample,thenodenumberofbox2ondiagramA25isA252.
(AllIDEF0nodenumbersbeginwithacapital letter, suchas "A".) Whenaboxis
detailedbyachilddiagram,thenodenumberoftheparentboxisassignedasthediagram
nodenumber;thus,theparentboxanditschilddiagramhavethesamenodenumber.
Context diagrams and the toplevel child diagram are exceptions to the above node
numbering scheme. Every IDEF0 model has a toplevel context diagram, the A0
diagram. Thisdiagramcontainsasingle"topbox"whichistheuniqueparentofthe
entiremodeledsubjectandbearstheuniqueboxnumber0(zero)andnodenumberA0.
EveryIDEF0modelshallalsohaveatleastthree,butnomorethansix,childboxeson
theA0childdiagramthatdetailstheA0parenttopbox,thoseboxesbearingtheunique
nodenumbersA1,A2,A3,toatmostA6. Thus,thesequence[A0,A1, ...,A2,...,
A3,...]startsthenodenumberingforeachmodel.
Forexample,amodelmighthavethefollowingnodenumbers:
...
diagrams
A1
A0

Optional higherlevel context

Optionalcontextdiagram
Required toplevel context diagram
(containsA0topbox)

A0 Toplevelchilddiagram
A1,A2,...,A6
A11,A12,....,A16,....,A61,...,A66
A111,A112,...,A161,....,A611,...,A666
...

Childdiagrams
Childdiagrams
Childdiagrams
Lowerlevelchilddiagrams

Nodenumbersmayalsobeusedasdetailreferenceexpressionstoindicatethedetailing
ofaparentboxbyachilddiagram.Ifafunctionhasbeendecomposed,thenodenumber
ofthechilddiagramwhichdetaileditmaybewrittenbeneaththelowerrightcornerof
theparentbox.InFigure7,theDREs(inthiscase,nodenumbers)forboxes1,2and3
indicatethattheyhavebeendetailedandidentifythechilddiagrams.
3.3.4.2.1NodeIndex
Thenodeindexisapresentationofnodeinformationinan"outline"format.Allnode
numbers,alongwitheitherdiagramtitlesorboxnames,shallbepresentedinanindented
form that exhibits the nested hierarchic structure of the model. This places related
59

diagramstogetherintheorderusedinanordinaryTableofContents,asisillustratedin
Figure19.

60

61

Figure19.TypicalNodeIndex
3.3.4.2.2NodeTree
The developed IDEF0 model with its structured decomposition provides the basis to
sketchthefulldecompositioninnodetreefashiononasinglelargediagram.Theuseofa
nodetreeisoptional.Thecontentofthenodetreeshallbeidenticaltothatofthenode
indexoranysuitableportionofinterest.
Thereisnostandardformatfortheactualdisplayofthenodeinformation,exceptthatthe
hierarchyshallbeshowngraphicallyasatreerootedatachosennode(e.g.,A0forthe
wholemodel).Figure20providesanillustration.

62

63

Figure20.TypicalNodeTree
3.3.4.3NodeReferences
Each diagram in a model has a node reference, which uniquely identifies it and its
positioninthemodelhierarchy. Thenodereferenceiscomposedoftheabbreviated
model name (see Section 3.4.5) and the diagram node number (see Section 3.3.4.2),
separatedbyaslash(/). Forexample,amodelnamedQualityAssuranceOperations
mightbeabbreviatedasQA,andanodereferencemightthenbeQA/A312.References
toadiagraminthesamemodelmayomitthemodelnameabbreviation,usingonlythe
diagramnodenumber.
A node reference may also have a suffix, e.g., F (for FEO), T (for text), or G (for
glossary), and a page number. For example, a node reference for a FEO might be
QA/A321F1(seeSection3.4.4).
3.3.4.4ModelNotes

64

Modelnotesareoptional.Theyaredenotedbyaninteger"n"insideasmallsquarebox

65

66

Foragivendiagram,thenotenumbersshallformaconsecutivesequence,startingat1.Ve
Modelnotesprovideinformationthatisrelevantto(andanintegralpartof)adiagram's
message,butthatdoesnotconvenientlyfitintotheboxandarrowsyntax.Ifthetextof
thenoteistoapplytoseveralplacesorseveralfeaturesofthediagram,theboxednote
number(withouttext)maybecopiedandmaybeattachedbyanIDEF0squiggletoeach
point of application, but only on the single diagram on which the model note's text
appears.

67

3.3.4.5ReferenceNotation
Astandardnotationisusedinwritingtextandnotestorefertodiagramsandspecific
partsofdiagrams.Referencesarebasedonboxnumbers,nodenumbers,ICOMcodes,
andnotenumbers.Thefollowingtableprovidesexamplesofreferencenotations.

REFERENCENOTATION

MEANING

2I1

Box2Input1

O2

TheboundaryarrowwithICOMcodeO2

2O2to3C1or2o2to3c1

Thearrowfrom2O2to3C1(TheI,O,CorM
maybeuppercaseorlowercase.)

I2to2I3to2O2to(3C1and4C2)

FromtheboundaryarrowwithICOMcodeI2
toBox2Input3,throughtheactivationofBox
2thatyieldsOutput2,totheavailability(viaa
forkingbranch)ofthatoutputasControl1on
Box3andControl2onBox4.

A21.3C2

On diagram A21 in this model, see Box 3

Control2. Anembeddedperiod means"look
specificallyat".

A42.

OndiagramA42,seemodelnote3.

68

69

A42.|3|

Same as above, using optional notation

(verticalpipessurroundingmodelnoteinstead
ofboxednote).

A42.3

OndiagramA42inthismodel,seeBox3.

MFG/A42.1

On diagram A42 of the model abbreviated

MFG,seeBox1.

70

3.4Models
3.4.1IDEF0ModelDescription
OneofthemostimportantfeaturesofIDEF0asamodelingconceptisthatitgradually
introducesgreaterandgreaterlevelsofdetailthroughthediagramstructurecomprising
themodel.Inthisway,communicationisenhancedbyprovidingthereaderwithawell
boundedtopicwithamanageableamountofdetailtolearnfromeachdiagram.
AnIDEF0modelstartsbypresentingthewholesubjectasasingleunitaboxwith
externalarrowboundaryconditionsconnectingittofunctionsandresourcesoutsidethe
subject. Thesingleboxiscalledthe"topbox"ofthemodel. (Thistopboxhasnode
numberA0.) SincethesingletopboxofanIDEF0modelrepresentsthesubjectasa
whole,thedescriptivenameintheboxisgeneral.Thesameistrueoftheexternalarrows
ofthemodel,sincetheyrepresentthecompletesetofexternalboundaryconditionsofthe
subjectasawhole,includingaccesstomechanismsupportthatsuppliesadditionalmeans
ofperformance.
3.4.2ContextDiagrams
ThediagraminwhichtheA0topboxappearsrepresentsthecontextofthemodelandis
called a context diagram. The minimum context for a model is the special context
diagramwiththenodenumberA0.TheA0contextdiagramhasonlythesinglenamed
A0topbox,withitslabeledexternalarrows,andalsotextualdefinitionsoftheViewpoint
and Purpose of the model. (The A0 diagram has no ICOM codes or tunneling at
unconnectedarrowends.)
Sometimes, however, in order to provide a more complete exposition of the
environmental context of the model, an optional A1 context diagram (having the
appearanceofanordinary,noncontext,diagram)isalsopresented.IntheA1context
diagram,theA0boxtakestheplaceofoneofthethreetosixnumberedboxes(theother
boxesretainingtheirexpectedboxnumber),sotheeffectistoprovideacompleteparent
diagram(withthreetosixboxes)forthemodel'stoptheA1throughA6nodesstill
beingthefirstgenerationchildren.InthecasewhereanA1contextdiagramisused,an
A0contextdiagramisstillpresented.ThisA0diagramstillhasonlythesinglenamed
A0topbox,withitslabeledexternalarrowsandalsotextualdefinitionsoftheViewpoint
andPurposeofthemodel.
Contextdiagramsarediagramsthathavenodenumbersoftheform"An"(withaminus
signincluded),wherenisgreaterthanorequaltozero.Ordinary,noncontextdiagrams
lacktheminussignintheirnodenumbers.Theboxnumberofthetopboxofthemodel
(representingthewholeofthemodeledsubject)alwaysis0.Boxnumber0shallappear
ontherequiredA0contextdiagramofthemodel,andshallalsoappearontheoptional
A1contextdiagram(ifany)whereittakestheplaceofoneoftheboxes(1toatmost6)
ofthatA1(modelwide)parentdiagram.ThusA0alwaysisthe(shared)nodenumber
71

oftheparentboxandchilddiagramforthewholemodelandalwaysisdetailedbyboxes
withnodenumbersA1,A2,A3,toatmostA6.
Withonlyonebox,A0isapropercontextdiagrambutisnota(proper)parentdiagram.
Properdiagramshavethreetosixboxes.Theparentalcontextisthatwhichprovidesor
namesthecontextforadiagramintheplaceofaproperparentdiagram.Theparental
contextoftheA0diagramistherequiredA0,ifthereisnoA1contextdiagram.Ifthere
isanA1contextdiagram,A1istheproperparentoftheA0diagram. Theparental
contextoftheA0contextdiagramalwaysis"TOP".

72

3.4.3HighLevelContextDiagrams
HighlevelcontextdiagramshavenodenumbersoftheformAn,forngreaterthanone.
ThusA1isacontextdiagram,isaproperparent(ofA0),butisnothighlevel.Fora
given model presentation, the highestlevel context diagram (largest n) has parental
context"NONE",unlessthehighestlevelcontextdiagramisA0.
Eachhighlevelcontextdiagram,An,syntacticallyisanordinarydetaildiagramexcept
thatoneofitsthreetosixboxeshasitsboxnumberreplacedby"minussignn1",so
that,forA1,thatboxistheA0topboxofthemodel,andthemodelasawhole(thatA0
boxitself,theparentofthechildren)appearstohaveparentA1,grandparentA2,etc.
Byprovidingamorecompletedescriptionofthemodel'senvironmentalcontext(not,
however,intendedtobedefinitiveinallrespects,butonly"typical"),contextmodeling
(characterizedbynegativenodenumbering)providesmoreconstrainingspecificationson
theboundaryconditionsoftheA0diagramofthemodel.
Contextmodelingproceedsjustasordinarydetailmodeling,theonlydifferencebeingthe
negativenumbering(andthenondefinitive,butnormativeinterpretation)thatpreserves
A0asthe"origin"ofthenodenumberbasedcoordinatesystemforallmodelreferences.
Allthenegativenodenumbermodelingmerelyprovidesmoreandmoredetailsaboutthe
sourcesandusesoftheexternalboundaryconditions.Thatdetailmaynotpreciselybe
matchedbyany particularspecificenvironment,completely. Thesecontextdiagrams
describethe"typical"context.
Figure21providesanillustrationinnodetreeformtoshowhowrichhighlevelcontext
mightappear.

73

74

Figure21.NegativeNodeNumberedContext

3.4.4FEOs,TextandGlossary
ThenodenumberingschemeprovidesthebasisforcoordinatingFEOs,text,andglossary
terms. Duringdevelopment itis important thateachnew element ofinformation be
associatedwiththenodethatbroughtitintoconsideration.
Foreachform(FEOs,text,andglossary),thenodenumberingextensionnotationconsists
ofasingleletterappendedtotheassociatednodenumber.Forexample,nodenumbers
forFEOsshallcontainanFforFEO(e.g.,A312F).
SomeIDEF0usersrecordglossarydefinitionsonIDEF0diagramforms,thoughtheuse
ofthisformforglossariesisnotrequired.Inthiscase,aglossarypageshalldefinethe
keywords,phrasesandacronymsusedwithaparticular,associatedIDEF0node.The
nodenumbersforsuchglossarypagesshallcontaina"G"forglossary(e.g.,A312G).
Likewise,someIDEF0usersrecordtheirtextualcommentsonIDEF0diagramforms,
thoughtheuseofthisformfortextisnotrequired.Inthiscase,atextpageshallprovide
thetextcommentsforaparticular,associatedIDEF0node.Thenodenumbersforsuch
textpagesshallcontaina"T"fortext(e.g.,A312T).
IfthereismorethanoneFEO,glossaryortextpageassociatedwithagivenIDEF0node,
thepagesshouldbedesignatedwithanadditionalnumbertouniquelyidentifyeach(e.g.,
A312F1,A312F2,...A312G1,A312G2,...,A312T1,A312T2,...).
3.4.5ModelName
Eachmodelhasaunique,descriptivenamethatdistinguishesitfromothermodelswith
whichitmaybeassociated.Thismodelnameisnormallyabbreviated(uniquely)foruse
innodereferences. Forexample,amodelnamedManufacturing Operations maybe
abbreviatedMFG.SeeSection3.3.4.3foradiscussionofnodereferences.
3.4.6PresentationRules
1.

Whenthereistext,itshallaccompanytheassociatedgraphicdiagram.

2.

Innonpublicationmodels,theglossaryassociatedwithaspecificgraphic
diagramshallaccompanythediagramandshalldefineonlythekeywords,
phrasesandacronymsusedwiththeparticularnode.

3.

In publication models, a glossary section shall define the key words,

phrasesandacronymsinalphabeticalorderfortheentiremodel.
75

4.

Whenatableofcontentsisprovidedforamodel,itshallbepresentedasa
nodetreeornodeindex,andshallcontainnodenumbers,diagramtitles
andboxnames.

76

ANNEXAIDEF0CONCEPTS
A.1Background
ThedesireoftheU.S.AirForcetoreducecostsandleadtimesbyassistingtheaerospace
industryinitsmodernizationeffortsisevidencedinitsmanyTechMod(Technology
Modernization)programs.Asimilargoal,butusinganindustrywidetargetratherthan
individual companies, was established under the ICAM (Integrated Computer Aided
Manufacturing)Program.InICAM,thegoalwastodevelopgenericsubsystemswhich
couldbeusedbyalargenumberofcompaniestoprovideasignificantupgradetothe
industryasawhole.Thesesubsystemsprovidesupportforcommonfunctionssuchas
managementofinformation,shopfloorschedulingandmaterialshandling.
Thisambitiousgoalneededacommonbaselinecommunicationvehiclearoundwhich
toplan,developandimplementthesubsystemsintheindividualaerospacecompanies.
ThebaselinewascalledtheArchitectureofManufacturing,sinceitwastoprovidean
industrywide architecture showing how industry works today and around which
genericsubsystemscouldbeplanned,developedandimplemented.
Todevelopthearchitecture,alanguagewasneededinwhichtoexpressanddocument
currentaerospaceindustryoperations. AttheoutsetofICAM,theAirForceissueda
Request for Proposal to build the architecture. An activity modeling technique was
specifiedastheexpressivelanguage(whereanactivitywasdefinedasamanufacturing
celloroperationalunit). Tobesuccessful,thelanguagehadtosatisfythefollowing
criteria:

Sincethearchitecturewastodepictmanufacturing,ithadtobeableto
expressmanufacturingoperationsinanaturalandstraightforwardway.

Since the subject was so vast and complex, it had to be concise and
provideastraightforwardmeansoflocatingdetailsofinteresteasilyand
quickly.

Since it was to be used by a wide audience, it had to be able to

communicatetoawidevarietyofaerospaceindustrypersonnelaswellas
toAirForceICAMProgramOfficepersonnel.

Since it was to serve as a baseline for generic subsystem planning,

development and implementation, it had to permit sufficient rigor and
precisiontoinsureorderlyandcorrectresults.

Sincethebaselinewastobedevelopedthroughthecooperativeeffortofa
largesegmentoftheaerospaceindustry,ithadtoincludeamethodology
(rulesandprocedures)foritsusethatwouldpermitmanydiversegroups
77

todeveloparchitecturepiecesandthatwouldpermitwidespreadreview,
critiqueandapproval.

Sincethebaselinewastorepresenttheentireaerospaceindustryrather
thananyonecompanyorindustrysegment,thetechniquehadtoincludea
meansofseparatingorganizationfromfunction;thatis,acommon
agreement could not be achieved unless the individual companies
organizational differences were separated out and only the common
functionalthreadwascaptured.

TheSADT(StructuredAnalysisandDesignTechnique)originallydevelopedin1972
byDouglasT.Ross,ofSofTech,wasselectedastheTheArchitectureMethodforuse
in the Air Force Computer Aided Manufacturing (AFCAM) Project. The activity
modeling technique was further developed and used in the followon ICAM Part I
Program.ThemajorsubsetofthistechniqueusedbytheICAMPartIIProgramOffice
waslaterrenamedanddocumentedasIDEF0.

A.2IDEF0Concepts
TheoriginalIDEF0methodologyincorporatedbasicconceptswhichaddresseachofthe
needslistedabove.ThesebasicIDEF0conceptsare:
1.

ActivityModelingGraphicRepresentation.Theboxandarrowgraphicsofan
IDEF0diagramshowthemanufacturingoperationasthebox,andtheinterfaces
to/fromtheoperationasthearrowsentering/leavingthebox.Inordertobeable
to express reallife manufacturing operations, boxes may be interpreted as
operatingwithotherboxes,withtheinterfacearrowsprovidingconstraintsasto
whenandhowoperationsaretriggeredandcontrolled.

2.

Conciseness.Thedocumentationofamanufacturingarchitecturemustbeconcise
topermitencompassingthesubjectmatter.Thelinear,verbosecharacteristicof
ordinarylanguagetextisclearlyinsufficient.Thetwodimensionalformprovided
byablueprintlikelanguagehasthedesiredconcisenesswithoutlosingtheability
toexpressrelationshipssuchasinterfaces,feedbackanderrorpaths.

3.

Communication. There are several IDEF0 concepts which are designed to

enhancecommunications:

Diagramsbaseduponverysimpleboxandarrowgraphics.
Englishtexttospecifybox(function)andarrow(dataorobjects)meanings.
Gradualexpositionofdetail,featuringahierarchywithmajorfunctionsat
the top and successive levels of subfunctions revealing wellbounded
detailbreakout.
A node index for locating details within the hierarchic structure of
diagrams.
78

4.

Limitation of detail on each successive diagram to not more than six

subfunctionsforeaseofreadercomprehension.
Diagramssupportedwithtextandglossarytoincreasetheprecisenessof
thegraphicrepresentation.

RigorandPrecision.TherulesofIDEF0enforcesufficientrigorandprecisionto
satisfyICAMarchitectureneedswithoutoverlyconstrainingtheanalyst.IDEF0
rulesinclude:

Detailexpositioncontrolateachlevel(36boxrule).
Boundedcontext(noomissionsoradditionaloutofscopedetail).
Syntaxrulesforgraphics(boxesandarrows).
Uniquenessofnamesandlabelsonadiagram.
Diagramconnectivity(DetailReferenceExpressions[DRE]).
Data/objectconnectivity(ICOMcodesandtunneledarrows).
Inputvs.controlseparation(rulefordeterminingroleofdataorobjects).
Minimumcontroloffunction(allfunctionsrequireatleastonecontrol).
Arrowbranch(forkorjoin)constraint(labelsforarrowsegments).
Arrowlabelrequirements(minimumlabelingrules).
Purpose and viewpoint (all models shall have a purpose and viewpoint
statement).

5.

Methodology. Stepbystepproceduresareprovidedformodeling,reviewand
interviewtasks.

6.

Organization vs. Function. The separation of organization from function is

includedinthepurposeofthemodelandcarriedoutbytheselectionoffunctions
and arrow labels during model development. Continual review during model
developmentensuresthatorganizationalviewpointsareavoided.

A.3DiscussionofIndividualIDEF0Concepts
Intheremainingsubsectionsdescriptionsofsomeofthebasicconceptsareelaboratedto
clarifythemandshowtheirutility.
A.3.1ActivityModelingGraphics
TheIDEF0methodologymaybeusedtomodelawidevarietyofautomatedandnon
automatedsystemsorsubjectareas,includinganycombinationofhardware,software,
machines,processesorpeople.FornewsystemsIDEF0maybeusedfirsttodefinethe
requirementsandspecifythefunctions,andthentodesignanimplementationthatmeets
therequirementsandperformsthefunctions.Forexistingsystems,IDEF0canbeusedto
analyze thefunctions thesystemperformsandtorecordthemechanisms (means)by
whichthesearedone.
79

The result of applying IDEF0 is a model. A model consists of diagrams, text and
glossary,crossreferencedtoeachother.Diagramsarethemajorcomponentsofamodel.
Allfunctions andinterfaces arerepresentedasboxes(functions)andarrows(dataor
objectinterfaces)ondiagrams.
The position at which the arrow attaches to a box conveys the specific role of the
interface.Thecontrolsenterthetopofthebox.Theinputs,thedataorobjectsactedupon
bytheoperation,entertheboxfromtheleft. Theoutputsoftheoperationleavethe
righthand side of the box. Mechanism arrows that provide supporting means for
performingthefunctionjoin(pointupto)thebottomofthebox.Callarrows,atypeof
mechanism arrow which enables the sharing of detail between models or between
portionsofthesamemodel,connecttothebottomoftheboxandpointdownward.These
arrowpositionsareillustratedinFigureA1.

80

81

FigureA1.FunctionBoxandData/ObjectsArrows
Theseboxandarrowmeaningsareusedtorelateseveralsubfunctionsonadiagram
comprisingamoregeneralfunction.Thisdiagramisaconstraintdiagramwhichshows
the specific interfaces which constrain each subfunction, as well as the sources and
targetsoftheinterfaceconstraints(FigureA2).

82

83

FigureA2.ConstraintDiagrams
InFigureA2,FunctionBisconstrainedbyoneinputandtwocontrols,andproducesa
singleoutput,whichconstrainsFunctionC.
Here,thetermconstrainsmeansthatafunctionusesthedataorobjectsshownentering
thebox,andtherefore,isconstrainedfromoperatingbytheinterface;thefunctioncannot
act until the contents oftheinterface arrow areprovided, andthe wayinwhichthe
functionoperatesdependsuponthedetails(value,number,etc.)ofthecontentsofthe
interfacearrow.
A.3.2CommunicationbyGradualExpositionofDetail
OneofthemostimportantfeaturesofIDEF0isthatitgraduallyintroducesgreaterand
greaterlevelsofdetailthroughthediagramstructurecomprisingthemodel.Inthisway,
communicationisenhancedbyprovidingthereaderwithawellboundedtopicwitha
manageableamountofnewinformationtolearnfromeachdiagram.
ThestructureofanIDEF0modelisshowninFigureA3.Here,aseriesoffourdiagrams
isshownwitheachdiagram'srelationtotheothers.
AnIDEF0modelstartsbyrepresentingthewholesystemasasingleunitaboxwith
arrowinterfaces tofunctionsoutsidethesystem. Sincethesingleboxrepresentsthe
systemorsubjectareaasawhole,thedescriptivenamewrittenintheboxisgeneral.The
sameistrueoftheinterfacearrowssincetheyalsorepresentthecompletesetofexternal
interfaces to the system as a whole. The diagram with the single box is called the
contextdiagram,andshalldefineintexttheviewpointandpurposeofthemodel.

84

FigureA3.IDEF0ModelStructure

85

Theboxthatrepresentsthesystemasasinglemoduleisthendetailedonanotherdiagram
withboxesconnectedbyinterfacearrows.Theseboxesrepresentmajorsubfunctionsof
thesingleparentfunction.Thisdecompositionrevealsacompletesetofsubfunctions,
eachrepresentedasaboxwhoseboundariesaredefinedbytheinterfacearrows.Eachof
thesesubfunctionsmaybesimilarlydecomposedtoexposeevenmoredetail.InIDEF0,
weusethefollowingterminology:functionsaredecomposed;theboxesthatrepresent
functionsaredetailed.
Abox,ifdetailed,isalwaysdetailedonachilddiagramintonofewerthanthreeboxes,
butnomorethansixboxes. Theupperlimitofsixforcestheuseofahierarchyto
describe complex subjects. The lower limit of three insures that enough detail is
introducedtomakethedecomposition(detailing)ofinterest.
Eachdiagraminamodelisshowninpreciserelationshiptootherdiagramsbymeansof
interconnecting arrows. When a function is decomposed into subfunctions, the
interfaces between the subfunctions are shown as arrows. The name of each sub
functionboxplusitslabeledinterfacesdefineaboundedcontextforthatsubfunction.
Inallcases,everysubfunctionisrestrictedtocontainonlythoseelementsthatliewithin
thescopeofitsparentfunction.Subfunctionsarediscreteanddonotoverlap.Further,
thecollectionofsubfunctionscannotomitanyelements.Thus,asalreadyindicated,the
parentboxanditsinterfacesprovideacontextforitschilddiagram.Exceptfortunneled
arrows,nothingmaybeaddedorremovedfromthispreciseboundary.
A.3.3DisciplinedTeamwork
TheIDEF0methodologyincludesproceduresfordevelopingandcritiquingmodelsbya
large group of people, as well as integrating support subsystems into an IDEF0
Architecture.Additionalsupportingprocedures,suchaslibrarianrulesandprocedures,
andreviewcycle(seeAnnexC)proceduresarealsoincludedintheIDEF0methodology.
(Itshouldbenotedthatsomeoftheserulesandprocedures,suchastheKitCycleor
ReaderAuthorCyclecritiqueprocedures,arealsousedwithotherIDEFtechniques.)
The creation of an IDEF0 model is the most basic of these disciplined teamwork
procedures. Thecreationofamodelisadynamicprocesswhichusuallyrequiresthe
participation of more than one person. Throughout a project, authors create initial
diagrams which are distributed to project members for review and comment. The
disciplinerequiresthateachpersonexpectedtomakecommentsaboutadiagramshall
maketheminwritingandsubmitthemtotheauthorofthediagram.Theauthorreplies,
alsoinwriting.Thiscyclecontinuesuntilthediagrams,andeventuallytheentiremodel,
areofficiallyaccepted.
IDEF includes procedures for retaining written records of all decisions and alternate
approaches astheyunfoldduringtheproject. Copiesofthediagrams createdbyan
authorarecritiquedbyknowledgeablereaderswhodocumentsuggestionsdirectlyonto
thecopies.Authorsrespondtoeachcommentinwritingonthesamecopy.Suggestions
86

are accepted or rejected in writing along with the reasoning used. As changes and
correctionsaremade,outdatedversionsofdiagramsareretainedintheprojectfiles.
Thediagramsarechangedtoreflectcorrectionsandcomments.Moredetailisaddedto
themodelbythecreationofmorediagramswhichalsoarereviewedandchanged.The
finalmodelrepresentsanagreementonarepresentationofthesystemorsubjectarea
fromagivenviewpointandforagivenpurpose.Thisrepresentationcanbeeasilyread
byothersoutsidetheinitialproject,usedforpresentingthesystemdefinitioninshort
standup briefings or in walkthroughs, and for organizing new projects to work on
systemchanges.

87

ANNEX B CREATING AND INTERPRETING IDEF0

DIAGRAMS
B.1ReadingIDEF0Diagrams
Amodelismadeupofacollectionofdiagramsandassociatedmaterialsarrangedina
hierarchicmanner. Anodeindex(ortableofcontents)shallbeprovided. Placingthe
diagramsinhierarchicalordergivesanoverallviewofthemodelandallowsaccessto
anyportion.
Readingisdonetopdown,consideringeachdiagramasacontextboundedbyitsparent
box. Afterthetopleveldiagramsareread,firstleveldiagramsareread,thensecond
leveldiagramsareread,etc.Ifspecificdetailsaboutamodelareneeded,thenodeindex
isusedtodescendthroughthelevelstotherequireddiagram.
When published, a model is bound in pagepair format and node index order.
Pagepairformatmeansthateachdiagramandtheentiretextassociatedwithitappear
onapairoffacingpages.(FigureB1.)

88

89

FigureB1.PagePairFormat
Nodeindexordermeansthatallchilddiagramsrelatingtooneboxonadiagramare
presentedbeforethechildrenofthenextbox.Thisplacesrelateddiagramstogetherin
thesameorderusedinanordinarytableofcontents.(FigureB2.)

90


91

FigureB2.NodeIndexShowingDiagramOrder
B.1.1ApproachingaModel
Modelsprovideanoverviewofthewholesystemorsubjectareaaswellasdetailsofa
particularsubject.Toreadamodelforitsoverview,usetheindextofindallhighlevel
diagrams.(FigureB3.)

92


93

FigureB3.NodeIndexShowingOverviewDiagrams
Toreadamodelfordetail,usetheindextofindalldiagramsdetailingthesubjectof
interest.(FigureB4.)

94


95

FigureB4.NodeIndexShowingSpecificDetailedDiagram
Furtherdetailinginamodelmaybetracedbyreferringtothedetailreferenceexpression
(DRE)justbelowtheboxnumber.Thisindicatesthenodenumber,Cnumberorpage
numberofthechilddiagramthatdetailsthebox.Intheexamplebelow,detailsforbox3
ondiagramA24maybefoundonadiagramwithnodenumberA243.IfnoDRE
appears,theboxhasnotyetbeendetailed.

96

97

Detailsmaybesharedwithinamodelorbetweendifferentmodels.Inbothcases,acall
arrow(downwardpointing)indicateswheretheshareddetailingappearsviaareference
expressionthatmayincludeaunique,abbreviatedmodelmane.Intheexamplebelow,
box4isdetailedbydiagramA4inmodelMQ.Inthisexample,thereferenceexpression
isadiagramnodereference.

B.1.2DiagramReadingSteps
Thepreciseinformationaboutasystemisinthediagramsthemselves. Thefollowing
readingsequenceisrecommended:
1.

Scantheboxesofthediagramtogainanimpressionofwhatisbeing
described.

2.

Referbacktotheparentdiagramandnotethearrowconnectionstothe
parentbox.Trytoidentifyamostimportantinput,controlandoutput.

3.

Considerthearrowsofthecurrentdiagram.Trytodetermineifthereisa
mainpathlinkingthemostimportant inputorcontrolandthe"most
important"output.

4.

Mentallywalkthroughthediagram,fromupperlefttolowerright,using
themainpathasaguide.Notehowotherarrowsinteractwitheachbox.
Determineiftherearesecondarypaths.Checkthestorybeingtoldbythe
diagrambyconsideringhowfamiliarsituationsarehandled.

5.

ChecktoseeifarelatedFEOdiagramexists.

6.

Finally,readthetextandglossary,ifprovided.
98

Thissequenceensuresthatthemajorfeaturesofeachdiagramreceiveattention.Thetext
willcallattentiontoanythingthattheauthorwishestoemphasize. Theglossarywill
definetheauthor'sinterpretationoftheterminologyused.
Eachdiagramhasacentraltheme,runningfromthemostimportantincomingboundary
arrowtothemostimportantoutgoingboundaryarrow.Thismainpaththroughtheboxes
andarrowsoutlinestheprimaryfunctionofthediagram.(FigureB5.)Otherpartsofthe
diagramrepresentqualifyingoralternativeconditionswhicharesecondarytothemain
path.

99

100

FigureB5.ExampleofMainPath
Thesystemsoperationcanbementallyenvisionedbypursuingthemainpath.Specific
kindsofdatainputs,thehandlingoferrorsandpossiblealternativeoutputslenddetailto
thestory.Thiswalkthroughenhancesunderstandingofthediagrams.
B.1.3SemanticsofBoxesandArrows
Thefundamentalnotionwhichmustguidetheinterpretationofanydiagramorsetof
diagramsis:Onlythatwhichisexplicitlystatedisnecessarilyimplied.Thisderivesfrom
theverynatureofconstraintdiagrams. Unspecifiedconstraintsmustnotbeassumed;
necessaryconstraintsmustbeexplicit. Thecorollaryisthat:Anyfurtherdetailingnot
explicitlyprohibitedisimplicitlyallowed.

101

102

FigureB6.ExampleofConstraint

AnassumptioncanbemadeusingFigureB6thatthetemperatureismeasuredoften
enough and the tolerances are changed when appropriate and the temperature is
monitoredagainstthetolerancesoftenenoughthatthedangersignalwillbeproduced
soonenough.Noneoftheseintuitiveunderstandingswouldconflictwithsubsequent
detailingwhichshowedthat:
a.

thetemperaturewasmeasuredbyperiodicsampling,or

b.

currenttoleranceswererequestedonlywhenthetemperatureincreasedby
somefixedamount,or

c.

aseriesoftemperaturevaluesproducedbybox1wasstoredbybox2
which examined the pattern of change to determine if the pattern was
withinthetolerances,etc.

Thegraphicnotationsofadiagramare,bythemselves,abstract.However,theydomake
importantfundamentaldistinctions. Theirabstractnatureshouldnotdetractfromthe
intendedbreadthofpossibleinterpretationsthatarepermitted.
B.1.3.1ConstraintsOmitHowandWhen
Eitherofthetworepresentations:

103

104

saysthat:theactivitya2isdependentondwhichiscreatedormodifiedbytheactivity
a1.
Eachrepresentationdefinesaconstraintrelationshipbetweenthetwoboxes.Allthatis
explicitly stated by the intermediate arrow for either representation is expressed as
follows:someactivationofbox2requiressomethingcalleddthatisproducedbysome
activationofbox1.
Frequently,diagramsimplystronglythattwoormoreboxesmayneedthecontentsofan
arrow. ThemeaningoftheboxesandarrowsshowninFigureB7isthatsomething
producedbybox1isneededbybox2andbybox3.Itmaybethatanactivationofthe
arrowssource(box1)mustprecedeeveryactivationofitsdestination(box2orbox
3). Itmaybethatoneactivationofthesourceissufficientforeveryactivationofany
destination. Withoutadditionalinformation,theboxesandarrowsalonepermiteither
interpretation.

105

106

FigureB7.Twoboxesusingthecontentsofthesamearrow
B.1.3.2MultipleInputs,ControlsandOutputs
Thebasicinterpretationoftheboxshownbelow(FigureB8)is:Inordertoproduceany
subsetoftheoutputs[O1,O2,O3],anysubsetoftheentries[I1,I2,I3,C1,C2,C3,C4,
M1,M2,M3]mayberequired.Intheabsenceoffurtherdetailingitcannotbeassumed
that:
a.anyoutputcanbeproducedwithoutallentriespresent,or
b.anyoutputrequiresallentriesforitsproduction.

107

FigureB8.IllustrationofICOMcoding
Thepartialdetailingofthepreviousbox(showninFigureB9,asitmightappearina
FEOdiagram)indicatesthatI3,C2,C3andC4arenotrequiredforproducingO1.Figure
B9illustratesthepointsthat:
a.

someformoffurtherdetailingwillspecifytheexactrelationshipofinputs
andcontrolstooutputs;

b.

untilthatdetailingisprovided,limitingassumptionsaboutrelationships
insideeachboxshouldnotbemade;

c.

readingofadiagramshouldconcentrateonthearrows,whichareexplicit,
ratherthanonboxnames,whichareonlyimplicit.

108

109

FigureB9.FEOrepresentingdetailingofmultipleICOMs
B.2Author'sGuidetoCreatingIDEF0Diagrams
WhencreatinganyIDEF0diagram,therequirementstobesatisfiedarethat:
a.

itspurposeandviewpointshallmatchthestatedpurposeandviewpointof
theoverallmodel;

b.

its boundary arrows shall correspond to the arrows that connect to its
parentbox;

c.

itscontentshallbeexactlyeverythinginitsparentbox.

B.2.1BasicStepsofAuthoring
Thestepbystepdisciplineofauthoringmakesitpossibletocreatediagramsthatform
usefulandcoherentmodels.Thedisciplinetofollowis:
a.

Boundthesubjectmattermorepreciselythanthenameofthefunctionbox
suggests.Thisisdonewithalistofdataandobjectsactedonorprocessed
bythefunction.

b.

Studytheboundedsetofsubjectmatterandformpossiblesubfunctions
ofthetotalfunction.

c.

Lookfornaturalpatternsofconnectionofthosesubfunctions.

d.

Splitandclustersubfunctionstomakesuitableboxes.

e.

Drawafinalversionofthediagramwithcarefulattentiontolayoutand
clarity.

110

B.2.1.1SelectingaContext,ViewpointandPurpose
Beforebeginninganymodel,itisimportanttodeterminethemodelsorientation.This
includesthecontext,viewpointandpurpose. Theseconceptsguideandconstrainthe
creationofamodel. Whiletheymayberefinedasauthoringproceeds,theymustbe
consistentthroughoutamodelifitsorientationistoremainclearandundistorted.
Thecontextestablishesthesubjectofthemodelaspartofalargerwhole. Itcreatesa
boundarywiththeenvironmentbydescribingexternalinterfaces.Thecontextdiagram
establishesthecontextforthemodel.

Theviewpointdetermineswhatcanbeseenwithinthecontext,andfromwhatslant
orperspective. Dependingonthepurpose,differentviewpointsmaybeadoptedthat
emphasizedifferentaspectsofthesubject.Thereisonlyoneviewpointpermodel.
Thepurposeestablishestheintentofthemodelorthegoalofcommunicationthatit
serves.Purposeembodiesthereasonwhythemodeliscreated(functionalspecification,
implementationdesign,customeroperations,etc.).
Thestartingpointforeveryanalysisistoboundthecontext.Decidewhatthefocusis
beforethetopmostboxis created. Bewareofdrifting outofthis carefullyselected
startingdomain.Everystepshouldbecheckedagainstthestartingpurpose.Thingsthat
dontfitmaybenotedforlatermodelingoftherelevantviews.Clarityisderivedfrom
therigorsofdetailing.Knowinghowfartogo,whentostop,whentochangegearsand
howthepiecesfittogetherwillalwaysdependonthepurposeforwhichamodelis
created.
B.2.1.2CreatingtheContextDiagram
Tostartamodel,createtheA0diagram.Drawasingleboxcontainingthenameofthe
functionwhichencompassestheentirescopeofthesystembeingdescribed.Useinput,
controlandoutputarrowsenteringandleavingtheboxtorepresentthedataandobject
interfacesofthesystemtoitsenvironment.Thissingleboxdiagramboundsthecontext
fortheentiremodelandformsthebasisforfurtherdecompositionefforts. Statethe
purposeandviewpointonA0contextdiagram.
SomeauthorsfinditeasiertosketchtheA0andthendrawthesingleboxandinterface
arrowsshownatlevelA0.Itmaybenecessarytoswitchdiagrammingeffortsbackand
forthbetweenA0andA0severaltimestoobtainagoodstartforthedecomposition.
IftheA0diagramhasbegunattoolowalevelofdetail,maketheA0boxthebasisofa
newlevelA0diagram.MoveuponeleveltoanewA0andrevisittheViewpointand
Purposestatements. RepeatthisprocessuntilanA0isreachedwhichhassufficient
scopetocoverallaspectsofthesystem. (Sometimessuchahigherlevelwillbroaden
ratherthanclarifythechosenviewpoint.Ifso,makeanA1multiboxcontextdiagram
andkeeptheA0diagramtotheoriginalintent.)
111

B.2.1.3CreatingtheTopMostDiagram
AllsystemfunctionsliewithinthesingleboxshownontheA0diagram.Thediagram
boundsthecontextofthesystem.TheA0diagramdecomposesthesinglefunctiononthe
A0diagramintoitsthreetosixmajorsubfunctions.
TherealtopofthemodelistheA0diagram.ItsstructureclearlyshowswhattheA0
diagramtriedtosay.ThetermsandstructureofA0alsoboundeverysubsequentlevel
becauseitisacompletedescriptionofthechosensubject.LowerlevelsdelineatetheA0
functions(boxes).Ifthepurposeofthemodelistobeachieved,thischainofdetailing
must be carefully followed at each step. Beginning at the top is the challenge of
authoring. Itforcestheauthortomaintainalevelofabstraction,keepanevenmodel
depthandrelegatedetailstoalowerlevel.
B.2.1.4CreatingChildDiagrams
Toformthestructureofdiagrams,detaileachboxontheA0diagramintoitsthreetosix
majorparts.Formanewdiagramforeachbox,whichcoversthesametopicasitsparent
boxbutinmoredetail.
Todetaileachboxby3to6childboxes,obtaintheneededadditionalfacts. Createa
firstdraft diagram by first listing all data and objects related to the function being
decomposed.Takecarethatthelistcoverstheentiretopicoftheparentboxsothatno
portionislostinthedecomposition. Thendrawboxeswhichassociatecandidatesub
functionnameswithappropriatedataandobjectsfromthelist,anddrawarrowsbetween
theboxes.
Toderivetheclearestpossiblediagram,modifyorredrawthediagramseveraltimes
untilsatisfied.Split(breakupaboxintotwoormoreparts)andcluster(combinetwoor
morepartsintoasinglebox)untilsatisfied.Splitandclusteruntilyouexpresstheparent
functioninthreetosixboxes.
Generate portions of more detailedlevel diagrams to explore points which need
clarification.Createseveral(3or4)diagramsasaset,ratherthanonediagramatatime.
B.2.1.5CreatingSupportingMaterial
Eventually,eachdiagramwillbeaccompaniedbyapageofnarrativetext,glossaryand,
perhaps,FEOs.ThetextassociatedwiththeA0diagramshouldcompletethemodels
orientationandiswrittenwhentheA0diagramiscreated. Thetextcomplementsthe
context(expressedinA0itself)byexpandinguponthestatedviewpointandpurposeof
themodel.
Textforeveryotherdiagram(includingA0)isquitedifferent. Ittellsabrief,concise
story.Itdoesnotduplicatewhatthediagramalreadysaysbymerelydescribingeachbox
112

functioninwords,butratherweavesthroughitspatterns.Ateverylevel,thiscaptures
theviewpointinawaythatfurthersthepurpose.Agraphicdiagrammayormaynothave
anassociatedtextdiagram.
Theglossaryexplainsthedefinitionstheauthorgivestofunctionsanddata/objectsina
diagram.Thesedefinitionsareimportantbecausetheterminologyusedinthemodelmay
have a completely different meaning in one company from the meaning in another
company. Terminology often differs among units or disciplines within the same
company.
FEOsarediagramsthathighlightaparticularlyinterestingorsubtleaspectofadiagram.
They are not bound by IDEF box and arrow syntax and may contain partial arrow
structuresandnotestoemphasizetheirpoint.

113

B.2.1.6SelectingaBoxtoDetail
Givenacompleteparentdiagram,firmupthehigherlevelsbeforeovercommittingto
details.Thatis,givenA0,emphasizeworkonA1,A2,A3.DecomposingA1intoA11,
A111,shouldbedonelater. Thisavoidspotentialreworkshouldchangesbemadeto
higherleveldiagrams.
Keepinganevendepthisnotastrictrule.Theamountofdepthatanytimedependson
whethermoredepthwouldcapturemeaningbetterthanonediagram.Don'tputoffdoing
alowerleveldiagram,e.g.,A111,butsketchwhiletheideasarefresh. Theimportant
thingistotreatallsuchforaysassketchesuntilthehorizontalevenlevelisconfirmed.
Bereadytoreworkthelowerlevelmaterialifitconflictswithhigherlevel,e.g.,A1,A2,
A3.
Twoguidelinesarehelpfulindecidingwhichboxtodetail:
1.

Startwiththehardpartthepartthatisleastfamiliarorisleastclear.

2.

Selecttheboxwhosedetailwillgivethemostinformationaboutother
boxes.

The simpler topics can be more easily decomposed later, with less risk of error or
oversight,andcanbeeasilymanipulatedtofitthedecompositionofthemorecomplex
issues.
B.2.1.7AuthorActivities
B.2.1.7.1DataGatheringPhase
ReadBackground:Theauthorgathersinformationaboutthesubjectmatterbyreading
sourceinformation.
Interview:Theauthorpersonallyinterviewsanexpertonthesubjectmatter.
Think: Digest the information obtained from reading and interviews before actual
diagrammingbegins.
Pick Box: Decide which box is the appropriate one to detail based on information
obtained.
B.2.1.7.2StructuringPhase
Draw:Thisencompassestheactualcreativeprocessofgeneratingadiagram. Itisnot
limitedonlytodrawingboxesandarrows. Italsoincludesthelistingofrandomdata
elements,makingsketches,etc.,whichprecededrawingboxesandarrows.
114

Redraw:Thiscoversthedigestivestageofdiagrammingandcorrespondstoeditingand
reworkingofverbaltext. Theactivity hereis concerned notwithcreating, butwith
graphicaleditingandrearrangingforclarity.
Fix Master: This applies to the modification of master drawings to incorporate
improvements. It is primarily a mechanical operation, consolidating the results of
separateredrawings,ofteninresponsetoreadercomments.

115

B.2.1.7.3PresentationPhase
WriteandEditText:`Textaccompanyinganydiagramshouldbeprecise. Editingwill
oftenalleviateunnecessarydetailandredundancy.
Assemble:Assembleanymaterial,diagrams,nodetrees,glossaries,text,etc.,relevantto
thesubject.IncludeacompletedCoverSheet.
B.2.1.7.4InteractionPhase
React:Thisreferstotheauthorreactingtocomments.Itisacombinationofreadingand
annotatingreactionstothecommentsinresponsetoreaders.
Talk:Thisrepresentstimespentwhenanauthorandreaderactuallygettogetherandtalk
aboutauthorreactionstothecomments.
Group Meetings: This is the time spent in group meetings reviewing progress or
brainstormingnextsteps.Theminutesofthegroupmeetingswillidentifythesubject
matterunderdiscussion.
B.2.2DrawinganIDEF0Diagram
Diagramcreationisthemostsubjectiveandcreativeactivityofthemodelingprocess.It
isopentowidevariationsbetweenindividualauthors. Noonesetofstepswillwork
equallywellforallauthors. Thestepspresentedhereareaprovensequenceandare
designedtoassistanewauthorindrawingIDEF0diagrams.
a.

Createarelevant,butnotyetstructuredlistofdata.Listitemswithinthe
contextoftheparentboxthatfirstcometomind.Groupitems,ifpossible,
toshowsimilarities.

b.

Name functions that act onthe listed dataand draw boxes aroundthe
names.

c.

Sketchappropriatearrows.Aseachboxisdrawn,leavearrowstubsto
make the box more meaningful. Make complete connections as it
becomesobviouswhatthediagramissaying.

d.

Draft a layout that presents the clearest box and arrow arrangement.
Bundlearrowstogetherifthestructureistoodetailed. Leaveonlythe
essentialelements,andmodifydiagramasnecessary.

e.

Createtext,glossaryandFEOdiagrams,ifnecessary,tohighlightaspects
whichareimportant.Proposechanges,ifneeded,intheparentdiagram.

B.2.2.1GeneratingFunctionBoxes
116

Function boxes are generated using the major subfunctions of the parent. As sub
function names are written, draw boxes around them to form the start of an actual
diagram. Atthisstagethenumberofboxesisimmaterial. Theycanbemodifiedby
clusteringandsplittingtoconformtothethreetosixboxrule.
Clusteringwillgrouptwoormoreboxestoformasinglebox. Itsgoalistocluster
related functions intoasingle,moregeneral function. Iteliminates premature detail
whichobscuresthemessagetobeconveyedatthislevel.
Splittingwillbreakasingleboxintotwoormoreparts.Itistheinverseofclustering.Its
goalistoprovidemoredetailtopresentsufficientunderstandingofthesubjectbeing
decomposed.
Reviewtheresultingsetoffunctionboxes.Lookforgoodbalancebetweenthefactors
chosen. See if the names can be made more specific. Use special terms and
abbreviationsonlywhenneededtopromotecommunicationwiththeintendedaudience
andonlyatthedetaileddiagramlevels. Donotusethematthehighest(A0andA0)
levels.Carefullydefinespecialtermsintheglossary.
Inallcases,makethefunctionboxnamesverbsorverbphrases.Wheneverthephrase
canbeinterpretedaseitheraverboranoun,usethenotation(v)tosignifytheintended
verbusage.
Boxes
1.

Inmostcases,layoutboxesdiagonallyfromupperlefttolowerright.
While any layout which makes clear the authors intent is acceptable,
vertical or horizontal formats tend to crowd arrows and hinder good
structuredanalysisstyle.

2.

Boxesplacedintheupperleftdominateboxesplacedlowerandtothe
rightthroughthecontrolarrowsthatlinkthem.Thisstandardstylemakes
iteasierforreaderstounderstandyourmeaning.

3.

Numbereachboxinitslowerrightinsidecorner.Assigntheboxnumbers
onadiagramfromlefttorightandfromtoptobottom. Thiswillhelp
definethenodenumberforeachbox. Theleadingdigitsoftheboxs
completenodenumberarethesameasthisdiagramsnodenumber.The
lastdigitofthenodenumberisthisboxnumber.IftheboxinFigureB10
appears in diagram A4, then the complete node number for this box
wouldbeA42.

117

FigureB10.BoxNumberandNodeNumber
4.

Onworkingordraftcopies,writethenodenumberor Cnumberbelow
thelowerrightcornerofanyboxthatisdetailed. TheCnumberDRE
indicatesthespecificversionofthediagramthatisintended.

5.

Nodiagrammaycontainmorethansixboxes.

B.2.2.2CreatingInterfaceArrows
Sketchinterfacearrowsconnectingtoeachindividualbox. Connectendsofarrowsto
showwhichoutputssupplywhichinputsandcontrols.
Recallthatinputdata/objectsaretransformedbythefunctiontoproducetheoutput.Ifan
arrowcontainsbothinputandcontroldata/objects,showitasacontrol.Ifitisuncertain
whetheranarrowisacontroloraninput,makeitacontrol.Ifitisunclearwhetherornot
aparticulardataorobjectarrowisneededatall,leaveitout(aslongasitisnottheonly
control).
Outputarrowsshowtheresultsofpossibleactivationsofthefunction. Thesyntaxfor
outputarrowsdoesnotindicatewhichpatternsofoutputarrowsmayoccurunderwhich
circumstances. If the sequence is of particular interest, draw a FEO illustrating the
pattern. Do notworry about sequence. Just make surethat all important cases are
allowedbythediagram.
Bundlegroupsofrelatedarrowswheneverpossible. Themostcommonmistakewhen
creatingarrowsistomakethearrowstructureorthearrowlabelstoodetailed.Thelevel
ofdetailofarrowsshouldmatchthelevelofdetailofboxes.Athighlevels,bothbox
namesandarrowlabelswillbegeneral.

118

Asafinalcheck,compareallarrowstothedatalisttoinsurethateachcorrectdataitem
appears.Elementsthatdonotappeareitherareinappropriateforthislevelofdetailor
wereoverlookedwhencreatingthearrows.
Thinkcontrolandconstraint,notflow.
Abasicruleforlayoutofthearrowstructureisconstrain,dontsequence. Thatis,
make the diagram structure show relationships that must be true no matter which
sequenceisfollowed.
Eventhoughsomethingmustprogressfromstagetostagetoreachsomedesiredend
result,trytoexpresstheconstraintsthatmustbesatisfiedortheinvariantpropertiesthat
mustbetrueratherthansomeonespecificsequenceofstepsthatwillyieldthatresult.
The reason is that all boxes may be active simultaneously. Thus, sequence has no
meaning.
Itisalwaysmorepowerfultoconstrainthantosequence.Whereverpossible,diagrams
shouldbecreatedthatsaytherightthingregardlessofwhatstepsaretakenfirst.Clearly,
thisisbetterthanrestrictingtoonlyoneofthepossiblesequences.
Often,itiseasiestatfirsttothinkofsubfunctionactionsinaparticularsequencetoget
unstuckandgetsomethingonpaper.Thismaybeagoodwaytogetgoing,butalways
reworkthefirstattemptintoaconstraintstructure.
Labelcarefully.
Subordinationofunneededdetailshighlightsthemeaningfulones. Dontclutteryour
diagramswithtoomuchinformationandtoomanyarrows.Dontspendtoolongona
singlelevel. Everythingneednotbeexpressedatoncetoavoidbeingincompleteand
misunderstood.Thewholepointofthedisciplineistogeteverythingsaid,eventually.
Also,ifthereistoomuchinadiagram,itbecomesrigid.Ifthisisallowedtohappen,the
diagramisweakened.Strengthcomesfromthestructure.Thiscanbeaccomplishedby
leavingdetailstothesubfunctions. Doiteratebetweenhighleveldiagramsandsub
functionsthatfilloutthedetails.

119

Leaveoutquestionablearrows.
Itisoftenhardtodeterminewhethertoshowanarrowornot.Theeasiestwaytohandle
thearrowquestion,isWhenindoubt,leaveitout.Ifthearrowisntreallyessentialto
themainbackbone,iftherearequestionsaboutit,itisprobablyincorrecttoincludeit.
Incorrectomissionofaquestionablearrownowwontcausepermanentdamage. The
needforthearrowwillbeclearerinconsideringsubfunctionsandtheICOMdiscipline
willforcethearrowbackuptothislevel.Atthattime,therewillbenoquestionaboutit.
B.2.2.3LevelofEffort
The initial goal in generating adiagram should bea clear diagram that represents a
definitemessageanddoesnotviolateanysyntaxrules.Whenthediagramisfinished,the
criticalguidelinesofreadingandreviewbyotherscanbeusedtoimprovethefirsttry.
Mostdiagramscanbemodifiedtomakeasecondversionthatisinsomesensebetterthan
thefirst.Thefirstwillrarelybetheverybest.
Asskilllevelsdevelop,firstdiagramsgetbetterandauthorsfeelmorecomfortableusing
IDEF0.Reworkingofdiagramswillalwaysbeanecessarypartoftheprocess.Thekey
ideaistouseareviewcycletomakeprogressonpaper.Inaseriesoforderlyadvances,
alloftheimportantaspectswillbeproperlyhandled.
IDEF0isathoughtformingmethodology,notjustadiagrammakingexercise.Putting
thoughts on paper and letting the notation and discipline work is a move towards a
satisfactory resolution. Rely onanability toaskgoodquestions,rather than onthe
expectationsofprovidingperfectanswers.
B.2.3ReDrawinganIDEF0Diagram
B.2.3.1ModifyingBoxes
Whenfirstcreatingadiagram,36functionboxesofapproximatelythesamelevelof
detailarederived.Clusteringandsplittingwillprovideaboundarywhichismoreeasily
understoodorwhichwillprovideasimplerinteractionbetweenthefunctionboxes.
Mostoften,clusteringandsplitting worktogether. Boxes aresplit andthe resulting
piecesclusteredintonewboxeswhichmorecloselyconveytheintendedmessage.The
samesubjectmatteriscovered,butpiecesaregroupedinamoreunderstandableway.
Splitandrephrase.
Itisimportantthatalloftheboxesofadiagramhaveaconsistentflavor. Changes
elsewhere should not make an existing subfunction seem out of place. Split and
rephrasetorestorethebalance.
120

Sometimesaboxdoesnotflowwiththeotherboxesofthecurrentdiagram.Frequently
thetroubleisthatotheraspectshaveundergonechangeandclarification.Thatwhich
earlierwasagoodidea,nowhasthewrongslantorflavor.
Divide the offending box by splitting it into two or more pieces, one of which still
containstheessenceoftheoriginalidea,butmorepertinentlyandconcisely.Doexpect
tochangethewordingofthebox(orboxes). Withtheseparation,newideasbecome
clearerandmeshmorecloselywithrelatedboxes.

121

Clusterandreplace.
Asolidabstractionisbothclearerandmorepowerfulthanprematuredetail. Cluster
relatedboxesandreplacebyasingleencompassingbox.
Frequentlyagoodlevelofabstractioncanbemadeevenbetterbyclusteringseveral
boxesintoamoregeneralviewandpostponingthedetailstothenextleveldown.Draw
alinearoundtheclusterandreplacethemallwithonebox,suitablynamed.Theextra
levelisnotanaddedcomplexity.Itisabetterrepresentationbecausethestructurehas
beenshownmoreclearly.
This phenomenon arises often in conjunction with splitting and is one of the most
powerfulmethodsofexplainingfunctions.
B.2.3.2BundlingArrows
Botharrowsandboxesshouldbeatacorrespondinglevelofabstractioninadiagram.
Therearetwobasicwaystoachievethis:
1.

Bundlearrowswiththesamesourceanddestinationunderasinglemore
generallabel,andmakeonearrow.

2.

Renamesomeboxes(usingSplitandCluster)tobetterdistributethesub
functionsandrelabelresultingarrows.

Itisseldomtruethatanexcessofarrowsindicatesamistake.Itmaybethattheyareboth
accurateandprecise.Butitisalwaystruethatanexcessofarrowsisbadifthemessage
isobscured. Theabilityofreaderstounderstandwhatisbeingsaidshouldguidethe
numberofarrowsused.
B.2.3.3ProposingModificationstotheContext
Thedetailedunderstandingrevealedbycreatinganewdiagrammayuncovererrorsor
oversightsintheparentdiagram.Parentmodificationisanaturalandanticipatedevent.
Whencreatingthearrowstructure,theruleisthatifthereisanydoubtwhetheranarrow
isneededbyafunctionbox,leaveitoutlaterdetailingwilldemonstratewhetherornot
thearrowisreallyneeded. Thisisthepointwheresuchquestionsareresolvedfora
specificreasonratherthanthroughtheformerspeculation.
Parentdiagramchangesmaypresentvariousdegreesofdifficulty.Ifthechangecanbe
accommodatedbyarevisiontotheimmediateparentonly,thisissimplerthanarevision
which involves more remote diagrams as well. When proposing a change, think it
throughcarefullyandassessitscomplexity.Substitutingsimplechangesformajorones
canharmthequalityofthedecomposition.Whenthecorrectioniscompleted,checkall
122

boundary connections to insure that ICOM codes are properly shown. Inform other
authorsworkingonthediagramofthechanges.
Alwayshaveinmindtheparentdiagramfortheboxbeingdetailed. Itwillaidinthe
creationprocess.Ifthedetaileddiagramdoesntfitthecontext,eitherthecurrentwork
orthecontextiswrong. Changethecontextorchangethecurrentwork. Theymust
match.

123

B.2.3.4ICOMSyntaxforConnectingDiagrams
Animportantaspectofunderstandingdiagramsistheabilitytofindandunderstandfacts
thatareneeded. Nodenumbersshowthestructureofthefunctiondecomposition(box
detailing).Thearrownetworkprovidesinterfaceconnections.
ICOM codes are written on all arrows having one end unconnected onthe diagram.
These boundaryarrows connect thearrow networkacross diagrams. Each boundary
arrowislabeledwithanICOMcodetospecifytheconnectionofthearrowtotheparent
box.
B.2.4GraphicLayout
Layouttheboxesdiagonallyaccordingtotheconstraintstructure,fromtheupperleftto
lowerright.Controlfeedbacksgoupandleft,andinputfeedbackarrows(whichmodel
memory)godownandleft.Atthispoint,numbertheboxesfromlefttoright.
Itisbesttostartthislayoutwiththemostheavilyusedconstraintarrowsonly,addingless
usedpathslater.Thissubsetofthearrowswillpermittheboxpositiontobedetermined.
Drawallboundaryarrowsshownontheparentdiagram andthenaddtheremaining
arrows.
B.2.4.1ConstraintsontheDiagram
1.

Functionboxesshallalwayshavecontrolarrows,thoughtheyneednotalways
haveinputs.

2.

Whenanentryarrowservesbothcontrolandinputfunctions,showitascontrol.
Whenindoubt,makeitcontrol.Anarrowappearingonaparentboxascontrol
can appear on the next level as control or input or both, depending on its
relationshiptosubfunctionsatthatlevel.

3.

Ingeneral,donotsplitanarrowintobothacontrolandaninputtothesamebox.
Thisdetailisbestshownonalowerleveldiagramwherethedestinationofeach
branchandthereasonforthesplitwillappear.Whenitmustbedonetomakethe
parentmoremeaningful,chooselabelsforthetwobranchesthatwillconveyyour
importantdecision.

124

125

4.

Iteratedactivity(memorystorageorfeedback)maybeshownas:

126

127

5.

Trytoavoidredundanciessuchas:

128

129

Inthesecases,thetrivialboxnamesmerelyrepeatthemessageconveyedbyplacement
ofthearrows. Alittleadditionalthoughtwillusuallyproducemoreinformativebox
names.
B.2.4.2ArrowPlacement
1.

Draw arrows along horizontal and vertical lines, not diagonally or as curves
(exceptatcorners).

2.

Placearrowcorners,crossingsandlabelsareasonabledistanceawayfromboxes.

3.

Dontusethekeywords,i.e.,data,function,input,output,control"or
mechanisminnamesorlabels,unlessabsolutelynecessary.

4.

Ifanarrowislong,labelittwice.

130

131

5.

PlaceICOMcodesattheunconnectedendsofarrows.

132

I2
133

6.

Connectopenendedboundaryarrowstoshowalltheplacesaffected. Readers
maymissconnectionsotherwise.

134

135

7.

Spaceparallelarrowsadequately. Theyarehardtofollowvisuallyiftheyare
lengthyandclosetogether.

136

137

8.

Placeextraarrowheadsalongarrowswhereneededforclarity.

B.2.4.3ArrowLayout
1.

Bundlearrowswiththesamesourceandthesamedestinationunlessthearrowis
ofsuchimportancethatmakingitpartofapipelinewoulddecreaseclarity.

138

139

2.

Useasfewarrowsaspossibleonanyonesideofabox.Iftherearetoomany,
bundlesome,labelwithasuitableabstractlabelandfanoutbranchestotheir
destinations.

140

141

3.

Controlfeedbacksshallbeshownasupandover.

142

143

Inputfeedbacksshallbeshownasdownandunder.

144

145

Mechanismfeedbackshallbeshownasdownandunder.

146

147

4.

Ifanarrowforksandfeedsintoseveralboxes,drawitatthesamerelativeICOM
positiononeachbox,ifpossible.

148

149

5.

Layoutarrowssoastominimizecrossings.

6.

Minimizecurvesandcorners,whilekeepinglabeledsegmentsclear:

150

151

7.

Usetheexpressivepotentialofbranchingarrowswhenandifitisappropriate.

152

8.

To avoid clutter when showing an arrow which applies identically to or is

obtainedidenticallyfromeveryboxonadiagram,usethetoallconvention:

153

154

9.

Allarrowsshallhavecurvedcornersatjoins,forksandbends.

155

156

B.2.5WritingText
B.2.5.1TextandGlossary
Thetextthatmayaccompanyeachdiagrampresentsabriefintegratingoverviewofthe
diagram,citingimportantrelations,patterns,orsubtleinteractionsbetweentheboxesand
arrows.
Preferably,thetextislessthanapageinlength. Ithighlightsfeaturesthattheauthor
feelsareofspecialinterestorsignificancebywalkingthereaderthroughthemainideas
ofthediagram.Itdoesnotduplicateeverydetailshownonthediagramitself.
Write the text only after a diagram has received a fairly high level of review and
approval.Waitingtowritethetextforcesthediagramitselftoproperlycommunicatethe
intendedmessage.Textbasedoncarefullydrawndiagramswillbeasstructuredandas
organizedasthediagramitself.
Useglossarydefinitionstosummarizethespecialmeaningsthatmayariseforkeyterms,
words,phrasesandacronymsusedinthediagram.Awordorphrasemayhavedifferent
connotationsfordifferentreadersofthediagram.
TrytogetgoodtextwithoutaddingaFEO. FEOsshouldbeusedtoillustratesubtle
aspectsthatclarifytheintentofadiagrambutwhichwouldclutterthediagramwerethey
included.IfaFEOisnecessary,thetextthataccompaniesitshouldrefertotherelated
diagram.
B.2.5.2NotesandReferences
Therearetwokindsofnotes,modelnotesandreadernotes.Modelnotesarediscussedin
thenormativesection.
Insharpcontrasttothemodelnotes,whicharepartofthediagramonwhichtheyappear,
readernotesexplicitlyareonthediagram,notpartofthediagram.Thustheycannotalter
themeaningofthediagram'ssyntaxorsemantics.Aswithmodelnotes,ifthetextofa
readernoteistoapplytoseveralplacesortoseveralfeaturesofthediagram(including
othermodelnotesorreadernotes)thecirclednotenumber(withoutanytext)maybe

157

copied and may be attached by an IDEF0 squiggle

158

159

to

each

point

Bydefinition,readernotesarestrictlyinformative,notnormative. Theymaybeabout
anythingatall,withrespecttothediagramormodel.Inpractice,readernotesmaybe
aboutthemodeledsubjectmatteroraboutitsmodeledpresentation,includingchoiceof
words,layout,accuracy,etc.

160

Reader notes are denoted by a number n inside a small circle:

161

162

. For any specific diagram (and hence node number), the numbers, n, shall fo
maconsecutivesequence,startingat1.Allreaders(includingtheauthor,whenc
mentingaboutsomething)shallsharethesamereadernotesequenceforadiagram.Read
rnotenumbersforanodeshallneverbereusedorreassigned. Thustheircreation
sequence

in

the

context

of

thei
Astandardnotationisusedinwritingtextandnotestorefertodiagramsandspecific
partsofdiagrams.Referencesarebasedonboxnumbers,ICOMcodes,nodenumbers,
andnotenumbers.
Forexample,
O2

means

TheboundaryarrowwithICOMcodeO2

2I1

means

Box2Input1

2O2to3C1

means

Thearrowfrom2O2to3C1

163

164

165

means

ModelNoten

|n|

means

ModelNoten(alternatenotation)

(n)

means

ReaderNoten(alternatenotation)

166

167

168

means

ReaderNoten

QA/A21.3C2 means

InQAmodelondiagramA21,seeBox3Control2

169

A42.

170

171

means

OndiagramA42inthismodel,seereadernote3

172

A42.

173

174

means

OndiagramA42inthismodel,seemodelnote3

A42.3

means

OndiagramA42inthismodel,seeBox3

Theseitemsmaybeusedindividuallyiftheyrefertothecurrentdiagram(e.g.,inmodel
notesortext).Otherwisetheyshouldbeprecededbynodenumber,andifnecessary,by
modelname.Aperiod.isusedtomeanseeacertainthingonthespecifieddiagram.
Forexample:
MFG/A21.3C2

means

InmodelMFG,ondiagramA21,seeBox3
Control2.

Each reference needs only as many fields as are necessary to be completely

unambiguous.
Thefullestformis:
ACCT/(A21=BT56).1O2to4C3
whichmeansinmodelACCT,diagramA21,CnumberBT56,seethearrowfrom
Box1Output2toBox4Control3.
Embedneatandcompletereferencesinthewordingofthetext,glossary,andFEOpages,
e.g.,"Theinfluence(2o3to1c2and3c2)ofthiscostontheultimateprice(o2)isof
concern." This traces the third output of box 2, through boxes 1 and 3, to the O2
boundaryarrowasthesentenceisread.Whenfinishedwiththetextgothroughandadd
boxnumberreferencestotiethetexttothediagramexactly.
Mostofthetimeasimpleboxnumber(Box3)orareferencetoacoupleofarrowsis
sufficient (Box 3, O1 and C2). When a reader needs to actually see the other
diagram,usethe.ofthereferencelanguage.

JustasICOMcodingnaturallyextendsthenodenumberbasedreferencingscheme,the
modelnoteandreadernotenotationspermitthemtobereferenced.
Forexample,
A21.3C2|2|(5)reply
carriesthepreviousexample(OndiagramA21,seeBox3Control2)tothecasein
whichthereaderreferencesthediagramauthorsreplytoreadernote#5(perhapsadded
bythesecondreaderofthediagram)whichcommentedontheauthorsmodelnote#2,
regardingthecontrolinquestion!Inthisexample,replyshowstheuseofbriefnatural
languageexpressionsinthereferencelanguage.

175

This example also illustrates the use of abbreviations |n| for

176

177

(modelnotes)

and

178

(n)

for

179

(readernotes)fortextualreferencepurposes.Theseabbreviationspermiteasierpreparat
on of references to notes using standard word processors. References to

B.3DataCollectionforIDEFModeling
B.3.1Introduction
Whenanalyzingordesigninganysystem,itmaybenecessarytoobtainorverifyfacts
about the system or subject matter at hand. There are many sources of factual
information.
Onemightdothefollowing:

Readexistingdocuments,usingeachtableofcontentsandindextolocate
neededinformation.

Observethesysteminoperation,ifitalreadyexists.

Survey a large group of people, through questionnaires or other such

means.

Talktooneormoreexpertswhopossessthedesiredknowledge.

Usewhateverisalreadyknownbytheauthor.

Guessorinventahypotheticaldescription,andaskreaderstohelpbringit
closertoreality.

Of all these methods, the most important is facetoface interaction with an expert.
Seldomwillallexistinginformationbewritten.Preconceivednotionsthatarereflected
inquestionnairesareoftenfaulty.
Akeypartofinterviewingistorecordtheinformationobtained.Thiscanbedoneeither
asinformalnotes,asactivityanddata/objectslists,asaformalmatrixoffunctions,oras
diagramsketches.
B.3.2TheInterviewProcess
Thepurposeofaninterviewistogatherinformationfromanindividualwhopossessesan
expertiseconsideredimportanttotheanalyticaleffort.Therearefourtypesofinterviews
thatmightbeconductedduringthecourseofperformingtheanalysisphaseofanIDEF
project.
(a)

FactFindingforunderstandingcurrentoperations.Thistypeofinterview
isusedtoestablishthecontentofaCurrentOperationsModelortohelp
understandtheexistingenvironment.
180

(b)

Problem Identification to assist in the establishment of future

requirements. This type of interview is used to validate the Current
OperationsModelandtoprovidethefoundationforaFutureOperations
Model.

(c)

Solution Discussion regarding future system capabilities. This type of

interviewisusedtoestablishthecontentofaFutureOperationsModel.

(d)

IDEF Author/Reader Talk Session. This type of interview is used to

resolveproblemswhichhavesurfacedduringtheconstructionofanIDEF
model.

Thereasonforidentifyingtypesofinterviewsisthatduringthecourseofperformingan
actual interview, ingredients of each type appear. The respondent might tell the
interviewerfactsaboutagivensystemintermsofproblems.Also,therespondentmight
identifyproblemsintermsofsolutionstotheproblems. Byconstantlyclassifyingthe
respondentsremarks,theinterviewercanbetterappreciatetheexpert'spointofview.
B.3.3TheInterviewKit
Astandardinterviewkitcanbeusedforrecordingtheinterview.Itmaybestoredinan
interview file and it may be distributed to appropriate project individuals. This
distribution mightincludeothermembers ontheanalysis teamoreventheinterview
respondentforcorrections,additionsanddeletions.Theinterviewkitwouldcontain:
1.

CoverPage(Kitcover)

2.

InterviewandRecordFollowup
(a)
(b)
(c)
(d)
(e)
(f)
(g)

InterviewerName(IDEFAuthorName)
InterviewDate(IDEFDiagramDate)
InterviewDuration(Starttime,Endtime)
RespondentName
RespondentTitleandOrganizationalResponsibility
RespondentTelephoneNumberandExtension
AdditionalSourcesofInformationIdentified
(1)
(2)

(h)
(i)

DocumentsTitleandLocation
Other IntervieweesName, Title, Organizational
Responsibility,Address,TelephoneNumber

EssentialElementsofInformationASummaryofthekeypoints
coveredintheinterview
Followup questions and/or areas of concern either not covered
duringtheintervieworpostponed
181

(j)

NewTermsforProjectGlossary

3.

ActivityandData/ObjectsList

4.

InterviewAgenda(developedinpreparationforinterview).

5.

InterviewNotesandRoughDiagrams

182

ANNEXCREVIEWCYCLEPROCEDURESANDFORMS
C.1IDEFTeamworkDiscipline
The development of any IDEF model is a dynamic process which requires the
participation ofmorethanoneperson. Throughoutaproject, thedraftportions ofa
modelarecreatedbyauthorsanddistributedtoothers(projectmembers,expertsinthe
subjectmatter,management,etc.)forreviewandcomment. Thesedraftportionsofa
modelarecalledKitsandmaycontaindiagrams,text,glossaryoranyotherinformation
theauthorfeelsispertinenttothedevelopmentofthemodel.
ItrequiresbrieftrainingandmodestexperiencetocorrectlyreadandunderstandIDEF0
models. Such knowledgeable understanding is essential if the teamsupplied quality
assuranceofIDEFmodelingistoberealized. Everyonesuitablyadvancedincorrect
readingskillsiscalledareader.
TheIDEFteamworkdisciplineidentifiesallpersonsinterestedinthereviewofamodel
asreviewers.ReviewerswhoareassignedtomakeawrittencritiqueofaKitarecalled
commenters.ReviewerswhoreceiveaKitforinformationonlyarenotexpectedtomake
written comments and are called readers. The author and the commenters share
responsibilityforthequalityofthemodel.Throughtheiracceptanceoftheagreedresult,
theotherreviewersshareaccountabilityfortheutilityoftheresults.
ThedisciplinerequiresthateachpersonexpectedtomakecommentsaboutaKitshall
make them inwriting usingreadernotes andsubmitthemtotheauthoroftheKit.
Writingonthereaderscopy,theauthorrespondstoeachnoteinwriting(asimplecheck
mark,foragreement;otherwise,anoteinreply).Thiscyclecontinues,encompassingall
Kitspertainingtoaparticularmodel,untilthemodeliscompleteandrecommendedfor
publication.
Atregularintervalsduringtheevolutionofamodel,themastercopyofthelatestversion
isplacedinthelibrary,andacopyisdisseminatedintheformofaKit,whichissentto
readers to assist them in maintaining current information about the model. As the
commentsoneachkitarereviewedbytheauthor,hemakeschangesinthemastercopy
ofthemodeltoincorporatecorrectionsandchanges. Anotherkitwhichincludesthe
latest changes isthendistributed tothelistofreaders. Moredetail isaddedbythe
creationofmorediagrams,textandglossary.Morecommentsaremade;morechanges
areincluded.Theendeffectofthisprocessfororganizedteamworkisahighassurance
that thefinalIDEFmodels arevalid,wellexpressed,andthat aconsensus has been
reachedbythesetofreaderswhohavebeenincludedinthereviewcycle.

C.2TheIDEFKitCycle
Increatingadocument,materialswrittenorgatheredbyanauthoraredistributed,inthe
formofaStandardKit,tocommenters,reviewersandotherreaders.Commentersreview
183

thematerialandwritecommentsaboutit.ThecommentersreturntheKittotheauthor
whoreactstocommentsandmayusethecommentstoreviseorexpandthematerial.The
Kitisreturnedtothecommenterwiththereactionsfromtheauthor.Readersmayreturn
commentstotheauthoraswell,butthisisnotrequired.ThisisknownasaKitCycle
(FigureC1).

184

185

FigureC1.KitCycle
ThestepsoftheKitCycleareasfollows:
TheauthorassemblesthematerialtobereviewedintoaStandardKit.Acover
sheetiscompleted.Copiesofthekitaredistributedtoeachofthereaders,and
totheauthor.Theoriginalisfiledforreference.
Within the response time specified, the commenter reads the kit and writes
commentsdirectlyonthecopyintheformofreadernotes,inredifpossible.
Thekitisreturnedtotheauthor.
Theauthorrespondsinwritingdirectlyoneachcommenter'scopy,inblueif
possible.Theauthormayagreewiththecommentbycheckmarkingit,noting
itonhisworkingcopyandincorporatingitintothenextversionofthemodel.
If there is disagreement, the author writes a note of reply attached to the
reader'snote(nonewnotenumber).Whetherornotthereisdisagreement,the
kitisreturnedtothereader,completingoneReader/AuthorCycle.(SeeC.4.1.2
regardingreadernotenumbering.)
The reader reads the authors responses and, if satisfied, files the kit.
(Commentedkitsarealwaysretainedbythereader.)Ifanassignedcommenter
does not agreewith theauthors responses,ameeting is arrangedwith the
authortoresolvedifferences.Ifthiscannotbedone,alistofissuesistakento
appropriate authority for decision. The author is not obligated to resolve
differences with every reader, but commenters are disenfranchised if their
concernsarenotresolved.
This cycle continues until a document is created which represents the careful
considerationofallprojectmembers.Inaddition,acompletehistoryoftheprocesshas
beenretained.
The results ofthis Kit Cycle areadocument towhichauthor andcommenters have
contributed,and,ifnecessary,alistofissuesthatrequiremanagementaction.
Throughoutthecycle,aprojectlibrarianhandlescopying,distribution,filingandtransfer
ofkitsbetweenauthors,commenters,reviewersandreaders.

C.2.1PersonnelRoles
Therolesandfunctionsofpeopleinvolvedare:
Authors(Analysts)
186

PeoplewhoprepareanyIDEFmodel.
Commenters(ExpertsorotherAuthors)
Peopleknowledgeableofthesubjectbeingmodeledfromwhomauthorsmay
haveobtainedinformationbymeansofinterviews,andhaveenoughtrainingin
anIDEFtechniquetoofferstructuredcommentsinwriting.Peopleassignedto
makeawrittencritiqueofakit.
Readers(Expertsoranyonewhowishestobeonthereaderlist)
Peopleknowledgeableofthesubjectbeingmodeledfromwhomauthorsmay
haveobtainedinformationbymeansofinterviews,andreviewdocumentsfor
informationbutarenotexpectedtomakewrittencomments.
Librarian
Apersonassignedtheresponsibilityofmaintainingafileofdocuments,making
copies,distributingkitsandkeepingrecords.
AllpeopleplayingtheserolesmustbetrainedandexperiencedIDEF0readers,sothey
canperformtheassignedfunctionsreliably.
Arolehasnothingtodowithsomeonesjobtitle,andthesamepersonmaybeaskedto
perform several roles. Thus, each individuals participation is, in fact, unique and
dependsuponthekitinvolved.
C.2.1.1Author
Anauthorinterviewsexperts,analyzestheinformation,organizesitintodiagramsand
createsmodels. Anauthormayormaynotbethesourceofthetechnicalcontentofa
document.Anauthormayserveonlyasananalystofacquiredinformation,identifying,
sorting out and organizing the presentation of knowledge obtained from experts and
applyingmodelingskillsinexpressinghisunderstandinginIDEF0terms.
C.2.1.2Commenter
Assigned commenters read material produced by an author and verify its technical
accuracy. Theyareresponsibleforfindingerrorsandsuggestingimprovements. The
roleofacommenteristhekeytoproducinghighqualityresults.Buteveryreadershould
note whether the author has followed the IDEF technique consistently; whether the
viewpoint and purpose have been adhered to; and whether errors or oversights exist
which should be brought to the author's attention. If a reader is a trained author,
suggestingchangesinthehierarchicalbreakdown,variationsinactivityboxcontentand
otherobservationstoenhancethecommunicationpowerandutilityofthemodelwillbe
welcomedbymostauthors.
C.2.2GuidelinesforAuthorsandReadersandCommenters
187

Inthissection,generalguidelinesforreadersandauthorsarediscussedreadersmay
havefurtherspecialinterestsascommentersandreviewersthatarenotcoveredhere.
C.2.2.1ReaderGuidelines
Nosetpatternofquestions andrulescanbeadequate forcommenting, sincesubject
matter,styleandtechniquevarysowidely.However,guidelinesdoexistforimproving
quality.Themajorcriteriaforqualityare:Willthedocumentcommunicatewelltoits
intendedaudience?Doesitaccomplishitspurpose?Isitfactuallycorrectandaccurate,
giventheboundedcontext?Overallguidelinesforcommentingare:

Make notes brief, thorough and specific. As long as the author

understandsthatnicetiesaredroppedforconciseness,thismakesforeasier
communicationandlessclutter.

188

Use

189

the

190

notation (reader notes) to identify comments. To write an

191

192

note,checkthenextnumberofftheREADERNOTESlist,numberthenote,ci

193

194

.(SeeSectionC.4StandardDiagramForm.)

Make constructive criticisms. Try to suggest solutions or point out

sourcesofproblems,clearly.

Taketimetogatheroverallcomments.Thesemaybeplacedonthecover
oronaseparatesheet. (Butdontgatherspecificpointsontothissheet
when they belong on the individual pages.) Agenda items for
author/commentermeetingsmaybesummarized.Makeagendareferences
specific.

Thelengthoftimespentcritiquingdependsonavarietyofthings:familiaritywithwhat
isbeingdescribed,thenumberoftimessomethinghasbeenreviewed,theexperienceof
thereaderandauthor,etc.Akitreturnedtoanauthorwithnocommentsotherthanthe
readerssignatureandacheckmarkmeansthatthereaderisintotalagreementwiththe
author.Thereadershouldrealizethatthereisasharedresponsibilitywiththeauthorfor
thequalityofthework.
C.2.2.2Author/CommenterInterchanges

195

When a reader returns a kit, the author responds by putting a or X by each

196

197

note(readernote).meanstheauthoragreeswiththecommenterandwillincorporate
ecommentintothenextversionofthekit.Xmeanstheauthordisagrees.Theaut
or must state why in writing where the comment appears. After the autho
C.2.2.3MeetingGuidelines
Untilcommentsandreactionsareonpaper,readersandauthorsarediscouragedfrom
conversing.
Whenameetingisrequired,theprocedureisasfollows:
1.

Eachmeetingshouldbelimitedinlength.

2.

Eachsessionmuststartwithaspecificagendaoftopicswhichrelateto
oneormoreofthecommentsandauthorresponses,andthesessionmust
sticktothesetopics.

3.

Eachsessionshouldterminatewhentheparticipantsagreethatthelevelof
productivityhasdroppedandindividualeffortswouldbemorerewarding.

4.

Each session must end with an agreed list of action items which may
includetheschedulingoffollowupsessionswithspecifiedagendas.

5.

Ineachsession,ascribeshouldbedesignatedtotakeminutesandnote
actions,decisionsandtopics.

6.

Serious unresolved differences should be handled professionally, by

documentingbothsidesofthepicture.

Theresultofthemeetingshouldbeawrittenresolutionoftheissuesoralistofissuesto
besettledbyappropriatemanagerialdecision. Resolutioncantaketheformofmore
studybyanyoftheparticipants.

C.3IDEFKits
A Kit is a technical document. It may contain diagrams, text, glossaries, decision
summaries,backgroundinformationoranythingpackagedforreviewandcomment.
Anappropriatecoversheetdistinguishesthematerialasakit.Thecoversheethasfields
forauthor,date,project,documentnumber,title,statusandnotes.
TherearetwotypesofIDEFKits:
StandardKit Tobedistributedforcomment. Itisconsideredaworkingpaperto
assisttheauthorinrefininghistotalmodel.
198

UpdateKit

Containsthelatestversionofamodel.Itissentforinformationonlyand
isdesignedtoaidinmaintainingcurrentinformationaboutthetotalmodel
whileportionsofthemodelarebeingprocessedthroughtheKitCycle.
TheUpdateKitmayincludeonlythosepageschangedsincetheprevious
updating.

Standard Kits contain portions of a model and are submitted frequently as work
progresses.StandardKitsaresubmittedthroughtheIDEFKitCycleforreviewandare
thetypereferredtointherestofthisannex.
UpdateKitsaresubmittedatregularintervals.Thesekitscontainthelatestversionofthe
model.RecipientsofUpdateKitsarenotexpectedtomakecommentsonthemalthough
theymaychoosetodoso.UpdateKitsarekeptbytherecipientsfortheirfiles.
C.3.1CompletingaKitCoverSheet
Anappropriatecoversheetdistinguishesthematerialasakit. Thecoversheethasfieldsfor
author,date,project,documentnumber,title,statusandnotes.PrepareoneCoverSheetforeach
kitsubmitted,fillinginthefollowingfieldsontheCoverSheet(SeeFigureC2).

199

WorkingInformation

ReviewerInformation

Filingandcopyinginformation
Listofkitreviewers
Scheduledateforvariousstagesofkitcycle

ContentInformation

Authororteamgeneratingthemodel
Projectnameandtasknumber
Dateoforiginalsubmissiontolibrary
Datesofallpublishedrevisions
Statusofmodel,eitherworking,draft,recommendedforacceptance
orpublicationasfinalmodel

Tableofcontentsforthekit
Statusofeachkitsection
Commentsorspecialinstructionstolibrarian

IdentificationInformation

ModelName(inNodefield)
Titleofthemodel
CNumber
FigureC2.IDEFKitCoverSheet

200

FigureC3.IDEFKITCONTENTSFORM

C.3.2HowtoPrepareaStandardKit
Toavoidoversights,reviewthekitasifthatweretheonlyinformationavailable.Catch
anytypographicalerrors.Addpointsofclarificationthatcometomindasbriefnoteson
thekititself. Glossarydefinitions forterms thatappearinthekit shouldalways be
appendedassupportmaterial.
Gather helpful materials and append these for the reader's benefit. Never use this
supplementalmaterialtoconveyinformationwhichshouldproperlybeconveyedbythe
diagram itself. Whenever possible, use themostnatural means ofcommunication
diagramsto show details that are important for the reader in understanding the
concepts. CombineallmaterialwithacompletedCoverSheetandKitContentsSheet
(FigureC3)andsubmittotheLibrary.

C.4StandardDiagramForm
TheIDEFDiagramForm(FigureC4)hasminimumstructureandconstraints.Thesheet
supportsonlythefunctionsimportanttothedisciplineofstructuredanalysis.Theyare:
Establishmentofcontext;
Crossreferencingbetweenpiecesofpaper;
Notesaboutthecontentofeachsheet.
Thediagramformisasinglestandardsizeforeaseoffilingandcopying.Theformis
dividedintothreemajorsections:
WorkingInformation(top)
MessageField(center)
IdentificationFields(bottom)
Thediagramformshouldbeusedforeverythingwritten.

201

FigureC4.StandardDiagramForm
TheformisdesignedsothattheWorkingInformationFieldsatthetopoftheformmay
be cut off when a final approved for publication version is completed. The
IdentificationFieldsatthebottomaredesignedtoshow,oneundertheother,whenthe
forms(withtopsintactfortacking)arespreadverticallyandthumbtacked,intopdown
order,onacorkboardorwall. TheexposedIdentificationFieldStripsactasathumb
indexarrangedinNodeIndex(outline)order. Ifthetwosidedpagepairpublication
formatisfollowed,withtheTextandContextpagebottomstowardthebinding,then
theirinformationbecomesvisiblewhenthewallmountedancestorformsareliftedup,to
seetheMessageFieldofeachdiagram.
C.4.1WorkingInformation
C.4.1.1TheAuthor/Date/ProjectField
Thistellswhooriginallycreatedthediagram,thedatethatitwasfirstdrawnandthe
projecttitleunderwhichitwascreated.Thedatefieldmaycontainadditionaldates,
writtenbelowtheoriginaldate.Thesedatesrepresentrevisionstotheoriginalsheet.Ifa
sheetisrereleasedwithoutanychange,thennorevisiondateisadded.
C.4.1.2The"ReaderNotes"Field
Thisprovidesacheckoffforreadernoteswrittenonthediagramsheet.Asacommentis
madeonapage,thecorrespondingnotenumberiscrossedout.Thisprocessensuresthat
each reader note on a diagram is assigned a unique note number, and that the note
numbersoneachdiagramareconsecutive.
C.4.1.3TheStatusField
Thestatusclassificationsindicatestagesofapproval.Theyare:
WORKING

The diagram is a major change, restarts the approval

sequence.Newdiagramsare,ofcourse,workingcopy,but
alsoitisusualfordiagramstoremainWorkingforseveral
revisionsbeforeadvancing. Anewauthorforadiagram
usuallyresetsthestatustoWorking,aswell.

DRAFT

Thediagramisaminorchangefromthepreviousdiagram,
andhasreachedsomeagreeduponlevelofacceptancebya
setofreaders.Draftdiagramsarethoseproposedbyatask
leader (who may be the author). Draft diagrams may
undergofurtherrevisions,iftheyareincludedinacurrent
kit along with other diagrams, or are brought back into
considerationfromsomereader'sfile,eventhoughtheyare
not in the current kit. Draft status remains until the
202

diagramisacceptedbyareviewmeetingofthetechnical
committeeorcoalition.
RECOMMENDED

Both this diagram and its supporting text have been

reviewed and approved by a meeting of the technical
committeeorcoalition,andthisdiagramisnotexpectedto
change.

PUBLICATION

This pagemaybeforwardedas is forfinalprintingand

publication.

203

C.4.1.4TheReader/DateField
Thisareaiswhereareadershouldinitialanddateeachform.
C.4.1.5TheContextField
Asketchofonlytheboxlayoutoftheparentdiagram,withtheparentboxhighlighted.
The parent diagrams node number is written in the lower left of the Context Field
(FigureC5).Theboxnumberoftheparentboxmaybewritteninthehighlightedbox,
eventhoughitalsoisthelastdigitinthechilddiagramsnodefieldentry.

204

205

FigureC5.Illustrationofcontextfield
Thefollowingspecial casesarise: 1)TheContext fieldoftherequiredA0context
diagramformis"TOP",writteninthecenterofthefield.2)TheContextfieldofthe
optionalA1highlevelcontextdiagramisA2,sketched,ifthereissuchahigherlevel
contextdiagram,andsimilarlyforAn,forn=2orgreater.3)TheContextfieldforthe
highestlevelofcontextdiagram,An,forlargestn(=1orgreater)is"NONE". See
Figure21foranillustrativeexample.
C.4.1.6TheUsedAtField
This isalistofdiagrams,otherthantheparentcontext, whichuseorreference this
diagramformpageinsomeway.
Themostcommonuseisalistingofoneormorenodereferencestosubmodelsfor
whichthischilddiagramsparentboxsuppliessupportforcallsintothischildsdetails.
Ifnecessary(thecasen=1beingassumedbyconvention),thenode_reference_expression
(whichbeginswithamodel_name/followedbyanodenumber)endswithMn,n
greaterthanorequalto2,makingthereferenceintoacompleteICOMcodereferenceto
a specific Mechanism arrow of the supported submodels top box. For example
TLS/A34M2writtenintheUsedAtfieldforchilddiagramMN/A211assertsthat
parentboxMN/A21suppliesmechanismsupport,viathesecondmechanismarrowof
itstopbox,tosubmodelTLS/A34.
WithsuchsupporttoaremotesubmodelsuppliedbythisUsedAtfield,thenanychild
box on this child diagram (or more generally, even the parent box that supplies the
support,oranyoffspringboxes)maybecalledupontosupplydetailsforsomereachable
offspringboxofthesupportedbox(treatedasthetopboxofasubmodel)whosenode
reference appears in the Used At field. A reachable offspring box is a box that is
reachable by a branching mechanism support arrow whose source is ICOMcode
connectedtothemechanismsupport.

206

Ifthetopofthediagramiscutoff,forpublication,thenthecontentsoftheUsedAtfield
must be copied into the Message field as a

207

note(modelnote).
C.4.2TheMessageField
TheMessagefieldcontainstheprimarymessagetobeconveyed.Thefieldisnormally
usedfordiagrammingwithanIDEFgraphicallanguage.However,thefieldcanbeused
foranypurpose:glossary,checklists,notes,sketches,etc.Projectmembersshoulduseno
paperotherthandiagramforms,sothatthereferencenumberbasedfilingsystemcan
provideacompleteprojectrecord. ThiscanbefacilitatedbyIDEFtoolsupportthat
includesEmailandBulletinBoarding,withautomaticCnumberingandpreference
settingsforeachparticipant.
C.4.3TheNodeField
Thisfieldcontainsthecompletenodereferenceforthesheet(includingmodel_name,
slash,NodeNumber,andF(forFEO),T(fortext)orG(forglossary)withthe
page number 1 or 2, etc. appended at the end to indicate overflow pages, if
necessary),sothatthesheetisuniquelylocatedforanyandallreferencepurposes.
C.4.4TheTitleField
TheTitlefieldcontainsthenameofthematerialpresentedontheDiagramForm.Ifthe
Messagefieldcontains adiagram, thenthecontents oftheTitle field mustprecisely
matchthenamewrittenintheparentbox.
C.4.5TheNumberField
C.4.5.1TheNumberField(LargeArea)
ThelargeareacontainstheCnumber.TheCnumberiscomposedoftwoorthreeletters
oftheauthorsinitials(chosentobeuniqueamongprojectparticipants)followedbya
numbersequentiallyassignedbytheauthor.ThisCnumberisplacedinthelowerleft
corner of the Number field and is the primary means of reference to a sheet itself,
becausethesheetasadiagramforminusecanonlybecreatedonce. Everydiagram
formusedbyanauthorreceivesauniqueCnumber,whichhabituallyshouldbethefirst
markmadeontheform.
Iftheprojectelectstotrackversionhistory,thentheCnumberofthediagramformof
which this sheet is an altered version shall be written parenthesized (space optional)
following the author's Cnumber entry in the Cnumber field. For example
AB34(CD123)indicatesthatthissheet(AB34)isintendedtobeareplacementfor
thealreadyexistingCD123.
Whenamodelispublished,theCnumbermaybereplacedbyastandardsequentialpage
number(e.g.,pg.17).
208

C.4.5.2TheNumberField(KitPageNumberSmallRectangleArea)
AkitpagenumberiswrittenbythelibrarianattherighthandsideoftheNumberfield
insidethesmallrectangle.Thisiscomposedofthedocumentnumberfollowedbythe
letteridentifyingthesheetwithinthedocument.

209

C.5KeepingFiles
EachofficiallyassignedparticipantinaprojectshallmaintainReader/Authorfilesofthe
documentsreceived.ThelibrarianshallmaintaintheofficialMasterandReferencefiles
oftheproject,archivingeachkitsubmittedduringthecourseoftheproject.
Variations in the filing process may occur based on individual preferences, but the
following files, maintained in alphabeticallysorted reference number order as the
primaryorganizationalfilingstructure,aretheminimum:
StandardKitFiles
Maintainedbyauthors,commentersandperhapsotherreaders. FileKit
CoverSheetschronologically,asamasterlog,butextractandfilemost
CpagesinappropriateModels,innodereferenceorder.Whenindoubt,
leavesheetinfiledKit,perhapsaddingcrossreferencingReaderNoteson
alreadyfiled diagram forms in selected otherfiling places, as well.
(EverysheetisthepropertyoftheReader,andReaderNotenumbering
restarts fresh for each Cnumbered sheet, so the added personal filing
ReaderNotescannotdoanyharm.)
UpdatedCurrentModelFiles:
Maintainedbyauthors,commentersandreadersfromUpdateKitsthatare
received.MaybeculledinfavorofProjectMasterversions,astheproject
progresses.
WorkingFiles:
Maintained by authorsand any Reader who initiates any ad hoc
interchangebetweenparticipantsthathasnoofficialAuthorassigned.The
KitCoverSheetforsuchaReaderstartedtopicshouldbesuggestively
named, so that an alphabetical filing of Kit contents can parallel the
officialWorkingFilesofmodels,etc.

ProjectFiles:
Maintainedbythelibrariantostandardssetbytheprojectmanagement.

C.6TheIDEFModelWalkThroughProcedure
InadditiontotheKitCycle,aWalkThroughProcedurehasbeendevelopedasaguide
for presenting model information to a group of reviewers (perhaps only weakly
experiencedinunderstandingIDEF0modelsontheirown).Itdoesnotsubstituteforthe
Reader/AuthorCyclereviewprocessthatiscentraltothequalityassuranceofIDEF0
210

modeling (explained in C.2), but may be streamlined for periodic project use at the
technicalleveltoprovideanopportunityforallparticipantstoshareordevelopcommon
interpretationsthatmaynotsurfaceintheoneononeKitbasedinterchanges.
1.

Presentthemodeltobeanalyzedbyusingitsnodeindex. Thisisthe
model'stableofcontents.Providesaquickoverviewofwhatistocome.

2.

Present selected glossary terms. Encourage each reviewer to replace

personal meanings of words with those that the presenting team has
chosen.Themeaningsshouldnotbequestionedatthispoint.Achangein
meaningnowwouldrequiremanychangesinthediagrams.

3.

Presenteachdiagramforreview.

Thediagramwalkthroughprocessisanorderly,stepbystepprocesswherequestions
canbeaskedthatmayidentifypotentialweaknessesinthediagramoritstext.Sixsteps
ofastructuredwalkthroughfollowbelow.
Diagramcorrectionsmaybeproposedatanystep.Thesecorrectionsmaybenotedfor
executionatalaterdateoradoptedimmediately.
Step1:Scanthediagram.
This step allows the reader to obtain general impressions about the content of the
diagram.Typically,thereaderwillhavereviewedtheparentdiagramwhichdepictedthe
current diagram as one of its boxes. The reader is now examining how the author
decomposedthatfunction.
Criteriaforacceptance:
1.

Thedecompositionisusefulforitspurposeandiscompletewithinthe
context of its parent box. All lower level functions can clearly be
categorizedundereachofitsboxes.

2.

Thediagramreflects,inthereviewersopinion,arelevantpointofview
basedonthepurposeofthemodel.

3.

Intheopinionofthereviewer,thereisenoughnewinformationprovided
toextendunderstandingoftheparentbox. Thereisnotsomuchdetail
thatthediagramappearscomplexandhardtoread.

Unless a problem is rather obvious, criticism may be delayed until Step 3 below.
However,firstimpressionsshouldnotbelost.Theymightbeputonablackboardorflip
chartpaduntilresolved.
Step2:Lookattheparent.
211

Oncethereaderunderstandsthecurrentdiagramsdecomposition,theparentdiagram
shouldbereviewedtoinsurecompatibility.
Criteriaforacceptance:
1.

Thedecompositioncoversallofthepointstherevieweranticipatedwhen
readingtheparentdiagram.

2.

Now that the decomposition of this portion of the parent diagram is

revealed,thedetailwhichthereviewerenvisionedforthisboxshouldstill
seemcorrect.Ifnot,notethemissingdetail.

212

Itmightbeimportantatthissteptoreturntotheparentdiagrambrieflyandaddnew

213

214

notes

(reader

notes)

215

or

embellish

Step3:Connecttheparentboxandthedetaildiagram.
Thisstepteststhearrowinterfaceconnectionsfromtheparenttochild.
Criteriaforacceptance:
1.

Therearenomissingorextrainterfacearrows.

2.

BoundaryarrowsarelabeledwithproperICOMcodes.

3.

Childarrowlabelsarethesameoranelaborationofitsparentsmatching
arrow.Labelsconveythecorrectandcompletearrowcontents.

4.

Examinationoftheconnectingarrowsrevealnoproblemsintheparent
diagram. (An added interface may create a misunderstanding of the
messageconveyedbytheparent.)

Aclockwisetourofthefouredgesoftheparentbox,checkingeacharrow,willprovidea
methodicalwaytocheckmatchingofICOMcodesboundaryarrowstotheparentarrows.
Step4:Examineinternalarrowpattern.
Thepatternofboxesandarrowsconstitutestheprimaryexpressionofthemodelbeing
created.
Eachboxwillbeexaminedinnodenumberorder,andeacharrowfollowedinICOM
orderforeachbox.Whenthisprocessiscomplete,thereviewersshouldbeledthrough
thediagramtoexploretheconsequencesofsituationswithwhichreviewersarefamiliar
andtotestthediagramscapabilitytosimulatetherelationshipsknowntoexist.
Criteriaforacceptance:
1.

Thediagramdoesnotlookcluttered.Thenumberofarrowcrossingsand
bendsisminimized.

2.

Theboxesshouldbebalancedwithregardtodetail.Thereshouldbean
equalamountofdetailwithineachbox. However,compromisesonthis
criterionareacceptableforthesakeofclarity.

3.

The diagram should be consistent with the reviewers experience and

knowledgeofthesubjectmatter.Feedbackanderrorconditionsshouldbe
shownasthereviewerexpects.

4.

Thelevelofdetailofthearrowsshouldmatchthelevelofdetailofthe
boxes. Bundling of arrows into more general arrows should be
considered.
216

Step5:Readthesupportivedocumentation.
Thisstepexaminesthepointsthattheauthorhighlightsinthetext,glossaryand
FEOs.
Criteriaforacceptance:
1.

Thetextconfirmstheinterpretationobtainedfromexaminingthediagram
itself.

2.

Normalpaths,feedback,errorhandlingandotherfeaturessuggestedby
thetextarefoundinthediagramorfoundinaFEO(ForExpositionOnly)
diagram.

3.

SignificantdiagramfeaturesuncoveredduringSteps14arefoundinthe
text,glossaryorFEO.

4.

Referencestothediagramaredetailedenoughtoconnecttext,glossaryor
FEOtospecificpartsofadiagram.

Step6:Setthestatusofthediagram.
Setthestatusofthediagram(asdefinedearlier)to:
Working
Draft
Recommended
Publication

217

ANNEXDInformativeDefinitions
Thissectioncontainsdefinitionswhichrelatetotheinformativeannexesofthis
document. SeeSection2fordefinitionsforthenormativesections. Aterm,if
defined,isdefinedeitherinSection2orAnnexD,butnotinboth.
D.1ApprovalLevel: OneofthefollowingfourwordsassignedtoanIDEFmodelto
indicateitsrelativedegreeofreviewandapproval:
Working
Draft
Recommended
Publication

(Lowestlevel)
(Nexttolowestlevel)
(Nexttohighestlevel)
(Highestlevel)

D.2Author:ThepersonwhopreparesandisresponsibleforanyspecificIDEFmodel
ordiagram.
D.3 Clustering: Boxes are split and clustered in diagramming. Clustering is the
groupingoftwoormoreboxestoformasinglebox. Itsgoalistocombinemultiple
functionsintoasinglemoregeneralfunction.
D.4 Commenter: A reader with sufficient training in an IDEF technique to offer
specificcommentsusingthereadernotenumberingsystemand(often)referringtoflaws
intheapplicationofthetechniqueitself.
AnassignedreaderwhosharesresponsibilitywiththeauthorforthequalityofanIDEF
kit,model,diagramorotherIDEFresult.
D.5Draft:Seeapprovallevel.
D.6Expert:Apersonfamiliarwithapartoftherealworldsystem(orsubject)being
modeled.Mayserveasasourceofinformationorasareviewerofpartofthemodel.
D.7IDEFRole:ApositioninanIDEFproject.Seeauthor,expert,commenter,reader
andlibrarian.
D.8Kit:Astandardizedpackageofdiagramscontainingportionsoforcompletetodate
modelstobereviewed.SeeKitCycle.
D.9KitCoverSheet:Aspecialformusedtocontroltheroutingofakitthroughakit
cycle.
D.10KitCycle:AformalReader/AuthorCycleprocedurewhichuseskitsforobtaining
peerorexpertreviewduringmodeldevelopment.
218

D.11Librarian: Thepersonresponsibleforroutingandtrackingofkitsandkeeping
orderlyprojectfilesandarchives.
D.12ProjectField:ThefieldontheIDEFdiagramformwhichrecordsthenameofthe
organizedtaskforwhichanIDEFmodelisprepared.
D.13Publication:Seeapprovallevel.
D.14 Reader: A person with (limited) training in an IDEF technique, sufficient to
accuratelyinterpretsyntaxandbasicmeaningsandtoreadandwritereadernotes,who
seespartorallofamodel.
D.15 Reader/Author Cycle: A procedure using reader notes for obtaining peer or
expertreviewduringmodeldevelopment.
D.16ReaderNote:AtextualcommentbyareaderaboutanIDEF0diagram.Reader
notesarenotpublishedaspartofthediagram,butratherareusedforcommunication
duringaReader/AuthorCycle.
D.17Recommended:Seeapprovallevel.
D.18Reviewer:AreviewersharesaccountabilityfortheutilityofanIDEFkit,model,
diagramorotherIDEFresult.SomereviewerslackReadershiptraining,butparticipate
inguidedwalkthroughs.
D.19Split:Boxesaresplitandclusteredindiagramming.Whenaparentboxisdetailed
onachilddiagram,theparentboxissplitintopieces,someofwhichmaythenbe
clustered,toformthe3to6boxesonthechilddiagram.
D.20Role:SameasIDEFRole.
D.21Working:Seeapprovallevel.

219