Analysis Techniques For Man-Machine Systems Design
Analysis Techniques For Man-Machine Systems Design Analysis Techniques For Man-Machine Systems Design
NATO UNCLAS S I.FIEDAC/243(Panel 8')TR/7 - 24Volume 2The analysis inroduces increasing levels of detail by breaking each function into its component parts. Starting with asingle unit (box) showing the interfaces to functions and resources outside the system, the decomposition proceeds byidentifying the sub-modules, each represented as a box with interfaces. SADT7' uses rules for these decompositions.It is recommended that a module be divided always into no fcwer than three. and no more than six sub-modules.Functions are described by an active verb written inside the box. Arrows that connect to a box represent objects,resources, information, etc. and are labelled by a noun. SADT'" includes procedures for critiquing the analyses by alarger group of people. The creation of a SADT"'1 definition is a dynamic process, which is seen as requiring theparticipation of more than one person. Throughout the project, designated "authors" create initial diagrams which aredistributed to project members for review and comment. Supporting procedures such as librarian rules and proceduresare also included.MORE GENERAL.. 1MORE DETAILEDThis diagram is the 'parentof that diagram - PONA 42Figure 2.6:SADT model structureNATO UNCLASSIFIED- 24 -
NATO UNCLASSIFIED- 25 AC/243(Panel-8)TR/7Volume 2la-yInputs to the techniqueInformation on system context (why the system isrequired) is needed to initiate the analysis. The analystsmust obtain information on system functions, inputs,controls, outputs, and design and operating constraints,as they proceed through the analysis.Outputs of the techniqueThe output of the technique is a system requirementsspecification, including SADTr diagrams, which showthe system functions, the function inputs, controls.resources, and outputs, and the logical flow of informationand material between them. The specification thusidentifies the mechanisms needed for the system concept.When to useBy definition, the technique is most suitable for the requirements definition phase of a project, (the preliminarysystem studies phase and concept formulation). This can include the requirements definition for-acomputcrsimulation such as SAINT (5.2) or other networking models, which can occur later during system development Thetechnique can also be used to document an existing system prior to upgrade.For human engineering purposes the technique could follow a mission analysis, or be derived directly from thestatement of requirements. It should precede detailed tasks analyses and workload analyses. If SADTr' is being usedfor system software development, then it may be possible to use it as the basis for human engineering studies.AdvantagesDisadvantagesSADTIm supports the systematic definition ofSADTr diagrams show only the input and output flowrequirements. It provides a management and accounting between functions. They do not show sequential functiontool, and is an effective way of obtaining consensus about flows or times. Thus SADT'" does not provide all ofthe requirements for a project Wallace, Stockenburg and the information required to produce a network model ofCharette (1987) argue that SADT"1 is the first of three operator tasks (see Floyd. 1986). Additional analysis isessential steps in a unified method for developing systems. necessary.The technique permits the specification of systemrequirements with the minimum of redundancy. Itrepresents the allocation of resources within a system, andprovides an effective basis for trade-off decisions, to studyfuture system capabilities and improvements, and toidentify system tasks and task dependencies. Thedocumentation of function resources also facilitates thestudy of reversionary-mode operation, because the impactof the "failure" of a specific resource can be studied easily.Related techniquesThe recommended limit of not more than six boxes perlevel can limit the scope of the representation, so that, atlower levels, concurrent functions may not berepresented on the same diagram.One user cautions that the "viewpoints" used to developthe requirements are not unique. Thus the analysisreflects a specific viewpoint, and could be biased.SADTrm is a development of the basic form of function analysis. The Controlled Requirements Expression (CORE)technique developed and used in the UK is closely related (System Designers, 1986). Also related are the StructuredDesign approach of Yourdon (1989), Structured Analysis of De Marco (1979), Essential System Analysis ofMcMenamin & Palmer (1989), and Information Systems Work and Analysis of Change (ISAC) developed byStockholm University (Lundeberg, Goldkuhl, & Nilson, 1981).NATO UNCLASSIFIED- 25 -
- Page 88 and 89: NATO UNCLASSIFIEDACM43(Panel-g)T1-7
- Page 90 and 91: NATO UINCLASSII ri.uACP243(Panei-8)
- Page 92 and 93: NATO UNCLASSIFtiEUACI243(Panei-8)TR
- Page 94 and 95: AC1243(Panel-8)TRnVolume I- 78 -.al
- Page 96 and 97: ANNEX I toA~43(Panei-9)TRf7-Volume
- Page 98 and 99: ANNEX I toAC/243(Panei-8)1=7 -Volum
- Page 100 and 101: ANNEX Ito6Aca41(Pane}-8)TRn7VolumL
- Page 102 and 103: ANNEX I toAC43(Pane-8TR7 - 8 -Volum
- Page 104 and 105: N1 A l O oJN k-~ L i-* 3 3 1 i- XAN
- Page 106 and 107: NATO UNCLASSIFIED. aNORTH ATLANTIC
- Page 108 and 109: N A T OU N C L A S S I F I E DREPOR
- Page 110 and 111: NATO UNCLASSIFIEDACQ243(Panei-88)TR
- Page 112 and 113: AC243(Panel-8)TR7-Volume 25.6 NASA
- Page 114 and 115: N A T O U N CLASIF l IE DAC/243(Pan
- Page 116 and 117: ACP243(Panel-8)TRn 2.Volume 2INTROD
- Page 118 and 119: N ATO UN CLA .3 -c,,i! EAC/243(Pane
- Page 120 and 121: NATO UNCLASS.IFIED-AC/243(Panel 8)T
- Page 122 and 123: AC/243(Panel 8)TR/7 -8 -Volume 21.2
- Page 124 and 125: AC/243(Panel 8)TR/7 10Volume 2weath
- Page 126 and 127: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 128 and 129: N A I UU N k L A A a Ir I DAC/243(P
- Page 130 and 131: NATO UNCLASSIFIEDMAC/243(Panel 8ITR
- Page 132 and 133: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 134 and 135: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 136 and 137: N ATIO U N C LA . 3 i F L- < D-AC/2
- Page 140 and 141: NATO UNCLASSIFIEDAC/243(Panel 8TR/7
- Page 142 and 143: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 144 and 145: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 146 and 147: -NATO UNCLA,)irrILUAC/243(Panel 8)T
- Page 148 and 149: N A T O U N (.LA5\ 1I r i iL-AC/243
- Page 150 and 151: NATO UNCLASSIFIED EAC/243(Panel 8 T
- Page 152 and 153: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 154 and 155: NATO UNCLASSIFIEDA-AC/243(Panel 8)T
- Page 156 and 157: NATO UNCI ASSIFIEDC/-43(Panel 8)TR/
- Page 158 and 159: NATO UNCLAS.SIFIEDAC/243(Panel 8)TR
- Page 160 and 161: NATO UNCLASSIFIED 2AC/243(Panei 8)T
- Page 162 and 163: NATO UNCLASSIFIEDAC/243(Panel 8')TR
- Page 164 and 165: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 166 and 167: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 168 and 169: NATO UNCLASSIFTEDAC/243(Panel 8)TR/
- Page 170 and 171: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 172 and 173: NATO UNCLASSIFIEDAC/243(Panel 8 TR/
- Page 174 and 175: NATO UNCLASSIFIEDAC/24 3 (6PanelVol
- Page 176 and 177: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
- Page 178 and 179: NATO UNCLASSIFIEDAC/243(Panel 8'tTR
- Page 180 and 181: N ATO UNCLASSIFIEDAC/243(Panel 8')T
- Page 182 and 183: NATO UNCLASShi Ih I t LUAC/243(Pane
- Page 184 and 185: NATO UNCLASSIFIED,AC/243(Panel 8 TR
- Page 186 and 187: NATO UNCLASSIFIEDAC/243(Panel 8)TR/
NATO UNCLASSIFIED- 25 AC/243(Panel-8)TR/7Volume 2la-yInputs to the techniqueInformation on system context (why the system isrequired) is needed to initiate the analysis. The analystsmust obtain information on system functions, inputs,controls, outputs, and design and operating constraints,as they proceed through the analysis.Outputs of the techniqueThe output of the technique is a system requirementsspecification, including SADTr diagrams, which showthe system functions, the function inputs, controls.resources, and outputs, and the logical flow of informationand material between them. The specification thusidentifies the mechanisms needed for the system concept.When to useBy definition, the technique is most suitable for the requirements definition phase of a project, (the preliminarysystem studies phase and concept formulation). This can include the requirements definition for-acomputcrsimulation such as SAINT (5.2) or other networking models, which can occur later during system development Thetechnique can also be used to document an existing system prior to upgrade.<strong>For</strong> human engineering purposes the technique could follow a mission analysis, or be derived directly from thestatement of requirements. It should precede detailed tasks analyses and workload analyses. If SADTr' is being usedfor system software development, then it may be possible to use it as the basis for human engineering studies.AdvantagesDisadvantagesSADTIm supports the systematic definition ofSADTr diagrams show only the input and output flowrequirements. It provides a management and accounting between functions. They do not show sequential functiontool, and is an effective way of obtaining consensus about flows or times. Thus SADT'" does not provide all ofthe requirements for a project Wallace, Stockenburg and the information required to produce a network model ofCharette (1987) argue that SADT"1 is the first of three operator tasks (see Floyd. 1986). Additional analysis isessential steps in a unified method for developing systems. necessary.The technique permits the specification of systemrequirements with the minimum of redundancy. Itrepresents the allocation of resources within a system, andprovides an effective basis for trade-off decisions, to studyfuture system capabilities and improvements, and toidentify system tasks and task dependencies. Thedocumentation of function resources also facilitates thestudy of reversionary-mode operation, because the impactof the "failure" of a specific resource can be studied easily.Related techniquesThe recommended limit of not more than six boxes perlevel can limit the scope of the representation, so that, atlower levels, concurrent functions may not berepresented on the same diagram.One user cautions that the "viewpoints" used to developthe requirements are not unique. Thus the analysisreflects a specific viewpoint, and could be biased.SADTrm is a development of the basic form of function analysis. The Controlled Requirements Expression (CORE)technique developed and used in the UK is closely related (System <strong>Design</strong>ers, 1986). Also related are the Structured<strong>Design</strong> approach of Yourdon (1989), Structured <strong>Analysis</strong> of De Marco (1979), Essential System <strong>Analysis</strong> ofMcMenamin & Palmer (1989), and Information <strong>Systems</strong> Work and <strong>Analysis</strong> of Change (ISAC) developed byStockholm University (Lundeberg, Goldkuhl, & Nilson, 1981).NATO UNCLASSIFIED- 25 -