NFT 770-7^

'P sjierenCiÊl]

fee fñM ;.S-.10 - RTy FM 770-78

FIELD MANUAL

>■7

YSTEM
ENGI BRING
Jß

ys ï ■
tiviow
the Jtoï 01 w
aTTN’ MiW ^ « ' /
ATrN
Boom’ 1Äbili
i R513,' Poatcgoa /
!\ .o Wosbiagto®# ^
a g03l®

í /¿^;E *DaUARTE.RS, DEPARTMENT OF THE ARM\Y

^ APRIL 197Í'
Af

1
^nno-'^

TlT I.C

MS - t
ViC
▼ Kl»KM«OMC
>5
J
\
f' (

N AMC
«>>
Gfc

D (k %
3fr‘ZAT o««

\ Æ3 D x£om
N AMC

OA# AMI ZAT IOM TtLZAMOMK

USASCAF FM 4S5 BOOK CARD

1 OECS4
f_
'i'-
^ \

,x

f: /

w i
 ' i

-FM 770—78

FIELD MANUAL HEADQUARTERS

NO. 770-78 } DEPARTMENT OF THE ARMY

WASHINGTON, DC, 27 April 1979

SYSTEM ENGINEERING

* Paragraph Page
CHAPTER 1. INTRODUCTION
Purpose and Scope ! 1-1 1-1
n
Historical Perspective ! 1-2 1-1
» Objectives 1-3 1-2
y Implementation 1-4 1-2
Executive Overview } 1-5 1-3

if
Publication Improvments
2. THE SYSTEM ENGINEERING PROCESS
General
Input Requirements
System Engineering Process Steps
1-

2-
2-2
2-3
2-2
2-5
System Elements 2-4 2-7
Functional Areas 2-
3. SYSTEM ENGINEERING MANAGEMENT
General : 3-
Planning the System Engineering Effort 3-2 3-1
Assignment of Responsibility and Delegation of Authority 3-3 3-3
System Engineering Management Control Methods 3-4 3-3
Relationship of System Engineering Process to Configuration Management 3-
Chapter 4. A SYSTEM IMPLEMENTATION METHOD
General 4-
System Engineering Documentation 4-2 4-2
APPENDIX A.REFERENCES A-l
B. THE SYSTEM ENGINEERING MODEL B-l
C. GLOSSARY C-l

-c

w
-

/•X

*This manual supercedes TM 38-760, 20 Nov 73, and TM 38-760-1, 30 Nov. 73

J
 1

. ^
- r

-’A
r ' FM 770-78

CHAPTER 1
INTRODUCTION

1-1. Purpose and Scope stand Army system engineering; however, this man-
ual may not be used as the basis for any contractual
a. This manual describes a system engineering requirement or action.
process and presents guidelines for system engineer- d.
ing management which will satisfy those regulations, to discriminate on the basis of sex when the words
«
directives, and standards which contain policy for the “he” or “she” appear; they are intended to include
u
application of system engineering. System engineer- both the masculine and feminine genders.
ing is performed for projects, systems, or items
* designated a major program under the provisions of 1-2. Historical Perspective
AR 70-1. The process is consistent with and comple- a. When weapon development programs were rela-
mentary to DA Pam 11-25, Life Cycle System tively simple to manage, engineering effort could be
Management Model for Army Systems. It may be directed by a few top managers. Communications
performed for nonmajor programs, based on the between participants were uncomplicated; functions
expected complexity of the program or weapon sys- and responsibilities were easily stated; and decision-
tem interfaces. The manual presents a means for making in regard to cost, performance, and schedule
integrating the efforts of each technical and manage- goals were fairly straightforward. User needs were
rial specialist in the design and development of a adequately covered in a one-volume model specifica-
total, balanced system. It contains guidelines for the tion and a one-volume contract. As state-of-the-art
identification of tasks and responsibilities for imple- advanced, science and engineering expanded along
menting the system engineering process. It provides highly specialized functional lines, acquired increased
doctrine for the education of Army personnel in the importance and complexity, and required more so-
concept of system engineering and its management. phisticated management.
It is not the purpose of this manual to prescribe or b. The problems of communication, coordination,
imply the organizational structure, management direction, and control of these specialties and among
methodology, procedures, or form of documentation geographically separated personnel have become in-
used to implement system engineering. creasingly severe. Some specialists are grouped into
b. The system engineering methodology described “functional” organizations to coordinate the state-of-
r herein is provided for use by all agencies concerned the-art across more than one program and to time-
with the conception, development, acquisition, field- share between programs. In other instances, special-
ing, and modification of both project-managed and ists are divided into program-oriented organizations,
nonproject-managed Army materiel systems and end or a compromise bilateral organization may be adopt-
i.
items. New programs requiring design effort and full ed, i.e., vertical program and horizontal function.
A -
integration of technical/scientific disciplines will bene- With advanced and increasingly complex new pro-
fit by following the guidelines within this manual for grams, there is need for increased rigor in the
arriving at engineering decisions. Managers of on- following technical and managerial activities:
going programs with unacceptable cost, performance, (1) Control of the design interfaces among sys-
or schedule status will find that the techniques, rigor, tems, equipment, personnel, facilities, and computer
and formats of this manual can serve as a diagnostic programs.
tool for exposing causes of deficiencies and provide a (2) Use of trade-off analysis techniques in alloca-
data base for engineering and management decisions. tion of functions, selection among design approaches,
c. This manual provides guidance for in-house and resolution of conflicting design objectives and
system engineering. Where used, the term “contrac- constraints.
tor” also means Government agency when system (3) Assurance that the performance specifica-
engineering is performed in-house. This manual may tions, detail design, and production data packages are
be made available to contractors to help them under- consistent with the fundamental mission require-

1-1
FM 770-78

merits and with balanced consideration of such factors b. Ensure that the definition and design of the
as producibility, operability, supportability, reliabil- system or equipment item are conducted on a total
ity, safety, and compatibility with interfacing sys- system basis, reflecting equipment, facilities, person-
tems, equipment, personnel, facilities, and computer nel data, computer programs, and support require-
programs. ments to achieve the required effectiveness in accept-
able risk, cost, and schedule considerations.
c. The development of solutions to the problems of
communications, direction, and control requires me- c. Integrate the design requirements and related
thodical, analytical approaches to the development of efforts of reliability, maintainability, integrated logis-
total systems. These approaches are termed system tics support, human factors engineering, health, safe-
engineering. The sequential and iterative method for ty, and other specialties with respect to each other as
top-down development of a product and its technical well as into the engineering effort.
program task elements is known as the system d. Ensure compatibility of all interfaces within the
engineering process. The total management effort is system, including the necessary supporting equip-
termed system engineering management. These may ment and facilities; and to ensure the compatibility *

be defined as follows: and proper interface of the system with other sys-
(1) System engineering. The transforming of an tems and equipment that will be present in the-
VJ
operational need into a description of system perfor- operational environment.
mance parameters and a system configuration. e. Establish, control, and maintain an effective
work breakdown structure throughout the life of the
(2) System engineering process. The repetitive system/project in accordance with applicable r
four-step method for developing program and design directives.
requirements. /. Evaluate effects of changes on overall system
(3) System engineering management. The man- performance, effectiveness, schedule, and cost; and to
agement process of coordinating the engineering and ensure that all affected activities participate in the
technical effort within a project or program. evaluation of changes.
d. The total design process encompasses system
g. Provide a framework of coherent system re-
analysis, definition and synthesis of requirements,
quirements to be used as performance, design, and
preliminary design, and detail design. System analy-
test criteria; and to provide source data for develop-
sis is the analysis and transformation of materiel
ment plans, contract work statements, specifications,
requirements into a theoretical model with quantita-
test plans, design drawings, and other engineering
tive terms, and the manipulation of the model in
documentation.
simulation of the operational environment. Definition
and synthesis of requirements is the translation of h. Measure and judge technical performance for the
performance objectives of a selected system approach timely identification of high risk areas and other
into design criteria (design-to requirements) for the
individual elements which will comprise that system. i. Document major technical decisions made during
Preliminary design develops the design approach for the course of the program.
the system and its elements based upon the criteria
provided by definition and synthesis of requirements. 1-4. Implementation
4
Detail design translates the design approach into a
manufacturing configuration which can be produced The following factors should be considered in imple-
-r
and supported within the state of existing or economi- mentation of system engineering:
cally achievable manufacturing technology and sup- a. System engineering requires mutual under-
port capability. System engineering integrates the standing and support among the system engineers,
engineering effort throughout the design process. senior management, and higher authority. The rigor,
documentation, and integration may require substan-
1-3. Objectives tial procedural changes.
b. Implementators of system engineering should
The objectives of the system engineering process and have diversified backgrounds of engineering experi-
the system engineering guidelines presented in this ence and an understanding of the relationship of the
manual are to— engineering specialty program to the design process.
a. Ensure that the engineering effort c. Without expertise in system engineering, formal
is fully
integrated, and to reflect adequate and timely consid- training of personnel is essential prior to implementa-
eration of design, test and demonstration, production, tion. Improper or poorly founded implementation
operation, and support of the system/equipment. may be expensive and reduced in effectiveness.

1-2
F
FM 770-78

1-5. Executive Overview 1-6. Publication Improvements

Executives of Army organizations involved in the Reporting of errors, omissions, and recommendations
development of materiel systems and end items may by the individual user for improving this publication
gain a general understanding of system engineering is encouraged. Reports should be made on DA Form
theory and management practice through reading 2028 (Recommended Changes to Publications) and
chapters 1 through 3 of this manual. In addition to the forwarded direct to Commandant, US Army Logis-
first three chapters, project and journeyman engi- tics Management Center, ATTN: DRXMC-SLS-
neering personnel should be familiar with chapter 4 EDD, Fort Lee, Virginia 23801.
and appendix B.

it

''i -

1-3
 1

-f
r
FM 770-78

CHAPTER 2
THE SYSTEM ENGINEERING PROCESS
v
2-1. General performance requirements for accomplishing mission
objectives; (2) Synthesis of combinations of system
а. A system may be defined as a composite of
$ elements capable of performing and/or supporting an elements to fulfill the function performance require-
operational role. The definition is insensitive to sys- ments; (3) Evaluation of the synthesis in terms of
tem size or complexity; it applies equally well to a time, life cycle costs, and performance, resulting in a
decision as to the preferred combination of system
large weapons system or a simple personnel/machine
system. The five possible elements which may com- elements and (4) Description of each element in the
prise the system are equipment, facilities, personnel, combination selected. The steps of the process and
A procedural data, and computer programs. Not every figure 2-1 are described in detail in paragraph 2-3.
' 5
system has all of these elements, but every system d. As shown in figure 2-2, every system must be
consists of a combination of some or all of them. The produced, tested, and deployed, following which it is
individual system elements are described more fully operated and provided logistics support. All function
in paragraph 2-4. performance requirements, therefore, are derived
б. No two systems are alike in their developmental from the needs of these functional areas. It follows
requirements. Regardless of system size or complex- logically that the system elements are identified and
ity, however, there is a uniform and logical process developed to meet the performance requirements
for arriving at engineering decisions. The process derived from the functional areas of operations,
converts input requirements (user need) into output logistics support, test, production, and deployment.
information which describes the optimal combination For example, the functions which must be accom-
of system elements which will satisfy that need. The plished for successful performance of the mission
overall process is described in the balance of this (operations functions) generate the requirements for
paragraph. Subsequent paragraphs develop this de- operations equipment, facilities, computer programs,
scription in terms of input requirements, functional personnel, and procedural data. Each of the other
areas, steps of the process, and system elements. functional areas generates requirements for their
c. The system engineering process is a elements.
respective system network of
r actions with very close interrelationships. As illus- e. Figure 2-3 shows the system engineering pro-
trated in figure 2-1, these actions are grouped into cess iteratively applied to the interrelated functional
the four steps: (1) Function analysis, which includes areas of operation, logistics support, test, production,
\ -
the determination of functions and their function and deployment. These functional areas are described

INPUT
REQUIREMENTS
|_ FUNCTION
ANALYSIS
SYNTHESIS 0— EVALUATION
AND
DECISION
DESCRIPTION
OF
SYSTEM
ELEMENTS

-©*-
Figure 2-1. The system engineering process.

2-1
 1
FM 770-78

FUNCTIONAL AREAS

l
^RODUCTION^ TEST J(DEPLOVNENT)( °¡^™ ) (OPERATIONS)

PERFORMANCE
REQUIREMENTS

(EQU,PHENT)(^^) (FACILITIES) ( (f"0^1)

r
SYSTEM ELEMENTS

Figure 2-2. Sources of requirements for system elements.

in paragraph 2-5. Each of these applications of the g. Although the functional requirements that are
process is accomplished to define and optimize the analyzed in the succeeding cycles are based upon the
combination of system elements needed to satisfy the characteristics of the operational elements, this does
requirements of that functional area. These applica- not imply that the operation cycle is completed to the
tions of the process are functional cycles. The initial ultimate detail level of description before the other
application of the process is addressed to the oper- cycles are initiated. At each level of definition from
ations requirements of the system. The inputs to this the system level down to the component level, the
“operations” cycle are the mission requirements, requirements imposed by logistics support, test,
operational environment, system constraints, and production, and deployment are considered in system
mèasures of effectiveness which have been initially optimization. At each level, the process is accom-
established by prior systems analysis. The output of plished for each of the functional cycles to the extent
this cycle consists of the description of an optimized necessary to identify risks, achieve delineation of
combination of system elements for the performance system elements and product elements of the work
of operational functions. This description is complete breakdown structure, and to validate the decisions
only when the inputs from all engineering disciplines which must be made at that level. Appendix B
and specialty programs have been integrated. describes the iterations of the system engineering - r
/. In the subsequent functional cycles shown in process as applied to the various functional areas
figure 2-3, the system engineering process is applied during each of the life cycle phases of a typical
to the logistics support, test, production, and deploy- operational systems development program.
ment requirements imposed by the selected combina-
tion of system elements. The production and logistics 2-2. Input Requirements
support cycles are concerned with the requirement to a. Introduction. Effective application of the system
produce and maintain equipment and facilities. The engineering process is dependent upon complete and
test and deployment cycles, however, are concerned clearly stated input information. This information is a
with the requirements imposed by all of the system product of systems analyses and various studies
elements. For example, personnel, computer pro- which establish the objectives and major characteris-
grams, and procedural data, as well as the equipment tics and constraints of the system. In early stages of
and facilities, require testing. The outputs of these the program, the input information is normally at a
cycles of the process are the descriptions of the gross level; it is expanded and refined as the system
logistics support, test, productin, and deployment engineering process is applied to definitize require-
elements. ments. This may create demands for additional input

2-2
r
FM 770-78
INPUT REQUIREMENTS
• MISSION
• ENVIRONMENT
• CONSTRAINTS OUTPUT
• MEASURES OF DESCRIPTIONS
EFFECTIVENESS OPERATIONS
ELEMENTS

SYSTEM •EQUIPMENT
OPERATIONS
ENGINEERING • FACILITIES
CYCLE
PROCESS • COMPUTER PROGRAMS
• PERSONNEL
• PROCEDURAL DATA

LOGISTICS SUPPORT
ELEMENTS
SYSTEM • EQUIPMENT ILS -
SUPPORT ENGINEERING • FACILITIES PLAN
CYCLE PROCESS • COMPUTER PROGRAMS
• PERSONNEL
• PROCEDURAL DATA

TEST
ELEMENTS

• EQUIPMENT
SYSTEM COORDINATED
• FACILITIES
TEST ENGINEERING TEST PLAN .
• COMPUTER PROGRAMS
CYCLE ' PROCESS
• PERSONNEL
• PROCEDURAL DATA

PRODUCTION
ELEMENTS

SYSTEM •EQUIPMENT PRODUCTION

PRODUCTION
'I - ENGINEERING • FACILITIES PLAN
CYCLE
PROCESS • COMPUTER PROGRAMS
• PERSONNEL
• PROCEDURAL DATA

DEPLOYMENT
ELEMENTS

SYSTEM • EQUIPMENT
DEPLOYMENT FIELDING
ENGINEERING • FACILITIES
CYCLE PLAN
PROCESS • COMPUTER PROGRAMS
• PERSONNEL
• PROCEDURAL DATA

Figure 2-3. The application of system engineering process to functional areas.

2-3
 'I
F«fl 770-78

from various concept sources. Close liaison between sary for each pertinent parameter of natural physical
the materiel developer and the using/support agen- environment, such as temperature, humidity, vibra-
cies is necessary to ensure adequacy of input. Inade- tion frequency, radiation, light, wind, and geography.
quacies which detract from the potential usefulness of Parameters which describe operational environ-
the system increase cost and delay deployment. The ments, e.g., enemy threat levels, must also be stated
four initial inputs to the system engineering process in specific values.
are mission, operational environment, system con-
d. System Constraints. System constraints origi-
straints, and measures of effectiveness.
nate from policy, experience, budget limitation, and
b. Mission. Input information describing the opera- prior analysis. These constraints usually affect the
tional mission must be sufficient to permit recognition characteristics and composition of the system as itp
of major functions and functional requirements to be elements are being derived in the synthesis portion of
met by the system. Where multiple missions are to be the system engineering process. Examples include
performed, each is described and anticipated mission the use of Government-furnished equipment, adher-
mixes are stated. The prime missions are those which ence to established logistics support concepts, confor- n
justify acquisition of the system. There will also be mity to current skill codes, specified system life, or
specified ancillary missions such as the training mis- the stipulation that certain types of equipments must
sions which the system is to fulfill to maintain a high not be used. Most of the hardware-oriented military i-
state of operational readiness in peacetime. Such specifications and standards contain constraints
missions should be so specified that their impact on which are input information to the system engineer-
design must be considered in the application of the ing process at the time of synthesis. In addition,
system engineering process. For example, during a there are definite constraints on the employment of
period of 10 years in a cold war training environment, personnel within a system based on safety engineer-
combat equipment may participate in regular training ing, the limits of human performance, and the avail-
and field exercises to the extent that much of it may ability of certain skills in the Army manpower pool.
be processed through several overhaul cycles. Analy- Constraints upon other system elements are generat-
sis could indicate that training demands exceed de- ed whenever personnel/machine interfaces are intro-
sign requirements imposed by operational mission duced in the system. Identification of these
profiles. Under these circumstances, the impact of constraints and their potential impact on system
training will be of the greatest significance, and could design require early input from human factors
result in selection of entirely different approaches. engineering.
Input information should be screened rigorously to e. Measures of Effectiveness.
ensure that the total system objective is adequately (1) Each decision made within the system engi-
defined and is consistent with the system identifica- neering process must be guided by the standards of
tion and interface information. To ensure proper measurment for evaluation of the various parameters
delegation of system engineering work, the nature of involved in the decision. To provide these standards,
interfaces at the boundaries of the system must be measures of effectiveness are established for the
identified early in the process. Detailed definition of system. All requirements stated for the system
functional and physical interfaces are quantified later should be related to some measure of effectiveness.
in the routine of the system engineering process. (2) A measure of effectiveness is a particular
Input information describing the operational mission
is contained in the Mission Element Need Statement
value of system effectiveness pertinent to one or - r:
more mission objectives. A measure of effectiveness
(MENS), the Letter of Agreement (LOA), and the is related to the inherent value or utility of the
Required Operational Capability (ROQ/Letter Re- system; it may or may not involve cost-effectiveness.
quirement (LR). In military systems, the measures of effectiveness
c. Operational Environment. The system performs should be based upon the mission objectives. They
under both internal and external environmental con- may be related to any or all of the effectiveness
ditions. The internal conditions are self-induced, e.g., factors of availability, dependability, and capability.
electronic compartment temperatures. The factors To be useful in decision making, a measure of
related to these conditions are derived with the effectiveness must be either quantitative, e.g., the
system engineering process. External environmental maximum attainable speed under stated conditions,
factors derive from the external universe in which the or probabilistic, e.g., the probability that a system
system must perform. These factors must be fur- can respond to and accomplish a specific mission
nished as input information. Generalized statements, objective.
such as “all-weather capability” or “hostile environ- (3) The basis for optimizing decisions changes as
ment”, are not adequate. Specific values are neces- a project progresses through its life cycle phases.

2-4
r
FM 770-78

During the Alternative Systems Concept Phase, the the performance requirements. These functions and
purpose of analysis and decision is to select two or their performance requirements provide a common
more cost-effective technical approaches to accom- denominator of selection and design criteria for the
plish stated objectives and to select broad logistics system elements, and initially identify areas where
support concepts. Cost-effectiveness analyses must trade-offs between input requirements and engineer-
consider both acquisition and operating costs. In the ing development require future consideration. The
Demonstration and Validation Phase, with the techni- function analysis step consists of three interrelated
cal approaches and the basic logistics support con- activities, described as follows:
cepts established, decisions are concerned with
allocation of performance capability to individual (1) Function identification. System objectives
elements of the systems, optimization of specific are analyzed to identify those functions which must
parameters within the systems, and selection of the be performed to satisfy the objectives of each func-
optimal system. In the Full-Scale Engineering Devel- tional area. Each function, i.e., characteristic action,
* opment Phase, with a cost a fixed factor, the bases of the system is identified for all specified modes of
for optimization become- producibility and contract usage in all specified environments. No-go, emergen-
incentives (when applicable). Measures of effective- cy, and consequent alternative functions are also
ness may change with the life cycle phases. identified. Each function of’the system is described,
including a statement of beginning and ending condi-
2-3. System Engineering Process Steps tions, i.e., inputs, outputs, and interface require-
a. Process Steps. The system engineering process ments (both intrásystem and intersystem), and
“V steps of function analysis, snythesis, evaluation and whether associated life-cycle costs are expected to be
decision, and description are described separately in sensitive to incremental changes in the performance
the following paragraphs. In application, however, requirements. Functions are indentured and identi-
these steps are interacting and interdependent. Fig- fied from top down so that subfunctions are recog-
ure 2-1 shows the relationship and interaction of the nized as part pf larger functions. Functions are
system engineering process steps. Function analysis arranged in their logical sequence so that any speci-
(Block 1), for example, cannot be performed beyond fied operational usage of the system can be traced in
the level of gross fiinctions without considering the an end-to-end or closed-loop path. Paths which are
synthesis of system elements (Block 2) or alternative operational alternatives are identified. When more
system elements, and verifying their capability of than one candidate functional arrangement is under
accomplishing the assigned functions; therefore, func- evaluation, (i.e., subject to subsequent selection),
tion analysis and synthesis are performed virtually in each is depicted and identified. Records are main-
concert. At each level, however, the synthesis must tained in order to document the rationale for accep-
be responsive to functional requirements. A good deal tance or rejection of each alternative, and for the
of evaluation in the form of analytical and engineering identification of a function as having an expected
judgment is involved in the combined function analy- sensitivity to system life cycle cost for incremental
A sis/synthesis activity in selection of the technically changes in the system performance requirements.
feasible design alternatives. The evaluation and deci- Similar functions are suitably cross-referenced to
sion activity shown as Block 3 in figure 2-1 ultimately assist in the recognition of a common synthesis
V. results in selection of the preferred combination of solution. Subfunctions also are derived in an iterative
"-'I system elements. Prior to final decision, the evalua- process, together with the determination of perfor-
tion performed in Block 3, to include an analysis of mance requirements and the synthesis of progressive-
risk, may require that new functional approaches be ly lower level system elements. At any level of detail,
examined, additinal design approaches be synthe- a function must be stated in purely functional, i.e.,
sized, . or changes to the input requirements be action, terms, and must not be stated in terms of its
considered by the using agency. design solution at the same level. For example, if
b. Function Analysis. After verification of the propellant must be transferred, the function is ex-
adequacy of initial input information, the first step in pressed as TRANSFER PROPELLANT. It is not
the system engineering process is function analysis. good practice to express the function as PROVIDE A
The objective of this step is to define a baseline of PROPELLANT PUMP which presupposes the
functions and function performance requirements means of accomplishing the action; however, it is
which must be met in order to adequately accomplish often desirable to express the function in terms of the
the operation, logistics support, test, production, and synthesis corresponding to a higher level function,
deployment requirements of the system, and to e.g., in the case above, the function TRANSFER
identify those functions where system life cycle costs PROPELLANT is based upon the prior synthesis
are expected to be sensitive to incremental changes in decision to use a liquid propellant.

2-5
FM 770-78

(2) Function performance requirements analy- collectively meet the time criteria requirements of
sis. A set of performance requirements is developed the total functional sequence. Time analyses per-
for each function. These requirements represent the formed on time critical functions should determine
acceptable level of performance for the accomplish- whether automatic or manual methods are essential;
ment of that function. Function performance require human performance may or may not be involved.
ments are derived in an iterative process with the These analyses are used to derive time constraints
development of the functions, synthesis of the system application to performance and design requirements.
design, and evaluation performed through trade-off They also become a factor in trade-off decisions
studies and application of established measures of where time is an important factor.
effectiveness for the system. Function performance
requirements are continually' reviewed against the c. Synthesis.
original requirements established for the system to (1) Synthesis is conceptual design. It is the point
ensure that system requirements are adequately in the system engineering process at which engineer-
fulfilled. All function performance requirements are ing creativity and technology are brought to bear in
stated in sufficient detail for direct use as criteria for the creation of a system or design concept to meet
hardware design as well as for equipment operation, stated requirements. One of the main objectives of
personnel skills and tasks, facility operation, comput- the system engineering process is to ensure that
er programing, display of procedural instructions- design concept includes full cognizance of function
/data, and logistics support. The requirements are performance requirements, system constraints, and
functionally oriented, and should not presuppose effectiveness criteria, and that system elements are
hardware or other elements which might be devel- given proper consideration in arriving at a design
oped subsequently. Performance requirements define concept.
the input and output status of the function sufficiently (2) Synthesis is performed initially to postulate
to ensure end-to-end or closed-loop compatibililty of possible technical approaches and, supporting each
functional behavior. Requirements are dimensioned technical approach, one or more system concepts
in measurable terms and/or stated in go/no-go criteria (arrangements of system elements which will satisfy
which can be verified by analysis, test, and/or demon- the function performance requirements). Later, dur-
stration. Performance requirements must be trace- ing successive iterations of the system engineering
able to the analysis by which they were derived and process, one or more design concepts will be synthe-
to the higher order of functions. In allocating the sized for each system concept. The configuration and
requirements to lower level^ functions and subsequent arrangement of system elements and the techniques
equipment design, activities performing function re- for their use are portrayed in any suitable form, such
quirements analysis should effect integration and as schematic block diagrams. The purposes of such
optimization to achieve completeness and compatibil- portrayals are to depict a complete response to the
ity of all engineering efforts. functional need which meets the initial input require-
ments, to depict compatibility between the elements
(3) Time requirements analysis. An analysis is of the system and interfacing system, to permit
performed to determine the time requirements of traceability between the elements and their function-
functions or functional sequences in which time is al origin in the operational usage, and to ensure
critical to mission success, safety, utilization of re- complete and comprehensive change control.
sources, minimization of downtime, and/or increasing (3) Synthesis must, therefore, consider the re-
availability. Not all functional sequences require time sults of various technical and design studies as well as
analysis—only those sequences in which time is a the requirements delineated by function analysis.
critical factor. The following are some examples of Since synthesis involves all system elements (not
the types of functions and functional sequences that merely equipment), it requires the inputs or partici-
are time critical: pation of all the technologies and disciplines that have
(а) Functions affecting system reaction time. a bearing on the system or design concept. Engineer-
(б) Time critical activities during mission. ing creativity is a key factor in the accomplishment of
(c) Mission “turn-around” time effective synthesis. Exploration of alternative ap-
(d) Time countdown activités. proaches which are beyond the obvious can be par-
(e) Functions requiring time analysis to deter- ticularly rewarding. Synthesized solutions should
mine optimum equipment and personnel utilization. take into cognizance the latest technological develop-
For time critical function sequences, the time re- ments in the areas of design, manufacturing, and
quirements are specified with tolerances. Times support methods.
should then be allocated to subfunctions so as to (4) Within each synthesized solution, characteris-
determine that sequential and concurrent actions will tics of the equipment, facilities, personnel, and proce-

2-6
r •

FM 770-78

dural data are balanced in accordance with the usage of all system elements, and their effectiveness
established measures of effectiveness. In effecting in achieving functional performance. The description
this balance, it is necessary to interrelate the charac- of the system and its individual elements becomes
teristics of system elements in terms of technical progressively more definitive as the program pro-
performance and effectiveness parameters. As sub- ceeds through the life cycle phases. At the beginning
systems develop and performance/design require- of each phase, the descriptions must be sufficient to
ments are allocated to system elements, data is provide the proper baseline for technical decisions
developed and retained to show the parametric inter- and contracting purposes. These descriptions define
relationship between subsystems within the system; the product elements of the work breakdown
between various system parameters or constraints, structure.
such as reliabilty, maintainability, supportability, (2) The engineering data which describes the
weight, operating cost, and downtime, and the rela- individual elements must be such that it controls the
tion of each to total system and mission design, development, test, production, and deploy-
* requirements. ment of equipment and facilities; the selection and
(5) Portrayal of the synthesized system in terms training of personnel; and the development of proce-
of its elements will, after selection has been made by dural data and computer programs. The description
the evaluation and decision step, provide a source of data may be in such form as specifications, design
data for equipment design documentation; interface descriptions, schematics, layouts, detailed drawings,
control documentation; consolidated facility require- personnel and training requirements data, and engi-
ments; contents of procedural handbooks, placards, neering reports. It may also include physical and
■i
and similar forms of instruction/data; task loading of mathematical models and computer programs.
personnel; consolidated computer programs; the (3) It is not possible to specify precisely the
specification tree and product elements of the work depth of data detail required for any phase of a
breakdown structure. project. In the early phases, however, the description
d. Evaluation and Decision. data shold be confined to performance requirements
(1) Evaluation is continual in order to select the so as not to constrain creative design unduly, but to
best combination of system elements to meet the allow subsequent engineering activities as much flexi-
mission objectives and support requirements. To aid bility as the program objectives will permit.
in risk assessment, and to avoid undue engineering
sophistication, each decision should have as its objec- 2-4. System Elements
tives a balance among performance, schedule, and The elements of a system are identified as equipment,
total system life cycle cost. facilities, personnel, prodedural data, and computer
(2) Evaluation and decision are always required programs. This means that any item required to
to establish that a feasible and adequate design produce, test, deploy, operate, and support the sys-
concept has been synthesized. Whenever alternate tem can be categorized as one of these system
functions and/or synthesis solutions are evolved, elements. Such categorization provides a logical and
evaluation and decision are accomplished through the convenient boundary for the structure or constitution
conduct of trade-off studies. This step cannot be of the system. Employment of some combination of
completed until the synthesis and functional analysis these elements in accordance with established doc-
of each alternative are reconciled. trine is the only means whereby the mission objec-
\ - (3) An effectiveness model may be developed to tives can be accomplished. While every system may
relate design parameters to established measures of not contain all five elements, all systems are made up
effectiveness. The outputs of such a model can of a combination of some or all of them. The following
provide assistance in choosing one of several synthe- (a through e below) describe the system elements and
sized combinations of system elements, and can discuss the role of system engineering process in
facilitate, investigation of the effects of parameter defining the requirements for each element.
changes on the overall system effectiveness. a. Equipment.
(4) Evaluation leads to a decision which selects a (1) This includes all equipment items required by
recommended system design concept; determines the system. In addition to the basic operational
that additional analysis, synthesis, and/or trade-off equipment required to perform the assigned mission,
studies are required to make a selection; or estab- it includes operational and maintenance support
lishes that the state-of-the-art in technology does not equipment; test equipment required by test pro-
provide an acceptable solution. grams; any special equipment (such as special trans-
e. Description. portation or installation and checkout equipment)
(1) The description required to step
deploy the system;
produces any special, unique, or
engineering
data that defines the configuration, arrangement, and long lead time equipment (such as factory tooling)

2-7
 1

FM 770-78

required to produce the deliverable equipment; and positions, and the duty positions into MOS’s. The
special trainers or training aids required to train resultant MOS’s provide the basis for selection of
personnel in the operation and support of the system personnel and the determination of training require-
and its equipment. ments. This task grouping is an activity of the human
(2) The system engineering process is used to factors engineering specialty and provides the per-
define the design requirements for all items of equip- sonnel element input to conceptual design.
ment needed by the system. The function perfor- c. Facilities.
mance characteristics which each equipment item (1) These include Government buildings and
must have are developed by function analysis. During other structures (landing pads, launch pads, control
synthesis, the function performance requirements center, etc.) required to operate, maintain, and, in
and all other design requirements and constraints some instances, produce the system and to conduct
that are imposed on the system or developed by Government testing that is specifically oriented to the
engineering analyses are integrated to provide a system. Many Army systems do not have fixed
complete set of “design-to” requirements for each operational facilities, but most systems and materiel *
equipment item. These equipment items are identi- items have requirements for maintenance and sup-
fied as the product elements of the work breakdown port facilities.
structure. (2) It is normal practice that the design and V

b. Personnel. construction or modification of Government facilities

(1) All systems involve the interaction of trained is accomplished under the cognizance of the Army
personnel with equipment. In certain systems, such Corps of Engineers. However, identification of the r
as HAWK, specially trained personnel, identified by requirements for new facilities or facility modifica-
systems peculiar military occupational specialty tions imposed by a new system or equipment item is
(MOS), are an integral part of the operational system. the responsibility of the system or equipment devel-
These personnel are specialists who are selected, oper. System engineering is concerned with the
trained, classified, and assigned as “components” of identification of these requirements. During the syn-
the system. On the other hand, many weapons/equip- thesis step of the system engineering process, the
ment systems developed for both tactical and nontac- facility characteristics necessary for the performance
tical units are used by personnel already trained in of functions and the facility requirements imposed by
the use and maintenance of various other items of the system equipment and personnel are identified.
materiel; an example is the SHERIDAN/SHILLE- These characteristics and requirements provide crite-
LAGH weapon system. This required the develop- ria to the Corps of Engineers for the design of new or
ment or modification of doctrinal concepts for modified facilities.
employment of the total system. The identification of d. Procedural Data. These data include all forms of
the various changes to procedural data, training instructional material to be used by personnel in
courses, MOS, and quantitative personnel require- producing, testing, deploying, operating, and main-
ments necessitated by the introduction of the new taining the system or equipment item. The material
equipment was part of the development process. It is may consist of field manuals, technical manuals, test
also a major interface among the materiel developer, procedures manuals, associated lists, drawings, diag-
the combat developer, and the training developer- nostic schematics, production process specifications,
/trainer. Maintenance and support personnel may and various display media. The system engineering
include Department of the Army civilians (DAC) or process defines the tasks which personnel must per-
contractor as well as military persons. form in accomplishing the system functions and the
(2) In the development of completely new sys- procedures for performing the tasks. The functionally
tems or new materiel items to be added to existing oriented instructional material and those pertaining
systems, system engineering, together with integrat- to support are developed as part of the integrated
ed logistics support and human factors engineering, is logistics support activity based upon the tasks/proce-
concerned with identifying the tasks, skills, training, dures defined by the system engineering process.
and numbers of personnel required to operate, main- Guidance for total system application within the
tain, support, test, and deploy the system or equip- conceptual and doctrinal employment envisaged by
ment items. In the application of the system the combat developer is normally defined in organiza-
engineering process, the tasks and skill requirements tionally oriented doctrinal and training literature or
related to the individual functions involved in oper- in field manuals specifically addressing the system.
ation, logistics support, test and deployment are e. Computer Programs. Whenever computer pro-
identified. The human performance tasks are formu- grams are required for production, test, operation, or
lated into task groups, and task groups into duty logistics support of the system, the system engineer-

2-8
r

m 770-78
ing process defines the capabilities and input and ply of ammunition and other consumables. Preventive
output requirements of such programs. Mandatory maintenance includes scheduled inspection, mainte-
procedures for development and documentation of nance, and those servicing functions (lubrication,
ADP system specifications are described in AR 18-1. refueling, time-phased parts replacement, and oth-
Computer resources, to include software, are includ- ers) described in AR 310-25. Corrective maintenance
ed as elements within subsystems of the work break- includes such functions as fault isolation, repair,
down structure; their requirements validation, risk adjust, and overhaul, at all maintenance levels. Lo-
analysis, configuration management, life cycle plan- gistics support functions are integrated into the
ning, milestone definition, demonstration criteria, design effort in accordance with AR 700-127, Inte-
contract deliverables, and post deployment support grated Logistics Support.
are as prescribed in DODD 5000.29. c. Test Functions. These are actions necessary to
determine to what extent the system and/or system
» - 2-5. Functional Areas elements are capable of performing basic mission/per-
The system engineering process is applied iteratively formance/support requirements and to determine
to the functional areas of mission operation, logistics product conformation to specification and technical
support, test, production, and deployment. The mis- requirements. Such functions include test require-
sion operation and logistics support functional re- ment determination, testing, test support, and test
quirements generate the need for all of the system result evaluation during all life cycle phases. These
elements that will constitute the delivered system. include test and evaluation during research and
•\
The functions involved in the other areas generate development of materiel (AR 70-10), quality assur-
the requirements for the additional elements needed ance during product acquisition (AR 702-9 and AR
to produce, test, and deploy the system. 702-10), user field tests, experiments and evaluations
a. Mission Operations Functions. These repetitive (AR 71-3), and operational tests and evaluations
actions performed on and by a system that has been (OTE) (AR 71-3). Test procedures must conform to
turned over to the user and that are required to the Single Integrated Development Test Cycle policy,
accomplish the given mission objectives and support under which the developer, contractor, test agencies,
the system in operation. Examples of mission oper- and evaluators share data, thus reducing redundant
ations functions for a deployed system would -include testing.
receiving alert indications, positioning or transport- d. Production Functions. These are actions neces-
ing the equipment, checking out the system, launch- sary to transform design into a capability for efficient
ing or firing operations, and accomplishing other and economical production of equipment and facility
mission operations, including target acquisition and elements of the system. The functions include such
identification and data reduction necessary to accom- actions as materials ordering, materials handling,
plish the basic mission. Examples of mission support fabrication, processing, process control, assembly,
functions are fueling and supplying of ammunition inspection, test, preservation, packaging, storage,
and other consumables. shipping, and disposition of scrap, salvage, and waste
r b. Logistics Support Functions. These are actions materials.
necessary to ensure continuing normal system readi- e. Deployment Functions. These are fielding ac-
ness (preventive maintenance functions), or to return tions necessary to initially transport, receive, depro-
a failed system element to readiness (corrective cess, install, test, checkout, provide logistics support
maintenance functions). They include actions such as for, and, as required, emplace, house, or store a
transport between maintenance activités and storage system or system element at the user location.
of unserviceable and repaired equipment, resupply of Materiel fielding concepts are described in AR 700-
repair parts, calibration of test equipment, and resup- 127.

*
2-9
 1

- •
■4

«
I
r

FM 770-78

CHAPTER 3
SYSTEM ENGINEERING MANAGEMENT

3-1. General project, regardless of size or complexity. Appendix B

describes the application of this process to the type of
a. The term “System Engineering Management project depicted in the life cycle system management
(SEM)” as used in this manual encompasses the model. System engineering must be tailored or modi-
management of the system engineering process fied for application to projects which deviate from
(SEP) and the integration of all engineering activities
that depicted in the model.
and technical aspects of the system/project from (2) Tailoring is performed to both breadth and
receipt of a Mission Element Need Statement depth. Tailoring in breadth includes the elimination
(MENS) through delivery of the system or item to or addition of system elements, particular system
the operational inventory. It includes management of engineering activities, functional areas, and/or life
the system engineering process, described in Chapter cycle phases. Tailoring in depth involves decisions
2, as well as management of preliminary and detail concerning the level of detail required to identify,
design activities and planning of the test program anddescribe, and specify the “design to” requirements.
of system performance evaluation. This chapter does The depth of system engineering varies from project
not prescribe to managers the methods by which they to project in relationship to complexity, uncertainty,
will manage their projects or programs; rather, it project urgency, and the willingness to accept risk.
points out the salient features of system engineering (3) One example of tailoring could involve the
management and presents a perspective of the role of addition of a functional area. In a system that
system engineering management within the total requires continual, intensive training to maintain a
spectrum of system/project management. high state of readiness, training functions and the
b. System engineering management is one of the impact of their performance requirements on design
major functions of project management. It is closely become extremely significant. Decisions based on life
interrelated with configuration management, inte- cycle costs and effectiveness may be required to
grated logistics support, and cost/schedule planning provide the best balance between the use of opera-
and control. There are various levels of system tional equipment for training or the development of
engineering management, ranging from the top level specific training devices. Such considerations may not
management exercised by the materiel developer to be limited to the training of operation and support
the most detailed level to which the performance and personnel in the usual sense, but may need to take
design requirements of system elements are con- into account the impact of maneuvers and field
trolled by the contractor or equivalent Government training exercises that are required to train com-
agency. The levels of system engineering manage- manders and their staffs. For such a system, it may
ment responsibility for any specific project are de- be that training requirements will be sufficiently
fined by the contract work breakdown structure and important to justify the application of the system
contract work statements. They are organized along engineering process to the functional area of training.
lines of the basic managerial functions of planning, (4) The breadth of the system engineering effort
organizing, and controlling, and conclude with a for systems which do not require computer programs
discussion of the relationship of system engineering or facilities would be limited or tailored, as necessary.
to configuration management, integrated logistics (5) A combat vehicle or aircraft system develop-
support, engineering specialty programs, and cost/
ment program which specifies the use of an existing
schedule control mechanisms.
engine would be modified or tailored in depth. De-
tailed consideration of the functions concerned with
3^-2. Planning the System Engineering Effort providing primary power would normally not be
a. Tailoring. required. The system engineering process would be
(1) The basic system
utilized engineering
in the process only
area of power de- to the depth
scribed in chapter 2 is applicable to any development necessary to define functional and physical interfaces

3-1
FM 770-78

with the balance of the system. It will also verify that c. System Engineering Management Plan (SEMP)
the specified engine meets all of the loading condi- (1) SEMP is prepared by each Army develop-
tions required by the mission profile of the ' new ment/production agency directed to accomplish sys-
system. If loading conditions are not met, or should tem engineering as part of a development project and
system performance be determined to be marginal, by each contractor whose statement of work calls for
then a complete application of the process to develop system engineering. A contractor’s SEMP is submit-
an alternative engine would be in order. The scope of ted as a part of the proposal in response to a request
the system engineering process to be applied (i.e., for proposal.
tailoring) is determined by the levels of risk, the (2) The SEMP is a concise top level management
complexity of the decisions required, the state-of-the- plan for the integration of all system activities. Its
art, and other critical areas. Persons directing the purpose is to maKe visible the organization, direction
application of system engineering must be willing to and control mechanisms, and personnel for the attain-
accept proven design procedures evolved from past ment of cost, performance, and schedule objectives.
experience; otherwise, duplication, through system The who, what, when, where, how, and why of the
engineering, may produce costly work which makes evaluation and decision-making authority and rele-
no further contribution to the development effort. vant interfaces must be clearly delineated. The level
of detail presented in the SEMP should be appropri-
b. Cost-Effective Application of System ate to the system life cycle status and degree of
Engineering. system complexity. Use of the SEMP as a manage-
(1) On almost any project, there are technical ment tool must be emphasized; it should reflect good
areas which have varying degrees of potential perfor- management judgment with minimum documenta-
mance and/or cost benefit. Resources should be ex- tion. Consideration of data reporting, data retrieval,
pended on those areas where the payoff potential is data utilization, and data visibility is essential.
the highest. The specific areas will depend upon the (3) The SEMP defines and describes the type and
characteristics of the system, but are usually associ- degree of system engineering management, the sys-
ated with such features as the uniqueness of the tem engineering process, and the integration of
program, the criticality to mission success, the de- related engineering programs. The plan contains
gree of technical risk involved, or the possibility of identification of organizational responsibilities, au-
either increasing performance capability or reducing thority for system engineering management, levels of
operating and/or maintenance cost. control for performance and design requirements,
(2) In applying system engineering to a specific control methods to be used, technical program assur-
project, a major consideration should be the benefits ance methods, control procedures to ensure integra-
to be expected in terms of cost. The cost of system tion of requirements and constraints, and schedules
engineering and its management should be considered for design and technical program reviews. The plan
relative to their potential payoff to the system and also contains a detailed description of the system
the project. This applies both to the types of proce- engineering process to be used, including specific
dures to be used and the depth of detail to which the tailoring to requirements of the system, in-house
process is carried and managed. Neither the rigor nor documentation, trade-off study methodology, and
the depth of the procedure used should be greater types of mathematical and/or simulation models to be
than their worth to the project. For example, the cost used for system and cost-effectiveness evaluations.
of conducting a trade-off study between two alterna- (4) The three parts of the SEMP are concerned
tive design approaches may be greater than the with system engineering management, the system
potential value differential of the alternatives. When engineering process, and engineering specialty inte-
such is the case, conducting a trade-off study would gration. Description of parts one and two are shown
not be cost-effective provided both alternatives fulfill in figure 3-1. References which describe many speci-
the performance requirements of the system. Similar- alities are shown in the same figure.
ly, the relationship between expenditure of engineer- (5) Depending upon system peculiarities, the plan
ing analysis time or testing and level of confidence is should also delineate the special or intensive manage-
usually nonlinear; and, in many instances, the poten- ment aspects of functions and activities critical to the
tial value of increased confidence beyond a certain system objectives. These might include, for example,
level would not warrant the added expenditure. risk analysis and assessment, resource allocation,

(locofrs ?ö§. 3-H, o (foldl-m, ofr A® end! oí fîhès nraairayeil.)

3-2
r

FM 770-78

work elements, trade-offs, program assurance, and specifications. The SRR and SDR are accomplished in
many other specialties. As a top management tool, the Demonstration and Validation Phase.
the SEMP must present the system engineering (c) The preliminary design characteristics re-
management and system engineering process, and view (PDCR) ensures that the preliminary design
relate these to the engineering specialties, activities, approved in terms of equipment, facilities, personnel,
and functions as an integrated plan, rather than as a procedural data, and computer programs is an accept-
composite or summary of discrete subplans. able design solution to total system and configuration
item requirements.
3-3. Assignment of Responsibility and Delegation (d) The design characteristics review (DCR)
of Authority. determines that detail design solutions satisfy the
Organizational responsibilities for system engineer- requirements and design constraints of the develop-
ing management must be established, and functions ment specification.
(e) The functional configuration audit (FCA) is
and lines of communication defined, which will enable
those responsible to control the application of re- the formal examination of functional characteristics
sources and make the decisions necessary to accom- test data for a configuration item, prior to acceptance
plish system engineering in keeping with the project of the prototype, to verify that the item has achieved
directive or the statement of work. For Army agen- the performance specified in its functional or allocated
cies engaged in development/production programs, configuration identification. The PDCR, DCR, and
the organization, responsibilities, and authority are FCA are accomplished in the Full-Scale Engineering
established by Government regulations and direc- Development Phase.
tives. Contractors will specify in the SEMP the (/) The physician configuration audit (PCA) is
organization of their own choosing for the conduct the formal examination of the “as-built” configuration
and management of system engineering. of an LRIP unit of a configuration item against its
technical documentation and functional requirements
in order to establish the configuration item initial
S-4. System Engineering Management Control product configuration identification. Configuration
Methods item is defined in appendix C (Glossary).
a. Design Reviews. (g) The configuration item verification review
(1) System engineering and design efforts direct- (CIVR) is the formal examination (technical audit) of
ed to a product element of the work breakdown the production item to verify conformance to configu-
structure are reviewed to gain visibility and to ration identification (technical data) and performance
determine their technical adequacy in meeting system interfaces within the system. The PCA and the CIVR
requirements. As the system engineering and design are accomplished in the Production and Deployment
effort proceeds through the life cycle phases, the Phase.
reviews become more detailed and definitive. Start- (3)
ing with the review of system and function perfor- engineering and the design that are relevant to the
mance requirements, the reviews progressively progress of the particular phase of the design. They
consider conceptual designs, preliminary designs, and include technical performance measurement and pro-
detail designs. The reviews encompass requirements gram review functions, as appropriate. They cover all
reviews, system design reviews, design characteris- performance requirements, the estimated effects of
tics reviews, functional configuration audit, physical incremental change in the requirements on life cycle
configuration audit, configuration item verification, costs, technical performance measurements to date,
and other design reviews that may be required. The and engineering specialties, such as reliability, main-
schedule and procedures for the conduct of design tainability, safety, human factors engineering, survi-
reviews are included in the system engineering man- vability/vulnerability, electromagnetic interference,
agement plan. standardization, test engineering, quality engineering
(2) Design reviews include the following: and security engineering. Special attention is accord-
(a) The system requirement review (SHR) ed the design integration, engineering specialty inte-
ensures that development effort is proceeding toward gration, and coordination with other program
the objectives in a logical manner and should ensure management functions. These design reviews include,
that adequate consideration has been given to the but are not necessarily limited, to the following:
test, production, deployment,' and logistics support
constraints. (a) Statement of requirements and/or allocated
(b) The system design review (SDR) ensures requirements.
that design approaches are responsive to system (ft) Design synthesis and evidence of meeting
performance objectives established in the system the requirements.

3-3
 1

FM 770-7®

(c) Drawings, schematic diagrams, models, and Phase whenever design and development are being
other data. carried out for product improvement changes or
(d) Development and qualification testing pro- modifications.
gress and data. (2) Planning for technical performance measure-
(e) Cost and schedule status, as reflected, or ment is included in the assessment plan which is
cost and schedule measurements for all tasks contrib- referenced in the system engineering management
uting to completion of the design phase. plan. The assessment plan establishes how product
(/) Problem analyses, anticipated changes, and assessments will be accomplished. It describes the
corrective action plans for deficiencies, scheduled times at which assessments will be per-
ft. Technical Program Reviews. formed, the objectives of each assessment, selection
(1) In addition to design reviews, periodic re- of performance parameters to be measured and
views are conducted for the purpose of determining tracked, forecasts of the parameter values to be
whether the planned technical program should be attained through the planned technical program,
altered as uncertainties are disclosed, eliminated, or planned methods of assessing the achievement of
reduced during the progression of the technical pro- planned performance parameters in the product de-
gram. For in-house projects, these reviews are the sign through engineering analysis and/or testing,
equivalent of a quarterly Review and Analysis identification of the data required to conduct such
(R&A). These reviews are a planned part of the assessments, and the acquisition of the required data
system engineering management effort, not a reac- from tests or analysis. For each assessment, the plan
tion to program exigencies. They are used to seek specifies the conditions under which tests or other
opportunities to reduce or redirect program effort to evaluations will be conducted, expected results ex-
effect economies in budget and time as well as pressed quantitatively, and methods of evaluation
requirements to increase or redirect program effort employed.
to overcome weaknesses which may develop in the (3) The technical parameters to be reported and
planned program. tracked are determined through the identification of
(2) Technical program reviews are concerned technically critical areas from review of performance
with task elements of the work breakdown structure specification requirements and performance incen-
(WBS). They may be scheduled to coincide with the tives and their relationship to system measures of
design reviews or technical performance measure- effectiveness. System elements and their perfor-
ment events for the corresponding product elements mance parameters to be tracked by the contractor or
of the WBS. Performance measurement seeks to the procuring activity are identified in the contract.
estimate, measure, and forecast actual design and In addition, the contractor is obligated to provide
system performance against planned values. Program visibility of all design deficiencies that effect system
reviews seek warranted changes to the planned performance whether or not the parameters are
technical program effort, but not to design require- identified for tracking. At the completion of each
ments or characteristics except where the design evaluation, results are recorded for comparison with
reviews have indicated favorable trade-offs between planned values. Variances of results from planned
the performance requirements and estimated life values are analyzed. The analysis will include evalua-
cycle costs. tion of the impact of variances on the technical
c. Technical Performance Measurement. program, on schedule, and on cost. System effective-
(1) Technical performance measurement (TPM) is ness and summary performance status reports are'
defined as the product design assessment which prepared from the basic parameter status data pro-
estimates through engineering analyses, or measures vided by technical performance measurements. Fig-
through tests, the values of essential performance ure 3-2 illustrates the information flow for technical
parameters of the current design of WBS product performance measurement and system effectivenss
elements. It forecasts the values to be achieved assessment. It includes TPM work breakdown ele-
through the planned technical program effort, mea- ments, master parameter list, planned parameter
sures differences between achieved values and those profiles, summation models, parameter status track-
allocated to the product element by the system ing and forecast, records of achieved parameter
engineering process, and determines the impact on profiles, system effectivenss and summary perfor-
system effectiveness. Technical performance mea- mance status report, and problem analysis and cor-
surement is initiated during the Demonstration and rective action. The first four items are the outputs of
Validation Phase after design-to requirements of the planning and replanning efforts. They form the inputs
product elements have been défined. It continues to technical performance measurements and assess-
throughout the Full-Scale Engineering Development ments. These items can be initially accomplished
Phase, and into the Production and Deployment during the Demonstration and Validation Phase of

3-4
 FM 770-78

elements for the purpose of technical performance

PROBLEM
ANALVSIS S measurement. Figure 3-3 illustrates a typical project
I C/S KS'WS~) CORRECTIVE WBS for a development program. Numbering of
! I ACTIONS
components and their associated drawings is most
TPM WORK SYSTEM ■ commonly done as illustrated, although the MIL-
BREAKDOWN EFFECTIVENESS _ J
ELEMENTS STATUS REPORT STD-482 procedure may be used. Figure 3-4 sche-
matically portrays the combination of WBS elements
into TPM elements.
SYSTEM (5) The master parameter list is established prior
SUMMATION
MODELS
to the design of performance tracking and status
RAS, reporting procedures. A technical performance pa-
TRS
rameter is a characteristic of an element representing
RECORDS OF
MASTER ACHIEVED
how well it must perform its intended function. It is
PARAMETER PARAMETER determined on the basis of sensitivity of each param-
LIST PROFILES eter. The technical parameters which are selected for
tracking and status reporting must be meaningful and
measurable through application of the system effec-
tivness model. The identification of parameters is
closely related to requirements allocation, and can be
¡PROGRAM accomplished with formulation of requirements allo-
I SCHEDULE
cation sheets (RAS) or test requirements sheets
PARAMETER
PLANNED
STATUS
(TRS). Parameters of an element selected are those
PARAMETER
PROFILES
TRACKING & directly contributing to selected parameters of a
FORECAST higher level element, or which represent the overall
contract requirement for the element. Examples of
the former group of parameters are component
weights, hydraulic power demand in units per minute
Figure 3-2. Technical performance measurement and and electric power demand in watts, a drift rate of an
system effectiveness assessment information flow. inertial guidance unit, and computer accuracy. Exam-
ples of the latter group of parameters are the gross
the program. Interfaces with other pertinent man- weight, engine power, system reliability, range, and
agement procedures are shown on the figure. The last reaction time. The mast parameter list contains all
four items are the outputs of technical performance measurable technical performance parameters for
measurements and assessments. These elements are each of the elements. It is usually arranged in.
described in (4) through (11) below. accordance with the WBS.
(6) A planned parameter profile is the time-
(4) The work breakdown
phased goals elements for technical
of the parameter values of a WBS
performance measurement are selected from the element. These goals are the expected achievements
contract WBS. The WBS is developed as indicated in of the development efforts on the element. A planned
MIL-STD-881A and AR 70-32. TPM elements are parameter profile may be a constant value which was
primarily product oriented. Each selected element used as the design criterion as a result of the
must possess measurable technical characteristics requirment allocation. In this case, the planned pa-
that contribute significantly to the technical perfor- rameter profile would appear as a horizontal line
mance or effectiveness of the total system. Since the against time. Other performance characteristics may
project WBS is a combination of deliverable configu- trend upward or downward. Figure 3-5 illustrates
ration items and task elements, it is sometimes two planned parameter profiles of contract specifica-
difficult to associate measurable technical perfor- tion requirements or allocated requirements. The
mance with each one of the WBS elements. Although planned goals may have to undergo revisions from
it may be possible to make the TPM elements time to time as the development progresses. The
identical with those of the project WBS product original planned goal should be retained as a refer-
elements, it would often result in duplication of ence. If not retained as a goal after replanning, the
parameters to be tracked and reported on the same value should be retained for variance analyses and
subsystems and configuration items. It is, therefore, revised goals should be traceable to it. Examination
logical to combine some WBS elements and work of the work progress should ensure that contract
packages into a specification tree-like structure of objectives are met.

3-5
FM 770-78

PROGRAM

TOTAL SYSTEM
1000

CONTRACTOR

CONTRACTOR TASKS
*
OTHERS

PRIME SECONDARY PECULIAR SYSTEMS

TRAINING SYSTEMS
MISSION MISSION SUPPORT T&E PROV MGT
EQUIPMENT EQUIPMENT EQUIPMENT DATA
1010 ' 1020 1030 1040 1050 1060

A, A.

MAJOR SYSTEMS ELEMENTS

X X X X X X X X X X
1011 1012 1013 1014 1015 1016

Z X X X
SUBSYSTEMS &
* TASK ELEMENTS

X X X X X X X X
1014A 1014B 1014C

COMPONENTS AND/OR
LOWER LEVEL
ELEMENTS
AS REQUIRED
X X X X X XX X X X
1014B01 1014B02 1014B03 1014B04 1014B05

X As

Figure 8-3. Typical work breakdown structure.

3-6
 FM 770-78

PROGRAM

TOTAL SYSTEM Mission & System Level

Performance and
MISSION
System Effective- Environmental Require-
ness Measures ments

Subsystem Level
Performance, Environ-
XXXX XXXX XXXX
mental and Interface

£ Requirements

“N

XXXX XXXX XXXX XXXX

Component Level
Performance, Environ-
mental and Interface
<? Requirements

XXXX XXXX XXXX

A,
Figure 3-k- Typical work breakdown elements for TPM.
FM 770-78

I I I I I I I I
CONTRACT OR ALLOCATED
REQU REMENT

ORIGINAL
PLANNED
oc
PRO :ILE

REPLANNING
<c
oc
Q.

M M J J A
CALENDAR TIME

TÏT
NEW REQU REMENT

ORIGINAL REQU REMENT

LU

«c
a.

(PLANNED PARAMETER PROFILES COINCIDE WT

REQUIREMENT & CHANGE OF REQUIREMENT)

M M A S 0 N

CALENDAR TIME

Figure 3-5. Planned parameter profile.

3-8
 FM 770-78

SECTION I. System Designation

SECTION II. System Effectiveness Summary

a. Narrative

b. Summary Chart (Figure 3-8)

SECTION III. System Effectiveness Analysis Plan

a. Mission

b. System Description

1. General Configuration

2. System Block Diagram

3. Mission Profile

4. Mission Outcome (s)

c. Definition of Characteristics/Master Parameter List

d. System Effectiveness Model/System Summation Models

e. System Effectiveness and Performance Parameter Requirements

SECTION IV. Parameter Matrices and Achieved Parameter Profiles

a. Availability

1. Requirements Narrative

2. Status Narrative

3. Matrix Chart/Profile

b. Dependability (Mission Reliability)

/

1. Requirements Narrative

2. Status Narrative

3. Matrix Chart/Profile

Capability (Kill Probability)

1. Requirements Narrative

2. Status Narrative

3. Matrix Chart/Profile

SECTION. V. Summary of Significant Changes, Problems and Corrective Actions

Figure 3-7. System effectiveness status report—topical outline.

3-11
 3-12
FM 770-78

SYSTEM EFFECTIVENESS AND

SUMMARY PERFORMANCE STATUS REPORT

RESPONSIBLE ACTIVItr DATE

IDENTIFICATION CHARACTERISTICS REQUIREMENTS STATUS VARIANCE

WORK
PRIMARY PERFORMANCE CHARACTERISTICS ESSENTIAL POC/LR
TPM SPECIFICATION STATU: BASED STATUS BASED ON STATUS BASED ON
OR PERFORMANCE PARAMETER REQUIREMENT TEST RESULTS
ELEMENTS REQUIREMENTS ON PREDICTION OPERATIONAL USE

.NOTES:

Figure 8-8. System effectiveness and summary performance status report.

. \

\ y
 FM 770-78
(7) The work breakdown structure described examples of parameter status tracking reports of twoi
above is a framework for technical performance parameters of a typical system. Periodic technical
allocation from which performance standards are performance summary reports which compare actual
established for each element in order to achieve total to planned technical performance will provide a
system performance requirements specified in the record of the degree of technical success of the WBS
contract. The summation models established during elements. Although only summary data is submitted
the planning process are used with the current to the procuring agency, traceable technical perfor-
estimate or measurement of the technical parameter mance data for work breakdown structure elements
values to compute the total system performance may be requested if required for additional analysis.
estimate at each reporting period. Through these This data will provide system management with
summary level reports, both the procuring agency visibility by which they may forecast system progress
and contractor management may quickly identify and possible trouble areas. It would also provide a
deviations from the planned parameter profile. A record for predicting changes in the planned TPM
simplified example of this process can be described by baselines as additional trade-offs are made during
the parameter of weight. It is obvious that if weight evolution of the design.
is a parameter at the top summary level, a simple (9) The accumulation of performance parameter
arithmetic summation of the actual weight of every status data over a period of time constitutes the
part of the total system must not exceed the total acheived parameter profile. Many parameter profiles
allowable weight for the system being developed. for lower level elements may be constructed directly
Each work breakdown structure element would be from the status data; others, for higher level ele-
allocated a specific or maximum weight. During the ments, can be derived through appropriate summa-
design, development, and test phases, the weight of tion models from parameter values of lower elements.
each WBS element would be reported and accumulat- Most of the technical performance parameters for the
ed through the summation model to arrive at a total overall system cannot be measured directly until the
system weight. It is not necessary that the planned system tests are conducted. Achieved parameter
weight parameter be constant over development time profiles may be added to the planned parameter
to meet the guaranteed or required weight of the profile charts as illustrated in figure 3-6.
total system. Management may recognize that weight
historically increases during the system life cycle, and (10) System effectiveness status reports and
planning may allocate a lesser value to permit growth summary performance status reports can be assem-
during system design, development, and test. Other bled from the basic parameter status data and ar-
parameters will require much more complex summa- ranged according to the needs of recipients. This data
tion models. For instance, reliability and maintainabi- can be sorted according to the performance param-
lity summation models utilize information on mean eters at the system level, parameters which contrib-
time beteen failure and mean time to repair of ute to system level performance, elements of other
subsystems and components, typical mission profiles, levels, or responsible engineering organizations. Sys-
intended mission mix, and maintenance man-hours tem effectiveness and summary performance status
per operation hour. Techniques for developing these reports that are required by the procuring agency
models have been formulated in the respective engi- shall be as stated in the contract. Figure 3-7 is a
neering specialty areas. sample format for this report. Figure 3-8 is a sample
format for either summary performance or system
(8) The fundamental effort of technical perfor-
effectiveness status reporting.
mance measurement is tracking the status of perfor-
mance parameters at the summary level and in terms (11) Reporting is required periodically, generally
of system effectiveness for additional analysis. This at higher levels of the WBS. It is a requirement that
data must originate from the organizations responsi- the contractor utilize this system in the performance
ble for the design or test of each of the WBS of his technical management, and récords of his
elements. Status of the parameters for each element internal actions should be maintained within the
may be established by credible design analysis, simu- contractors facility. Whenever a plan is changed, or
lation, environmental test, prototype test, engineer- deviation from planned technical performance values
ing test, service test, or field test. Periodic status is reported, traceable records will be maintained. The
information of the accomplished parameter values are procuring agency may require the contractor to
submitted to the appropriate management organiza- discuss the records and technical performance mea-
tion for analysis and reporting. At this location, raw surement reports at levels of the work breakdown
data may be grouped according to parameters, ele- structure within the TPM lower than the reporting
ments, systems, and organizations. Figure 3-6 shows levels. The capability for examination on an exception

3-9
r
FM 770-78

CONTRACT OR'ALLOCATED
REQUIREMENT

ORIGINAL
PLANNED
PARAMETER

"PROFILE-
REPLANNING

ACHIEVED
VALUE

JFMAMJ JASOND
CALENDAR TIME

NEW REQ UIREM EN

PARAMETER

ORIG NA REQUIREM EN

ACHIEVED
VALUE

(PLANNED PARAMETER PROFILES COINCIDE WI

REQUIREMENT & CHANGE OF REQUIREMENT)

MAM J J A S 0 N D

CALENDAR TIME

Figure 3-6. Achieved parameter profiles.

3-10
 FM 770-78

basis by the procuring activity of lower work break- engineering process interfaces with configuration
down structure elements will give the contracting management through technical data. An output of the
activity knowledge of the WBS elements which cause system engineering process is technical data which
the technical performance deviation. This assurance establishes baselines to which configuration manage-
of visibility will give the procuring activity confidence ment procedures are applied throughout the life
in the reprogramming necessary, to meet the contract cycle. This is done by established procedures which
requirements. Development of the technical perfor- identify the complete technical description of the
mance measurement and assessment system is re- system as it evolves, control the documents that
quired during the Demonstration and Validation provide this identification, and continually update the
Phase of the system life cycle. The contractor may documentation to reflect the approved configuration
propose an internal technical performance measure- of the system. The output of the system engineering
ment system, or use the technical performance mea- process in the Alternative Systems Concept Phase
surement procedure set forth in this manual. During provides the functional configuration identification
evaluation of the contractors proposal, the procure- (FCI). This identification translates the LOA into
ment agency will evaluate the technical performance performance and design requirements, design con-
measurement and assessment system and ensure that straints, inter- and intrasystem interfaces, test and
it possesses the capabilities set forth in the contract. evaluation requirements, and functional areas of the
system which are documented in the system specifica-
3-5. Relationships tion at the end of the phase. During the Demonstra-
o. Relationship of System Engineering Process to tion and Validation Phase, the system engineering
Configuration Management. process provides the allocated configuration identifi-
(1) A fundamental concept associated with sys- cation (ACI), which consists of a series of develop-
tem/project development is the use of three baselines ment specifications that define the functional and test
to ensure an orderly transition from one major requirements for each major configuration item.
decision point to the next in the system life cycle. These development specifications will be used to
This concept is illusrated in figure 3-9. The system specify requirements for the design, development,

ALTERNATIVE PROD.
DEMONSTRATION
FULL SCALE AND
SYSTEMS AND ENGINEERING
CONCEPTS VALIDATION DEPLOY.
DEV. PHASE
PHASE PHASE PHASE

I I
I
ALLOCATED
PRODUCT
FUNCTIONAL BASELINE
BASELINE
BASELINE (OPTIONAL)
I
FUNCTIONAL
CONFIGURATION
AUDIT

SE BLOCK 41

PHYSICAL
CONFIGURATION
AUDIT

SE BLOCK 45

FUNCTIONAL ALLOCATED PRODUCT

CONFIGURATION CONFIGURATION CONFIGURATION
DOCUMENTS IDENTIFICATION IDENTIFICATION IDENTIFICATION

MIL-STD- SYSTEM DEVELOPMENT PRODUCT

490 SPECIFICATION SPECIFICATION SPECIFICATION

Figure 3-9. Configuration management as related to life cycle.

3-13
FM 770-78
test, and evaluation of the equipment and facility system engineering process and described in the
elements of the system. The requirements stated in baselines define product elements of the work break-
the development specifications encompass the total down structure.
system requirements as stated in the system specifi-
cation. During the Full-rScale Engineering Develop- b. Relationship With Integrated Logistics Support
ment Phase, the system engineering process provides (ILS).
the product configuration identification (PCI), which (1) Guidance and procedures to be used in the
includes product specifications. application of ILS are covered in AR 700-127, TM 38-
710, and TM 38-715. These documents define the
(2) System engineering develops three configura- concept of ILS planning and describe the actions and
tion management baselines during the life cycle. judgments necessary to insure the orderly and sys-
(a) Functional baseline. The functional base- tematic initiation, development, and monitoring of
line is established at the end of the Alternative support planning and implementation of plans for end
Systems Concepts Phase, and normally is concurrent items or systems.
with approval to initiate engineering development or
operational system development. It is established by (2) ILS includes that planning required for the
approval and release of the system specification technical management elements and tangible support
which delineates the system functional requirements. elements which are required for logistics support of
It is prepared in accordance with MIL-STD-490. an equipment item or system. The three technical
(b) Allocated baseline. The allocated baseline is management elements are the engineering element,
established at the end of demonstration and valida- logistics support resource funds, and logistics support
tion. This optional baseline, when used, will govern management information. The elements provide input
the development of selected configuration items that for the system engineering process. The tangible
are part of a higher level configuration item. It support elements receive output from the system
consists of development specifications which result engineering process as follows: support and test
from application of the system engineering process equipment; supply support (repair parts and spares);
during demonstration and validation. When com- transportation and handling; technical data; facilities;
bined, the development specifications must meet and personnel and training. The ILS concept em-
criteria established in the system specification. Ap- bodies an anaylsis of equipment design with the
proval and release of these development specifica- following objectives:
tions establishes this baseline. (а) Earlier consideration of support require-
(c) Product baseline. The product baseline is ments in design and developmnent of new materiel.
established at the completion of the physical configu- (б) Improved maintenance support and re-
ration audit (PCA). This baseline consists of product duced skill requirements.
specifications, process specifications, and material (c) Optimum balance among support elements
specifications. Additionally, system engineering pro- achieved by considering possible trade-offs.
vides engineering drawings and related data to pro- id) All support elements on hand, when
vide a set of documents adequate for the required.
procurement, production, test, evaluation, and accep- (e) Minimum life cycle cost for support.
tance of an item. (3) Interface:
(3) The above baselines serve as system engi- (a) System engineering procedures enable de-
neering management reference points. They repre- termination of system logistics support elements to
sent the progressive development of specifications, the degree of detail appropriate to given points in the
drawings, and associated data. These technical data life cycle. ILS covers the multitude of detailed actions
progress from general requirements to detail require- to be accomplished and procedures to be followed to
ments. They provide a level of control which is ensure preparation of detailed management support
initially a broad scope. Eventually, they are nar- plans and development of total support requirements.
rowed to be more restrictive as the design becomes (b) There must be a flow of information be-
more definitive. A constant closed-loop relationship tween the two activities at various points in the life
must be maintained between established design re- cycle. Certain outputs of ILS activities provide inputs
quirements and design effort, thereby ensuring that to the system engineering process. Certain outputs of
the design effort is at all times directed to meet, the system engineering process provide input to ILS.
rather than exceed or fall short of, total system The primary medium for transfer of this input-output
requirements. The baselines also represent the pro- information data is the Logistics Support Analysis
gressive and evolutionary development of system Records (LSAR) input data sheets and output sum-
documentation. System elements developed by the mary reports.

3-14
 FM 770-78

(c) Logistics support concepts for the system data flow are apparent. Thereafter, with properly
are developed based upon experience, requirements implemented procedures, the rigor of the system
documents, and documentation derived from similar engineering process insures participation of the spe-
systems. These concepts must interface with the cialist at the pertinent points in decision making.
guidance provided by concept and doctrinal studies, (2) As depicted in figure 3-10, system engineer-
and furnish early and continuing inputs to system ing and specialty program interrelationships may be
engineering. represented by three imaginary round tables. At the
(d) The system engineering process provides first table, system engineering is concerned with
the operational data upon which the logistics support conceptual analysis. The specialists in this group
analysis is based. These data provide the engineering contribute candidate concepts which are subject ei-
derived information required in the LSAR sheets ther to acceptance, rejection, or trade-off study
which are used by the logistics support manager to analyses for resolution.
accomplish integration with system engineering. The (3) As data emerges from the first table in the
LSAR data is, in turn, used by the system engineer- form of system engineering documentation, it is
ing process to provide or revise requirements for reviewed at the second table for disciplinary con-
equipment, personnel, facilities, procedural data, and straints and expansion of requirements. Often, the
computer programs in appropriate functional areas. action at the second table will override the action at
(e) Based upon analysis of the design charac-
the first. In this case, the data is returned to the first
teristics of proposed system equipment and facility group for rework. Material which pases through the
elements and upon logistics support concepts, the first two groups goes to the third for execution of
system engineering process is employed to define the downstream responsibilities. It is interesting to note
requirements for and provide descriptions of oper- that specialists at the second table are identified with
ations and maintenance elements. plans, all drafted in conjunction with the activity of
(f) Based upon LSAR data and description of the system engineering process. Some of the special-
the proposed maintenance elements provided by the ists shown may have little or no participation in the
system engineering process, ILS updates the Plan for Alternative System Concepts Phase, but the network
Logistics Support (Section VI) (OAP/AP) to provide is designed to include them later at the appropriate
technical direction and management to the ILS effort. times. A very important participant in all phases in
These plans become progressively more definitive as the designer at the third table who produces configu-
the design and logistics support analysis of equipment rations, layouts, and trade-off study data. The de-
and facility elements of the system evolve. signer is linked very closely with the conceptual
(g) In developing the logistics support ele- specialists from the earliest part of the effort, and in
ments in system engineering, consideration is given later phases, executes the detail design for produc-
to the impact of integrated logistics support upon tion. At this time, the designer is supported and
equipment design and upon system effectiveness and audited by the specialists who earlier prescribed
cost-effectiveness. “design-to” requirements.
c. System E ngineering / Specialist
Interrelationship. d. Relationship of System Engineering to Cost and
(1) Integration Schedule Control
of engineering Mechanisms.
specialties into the
total engineering program is a major objective of (1) Cost is a major consideration every time an
system engineering management. In the earlier engineer or designer conceives possible alternative
stages of a program, system engineers work in solutions to solving an operational problem. In the
conjunction with operations research and operations system engineering process, life cycle costs are con-
analysis specialists to establish appropriate measures sidered along with the design constraints, reliability,
of effectiveness. System effectiveness is normally maintainability, safety, and other parameters and
influenced by factors of reliability, maintainability, engineering specialties.
and other parameters of total system performance. (2) The use of the work breakdown structure
Thus, reliability, maintainability, and other specialty (WBS) as a framework for visibility provides a means
programs are incorproated into the system engineer- of identifying the small pieces (detail system ele-
ing process at logical and pertinent points in time ments) to which life cycle costs are assigned. Cost
with sufficient applicable input data. As the concept control and prevention of cost escalation are directly
grows, contributions of additional engineering spe- tied to constraining the design by identifying the
cialties are brought into the design of the system, risks and life cycle cost implications every time1
specialists can identify the processes of their profes- synthesis of alternatives is accomplished. As each
sions in terms of input and output, and the points of design alternative is considered, including those al-
their linkage with the system engineering process ternatives based on incremental changes in the func-

3-15
FM 770-78

BASIC INPUT
MISSION OBJECTIVES
MISSION ENVIRONMENTS
MISSION CONSTRAINTS
MEASURES OF EFFECTIVENESS

THERMO
ELECTRONICS
DYNAMICS

CONCEPTUAL STRUCTURAL ^ENGINEEFUNGy AERODYNAMICS

ANALYSIS

OTHER MECHANICAL

SE DOCUMENTATION

VALUE
TEST / SAFETY

DISCIPLINARY TRANSPORTABILITY/^ SYSTEM MAINTAINABILITY

ANALYSIS
QUALITY
{ ENGINEERING)
RELIABILITY
ASSURANCE

HUMAN

PACKAGING FACTORS

SE DOCUMENTATION f
FACILITY EQUIPMENT
DESIGN DESIGN

SYSTEM PROCEDURAL
IMPLEMENTATION PERSONNEL
ENGINEERING DATA

COMPUTER
PROGRAMS

DESIGN REQUIREMENTS
OUTPUT

Figure 3-10 System engineering/specialist interrelationships.

3-16
 FM 770-78
tion performance requirements for functions where similar measurement by functional (organizational)
system life cycle costs are expected to be sensitive to cost element. There is also a part of the CPR for
the requirements, the most cost-effective alternative identifying changes to the cost baseline and project-
is identified and selection justification is included in ing the time phasing on the planned cost. Also
the trade-off studies prior to the decision to select a provided is a manpower loading report which permits
particular conceptual design. measurement of personnel utilization against the
(3) Among the interrelationships of management budgeted plan. The CPR includes a narrative which
systems and system engineering, one of the most identifies significant problems, explains major cost
important is that associated with cost/schedule plan- and schedule variances, and addresses their impact
ning and control. The product and service segments and the corrective action taken on proposals. This
of a system are related by system engineering for any information assists the project manager in making
specific project and are defined by the contract work necessary decisions regarding the project. Using
breakdown structure and contract work statements. selected WBS elements, the contractor reports
As shown in figure 3-3, the definition and identifica- planned costs for the work performed versus actual
tion of lower indenture levels, through application of costs for that work. This information is then used to
system engineering and the system engineering pro- update projected costs at completion of the program.
cess, provide the details to which are applied various The projections provide an early indication of the cost
management and control systems and criteria in trend, thereby identifying potential overruns prompt-
order to achieve firm, fixed, credible estimates of ly enough to permit the project manager to take
costs. Some of these are Cost/Schedule Control Sys- effective corrective action. The information contained
tem Criteria (C/SCSC), Contract Cost Data Report- in the Cost Performance Report is also required by
ing (CCDR), Cost Performance Report (CPR), and DOD components in completing the Selected Acquisi-
Cost/Schedule Status Report (C/SSR). tion Reports (SAR), an internal requirement which
(4) System engineering provides an achievable provides program performance measurement infor-
technical foundation upon which costs can be based. mation to the Secretary of Defense and the Congress.
Application of system engineering produces the engi-
neering data that describes all system elements. As (7) The Cost/Schedule Status Report (C/SSR)
the program proceeds through the life cycle phases, provides cost and related data for measuring contrac-
one of the major constraints is the limitation of tor cost and schedule performance against selected
available funds. This constraint impacts in all areas of WBS elements, and includes a narrative which identi-
preliminary design. System engineering identifies the fies significant problems, explains major cost and
product and service segments of the work breakdown schedule variances, and addresses the corrective
structure (WBS). WBS provides the visible frame- action taken or proposed. The C/SSR is a scaled-down
work for cost estimates. It is the summation of costs version of the CPR for use on nonmajor contracts.
applied to the identified segments and components of Where the CPR is used with the C/SCSC, the C/SSR
the WBS that provide firm estimates of the system does not require cost performance reporting on a
cost. The balance achieved among system perfor- functional basis, nor on manpower or baseline report-
mance, cost, and schedules is documented, and its ing. The C/SSR does not give the contractor greater
traceability is available for consideration of the pro- flexibility in the selection of internal cost performance
gram manager on demand at scheduled reviews. measurement techniques, but assists the Government
manager in understanding the derivation and mean-
(5) Cost and schedule performance measurement ing of the reported data.
is accomplished through contractor management con-
trol systems which meet the DOD Cost/Schedule (8) The Contractor Cost Data Reporting (CCDR)
Control Systems Criteria. These criteria require Plan is used to specify requirements for the collection
contractors to measure cost performance in terms of of cost data on selected WBS elements for cost
the work accomplished compared to the resources analysis purposes. It identifies proposed cost informa-
used. They also ensure that contractors are using cost tion coverage for selected contractors and in-house
and schedule control systems which provide both Army activities engaged in the development and
contractor and the Government with adequate visibil- production of the system. This cost data is required
ity and control at all levels of management, using data by the Army to accomplish its cost estimating and
from the same source. analysis functions. The relationship that exists be-
(6) The Cost Performance Report (CPR) pro- tween CCDR and system engineering is that the
vides cost and related data for measuring a contrac- WBS results from the application of system engineer-
tor’s cost and schedule performance against selected ing. Thus, system engineering again contributes to
WBS elements (MIL-STD-881A), and provides a cost control mechanisms.

3-17
 FM 770-78

e. Relationship of System Engineering to Cost and providing confidence that established milestones have
Technical Performance Measurement. been successfully met, that expenditure of resources
(1) System engineering employs engineering has accomplished the objective for which they were
analysis, test, and evaluation to make periodic assess- allocated, and by predicting technical problems that
ments of the status of the technical program in can cause program (project) cost and schedule vari-
achieving the performance parameters it has estab- ances by triggering action to reduce these variances
lished for the product system. These technical assess- before they result in cost and schedule overruns.
ments resulting from TPM, when correlated to cost
and schedule reports, provide the complete status of (3)
the project. They serve to identify any engineering or basis for allocating funds to program tasks against
other technical problems requiring management at- time; and for relating earned value of cost schedule
tention and to forecast the impact on program (pro- control systems to demonsrated values of perfor-
ject) cost, schedule, and utlimate performance of any mance parameters. The information generated by this
out-of-tolerance conditions. interrelationship enables the manager to efficiently
(2) Technical performance measurement (TPM) plan and control the technical program for the design,
supports cost/schedule performance measurement by development, test, and evaluation of the system.

I 3-18
 FM 770-78

CHAPTER 4
A SYSTEM ENGINEERING IMPLEMENTATION METHOD

4-1. General (a) Function identification. In the planned oper-

ation of a potential system there are a large number
a. Implementation. This chapter describes a meth-
of possible functions and functional sequences. The
od and à set of documentation tools for implementing
nature of these functions is dependent upon the
the system engineering process. The procedures and
documentation described here have been utilized mission objectives and varies from system to system.
For the accomplishment of function identification in
effectively in a board variety of programs; however,
the operation and deployment cycles, the basic ana-
other procedures and documentation may be used as
lytical tool is the functional flow block diagram
long as the prescribed objectives of system engineer-
(FFBD). This format allows for a broad selection of
ing are attained. System engineering documentation
functions, and provides a means for depicting func-
is controlled in a manner similar to that used for a set
tional sequences and relationships. On the other
of engineering drawings..
hand, in the functional areas of maintenance, test,
b. Concept of Minimum Documentation. Because and production, there is a smaller number of possible
of the iterative nature of the system engineering functions, and the functional requirements are depen-
process, it is necessary that documentation be held to dent upon the design configuration of the system
a minimum. This concept recognizes that excessive equipment. F or the identification of logistics support,
amounts of formal paper to identify, define, and test, and production functions in their respective
describe the system requirements and solutions will cycles of the process, the following forms are pro-
inhibit timely and conscientious use of the system vided, and may be used to correlate functions to
engineering discipline. The minimum documentation equipment end items, subassemblies and components:
concept emphasizes creative aspects, but is not in- end item maintenance sheet (EIMS), test require-
tended to discourage the use of specialized forms and ments sheet (TRS), and production sheet (PS). Func-
working paper where a clear need exists. tional flow block diagrams may also be used in these
c. Documentation and Document Relationship. cycles if the sequence and relaionship of functions has
(1) Internal documentation is derived from the a bearing on the function analysis.
system engineering process itself. The four system
engineering steps (function analysis, synthesis, evalu- (6) Function perj'ormance requirements analy-
ation and decision, and description) are applied to the sis. In all of the functional cycles of the process, the
five system functional areas (operation, logistics sup- requirements allocation sheet (RAS) is used as the
port, test, production, and deployment) in order to primary analytical tool in conjunction with functional
define the requirements and develop criteria for flow block diagrams and the special purpose docu-
selection and design of the five system elements ments such as end item maintenance sheets, test
(equipment, personnel, facilities, computer programs, requirements sheets, and production sheets. The
and procedural data). RAS serves three-purposes in documenting the sys-
(2) System engineering documentation provides tem engineering process: initially, it is used to record
analytical tools for the process steps as applied to the the performance requirements established for each
functional areas. The documents include the minimum function; during synthesis, it is used to show the
information required at each step of the process to allocation of the function performance requirements
perform that step and to define the system elements. to individual system elements or combination of
The basic documentation is the most frequently used, elements; following evaluation and decision, the RAS
is most adaptable, and will in many cases fulfill all provides the functionally oriented data required for
documentation requirements. The special purpose description of the system elements.
documentation is given as examples of variations on (c) Time requirements analysis. The time line
the basic documents and may be used when they sheet (TLS) is used to perform and record the
serve a need. analysis of time-critical functions and functional se-

4-1
FM 770-78

4-2
FUNCTION ANALYSIS

Function
Function
Synthesis of Evaluation
~ 1
—^r)—► Description of
Performance
Identification Conceptual Sys, & Decision System Elements
Requirements

I
FUNCTIONAL FLOW ”1 REQUIREMENTS 1 CONCEPT TRADE-OFF DESIGN SHEETS (DS)*
BLOCK DIAGRAMS ALLOCATION SHEETS I DESCRIPTION SHEETS STUDY REPORTS
(FFBD)* (RAS)* (CDS)* (TSR)# FACILITY INTERFACE
END ITEM MAINTENANCE SHEETS (FIS)**
SHEETS (EIMS)** TIME-LINE SHEETS SCHEMATIC
TEST REQUIREMENTS (TLS)* BLOCK DIAGRAMS (SBD)*
SHEET (TRS) + *
PRODUCnO_N SHEET_(PSJ_**
FFBD * TMí* CDS* “I
TSR* r os*
DEFINE THE REQUIRE- CONSTRAIN THE DESIGN- SELECT, EVALUATE DEFINE, DESCRIBE AND
IDENTIFY AND SEQUENCE
FUNCTIONS THAT MUST MENTS AND CONSTRAINTS ER TO STOP AT A POINT AND OPTIMIZE PRO- SPECIFY PERFORMANCE,
BE ACCOMPLISHED TO FOR EACH OF THE FUNC- IN THE CYCLE AND CREATE MISING OR ATTRACT- DESIGN AND TEST CRITERIA
ACHIEVE SYSTEM OR PRO- TIONS AND RELATE EACH AT THE GROSS LEVEL A IVE CONCEPTS AND FOR THE SYSTEM ELEMENTS,
JECT OBJECTIVES. DE- REQMT TO THE SYSTEM DESIGN OR SYNTHESIS DOCUMENT THE TRADE- a. EQUIPMENT
VELOP THE BASIS FOR ELEMENTS OF MEETING THE FFBD, RAS, OFF AND SUPPORTING b. FACILITIES
ESTABLISHING INTER- TLS REQUIREMENTS AND RATIONALE. CONSIDERS c. PERSONNEL
SYSTEM FUNCTIONAL a. EQUIPMENT
b. FACILITIES CONSTRAINTS. ALL POSSIBLE d. PROCEDURAL DATA
INTERFACES AND
c. PERSONNEL SOLUTIONS WITHIN THE e. COMPUTER PROGRAMS
IDENTIFY SYSTEM
d. PROCEDURAL DATA SBD * FRAMEWORK OF REQMTS.
RELATIONSHIPS.
e. C0MPÚTER DEVELOP AND' PORTRAY FIS**
EIMS/TRS/PS/ LSAR **
IDENTIFY MAINTE- PROGRAMS SCHEMATIC ARRANGE-
MENT OF SYSTEM EL- IDENTIFY ENVIRONMENTAL
NANCE, TEST AND PRO-
EMENTS TO SATISFY AND PHYSICAL INTERFACES
DUCTION FUNCTIONS ON TLS*
A SPECIFIC END ITEM, SYSTEM REQMTS. BETWEEN EQUIPMENT AND
PRESENT CRITICAL
SUB-ASSEMBLY AND COM- FACILITIES ON AN END
FUNCTIONS AGAINST A
PONENT BASIS ITEM BASIS.
TIME BASE IN THE
REQUIRED SEQUENCE
OF ACCOMPLISHMENT

INDENTURE IS CARRIED TO THE LEVEL

REQUIRED FOR THE SELECTED LEVEL OF * BASIC DOCUMENTATION
ENGINEERING TO IDENTIFY. DESCRIBE ** SPECIAL DOCUMENTATION
AND SPECIFY.

Figure U-l. Basic and special purpose documentation for system engineering.

• • ■ • .. . •
 FM 770-78

quences. In performing time requirements analysis mance requirements are satisfied by the combined
for complex functional sequences, additional tools, system elements, and that such requirements are
such as mathematical models or computer simulation, optimized against system performance requirements
may be needed. Time requirements analysis is per- and constraints.
formed in any or all of the functional cycles of the (2) The system engineering documentation de-
process to determine whether time is a critical factor. scribed in this chapter provides the audit trail for
(d) Synthesis. Two documentation tools accom- traceability. Figure 4-2 portrays an example of the
plish and record the synthesis of design approaches or mechanics used to provide traceability within the
alternative approaches. The concept description sheet system engineering documentation. Prior to synthe-
(CDS) is used to collect the performance require- sis, all requirements and other analytical data are
ments and constraints as delineated by function oriented to functions and are identified by the func-
analysis that apply to an individual subsystem or end tion number to which they pertain. During synthesis,
item, and to describe at the gross level a design system elements or candidate elements are identified
approach for meeting the requirements. The schemaic to satisfy the function performance requirements.
block diagram (SBD) is used to develop and portray After synthesis, all requirements and other design
the conceptual schematic arrangement of system data are oriented to system elements, and are identi-
elements to meet system or subsystem requirements. fied by the appropriate configuration item (Cl) num-
The CDS and SBD are both applicable to all function- ber (or similar identification for other elements).
al cycles and, following evaluation and decision, will
provide the basis for development of descriptions of e. Relation of System Engineering Documentation
system elements. to Other Technical Data.
(e) Evaluation and decision. Since program (1) The documentation described in this chap-
risk and cost are dependent on practical trade-offs ter provides the data required for implementation of
between stated operating requirements and engineer- the system engineering process. This documentation
ing design, trade-offs must be considered not only at is considered internal to the system engineering
the beginning of the program but continually process. Most of the data developed by the process is
throughout development. The trade study report required by other activities engaged in the develop-
(TSR) is used to correlate characteristics of alterna- ment project. Figure 4-3 illustrates in matrix form
tive solutions to the requirements and constraints the multiple application of the data elements con-
which establish the selection criteria for a specific tained in the system engineering documentation for a
trade-off study area. The report also documents the theoretical system. Note that each of the activities
rationale used in the decision process and should marked have a need for the information generated for
present risk assessment and risk avoidance consider- the delineation of the data elements. As systems vary
ations. Other tools, such as analytical or mathemat- and activities in individual plants may or may not
ical models or computer simulation, may be needed have need of data, the entries in the matrix would
and used in accomplishing the evaluation and decision change accordingly. The decision to use data is that of
process. the manager. It is to be noted that without the single
(/) Description. Two forms are provided to source of identifiable data elements as shown in the
describe system elements. The design sheet is used to column on the left, each of the activities would
establish and describe the performance, design, and generate the necessasry data based on its interpreta-
test requirements for equipment end items, critical tion of the requirements. This could lead to signifi-
components, and for computer programs. The facility cant differences in interpretation and to unrelated
interface sheet (FIS) is used to identify the environ- requirements.
mental requirements and interface design require- (2) Data elements included in system engineering
ments imposed upon facilities by the functional and documentation generated by the system engineering
design characteristics of equipment end items. The process are said to be source data; other program
design sheet and FIS provide the basis for the formal documentation, based upon this source data, is said to
identification required for configuration management. be derived documentation. Thus, system engineering
d. Traceability in Documentation. data, in addition to its internal use, provides inputs to
(1) The system engineering process provides external documentation. Figure 4-4 shows the rela-
traceability which, in turn, ensures technical integri- tionship of the basic system engineering document-
ty in application of the system engineering process. tion to the system engineering process and to typical
Technical integrity ensures that the design require- derived documentation. The system engineering pro-
ments for the system elements reflect the function cess may be depicted as a 5 x 5 x 5 with three axes;
performance requirements, that all function perfor- the process steps, the function areas, and the system

4-3
FM 770-78

TIME LINE ANALYSIS

Z.O FLOW
RAS Cl
NO
m
DIAGRAMS
123
2.1 =
2.2

2.1
-cTLJl- 2.4
12.36= 124
2.2

TRADE-OFF STUDY
DESIGN SHEET
CINQ
SCHEMATIC
Cl. NO. 123 123 124
FUNCTTONMT
NO.124 2.1 =
123
4.6“
4.7 =
8.0 =
124

Figure b-2. Traceability in system engineering documentation.

elements. The system engineering documents are format and basic symbols for functional diagrams are
shown opposite the process steps during which they illustrated in figure 4-5.
are generated. The derived documents noted on the (1) Level designation and scope notes. Functional
illustration are typical examples. flow block diagrams are designated as top level, first
level, second level, and so on. The top level functional
4—2. System Engineering Documentation flow block diagram describes the gross operational
Detailed descriptions of the system engineering docu- functions. The subsequent level diagrams represent
mentation items: progressive expansions of individual functions of the
a. Functional Flow Block Diagrams (FFBD) (fig. preceding level. Each functional flow block diagram
4-5). The initial step in the system engineering contains a “scope notes” area. On top level diagrams,
process formulates a functional description of the this area contains the formal name of the system and
system. Functional flow block diagrams are devel- its objectives, a brief description of the scope of the
oped for the primary purpose of structuring system programs, and comments such as the limitations of
requirements in functional terms; the main emphasis the analysis. On lower level diagrams, the scope note
is on accuracy and completeness rather than upon is used to describe the relationship of the data
format. As an aid in developing, interpreting, and covered on the diagram with data covered in other
providing standardization necessary to control inter- diagrams. It should briefly summarize the condition
faces, certain basic rules and symbols have been that exists at the starting and ending point of the
developed and are followed in the physical layout of drawing and the general purpose and scope of the
the functional diagrams. These requirements are functions covered in the diagrams. Normally, the
described in subsequent paragraphs. The general materiel developer prepares functional flow block

4-4
 • • è
OUTPUT DATA FOR PLANS AND ACTIVITIES

PROGRAM PLANS AND ACTIVITIES

Plans and activities
shown here are typical
examples, and may vary
with different projects.
£
3=
s- «
s-
Sr
S'
k; s-
« ■í?
s;
>s/ 's/ ■i' s- s-
SYSTEM ENGINEERING Sr
—r
iC k/
S' Sr « v/
DATA ELEMENTS Sr
AND OTHERS,

Operational Functions/Rqmts E.G., MIS

Log Spt Functions Rqmts

Reí i abi1i ty/Mai nt/Rqmts

Equipment Design Criteria

Equipment Design Solutions

Facilities Requirements

Function Performance Times

Task Description/Skil1 Rqmts

Operating Procedures
m770-78

4-5
Figure í-3. Multiple application of SE data elements.
FM 770-78

^ J5
aV
O* ^

.éb’sfr jS*

BASIC
SYSTEM
SÄ
ENGINEERING
DOCUMENTS
S'
s?9 *•
<5> TYPICAL
DERIVED
DOCUMENTS
FUNCTION AS REQUIRED
FFBD IDENTIFICATION
o
o
FUNCTION PERFORMANCE Q£
RAS/TLS a.
REQUIREMENTS

CDS/SBD SYNTHESIS

>1
TSR

DS/FIS
EVALUATION & DECISION

DESCRIPTION
1/
/

^ DEPLOYMENT PLAN
I
FFBD - FUNCTIONAL FLOW
BLOCK DIAGRAMS ^“PRODUCTION PLAN
RAS - REQUIREMENTS ALLOCATION
SHEETS
COORDINATED TEST
TLS - TIME LINE STUDIES
PROGRAM
CDS - CONCEPT DESCRIPTION
SHEETS *-*• PLAN FOR LOGISTICS SUPPORT
SBD - SCHEMATIC BLOCK
DIAGRAMS
TSR - TRADE-OFF STUDY REPORTS
OPERATION PLAN
DS - DESIGN SHEETS
FIS - FACILITY INTERFACE
SHEETS

Figure U-U- Relationship of basic to derived documentation for system engineering.

diagrams down to the level necessary to establish the 4-6. Functions which further indenture these top
parameters of the major subsystems. The system functions contain the same parent identifier and
contractor then prepares the lower level functional coded at the next decimal level for each indenture.
flow block diagrams to the level necessary for pro- For example, if more than one function is required to
gram definition and identification of technically criti- amplify function 1.0 at the first level of indenture, the
cal areas. sequence will be 1.1, 1.2, 1.3, . . ., l.n. In expanding
(2) Function numbering. Functions identified on function 1.2 at the second level, the numbering will be
the diagrams at each level are numbered in a manner 1.2.1, 1.2.2, . . ., 1.2n. Where several levels of
which preserves the continuity of functions and pro- indentures appear on a single functional diagram, the
vides information with respect to -function origin same pattern is maintained. While the basic ground
throughout the system. The indenture numbering rule is to maintain a minimum level of indentures on
related to flow diagram level is illustrated in figure any one particular flow, it may become necessary to

4-6
 s

ABBREVIATlONS/NOTES:

"AND" GATE: PARALLEL FUNCT.

"OR" GATE: ALTERNATE FUÑCT.

■ FUNCTIONAL
DESCRIPTION

Ref 9.2, Provide Guidance

FUNCTION 9.2.2
NUMBER r—SUMMING GATE GO FLOW

9.2.1

PARALLEL (AND Ref. 11.3.1

3.5 Ref AND
FUNCTIONS

See Detail Diagram 9.2.3

See Detail Diagram

OR OR

ALTERNATE
FUNCTIONS

I I

V
9.2.4

1.1.2 Ref i SYS.

NO GO FLOW TENTATIVE
MALF.
FUNCTION

INTERFACE REFERENCE See Detail Diagram

LEADER NOTE
BLOCK (USED ON FIRST
& LOWER LEVEL FUNCT.
DIAGRAMS ONLY)

FLOW LEVEL DESIGNATOR

2ND LEVEL

SCOPE NOTE:
FUNCTIONAL FLOW BLOCK DIAGRAM

TITLE BLOCK AND STD. DWG. NO. FORMAT

FM 770-78

Î Figure b-5. Functional flow block diagram general format and symbols.
FM 770-78

6.0 5.0 3.0

TOP LEVEL

2.6 2.7
1.3 1.6 1.7

1st LEVEL 2.8

1.4 /n.5

1.5.3 1.5.4 1.5.5

1.2.1 1.2.2 1.2.3 1.2.6

2nd LEVEL
1.2.5

Figure U-6. Indenture levels and traceability.

include several levels to preserve the continuity of mining effect on the selection of functions and func-
functions and to minimize the number of flows re- tional paths are referenced on the diagrams. This is
quired to functionally depict the system. The general accomplished by a flag noting the functional path
criteria for the number of functions and level of involved showing the applicable trade study numbers.
indentures appearing on any particular flow are Corresponding flag notes are continued in the
accuracy, traceability, and clarity of presentation. “Notes” section of the diagram.
(3) Function block. Each separate(4)function on a
Flow connection. Lines connecting functions
functional flow block diagram is presented in a single indicate only the functional flow, and represent nei-
box enclosed by a solid line. Blocks used for refer- ther a lapse in time nor any intermediate activity. In
ences to other forms are indicated as partially en- indicating the flow, vertical and horizontal lines
closed boxes labeled “Ref’ and bearing its own between blocks indicate that all functions so interre-
number. Each function may be as gross or as detailed lated must be performed in either a parallel or series
as required by the level of the diagram on which it sequence as indicated.
appears, but it will stand for a discrete action to be (5) Flow direction. Functional flow block dia-
accomplished. Trade-off studies which have a deter- grams are drawn so that the functional flow is from

4-8
 FM 770-78

left to right and the reverse flow, as in the case of a or diverge from the “OR” gate. An “AND” gate may
functional loop or servo system, from right to left. have multiple inputs and multiple outputs. All of the
Primary input lines enter the function block from the input functions must be completed prior to passage
left side; the primary output or “GO” line exits from through the gate. An “OR”gate may have multiple
the right; and the “NO GO” line from the bottom of inputs or multiple outputs, but not both. The sum-
the box. However, where other considerations dictate ming gate which preceds parallel and alternative
a different arrangement to highlight a physical area, functional paths is repeated at the end of those
level of maintenance, or other significant consider- functional paths when this redundancy increases the
ation, a different arrangement might be employed. clarity of the diagram..
(6) Summing(7) gates.
GO/NO-GO
A circlepaths.
is usedThe
to depict
symbolsa “G” and “G”
summing gate. As in the case of functional blocks, are used to indicate “GO” and “NO-GO” paths. The
lines enter and/or exit the summing gate as appropri- symbols are entered adjacent to the line(s) leaving a
ate. The summing gate is used to indicate the particular function block to indicate alternative func-
convergence and/or divergence of parallel or alternate tional paths (fig. 4-5).
functional paths and is annotated with the terms (8) Numbering procedures for changes to func-
“AND” or “OR” respectively. The term “AND” is tional flow block diagrams. In order to provide a
used to indicate that parallel functions leading into rapid means for changing flows without causing
the gate must be accomplished before proceeding into extensive or chain reaction revision of numbering,
the next function, or that paths emerging from the addition of functions to existing data is accomplished
“AND” gate must be accomplished after the preced- by locating the new function in its correct position
ing function. The “OR” gate indicates that alternative without regard to subsequence of numbering. The
paths may lead to or follow a particular function. The new function is numbered using the first unused
term “OR” is used to indicate that any of several number at the level of indenture appropriate for the
alternative paths (alternative functions) converge to new function, as in figure 4-7.

2.5 2.1
ADDED ORIGINAL
FUNCTION FUNCTION

2.4
ADDED
FUNCTION

2.2
ORIGINAL
FUNCTION

I
!
2.3
ORIGINAL
FUNCTION

Figure U-7. Addition of functions.

4-9
FM 770-78

When previously established functions must be redel- selection. Leader note examples: NO-GO, system
egated to a different functional string, the function to malfunction, operational launch, gravity mode. In any
be moved is considered retired and the new location event, all abbreviations and any notes used on the
of that function is considered as a new addition to the drawing to simplify or clarify the meaning are listed
acquiring strings and is treated as shown in figure 4- in this area of the drawing. Definition and descrip-
8. tions should be complete and accurate.
(9) Abbreviations, notes, and leader (10) Title
notes.block.
Ab- A title block is placed in the
breviations are used in flow blocks to increase the lower right comer of the drawing. The title block
understandability of functional flow block diagrams contains the title of the functional diagram, the
and to reduce the space required. Generally, these functional diagram number, and the appropriate sig-
abbreviations are restricted to those commonly un- natures, approvals, and dates. The formal title for top
derstood in the program. Functional diagrams, while level diagrams is “Top Level Functional Diagram . . .
logically aranged, are not logic networks in the System.” The title for lower level diagrams is the
mathematical sense, and gates alone are not adequate same as the title of the reference block, i.e., the
to avoid ambiguity in all cases. To minimize the function being detailed. A level designator is placed
problem, leader notes are used for clarification. directly above the title block to indicate flow level.
Leader notes are placed near a line entering or (11) Revision block. A revision block is located in
leaving a function when additional clarification is an appropriate area. The revision block contains the
required. Leader notes are used particularly in con- revision symbol, the revision date, and the appropri-
junction with “OR” gates to indicate criteria of ate approval signatures. Each revision is described on

l.l ► 1.2 ► 1.3

FLOW A

4.1 4.2 4.3

FLOW B

CHANGE FUNCTION 4.2 FROM FLOW B TO FLOW A

1.1 1.2 1.3

1.4

FLOW A CHANGED

4.1 4.3

FLOW B CHANGED

Figure b-8. Redelegation of functions to different functional string.

4-10
 FM 770-78

the revision page of the document containing the and modifications incorporated into the contract by
functional diagrams. finalized supplemental agreement.
(12) Detail reference. A function block which has (6) Column B—Enter the letter “A” for addi-
a lower level breakout will have the note “See Detail tion, “C” for change, and “D” for deletion, as applic-
Diagram” inside or below that block. able to column A. A number following the letter shall
b. End Item Maintenance Sheet (EIMS) (fig. U-9). be entered to indicate the numbered change or
The end item maintenance sheet is a special purpose addition, e.g., “C2” would be change 2.
form which may be used to identify maintenance (c) Column C—Enter the relative position of
function requirements on a specific configuration the item within the group assembly hardware break-
item, subassembly, and component basis. When both down starting with identure “A.” This would identify
system engineering and LSAR documentation re- the highest level of a given item of hardware to be
quirements are specified on the project, it will be produced or furnished as an entity by the Govern-
advantageous to use LSAR input data sheets for ment and would progress in order through B, C, D,
recording maintenance engineering analysis data. etc., in accordance with the mechanical disassembly
relationship of the parts being analyzed.
(1) Use of LSAR data sheets. LSAR sheets are (d) Column D—Enter the nomenclature, man-
completed manually or by other appropriate means to ufacturer’s part number, and national stock number
provide the nomenclature, Government-type model (NSN), if available, for the corresponding equipment
and series designation, as applicable, or the major indenture.
end items or systems, and/or commercial type, model, (e) Column E—Subsequent to the establish-
and series designation in the space provided. ment of the product baseline, engineering change
(2) Use of end item maintenance sheet. The requests (ECR’s) will require that the first item
EIMS may be used if LSAR documentation is not which incorporates the change be specifically identi-
required on the project. While its use may not be fied and noted opposite the applicable equipment
generally applied, the EIMS is included in this entry. The serial number(s) of the next higher end
manual to demonstrate the traceability and correla- item are used when there is a possibility of hardware
tion required for compatibility with other system differences within a given part number. Where con-
engineering basic documentation. EIM’s are prepared figuration differences exist within the next higher
in the format presented in figure 4-9 as follows: item or assembly that would affect the maintenance
(a) Column A—Enter the contract control of the item under analysis, the lowest and highest
number. This number identifies the procuring mili- serial number of the next higher item or assembly are
tary service or agency, the fiscal year, last four digits shown. In cases where the specific item under analy-
of the contract number, and identification of exhibits sis applies to all serial numbers of the end item, insert

INSTE. MAINTENANCE MAINT. LOCATION,

END ITEM MAINTENANCE SHEET < G , MAINTENANCE FUNCTIONS v « J ,
STATUS jV FREQUENCY (AP. 7SC-1) '

SUBSYSTEM
END ITEM
ITEM O uj MFG. PART NO.
CONTROL I— UJ AND ON *X. UJ
— O — Li_
NO. STOCK NO. C£ U_
UJ UJ
NOUN, NAME to
N
0 'V
\t!

NUMBER OF Cl & NOMENCLATURE

Figure U-9. End item maintenance sheet.

4-11
FM 770-78

the lowest serial number and “and subsequent.” End the ready status. Frequencies of functions identifying
items for which there is no higher end item reflect operating or calendar time are entered as a number
only their own serial numbers. followed by one of these letter codes: D = Days, M =
(J) Column F—Identify the installation status Months, S = Seconds, H = Hours, C = Cycles.
of equipment at the time the maintenance function in Reasons for the frequency selection are narrated on
column G is accomplished. No entry is to be made for the RAS in the “Design Requirements” column to
“whenever” or “as required” maintenance actions. substantiate both the need for the function and its
(g) Subcolumn Fl—Enter an “X” to indicate frequency. If the maintenance function is scheduled
that the preventive or corrective maintenance func- but not on the basis of time (operating or calendar),
tion indicated on that line is performed while the the requirement is entered under the preventive
equipment is installed in its normal operating column using the following codes when applicable:
configuration.
{h) Subcolumn F2—Enter an “X” to denote 1. PI—This code identifies a maintenance
that the maintenance function is performed on a function required PRIOR TO INSTALLATION in
subsystem or module that has been removed from the the equipment configuration for which it is intended.
system, but has not been disassembled. 2. R—This code identifies a maintenance
function required upon RECEIPT from the
(i) Subcolumn F3—Entry of “X” in this col-
factory/depot.
umn denotes reparable equipment that can be re- 3. PM—This code identifies a maintenance
moved and installed only on a disassembled function required PRIOR TO MISSION
subsystem or major assembly.
accomplishment.
(7) Column G—Enter identification of the 4. POM—This code identifies a maintenance
maintenance functions required on equipment listed function required after every POST MISSION or
under column D. Subcolumns 1 through 10 identify post start period. Post start would include an aborted
basic maintenace functions which may apply to the mission condition.
equipment entered in column D. Refer to AR 310-3 5. PU—This code identifies a maintenance
for definitions of these maintenance functions. Only function required PRIOR TO USE of the item.
one function entry is made per line item. As each
entry is made in column G, the preventive and (m)
corrective maintenance frequency of that function is estimated frequency for corrective maintenance func-
entered in the appropriate subcolumn of column H. tions. The failure rate is identified in the terms of
Each major assembly is analyzed as a complete number of failures per item per month. The code
assembly for maintenance functions and maintenance designating the time unit and the quantity is entered
frequency: (1) In a system installed; (2) For subsys- in the same manner as subcolumn HI entries.
tem-assembled configuration; and (3) As an end item, {n) Subcolumn H3—When accomplishment of
whether it is a primary or secondary item. After a particular function requires that additional func-
analysis as an end item, the major assembly is broken tions be performed, an “X” is entered in subcolumn
down in a logical order of disassembly on successive H3.
lines. The lower indenture items identified thereon (0) Column J—This column identifies the peri-
are subjected to analysis as performed on higher level od of time, expressed in calendar months, when an
equipment. item may remain in serviceable stock for issue. Enter
(k) Column H—This column is subdivided into calendar months in this subcolumn or “IND” if the
three subcolùmns within which are recorded the item has an indefinite shelf life.
manufacturer’s frequency recommendation relevant (p) Column K—This column is used to corre-
to the requirements for preventive maintenance. Also late levels of maintenance to be accomplished with
recorded is the estimated frequency of corrective maintenance locations. The column may be divided
maintenance for each applicable function identified in into subcolumns for identifying the gross maintenance
column G. If a specific function occurs at two different locales of the system. Each horizontal line entry
frequencies, a separate line is used for each frequency identified by a maintenance function in column G is
at which the function is accomplished. Entries made coded with an indicator in the appropriate subcolumn
in this column are recorded as follows: of K as to the specific level recommended for
(L) Subcolumn Hi—This subcolumn is used to performance.
indicate the calendar and/or operating time cycles (3) Identifying information. Appropriate identi-
that may be accumulated on the item under analysis fying information including the revision letter, date,
prior to requiring accomplishment of the maintenance approval, document number, and page number are
function indicated on the same line to keep the item in entered at the bottom of the sheet.

4-12
 FM 770-78

c. Test RequirementSheets are required

Sheet (TRS) in order
(fig. 1-10). The to ensure the timely
test requirement sheet serves several purposes in the availability of the test elements. Test elements stated
system engineering process. It identifies all the in section 4 of the Design Sheet or appropriate
requirements called out in section 3 of the System specification are the source of performance require-
Design Sheet which must be demonstrated or verified ments for test functions. Test equipment, facilities,
during the life cycle testing. It serves as a tool for personnel, computer programs, and procedural data
management check whether appropriate provisions to satisfy these requirements are derived from the
have been made for verification of all performance/de- test cycle of system engineering.
sign requirements. It also provides for the identifica- d. Production Sheet. A production sheet may be
tion of test functions for the test cycle of the system developed for each end item of operations and mainte-
engineering process. The TRS is used to describe test nance equipment which imposes unique or critical
requirements of the overall system. By appropriate production problems. The criticality may be caused
repetition, the TRS is indentured to the level desired, by new processes required, high production rates, or
e.g., end item, assembly, subassembly, or high production costs. No standard format has been
component. developed for the production sheet. The sheet should
(1) Preparation. be designed by the user to fit the specific production
(a) Block A—Title of sheet. problem. In general, the sheet should correlate pro-
(b) Block B—Name here the system, item, or duction functions to indenture levels of the equipment
assembly to which this sheet applies. Use official end item in a manner similar to the end item
nomenclature, if possible, or the accepted name maintenance sheet. Only production-critical indenture
assigned during development. levels, functions, and factors should be included.
(c) Block C—When available, enter the manu-
facturer’s part number, detail specification number, e. Requirements Allocation Sheet (RAS) (fig. 4-
or other appropriate identification. U).
(d) Block D—This block gives the legend for (1) The requirements allocation sheet is initially
the codes used in columns 2 and 3 of Block E for used to document the performance requirements for
verification method and type of test which will be each function or group of functions depicted in the
used to demonstrate that the requirement identified Functional Flow Block Diagram, End Item Mainte-
in column 1 has been met. nance Sheet, Test Requirement Sheet, and Produc-
(e) Block E—Contains four columns which tion Sheet. Where feasible, performance
form the matrix for requirement identification, verifi- requirements are stated in terms of purpose of the
cation method, test type, and verification function; performance parameters; design con-
requirement. straints; and requirements for reliability, human
1. Column 1—Enter in column 1 the para- performance, safety, operability, maintainability, and
graph number from the system development or prod- transportability. Following synthesis, the RAS is
uct specification (or Design Sheet) which states, a used to allocate function performance requirements to
requirement subject to verification. individual system elements or combination of
2. Column 2—Enter the verification meth- elements.
od(s) per legend in Block D which will be used to (2) The RAS is prepared in accordance with the
confirm that the requirement is being fulfilled. description given below. General format is indicated
3. Column 3—Enter the test type(s) per in figure 4-11. The physical format of the RAS is
legend in Block D which will be conducted to accom- highly flexible. It can be expanded and contracted
plish verification that the requirement has been both vertically and horizontally, as required.
fulfilled. (а) Block A—Functional diagram title and
4. Column 4—Enter the paragraph number number. This block contains a reference to the title
from the system development or product specification and number of the drawing containing the functional
(or Design Sheet) which states the verification diagram or identification of the End Item Mainte-
requirement. nance Sheets, Trade-Off Study Reports, or Produc-
(2) For each system, end item, assembly, subas- tion Sheets from which the function bèing analyzed
sembly, or component for which the verification originated. When the RAS’s are used to document
method is designated in column 2, function analysis the analaysis of functions on the end item mainte-
using Requirements Allocation Sheets, Functional nance sheets, enter the nomenclature and number of
Flow Block Diagrams, Time Line Sheets, synthesis the configuration item (Cl).
using Schematic Block Diagrams and Concept De- (б) Column B—Function name and number.
scription Sheets, evaluation and decision using Trade- The name and number of each block on the referenced
Off Study Reports, and description using Design functional flow block diagram or other source is

4-13
 4-14
FM 770-78

TEST Cl NO.
REQUIREMENT NOMENCLATURE DETAIL SPEC. NO. (OR OTHER IDENTIFICATION) ^
SHEET

METHOD LEGEND %
IDI
NA NOT APPLICABLE 1. EXAMINATION 2. REVIEW OF ANALYTICAL DATA DEMONSTRATION TEST
TEST TYPE LEGEND
COORDINATED TEST PROGRAM PRODUCTION & POST-PRODUCTION TESTING USER TEST
a
A. ENGINEERING DESIGN TEST J. FIRST ARTICLES TESTING FORCE DEVELOPMENT TEST
i-H
B. DEVELOPMENT TEST I s K. COMPARISON TEST r*v AND EXPERIMENTATION
C. OPERATIONAL TEST I £C L. QUALITY CONFORM. ACCEPT. INSP. ce R- OPERATIONAL FEASIBILITY
< c TEST
D. DEVELOPMENT TEST II M. INTERCHANGEABILITY TEST
E. OPERATIONAL TEST II ON-SITE USER TEST
F. DEVELOPMENT TEST III o N. RECONDITIONING
G. OPERATIONAL TEST III ^ O. INT. MAINTENANCE SHOP TEST
H. PRODUCT IMPROVEMENT 8 P. SURVEILLANCE TEST
PROPOSAL TEST
I. TECHNICAL FEASIBILITY TEST

'I •2»
REQUIREMENT V- ' VERIFICATION V VERIFICATION. REQUIREMENTS
REFERENCE METHOD COORDINATED PROD AND USER PER SECTION 4 OF
PER SECTION. 3 TEST PROGRAM POST PROD TEST 'si'
OF SPECIFICATION(S)
OF SPECS
NA A S

\
» E/

CONTINUATION SHEETS AS REQ UIRED

Figure i-10. Test requirement sheet.

 FM 770-78

EQUIPMENT PERSONNEL AND TRAINING

FUNCTIONAL DIAGRAM TITLE AND NO
IDENTIFICATION EQUIPMENT REQUIREMENTS
REQUIREMENTS ALLOCATION
SKEET PROCE-
Cl DURAL
OR DETAIL DATA
SPEC OR TNG & TNG REQUIRE-
NOMEN TIME PERFORMANCE
INDEX OR EQUIP MENTS
CLATURE REQ REQUIREMENTS
FUNCTIONAL PERFORMANCE FACILITY MASTER REQ
AND DESIGN REQUIREMENTS REQUIREMENTS CONTROL
NUMBER

.'F,'
i C » I D >
N J' v 2/ V 3, . F '

Figure 4-11. Requirements allocation sheet.

entered in sequence. Subfunctions which evolve as a 1. Description of the function including the
product of the RAS analysis, but which are not “why” and “what” of the function, i.e., answering the
identified as discrete functions as the functional flow questions: Why is the function necessary? Why
block diagram or other source, may be identified in should the functions be accomplished at this point in
the column to minimize unnecessary diagram expan- the sequence of activities? What engineering charac-
sion. Functions are expanded by listing these sub- teristics of this function are related to engineering
functions only when additional performance characteristics of another function?
requirements are generated. When the RAS is used 2. Specific design characteristics created by
to document the analysis of the functions on the end the function, i.e., input, output, performance values,
item maintenance sheet, the EIMS line number and and allowable quantitative tolerances include applic-
maintenance function identification is entered in col- able maintenance constraints, such as checkout limit,
umn B. calibration limitations and requirements, accessibility
(c) Column C—Functional performance and requirements, limiting prerequisites, including identi-
design requirements. This column contains the quali- fication of pressurized and toxic environments, and
tative and quantitative performance requirements critical disassembly requirements. Detail should be
which result from analysis of the function identified in sufficient for direct use as criteria which initiate and
column B. These requirements are developed and control the system and system equipment design.
expanded in detail to provide criteria for synthesizing Include sufficient technical detail to extract portions
and evaluating methods of satisfying each functional of one or more RAS’s and, in conjunction with
requirement in terms of combinations of equipment, schematics, assemble them into the design sheet as
facilities, and personnel. This column also contains integrated design requirements.
any design requirements and/or constraints that ap- 3. Requirements which constrain or have
ply to the equipment that may be selected to perform significant influence on design, such as power, phys-
the function. These requirements are developed in ical dimension and weight, controlled and natural
equal depth for maintenance, test and production environment, and human performance capabilities
functions reflected on the appropriate sheet, as well and limitations. Time constraints either created by or
as operational and deployment functions identified in constraining the function shall be identified. Illustra-
functional flow block diagrams. The objectives of the tion of such constraints might be computation times,
performance and design requirements entries are to countdown or availability, or effectivensss studies.
establish functional and design requirements for in- 4. Requirements for reliability, safety, main-
clusion in the design sheet and, subsequently, into tainability, and transportability.
the requirements section of the development specifi- 5. Functional and technical interface re-
cation; initiate recognition of intrasystem and inter- quirements evolving from analysis of the function are
system interface requirements and facility separately identified to facilitate interface surveil-
requirements; and initiate recognition of personnel lance and collection. The requirements describing the
requirements. Performance and design requirement interface are specific and quantified. Where intersys-
entries include— tem interface is specified, the configuration of that

4-15
 FM 770-78

system is specified together with the technical char- aids are required, as well as the recommended type
acteristics of the interface. When any of the above for the functions and tasks identified in columns B
entries are products of trade-off study reports, other and FI. The following codes are used to indicate the
backup studies, specifications, or other sources, a extent of training required:
specific reference to the applicable source is made. 1. X—requires no training.
(d) Column D—Facility requirements. This 2. A—^requires a general familiarization
column contains the facility requirements imposed by through discussion and/or demonstration.
the performance and design requirements in column 3. B—^requires a briefing on the knowledge
C. The entries identify— or job task to meet the job requirements; does not
1. Controlled and natural environmental re- need to apply the information received.
quirements, e.g., temperature and humditiy ranges, 4- C—^requires a briefing on the knowledge
illumination and noise levels, wind and snow loading, or job task to meet the job requirements; needs to
precipitation, penetration and abrasion effect, and apply the information received in a nonjob-like situa-
atmospheric pressure. This entry identifies facilities tion, such as written test or verbal problem-solving
which must be developed or scheduled on a long lead situations.
basis to provide or test the system capability to 5. D—requires a briefing on the knowledge
withstand specific environments. or job task; needs to perform or apply representative
2. Utility requirements, e.g., power (electri- portions of the job task or knowledge in a job-like
cal, hydraulic, etc.), air conditioning, ventilation, and situation, either on actual equipment or trainers.
heating to be satisfied by the facility. 6. E—^requires a briefing on the knowledge
(j) Column F2—Time required. Enter the or job task; needs to perform the complete job task or
elapsed time required to accomplish the task' in apply the knowledge in a job-like situation on actual
seconds, minutes, hours, or days to the first decimal; equipment or trainers.
use S = sec., M = min., H = hour, D = day; e.g., 7. F—same as E, but performed a sufficient
3.5 S means 3.5 seconds. number of times to ensure proficiency in all phases of
(Jc) Column F3—Performance requirements. performance.
For those task requirements outlined in FI, the The training equipment or aids recommended may be
following entries, as appropriate, are used: mission simulators, part-task trainers, training at-
1. Crew coordination, i.e., if the task re- tachments, animated panels, cutaways, exploded or
quires more than one person, define the coordination site display, training films, and charts and transpar-
requirement including the communications necessary encies. For training equipment end items, the Cl
and number of personnel involved. number or applicable specification number is entered
2. Job knowledge, i.e., state whether or not in this column, as appropriate.
theory of operation is required or just an understand-
ing of the procedures necessary to accomplish the (m) Column G—Procedural data require-
task. ments. Functions which produce complicated or haz-
3. Making decisions, i.e., if the task requires ardous requirements involving personnel will
judgment of decision, summarize action and the generally dictate the need for procedural information.
criteria which control that action. Column G provides the means for ensuring that the
1. Safety procedures, i.e., if the task re- developer has considered available data, and where
quires more than normal caution to prevent injury to not available, has programed development of the
personnel or equipment malfunction, summarize the procedural data. Entry in this column is in all cases
procedural criteria which will minimize risk. specific. For engineering development programs, en-
5. Performance under stress, i.e., if the ter the nomenclature, number, and type of procedural
personnel actions are to be performed under time or data available or to be established (test directives,
technical stress, summarize the significant conditions test procedures, specific equipment procedures).
under which stress occurs. Where the requirements are applicable to operational
6. Skill demands for critical tasks, i.e., military programs, include the technical manual num-
define perceptual, judgmental, and motor demands. ber in existence or to be established; include the
7. Define sustenance and other life support technical manual preparation specification against
requirements imposed by the functions and design each type of data to be prepared. Commercially
requirements. available publications may be applicable to higher
(Í) Column F4—Training and training equip- development engineering efforts or operational mili-
ment requirements. Enter training and training tary supplier. In any category previously described,
equipment requirements to indicate the extent of changes required to make existing procedural data
training required and whether training equipment or suitable for the technical requirement involved are
 FM 770-78

noted by a parenthetical (c) following document quired) is a separate but correlated effort. Procedural
number, i.e., Speery Gyro 25656 G (c) or T.M. (c). instructions are not included. A task is defined as a
3. Civil/structural/architectural require- concise statement of a unit of work that has an
ments. Requirements for structures are stated in identifiable starting and ending point, is measurable,
terms of functional requirements, induced environ- and cannot be reduced to two or more significant
ment, and minimum dimensions. Requirements for parts. If a breakdown of a statement would result in
space, access, and monitoring in new or existing stating obvious activities such as “Bolt in Place” or
structures are described in terms of minimum dimen- “Open Access Door,” the breakdown is not to be
sions necessary to accommodate the equipment. considered significant. If a unit of work to be per-
4. Facility equipment, if identified earlier in formed by equipment, facilities, personnel, or some
the system engineering process. combination thereof, can be broken into two or more
(e) Column E—Equipment identification. significant parts, it is a function; for example, “Install
(J) Column El—Nomenclature. Enter the Communication Equipment” can be broken into at
short form nomenclature of the end item(s) of equip- least two significant parts: “Install Transmitting
ment, which has been selected to satisfy the function- Equipment” and “Install Receiving Equipment.”
al performance requirement. Once nomenclature is Task requirements are identified by alphanumeric
used against a given function or within a given extensions of the function number in column B; for
function, the item may be identified thereafter by example, function 3.1.2 would have corresponding
number. tasks numbered 3.1.2a, 3.1.2b, . . . 3.1.2n with task
(g) Column E2—Cl identification. Enter the breakdown numbered 3.1.2.a.l, 3.1.2.b.2, and so on.
Cl identification number. This may be the manufac- (3) Appropriate identifying information including
turer’s part number, specification number, or NSN. the revision letter, date approval, document number,
(A) Column F—Personnel and training equip- and page number, are entered on the bottom of the
ment requirements. For functions that are to be sheet.
completely automated and will not involve personnel, /. Time Line Sheets (TLS) (fig. 4-12).
this column may be eliminated. For these functions, a (1) Time line sheets are used to support the
separate sheet may be used with columns B, C, D, development of design requirements for the oper-
and E, only. ation, test, and maintenance functions. They depict
-• (i) Column Fl—Tasks. Enter the human per- concurrency, overlap, and sequential relationship of
formance task requirements which are involved in functions and related tasks and identify the time-
performance of the functions identified in column B. critical functions. Time-critical functions are those
These task requirements are specified to the level of that affect reaction time, downtime, or availability.
technical depth that will facilitate identification of (2) Time line sheets may be prepared in the
personnel requirements and procedure development. format shown in figure 4-12 in accordance with the
Detail task identification and analysis (when re- following requirements:

TIME LINE SHEET FUNCTION LOCATION TYPE OF MAINTENANCE (IF APPLICABLE)

(A) (B) (C)
SOURCE OF FUNCTION & CORRESPONDING TASKS
FUNCTION (IF APPLICABLE)
(E)

Figure i-12. Time line sheet.

4-17
FM 770-78

(a) Block A—Enter the title of the time-critical cept in concise terms that are either within or
functions appearing on the functional flow diagram. approach the framework of constraints and require-
(ft) Block B—Enter the location where the ments described by the earlier FFBD and RAS.
functions and corresponding tasks are to be
performed. h. Schematic Block Diagrams (fig. 4-14).
(c) Block C—This entry is applicable only for (1)
functions involving maintenance. When applicable, assemble function performance requirements and cri-
indicate preventive or corrective maintenance. teria, as established and documented in the require-
(d) Column D—Enter the functional diagram ment allocation sheets, into an integrated set of
drawing number, function block number, and docu- design requirements comprising a system (including
ment number of the Requirements Allocation Sheet. interfaces with other systems), an end item, or a
Enter identifying information (control number no- group of related end items (subsystem).
menclature) from End Item Maintenance Summary (2) Schematics are prepared to identify intersys-
and End Item Code, whenever the function has been tem relationships, e.g., a command/control system
derived from the End Item Maintenance Summary or interface with a strategic weapon system; or intrasys-
LSAR. tem relationships including that between constituent
(e) Column E—Enter the functions and corre- elements of a subsystem, e.g., in communication
sponding personnel tasks contained on Requirements subsystem interfaces between closed circuit TV,
Allocation Sheets. Corresponding tasks will not be work station intercom, remote site communication
applicable for all time-critical functions. For time- and subordinate detailed schematics, as required. The
critical functions involving human engineering, iden- essential characteristics of a schemaic are to delineate
tify Military Occupational Specialty. by symbols (schematic, architectural,electronic,
(0 Column F—Enter the elapsed time esti- mathematical, structural, mechanical, or others) the
mated to accomplish functions and corresponding features and relationships of end items, subsystems,
task, if applicable, in seconds, minutes, hours, or components, and parts. Schemaics are structured in a
days to the first decimal, in bar chart manner, the manner that show the functional interfaces and ap-
total time in days, hours, minutes, and/or seconds is portionment of requirements between major systems,
entered at the end of each time bar; use S = seconds, within the system, among the elements of the system
M = minutes, H = hour, D = day, e.g., 3.5 S means (equipment, personnel, facilities), and between end
3.5 seconds. items; end to end and/or closed-loop relationships; and
(3) Identifying information. Appropriate identify- the maintenance or checkout aspects of the proposed
ing information, including dates, approval, and docu- design. The amount of detail shown in the schematic
ment numbers are entered at the bottom of the page. block diagram varies depending upon the point in
g. Concept description sheet (fig. U-13). The pur- time that the schematic is prepared, the level of
pose of this document is to signal the designer that he information available in the requirements allocation
should stop at a point in the system engineering sheets and trade studies, and the level at which
process and create a gross level concept. The concept hardware requirements are being described (system,
description sheet may take many forms and may major subsystem, major end item, black box, or
include any indenture. The sheet describes the con- other). Sufficient detail is shown to illustrate how the
design requirements are to be met.
CONCEPT DESCRIPTION
SHEET NOMENCLATURE
Cl OR SPECIFICATION OR
INDEX OR MASTER
(3) As system definition progresses, the schemat-
CONTROL NO. ic block diagrams are updated to incorporate new
requirements such as maintainability features, self-
test capability, read-out indications, monitoring capa-
bility, critical pressures, voltages, and other quanti-
tative expressions of system performance. Schematic
block diagrams generate a family of lower level
diagrams traceable from the top down or from the
bottom up, collect and apportion effective RAS re-
quirements or trade-off study requirements against
applicable system or subsystem equipment, and iden-
ENGINEER- DATE- •PAGE NO.- 0F- tify major intersystem and intrasystem requirements
and interrelationships.
(4) The basic technique for developing schematic
block diagrams is illustrated in figure 4-14. The first
Figure 4-13. Concept description sheet.

4-18
 ATTITUDE CONTROL AND MANEUVERING SUBSYSTEM
SCHEMATIC BLOCK DIAGRAM

1
INERT GAS PRESSURI- ELECTRICAL .
ZATION SUBSYSTEM • POWER !
I SUBSYSTEM | MANUAL CONTROL
I (REF) I AND DISPLAY
INERT GAS PRESSURANT I J SUBSYSTEM
INERT GAS PRESSURANT
(REF)
OXIDIZER REMAINING

INDICATION I
OXIDIZER FUEL
STORAGE
FUEL REMAINING J

NAVIGATION
STORAGE
INDICATION
SUBSYSTEM SUBSYSTEM

SIGNALS
COMMAND SIGNALS

COMMAND SIGNALS

COMMAND SIGNALS
4 MSRV GUIDANCE ,
1
COMMAND SIGNALS AND NAVIGATION |
' SUBSYSTEM (REF) I
I I
SOLENOID SOLENOID FUEL
OXIDIZER
VALVE VALVE
(OXIDIZER) (FUEL)

I
ROCKET ENGINE NOZZLE ASSEMBLIES

PITCH ROLL YAW LONGITUDINAL

THRUST THRUST THRUST VELOCITY
INCREMENTS
>4

4-19
?
Figure 4-14. Schematic block diagrams. 00
FM 770-78

level schematic diagrams are completed for the sys- (1) Trade-off study reports provide a systematic
tem or subsystem being developed. The schematic assessment of requirements and their alternative
depicts either a “closed-loop” or end-to-end block solutions. They also help document engineering deci-
description of intrasystem interfaces. Second level sions, providing visibility into the system engineering
detail diagrams are technical expansions of first level effort and the reasons for selection of one alternative
diagrams. Input and output expansions are related to over another. Selection of the optimum alternative
the interfaces expressed in the first level diagrams. will usually require risk analysis to measure the
Third level detail diagrams are organized functionally potential for cost, schedule, and performance
to define significant end-to-end system logic across all deficiencies.
hardware and facility interfaces involved, i.e., power
(2) Trade-off study reports are prepared as
subsystem, launch control, flight sequence, malfunc-
follows:
tion detection and control, and others. Hardware
(a) Paragraph 1—State the scope of the
designators established in first and second level detail
report.
schematics are used with logic elements to depict
(b) Paragraph 2—Identify and list the func-
interfaces with facilities and equipment, and to main-
tional and technical design requirements which are
tain a traceable relationship to the other schematic
germane to the trade-off. In each subparagraph, state
diagrams. For time-critical functions, time governs
the functional requirement first and then identify
the layout of the drawing, i.e., reading from left to
related technical design requirements. Immediately
right, being with the initial functions and proceed so
following each requirement (and in the same para-
that the operations sequence of all applicable hard-
graph), a reference is made which identifies the
ware is shown.
source of the requirement. This reference consists of
i. Trade-off stvdy report (fig. 1-15).
the title, file number, date, page number, and para-
graph number from which the requirement statement
was extracted.
(c) Paragraph 3—List the possible design
1. Scope
approaches and identify the significant characteristics
2. Functional and Technical Design Requirements and associated risks of each design approach. Only
a. reasonably attainable design approaches are listed,
b. (Sub-paragraphs - 1 per requirement ) considering technical capabilities, time schedules,
c.
resource limitations, and requirement constraints.
Characteristics considered must relate to the attri-
3. Design Approaches and Significant Characteristics
butes of the design approaches bearing most directly
^a. (List selected design approach) on stated requirements. These characteristics should
(1) (List characteristics of the approach) reflect predicted impact on such factors as cost,
b. effectiveness, supportability, personnel selection,
4. Comparison Matrix of Design Approaches .
training requirements, technical data, schedules, per-
formance, survivability, vulnerability, growth poten-
Functional and Design Approaches tial, facilities, transportability, and producibility.
Technical Design
Requirements (d) Paragraph U—Present a comparison matrix
of design approaches. The purpose of the matrix is to
{Characteristics of each approacR)
compare the characteristics for each design approach
** to determine the degree to which the design ap-
proaches satisfy the functional and technical design
5. Recommended Design Approach requirements. The objective is to facilitate rapid
a. 1. comparison and evaluation of potential design ap-
b. (Sub-Paragraphs - 1 per substantiating reason) proaches and to allow preliminary screening out of
those design approaches that are inconsistent with
the functional and technical design requirements.
Where applicable, include cost-effectiveness models
and cost analysis data as enclosures.
(e) Paragraph 5—Recommend the most prom-
ising design approach and provide narrative to sub-
stantiate the recommendation. Include schematic
drawings, outline drawings, interface details, func-
Figure 4-15. Trade-off study report format. tional diagrams, reliability data, maintainability data,

4-20
 FM 770-78

safety data, statistical inference data, and any other support, test, production, and deployment equip-
documentation or data deemed necessary to support ment. Entries on these forms will depend upon the
the recommendation. The narrative must cover the extent of definition accomplished for the equipment.
requirements which the recommended approach im- The FIS’s are used by facility engineers to prepare
poses on other areas of the system. facility diagrams and drawings. Facility interface
(3) Trade-off study sheetsreport
are prepared as í-16).
index (fig. follows:The
materiel developer prepares and maintains a trade-off
study report index. This index identifies by contract (1) Block A—Nomenclature and Cl number.
or in-house activity identification number all trade-off Enter that nomenclature and identification of the
studies required and those which have been equipment MIL-STD-881) for which the facility re-
completed. quirements are being identified. Identification should
include development description numbers, specifica-
tion numbers, and system identification.
TRADE-OFF STUDY REPORT INDEX
(System Nomenclature) (2) Block B—Originator. Enter the identification
of the contractor or other agency originating the
REQUIREMENTS COMPLETED sheet and the equipment identified in Block A.
CONTRACT
TITLE DATE
FILE (3) Block C—Site effectivity. Enter the site,
OR W/D NR. LOCATION
location, or general area of use of the equipment
identified in Block A. If the equipment location is
fixed within a particular facility area, this area should
be identified, along with the major location. If the
equipment is portable, state this and identify general
area of use, e.g., “portable equipment, missile ready,
and maintenance areas.” Amplify the location infor-
mation as necessary in the specific requirements..
(4) Block D—Reference function. Enter the func-
Figure 4-16. Trade-off sutdy report index.
tion numbers for which the equipment identified in
Block A is used, and the appropriate RAS reference
j. Design Sheet (fig. i-17). A design sheet is numbers where the functions are documented.
prepared for each Cl, facility Cl, and modified (5) Block E—Environmental requirements. Us-
inventory equipment item or engineering critical ing the checklist at the top of the column, enter the
component, but is not required for unmodified inven- requirements data for each checklist heading using
tory equipment items or standard parts. The develop- the numeric designation from the checklist. These
er may find it necessary to utilize additional internal entries are derived from the appropriate sections of
documentation to supplement the design sheet in the design sheet, e.g., environmental, human perfor-
order to establish and maintain control of his design mance, safety, and others. Entries are as brief as
effort. Care must be exercised to ensure that high possible, stressing quantitative values, but complete
risk technical areas are identified and that the design enough to fully portray the environmental require-
is such that the risk has been reduced to an accept- ments and effects of the equipment as outlined in the
able level. Such supplementary documentation will description of each heading. When the checklist
not be included in the detail specifications. : heading is not applicable to the equipment identified
(1) Block A—Enter the short-form nomenclature in Block A, indicate this with an “N/A” entry for the
of the contract item, and abbreviated category of corresponding checklist heading number.
equipment (MIL-STD-881). (6) Block F—Interface design requirements. In a
(2) Block B—Enter the Cl or critical component manner similar to Block E, this block and checklist
code identification, specification number, or number are used to state the design requirements data for the
assigned to the item (MIL-STD-481 and MIL-STD- physical interfaces between the equipment identified
490). in Block A and the appropriate facilities. Data for
(3) Block C—The design sheet will reflect techni- these entries are derived from the design sheet.
cal information required by sections 3 and 4 of Information entered in Block F does not replace or
development specifications, and as specified in con- substitute for interface control drawings. Depending
figuration management documents. on the point in the system engineering process, this
k. Facility Interface Sheet (fig. A-18). Facility sheet may be the input to development of the
interface sheets (FIS) are used for recording facility definitive interface control drawings, at which time
design requirements imposed by operation, logistics the drawings become a supplement to the facility

4-21
FM 770-78

DESIGN SHEET NOMENCLATURE CI NO. OR CRITICAL COMPONENT

CODE IDENTIFICATION

DETAIL SPEC NO.

(BLOCK A) (BLOCK B )

REQUIREMENTS FOR DESIGN AND TEST

(BLOCK C)

REVISION APPROVAL DATE PAGE NO.

Figure 4-17. Design sheet.

FACILITY INTERFACE SHEET NOMENCLATURE AND CI NUMBER

SITE EFFECTIVITY REFERENCE FUNCTION

\B; •’C)

ENVIROMENTAL REQUIREMENTS INTERFACE DESIGN REQUIREMENTS

SYMBOL/CATEGORY SYMBOL/CATEGORY

(1) VIBRATION/SHOCK ACOUSTIC LEVEL (6) ELECTROMAGNETIC INTERFERENCE/COMPATABILITY (1) ENVELOPE AND WEIGHT (6) ACCESS
(2) TEMPERATURE AND HUMIDITY <7) CONTAMINATION LEVEL (2) MOUNTING PROVISIONS (7) POS ITION/LOCATION
(3) FORCED VENTILATION/AIR CHANGES (8) HAZARDS - SAFETY (3) ELECTRIC POWER (8) HANDLING PROVISIONS
(4) ILLUMINATION (9) HEAT REJECTION RATE (A) ELECTRICAL GROUNDING (9) FIRE/HAZARD PROVISIONS
(5) PERSONNEL OCCUPANCY (10) CRITICAL TIME FACTORS (5) WATER AMD GAS SERVICE (10) OTHER - SPECIAL INTERFACE
(11) OTHER - SPECIAL ENVIRONMENTAL REO'MTS CONSIDERATIONS

Figure 4-18. Facility interface sheet.

4-22
 FM 770-78

interface sheet to illustrate and detail the physical updating of the format continues by the originator
interface. Where such a drawing has been issued, the until all requirements are stated and blanks filled in.
appropriate heading entry will refer to this drawing Where a reasonable estimate can be established, it is
and the drawing appended to the facility interface entered, followed by the designation “(Estimated)” or
sheet. Facility interface sheet entries are subject to “(est).” When verified, the “(est)” designation is
interaction of the system engineering process. En- removed by revision to the facility interface sheet.
tries are always made as completely as possible.
Where certain information is recognized as a require- 1. Identifying Information. Appropriate identifying
ment but is not available, the entry indicates the information, including the revision letter, date, ap-
missing but recognized requirement with a blank, proval, document number, and page number, is
e.g., “Required electric power will be 220 ± 18v., 60 entered at the bottom of the sheet. Pages are
± 10 cps, 3 Phase, KW, LL PF.” Subsequent numbered consecutively for each end item.

4-23
 FM 770-78

APPENDIX A
REFERENCES

A—1. Department of Defense Directives, Instructions, and Guides

DMSSO-GB-1 DOD Specification Development Guide
DODD 4100.35 Development of Integrated Logistics Support for
Systems and Equipment
DODD 4120.18 Use of the Metric System of Measurement
DODI 4200.15 Manufacturing Technology Program
DODD 5000.1 Major Systems Acquistion
DODD 5000.2 Major System Acquisition Process
DODD 5000.3 Test and Evaluation
DODD 5010.19 Configuration Management
DODD 5010.20 WBS for Defense Materiel Items
DODD 5000.29 Management of Computer Resources in Major
Defense Systems
A-2. Military Standards and Specifications
Defense Systems
MIL-STD-100A Engineering Drawing Practices
MIL-STD-100B Gage Inspection
MIL-STD-470 Maintainability Program Requirements (for
Systems and Equipments)
MIL-STD-471 Maintainability Demonstration
MIL-STD-480 Configuration Control—Engineering Changes,
Deviations, and Waivers
MIL-STD-481 Configuration Control—Engineering Changes,
Deviations, and Waivers (Short Form)
MIL-STD-481A Configuration Status Accounting—Data Elements
and Related Features
MIL-STD-483 Configuration Management Practices for Systems,
Equipment, Munitions, and Computer Programs
MIL-STD-490 Specification Practices
MIL-STD-499A System Engineering Management
MIL-STD-721B Definition of Effectiveness Terms for Reliability,
Maintainability, Human Factors, and Safety
MIL-STD-756A Reliability Prediction
MIL-STD-781 Reliability Tests, Exponential Distribution
MIL-STD-785 Reliability Program for Systems and Equipment
Development and Production
MIL-STD-881A Work Breakdown Structures for Defense Materiel
Items
MIL-STD-961 Outline of Forms and Instructions for the Prepara-
tion of Specifications and Associated Documents
MIL-D-1000A Drawings, Engineerings, and Associated Data
MIL-STD-1388 Logistics Support Analysis
MIL-STD-1472 Human Engineering Design for Military Systems,
Equipment, and Facilities

A-l
FM 770-78

MIL-STD-1521 Technical Reviews and Audits for Systems, Equip-

ment, and Computer Programs
MIL-Q-9858A Quality Program Requirements
MIL-D-26239A Data, Qualitative and Quantitative Personnel
Requirements Information (QQPRI)
MIL-H-46855 Human Engineering Requirements for Military
Systems, Equipment, and Facilities
MIL-S-83490 Specifications, Types, and Forms

A-3. Army Regulations and DA Pamphlets

AR 5-5 The Army Study System

AR 11-13 Army Electromagnetic Capability Program
AR 11-18 The Cost Analysis Program
DA Pam 11-25 Life Cycle System Management Model for Army
Systems
AR 11-27 Army Energy Program
AR 11-28 Economic Analysis and Program Evaluation for
Resource Management
AR 15-14 Systems Acquisition Review Council Procedures
AR 18-1 Management Information Systems—Policies,
Objectives, Procedures, and Responsibilities
AR 34-1 US Participation in NATO Military Standardiza-
tion, Research, Development, and Logistic
Support of Military Equipment
AR 37-40 Army Production Base Support Program Report
(RCS-CSGLD-1123)
AR 37-55 Uniform Depot Maintenance Cost Accounting and
Production Reporting System
AR 70-1 Army Research, Development, and Acquisition
AR 70-2 Materiel Status Reporting
AR 70-9 Army Research and Development Information
System Program Planning and Ongoing Work
Reporting
AR 70-10 Test and Evaluation During Development and
Acquisition of Materiel
AR 70-15 Product Improvement of Materiel
AR 70-17 System/Project Management
DA Pam 70-21 The Coordinated Test Program (CTP)
AR 70-27 Acquisition Plan/Development Concept Paper/Pro-
gram Memorandum
AR 70-32 Work Breakdown Structure for Defense Materiel
Items
AR 70-35 Advanced Planning for Research and Development
AR 70-37 Configuration Management
AR 70-44 DOD Engineering for Transportability
AR 70-47 Engineering for Transportability
AR 71-3 User Testing
AR 71-5 Introduction of New or Modified Systems/
Equipment
AR 71-6 Type Classification/Reclassification of Army
Materiel
AR 71-7 Military Training Aids and Training Aids Center
AR 71-9 Materiel Objectives and Requirements
AR 200-1 Environment Protection and Enhancement

A-2
 FM 770-78

AR 310-3 Preparation, Coordination, and Approval of

Department of the Army Publications
AR 385-16 System Safety
AR 602-1 Human Factors Engineering Program
AR 611-1 MOS Development and Implementation
AR 700-15 Packaging, Packing, and Marking of Items of
Supply
AR 700-18 Provisioning of US Army Equipment
AR 700-47 Defense Standardization Program
AR 700-51 Army Data Management Program
AR 700-82 Use and Application of Uniform Source, Mainte-
nance, and Recoverability Codes
AR 700-90 Army Industrial Preparedness Program
AR 700-127 Integrated Logistics Support
DA Pam 700-XX Integrated Logistics Support Management Model
(ILSMM)
AR 702-3 Army Materiel Reliability, Availability, and Main-
tainability (RAM)
AR 702-9 Production Testing of Army Materiel
AR 702-10 Post-Production Testing of Army Materiel
AR 715-5 DOD Priorities and Allocations Manual
(DODI 4410.1)
AR 715-6 Proposal Evaluation and Source Selection
AR 750-1 Army Materiel Maintenance Concepts and Policies
AR 1000-1 Basic Policies for Systems Acquisition by the
Department of the Army
AT4. Technical Manuals
TM 38-710 Integrated Logistics Support Implementation
Guide for DOD Systems and Equipment
TM 38-715 Provisioning Requirements for US Army Equip-
ment (PR-1)
TM 38-715-1 Provisioning Techniques

A-3
 SYSTEM ENGINEERING ACTIVITIES
ALTERNATIVE SYSTEMS CONCEPT PHASE
BLOCK 1.0—ANALYZE BASIC INPUT REQUIREMENTS
RESPONSIBILITY: Special Task Force/Special Study Group (STF/SSG)
DESCRIPTION: Prior to initiating in-house or contractual materiel system
1
planning studies, it is necessary to analyze the nature and objectives of the
required mission as stated in or developed from the Mission Element Need
Statement (MENS), objectives and justification must establish known require-
ments and constraints before initial function analysis and synthesis can be
undertaken.
REFERENCES: AR 1-1, AR 70-1, AR 71-9, AR 1000-1
BLOCK 2.0—DEVELOPMENT OF ALTERNATIVE TECHNICAL APPROACHES
RESPONSIBILITY: Contractor
DESCRIPTION: The activities in this block represent the initial system
engineering effort in support of the materiel concept investigation. The effort
begins with receipt of an approved MENS, and leads to alternative approaches
that will be presented as technically promising concepts.
BLOCK 2.1—INITIAL FUNCTION ANALYSIS TO FORMULATE ALTERNATIVE
TECHNICAL APPROACHES
RESPONSIBILITY: Contractor
DESCRIPTION: The initial system engineering process begins with a detailed
analysis of the mission objectives and constraints to achieve complete exposure
and detailed amplification of the functions required to achieve the desired
capability. This may require the development of a series of models to depict
functions of achievable alternative technical approaches for accomplishing the
mission. Each of these competing functional approaches is then analyzed in detail
to determine the relative probability that performance requirements will be
attained. These alternative technical approaches are studied to translate
objectives into performance requirements, constraints, and identification of
major barrier areas as criteria for conceptual design of the system, subsystems,
and segments. The function performance requirements are documented in terms
of inputs and outputs, environments, performance, time constraints, and other
considerations in sufficient detail to enable synthesis to be accomplished.
FORMS: Functional Flow Block Diagram, Time/Line Sheets, Requirements
Allocation Sheets
REFERENCES: AR 70-1, AR 71-9
BLOCK 2.2—SYNTHESIS OF ALTERNATIVE TECHNICAL APPROACHES
RESPONSIBILITY: Contractor
DESCRIPTION: Synthesis is undertaken to evolve alternative conceptual
approaches that appear to be technically capalbe of accomplishing the functions
necessary to achieve the mission objectives. The outputs of this synthesis are
gross descriptions of alternative technical approaches in terms of their system
elements. The descriptions are organized só as to compare alternative technical
approaches.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 70-1, AR 71-9
FM 770-78

BLOCK 2.3—PRELIMINARY EVALUATION OF ALTERNATIVE TECHNICAL

APPROACHES
RESPONSIBILITY: STF/SSG
DESCRIPTION: Alternative technical approaches are evaluated to compare
functional approaches against the mission requirements, and the relative
achievability and potential effectiveness of the alternatives. Evaluations per-
formed are limited by factors such as the depth of available background materiel
and limitation in time, money, and study resources.
REFERENCES: AR 70-1, AR 71-9
BLOCK 2.4—TECHNICAL INPUTS TO LOA
RESPONSIBILITY: STF/SSG
DESCRIPTION: Those alternative technical approaches which survive this
initial system engineering process are included in the LOA. The technically
promising alternative approaches are graphically portrayed using a task analysis
diagram supported by brief specific narratives describing work to be done
sequentially, work to be done in parallel approaches, major technical barriers,
cost estimates, estimated time required to meet objectives (included to complete
the documentation and not,as a constraint), priorities of approaches, critical
performance parameters, probabilities of technical success for each approach,
recommended equipment currently available, a range estimate of cost assess-
ment by major cost categories (R&D, investment nonrecurring, investment
recurring), and a recommended category (6.2, 6.3, 6.4) of the R&D program to
initiate the project.
REFERENCES: AR 70-1, AR 71-5, AR 71-9, AR 700-127, AR 702-3
BLOCK 3.0—FORWARD LOA
RESPONSIBILITY: STF/SSG
DESCRIPTION: The LOA, jointly signed by the combat and material develop-
ers, is forwarded to HQ DA (DCSOPS) for review and approval (major systems),
or for information (nonmajor systems).
REFERENCES: AR 70-1, AR 71-9

BLOCK 4.0—SYSTEM ENGINEERING OF SELECTED SYSTEM CONCEPTS

RESPONSIBILITY: STF/SSG
DESCRIPTION: This system engineering activity expands the initial technical
approaches as to a level sufficient to permit the selection of preferred system
concepts from the set of alternative technical approaches considered. The
outputs of this iteration are included in the Concept Formulation Package and
technical inputs to the Outline Acquisition Plan.
BLOCK 4.1—FUNCTION ANALYSIS OF SELECTED SYSTEM CONCEPTS
RESPONSIBILITY: Contractor
I

DESCRIPTION: Working from gross description of alternative technical

approaches generated in the first iteration (Blocks 2.1, 2.2, 2.3, and 2.4), the
system engineering process now can be applied to expand the initial function
models by identification and definition of lower indenture functions. Performance
requirements are developed for each functional indenture and time requirements
analyses performed as required. Functional requirements of each system
concept of the alternative technical approaches are depicted for all operational
modes of usage in all specified environments. Each function is described with

B-4
 FM 770-78

APPENDIX B
THE SYSTEM ENGINEERING MODEL

B-l. General. and input and output to and from the life cycle model.
Other symbolism is reflected in the legend on each
a. This appendix describes a model for application figure.
to the five functional areas (operations, logistics d.
support, test, production, and deployment) of the graphic flow of the model provides additional continu-
system engineering process described in chapter 2 ity, comprehension, and clarity to the model. Each
and the management activities described in chapter 3. description correlates the block number and title with
Figures B-l, B-2, B-3, and B-4 depict the flow of the graphic flow, identifies the agency responsible for
system engineering activities for the Alternative coordination of the activity, describes the activity,
Systems Concept, Demonstration and Validation, indicates the system engineering documentation used
Full-Scale Engineering Development, and Production to accomplish the activity, and lists pertinent refer-
and Deployment Phases of the life cycle model. ences. The inclusion of references to system engineer-
Narrative descriptions of each block of the graphic ing forms which are described in chapter 4 does not
flow of the model are also provided. Together these imply that these forms are prescribed, but instead
two parts of the model identify the system engineer- illustrates only one' of many ways of presenting data
ing documentation and describe the relationships and describing ongoing design activities.
between documentation, engineering, requirements
and design reviews, in-process reviews, inputs to
B-2. Alternative System Concepts Phase (fig B-l)
configuration management basehnes, and inputs to
and outputs from the life cycle model. a. The combat developer conducts continuing anal-
b. The model dipicts a project managed system yses of mission areas in order to identify those
from concept to disposal. Since not all projects fall mission elements for which existing or projected
into this category, each system engineering effort capability is deficient and to identify opportunities for
must be tailored to the peculiarities of the system and capability enhancement through more effective and
the project. The substance of the activities described less costly methods and systems. To define long-
in the model must be accomplished at some time range research objectives, the combat developer
during the system life cycle if a balanced, effective develops a science and technology objective (STO),.
system is to be developed. which describes scope, background, concepts, desired
c. Figures B-l, B-2, B-3, and B-4 show a life cycle capabilities, and priority of science and technology
activities line, a baseline descriptions line, and a objectives. When a mission need is identified, the
system engineering activities line. Beginning in dem- combat developer documents it in a Mission Element
onstration and validation, the system engineering Need Statement (MENS) in terms of the operational
activities line is further subdivided into lines for the task to be accomplished (AR 71-9). Because MENS is
functional cycles of operations, logistics support, test, not cast in terms of capabilities and characteristics of
production, and deployment. In the earlier applica- a hardware of software system, there in no system
tions of the process, the emphasis is primarily upon engineering during the analyses of mission areas.
the operational requirements of the system, but the b. The overall objective of the Alternative System
requirements of all other functional areas are also Concepts Phase is to examine the military, economic,
analyzed to the extent necessary to establish concepts and technical bases for a major development program
and methodologies, and, in some instances, to identify and the alternative systems which warrant going into
major system elements related to these functional the next phase. The system engineering starting
areas. Dotted lines enclose interations of the system point in the life cycle of a materiel system is the
engineering process and other groupings of homogen- identification of an operational deficiency, technologi-
eous activities. Arrowed lines indicate sequential flow cal opportunity, or approaching obsolensence of exist-
(Locate fig. B-l, a fold-out, ât the end of this manual)

B-l
FM 770-78

ing systems, This need may result from combat selected concepts meet validated capability goals, are
development efforts or from field reports of current technically feasible, and provide the basis for selec-
operating forces. The proponent’s need must be tion of a system which can be efficiently and effective-
evaluated against ongoing or planned developments ly developed, produced, operated, maintained, and
and concepts, and validated by appropriate studies supported.
before conceptual development may begin. e.
c. Indications of new Army requirements and following objectives prior to validation: the technol-
capabilities are found in the DA, Joint Staff, and ogy needed is sufficiently in hand, and primarily
national plans and policies; and long-range projections engineering rather than exploratory effort is re-
concerning strategic estimates, intelligence esti- quired; the mission and performance envelopes and
mates, and technological forecasts as described in AR broad logistics support approaches are defined; the
1-1. The identified requirement initiates an investiga- best technical approaches have been selected; thor-
tion of available technology and proposal of materiel ough trade-off analyses have been made, both of the
which combines with an operational concept to form stated operational requirement against engineering
the basis for a letter of agreement (LOA). The LOA designs and between the design parameters them-
requires HQDA approval before further development selves; the cost-effectiveness of competing items on a
effort is undertaken. DOD-wide basis; cost and schedule estimates are
d. The Alternative Systems Concept Phase evolves credible and acceptable; and the high risks have been
system concepts for advanced development in the identified and plans made to resolve them.
Demonstration, and Validation Phase. System engi- /. Blocks 1.0 through 5.0 describe system engineer-
neering activities are less precisely defined and struc- ing activities in the Alternative Systems Concept
tured in this phase than in later phases. However, the Phase. This phase is conducted by the Special Task
results of early application of the system engineering Force/Special Study Group (STF/SSG), with combat,
process are vital since the conditional commitment to materiel, and training developer members of the
enter engineering development, or operational system STF/SSG providing input as required. Although sys-
development is made on the basis of the performance, tem engineering support of the task force or study
cost, and schedule data developed during the Alterna- group is done almost exclusively by contract, these
tive Systems Concept Phase. System engineering activities are described in blocks 1.0 through 5.0 in
activities are addressed basically to one purpose— sufficient detail for in-house accomplishment, should
demonstration of feasibility. This means that the that route be taken.

B-2
 FM 770-78

Statements of beginning/ending conditions to include inputs, outputs, and

intrasystem/intersystem interface requirements. Functions are defined to en-
sure indentation as part of the largest function(s) and arranged in their logical
sequence so that any specified operational use of the system can be traced within
the cycle. Alternative operational cycles are also identified. When more than one
system concept is evaluated, each is depicted and identified. Records are kept to
reflect the rationale for acceptance or rejection of each alternative. Similar
functions are cross-referenced to ensure a common synthesis solution. Gross
functions of each system concept are developed in sufficient detail to differenti-
ate those performed by the system from those to be performed by subsystems.
During this iteration, all functional cycles (operation, logistics support, test,
production, deployment) are considered. While a detailed analysis cannot be
made at this time for all functional cycles, concepts for all cycles are identified
and described. Initial determination of skill levels and training requirements are
identified and described. This effort is based not only on information previously
provided, but also continuing Combat Developer inputs which further refine and
define mission and performance envelopes and requirements.
FORMS: Functional Flow Block Diagrams, Requirements Allocation Sheet,
Time Line Sheet
REFERENCES: AR 70-1, AR 70-27, AR 71-5, AR 71-9, AR 602-1, AR 611-1,
AR 750-1
BLOCK 4.2—SYSTHESIS OF SELECTED SYSTEM CONCEPTS
RESPONSIBILITY: Contractor
DESCRIPTION: Synthesis may be performed at any level of functional
indenture in order to postulate a design or alternative designs to satisfy the
V function performance requirements and provide the basis and visibility needed
for evaluation and decision. These synthesized solutions should take into
consideration the latest technological developments. The arrangement of system
elements is portrayed in a suitable form (such as schematic diagrams) to depict a
complete response to the functions, to plan compatibility among elements of the
system and interfacing subsystems, and to permit traceability between the
elements and their functional origin. Expansion of the function into subfunction
must recognize the synthesis at the preceding higher level. Cofunctioning
equipment, support equipment, personnel, facilities, computer programs, and
procedural data are identified and grouped as a system/subsystem corresponding
to the function which they collectively accomplish.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 70-1, AR 70-27, AR 71-5, AR 71-9, AR 602-1, AR 750-1

BLOCK 4.3—EVALUATE SYSTEM CONCEPTS

RESPONSIBILITY: STF/SSG
DESCRIPTION: This block represents the detailed analyses performed to
compare and evaluate alternative system concepts. Definition of system concepts
should not preclude choice in preliminary design above those constraints in the
MENS. The number and types of evaluations to be performed may vary with
each case. The common factor in each case will be that evaluations conducted are
greatly refined over those previously conducted. Trade-off studies can now
encompass such factors as man/machine combinations, hardware systems,
components, and system support characteristics.
The STF/SSG makes trade-off determinations and analysis. The trade-off
studies should insure that the selected system concept represents the best choice

8-5
FM 770-78

possible from a mission standpoint as well as technical risk. Based on results of

the trade-off evaluation and other data, including force level planning guidance,
the STF/SSG establishes cost and schedule estimates. These estimates of total
life cycle costs and schedule must be sufficiently developed to permit joint
system merit evaluations (Cost and Operational Effectiveness Analysis
(COEA)). The depth of the analytical studies conducted must be sufficient to
show clearly that the selected system concepts have a significant advantage over
the others in terms of performance, cost, and schedule. It is imperative that
these studies include an assessment of technical risk and the consequence of
failure.
FORM: Trade-Off Study Reports
REFERENCES: AR 70-1, AR 70-27, AR 71-5, AR 71-9, AR 602-1, AR 702-3,
AR 750-1
BLOCK 4.4—FINALIZE CONCEPT FORMULATION PACKAGE
RESPONSIBILITY: STF/SSG
DESCRIPTION: The STF/SSG performs an overall assessment of the combined
supporting data for the selected system concept. The assessment is documented
in the Concept Formulation Package and included in the Outline Acquisition
Plan as evidence that the project is ready to enter advanced development.
REFERENCES: AR 70-27, AR 71-9, AR 611-1, AR 700-127, DA Pam 11-25
BLOCK 5.0—TECHNICAL INPUT TO OUTLINE ACQUISTION PLAN
RESPONSIBILITY: Materiel Developer, in coordination with the Combat
Developer, Operational Tester, Trainer, or Logistician
DESCRIPTION: The Outline Acquisition Plan (OAP) is prepared in the format
prescribed in AR 70-27. It contains narrative summaries of the technical goals
and detailed supporting plans required to outline the proposed program to
satisfy the LOA. These detailed supporting plans (i.e., Configuration Manage-
ment Plan, Coordinated Test Plan, Reliability and Maintainability Plan, Inte-
grated Logistics Support Plan, System Safety Plan, and others) are prepared
from the technical data outputs of the Alternative Systems Concept Phase
system engineering process and from the various engineering specialties. Much
supporting data will be general at this point in the life cycle. However, the OAP
must be sufficiently completed at the end of the phase to permit the appropriate
management decision to be accomplished. Although no decisions on the method
of production and procurement are determined at this early stage, the OAP
should address pertinent considerations on advance procurement planning which
will affect development.
FORMS: Schematic Block Diagram, Design Sheets, Trade-Off Study Reports,
Requirements Allocation Sheets, Time Line Sheets, Facility Interface Sheets,
LSAR Records
REFERENCES: AR 18-1, AR 70-1, AR 70-17, AR 70-27, AR 71-5, AR 71-9,
AR 385-16, AR 602-1, AR 611-1, AR 702-3, TM 38-703

B-6
 FM 770-78

B-3. The Demonstration and Validation Phase (Fig.

B-2)

a. Validation is mandatory for all new develop- ly define the relationships between, and the responsi-
ments or major modifications of existing items which bilities of all parties to the contract; identify high risk
are estimated to require cumulative expenditures areas; verify technical approaches; establish firm and
greater than $75 million in RDTE funds or $300 realistic schedules and cost estimates for engineering
million in production investment funds, unless specifi- development and production; establish schedules and
cally waived by Department of the Army. Other life cycle cost estimates for planning purposes for the
projects may be designated for validation by DA or total project, including operation, logistics support,
DOD. test, production, and deployment; and establish re-
b. The degree of technology advancement to be quirements for the support plan planning data. The
accomplished by the development is limited to that contractor’s requirements proposal should include
which can be demonstrated quantitatively, by either such information as a list of the end items required;
laboratory or experimental devices, to have a high performance specifications for each item; a work
probability of achievement. If it is necessary to make breakdown structure and a program activities net-
a forcast of anticipated developmental achievement, work plan; the principal objectives and features of the
the forecast will assume the probability of matching overall system design, including recommendations for
but not exceeding the laboratory results. This as- its operational use; a recommended logistics plan;
sumption is not intended to limit a system develop- detained cost estimates and milestone schedules for
ment to assembly of off-the-shelf components, büt engineering development or development and produc-
rather to ensure a high level of confidence that every tion as well as planning estimates and schedules for 5
technical requirement can be met. years beyond; quantitativeive reliability and main-
c. Demonstration and validation is normally per- tainability specifications and test plans; time/cost/per-
formed by two or more contractors in competition formance trade-off decisions on major alternatives;
under technical direction of the Army. It may, required new design and technology; forseeable tech-
however, be performed by a sole-source contractor, if nical problems and proposed solutions; technical
necessary, or by Army laboratories if they are to specifications and performance specifications for sup-
peform the engineering development. The system port items for which early engineering development
engineering effort contributes to preparation of a is required; delivery schedules and requirements for
Request for Proposal (RFP) to potential contractors; data and documentation; and, as required, a proposed
evaluation of contractor proposals for conducting schedule of production engineering and production
demonstration and validation; selection, negotiation, tooling.
and award of contracts; preparation of the selected e.
contrators’ proposals; submission of contractors’ re- system engineering effort is performed indepth to
ports, and development engineering or production define the performance requirements for all elements
engineering proposals; evaluation of contractor sub- of the system. The phase may begin after approval by
missions; selection of the preferred contractor; and an IPR for nonmajor systems or after ASARC
negotiation of a definitive development contract with I/DSARC I approval for major systems, and ends
the selected contractor. with validation IPR/ASARC II/DSARC II, as
d. The ultimate goal of demonstration and valida- appropriate.
tion is to select a system for full-scale engineering /. Blocks 6.0 through 24.0 describe system engi-
development. Subsidiary objectives are to establish neering activities in the Demonstration and Valida-
firm and realistic performance specifications; precise- tion Phase.

Locate fig. B-2, a fold-out, at the end of this manual)

B—7
FM 770-78

SYSTEM ENGINEERING ACTIVITIES

DEMONSTRATION AND VALIDATION PHASE
BLOCK 6.0—FUNCTIONAL CONFIGURATION IDENTIFICATION
RESPONSIBILITY: Materiel Developer
DESCRIPTION: The Materiel ' Developer begins validation upon HQ DA
approval of the Outline Acquisition Plan (OAP). OAP update is followed by
application of the system engineering process to the system specification (SE
Blocks 6.1, 6.2, 6.3, and 6.4) to integrate changes which are directed as
conditions of approval and to incorporate new information acquired. The system
■engineering process is initially applied to the operating function area require-
ments because selection of operations elements establishes the basic require-
ments for all other functional areas. Available information concerning all
functional areas must be considered, particularly when these areas impose
constraints on the total system design. The objective is to create a technically
and economically balanced system. A function analysis is conducted for all
reasonable alternative approaches to determine performance requirements for
each function. Preliminary system design concepts are expanded and synthe-
sized. Trade-off studies are made to support evaluations and decisions. One
system design concept is tentatively selected, with possible alternatives, to
establish a firm base for expansion of the-total system requirements for technical
input to a Request for Proposal.
REFERENCES: AR 71-1.

BLOCK 6.1—INITIAL VALIDATION FUNCTION ANALYSIS

RESPONSIBILITY: Materiel Developer
DESCRIPTION: Following approval by HQ DA, the Outline Acquisition Plan is
subjected to the system engineering process to reflect changes which may have
been directed as conditions of approval, and to incorporate any new information
acquired while awaiting approval. The higher level functions in the model are
iterated as necessary to firmly establish them as baselines. The initial function
analysis performed during the Alternative Systems Concepts Phase is now
iterated and expanded to lower levels to reflect new information and directed
changes. This analysis includes consideration of operation, logistics support,
test, production, and deployment functions to the level necessary to define
concepts. A time requirements analysis is performed on time critical functions.
Mission objectives and constraints are reviewed and reexamined in relation to
higher and lower order systems. A series of preliminary functional models are
developed on as many levels as necessary to depict reasonably achievable
alternate functional approaches. Each competing functional approach is then
examined in detail to determine performance requirements associated with its
function and the documenting of these requirements is terms of inputs, outputs,
environments, performance constraints, time constraints, and other
considerations.
FORMS: Functional Flow Block Diagram, Requirements Allocation Sheet, Time
Line Sheet
REFERENCES: AR 70-1, AR 71-1, AR 71-5, AR 356-16, AR 602-1,-AR 715-
6, AR 750-1

B-8
 FM 770-78

BLOCK 6.2—SYNTHESIS OF PRELIMINARY SYSTEM DESIGN CONCEPTS

RESPONSIBILITY: Materiel Developer
DESCRIPTION: Each of the proposed alternative system concepts in the
Outline Acquisition Plan is expanded to acquire further understanding of
functions, performance, design requirements, and constraints. The impact of
each proposed system concept on other elements of the total system are
assessed, and these new concepts used to expand further the functional model to
identify lower indentured functions. This synthesis of solutions is accomplished
only to the level to which the Government wishes to constrain the competing
Demonstration and Validation Phase contractors. Schematics are used as tools in
the synthesis process. They provide for visibility, traceability, and communica-
tions. They also portray the interfaces among system elements and aid in
integratng performance requirements into specific system elements. Facility end
items, such as elevators, cranes, ramps, and environmental control systems are
identified, particularly in the case of command and control centers, mission
installations, fixed repair facilities, and strategic communications systems. The
number and kinds of personnel for system operation, logistics support, test,
production, and deployment are identified in gross terms. The facilities,
personnel, training equipment, procedural data, and periods of time needed for
training purposes are identified in gross terms. Government-furnished equip-
ment (GFE), which constitutes constraints upon the system, is identified. In
cases where the new system is one which is evolving from a presently installed
system, or from a combination of presently installed equipments or systems, the
performance requirements may have been generated from a study of existing
capabilities. In this case, the scope of the existing system or systems may be
fixed by mutual agreement between the developer and the user.
FORMS: Schematic Block Diagrams, Concept Description Sheets
REFERENCES: AR 71-1, AR 71-5, AR 385-16, AR 602-1, AR 715-6, AR 750-
1
BLOCK 6.3—EVALUATION AND DECISION
RESPONSIBILITY: Materiel Developer
DESCRIPTION: An evaluation of the various conceptual designs resulting from
the expanded function analysis and preliminary system design concepts is
conducted in consideration of various personnel/machine/technique combinations,
hardware systems, and major components. The performance and design require-
ments that were defined during concept are updated to incorporate the results of
this evaluation. The impact of the various conceptual designs on logistis support,
test, production, and deployment, and on costs and schedules are considered at
this time. A technical rationale is prepared which summarizes the logic and
conclusions reached, and the possible consequences of selecting significant
alternative conceptual designs. High risk technical areas, long lead time items,
and high cost areas where trade-off studies are to be performed by the validation
contractor(s) are identified for inclusion in the Request for Proposal. A
conceptual design or possible alternatives are selected, for translation into the
system specification.
FORM: Trade-off Study Reports
REFERENCES: AR 71-1, AR 385-16, AR 602-1, AR 715-6, AR 750-1
BLOCK 6.4—INITIAL DESCRIPTION OF SYSTEM ELEMENTS
RESPONSIBILITY: Materiel Developer
DESCRIPTION: The system specification presented the basic requirements as

B-9
FM 770-78

defined during concept. By iteration in Blocks 6.1, 6.2, and 6.3, it is expanded to
provide a standard base within which competition may freely operate to
ultimately produce a technically and economically balanced system over the life
cycle of the materiel. The system design and test requirements are defined such
that the Request for Proposal(s) will communicate fully the Department of the
Army’s intent. The description of system elements establishes the criteria for
operations, logistics support, test, production, and deployment of the overall
system, and reflects the major engineering designs which have been made to
date.
FORM: Design Sheets
REFERENCES: AR 11-13, AR 18-1, AR 71-5, AR 71-9, AR 385-16, AR 715-
6, AR 750-1
BLOCK 7.0—EXPAND SYSTEM REQUIREMENTS
RESPONSIBILITY: Materiel Developer
DESCRIPTION: The requirements for the total system are established as
technical inputs to the Request for Proposal. The requirements are stated in all-
inclusive terms, specific as to Government intent, and in such a manner to
permit latitude by the offeror to utilize creative ability in submitting meaningful
proposals reflecting the offeror’s knowledge and experience. Blocks 7.1, 7.2, 7.3,
7.4, 7.5, and 7.6, respectively, describe technical requirements for the system
specification, criteria for trade-off studies, and maintenance support, test,
production, and deployment plans. The requirements established for the various
plans are oriented primarily toward the generation and updating of the plans,
and the criteria to be satisfied for each plan. The significance of establishing total
system technical requirements as input to the RFP is that these requirements
provide the base against which offerors submit proposals. The outputs from the
above-cited system engineering blocks are provided in Block 8.0 as technical
input to the Request for Proposal.
REFERENCES: AR 34-1, AR 70-1, AR 71-5, AR 71-9, AR 385-16, AR 715-6,
AR 750-15,

BLOCK 7.1—EXPAND SYSTEM SPECIFICATION

RESPONSIBILITY: Materiel Developer
DESCRIPTION: From the initial description of system elements in Block 6.4,
the system specification is expanded for inclusion in the Request for Proposal to
amplify the requirements which were identified during the Alternative Systems
Concepts Phase. It is expanded in a manner to permit the offeror flexibility in
design approaches without compromising basic performance requirements. The
system specification must encourage alternatives and stimulate initiative and
creativity by the offerors. It must state clearly the performance requirements in
definitive terms, but permit exploitation of advances in technology such as use of
new materials, automated design, integrated electronics, advanced computer
techniques, or unique sources for power or propulsion. Performance require-
ments will be stated as operationally effective bands which place a limit or limits
on acceptable bands of performance.
As required by the Plan for Logistics Support and the several test plans
(Blocks 7.3 and 7.4), the system specification requires that design provide for
accessibility of test points and any other features necessary to enable perfor-
mance of maintenance or testing without major disassembly of the equipment or
system. It also includes any known maintenance or tests required to operate the
system. Included are maintenance and tests necessary to set up or assemble the
system, interface it with other systems, or measure particular performance

B-10
 FM 770-78

characteristics during operation in order to ensure maximum operating efficien-

cy or performance.
REFERENCES: AR 70-10, AR 71-9, AR 385-16, AR 602-1, AR 715-6,
AR 750-1
BLOCK 7.2—DEVELOP CRITERIA FOR TRADE-OFF STUDIES
RESPONSIBILITY: Materiel Developer
DESCRIPTION: Specific operational areas or design features are identified
within which, or against which, trade-off studies are to be made by the
contractor. Trade-off studies may involve revisions of system functions and
performance requirements which could result in revised configurations of the
system or specific end items. Criteria for trade-off studies are expressed in
terms of resources and system parameters. Examples of resources are funds,
time, manpower, and skills. Examples of parameters are weight, mission,
length, reliability, maintainability, safety, vulnerability, and survivability.
Where possible, criteria for measurement of system effectiveness are stated in
quantitative terms. The criteria established for trade-off studies are related to
the system measures of effectiveness and the MENS/LOA with .particular
attention to “essential” characteristics and “desired” characteristics stated
therein. Trade-off limitatins are specified in relation to “essential” characteris-
tics and performance requirements for operations, logistics support, test,
production, and deployment elements.
All documents which have a direct bearing on the system are identified,
reviewed, and selected. The selected documents listed will provide the necessary
background information with the Request for Proposal for demonstration and
validation. The results of prior studies that provide the base for technical reports
prepared during the Alternative System Concepts Phase are of particular
importance to this process since they relate to feasibility, cost-effectiveness,
major trade-offs, operational analysis, and logistics analysis.
REFERENCES: AR 71-9, AR 385-16, AR 602-1, AR 702-3, AR 715-6,
AR 750-1
BLOCK 7.3—UPDATE LOGISTICS SUPPORT PLAN
RESPONSIBILITY: Materiel Developer
DESCRIPTION: The concept for maintaining system equipment, initiated
during the Alternative System Concepts Phase and incorporated into the ILS
Plan of the Acquisition Plan (Block 5.0), is updated to describe the gross
maintenance capabilities and capacity required of using and supporting organiza-
tional units. This updated description provides information concerning tactical
employment of the system, its bearing on maintenance problems, and any
unusual maintenance environment to which the system or its end items may be
subjected. It also provides information on mobility considerations as reflected in
allowable downtime, equipment availability requirements, and other operations
requirements which may have a bearing on the maintenance concept.
The updated Logistics Support Plan includes quantitative reliability and
maintainability goals, trade-off limits, demonstration concepts, measure of
overall system maintainability, data to be provided by the contractor as a basis
for reliability predictions, manpower skills, training requirements, constraints
on maintenance, field data to be collected, procedures for feedback of data; data
analysis to be conducted, methods/techniques to be used for data analysis,
requirements for data utilization for system optimization, and required equip-
ment and facilities. It establishes requirements to determine the most feasible
method of supporting the. equipment or system, to generate and prepare

B-n
FM 770-78

delivery schedules of procedural data during the entire materiel life cycle phase
for implementation of the Logistics Support Plan, and to satisfy Logistics
Support Analysis Record (LSAR) requirements.
REFERENCES: AR 71-1, AR 358-16, AR 602-1, AR 700-127, AR 715-6, AR
750-1
BLOCK 7.4—PREPARE INITIAL TEST PROGRAM AND PLANS
RESPONSIBILITY: Materiel Developer/Combat Developer
RESPONSIBILITY: The test program and plans address tests to be performed
by both the contractor and the Government. They are the Coordinated Test
Program (AR 70-10), Product Assurance Test Plan (AR 702-9), Post-Production
Test Plan (AR 702-XX), and User Test Plan (AR 71-3). These plans provide for
identification of personnel and materiel support required and for preparation of
test specifications. They are structured to ultimately encompass all test
requirements for the system, including research, feasibility, development,
operational, production, and post-production tests, up to system disposal.
The plans include such general concepts as time schedules, required test
facilities, available locations and facilities, planned quantities of items for test,
availability of items to be tested, number of items to be tested, training, and
planned Government and contractor personnel and materiel support for tests.
Environmental tests, safety tests, reliability tests, and others are included as
part of each test, as appropriate. For each of the applicable tests, criteria are
established for early identification and development of information relative to
required special test equipment, special calibration equipment, shop facilities,
air and ground vehicles, special fixed and mobile test facilities or sites, personnel
skills, and training. Criteria are established for data collection, recording,
storage, retrieval, analysis, and feedback of test data and analysis to correct
design and achieve system optimization. The plans include requirements for
accumulation and use of test data to preclude duplication of tests. In planning
the test program, requirements are established for determining mode of >
equipment transportation and scheduling to test site, and for determining and
identifying long lead time areas and access to special facilities.
Requirements for procedural data to be developed and delivered during
Demonstration and Validation, Full-Scale Engineering, Development, and
Production and Deployment Phases are included in the plans. These plans do not
include any tests which are required solely for operation or maintenance of the
system. These tests will have been included under Blocks 7.1 and 7.3
respectively.
REFERENCES: AR 70-1, AR 70-10, AR 70-15, AR 71-3, AR 71-9, AR 385-
16, AR 700-51, AR 702-9, AR 750-1

BLOCK 7.5—PREPARE INITIAL PRODUCTION PLAN

RESPONSIBILITY: Materiel Developer
DESCRIPTION: At this time, requirements for determining necessary re-
sourses and specifying schedules necessary to produce materiel are established
and incorporated into a Production Plan. The requirements for the plan will be
included in the Request for Proposal (RFP).
The RFP will require that the contractor formulate general concepts under
which the system is to be produced; establish feedback requirements and criteria
(plans, methods, techniques of production) to optimize design of the total
system; specify contractor claimed rights in data with a plan to minimize the
impact of such claims; establish requirements for determining the need for or

B-12
extent of production engineering establish requirements for management of
possible production sources; specify industrial security requirements for produc-
tion of system elements; establish quantitative production reliability goals,
trade-off limits, and production concepts; establish requirements for special
facilities, calibration equipment, and manufacturing test and inspection equip-
ment; establish production interfaces with operations, logistics support, test,
and deployment elements; formulate initial schedule and quantities of items or
systems for limited and continued production; establish requirements, when
applicable, for mobilization base planning, and production rates under emergen-
cy conditions; require that offerors predict the state of industrial technology
against a time base for future production of critical components; establish
requirements for identification of high production risk, high production costs,
long lead time items; identify unusual production requirements that will provide
a basis for system trade-offs; specify a requirement that proposals include
recommendations concerning the need for stockpiling and/or research and
development to alleviate possible future mobilization problems; determine
possible constraints to a short lead time resumption of production after it has
been discontinued for a number of years; and furnish the criteria to be used in
the evaluation of a Production Plan from the standpoint of the need for a
subsequent establishment of a mobilization base. Some of these criteria would
include the use of strategic or short supply materials, the use of piece parts or
components which required long lead time for processing or high level skills for
machining, personnel skills unique to the solely military nature of the produc-
tion, and dispersion of production facilities. Where hazardous materials are
involved, the offeror would also be required to specify safety requirements for
production, handling, and storage.
REFERENCES: AR 37-40, AR 385-16, AR 715-5, AR 700-18, AR 700-51, AR
715-50, MIL-D-1000, MIL-STD-100

BLOCK 7.6—PREPARE INITIAL MATERIEL FIELDING PLAN

RESPONSIBILITY: Materiel Developer
DESCRIPTION: A Fielding Plan is prepared to provide basic requirements for
initial deployment of the system. This plan includes the functions to be
performed to transport, receive, process, install, checkout and, as required,
store or activate at the user location. It includes sufficient requirements and'
related information for incorporation into the RFP. Care is exercised to ensure
compatibility with the Plan for Logistics Support. As a minimum, the Materiel
Fielding Plan includes the deployment concept, identification of possible modes
of transportation, and transportability characteristics that will require special
transport or special precautions during movement; estimate of special proce-
dures and processes related to receipt and processing of equipment; identifica-
tion of special installation and checkout requirements; identification of critical
procedures ralated to deployment activities; identification of estimated facility
and storage requirements and procedures; and identification of special training
requirements associated with deployment for inclusion in appropriate training
plans.
REFERENCES: AR 71-5, AR 702-3, AR 750-1

BLOCK 8.0—PROVIDE TECHNICAL INPUT TO REQUEST FOR PROPOSAL

RESPONSIBILITY: Materiel Developer
DESCRIPTION: Appropriate information resulting from Blocks 7.1, 7.2, 7.3,
7.4, 7.5, and 7.6 is provided for inclusion in the Request for Proposal. The
 FM 770-78

technical information furnished must satisfy the applicable requirements of AR

702-3 concerning RAM.
REFERENCES: AR 70-1, AR 70-27, AR 702-3
BLOCK 9.0—SYSTEM ENGINEERING FOR OPERATIONS ELEMENTS—PREP-
ARATION FOR PROPOSAL
RESPONSIBILITY: Offeror
DESCRIPTION: Upon receipt of the Request for Proposal resulting from
source selection approval, the offeror reviews the system specification, criteria
for trade studies, operations, maintenance, test, production, and deployment
plans to ensure that these elements have been properly considered and
integrated for creation of the best technically and economically balanced system.
The offeror applies system engineering to the operations requirements in order
to expand the system specification to reflect the offeror’s experience and planned
approach to meeting system requirements. A proposed system design approach
is selected and documented in Block 9.4. Application of the system engineering
process at this point will provide the necessary base for the offeror to expand the
Request for Proposal requirements for the logistics support, test, production,
and deployment areas, and perform efforts essential to development of a
proposal that reflects a balanced system design approach. The offeror must
exercise his full knowledge and experience in considering logistics support, test,
production, and deployment requirements because of their influence on the
proposed design approach.
The updated system specification (Block 9.4) is used as a basis for proposal
expansions of all program plans and development of the offeror’s proposal.
DESCRIPTION: AR 70-1
BLOCK 9.1—EXPAND FUNCTION ANALYSIS
RESPONSIBILITY: Offeror
DESCRIPTION: Upon receipt of the Request for Proposal, the offeror reviews
the system specification, criteria for trade studies, operations, logistics support,
test, production, and fielding plans to ensure that these elements have been
adequately considered and integrated into the functional models. The functional
models and functional requirements data provided by the Government are
compared with the offeror’s functinal model developed in anticipation of the
Request for Proposal. It may be necessary to modify the functions and their
sequencing to reflect the offeror’s technical experience and planned approach to
meeting the system requirements. The offeror expands the preliminary function-
al models furnished with the Request for Proposal to lower levels to adequately
portray the approach, and establishes associated function performance require-
ments. Alternative modes of operation are represented by alternative flows.
A time analysis is performed on time-critical functions. A function is
considered time-critical when the estimated time required to perform it has a
direct or contributory effort on reaction time, downtime, availability require-
ments, or utilization of resources.
The extent to which the functional model is expanded depends on whether
or not the functions are relatively well understood, are new and unique, or at
least represent an increase in capability. The modified and expanded functional
model is summarized in the offeror’s technical proposal.
FORMS: Functional Flow Block Diagram, Requirements Allocation Sheet, and
Time Line Sheet
REFERENCES: AR 70-1, AR 702-3, AR 715-6, AR 750-1

8-14
 FM 770-78

BLOCK 9.2—SYNTHESIZE CONCEPTUAL DESIGN

RESPONSIBILITY: Offeror
DESCRIPTION: Based on the functional performance requirements developed
as a result of function analysis (Block 9.1), an initial conceptual design is
developed. This synthesis is not restricted to the hardware of the system, but
includes all system elements. Schematic diagrams of various types are used as
tools in the synthesis process to provide visibility, traceability, and means of
communications. The primary objective of preparing such schematics is to
graphically portray and identify interfaces between system elements and to aid
in integrating performance requirements into specific element recommendations.
Requirements are identified which can be satisfied by using equipment
available in the DOD inventory or which are commercially available. Facility end
items are identified, particularly in the case of missile installations, fixed
communications facilities, and fixed command and control centers. Facilities,
training programs, equipment, and documentation are identified for which early
engineering development is required. The synthesis includes gross identification
of personnel tasks and an estimate of the number of personnel at various skill
levels required to operate and maintain the system. An estimate is made of
requirements and schedules for training programs, training equipment, facili-
ties, procedural data, and computer programs. Trade-off studies performed and
proposed trade-off studies to be accomplished along with design alternatives are
identified and described in sufficient detail to enable evaluation in Block 9.3.
FORMS: Schematic Block Diagram and Concept Description Sheet
REFERENCES: AR 70-1, AR 71-5, AR 702-3, AR 715-6, AR 750-1

BLOCK 9.3—EVALUATION AND DECISION

RESPONSIBILITY: Offeror
DESCRIPTION: The alternative resulting from expansion of the function
analysis and synthesis of conceptual design are evaluated from the standpoints of
time, life cycle costs, and performance. The extent of analysis, synthesis, and
evaluation depends on the depth of system engineering accomplished by the
offeror and his/her proposed system concept to fulfill the performance/design
requirements presented in the Request for Proposal. Trade-offs are performed
by the offeror using the criteria furnished with the Request for Proposal. These
trade-offs are both intratechnical, i.e., trade-offs of one design feature against
another and extratechnical, i.e., between operational performance, logistics
support, personnel skills and training, and facilities, as applicable. At this point,
risks are identified. Offerors may propose additional trade-off studies and their
method for accomplishment. Based on the evaluation, a conceptual design is
selected for proposal.
FORM: Trade-off Study Report
REFERENCES: AR 70-1, AR 702-3, AR 715-6, AR 750-1

BLOCK 9.4—UPDATE SYSTEM SPECIFICATION

RESPONSIBILITY: Offeror
DESCRIPTION: The system specification provided with the Request for
Proposal is updated by adapting the proposed system design approach to the
system specification. Care must be taken to preserve the basic Army require-
ments which established the functional baseline. The offeror is allowed maximum
flexibility within the basic system requirements to display his design approach.
Initial actions include: (1) evaluation of the requirements in terms of his own

B-15
FM 770-78

background knowledge, experience, and capabilities; (2) establishment of a

proposed approach to the requirements; and (3) assignment of responsibilities to
engineering elements within his organization for additional preliminary design
effort.
Results of engineering efforts are reflected in the updated proposed system
specification and the required system engineering documentation submitted as
part of the offeror’s proposal.
FORM: Design Sheets
REFERENCES: AR 18-1, AR 70-1, AR 715-6, AR 750-1,
BLOCK 10.0—DEVELOP PROPOSED DESIGN AND SUPPORT APPROACHES
RESPONSIBILITY: Offeror
DESCRIPTION: The offeror will use the updated system specification (Block
9.4) as the base for developing his proposed design approach for satisfying the
Request for Proposal requirements in the areas of operations, maintenance, test,
production, and deployment. This includes efforts performed under Blocks 10.1,
10.2, 10.3, 10.4, and 10.5. The outputs are proposed plans reflecting the offeror’s
approach for satisfying all the requirements for each activity area. The proposed
plans will comprise the technical inputs to the offeror’s proposal (Block 11.1).
REFERENCES: AR 70-1
BLOCK 10.1—DEVELOP PROPOSED DESIGN APPROACH
RESPONSIBILITY: Offeror
DESCRIPTION: The operational requirements specified by the system specifi-
cation contained in the Request for Proposal are reviewed to ensure that the
trade-offs made in developing a proposed design approach have retained system
compatibility and basic requirements. Trade-off studies performed in accordance
with the criteria furnished with the Request for Proposal are reviewed to ensure
the technical adequacy of the proposed design approach in satisfying operational
requirements. The offeror’s proposal will identify the trade-off studies to be
accomplished and the methodology to be employed. The operational characteris-
tics of the proposed desgin approach are evaluated against the operations
requirements to ensure adequacy of design approach and to establish a sound
base for making cost estimates, recommending schedules for development, and
preparing performance specifications for each end item.
The offeror’s design concept may be supported by functional and schematic
diagrams. The updating of operations performance requirements is accomplished
with respect to system readiness, survivability/vulnerability, penetrability,
damage limitation, range, safety, reliability, training requirements, maintainabi-
lity, transportability, number of installations required, types of facilities, and
others, as applicable.
FORMS: Schematic Block Diagram, Concept Description Sheet, Design Sheets
REFERENCES: AR 70-1, AR 385-16, AR 715-6, AR 750-1

BLOCK 10.2—DEVELOP LOGISTICS SUPPORT PLAN

RESPONSIBILITY: Offeror
DESCRIPTION: The offeror reviews the Maintenance Plan requirements in the
Request for Proposal for adequacy and compatibility with the system specifica-
tion to identify the required maintenance capabilities. The nature and the
number of any repair facilities to be provided as part of or in support of the
system, and requirements to be placed on common facilities, are identified. The

B-16
 FM 770-78

offeror prepares a plan which satisfies the requirements of a Contractor

Logistics Support Plan required by ILS and by AR 70-1.
A plan for providing any information which is new or different from that
provided by the Government is included in the proposed Contractor Logistics
Support Plan. This information pertains to data to be collected, procedures for
feedback of data, data analysis to be conducted, methods/techniques to be used
for data analysis, and utilization of maintenance and repair data to optimize
system design. A statement of any effort accomplished on maintenance evalua-
tion not covered elsewhere in the proposed support plan is included. Proposed
trade-off studies, and a plan for demonstrating the maintenance concept are
identified. A plan is proposed for development and delivery of requirement -
maintenance technical/procedural data during various phases of the system life
cycle, along with identification of parameters having an impact on maintenance
and the proposed technique for resolving any incompatibilities.
FORM: Trade-off Study Reports ,
REFERENCES: AR 70-1, AR 385-16, AR 602-1 AR 700-127, AR 715-6, AR
750-1, AR 1000-1

BLOCK 10.3—DEVELOP TEST PROGRAM AND PLANS

RESPONSIBILITY: Offeror
DESCRIPTION: The test program and plans received as part of the Request for
Proposal is realined in accordance with the proposal being prepared. The
proposal identifies tests to be performed by the contractor or the Government,
as well as contractor prepared support, test specifications, and test plans. In
addition to revising the nature of the tests to be performed, it may be necessary
to revise schedules, locations of tests, quantities of items to be tested, test
support, and test personnel required. The Coordinated Test Program and all
other test requirements are updated for alinement with the proposal udner
preparation. Concepts, methodology, techniques, approaches, and schedules are
prepared in response to the Request for Proposal. Specifically, the following are
identified: Government or contractor tests to be conducted at a Government
facility, period of time required, Government test equipment needed, and
Government personnal and materiel support required, requirements for special
test equipment, special facilities, and calibration equipment beyond those stated
by the Government in the test program and plans contained in the Request for
Proposal; methods and techniques to be employed to record, collect, store,
retrieve, analyze, and use test data for design optimization. This includes
requirements for any specific type of computer or computer lánguage for
interfacing with other programs; high technical test risk, high test cost, and long
lead time items; unusual requirements for transportation of equipments to the
test site, scheduling of tests, special tools, repair parts, and procedural data
needed, along with a proposed approach for development of a plan for generation
and delivery of required technical/procedural data; and special tests concerned
with nuclear weapons effects.
FORM: Test Requirements Sheet
REFERENCES: AR 70-1, AR 70-10, AR 70-15, AR 71-3, AR 385-16, AR 700-
51, AR 702-3, AR 702-9, AR 750-1, DA Pam 70-21
BLOCK 10.4—DEVELOP PROPOSED PRODUCTION PLAN
RESPONSIBILITY: Offeror
DESCRIPTION: In responding to the Request for Proposal, the offeror
proposes development of a productin plan consistent with the requirements of
B-17
FM 770-78

Block 7.5 and other specific program requirements. These include recommenda-
tions concerning production of the complete system by one source, use of prime
and subcontractor structure, or use of Government depot as a check and
assembly point for major system elements. The plan includes the proposed
development of a product assurance program for use during production. A plan
is proposed for specifying areas where production engineering will be required
and the lead time needed. In addition, “make-buy” and subcontracting procure-
ment plans are proposed. The plan includes the following: technique for feedback
for production data for design optimization; development of a plan for generation
and delivery of required procedural data; plan for processing ECR’s under the
configuration management plan; plan to minimize impact of contractor claimed
rights in data; and response to any mobilization requirements of the Request for
Proposal. High production risk, high production cost, and long lead time items
are identified as a basis for possible trade-offs; and, as requested, production
rates/scheduess are recommended.
REFERENCES: AR 37-^0
BLOCK 10.5—DEVELOP PROPOSED FIELDING PLAN
RESPONSIBILITY: Offeror
DESCRIPTION: The development of a Fielding Plan is proposed to incorporate
changes required by the proposed design approach and Logistics Support Plan.
The Fielding Plan must ensure consistency with the system configuration being
proposed and indicate any change which should be made in the Initial Fielding
Plan due to anticipated increase in system effectiveness or capabilities proposed
over those required in the Request for Proposal. For example, the number of
helicopters needed for complete surveillance of any area may be decreased due
to a proposed major increase in speed, decreased downtime, or increased speed
of data interpretation and evaluation.
Initial plans are updated for transportation of the system to the field, its
installations, checkout, and general concept for deployment. The updated plan
reflects the differences in conceptual design between that proposed by the
offeror and the Request for Proposal. As a minimum, the offeror’s response must
satisfy the requirements specified in Block 7.6. Applicable high-risk and high-
cost areas are identified.
REFERENCES: AR 71-5, AR 750-1
BLOCK n.O—INPUTS TO PROPOSALS
RESPONSIBILITY: Offeror
DESCRIPTION: EAch offeror prepares technical and managerial input to the
RFP as described in Blocks 11.1 and 11.2
REFERENCES: AR 70-1, AR 700-51
BLOCK 11.1—TECHNICAL INPUTS TO PROPOSALS
RESPONSIBILITY: Offeror
DESCRIPTION: Each offeror will utilize the technical information developed
under Blocks 10.1, 10.2, 10.3, 10.4, and 10.5 in preparation of his response to the
RFP, to include a planning proposal for follow-on development.
REFERENCES: AR 18-1, AR 70-1, AR 700-51
BLOCK 11.2—SYSTEM ENGINEERING MANAGEMENT PLAN
RESPONSIBILITY: Offeror
DESCRIPTION: Each offeror prepares a System Engineering Management

B-18
 1

FM 770-78

Plan for incorporation in his/her proposal. The plan must state how the bidder
proposes to effect system engineering management during Demonstration and
Validation and subsequent phases. The System Engineering Management Plan
includes proposed measures of effectiveness (MOE) models and techniques for
technical performance measurement.
REFERENCES: AR 70-1, AR 700-51
BLOCK 12.0—INPUTS TO WORK STATEMENTS AND DTI
RESPONSIBILITY: Materiel Developer
DESCRIPTION: Technical inputs are provided for inclusion in the Statement of
Work for the contracts to be awarded to the succèssful offerors. These inputs
will be those provided under Block 8.0, revised to incorporate any desirable
technical inputs which have been furnished by the offerors as part of their
proposals. Maintenance support requirements are revised, as necessary, to
include information provided by LSAR. Prior to submission of the revised
inputs, coordination is effectd with the Combat Developer to ensure that the
revisions are consistent with the Letter of Agreement. Inputs are also provided
for Development Test I (DT I), the first iteration of development testing. The
objectives of developmental tests are to demonstrate that design risks are
minimal, tha engineering development is on schedule, and that progress toward
achievement of system specifications is satisfactory. Evaluation of health and
safety characteristics of each system or item is conducted throughout develop-
mental testing.
RESPONSIBILITY: AR 18-1, AR 70-1, AR 71-9, AR 750-1
BLOCK 13.0—DEFINITION OF OPERATIONS REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: In system engineering Blocks 13.1, 13.2, 13.3, and 13.4, the
contractor, through the system engineering process, further definitizes the
system specified in the work statements (Block 12.0) using the approach
contained in his proposal. The activities in this cycle of the system engineering
process are restricted to the operation elements of the system to form a base for
defining requirements for the remaining system elements. Care must be taken
to observe the constraints imposed by the logistics support, test, production,
and deployment requirements. The output of this cycle of the system engineer-
ing process is a description of the selected operations elements (Block 13.4)
which provides a base for the System Requirements Review (Block 14). It also
provides a base for the system engineering activities concerned with logistics
support, test, production, and deployment.
REFERENCES: AR 70-1
BLOCK 13.1—FUNCTION ANALYSIS OF OPERATIONS REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: A detailed function analysis is performed to identify and define
the operations functions which must be accomplished. This analysis will be a
further iteration and expansion of the model prepared for the proposal modified
to incorporate requirements of revised work statements, if any, made by the
Government. And analysis of time-critical functions is performed as part of the
function analysis. An identification and analysis of those functions where system
life cycle costs are expected to be sensitive to incremental changes in the
requirements is preformed as part of the function analysis.
It is necessary to define operations prior to defining logistics support,, test,
production, and deployment functions. The selection of operations functions may

B—19
r

FM 770-78

be influenced by previously acquired contractor experience concerning logistics

support, test, production, and deployment considerations. Operations functions
which cannot be logically supported from maintenance, test, production, or
deployment standpoints are not to be selected. The alternative functional
approaches for meeting system operation requirements within the specified
performance envelope and trade-off criteria are considered. The ranges of
interest around the operations requirements are established where life cycle
costs, related to associated functions, are sensitive to incremental changes in the
requirements. Only those alternatives which offer significant payoffs in terms of
time, cost, and performance should be pursued.
Firm performance requirements are established for the operations functions
which will provide an acceptable level of operational capability. Ranges in the
performance requirements are maintained in those areas where significant
trade-off studies in preliminary design are required due to the projected
sensitivity of life cycle costs to the operations requirements. All performance
requirements are stated in sufficient detail for use as criteria for equipment
design and operation, and to define requirements for personnel, skills, tests,
facilities, computer programs,procedural instructions, and technical data. This
analysis is expanded to the point where sufficient information has been
developed to define the requirements for all operations elements of the system.
In coryunction with development of the detailed function model, an effectiveness
model is developed to be used as guidance for the evaluation of alternatives
performed in Block 13.3.
FORMS: Functional Flow Block Diagram, Reqiurements Allocations Sheet,
Time Line Sheet
REFERENCES: AR 70-1, AR 71-5, AR 71-9, AR 385-16, AR 602-1,
AR 702-3, AR 750-1

BLOCK 13.2—SYNTHESIS AND PRELIMINARY DESIGN OF OPERATIONS

ELEMENTS
RESPONSIBLITY: Contractor
DESCRIPTION: The preliminary design approach submitted with the porposal
is refined and expanded to incorporate the requirements defined by the detailed
function analysis. This is accomplished by revision of schematic diagrams and
development of additional schematics at lower levels of indenture. These
schematics show relationships among system elements to meet established
performance requirements, as well as changes in these relationships through
incremental changes in the requirements within the established ranges of
interest. In addition to synthesizing the operational equipment, requirements for
facilities, personnel, procedural data, and computer programs are defined. In the
translation of operations function requirements into design concepts, emphasis is
placed on quantification of performance requirements and design constraints.
Examples are: (1) input-output performance values and tolerances; (2) design
constraints such as power , size, weight, volume, interface, environment, and
human performance capabilities and limitations; (3) reliability, survivability,
vulnerability, producibility, safety, maintainability, and transportability
considerations.
Preliminary design of the operational equipment and facilities is carried to
sufficient depth to define the contactor’s recommended design approach. The
contractor also conducts studies using human factors engineering criteria and
methods to determine the training requirements, selection and design of training
equipment, man-machine interfaces, and establishment of the number and type
of personnel required. Logistics support, test, production, and development

B-20
 FM 770-78

impacts on design of operations equipment are given appropiate consideration

during this synthesis. Alternative design approaches and interfaces with other
segments of the system are identiñed and described in sufficient detail for
evaluation.
FORMS: Schematic Block Diagrams, Concept Description Sheets.
REFERENCES: AR 70-1, AR 71-5, AR 71-9, AR 385-16, AR 715-6, AR 702-
3, AR 750-1
BLOCK 13.3—EVALUATION AND DESIGN
RESPONSIBILITY: Contractor
DESCRIPTION: Trade-off studies are performed to select the optimum
combination of operational system elements. These studies include those
directerd by the statement of work and those necessary to provide the technical
subtantiation of requirements for equipment, facilities, procedural data, comput-
er programs, manpower, and training required. Requirements of the technical
specialties are identified and evaluations made on human factors engineering,sa-
fety, security, reliability, producibility, maintainability, and logistics support
impact on design approaches. A thorough evaluation is made on any high
technical risk techniques considered for achieving a major improvement in
operational performance, maintainability, production, and the areas where the
sensitivity of life cycle cösts to performance has been identified as significant,
The rationale for any such decisions is recorded.
Each synthesized combination of system elements and the proposed design
configuration of equipment unique to a given configuration are evaluated using
the system effectiveness model. The configuration of each major end item is
selected in consideration of man-machine relationships with respect to operation
and maintenance, safety and security, comparison of inherent reliabilities of
different design approaches, and the effect of design complexity on operating
reliability and maintenance. The advantages and disadvantages of designing or
selecting end items which require long lead time or high cost production are
considered along with their impact on deployment and maintenance. The
rationale for decisions made during this iteration is recorded.
FORM: Trade-Off Study Reports
REFERENCES: AR 70-1, AR 71-5, AR 71-9, AR 385-16, AR 602-1, AR 715-
6, AR 750-1
BLOCK 13.4—DESCRIPTION OF OPERATIONS ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: Detailed descriptions are prepared to enable formulation of a
technical design for each operational end item. The descriptions include essential
and desired operation features and specify numerical input-output values with
allowable tolerances.
These descriptions include considerations pertaining to safety, man-machine
interfaces, maintainability, survivability, vulnerability, reliability, producibility,
transportability, and the need for and interfaces with any supporting facilities.
The descriptions for all selected operations elements are supported by trade-offs
studies and by decisions, with rationale which led to selection of particular
elements. The descriptions define the elements in the following terms: equip-
ment—performance constraints, design, test, and evaluation requirements;
facilities—location, size, structural requirements, and equipment: personnel—
numbers, types (to include MOS’s where known), task performance times, and
required training; procedural data—procedures to be covered and the means for
B-21
r
FM 770-78

imparting or communicating to the user; and computer programs—purpose,

capability, input, and output requirements.
FORM: Design Sheets
REFERENCES: AR 18-1, AR 70-1, AR 71-5, AR 71-9, AR 385-16, AR 611-1,
AR 702-3, AR 750-1
BLOCK 14.0-SYSTEM REQUIREMENTS REVIEW
RESPONSIBILITY: Materiel Developer
DESCRIPTION: A separate review is held with each participating prime
contractor to ensure that the demonstration and validation effort is proceeding
toward the objective in a logical manner. The materiel developer will ensure that
the reviews are conducted so that creative or proprietary differences of the
contractors are not compromised. In a competitive Demonstration and Valida-
tion Phase, the Government agencies participating must be careful to provide
only negative guidance so as not to direct any one contractor toward a
Government solution.
The operations elements in Block 13.4 are reviewed with each contractor to
ensure that systems requirements are being met. Specific attention is directed
toward a review of contractor interface documentation to ensure that compatibil-
ity is being maintained. Conceptual designs developed in Block 13.2 and selected
in Block 13.4 furnish the basic information necessary for the review and
evaluation of interface problems and solutions. This review ensures that
adequate consideration has been given to logistics support, test, production, and
deployment constraints. Compatibility of data is verified for LSAR and
management purposes.
Contractor and materiel developer recommendations and actions to be taken
as a result of the review are documented. The materiel develper directs spécifié
attention to maximum use of Government-furnished equipment without compro-
mising the capability of meeting total system requirements stated in the
ROC/LR.
REFERENCE: AR 70-1

B-22
BLOCK 15.0—DEFINITION OF LOGISTICS SUPPORT REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: In Blocks 15.1, 15.2, 15.3, and 15.4, the contractor accom-
plishes logistics support analysis of the operations equipment and facilities
described as a result of the activities of Block 13.4, to determine logistics
support functions and to identify logistics support elements. This represents a
portion of the logistics support analysis required by ILS. Using the system
engineering process, the contractor optimizes the logistics support elements
while observing the constraints imposed by operations, production, test, and
deployment requirements. If the logistics support elements have an adverse
effect on other system elements, the iterative process is repeated in the
appropriate functional cycles using the new logistics support parameters
developed. The integrity of the operations functional requirements must be
preserved throughout the system engineering process while creating and
maintaining an optimum economical and technical balance. This application of the
system engineering process results in the Initial Description of Logistics
Support Elements (Block 15.4). It also provides inputs to System Design
Optimization Trade-Offs (Block 19.0).
REFERENCES: AR 70-1, AR 700-127
BLOCK 15.1—INITIAL FUNCTION ANALYSIS OF LOGISTICS SUPPORT
REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The contractor identifies logistics support functions based
upon the logistics support requirements of the operations equipment and
facilities resulting from the activities described in Block 13.4. Each gross
function is expanded in detail, to the level necessary to ensure adequate
definition of the logistics support requirements to satisfy demonstration and
validation objectives. The logistics support function analysis completely de-
scribes the logistics support functions imposed by system requirements and
constraints. The performance requirements associated with each logistics
support function are developed.
An analysis of the time critical logistics support functions is conducted. The
analysis depicts the concurrency, overlap, and sequential relationship of the
various logistics support functions. This analysis may indicate regroupings or
resequencing of logistics support functions to decrease overall maintenance time
and cost, or to decrease downtime required for logistics support. The develop-
ment of maintenance function requirements will be in accordance with specified
system reliability and maintainability requirements.
FORMS: LSAR Forms, End Item Maintenance Sheet, Requirements Allocation
Sheet, Time Line Sheet
REFERENCES: AR 70-1, AR 385-16, Ar 602-1, AR 700-127, AR 750-1
BLOCK 15.2—SYNTHESIS AND PRELIMINARY DESIGN OF LOGISTICS
SUPPORT ELEMENTS
RESPONSIBILITY: CONTRACTOR
DESCRIPTION: Based on the analysis of the logistics support functions,
synthesis and preliminary design is performed to define major logistics support
elements. Equipment selection must be in accordance with established logistics
support concepts. Peculiar equipment and facilities required by the logistics
support functions are determined and selected. Quantities of equipment are
related to requirements for facilities, personnel and training, procedural data,
f
FM 770-78

and computer programs. Items of logistics support equipment and facilities are
correlated with associated system logistics support functions and functional
performance requirements. Schematics are used to relate logistics support
elements to their function requirements and interfaces, and to provide visibility
and traceability.
As in the case of operations, the requirements specified for logistics support
personnel and training will be preliminary in nature. The identification of
complete personnel and training requirements will be dependent upon additional
design effort and maintenance engineering analysis. Sufficient information must
be developed concerning personnel and training requirements for an evaluation
of the selected logistics support elements. Technical approaches for preliminary
design are verified and all high risk and high cost areas identified. The
operations equipment availability requirement, reliability plan, maintainability
plan, product assurance plan, and proposed maintenance allocations are re-
viewed for their impact on the preliminary design approach. Alternatives are
determined, identified, and described in sufficient detail to establish a base for
trade-off studies.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 70-1, AR 71-5, AR 385-16, AR 602-1, AR 750-1
BLOCK 15.3—EVALUATION AND DECISION
RESPONSIBILITY: Contractor
DESCRIPTION: An evaluation of logistics support preliminary design is
accomplished and trade-offs made with risk identified to provide a technical and
economic balance between selected logistics support equipment, facilities,
procedural data, personnel, training, and computer programs. The trade-off
studies provide the basis for allocation of logistics support functions and design
requirements.
The evaluation of logistics support preliminary design and the decision
process for selection of logistics support elements include consideration of
requirements for all echelons including depot maintenance; selection of logistics
support elements that may be utilized for all maintenance levels; maximum
utilization of selected test, production, and deployment elements, and product
assurance and calibration equipment throughout all levels of logistics support;
utilization of product assurance requirements and concepts throughout the
spectrum of logistics support activities; an optimum balance among selected
logistics support elements and specified requirements for system reliability and
system equipment maintainability; and feedback of function performance re-
quirements to ensure incorporation of necessary maintainability design features
into operations equipment.
FORM: Trade-Off Study Reports
REFERENCES: AR 70-1, AR 71-5, AR 385-16, AR 602-1, AR 750-1, TM 38-
703
BLOCK 15.4—INITIAL DESCRIPTION OF LOGISTICS SUPPORT ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The performance and design requirements for each selected
end item of logistics support equipment and facilities provide the basis for
proposed development specifications. The logistics support elements are de-
scribed in the following terms: equipment—performance, constraints, design,
test, and evaluation requirements; facilities—location, size, structural require-
ments, and equipment; personnel—number, types (to include MOS’s, where

B-24
 FM 770-78

known), task performance times, and required training; procedural data—

procedures to be covered and the means for imparting or communicating them to
the user; and computer programs—purpose, capabilities, input and output
requirements.
The descriptions of logistics support elements resulting from the system
engineering process as applied to maintenance will provide the basis for
preparing the Logistics Support Plan and input data to LSAR. The related
quality assurance requirements form an important part of these documented
descriptions. The Logistics Support Plan will become more definitive as system
definition and development progresses. The descriptions of logistics support
elements are inputs to the System Design Optimization Trade-Offs (Block 19.0)
and provide a sound basis for cost estimation.
FORM: Design sheets
REFERENCES: AR 18-1, AR 70-1, AR 71-5, AR 71-9, AR 385-16, AR 611-1,
AR 750-1, TM 38-703
BLOCK 16.0—DEFINITION OF TEST REQUIREMENTS
RESPONSIBILITY: Contractor ^
DESCRIPTION: In Blocks 16.1, 16.2, 16.3, and 16.4, the contractor, utilizing
the description of operations elements (Block 13.4) as a base, develops test
functions and functional performance requirements and selects test elements for
the total system. Using the system engineering process, the contractor identifies
and optimizes the test elements while observing the constraints imposed by the
operations, production, logistics support, and deployment elements. This opti-
mization includes an analysis of the number of items to be tested. Test elements
for utilization in all areas of life cycle testing are identified. During advanced
development, engineering development, and initial production, the Single
Integrated Development Test Cycle policy will be observed to ensure develop-
ment and sharing of integrated data.
If the test elements selected to satisfy test functions have an adverse effect
on the operations elements (Block 13.4) or other system elements, the iterative
process is repeated for the appropriate functional area. The integrity of the
operations function requirements must be preserved while creating and estab-
lishing an optimum economic and technical balance throughout the system life
cycle. The results of the system engineering process on test elements appear in
the Initial Description of Test Elements (Block 16.4). They are also inputs to
System Design Optimization Trade-Offs (Block 19.0).
REFERENCES: AR 70-1, AR 70-10, AR 70-15, AR 71-3, AR 71-9, AR 702-3,
AR 750-1, DA Pam 70-21
BLOCK 16.1—INITIAL FUNCTION ANALYSIS OF TEST REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The proposed test plans are reviewed to identify tests to be
made on operations, logistics support, production, and deployment elements of
the system. Included are those tests of the system and its elements required by
the various engineering specialties. Based upon the synthesis and preliminary
design resulting from the system engineering process as applied to the other
functional areas, a function analysis is performed to identify all system test
functions and functional performance requirements for test elements.
All test function performance requirements are identified and described in
sufficient detail to permit synthesis of test equipment, facilities, personnel,
procedural data, and computer programs. Test function alternatives are identi-

B—25
FM 770-78

fied and their performance requirements are described in sufficient detail for
thorough consideration in trade-off studies. Function analysis relates functional
performance requirements to the test functions. Time requirements analysis is
performed for time critical test functions.
FORMS: Requirements Allocation Sheet, Test Requirement Sheet
REFERENCES: AR 70-1, AR 70-10. AR 71-3, AR 71-9, AR 385-16
BLOCK 16.2—SYNTHESIS AND PRELIMINARY DESIGN OF TEST ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: This synthesis defines the test elements needed to satisfy all of
the test requirements identified by the test function analysis of Block 16.1. It is
performed in consideration of requirements for all test elements to include test
equipment, instrumentation, and test procedures; calibration instruments and
facilities; testing facilities; data collection, analysis, storage, and retrieval
methods; computer programs for automated tests; personnel; and extent of data
required to achieve a stated level of confidence.
Changes in the preliminary design for any of the operations, logistics
support, production, or deployment elements could significantly affect test
requirements. Therefore, technical personnel engaged in activities relative to
definition of these operations, logistics support, production, and deployment
elements must provide continuous consultation and guidance during application
of the system engineering process to the test functional area. Alternative test
methods and elements are identified and described in sufficient detail to provide
a basis for trade-off studies. Schematics are used to postulate design concepts,
define interfaces, and provide traceability. Special attention is given to selection
of test elements that may be utilized in multiple test areas. This consideration
includes collection of test data (beginning with feasibility test) for joint
utilization throughout all life cycle phases.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 70-1, AR 70-10, AR 71-3, AR 71-9, AR 385-16, AR602-1
BLOCK 16.3—EVALUATION AND DECISION
RESPONSIBILITY: Contractor
DESCRIPTION: This evaluation of the various test methods and elements
synthesized under Block 16.2 is performed from two standpoints: the configura-
tion of test elements which will provide the optimum test program in regard to
performance, cost, and schedule; and the configuration of test elements which
will provide the best technical and economic balance between the test program
and the operations, logistics support, production, and deployment areas of the
system. Configuration of test elements which comprise a particular test program
are evaluated in terms of test set-up times, speed of data acquisition, accuracy of
measurement with respect to desired accuracy limits, number of personnel, mix
of personnel skills required, degree of automation, degree of calibration of
instruments, commonality of test equipment for different tests, amenability of
data to quick and accurate interpretation, and accessibility and applicability of
data for use in later stages of development or production.
Trade-off studies are performed for achieving the best technical and
economic balance with risks identified among test functions, performance
requirements, personnel, facilities, number of test samples, schedules, costs,
programs, procedures, equipments, and technical data requirements. Evaluation
must ensure that necessary design features for test of operations and logsitics
support equipment are identified in order to accomplish the required test

B-26
 FM 770-78

functions. These required design features are provided to the technical person-
nel responsible for design evaluation of the impact to test design approaches.
Test elements are selected which provide optimal utilization throughout life
cycle testing of the materiel. Concepts, methodology, and techniques are
selected which will optimize collection and utilization of data for all tests.
FORM: Tratle-Off Study Reports
REFERENCES: AR 70-1, AR 70-10, AR 71-3, AR 71-9, AR 385-16, AR602-1
BLOCK 16.4—INITIAL DESCRIPTION OF TEST ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The performance and design requirements for each selected
end item of test equipment, facilities, and computer programs are documented to
provide the basis for proposed development specifications. The descriptions
identify the elements in the following terms: equipment—performance con-
straints, design, test and evaluation requirements; facilities—location, size,
structural requirements, and equipment; personnel—numbers, types (to include
MOS’s, where applicable and known), task performance times, and required
training; procedural data—procedures to be followed and the communication
media to be used; and computer programs—purpose, capabilities, input, and
output requirements. Interfaces are defined and documented to provide a sound
base for cost estimates and total system trade-off studies to achieve the best
technical and economic balance for test of all system elements. The descriptions
of test elements are an input to Block 19.0 for System Design Optimization
Trade-Offs and cost estimation.
FORM: Design Sheet
REFERENCES: AR 18-1, AR 70-10, AR 71-3, AR 71-9, AR 385-16, AR 611-
1, AR 702-3
BLOCK 17.0—DEFINITION OF PRODUCTION REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The results of the system engineering process on production
elements appear in the Initial Description of Production Elements (Block 17.4).
They are inputs to the system Design Optimization Trade-Offs (Block 19.0).
REFERENCE: AR 70-1
BLOCK 17.1—INITIAL FUNCTION ANALYSIS OF PRODUCTION
REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: Based upon the description of operations, logistics support,
test, and deployment equipment items, a function analysis is performed to
identify functions and their performance requirements necessary to synthesize
concepts for efficient and economic production of system end items in confor-
mance with quality standards and at specified rates required to satisfy program
objectives. Production alternatives are identified and described by alternate
functional models in sufficient detail to provide a base for trade-off studies. A
time requirements analysis is performed for each time-critical production
function.
The system engineering process is applied to the production functional area
to the degree necessary to establish the concepts under which the system will be
produced and to determine the requirements for any special or unique
production capabilities required. This is not intended to replace or duplicate the

B-27
FM 770-78

production engineering normally performed by industrial contractors. Instead, it

is accomplished to interface production engineering with system engineering in
the areas necessary to determine the impact of production on system design,
eliminate production risks, identify and support trade-offs, and provide a basis
for cost estimating.
The contractor utilizes the descriptions of operations, logistics support, test,
and deployment elements (Blocks 13.4, 15.4, 16.4, and 18.4) as a base, and
develops requirements for the production elements needed to produce the
system. In Blocks 17.1, 17.2, 17.3, and 17.4, through the system engineering
process, he identifies and optimizes the means for efficiently and economically
producing the system elements while observing the constraints imposed by the
operations, test, logistics support, and deployment activities.
A continuous interplay of information is maintained between the system
engineering process for production elements and the system engineering process
for the operations, maintenance, test, and deployment elements in order to
ensure compatibility of the selected production elements with all other system
elements. Function performance requirements establish a basis for special or
unique production equipment, facilities, personnel, skills, computer programs,
and procedural data essential to the economic and efficient production of and
preparation for delivery of all system items. The function analysis includes
consideration of production engineering to match the capabilities of current or
achievable industrial production techniques and processes. The requirements are
stated in terms of rate of production, accuracy, lead time, production flow,
tolerances, and environment (e.g., air conditioning, “clean room”). Identification
and definition of unusual and special requirements are established (e.g., plant
facilities, machine tools, special tooling, special test equipment, jigs, fixtures,
dies). Special consideration is given to unusual performance requirements for
procedural data, manufacturing personnel, manufacturing techniques and pro-
cesses, safety, quality control, industrial security, material flows, tolerance
allocations, materials, and preservation, packaging, and packing for shipment of
system items. When contractually stipulated, the analyses includes consider-
ation of future mobilization requirements for expansion of the production
equipment base, and retention, preservation, use, and ultimate disposition of
production equipment and facilities. Changes in operations, logistics support,
test, deployment functions, and design approaches can materially influence the
production functions and performance requirements.
FORMS: Production Sheet, Requirements Allocation Sheet, Time Line Sheet
REFERENCES: AR 37-40, AR 385-16, AR 700-15

BLOCK 17.2—SYNTHESIS AND PRELIMINARY DESIGN OF PRODUCTION

ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: Various production concépts are formulated which will enable
performance of the production functions delineated under Block 17.1. These
concepts should describe the types and quantity of production elements needed.
Prime contractor “make or buy” considerations are established on a preliminary
basis. Potential sources of supply (vendors) are tentatively identified relative to
all major system items. High risk and high cost production areas, long lead time
items, and production areas involving contractor claimed rights-in-data are
identified. Production elements and processes that affect operations, logistics
support, test, and deployment elements must be provided to the technical
personnel responsible for definition of these elements. Critical interfaces are
identified and defined. Production-critical items are identified. Production

B-28
 FM 770-78

essential to deployment. Schematic diagrams are used to identify each deploy-

ment element, provide visibility and traceability, and establish interfaces. The
assurance that all interfaces are properly identified, established, and maintained
is accomplished through continuous liaison among technical personnel responsi-
ble for the definition of operations, logistics support, test, and production
elements. It is essential during this synthesis that high risk, high cost, and long
lead time deployment items, safety, and security requirements are identified and
described in sufficient detail to establish a basis for trade-off studies.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 70-1, AR 385-16
BLOCK 18.3—EVALUATION AND DECISION
RESPONSIBILITY:. Contractor
DESCRIPTION: The contractor evaluates deployment functions, functional
performance requirements, and deployment elements in terms of validity of
performance requirements and feasibility of the technical approach. This
includes evaluation of deployment alternatives and trade-offs for selection of
deployment elements. The rationale for decisions is documented. Information
concerning decisions which affect other system elements is furnished to the
technical personnel responsible for the affected elements. Trade-off studies are
performed, with risks identified, to achieve the best technical and economic
balance between deployment functions and all deployment elements. Considered
in the trade-off studies are the functional performance requirements in relation
to deployment equipment; personnel skills and training requirements; facilities,
including land; procedural data; and computer programs.
FORM: Trade-Off Study Reports
REFERENCE: AR 70-1
BLOCK 18.4—INITIAL DESCRIPTION OF DEPLOYMENT ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: Descriptions are developed for all selected deployment ele-
ments. The descriptions identify the elements in the following terms: equip-
ment—performance, constraints, design, test, and evaluation requirements:
facilities—location, size, structural requirements, and facility equipment; per-
sonnel—^numbers, types (to include MOS’s, where known), task performance
times, and required training; procedural data—procedures to bè covered and the
means for imparting or communicating to the user; and computer programs—
purpose, capability, input, and output requirements. The documented descrip-
tions describe types, quantities, and availability of equipment selected. These
initial descriptions of deployment elements provide input to Block 19.0 and
establish a base for further trade-off studies involving operations, logistics
support, test, production, and deployment elements to achieve the best technical
and economic balance. The description will also provide input to the updated
fielding plan (Block 22.6).
FORM: Design Sheet
REFERENCE: AR 18-1, AR 611-1
BLOCK 19.0—SYSTEM DESIGN OPTIMIZATION TRADE-OFFS
RESPONSIBILITY: Contractor
DESCRIPTION: The criteria for trade-off studies which were developed in
Block 7.2 are used at this time to perform trade-offs and to optimize the

B-31
FM 770-78

preliminary design of the system. The optimum preliminary design of the system
is that design which represents the best combinaion of equipment, facilities,
personnel, procedural data, and computer programs. These elements have been
selected separately to perform the operations, logistics support, test, produc-
tion, and deployment functions. The criteria for selection of “best combination”
are overall performance in terms of the measures of effectiveness models (Block
11.2), fulfillment of system specification requirements, life cycle costs, and the
capability of meeting deployment schedules. Trade-off decisions and rationale,
with risks identified, are documented.
FORM: Trade-Off Study Report
REFERENCES: AR 70-1, AR 71-5, AR 750-1

BLOCK 20.0—SYSTEM DESIGN REVIEW

RESPONSIBILITY: Materiel Developer, Contractor
DESCRIPTION: A system design review is held by the Materiel Developer
separately with each prime contractor to ensure that design approaches are
responsive to the system performance objectives established in the system
specification. The Combat Developer, Trainer, and other Army agencies, as
needed, participate in this review.
The description of operations elements selected by contractors as represent-
ing their optimum preliminary design of the system are reviewed and evaluated.
Special attention is directed toward interface documentation, high risk areas,
long lead times, and trade-off studies involving all functional areas. The Material
Developer will ensure that this review is conducted so that creative or
proprietary differences of the contractors are not compromised. Government
agencies must be careful to provide only negative guidance so as not to direct
any one contractor toward a solution preferred by the Government.
At this review it will be determined whether or not the proposed
combination of operations, logistics support, test, production, and deployment
elements of the system has an effect on program concepts, prior estimates of
quantity or types of equipment and facilities needed, or personnel requirements.
The Materiel Developer reviews the description of proposed system elements to
ensure that the System Design Optimization Trade-Offs, with risks identified
(Block 19.0), fiilly integrate the operations, logistics support, test, production,
and deployment requirements. In instances where a contractor has identified the
requirement for Government-furnished equipment in the DOD inventory, the
Materiel Developer shall validate the availability of the items.

BLOCK 21.0—PRODUCE PROPOSED DEVELOPMENT SPECIFICATIONS

RESPONSIBILITY: Contractor
DESCRIPTION: Based upon decisions from the system design review, Develop-
ment Specifications are prepared for all proposed configuration items. The
Specification Tree and the Work Breakdown Structure are revised to reflect any
additions or deletions. It may not be possible to identify and define every
configuration item in the system during the Demonstration and validation Phase.
The need for some items of equipment is dependent upon the detail design of
major end items, and may be established during the Full-Scale Engineering
Development Phase.
REFERENCES: AR 18-1, AR 70-1, AR 71-1, MIL-STD-490

B-32
 FM 770-78

design alternatives are determined and described in sufficient detail to provide a

basis for trade-off studies, cost estimates, evaluations, and decisions.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 37-40, AR 700-51
BLOCK 17.3—EVALUATION AND DECISION
RESPONSIBILITY: Contractor
DESCRIPTION: An evaluation of the various production concepts synthesized
under Block 17.2 is accomplished from the standpoints of cost, effectiveness, and
potential availability. Cost includes investment in new manufacturing processes
and procuring of new machinery; effectiveness includes production rates,
accuracy of manufacture, assembly rates, quality control methods, ratio of
acceptable items produced to total items produced; and potential availability is a
measure of the lead time required to acquire necessary machinery, processes,
and special handling equipment, and to hire and train new personnel. Trade-off
studies which consider the above parameters are conducted to arrive at an
optimal concept, with risks identified, for the production of operations, logistics
support, test, and deployment equipment items. An evaluation and determina-
tion is made of the impacts that are created on design of operations, logistics
support, test, and deployment equipment by use of the alternative synthesized
manufacturing processes and techniques.
An important consideration in the evaluation of synthesized concepts is the
need for establishment of a mobilization base. A concept which will ensure quick
initiation of production a number of years after multiyear procurements have
been completed is more desirable from this standpoint than a concept which does
not have this attribute.
FORM: Trade-Off Study Reports
REFERENCES: AR 37-40, AR 700-15, AR 700-51
BLOCK 17.4—INITIAL DESCRIPTION OF PRODUCTION ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: Initial descriptions of production elements, production alterna-
tives, and trade-off studies will be documented with rationale used as the basis
for selection. This documentation will provide a basis for overall trade-off studies
which may be found necessary between the production elements and the
elements comprising operations, logistics support, test, and deployment to
ensure the best technical and economic balance for production of the total
system.
The production elements will be described in the following terms: equip-
ment—performance, constraints, design, test, and evaluation requirements:
facilities—location, size, structural requirements, and equipment: personnel—
number, skills, task performance times, required training, and rate of buildup of
production force; procedural data—procedures to be followed with respect to
receipt and inspection of incoming materials, manufacturing processes, degree of
automation, assembly processes, and preparation for shipment; and computer
programs—purpose, capabilities, input, and output requirements.
The description of selected production elements provides the basis for
updating the Proposed Production Plan (Block 10.4) which now must represent
an optimum of performance, cost, and schedules for production of system items.
The preliminary Product Assurance Program is reviewed to ensure compatibility
with the Initial Description of Production Elements. The description of selected

B—29
 1

FM 770-78

production elements will be an input to Block 19.0 (System Design Optimization

Trade-Offs) and to the Updated Production Plan (Block 22.5).
FORM: Design Sheets
REFERENCES: AR 18-1, AR 37-40, AR 611-1, AR 700-15, AR 700-51, MIL-
STD-120
BLOCK 18.0—DEFINITION OF DEPLOYMENT REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The contractor develops requirements for the elements needed
for deployment of the operations and logistics support elements of the system.
The system engineering process is conducted to identify and optimize these
deployment elements within the constraints imposed by the opertions, logistics
support, test, and production functional areas. If the deployment elements
selected have an adverse effect on the operations elements or other system
elements, the iterative process is repeated in the appropriate functional area.
The integrity of the operations function requirements must be preserved while
creating and establishing an optimal economic and technical balance throughout
the system.
The results of application of the system engineering process to the
deployment functional area appear in the Initial Description of Deployment
Elements (Block 18.4). They are inputs to the System Design Optimization
Trade-Offs (Block 19.0).
REFERENCE: AR 70-1
BLOCK 18.1—INITIAL FUNCTION ANALYSIS OF DEPLOYMENT
REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: A function analysis is performed on operations and logistics
support equipment and facilities to derive their initial deployment requirements.
This analysis identifies system deployment functions and function performance
requirements necessary for initial deployment of the system under each of the
different types of operations or environments in which the system may be
employed. The deployment functional model is expanded to lower indenture
levels as necessary to identify the functional performance requirements essential
to the selection of major deployment elements. Deployment alternatives are
depicted by alternate functional models. A time requirements analysis is
performed to determine the optimum concurrency or sequencing of actions which
will ensure timely deployment under each type of operation or environment.
FORMS: Functional Flow Block Diagram, Requirements Allocation Sheet, Time
Line Sheet
REFERENCE: AR 70-1

BLOCK 18.2—SYNTHESIS AND PRELIMINARY DESIGN OF DEPLOYMENT

ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: Based upon the requirements established by function analysis,
synthesis is conducted to define the major and unique deployment elements of
the system. All major items of equipment needed for deployment are identified,
and sufficient preliminary design accomplished to clearly indicate the design
approach necessary for inclusion in the development proposal. The synthesis will
ensure that the elements are adequate and suitable for performing actions

B-30
BLOCK 22.0—UPDATE PROPOSED DESIGN APPROACH
RESPONSIBILITY: Contractor
DESCRIPTION: The contractor uses the results of the System Design Review
(Block 20.0) as the basis for updating his/her System Specification, System
Design, Logistics Support, Test, Programs and Plans, Production, and Fielding
Plans. The technical outputs are provided as inputs to the allocated baseline.
BLOCK 22.1-UPDATE SYSTEM SPECIFICATION
RESPONSIBILITY: Contractor
DESCRIPTION: From technical information developed and decisions made
during Demonstration and Validation, the System Specification is expanded and
updated to include overall system performance requirements, design approach,
personnel utilization, training, and test requirements. The updated System
Specification, along with the development specification for each proposed
configuration item, will describe the contrctor’s recommended allocated baseline.
If, as a result of the validation effort, the contractor determines that changes to
the System Specification are necessary or will provide significant improvements
to the system capability, he/she recommends these changes in accordance with
established configuration management procedures.
REFERENCES: AR 18-1, AR 70-1, AR 71-5, AR 71-9, AR 385-16, AR 602-1,
AR 750-1, MIL-STD-480, MIL-STD-481

BLOCK 22.2—UPDATE SYSTEM DESIGN

RESPONSIBILITY: Contractor
DESCRIPTION: The preliminary design of the system optimized in Block 19.0
is updated to be consistent with the Proposed Development Specification
prepared under Block 22.1. The updated system design must satisfy all
functional baseline requirements.
REFERENCES: AR 70-1, AR 71-5, AR 71-9, AR 750-1, MIL-STD-490, MIL-
STD-100, MIL-D-100

BLOCK 22.3—UPDATE LOGISTICS SUPPORT PLAN

RESPONSIBILITY: Contractor
DESCRIPTION: The Logistics Support Plan proposed under Block 10.2 is
updated to incorporate information generated by the system engineering
activities of the Validation Phase. The updated plan will include quantitative
reliability and maintainability goals such as maintenance man-hours and elapsed
time needed to perform the major maintenance functions of periodic inspection,
routine preventive maintenance, field testing and checkout, and removal and
replacement of major components in each end item of equipment; a plan by which
achievement of the above goals may be demonstrated; a plan for maintenance of
logistics support facilities; organizational alloation of maintenance functions;
nature and number of repair facilities to be provided as part of, or in support of
the system; personnel numbers, types (to include MOS’s, where known), task
performance times, and required training; plan for collection, feedback, analysis,
and utilization of maintenance and repair data during system development,
production, and operation (data content and format must satisfy requirements of
the Logistics Support Analysis Record); plan for development and delivery of
maintenance procedural data during various phases of the system life cycle; plan
for detection of design parameters having an impact on support and a description
of techniques for resolving such impact; and identification of tests indigenous to
support of the system (these tests will not be included in the updated test plan).
FM 770-78

The maintenance equipment, facilities, personnel, training, computer pro-

grams, and procedural data included in the updated Logistics Support Plan must
be consistent with the proposed Development Specifications prepared under
Block 21.0 and the expanded System Specifications prepared under Block 22.1
FORMS: LSAR, End Item Maintenance Sheet
REFERENCES: AR 70-1. AR 700-127. AR 750-1, TM 38-703
BLOCK 22.4—UPDATE COORDINATED TEST PROGRAM
RESPONSIBILITY: Contractor
DESCRIPTION: Using information developed under Block 16.0 as a base, the
test program and plans are updated to conform with actions taken under Blocks
21.0 and 22.1 and to ensure conformance with the test concept set forth in the
updated system specification. The test plans identify test objectives, the number
of items to be tested, numbers and types of tests required, testing objectives,
testing schedules, funding requirements, and test support requirements. The
plan will be of a preliminary nature since it is dependent upon detailed design of
equipment items. The plan will become more definitive as the development
program progressed.
Based upon the effort accomplished under Block 16.0 the following determi-
nations are documented in the test plans: tests for validation of compliance with
proposed development specification requirements; tests required to verify
compliance with product assurance, and quantitative reliability and maintainabi-
lity goals; tests required on logistics support facilities; identification of special
test equipment, special calibration equipment, supply or maintenance facilities,
special fixed and mobile test facilities that require early development; proposed
plan for test data recording, collection, storage, retrieval, analysis, and feedback
of design optimization, including techniques for accumulation and use of test data
to preclude duplication of tests; identification of major end items to be subjected
to nuclear weapons effects testing, including long lead time requirements and
required access to special facilities; proposed plan for development and delivery
schedule of test/procedural data, test specifications, and test plans throughout
the materiel life cycle; required mode of equipment transportation and schedul-
ing to test site; and requirements for special tools, repair parts, and technical
documentation. The test plans with supporting documents must satisfy the
allocated baseline test requirements.
FORM: Test Requirements Sheet
REFERENCES: AR 70-1, AR 70-10, AR 70-15, AR 71-3, AR 71-9, AR 702-3,
AR 750-1, DA Pam 70-21
BLOCK 22.5—UPDATE PRODUCTION PLAN
RESPONSIBILITY: Contractor
DESCRIPTION: Using information developed under Block 17.0 as a base, the
Production Plan (Block 10.4) is updated to reflect the description of production
elements and ensure conformance with the production concept set forth in the
Demonstration and Validation Phase contract.
Based upon the effort accomplished under Blocks 17.0, 17.1, 17.2, 17.3 and
17.4, the following determinations will be documented in the proposed produc-
tion plan: general concept for production of the system; requirements and
proposed plan for development of procedural data necessary to effect production
(to include production equipment specifications and drawings, formulas, meth-
ods, procedures, techniques, facilities, quality controls, and the proposed
method for processing ECR’s approved under the configuration management

B-34
 FM 770-78

plan); requirements for production engineering with required lead time; require-
ments for production management capability, technical capability, quality
controls, potential for quantity production and possible supply sources; industrial
safety and security requirements; quantitative production reliability goals;
recommended production rates and schedules; high production risk and cost,
long lead time items and unusual production requirements; recommendations
relative to establishment of a production base for mobilization with production
rates and schedules; proposed plan for identification of contractor claimed rights-
in-data and their impact on production and costs; plans, methods, and techniques
for feedback of production information for system design optimization; recom-
mendation for contractor structure to produce the total system equipment (to
include prime contractor structure, subcontractor structure, or Government
facilities as check and assembly points for major system elements); and proposed
“make or buy” plan and subcontracting procurement plan. The Production Plan
must satisfy all the allocated baseline production requirements.
FORM: Production Sheet
REFERENCES: AR 70-1, AR 37-40, AR 385-16, AR 700-51, AR 702-3, MIL-
STD-100, MIL-D-100

BLOCK 22.6—UPDATE FIELDING PLAN

RESPONSIBILITY: Contractor
DESCRIPTION: The Fielding Plan is updated using information developed
under Block 18.0. It will include the proposed approach for accomplishment of
functions such as transportation, receiving, processing, installation, checkout,-
and required emplacement, housing, storing, or activation at the user location.
All major items of equipment and facilities needed for deployment, as well as any
safety and security requirements, are identified. The plan must be consistent
with the system configuration being proposed, and the collateral logistics
support, test, and production plans.
REFERENCES: AR 70-1, AR 70-17, AR 71-5, AR 385-16, AR 611-1

BLOCK 23.0—TECHNICAL INPUTS TO ALLOCATED BASELINE

RESPONSIBILITY: Contractor
DESCRIPTION: The demonstration and validation contractor assembles all the
technical outputs of Blocks 21.0 and 22.0 and provides them as technical inputs
to the allocated baseline. These technical inputs consist of the expanded Systems
Specifications, updated Development Specifications (Allocated Configuration
Identifications), and updated recommended support, test, production, and
deployment plans. The technical inputs to the allocated baseline will provide part
of the basis for the engineering development contract negotiations.
REFERENCES: AR 18-1, AR 70-1, AR 70-37, AR 702-3, AR 715-6

BLOCK 24.0—INPUTS TO PRODUCIBILITY ENGINEERING AND PLANNING

(PEP) AND DT II TEST DESIGN PLAN
RESPONSIBILITY: Contractor
DESCRIPTION: PEP should be initiated as soon as production requirements
are established, but no later than DT II/OT II. Its purpose is to ensure a smooth
transition from development to production, anticipating potential manufacturing
problems, and seeking design and schedule trade-offs to facilitate the manufac-

B-35
FM 770-78

turing process. DT II is designed to measure technical performance (e.g., RAM,

compatibility, interoperability, safety, supportability) of the system and its
associated support equipment, training, and logistics support packages; to
demonstrate that engineering is reasonably complete; that solutions are in hand
for all significant design problems; and that the system is ready for transition to
production. The test is designed to require maximum exchange of test data
between the contractor and materiel developer.
REFERENCES: AR 70-1, AR 70-10, AR 70-27, AR 70-37, AR 71-3, AR 700-
90

B-36
 FM 770-78

B—4. The Full-Scale Engineering Development Phase velopment projects. It involves detail design, devel-
(Fig. B-3) opment, and production of operations, logisitics
support, test, deployment, and production
a. The Full-Scale Engineering Development Phase
equipment.
begins with validation IPR/ASARC II/DSARC II
approval that advanced development (brassboard) c. In instances when demonstration and validation
prototypes and their associated allocated configura is not mandatory, this phase may follow the Alterna-
tion identifications (allocated baselines) describe tive Systems Concepts Phase, and include those
prototypes which will satisfy approved materiel needs functional processes and management procedures
stated in the ROC/LR. The phase ends with an which are normally accomplished during validation.
engineering development prototype which very close- While development and production are separate func-
ly approximates the anticipated final product along tions which may be contracted on an individual basis,
with its documentation and test results which support they may overlap as determined by production engi-
a descision to enter the Production and Deployment neering programs and type-classification actions.
Phase. d. Blocks 25.0 through 43.0 describe system engi-
b. This phase of the materiel life cycle applies to all neering activities in the Full-Scale Development
engineering development and operational system de- Phase.

(Locate fig. B-3, a fold-out, at the end of this

manual.)

B-37
FM 770-78

fi

SYSTEM ENGINEERING ACTIVITIES

FULL-SCALE ENGINEERING DEVELOPMENT PHASE

BLOCK 25.0—SYSTEM ENGINEERING INPUTS TO PLANS AND SCHEDULES

RESPONSIBILITY: Materiel Developer/Contractor
DESCRIPTION: This input is generated from the system engineering activities
which were accomplished during demonstration and validation and as provided
by ILS. It consists of the technical approaches selected to satisfy the
requirements for which the project was established and other engineering
information pertinent to the establishment of development, production, and test
schedules; cost estimates; management and information systems; logistics
support plans; and personnel staffing plans. This input provides a means with
which to define, identify, and control various interfaces at predetermined points
in time throughout the materiel life cycle, and ensures proper relationships of
the design efforts to system engineering activities.
REFERENCES: AR 70-1, AR 70-17, AR 70-27, AR 70-37, AR 71-5, AR 71-9,
AR 611-1, AR 750-1
BLOCK 26.0—COMPLETION OF PRELIMINARY DESIGN FOR OPERATIONS
ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The completion of preliminary design for operations elements
must be accomplished early in the Full-Scale Engineering Development Phase.
The validation contractor(s) will normally have accomplished preliminary design
for the operations elements to the indenture level necessary for formulation of
firm proposals to enter the Full-Scale Engineering Development Phase. In those
instances where a formal Demonstration and Validation Phase is not required,
i.e., where a program proceeds directly from Alternative System Concepts to
the Full-Scale Engineering Development Phase, it becomes even more essential
that the system engineering process be applied early in development for
completion of preliminary design of operations elements. These provide a basis
for detail design and for performing preliminary design of logistics support, test,
production, and deployment elements. Following award of the development
contract, Blocks 26.1, 26.2, 26.3, and 26.4 describe the system engineering
activities necessary for completion of preliminary design for operations ele-
ments. The documented descriptions of operational elements, Block 26.4,
provide the necessary base for the preliminary design characteristics review
(PDCR) of operation elements (Block 27.0). The completion of the PDCR
establishes a firm base for detail design of operations elements and for
definitization of requirements for logistics support, test, production, and
deployment elements.
REFERENCES: AR 70-1

BLOCK 26.1—FUNCTION ANALYSIS

RESPONSIBILITY: Contractor

B-38
DESCRIPTION: The function analysis conducted during demonstration and
validation is expanded to indenture levels necessary to establish all operation
function performance requirements for completion of preliminary design for
operations elements. The additional function performance requirements are
firmly established and stated in sufficient detail for use as criteria for equipment
design and operation, personnel skills and tasks, facilities, computer programs,
and procedural data. A time requirements analysis is performed for any time
critical functions.
FORMS: Functional Flow Block Diagram, Requirements Allocation Sheet, Time
Line Sheet
REFERENCES: AR 70-1, AR 385-16, AR 602-1, AR 700-47, AR 702-3, MIL-
D-1000, MIL-STD-100
BLOCK 26.2—SYNTHESIS AND COMPLETION OF PRELIMINARY DESIGN
RESPONSIBILITY: Contractor
DESCRIPTION: Synthesis and preliminary design of operations elements are
completed as lower indenture level function performance requirements are
established during the function analysis. Schematic diagrams are used to portray
selected operations elements and their arrangement and interfaces in the
system. A continuous interchange of engineering information is maintained
among operations, logisitcs support, test, production, and deployment design
activities. Visibility and traceability are provided by schematic diagrams. High
risk, high cost, and long lead time items are identified. The preliminary designs
for operations equipment and facilities are completed in order to establish a base
for initiation of detail design. All required equipment, facilities, personnel,
procedural data, and computer programs are identified. Alternatives are
determined, identified, and described in sufficient detail to establish a basis for
trade-off studies.
FORMS: Schematic Diagrams, Concept Design Sheets
REFERENCES: AR 70-1, AR 385-16, AR 700-47, AR 702-3, MIL-D-1000,
MIL-STD-100
BLOCK 26.3—EVALUATION AND DECISION
RESPONSIBILITY: Contractor
DESCRIPTION: Evaluation is made of the prelimary design accomplished to
satisfy functional performance requirements. Trade-off studies are conducted to
establish a technical and economic balance among operations elements with
minimum risk. Care is taken to ensure that this balance is retained for the total
system. The evaluation and decision process ensures that the preliminary
designs for operations equipment and facilities are sufficiently complete and
adequate to provide a firm base for application of the system engineering process
to logistics support, test, production, and deployment functional areas.
FORMS: Trade-Off Study Reports
REFERENCES: AR 70-1, AR 385-16, AR 602-1, AR 700-47, AR 702-3, MIL-
D-1000, MIL-STD-100

BLOCK 26.4—DESCRIPTION OF OPERATIONS ELEMENTS

RESPONSIBILITY: Contractor
DESCRIPTION: The performance requirements and preliminary design of
selected operations equipment and facilities are documented to provide a firm
base for detail design. Descriptions are produced for all selected operations
FM 770-78

elements in the following terms: equipment—performance, constraints, design,

test, and evaluation requirements; facilities—location, size, structural require-
ments, and equipment; personnel—numbers, types (to include MOS’s where
known), task performance times, and required training; procedural data—
procedures to be covered and the means for imparting or communicating them to
the user; and computer programs—purpose, capabilities, and input and output
requirements. All requirements, including interfaces, are identified, defined,
and documented to achieve the best technical and economic balance for the total
system.
FORMS: Design Sheet, Facilities Interface Sheet
REFERENCES: AR 70-1, AR 385-16, AR 602-1, AR 700-47, AR 702-3, MIL-
STD-100A, MIL-D-1000A
BLOCK 27.0—PRELIMINARY DESIGN CHARACTERISTICS REVIEW OF
OPERATIONS ELEMENTS
RESPONSIBILITY: Materiel Developer/Contractor/Combat Developer
DESCRIPTION: Preliminary design characteristics reviews (PDCR) are con-
ducted for each operations configuration item (Cl) and facility. The purpose of
the review is to ensure that the preliminary design approach in terms of
equipment, facilities, personnel, procedural data, and computer programs is an
acceptable design solution to total system and configuration item requirements.
The combat developer, trainer, and other Army agencies, as needed, participate
in this review. The basic documentation reviewed includes the requirements
sections of the system, and development specifications and the system engineer-
ing data generated during preliminary design of operations equipment and
facilities. Considerations at the time of a preliminary design characteristics
review include compliance with established design criteria, evaluation of
engineering drawings, breadboards/brassboards and models, interface between
configuration items, schedule compatibility, and life cycle costs. Preliminary
design characteristics reviews are conducted on an incremental basis and,
whenever possible, on related groups of operations equipment. They are
accomplished in accordance with the schedule and attendance requirements
specified in provisions of the development contract. Action items resulting from
a PDCR can be made contractually binding only by appropriate action of the
procuring contracting officer. During this review, information will be available
for inclusion in the Logistics Support Analysis Record (LSAR) to assist in
preparation of maintenance and other logistics support requirements by location.
REFERENCES: AR 70-1, AR 385-16, AR 602-1, AR 750-1, MIL-STD-100A,
MIL-STD-490, MIL-D-1000A

BLOCK 28.0—DETAIL DESIGN OF OPERATIONS EQUIPMENT AND

FACILITIES
RESPONSIBILITY: Contractor
DESCRIPTION: The technical data, such as function diagrams, function
performance requirements, time requirements analysis, and schematic diagrams
generated from preceding system engineering activities, provide the logic and
constraints for detail design. Based on this data and the engineering drawings,
breadboards/brassboards and models developed by preliminary design effort is
directed toward accomplishing design in the detail required for manufacturing,
instruction, programing, operating, and inspecting. It is an objective of system
engineering to ensure that detail design efforts are coordinated and comprehen-
sive, and that all engineering disciplines and technologies have been integrated
to obtain an optimum final system design. Operations facility requirements, if

B-40
 FM 770-78

any, are considered in order to ensure proper equipment and facility interfaces.
Methods of ensuring design coordination and completeness include prescribing
documentation approval and release procedures and establishing communication
flows to obtain an adequate exchange of expertise. Although shown as a single
block on the flow diagram, detail design of operations equipment and facilities is
a continuous effort and is not completed until approval and release of Product
Configuration Identification. The effort overlaps the detail design of logistics
support, test, production, and deployment equipment and facilities, and is
influenced by the requirements of those designs.
REFERENCES: AR 70-1, AR 385-16, MIL-STD-100A, MIL-STD-480, MIL-
• STD-481,MIL-STD-482, MIL-D-1000A

BLOCK 29.0—DEFINITION OF ADDITIONAL LOGISTICS SUPPORT

REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: As detail design of operations equipment and facilities pro-
gresses (Block 28.0), the system engineering process is directed toward the
development of additional logistics support requirements for each configuration
item in order to define additional logistics support elements. During this
process, the logistics support requirements developed during the Demonstration
and Validation Phase and documented in Logistics Support Analysis Record
(LSAR) are refined and expanded. The detail design of operations equipment
(Block 28.0) is a continuing and progressive activity over a long period of time in
the Full-Scale Engineering Development Phase. Therefore, this process for
defining detailed logistics support requirements must progress over time in
concert with the detail design activity. As logistics support production and test
equipment items and facilities are designed, they are also analyzed to determine
their logistics support requirements. The process continues until all logistics
support elements required by the system have been selected and defined. This
process constitutes the maintenance engineering analysis required by ILS and
the data output is provided in a format compatible with LSAR. The description
data is used to update LSAR and provide the basis for the preliminary design
characteristics review of logistics support elements (Block 33.1) and detail
design of logistics support equipment and facilities (Block 34.2).

BLOCK 29.1—DETAIL FUNCTION ANALYSIS OF ADDITIONAL LOGISTICS

SUPPORT REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: As designs evolve for operations and logistics support equip-
ment and facilities, an analysis of each of these items is conducted to determine
the logistics support functions and performance requirements for each. Qualita-
tive and quantitative requirements are established for each logistics support
function identified. The logistics support function ananlysis is carried to the
lowest reparable nonstandard component for each configuration item; however,
the depth of analysis necessary depends to some extent on the complexity or
uniqueness of the configuration item. This function analysis is an expansion in
detail of that initiated in the Demonstration and Validation Phase. The objective
is to identify what has to be done to ensure that the system, subsystem, or
component is maintained in an operable condition. A time requirements.
ananlysis is conducted for maintenance functions which are critical from the
standpoint of system or equipment downtime or utilization of maintenance
resources.

B-41
FM 770-78

FORMS: Requirements Allocation Sheet, End Item Maintenance Sheet (LSAR),

Time Line Sheet
REFERENCES: AR 70-1, AR 70-17, AR 700-127, AR 750-1

BLOCK 29.2—SYNTHESIS AND PRELIMINARY DESIGN OF ADDITIONAL

LOGISTICS SUPPORT ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: Based upon the function analysis, a synthesis is accomplished
to derive a combination of system elements that satisfy the logistics support
functional requirements. Man/machine support equipment relationships are
important considerations in synthesis. Product assurance and calibration re-
quirements are considered in this synthesis. The synthesis is expressed in terms
of design retjuirements and design approaches for equipment and facilities and
their interface, personnel tasks to be performed, task performance times,
training and training equipment required, procedural data, and computer
program requirments. The objectives are reduction in total manpower, level of
technical skills and training required, and the probability and consequences of
human error; use of standard parts, maintenance equipment, calibration
components, modules, tools, and test equipment; interchangeability of parts,
components, modules; accessibility for adjustment, calibration, and repair;
reduction of repair frequency; use of throw-away and metered components;
speed in malfunction diagnosis and fault isolation; reduction in repair time and
downtime; and time between overhaul extensions based upon section replace-
ment for components. Alternative logistics support elements are identified and
described in sufficient detail to enable evaluation and decision.
FORMS: Schematic Block Diagram, Concept Design Sheet
REFERENCES: AR 70-1, AR 385-16, AR 602-1, AR 700-127, AR 702-3, AR
750-1, TM 38-703.

BLOCK 29.3—EVALUATION AND DECISION

RESPONSIBILITY: Contractor
DESCRIPTION: A continuous evaluation is performed to select logistics
support elements from among the alternatives which have been synthesized.
This evaluation includes trade-off studies to determine those methods, ap-
proaches, and techniques which can best meet the requirements. Typical
subjects for study include levels of logistics support, quantity of equipment,
facility utilization, degree of automation for maintenance, technical risk, and
total predicted costs. The equipment, repair parts, personnel, training, and
facility requirements, and requirements imposed on the rest of the system by
the solution selected are identified. The most promising design approaches are
selected and the rationale for their selection is documented. Decisions that affect
other system elements are coordinated with the personnel responsible for the
affected elements.
FORMS: Trade-Off Study Report
REFERENCES: AR 702-3, AR 750-1
BLOCK 29.4—DESCRIPTION OF ADDITIONAL LOGISTICS SUPPORT
ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The description of logistics support elements documented in
the Demonstration and Validation Phase is updated and expanded to incorporate

B-42
 FM 770-78

BLOCK 30.4—DESCRIPTION OF ADDITIONAL TEST ELEMENTS

RESPONSIBILITY: Materiel Developer/Contràctor
DESCRIPTION: Complete descriptions of test elements are developed based
upon decisions reached during the evaluation and decision process. These
descriptions state the design and performance requirements for equipment and
facilities needed to accomplish test functions on operations and logistics support
elements of the system. They accommodate and comply with constraints
imposed by operations and logistics support procedures, previously specified test
facilities, and location and types of test personnel. The descriptions define
performance parameters including tests and measurements to be performed,
accuracies required, reliability, redundant requirements, and methods of perfor-
mance. Software requirements are also described. Drawings, associated lists,
and other documents oriented toward test equipment items and facilities are
prepared. End items are described in terms of performance and design
requirements. Personnel are described in terms of tasks, skill levels, perfor-
mance capabilities, and responsibilities. Facilities are described by their
purpose, capabilities, and input-output requirements. Test .data requirements
are described in terms of the type, method of collection, presentation dissemina-
tion, and purposes.
FORMS: Design Sheet
REFERENCES: AR 18-1, AR 70-1, AR 70-10, AR 70-37, AR 71-3, AR 611-1,
AR 702-3, MIL-D-1000A, MIL-STD-480, MIL-STD-481, MIL-STD-482

BLOCK 31.0—DEFINITION OF ADDITIONAL PRODUCTION

REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: As detail design of operations and logistics support equipment
progresses, the system engineering process is applied to the production
functional area to identify the requirements for any additional unique production
elements. During this application of the process, production performance
requirements developed during the Demonstration and Validation Phase are
refined and expanded. The detail design operations and logistics support
equipment is a continuing and progressive activity in the Full-Scale Engineering
Development Phase. This process for defining production requirements must
progress in concert with the detail design activity. The process continues until
unique production elements required by the system have been selected and
defined.

BLOCK 31.1—DETAIL FUNCTION ANALYSIS OF ADDITIONAL

PRODUCTION REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: As designs for equipment and facilities are completed, a
function analysis of the production requirements for each configuration item is
performed. This analysis is an expansion of the analysis initiated in the
Demonstration and Validation Phase. Its purpose is to determine additional
unique production functions to be performed. The analysis establishes the
performance requirements for production elements essential to the economical
and efficient production of system items. Consideration is given to unusual
requirements for procedural data, personnel skills, manufacturing techniques
and processes, quality control, material flows, and packaging and packing for
shipment of system items. The function analysis continues during detail design

B-45
FM 770-78

to establish unique process and tasks required for adequate and timely
modifications. A time requirements analysis is performed for time-critical
production functions.
FORMS: Functional Flow Block Diagram, Requirements Allocation Sheet,
Production Sheet, Time Line Sheet
REFERENCES: AR 37-40

BLOCK 31.2—SYNTHESIS AND PRELIMINARY DESIGN OF ADDITIONAL

PRODUCTION ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: Additional elements required to produce operations, logistics
support, test, and deployment equipment are identified. This identification
includes requirements and approaches for special and unique facilities, machine
tools, materials, personnel skills, manufacturing processes and techniques,
computer programs, procedural data, special tooling, inspection and test
equipment jigs, fixtures, quality control, and packaging and packing to ship
system items. Schematic diagrams are used to identify selected production
elements. Preliminary designs of unique production equipment and facilities are
developed and compared to production function performance requirments in
order to ensure that barrier requirements have been met. Special consideration
is given to high production risks and costs, and long lead time items previously
identified. Alternative production methods are identified and described in
sufficient detail to provide sound bases for trade-off studies used in evaluation
and decision.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 37-40, AR 611-1, AR 700-51

BLOCK 31.3—EVALUATION AND DECISION

RESPONSIBILITY: Contractor
DESCRIPTION: An evaluation of the synthesis of production methods and the
preliminary design of unique production and facilities is performed by conducting
effectiveness and trade-off studies to determine the best combination of
production elements. Only reasonable approaches that are within the state-of-
the-art minimum technical risk, or economically achievable advances in industri-
al technology are pursued. A continuous exchange of data is maintained between
all system engineering activities to determine impact on production elements
when modifications to the operations, logistics support, test, and deployment
equipment items are made. Trade-offs are made, production elements selected,
and preliminary design established.
FORMS: Trade-Off Study Reports
REFERENCES: AR 37-40, AR 71-9, AR 700-51, MIL-STD-100

BLOCK 31.4—DESCRIPTION OF ADDITIONAL PRODUCTION ELEMENTS

RESPONSIBILITY: Contractor
DESCRIPTION: The description of production elements as documented during
the validation phase are updated and expanded to describe in detail the
additional elements required. The descriptions identify elements in terms of
personnel—numbers, types, duties, task performance times, and required
training; equipment—performance, design, quality control criteria, and evalua-

B-46
 FM 770-78

the latest and best technical and economic balance for the system elements.
Items of equipment are described in terms of performance, design, test, and
evaluation requirements. Personnel are described in terms of numbers, types (to
include MOS’s where known), task performance times, and required training.
Facilities are described in terms of location, size, structural requirements, and
facility equipment. Computer programs are described by their purpose, capabili-
ties, and their input and output requirements. Procedural data requirements are
described in terms of the procedures to be covered and the types of manuals
required. Logistics support elements are described in sufficient detail to provide
the system engineering inputs to integrated logistics support.
FORMS: Design Sheet
REFERENCES: AR 18-1, AR 71-5, AR 602-1, AR 611-1, AR 702-3, AR 750-
1, TM 38-703

BLOCK 30.0—DEFINITION OF ADDITIONAL TEST REQUIREMENTS

RESPONSIBILITY: Materiel Developer/Contractor
DESCRIPTION: As detail design of operations and logistics support equipment
progresses, the system engineering process is applied to the test functional area
to identify the requirements for any additional test elements. During this
application of the process, the test requirements which were developed during
validation are expanded and refined. The detail design of operations and logistics
support equipment is a continuing and progressive activity in the full-scale
development phase. This process for defining detail test requirements must
progress in concert with the detail design activity. The process continues until
all test elements required by the system have been selected and defined.

BLOCK 30.1—DETAIL FUNCTION ANALYSIS OF ADDITIONAL TEST

REQUIREMENTS
RESPONSIBILITY: Materiel Developer, Contractor
DESCRIPTION: The detail function analysis of test requirements is accom-
plished as detail design of operations equipment (Block 28.0), description of
additional logistics support elements (Block 29.4), and the test plans develop.
This function analysis is conducted to identify critical parameters which require
testing to demonstrate satisfaction of the ROC/LR, system specifications, and
development specifications. Test plans concern those activities involved in
testing and evaluation of the operations and logistics support elements to
determine their suitability and conformance to detailed technical requirements.
These tests do not include those inherent in the operations mission or in the
maintenance of the operations equipment and facilities. In performing the
analysis, various charts and diagrams are prepared to define the test functions to
be performed on each operations logistics support configuration item. This
analysis is carried to the level necessary to prescribe all system test require-
ments during the Full-Scale Engineering Development and Production and
Deployment Phases. A time requirements analysis is performed for critical test
functions. Test requirements analyses must be conducted in conjunction with the
operation and logistics support cycles and the test plans in order to develop
design requirements for all categories of test and checkout equipment. Each
iteration of the operations and logistics support cycles introduces new require-
ments or constraints on the test functions. Time-phased planning of test
functions is conducted at this time. The test function analysis can be completed
only when operations and logistics support elements have been firmly defined.

B-43
FM 770-78

FORMS: Functional Flow Block Diagram, Requirements Allocation Sheet, Test

Requirement Sheet, Time Line Sheet
REFERENCES: AR 70-1, AR 70-10, AR 70-15, AR 71-3, AR 385-16, AR 702-
3, AR 750-1
BLOCK 30.2—SYNTHESIS AND PRELIMINARY DESIGN OF ADDITIONAL
TEST ELEMENTS
RESPONSIBILITY: Materiel Developer, Contractor
DESCRIPTION: Based upon the function analysis, a synthesis is accomplished
to devise methods for meeting test function requirements. Various approaches
which incorporate the combination of procedures, equipment, and personnel
skills are synthesized. Special consideration is given to the amount of built-in
test capability, and the degree of failure diagnosis and fault location required to
successfully accomplish objectives of the test program; compatibility with
multipurpose, automatic diagnostic equipment in the field and the test site;
minimum requirements for special test equipment; requirements for test
equipment access points or connections; built-in sensors or measuring devices,
such as those needed for telemetry; simulation techniques, where applicable; and
requirements for testing by the Government. Wherever possible, contractor
testing and data will be used to satisfy Materiel Developer requirements and'
objectives. During synthesis, awareness of existing test equipment and facility
capabilities is required to preclude unnecessary development of special test
equipment, facilities, and computer programs; identification of the personnel
skills, numbers, and training required to perform test functions; and procedural
drafts and detailed test procedures prescribing methods for performance of test
functions. Preliminary design of new test equipment and facilities is accom-
plished, and requirements for off-the-shelf items and existing facilities are
documented. Preliminary design and detailed test procedures are compared with
test function requirements in order to ensure that all requirements have been
met. Operations and maintenance procedural requirements are considered as
constraints on the test equipment and procedures package.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 70-1, AR 70-10, AR 71-3, AR 385-16, AR 602-1, AR 702-
3

BLOCK 30.3—EVALUATION AND DECISION

RESPONSIBILITY: Materiel Developer/Contractor
DESCRIPTION: Comparison and trade-off studies are conducted on the various
options developed during synthesis and preliminary design. The objective is the
formulation of decisions which optimize the selection and usage of test
equipment, facilities, and procedures, and minimize requirements for special test
elements. The factors involved in making these decisions include mission,
operations, and design characteristics of the equipment, anticipated and/or
required reliability, maintenance structure, equipment and personnel available
to the tester, operations environment, logistics support requirements, technical
risk, and development time and costs. Special purpose, general purpose, and
built-in test equipment are compared on the basis of the above factors. Trade-
offs of manual vs. automatic, and built-in vs. portable test instrumentation and
data collection equipment are accomplished during the evaluation. The above
factors are a basis for determining sample size, replications, and data accuracy.
FORMS: Trade-off Study Report
REFERENCES: AR 70-1, AR 70-10, AR 71-3, AR 702-3, AR 750-1

B—44
 FM 770-78

BLOCK 33.0—PRELIMINARY DESIGN CHARACTERISTICS REVIEW (PDCR)

OF LOGISTICS SUPPORT ELEMENTS
RESPONSIBILITY: Materiel Developer/Contractor
DESCRIPTION: The objective of this review is to ensure that design require-
ments approved, established, and contracted against at the end of the Demon-
stration and Validation Phase can be achieved; engineering design approach
taken by the contractor is technically feasible and sound; and detail design can
implement the design approach. Changes to development engineering documen-
tation are made to reflect changes to design, design approach, personnel tasks,
facility requirements, training and training equipment requirements, and
procedural data. This review establishes that the logistics support elements are
still compatible with previously accomplished design or that Engineering Change
Requests have been initiated and approved to meet updated requirements. The
approved data will update Logistics Support Analysis Records (LSAR).
REFERENCES: AR 602-1, AR 700-127, AR 750-1
BLOCK 34.0—PRELIMINARY DESIGN CHARACTERISTICS REVIEW (PDCR)
OF TEST ELEMENTS
RESPONSIBILITY: Materiel Developer/Contractor/Combat Developer
DESCRIPTION: When test elements have been fully described, a preliminary
review of their characterisitcs is undertaken and the selected approach for
testing is verified. Through this review, the responsible activities ensure that

«
the testing approach is reasonable and is within the state-of-the-art. They
ensure that all test requirements can be met within the time and funding
constraints of the program and that maximum utilization of test data is made to
meet test requirements.
REFERENCES: AR 70-1, AR 70-10, AR 71-3, AR 71-9, AR 385-16, AR 700-
51, AR 750-1

>•
B—49
FM 770-78

BLOCK 35.0—PRELIMINARY DESIGN CHARACTERISTIC REVIEW (PDCR) OF

PRODUCTION ELEMENTS
RESPONSIBILITY: Materiel Developer, Contractor
DESCRIPTION: This review is conducted on each unique item of production
equipment, facilities, and associated production elements. It is intended to
evaluate the producibility of the operations and logistics support equipment
items, evaluate the adequacy of procedural data, ensure compatibility with the
product assurance program and technical adequacy of the selected designs, and
determine compatibility with the system specification.
REFERENCES: AR 37-40

BLOCK 36.0—PRELIMINARY DESIGN CHARACTERISTICS REVIEW (PDCR)

OF DEPLOYMENT ELEMENTS
RESPONSIBILITY: Materiel Developer, Contractor
DESCRIPTION: This review is conducted to evaluate the progress and
technical adequacy of the selected design approach in order to determine its
compatibility with the initial description as prepared during validation. Prelimi-
nary design characteristics reviews are held by the materiel developer to ensure
that all deployment aspects are duly considered prior to detail design. These
reviews provide for any changes updating of plans and documents to reflect
these changes prior to commencing detail design.
REFERENCE: AR 70-1

BLOCK 37.0—SYSTEM DESIGN OPTIMIZATION

RESPONSIBILITY: Contractor
DESCRIPTION: The optimum detail design of the system is that design which
represents the best combination of system elements which have been selected to
perform the operations, logistics support, test, production, and deployment
functions. The criteria for selection of this “best combination” are overall
performance in terms of fulfillment of system specification requirements, life
cycle costs, and elapsed time needed to meet deployment schedules. The criteria
developed under Block 7.2 (Develop Criteria for Trade-Off Studies) will have
been included in the contract work statement and will be utilized in performing
trade-offs to achieve the best combination of system elements. The trade-off
studies, including risk analysis, are documented with the rationale that led to the
decisions and submitted to the Government as required by the terms of the
contract.
REFERENCES: AR 70-1, AR 700-51

BLOCK 38.0—DETAIL DESIGNS

RESPONSIBILITY- Contractor
DESCRIPTION: Based on the satisfactory completion of the Preliminary
Design Characteristics Review of logistics support, test, production, and
deployment elements, Blocks 38.1, 38.2, 38.3, and 38.4 describe the detail design
of these elements. Output of the detail design activities will be in the form of
detained engineering' documentation which defines the configuration of each
element.

B-50
 FM 770-78

tion requirements: facilities—location, size, structural requirements and equip-

ment; procedural data—procedures to be covered and documentation for
imparting the data to the user; and computer programs—purpose, capabilities,
input, and output requirements.
FORM: Design Sheets
REFERENCES: AR 18-1, AR 37-40, AR 611-1, AR 700-51, MIL-STD-100A,
MIL-D-1000A
BLOCK 32.0—DEFINITION OF ADDITIONAL DEPLOYMENT
REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: As detail design of operations and logistics support equipment
and facilities progresses, the system engineering process is applied to the
deployment functional area to identify the requirements for any additional
deployment elements. The detail design of operations and logistics support
equipment and facilities is a continuing and progressive activity in the Full-Scale
Engineering Development Phase. Therefore, this process for defining deploy-
ment requirements must progress in concert with detail design activity. The
process continues until all deployment elements required by the system have
been selected and defined. Data output from this iterative process will be used to
update existing documentation. The process will provide sufficient data for the
PDCR of deployment elements (33.4) and detail design of deployment equipment
(Block 34.5).
BLOCK 32.1—DETAIL FUNCTION ANAYLSIS TO ADDITIONAL
DEPLOYMENT REQUIREMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: As detail designs are completed for the operations and logistics
support equipment and facilities, a function analysis of additional deployment
requirements for the system and/or each end item is accomplished. This analysis
is conducted in conformance with the fielding plans which were prepared and
updated during the Demonstration and Validation Phase. This analysis is to
determine additional and specific deployment functions to be performed to
transport, receive, process, install, checkout and, as required, store or activate
the system at user location. The analysis considers physical movement in the
light of distribution and transportation capabilities, and to the extent practica-
ble, identifies functional requirements associated with primary transportation
modes and unusual or specialized movement and handling requirements. The
function analysis continues during detail design to establish adequate and timely
processes and tasks. For each function identified, the performance requirements
are stated in definitive terms to provide a basis for selecting the system
elements necessary to achieve the objectives of the fielding plan. A time
requirements analysis is accomplished in consideration of critical and emergency
situations which may affect time for activation of operations and maintenance
equipment and facilities.
FORMS: Functional Flow Block Diagram, Requirements Allocation Sheet, Time
Line Sheet
REFERENCES: AR 70-1, AR 70-17
BLOCK 32.2—SYNTHESIS AND PRELIMINARY DESIGN OF ADDITIONAL
DEPLOYMENT ELEMENTS
RESPONSIBILITY: Contractor
DESCRIPTION: The synthesis of additional deployment elements and prelimi-

B-47
FM 770-78

nary design of deployment equipment are accomplished at this time. This effort
may be performed concurrently with function analysis to complete the definition
of deployment processes, tasks, and equipment necessary to support the
deployment functions. The synthesis is pursued selectively on the basis of
complexity and uniqueness of the end item and in consideration of man/machine
relationships, alternative methods or combinations of resources, availability of
Government-furnished equipment, and charactreristics of equipment, facilities,
personnel, and procedural data required to support transportation, training,
installation, checkout, storage and/or activation of the system or end item.
Preliminary design of deployment equipment is completed to the extent that the
design of operations and logistics support equipment has been completed so that
specific transport media may be designated and evaluated, and modifications
identified to provide timely availability of equipment and services in support of
projected delivery schedules. During synthesis, personnel requirements are
identified in terms of personnel tasks to be performed, task performance times,
and changes to procedural data.
FORMS: Schematic Block Diagram, Concept Description Sheet
REFERENCES: AR 70-1, AR 71-5, AR 611-1

BLOCK 32.3—EVALUATION AND DECISION

RESPONSIBILITY: Contractor
DESCRIPTION: Continuous visibility of the operations and logistics support
elements is maintained so that deployment decisions may be reviewed and
revised as conditions changed and to permit evaluation of deployment alterna-
tives which were previously synthesized. From this evaluation, the most
effective means, approaches, and techniques which can be employed to accom-
plish deployment function requirements are determined. Only reasonably
attainable low risk design approaches are pursued in consideration of technical
capabilities, cost, schedules, resource limitations, or other constraints as
specified in system requirement documentation. Decisions that affect other
system elements must be coordinated with the personnel responsible for the
affected elements.
FORM: Trade-Off Study Reports
REFERENCE: AR 70-1

BLOCK 32.4—DESCRIPTION OF ADDITIONAL DEPLOYMENT ELEMENTS

RESPONSIBILITY: Contractor
DESCRIPTION: The descriptions of deployment elements developed during the
Demonstration and Validation Phase are updated and expanded at this time to
describe in sufficient detail the equipment, facilities, personnel, procedural data,
and computer programs required to support deployment of the system/end item.
The cpmpleted descriptions of deployment elements are the basis from which to
initiate detail design. The descriptions identify these elements in the following
terms: equipment—performance, constraints, design, test, and evaluation re-
quirements; facilities—location, size, structural requirements, and equipment;
personnel—numbers, types (to include MOS’s where applicable and known), task
performance times, and required training; procedural data—procedures to be
covered and the means for imparting or communicating to the user; and
computer programs—purpose, capability, input, and output requirements.
FORM: Design Sheet
REFERENCES: AR 18-1, AR 70-1, AR 71-5, AR 611-1

B—48
 FM 770-78

BLOCK 38.1—DETAIL DESIGN OF LOGISTICS SUPPORT EQUIPMENT AND

FACILITIES
RESPONSIBILITY: Contractor
DESCRIPTION: As designs evolve for operations and logistics support equip-
ment, detail design specifications for logistics support equipment and its
associated facilities are prepared. These specifications contain reference to an
approved top level drawing for the configuration item. The detail design is
constantly assessed against the performance/design requirements and the
selected design approach. The “build-to” documentation must be emphasized to
ensure that the product matches the requirements established for it and the
criteria against which the product is to be delivered and accepted. Engineering
documentation evolves in the form of detail drawings, interface drawings,
detailed specifications for logistics support equipment, and facilities and engi-
neering breadboards/brassboards and mockups.
REFERENCES: AR 18-1, AR 70-1, AR 385-16, AR 602-1, AR 611-1,
AR 700-127, AR 750-1, MIL-STD-100A, MIL-STD-490, MIL-D-1000A
BLOCK 38.2—DETAIL DESIGN OF TEST EQUIPMENT AND FACILITIES
RESPONSIBILITY: Materiel Developer, Contractor
DESCRIPTION: Detail design of test equipment and its associated facilities is
accomplished in accordance with the development specification, logistics support
development specification, and in conjunction with the coordinated test plans.
Product specifications and drawings for test equipment and facilities are
prepared at this time. Test methods and procedures, including those for data
analysis, computing, and recording, are developed, and the number, types, and
duties of personnel needed for testing are determined.
REFERENCES: AR 18-1, AR 70-1, AR 70-10, AR 70-15, AR 71-3, AR 71-9,
AR 385-16, AR 702-3, MIL-STD-1000A, MIL-STD-490,
MIL-D-1000A
BLOCK 38.3—DETAIL DESIGN OF PRODUCTION EQUIPMENT AND
FACILITIES
RESPONSIBILITY: Contractor
DESCRIPTION: Detail designs of unique production equipment and facilities
are developed from the descriptions of these elements initially established
during the Démonstration and Validation Phase and expanded during the Full-
Scale Engineering Development Phase (Block 31.4). Drawings and specifications
are prepared for each unique equipment item and facility.
REFERENCES: AR 18-1, AR 37-40, AR 385-16, AR 611-1,
AR 700-51
BLOCK 38.4—DETAIL DESIGN OF DEPLOYMENT EQUIPMENT
RESPONSIBILITY: Contractor
DESCRIPTION: Detail design of deployment elements is generated from the
descriptions which were established in the Demonstration and Validation Phase
and expanded during the Full-Scale Engineering Development Phase (Block
32.4). Although some design was previously accomplished in varying degrees,
the detail effort does not start until the development specifications are approved
and the allocated baseline established. Product specifications and drawings for
deployment equipment items are prepared at this time.
REFERENCES: AR 18-1, AR 70-1, AR 611-1, MIL-STD-100A,
MIL-STD-490, MIL-D-1000A

B-51
FM 770-78

BLOCK 39.0—DESIGN CHARACTERISTICS REVIEW (DCR) OF SYSTEM

ELEMENTS
RESPONSIBILITY: Materiel Developer/Contractor
DESCRIPTION: The 39 series blocks describe the reviews which take place
upon completion of detail design (Blocks 28.0 and 38.1 through 38.4) and system
design optimization (Block 37.0). The DCR of logistics support, test, production,
and deployment elements, while accomplished incrementally, are considered in
the DCR for operations elements. Design changes resulting from these reviews
are incorporated in the detail design documentation. Performance requirement
changes, if any, resulting from these reviews are incorporated in applicable
baseline documentation in accordance with established configuration manage-
ment procedures. Design characteristics reviews are conducted prior to release
of design for prototype fabrication to ensure acceptability of the detail design.
The objective is to determine that detail design solutions satisfy the require-
ments and design constraints of the development specification. The reviews
include consideration of all aspects of the design, such as performance,
reliability, maintainability, producibility, transportability, human factors engi-
neering, effectiveness factors, and safety.
FORMS:
REFERENCES: AR 70-1, AR 71-5, AR 71-9, AR 385-16, AR 602-1,
AR 700-127, AR 750-1, MIL-STD-480, MIL-STD-481, MIL-STD-482,
MIL-STD-490

BLOCK 40.0—PROTOTYPE DOCUMENTATION

RESPONSIBILITY: Contractor
DESCRIPTION: This documentation consists of engineering drawings, specifi-
cations, and other technical data which prescribe the initial “build-to" design of
the system. It serves as the basis for producing prototypes in sufficient
quantities to meet development and operational acceptance test requirements,
and is prepared in a format which permits easy conversion to the requirements
of quantity production and multisource use.
REFERENCES: AR 18-1, AR 70-1, AR 70-10, AR 700-51, MIL-STD-100A,
MIL-STD-480, MIL-STD-481, MIL-STD-482, MIL-STD-490 MIL-D-1000A
BLOCK 41.0—FUNCTIONAL CONFIGURATION AUDIT (FCA)
RESPONSIBILITY: Materiel Developer
DESCRIPTION: This is an audit to formally examine the functional characteris-
tics test data for a configuration item prior to acceptance of the prototype. If the
item has achieved performance specified in the functional or allocated configura-
tion identification, proceed to Block 43.0, Product Configuration Identification;
otherwise, to Block 42.0 for design changes.
REFERENCES: MIL-STD-480, MIL-STD-481, MIL-STD-482,
MIL-STD-490 MIL-STD-1521

BLOCK 42.0—(Blocks 42.1 through 42.5)—DESIGN CHANGES BASED ON DT

ll/OT II
RESPONSIBILITY: Materiel Developer/Contractor/Combat Developer
DESCRIPTION: The deficiencies which were disclosed during conduct of DT
II/OT II are presented for resolution or corrective action. The system engineer-
ing process is then iterated to the depth required for each system engineering
activity to identify all of the essential design changes that must be accomplished,

B-52
 FM 770-78

and to ensure that any new relationships between the redesigned items or areas
and those previously accepted will adequately interface.
If material revisions do not affect the operational capability of the using
unit, the materiel developer implements the necessary revisions through normal
engineering change action. The materiel developer performs the system engi-
neering activities to update product configuration identification; develop re-
search and development model prototype; develope program change request;
initiate product improvement tests and required quality assurance planning;
obtain required production engineering. DA publications, provisioning, and
training support changes; coordinate additional required testing with appropri-
ate agencies; initiate requests for revision of distribution, materiel, modification,
and international logistics plans; and provide input to ILS for revision and
updating of logistics support requirements.
If a significant change in the operational capability of the using unit is
deemed necessary, the change in performance characteristics is developed by
the Combat Developer assisted by the Materiel Developer. Upon Department of
the Army approval of the new performance characteristics, the Materiel
Developer initiates development action. The type of development necessary will
determine the recycle path through the system engineering model. The Materiel
Developer also accomplishes retest planning.
The system engineering process and related data are utilized in performing
feasibility studies to define and justify major system modifications required as a
result of product improvement changes or changes to operational requirements.
Particular emphasis is placed on determining and defining the total system
impact of the change, i.e., describing equipment, computer programs, facilities,
personnel, and procedural data impacts. In the accomplishment of this task, the
system engineering activities depicted and described in the model are iterated to
the extent necessary to ensure the orderly and coherent implementation of the
change.
REFERENCES: AR 18-1, AR 70-10, AR 71-3, AR 71-9, AR 385-16,
AR 700-35, MIL-STD-100A, MIL-STD-480, MIL-STD-481, MIL-STD-482,
MIL-STD-490, MIL-D-1000A
BLOCK 43.0—PRODUCT CONFIGURATION IDENTIFICATION (PCI)
RESPONSIBILITY: Materiel Developer/Contractor
DESCRIPTION: The product configuration identification includes program
unique product specification types, C, D, E, and/or a military specification, level
3 engineering drawing and associated lists, and related data to provide a set of
documents adequate for the procurement, production, test, evaluation, and
acceptance of an item without requiring further development work. This set of
documents provides that technical description which describes the required
physical characteristics of an item, the functional characteristics designated for
production acceptance testing, and required acceptance tests. PCI is followed by
Development Acceptance IPR/ASARC III/DSARC III and award of contract for
production. '
REFERENCES: AR 70-1, AR 310-3, MIL-STD-100A, MIL-STD-480,
MIL-STD-481, MIL-STD-482, MIL-STD-490 MIL-STD-961, MIL-D-1000A

B-53
FM 770-78

B-5. The Production and Deployment Phase (Fig. B- audit of first production items, Deficiencies in effec-
4) tiveness or suitability of new systems or inadequacies
in logistics support may be noted by the user.
a. System engineering during the Production and c. Product improvements may originate from user
Deployment Phase is concerned primarily with cor- recommendations, from requirements documents, or
rection of deficiencies and with product from directed extensive modifications to enhance
improvements. materiel capabilities.
d. Blocks 44.0 through 50.0 describe system engi-
b. Production deficiencies may be discovered by the neering activities in the Production and Deployment
materiel developer during the physical configuration Phase.

B-5 4
 » • è «
PRODUCTION AND DEPLOYMENT PHASE

EVENT 116
EVENT 102*/72 EVENT 73
INTERFACE

PRODUCT
CONTINUE IMPROVEMENT/
PRODUCTION
LIFE CYCLE

CONTRACT MODIFICATION
FACILITY PRODUCTION
AWARD

♦FULL-SCALE PRODUCTION
CONTRACT AWARD. LRIP
ONLY IF REQUIRED AND
AUTHORIZED.
BASELINE DESCRIPTION

50.0
47.0

UPDATE PRODUCT
UPDATE PRODUCT CONFIGURATION
CONFIGURATION IDENTIFICATION

£
C/l
m
ENGINEERING ACTIVITIES

46.0 49.0
48.0V45.0
44.0

DESIGN
DESIGN IMPROVEMENT/
/ PRODUCTION CIVAVPCA
CHANGES MODIFICATION
ELEMENTS

\
*IF LRIP. ACCOMPLISH PCA (BLOCK 45).
PLUS CIVR WHEN FULL-SCALE PRODUCTION
SYSTEM

ENTERED.

FIGURE 8-4
FM 770-78

PRODUCTION AND DEPLOYMENT PHASE

00
I
U1 Figure B-l. Production and deployment phase.
U1
FM 770-78

SYSTEM ENGINEERING ACTIVITIES

PRODUCTION AND DEPLOYMENT PHASE

BLOCK 44.0—PRODUCTION ELEMENTS

RESPONSIBILITY: Materiel Developer
DESCRIPTION: These are PCI and production plan inputs which describe
capital equipment, hardware, software, personnel, and materials requirements
necessary to transform design into efficient and economical production of the end
item or system. Examples of production functions include such actions as
materials handling, fabricating, processing, assembling, inspecting, testing,
packaging, packing, storing, and shipping.
REFERENCES: AR 700-47, AR 700-90

BIOCK 45.0—PHYSICAL CONFIGURATION AUDIT (PCA)

RESPONSIBILITY: Materiel Developer
DESCRIPTION: This audit is conducted to determine the adequacy and validity
of the product configuration identification. It is conducted on, or during the
assembly of, the first (LRIP) article of system equipment items. The PCA
consists of comparing the as-produced system equipment with the product
configuration in accordance with the approved PCI (drawings and
specifications).
REFERENCES: AR 18-1, AR 70-1, MIL-STD-100A, MIL-STD-480,
MIL-STD-481, MIL-STD-482, MIL-STD-490, MIL-STD-961, MIL-D-1000A,
MIL-STD-1521

BLOCK 46.0—DESIGN TO EQUIPMENT BASED UPON PHYSICAL

CONFIGURATRION AUDIT
RESPONSIBILITY: Materiel Developer/Contractor
DESCRIPTION: Design changes indicated and approved as a result of PCA or
CIVR are introduced into the system in a manner which will minimize conflicting
interrelationships with accepted elements. The system engineering process is
iterated to the depth required to ensure optimization of the total system after
incorporation of the design changes. Changes which affect the product baseline
are processed by engineering change requests in accordance with configuration
management procedures. Additional tests may be run if necessary to ensure
acceptability of the modified system.
REFERENCES: AR 18-1, AR 70-1, AR 70-10, AR 385-16, AR 700-127,
AR 702-3, AR 750-1, MIL-STD-100A, MIL-STD-480, MIL-STD-481,
MIL-STD-482, MIL-STD-490, MIL-STD-961, MIL-D-1000, MIL-STD-1521

B-56
 FM 770-78

BLOCK 47.0—UPDATE PRODUCT CONFIGURATION IDENTIFICATION

(PCI)
RESPONSIBILITY: Materiel Developer
DESCRIPTION: The product configuration identification is updated as required
to correct deficiencies resulting from PCA or from CIVR. These changes are
incorporated into the PCI in accordance with established configuration manage-
ment procedures.
REFERENCES: AR 70-37, AR 385-16, MIL-STD-100A, MIL-STD-480,
MIL-STD-481, MIL-STD-490, MIL-STD-961, MIL-D-100A, MIL-STD-1521
BLOCK 48.0—CONFIGURATION ITEM VERIFICATION REVIEW (CIVR)
RESPONSIBILITY: Materiel Developer
DESCRIPTION: This review is a formal technical audit of the (full-scale)
production item to verify conformance to technical data and to performance
interfaces within the system. It validates continuation of production.
REFERENCE: AR 70-37
BLOCK 49.0—DESIGN IMPROVEMENT/MODIFICATION
RESPONSIBILITY: Materiel Developer/Combat Developer
DESCRIPTION: The need to repeat the system engineering process to support
modifications and/or product improvements may result from equipment improve-
ment recommendations, suggestions from the field, or be self-initiated to
improve cost-effectiveness or product performance.
Extensive modification of items of materiel may require recycling or partial
recycling of the system engineering process. Combat developer concurrence and
participation is required in any change which affects the ability or manner of an
item to perform the mission for which it was designed as reflected in the
ROC/LR. Modifications of this nature are tested in the same manner as service
testing of the original item. The combat developer participates in confirmatory
and check tests in the same manner as for service tests. Accomplishment of the
modifications may require that production be continv^d or reinitiated, as
necessary, to meet the additional or changed require .ents. Elimination of
discovered deficiencies may also require review of technical assistance capabili-
ty, development of logistics support or overhaul requirements, and appropiate
actions outlined in system engineering Block 46.0. This process provides input to
ILS so that actions may be accomplished to revise and up date previously
established support data and requirements.
REFERNCES: AR 70-15, AR 700-35, MIL-STD-100A, MIL-STD-480,
MIL-STD-481, MIL-STD-490, MIL-STD-961, MIL-D-1000A
BLOCK 50.0—UPDATE PRODUCT CONFIGURATION IDENTIFICATION
RESPONSIBILITY: Materiel Developer
DESCRIPTION: The product configuration identification is updated by engi-
neering change requests to effect all modifications and/or product improvements.
These changes are incorporated in accordance with configuration management
procedures.
REFERENCE: AR 70-37
i

B-57
 1

FM 770-78

APPENDIX C
GLOSSARY

Definitions in this glossary conform to or are derived from official publications or generally accepted usage.
Should conflict of definitions arise, the following should be used in the interpretation of this publication.

ACI. Allocated Configuration Identification. to fabricate, assemble, test, and produce equipment
and facility items. In MIL-STD-490 these are identi-
Acquisition Plan (AP). The definitive plan for man-
fied as Product Specifications; in MIL-STD-961, as
agement of the program for development of materiel Military Specifications.
which will accomplish the objectives in an approved
materiel requirement document. CDS. Concept Description Sheet.
ADP terms (all). See AR 18-1. Cl. Configuration Item.
Allocated baseline. The initial approved configura- Combat Developer. The agency or command respon-
tion identification. This is the baseline to which sible for concepts, doctrine, organization, and mater-
systems and equipment are controlled. iel objectives and requirements for the employment
of Army forces. TRADOC is the principal combat
Allocated configuration identification (ACI). Cur-
developer.
rent, approved performance oriented specifications
governing the development of configuration items Concept description sheet (CDS). A sheet for relat-
that are part of a higher level Cl, in which each ing gross level designs to the functions, require-
specification: (1) defines the functional characteristics ments, and constraints that the design is to meet.
that are allocated from those of the higher level Cl;
Conceptual design. Synthesis.
(2) establishes the tests required to demonstrate
achievements of its allocated functional characteris- Configuration. The functional and/or physical charac-
tics; (3) delineates necessary interface requirements teristics of hardware/software as set forth in technical
with other associated configuration items; and (4) documentation and achieved in a product.
establishes design constraints, if any, such as compo- Configuration identification. The current approved
nent standardization, use of inventory items, inte- or conditionally approved technical documentation for
grated logistics support requirements. a configuration item as set forth in specifications,
AP. Acquisition Plan. drawings, and associated lists, and documents refer-
enced therein.
Baseline. A configuration identification document or a
set of such documents formally designated and fixed Configuration item (Cl). An aggregation of hard-
at a specific time during a CTs life cycle. Baselines, ware/software, or any of its discrete portions, which
plus approved changes from baselines, constitute the satisfies an end use function and is designated by the
current configuration identification. For configuration Government for configuration management. CTs may
management there are three baselines; Functional, vary widely in complexity, size, and type.
Allocated, and Product. Configuration management. A discipline applying
Basic (input) requirements. Those statements of fact technical and administrative direction and surveil-
and assumption portraying the primary universe for lance to— (1) identify and document the functional
application of the system engineering process; these and physical characteristics of a configuration item;
are mission/objective, environment, constraints, and (2) control changes to those characteristics; and (3)
measures of effectiveness. record and report change processing and implementa-
tion status.
"Build-to" specifications. Those specifications which
are developed during detail design and prototype Deployment. Fielding functions to be performed and
fabrication. They contain the information necessary system elements required to initially transport, re-

C-l
r
FM 770-78

ceive, process, install, test, checkout, train, operate Functional area. The activities, subfunctions, and
and, as required, emplace, house, store, or deploy the elements of a primary function.
system into a state of full operational capability.
Functional baseline. The initial approved functional
Description of the system elements. Engineering configuration identification.
data that defines the configuration, arrangement, and Functional configuration audit. The formal examina-
usage of all system elements and their effectiveness
tion of functional characteristics test data for a
in achieving functional performance.
configuration item, prior to acceptance, to verify that
Design reviews. Determination of the technical ade- the item has achieved the performance specified in its
quacy of the system engineering and design efforts in functional or allocated configuration identification.
meeting system requirements.
Functional configuration identification (FCI). The
Design sheet. Documentation on which is recorded current approved technical documentation for a con-
performance, test, and design requirements for figuration item which prescribes all necessary func-
equipment end items, critical components, and com- tional characteristics.
puter programs.
Functional cycle. The application of the system engi-
"Design-to" specifications. Those specifications neering process to an activity for definition or refine-
which contain the performance, design, and verifica- ment of appropriate system elements.
tion (test) requirements for an item of equipment or
facility. They are developed prior to detail design of Functional flow block diagram (FFBD). A drawing
the item and provide the basis for design. In MIL- on which the system requirements are structured into
STD-490, these are identified as the System Specifi- functional terms.
cation and Development Specifications. Indenture. A method of showing relationships to
DS. Design Sheet. indicate dependence.
EIMS. End Item Maintenance Sheet. Integrate. To put or bring (parts) together into a
whole; unify.
End item maintenance sheet (EIMS). Document for Interface. A boundary or point common to two or
identifying maintenance functions on a specific end
more command and control systems, subsystems, or
item, subassembly, and component basis.
other entities against which or at which necessary
Engineering specialty plan. Descriptive name for any information flow takes place.
plan or activity having requirements, constraints, or
contributions that must be considered in developing Integrated logistics support. A composite of the
the system elements. elements necessary to ensure the effective and eco-
nomical support of a system of equipment at all levels
Evaluation and decision. Process of determining the of maintenance for its programed life cycle.
combination of system elements that best meet the
mission objectives and support requirements. Interface control documentation. Documents result-
ing from that part of the System Engineering Man-
Facility interface sheet (FIS). Documentation of envi- agement Plan describing how interface requirements
ronmental requirements and interface design require- will be accomplished.
ments imposed upon facilities by the end items of
equipment. Iterate. To do again for the purpose of expanding,
understanding, refining, improving, indenturing, or
FFBD. Functional Flow Block Diagram. updating current knowledge.
Fielding. See Deployment. Iterative methodology. Sequential and repetitive
FIS. Facility Interface Sheet. top-down development of a topic by— identifying
those actions (functions) required to accomplish the
Function. Actions required to accomplish part or all of objective; allocating the (basic input) requirements to
a specific mission objective and those actions required the appropriate functions (functional allocation);
to support the basic mission. translating the requirements into solutions (synthesis
Function analysis. Determination of the functions and or conceptual design) through system/design engi-
their sequence and interdependence required to ac- neering studies; portraying the interdependence
complish a mission objective, and the relating of among the solution elements; researching and evalu-
(basic) requirements to the functions upon which they ating the alternate solutions and determining the
impact. most feasible solution; analyzing the selected solu-

C-2
r tions to assess the impact on the requirements/design
and other solution elements.
Letter of Agreement. An STF/SSG document outlin-
FM 770-78

ing cost and schedule implications, and selecting a

preferred alternative or set of alternatives.
Outline Acquisition Plan. The document of record
ing basic agreements between combat developer and which supports the advanced development effort.
materiel developer for further investigation of a PEP. Production Engineering and Planning.
potential materiel system.
Physical configuration audit (PCA). The formal ex-
Letter Requirement. An abbreviated procedure which
amination of the “as-built” configuration of a Cl
may be used in lieu of the ROC for acquisition of low
against its technical documentation and functional
value items.
requirements in order to establish the CPs initial
Life cycle test plan. A generic term which encom- product configuration identification.
passes the major materiel tests conducted throughout
PIP. Product Improvement Proposal.
the materiel life cycle.
Product baseline. The initially approved or condition-
LOA. Letter of Agreement.
ally approved product configuration identification.
Logistics Support Analysis Record. Record of main-
Product configuration identification (PCI). The cur-
tenance task analysis data used to identify, define,
rent approved or conditionally approved technical
analyze, and quantify logistics support requirements.
documentation which defines the configuration of a Cl
LSAR. Logistics Support Analysis Record. during the production, operation, maintenance, and
logistics support phases of its life cycle, and which
Maintenance. The functions of sustaining materiel in prescribes: (1) all necessary form, fit, and functional
an operational status, restoring it to a serviceable characteristics of a Cl; (2) the selected functional
condition, or updating and upgrading its functional characteristics designated for production acceptance
utility through modification. testing; and (3) the production acceptance tests.
Materiel Developer. The command or agency respon- Product Improvement Proposal (PIP). A proposal for
sible for research, development, and production vali- product improvement which does not significantly
dation of a system which responds to HQ DA change the approved performance envelope of the
objectives and requirements. system.
Measures of effectiveness. A particular value or set Production sheet. Document describing production
of values of system/subsystem effectiveness pertinent facilities, equipment, personnel, and operations re-
to one or more mission objectives. quired to produce each configuration item.
MENS. Mission Element Needs Statement. Production Engineering and Planning (PEP). RDTE
Mission Element Need Statement. The justification planning and engineering tasks of the materiel devel-
document for initiation of a new major system acqui- oper to ensure producibility of material prior to
sition (AR 71-9). Includes mission needs, threat procurement.
assessment, existing capability identification, defi- PS. Production Sheet.
ciency assessment, constraint consideration, impact
assessment, and program planning. RAS. Requirements Allocation Sheet.
Rationalization, Standardization, Interoperability
Mission profile. A portrayal of operations functions, (R/S/I) (AR 34-1).
e.g., a top level FFBB.
Required operational capability (ROC). Narrative
OAP. Outline Acquisition Plan. description of minimum operational, technical, and
Operations. A military action or the carrying out of a cost information required for a HQ DA decision to
strategic, tactical, service, training, or administrative initiate development of a new materiel system or
military mission; the process of carrying on combat, item.
including movement, supply, attack, defense, and Requirements allocation sheet (RAS). A format on
maneuvers needed to gain the objectives of any battle which the requirements and constraints are defined
or campaign. for each function and related to the appropriate
system element(s).
Optimization. The process of identifying the relative
operational and/or support effectiveness of system Risk analysis. The application of qualitative and
and technical program element alternatives which quantitative techniques for analyzing, quantifying,
have been defined by system engineering, determin- and reducing the uncertainty associated with the
)
\ C-3
FM 770-78

realization of time, cost, or performance goals. The all engineering activities and technical aspects of the
1
prediction of cost growth, schedule, slippage, and
performance degradation to allow for proper manage-
ment of future events. Also called risk evaluation.
system/project from receipt of a requirement for a
new system or materiel item through the delivery of
the system or item to the operational inventory.
«
ROC. Required Operational Capability. System engineering management plan (SEMP). A
plan for the application of the principles of manage-
RSI. Rationalization, Standardization, Inter- ment to ensure effective execution of the system
Interoperability.
engineering effort.
SBD. Schematic Block Diagram.
System engineering process. The sequential and
Schematic block diagram (SBD). A basis for assem- iterative methodology involving top-down develop-
bling function performance requirements and criteria ment of the product and technical program task
into an integrated set of design requirements for the elements of the Work Breakdown Structure and
system. allocation of requirements for design and for technical
program definition to all system and technical pro-
Sciences and Technology Objective (STO) (AR 71—
gram elements including those for technical perfor-
9). mance measurement. Repetitive steps for resolving
SEMP. System Engineering Management Plan. requirements, i.e., a four-step process consisting of
function analysis, synthesis, evaluation and decision,
STO. Science and Technology Objective.
and description which is repeated for every design
Synthesis. Translation of functions and requirements requirement.
into possible solutions (resources and techniques)
System engineering process element. A specialty
satisfying the basic input requirements. Synthesis is
task/program which contributes to an integrated,
performed concurrently with function analysis, when-
comprehensive system engineering process.
ever possible, and often yields alternative solutions
for analysis during trade-off studies. Tailoring. The selective application of system engi-
neering, technical, and managerial resources to fulfill
System. A composite of equipment skills and tech- the objectives of a project/program.
niques capable of performing and/or supporting an
operational role. A complete system includes all Technically critical area. System functional require-
equipment related facilities, materiel, software, ser- ments which are critical to system operational and/or
vices, and personnel required for its operation and support effectiveness, program schedule or cost,
support to the degree that it can be considered a self- and/or for which the proposed or alternate solutions
sufficient unit in its intended operational environ- involve significant technical risk.
ment. The system is what is employed operationally
and supported logistically. It is the product of the Technical performance measurement (TPM). The
acquisition program. design assessment function of performance measure-
ment which estimates through engineering analyses,
System element. Any item required to produce, test, or measures through tests, the values of essential
deploy, operate, maintain, and support the system, performance parameters of the current design of
i.e., equipment, personnel, facilities, procedural data, system elements and forecasts the values to be
or computer programs. obtained through the planned technical approach.
System engineering. The selective application of Technical program. The total program effort for a
scientific and engineering efforts to: (1) transform an system. It includes all design/development/test/eva-
operational need into a description system configura- luation activities and associated resources to progress
tion which best satisfies the operational need accord- from an operational requirement to the system in
ing to the measures of effectiveness; (2) integrate operational use, including interfaces with production,
related technical parameters and ensure compatibility operation by user, logistics support, and training.
of all physical, functional, and technical program The technical program includes the management
interfaces in a manner which optimizes the total functions of planning and controlling as well as the
system definition and design; and (3) integrate the accomplishment of functions. System engineering is
efforts of all engineering disciplines and specialties itself a part of the technical program.
into the total engineering effort.
Technical program element. Element of the Contract
System engineering management. Management of Work Breakdown Structure down to the Work Pack-
the system engineering process and the integration of age level.

C-4
 FM 770-78

Test. Functions to be performed and system elements Trade-off. Selection of a preferred parameter.
required to verify that a system meets, exceeds, or
fails to meet the technical or operational properties Trade-off study reports (TSR). Documentation for the
ascribed to the system. evaluation of all possible problem solutions and the
selection of the most promising approach.
Test requirements sheet (TRS). A document for iden-
tifying test functions on a specific end item, subas- Training Developer. The agency or command respon-
sembly, and component basis; documentation of all sible for concepts, doctrine, organization, materiel
requirements that must be demonstrated or verified objectives, and requirements for the training of Army
during life cycle testing. personnel. TRADOC is the principle training
Time critical functions. Those functions which must developer.
be accomplished within critical time constraints; oth- TRS. Test Requirements Sheet.
erwise system performance (e.g., reaction time) fails.
Time line sheet (TLS). Documentation for analysis of TSR. Trade-Off Study Report.
(expected) time-critical functions and functional
sequences. Visibility. Documentation to verify that data is so
constructed as to determine and illustrate factors
TLS. Time-Line Sheet. concerning technical or mission critical areas for
TPM. Technical Performance Measurement. evaluation.

Traceability. The capability to track system require- WBS. Work Breakdown Structure (MIL-STD-881A).
ments from a system function to all elements of the
system which, collectively or individually, perform Work Breakdown Structure (WBS). A product-orient-
the function; an element of the system to all functions ed family tree composed of hardware, services, and
which it performs; a specific requirement of the data. A summary WBS is the upper three levels of a
source analysis or contractual constraint which origi- WBS; it has uniform element terminology, definition,
nated the requirement. Traceability includes tracking and placement in the WBS. A project summary WBS
allocation design (and technical program) require- is a summary WBS tailored to a specific defense
ments through the work breakdown structure be- materiel item. A contract WBS is the complete WBS
tween the system level and the lowest level of •for a contract. A project WBS is the complete WBS
assembly. for the project.

C-5 >
t
 FM 770-78

INDEX
Paragraph
or Block Page

Allocated baseline 3-5o(2)(6) 3-14

Alternative Systems Concept Plans B B-l
Alternative technical approaches B2.0 B-3
Baseline B-2 B-l
Allocated 3-5a(2)(i>) 3-14
Functional 3-5a(2)(b) 3-14
Product 3-5a(2)(¿>) 3-
Computer programs element 2-4e 2-8
Concept description sheet 4-2g 4-
Concept formulation package B4.4 B-6
Configuration item verification review 3—4a 3-3
Configuration management 3-5 3-13
Coordinated Test Program B7.4 B-l 2
Cost and schedule control 3-5d 3-15
Cost-effective application 3-26 3-2
Cost information reports 3-5d(8) 3-17
Cost performance report 3-5d(6) 3-17
Cost/schedule control systems 3-5d(5) 3-
Demonstration and Validation Phase B-3 B-7
Deployment
Functional area 2-5e 2-9
Fielding Plan B7.6 B-13
Description
Step 2-3e 2-
System elements B6.4 B-9
Logistics support elements B15.4 B-24
Design characteristics review 3-4a 3-
Design reviews 3-4a 3-
Design sheet 4-2j 4-
Design test I B12.0 B-19
Documentation
Description 4-2 4-
Minimum concept _4-16 4-1
Traceability 4-2d 4-13
Elements system 2-4 2-
End item maintenance sheet 4-26 4-11
Engineering specialty plans 3-2c 3-
Equipment element 2-4a 2-7
Evaluation and decision 2-3d 2-7
Facilities elements 2-4c 2-8
Facility interface sheet 4-2A 4-21
Fielding Plan B7.6 B-13
Full-Scale Engineering Development Phase B-4 B-37
Function analysis step 2-36 2-5
Function identification 2-36(1) 2-5
Function performance requirements 2-36(2) 2-6
Functional areas
Deployment 2-5e 2-9
Logistics support 2-56 2-9
Operations 2-5a 2-9
Production 2-5d 2-9
Test 2-5c 2-9

Index-1
FM 770-78
Paragraph
or Block Page

Functional baseline 3-5a(2)(a) 3-14

Functional configuration audit 3-
Functional configuration identification ... B6.0 B-8
Functional flow block diagrams 4-
Input requirements
Measures of effectiveness 2-2e 2-4
Mission 2-26 2-4
Operational environment 2-2c 2-4
System constraints 2-
Integrated logistics support 3-
Letter of agreement B2.4 B—4
Life cycle phases
Alternative System Concepts B-2 B-l
Démonstration and Validation B-3 B-7
Full-Scale Engineering Development B-4 B-37
Production and Deployment B-5 B-54
Logistics support analysis record 3-56(3) 3-14
Maintenance support plan B7.3 B-ll
Operational elements description B13.4 B-21
Operations functional area 2-5a 2-9
Outline acquisition plan B4.4 B-6
Performance requirements 2-36(2) 2-6
Personnel element 2-
Physical configuration audit 3-
Preliminary design characteristics review 3-4a 3-3
Procedural data element 2-4d 2-8
Process steps 2-
Product baseline 3-
Product improvement B49.0 B-57
Production
Functional area 2-
Initial plan B7.5 3-12
Sheet B-3 B-7
Production and Deployment Phase B-5 B-54
Request for proposal B-3 B-7
Input to B8.0 B-13
Requirements allocation sheet 4-
Reviews, design 3-
Schematic block diagrams 4-
Science and technology objective B-2a B-l
Specialist interrelationships 3-5c 3-15
Support plan B10.2 B-16
Synthesis step 2-
System design review 3-
System effectiveness reports 3-4c(10) 3-9
System elements 2-
System engineering management 3-
System engineering management plan .. 3-2c 3-2
System requirements review 3-4a 3-3
Tailoring 3-2a 3-1
Technical performance measurement .... 3-4c 3-4
Achieved parameter profile a-4c(9) 3-9
Master parameter list 3-4c(5) 3-5
Parameter status tracking 3-4c(8) 3-9

Index-2
 By Order of the Secretary of the Army:

BERNARD W. ROGERS
General, United States Army
Official:
Chief of Staff
J.C. PENNINGTON
Major General, United States Army
The Adjutant General

Distribution:
Active Army: To be distributed in accordance with DA Form 12-11B, require-
ments for Logistics Materiel Development Management
ARNG & USAR: None

«
\
f

»
 FM 770-78
Paragraph
or Block Page
Planned parameter profile 3-4c(6) 3-5
Work breakdown elements 3-4c(4) 3-5
Technical program reviews ... 3- 3-4
Test functional area 2-5c 2-
Test requirement sheet 4- 4-13
Time line sheets 4-2/ 4-17
Time requirements analysis ... 2- 2-6
Trade-off study report 4-2i 4-20
Training as a functional area . . 3- 3-
Training developer 2- 2-8
Work breakdown structure . . . 3- 3-5

Index-3
 i
r I
i

’j
 M
•«

COMPONENTS OF THE SYSTEM ENGINEERING MANAGEMENT PLAN

SYSTEM ENGINEERING
MANAGEMENT PLAN
(SEMP)

SEMP, PART 1 SEMP PART 2 SEMP, PART 3

SYSTEM ENGINEERING SYSTEM ENGINEERING ENGINEERING

MANAGEMENT PROCESS SPECIALTY
(SEM) (SEP) INTEGRATION

MISSION REQUIREMENTS/CONSTRAINTS FUNCTION ANALYSIS RELIABILITY

Interprets, clarifies and validates basic Defines functions and function performance re- MIL-STD-785A , 756, 781, AR 702-3
inputs to the System Engineering Process. quirements which must be met in order to accom- MIL-HD8K-217A
plish the operations, maintenance, test, pro-
duction and deployment requirements of the
system.

RESPONSIBILITY/AUTHORITY MAINTAINABILITY

Identifies organization(s) and-key personnel MIL-STD-470, 471, AR 702-3

SYNTHESIS OF CONCEPTUAL SYSTEMS
for managing the system engineering effort and
defines responsibilities, lines of communica-
tion and functions of personnel associated Depicts a complete response to functional
with system engineering policy. needs; provides alternatives for trade studies;
HUMAN ENGINEERING/HUMAN FACTORS
depicts compatibility between system elements
and interfacing systems; provides traceability
between system elements and their functional MIL-STD-1472, MIL-H-46855
origin in the operational usage.
RESOURCE ALLOCATION

Allocates resources of budget, schedule and

PERSONNEL REQUIREMENTS
expertise necessary to achieve effective System
EVALUATION AND DECISION
Engineering and System Engineering Management.
MIL-STD-26239A
Selects the best combination of system ele-
ments to meet the mission objectives and
support requirements as a balance of cost,
PROCEDURES performance and schedule.
ELECTRONIC WARFARE

Establishes the formal process for implementing

System Engineering and System Engineering
Management through all phases of the program.
DESCRIPTION OF SYSTEM ELEMENTS

SURVIVABILITY/VULNERABILITY
Produces engineering data that identifies,
describes and specifies the configuration,
DOCUMENTATI0N/F0RMAT arrangement and usage of all system elements
and their effectiveness in achieving func-
tional performance. Controls the design,
Establishes procedures for the generation and SECURITY ENGINEERING
development, test, production and deployment
management of all system engineering documenta-
of equipment and facilities; the selection and
tion. Specifies formats of documentation.
training of personnel; the development of pro-
cedural data and computer programs. Provides
a basis for change control.
SAFETY
DESIGN REVIEWS

MIL-STD-882, AR 385-16
Establishes schedules and procedures for the
comprehensive examination and review of all
aspects of the design. MIL-STD-1521

STANDARDIZATION/RSr

INTERDISCIPLINARY INTEGRATION AR 34-1

Establishes procedures to assure design com-

patibility from the standpoint of all pertinent
engineering and scientific disciplines. ILS & LSA

DOD Directive 4100.35, AR 700-18,

AR 750-1, AR 700-127, AR 1000.1,
ENGINEERING DECISION PROCESS
AR 1000.2 MIL-STD-1388-1,
MIL-STD 1388-2, DI-L-7017
Establishes formal internal procedures utiliz-
ing system effectiveness models, trade-off ELECTROMAGNETIC COMPATIBILITY
studies, risk analysis, etc.'

MIL-STD-461, 462, 463, 462

□ODD 3222.2, DODD 4650.1

PROGRAM ASSURANCE

SYSTEM/COST EFFECTIVENESS
Identifies technical measures which can reduce
the risks and unknowns associated with critical
MIL-STD-721B, 217
areas of the program and selects measures to be
implemented.

VALUE ENGINEERING

CHANGE CONTROL

Establishes formal internal procedures neces-

sary to control all technical data that has an
impact upon configuration, performance require- TRANSPORTABILITY

ments, design constraints or functional/physical

interfaces. MIL-STD480,483 AR-70-44

WORK BREAKDOWN STRUCTURE QUALITY ASSURANCE

Identifies the structure of products and serv- MIL-Q-9858A

ices comprising the entire work effort.
MIL-STO-881

MATER IALS/PROCESSES
TRAINING

Identifies and establishes methods and pro-

cedures that will be used to train selected
personnel in the system engineering process/
system engineering management methodology HEALTH

and rationale.

TECHNICAL PERFORMANCE MEASUREMENT

ASSESSMENT
Identifies items which have significant impact
upon system effectiveness; identifies and AR 70-1, AR 70-27,
quantifies parameters which have significant AR 705-50
impact upon (system1effectiveness; establishes
analytical or test criteria for the estimation
POLLUTION CONTROL
or measurement of technical performance; esti-
mates or measures, evaluates and forecasts all
significant technical performance character-
istics of the system through the design
activity. MIL-STD-1521

MIS

DODD 5000.29, AR 18-1

TAILORING

Deletes, alters or adds requirements in order

OTHERS AS REQUIRED
to adapt this manual to the peculiarities of
specific systems or'subsystems

NOTE: THIS IS AN EXAMPLE OF A SEMP,

NOT A REQUIREMENT. PART 3 IS
MILESTONES/SCHEDULES ACCOMPLISHED IN CONJUNCTION WITH PARTS
1 & 2.
Identifies and establishes cost, time and
• REFERENCES CITED FOR INITIAL REFERENCE ONLY.
performance accomplishments that are essential
at a specified point in time to meet the ob-
FULL REFERENCES IN DOD INDEX OF SPECIFICATIONS
jectives of the system engineering effort.
AND STANDARDS (DODISS), PARTS I & II, AND IN
DA PAM 310-1.
* •
 ALTERNATIVE SYSTEMS CONCEPTS PHASE
ANALYSIS OF MISSION AREAS
EVENT 10 EVENT 12
(PRE-CYCLE)
TO
LU OO MILESTONE
-J LU
O ■ SCIENCE & TECHNOLOGY OBJECTIVE (STO)
>- I—
I
O ^ / HQ DA DCP I PR/
MISSION ELEMENT NEED STATEMENT (MENS) STF/SSG INF0/APPR0VAL DPM ASARC 1/
*-H O
_I <c APM DSARC I
DOD APPROVAL

MILESTONE ZERO

CO
Z
LU O
Z »—*
• I—
_l û.
LU t—t
en ai [
c o
Cû co
DEVELOPMENT OF ALTERNATIVE ♦SYSTEM ENGINEERING OF o
2.0 TECHNICAL APPROACHES 4.0_ ^SELECTED SYSTEM CONCEPTS H
r 2.1 2.2 4.1 4.2
o
z
>
m

■o
co INITIAL X
FUNCTION
>
CO >
SYNTHESIS OF CO
ANALYSIS TO FUNCTION SYNTHESIS
FORMULATE ALTERNATIVE ANALYSIS OF OF SELECTED
TECHNICAL SELECTED SYSTEM
o ALTERNATIVE
CO <c 1.0 TECHNICAL APPROACHES 2.4 CONCEPT(S) CONCEPT(S) 4.4
< CD
APPROACHES
5.0
X
Û. i—i ANALYZE
a: TECHNICAL TECHNICAL

o
LU
LU
z
BASIC
INPUT
J 2.3
INPUTS TO
FORWARD
LOA 4.3
FINALIZE
CONCEPTUAL INPUT TO
UJ »—i LOA PACKAGE
ÛÛ CD OAP
REQUIREMENTS
PRELIMINARY
EVALUATION OF EVALUATE &
ALTERNATIVE SELECT SYSTEM
CO TECHNICAL
>- CONCEPT(S)
CO APPROACHES

NOTE: BASED UPON DA AND/OR DOD REVIEW OF THE OUTLINE ACQUISITION

PLAN, THREE ALTERNATIVES EXIST: (1) APPROVAL TO ENTER THE DEMON-
STRATION AND VALIDATION PHASE; (2) DECISION TO TERMINATE PROJECT;
(3) DIRECTION TO REWORK THE CONCEPT FORMULATION PACKAGE AND THE
OUTLINE ACQUISITION PLAN. UNDER ALTERNATIVE THREE, THE SYSTEM
LIFE CYCLE ENGINEERING PROCESS IS REINITIATED AT APPROPRIATE POINTS.
INTERFACE SYSTEM ENGINEERING
MANAGEMENT ACTION

STEP IN THE SYSTEM

ENGINEERING PROCESS
♦SYSTEM ENGINEERING PROCESS
(SEE FIGURE 2-1) FIGURE B-1 ALTERNATIVE SYSTEMS CONCEPTS PHASE

A
 Il

f • *
'1
i
. ♦

• f
 EVENT 45
FULL-SCALE ENGINEERING DEVELOPMENT PHASE
EVENT 51 EVENT 52 EVENT 60 EVENTS 64, 69, 71 TO MILESTONE III
EVENT 48

<-> <_J
>- <t ENGINEERING ' DEV N
CJ u_ DT II UPDATE
DEVELOPMENT ACCEPTANCE
TEST DESIGN DT OT ACQUISITION
CONTRACT IPR/ASARC III/
PLAN PLAN
\ AWARD /" DSARC III
TO PRODUCTION
CONTRACT AWARD

40.0 43.0
uj a. COMPLETION OF PRELIMINARY DESIGN PRODUCT
■—i
«t a:
PROTOTYPE
m o 2610_ FO R_0_P_E RATIO N_S _ELEME N2S: DOCUMENTATION CONFIGURATION
r
26.1 26.2 IDENTIFICATION

SYNTHESIS DESIGN CHANGES

AND 39.0 42.0 BASED ON DTII/OTII
25.0 FUNCTION
COMPLETION OF 26.4 28.0 ! 1
ANALYSIS 27.0 37.0 42.1 .
SYSTEM PRELIMINARY 39.1 41.0
DETAIL
DESIGN DESCRIPTION PRELIM DCR
ENGINEERING DESIGN OF SYSTEM DCR OF
! FUNCTIONAL\
INPUTS TO OF OF OPERATIONS
26.3 OPERATIONS CONFIGURATION
MASTER PLANS , OPERATIONS OPERATIONS DESIGN OPERATIONS DESIGN
EQUIPMENT AUDIT
& SCHEDULES EVALUATION ELEMENTS ELEMENTS . OPTIMIZATION ELEMENTS CHANGES
AND FACILITIES V (FCA) /
AND
DECISION
29.0 DEFINITION OF ADDITIONAL LOGISTIC SUPPORT REQUIREMENTS
i DESIGN CHARACTERISTICS REVIEW
29.1 29.2 (DCR) OF SYSTEM ELEMENTS.
DETAIL FUNCTION SYNTHESIS AND DETAIL
PRELIMINARY 38.0 DESIGNS
ANALYSIS OF
DESIGN OF
ADDITIONAL
ADDITIONAL 38.1
LOGISTIC SUPPORT 29.4
LOGISTIC SPT 33.0 42.2
REQUIREMENTS DESCRIPTION DETAIL
ELEMENTS PRELIM 1 DESIGN OF
OF
DCR OF DCR OF \ LOG SPT
ADDITIONAL LOGISTIC
29.3 LOGISTIC SP LOGISTIC SPT DESIGN
LOGISTIC SPT 30.0 DEFINITION OF_ADpiTIO_NAL TESJ REQUIREMENTS SUPPORT
EVALUATION ELEMENTS i ELEMENTS / CHANGES
ELEMENTS 30.1 '30.2 “ —1 EQUIP AND
AND FACILITIES
DECISION Z=3— DETAIL
FUNCTION
SYNTHESIS &
PRELIMINARY
1U
00 ANALYSIS OF DESIGN OF
END PHASE

< •ADDITIONAL ADDITIONAL 38.2

X 30.4
a. TEST TEST 34.0 39.3 42.3
H ELEMENTS DETAIL
REQUIREMENTS PRELIM.
5 DESCRIPTION
DCR OF
DESIGN OF DCR OF TEST
OF ADDITIONAL TEST TEST DESIGN
LIFE CYCLE 31.0 DEFINITION OF ADDITIONAL PRODUCTION REQ 30.3 TEST
TEST ELEMENTS EQUIP. & ELEMENTS CHANGES
INTERFACE 31.1 EVALUATION ELEMENTS
31.2 FACILITIES
AND
DETAIL SYNTHESIS &
DECISION
FUNCTION PRELIMINARY
ANALYSIS OF DESIGN OF
ADDITIONAL ADDITIONAL
31.4 38.3
PRODUCTION PRODUCTION 35.0 42.4
REQUIREMENTS ELEMENTS DESCRIPTION DETAIL
STEP IN THE SYSTEM OF PRELIM.
DESIGN OF DCR OF PRODUCTION
ENGINEERING PROCESS ADDITIONAL DCR OF
31.3 PRODUCTION PRODUCTION DESIGN
PRODUCTION 32.0 JD^FINrilON OF ADDITIONAL DEPLOYMENT REQ PRODUCTION
EQUIP. & ELEMENTS CHANGES
EVALUATION ELEMENTS ELEMENTS
32.1 32.2 FACILITIES
AND
DECISION DETAIL SYNTHES S &
FUNCTION PRELIMINARY
ANALYSIS OF DESIGN OF
ADDITIONAL ADDITIONAL 38.4
SYSTEM ENGINEERING 32 36.0 42.5
DEPLOYMENT DEPLOYMENT 39.5
MANAGEMENT ACTIONS DETAIL
REQUIREMENTS ELEMENTS DESCRIPTION PRELIM.
DESIGN OF DCR OF
OF ADDITIONAL DCR OF DEPLOYMENT
DEPLOYMENT
DEPLOYMENT DEPLOYMENT DEPLOYMENT DESIGN
32.3 EQUIP AND
ELEMENTS ELEMENTS ELEMENTS CHANGES
EVALUATION FACILITIES FIGURE B-3
AND
FULL-SCALE ENGINEERING
DECISION
DEVELOPMENT PHASE
I L

L «
9£Sí.C0000C
 EVENT 16 ADVANCED DEVELOPMENT PROTOTYPE CONTRACT DEMONSTRATION AND VALIDATION PHASE TO
MILESTONE
II
EVENTS 14,15
1 EVENT 31 EVENT 33 EVENT 43 EVENT 48
LIFE CYCLE
INTERFACE

DCP1 AD
APPROVAL, AD DT
PROTOTYPE POTENTIAL CON-' CONTRACTOR VALIDATION
PROTOTYPE ROC/LR ACQUISITION
UPDATE RFP TRACTORS PREPARE VALIDATION PEP TEST DESIGN
CONTRACT PLAN
IPR/ASARC 11/
OAP V PROPOSALS PLAN
^ DSARC II v
EVENT 21
EXPAND SYSTEM
p OJEQU IREMENTS_ ^ UPDATE PROPOSED
DESCRIPTIONS

APPLICATION OF SYSTEM ENGINEERING DESIGN APPROACH

BASELINE

PROCESS TO FUNCTIONAL CONFIGURATION

* SYSTEM ENGINEERING OF OPERATIONS ELEMENTS
22.1
IDENTIFICATION (FCI) EXPAND DT 13.0 DEFINITION OF OPERATIONS REQUIREMENTS
9 • 0_PREPA_RATION_FOR_ PROPOSAL
UPDATE
SYSTEM r DEVELOP PROPOSED
9.1 9.2 13.1 13.2 SYSTEM
SPECIFICATION DESIGN AND
SYNTHESIS
11.0 INPUTS FUNCTION SYNTHESIS & SPECIFICATION
EXPAND lO^OSUPPORT APPROACHES
VALIDATION OF SYNTHESIZE TO PROPOSALS ANALYSIS OF PRELIMINARY
24.0 OTHER INPUTS
FUNCTION
ANALYSIS
PRELIMINARY
SYSTEM DESIGN
6.4 7.2
FUNCTION
ANALYSIS
CONCEPTUAL
DESIGN
9.4 10.1 r 11.1 I 12.0 OPERATIONAL DESIGN OF
OPERATIONAL
13.4. 14.0 19.0
20.0 21.0 22.2
INITIAL DEVELOP PROVIDE REQUIREMENTS
CONCEPTS DEVELOP
TECHNICAL
INPUTS TO ELEMENTS
DESCRIPTION PRODUCE /TECHNICAL
TECHNICAL UPDATE I / SYSTEM \ SYSTEM DESIGN

—r~
EVALUATION
DESCRIPTION
OF SYSTEM
ELEMENTS
CRITERIA
FOR TRADE-
OFF STUDIES
INPUT TO
REQUEST FOR/
PROPOSAL,
9.3
EVALUATION
SYSTEM
SPECIFICATION
PROPOSED
DESIGN
APPROACH
INPUTS
WORK
STATEMENTS
AND DTI
O LU

cr o
>- 13.3
EVALUATION
OF
OPERATIONAL
ELEMENTS
-r*/ REQUIREMENTS^
1
\ REVIEW /
1

r
6 DEF!I^TIOI\l_OF LOG_SUPRORT REQUIREjMENTS
1t:0
OPTIMIZATION'
TRADE-OFFS
SYSTEM
DESIGN
REVIEW
PROPOSED
DEVELOPMENT
UPDATE
SYSTEM
DESIGN
/ INPUTS TO
\ ALLOCATED
PEP

15.1 15.2 ^ SPECIFICATION \BASE LINE

AND AND AND
DECISION DECISION 11.2 DECISION
f INITIAL SYNTHESIS &
FUNCTION PRELIMINARY
10.2 ANALYSIS OF DESIGN OF 15.4
22
SE MGM'T LOG SUPPORT LOG SUPPORT , / DT II TEST
INITIAL L L
DEVELOP PLAN UPDATE - *< DESIGN
REQMTS .ELEMENTS DESCRIPTION
UPDATE LOGISTIC I \ PLAN
OZ LU OF LOGISTIC
SUPPORT PLAN SUPPORT 15.3 16.0* DEFINITION OF TEST REQUIREMENTS SUPPORT
1 O- (_> LOG SUPPORT
PLAN Q->- EVALUATION 16.1 16.2 PLAN
ZD <-J ELEMENTS
AND
INITIAL SYNTHESIS &
DECISION Ï
vû FUNCTION PRELIMINARY
Hr. 7.4 10.3 DESIGN OF 16.4 22.4
« ANALYSIS OF
*3: TEST
G- LIFE CYCLE
PREPARE DEVELOP TEST REQMTS INITIAL
INITIAL TEST ELEMENTS DESCRIPTION UPDATE TEST
TEST
INTERFACE
PROGRAMS PROGRAM 16.3 OF PROGRAMS
& PLANS & PLANS oo o 17.0*DEFINITI0N OF PRODUCTION REQUIREMENTS TEST & PLANS
LoJ >- EVALUATION
I— (_> 17.1 17.2
ELEMENTS
AND
INITIAL SYNTHESIS & DECISION
FUNCTION PRELIMINARY O
7.5_ 10.4 ANALYSIS OF DESIGN OF
o
17.4 >
STEP IN THE SYSTEM PRODUCTION PRODUCTION INITIAL
PREPARE DEVELOP
REQMTS ELEMENTS DESCRIPTION UPDATE
ENGINEERING PROCESS INITIAL PROPOSED 00
PRODUCTION
PLAN
PRODUCTION
PLAN
O (_>
ZD >- ~~T~ 17.3 I OF
PRODUCTION 18.0 DEFINITION OF DEPLOYMENT REOUIREMENTS.
PRODUCTION
PLAN
>
CO
m
Q <_) EVALUATION 18.1 18.2
O ELEMENTS
QZ AND INITIAL SYNTHESIS &
DECISION FUNCTION PRELIMINARY
7.6 10.5 ANALYSIS OF DESIGN OF 18.4
PREPARE DEPLOYMENT DEPLOYMENT INITIAL
SYSTEM ENGINEERING DEVELOP
♦SYSTEM ENGINEERING REQUIREMENTS ELEMENTS DESCRIPTION
INITIAL UPDATE
MANAGEMENT ACTION FIELDING
FIELDING
PLAN
PROfcbSS (SEf FIG. 2-1)
PLAN
>- _l
o o
18.3 1 OF
DEPLOYMENT
FIELDING
PLAN
O- O
LjJ
EVALUATION
ELEMENTS FIGURE B-2
AND
Q
DECISION _J DEMONSTRATION AND
VALIDATION PHASE
•V

m
 »
i
*
Z'

ZI
3000031536