Functional Analysis and Requirements Allocation

Preliminary system design, sometimes referred to as advanced development, begins with the technical baseline for the system (often described by a system-level specification or the A Specification) and proceeds through the translation of established system-level requirements into detailed qualitative and quantitative design requirements. The tech­nical baseline includes the definition of operational requirements and the maintenance concept (described in Chapters 3 and 4), and the translation process is accomplished through functional analysis and requirements allocation, the accomplishment of trade­off studies, synthesis and system optimization, and so on. Basically, the preliminary design process is iterative in nature and drives the design toward the detailed definition of a specific system configuration. The activities associated with this phase of the life cycle are reflected by blocks 3 through 9, Figure 3-1.

5.1. System functional analysis

An essential element of preliminary design is the utilization of a functional approach as a basis for the identification of design requirements for each hierarchical level of the system. A function constitutes a specific or discrete action required to achieve a given objective (e.g., an operation that the system must perform to accomplish its mission, a maintenance action that is required to restore the system to operational use). Such actions may be accomplished through the use of equipment, personnel, facilities, software, data, or a combination thereof. The functional approach helps to assure:

1. That all facets of system development, operation, and support are covered. This includes design, production/construction, test, deployment, transportation, train­ing, operation, and maintenance.

124

126

Functional Analysis and Requirements Allocation Chap. 5

i

hierarchy of system functions, and functional interfaces. Functional flow diagrams are designated as top level, first level, second level, and so on. The top-level shows gross operational functions. The first-level and second-level diagrams represent progressive expansions of the individual functions of the preceding level. Functional flow diagrams are prepared down to the level necessary to establish the needs (hardware, software, facilities, personnel, data) of the system. The indenture relationships of functions by level are illustrated in Figure 5-1, and the major steps involved in developing functional flows are noted below.

1. Function numbering. Functions identified on the functional flow diagrams at each level should be numbered in a manner which preserves the continuity of functions and provides information with respect to function origin throughout the system. Func­ tions on the top-level functional diagram should be numbered 1,0, 2,0, 3.0, and so on. Functions which further indenture these top functions should contain the same parent identifier, and should be coded at the next decimal level for each indenture. For example, the first indenture of function 3.0 would be 3.1, the second 3,1.1, the third 3.1.1.1, and so on. For expansion of a higher-level function within a particular level of indenture, a numerical sequence should be used to preserve the continuity of function. For example, if more than one function is required to amplify function 3.0 at the first level of inden­ ture, the sequence should be 3.1, 3.2, 3.3, . . , , 3.n. For expansion of function 3.3 at the second level, the numbering shall be 3.3.1, 3.3.2, . . . , 3.3.n. Where several levels of indentures appear on a single functional diagram, the same pattern should be main­ tained. While the basic ground rule should be to maintain a minimum level of indentures on any one particular flow, it may become necessary to include several levels to preserve the continuity of functions and to minimize the number of flows required to functionally depict the system.

2. Function reference. Each functional diagram should contain a reference to its next higher functional diagram through the use of a reference block. For example, func­ tion 4.3 should be shown as a reference block in the case where the functions 4.3.1, 4.3.2, . . . , 4.3.n, and so on, are being used to expand function 4.3. Reference blocks shall also be used to indicate interfacing functions as appropriate,

3. Function block. Each separate function on a functional diagram should be pre­ sented in a single box enclosed by a solid line. Blocks used for reference to other flows should be indicated as partially enclosed boxes labeled "Ref." Each function may be as gross or detailed as required by the level of functional diagram on which it appears, but it should stand for a definite, finite, discrete action to be accomplished by equipment, personnel, facilities, software, or any combination thereof. Questionable or tentative functions should be enclosed in dotted blocks.

4. Flow connection. Lines connecting functions should indicate only the func­ tional flow, and should not represent either a lapse in time or any intermediate activity. Vertical and horizontal lines between blocks should indicate that all functions so inter­ related must be performed in either a parallel or series sequence. Diagonal lines may be used to indicate alternative sequences (cases where alternative paths lead to the next function in the sequence).

128

Functional Analysis and Requirements Allocation Chap. 5

1i K*" !* /; '

5. Flow directions. Functional diagrams should be laid out so that the functional flow is generally from left to right and the reverse flow, in the case of a functional loop, from right to left. Primary input lines should enter the function block from the left side; the primary output, or "go" line, should exit from the right; and the "no-go" line should exit from the bottom of the box.

6. Summing gates. A circle should be used to depict a summing gate. As in the case of functional blocks, lines should enter and/or exit the summing gate as appropriate. The summing gate is used to indicate the convergence, or divergence, of parallel or alternative functional paths and is annotated with the term "AND" or "OR." The term "AND" is used to indicate that parallel functions leading into the gate must be accom­ plished before proceeding to the next function, or that paths emerging from the AND gate must be accomplished after the preceding functions. The term ''OR" is used to indicate that any of several alternative paths (alternative functions) converge to, or di­ verge from, the OR gate. The OR gate thus indicates that alternative paths may lead or follow a particular function.

7. Go/No-go paths. The symbols "G" and *^SG" are used to indicate "go" and "no-go" paths, respectively. The symbols are entered adjacent to the lines leaving a particular function to indicate alternative functional paths.

8. Numbering procedure for changes to functional diagrams. Additions of func­ tions to existing data should be accomplished by locating the new function in its correct position without regard to sequence of numbering. The new function should be num­ bered using the first unused number at the level of indenture appropriate for the new function.

The functions identified should not be limited to only those necessary for operation of the system, but must consider the possible impact of maintenance on system design. Maintenance functional flow diagrams will, in most instances, evolve from operational functional flow diagrams. Maintenance requirements (evolving from the maintenance concept) should be addressed to preclude the possibility of developing a technically feasible system from an operational viewpoint, without first determining whether or not the system can be effectively and economically supported throughout its planned life cycle. Experience has indicated that the costs associated with system maintenance and support often far exceed the cost of system acquisition. The objective is to attain the proper balance of performance, effectiveness, support, and economic factors.

The benefits associated with the generation of functional flows are many. First, the process enables the engineer to approach design from a logical and systematic stand­point. The proper sequences and design relationships are readily established. Second, the preparation of functional flows forces the integration of the numerous interfaces that exist in system development and operation. Both internal and external interface problems are quickly identified at an early stage in the life cycle. Sometimes these benefits are difficult to visualize unless one has actually had some experience in functional analysis. However, it has been shown that many design problems which occur later in the life cycle could have been avoided had this approach been followed initially.

CO

o

Example: System Top-Level Function Series

2.0

Design

_

i

4.0

Prime

Deline System Requirements

Mission

Equipment			Perform System Integration and Test
3.0
Design System Support Capability
			I

"~\ i

i i

Procure

Elements of Support