Document created: 29 October 2003
Air University Review, November-December 1973
Major Chris N. Wilcox
One of the crucial problems in the communications-electronics management area is assuring that systems and services remain responsive to Air Force needs in the face of changing technology, restricted resource climates, and revised concepts of command and control. Solving this problem requires effective planning, which depends in turn on the accurate and timely definition of operational requirements.
As used here, the term “operational requirements” pertains mainly to the basic needs of operating organizations for communications services such as command and control channels, data links to computers, air/ground radios, or telephones that are essential for accomplishing the Air Force’s mission. Operational requirements must include sufficient detail to quantitatively describe the service required, for example: range, accuracy, reliability, or security. Not included are technical and support considerations that pertain to finding the best or most efficient way to provide a service; these are design considerations.
The collection and analysis of requirements constitute a complex undertaking, hampered by a great deal of inherent uncertainty and imprecision. Informed opinion often differs concerning the validity of individual requirements and the accuracy of their specifications. While the use of analysis and systems engineering can remove some of the subjectivity regarding individual requirements, a number of problems remain, particularly in dealing with the communications picture as a whole.
First, there is a need for a more aggressive approach toward collecting and sifting requirements. Dr. John S. Foster, Jr., Director of Defense Research and Engineering, warns that the military must use “a specific effort by competent people” to identify deficiencies in peacetime so that they will not surprise or haunt us in war.1 Clearly, such an effort must be thorough and comprehensive. For example, in addition to inspections for procedural compliance, there must be thorough, searching analyses of the procedures themselves. In addition to knowing that systems are operating as designed, it is important to know if the design itself is still responsive to the mission. Also, it is implicit in Dr. Foster’s warning that planners seek to forecast requirements rather than wait until the needs become obvious; otherwise, there may not be time to respond.
Second, more attention must be paid to relationships between requirements. Considerations of commonality and interoperability tighten the coupling between otherwise unrelated requirements. Although our experience as far back as World War II and Korea showed the necessity for standard communications equipment, for the past fifteen years the growing utility of computers and leased communications services has led to a lapse of standardization in favor of cost savings and special responsiveness considerations. Now the costs of computer systems, needs for interfaces between previously separate systems, and centralized control of the strategic forces are reversing the trend. But the very efforts of making interfaces and seeking commonality severely complicate the requirement process because of the necessary trade-off and external system considerations.
Third, decision-makers cannot evaluate requirements in isolation. To make resource allocations as wisely as possible, they must have a mechanism for placing requirements within the context of higher missions and other competing requirements before assigning priorities. This is difficult when commands develop and forward requirements piecemeal for approval, as current procedures allow.
In order to address these problems more effectively, it is helpful to take a systems approach toward requirements identification and analysis. Although there is an identifiable method to the systems approach, it is more properly described as a frame of reference whereby the planner thinks in terms of groups of requirements and their interrelationships rather than isolating requirements to simplify the solution. The broader view has an obvious appeal, but there are significant pressures that make it easier to deal with narrow rather than broad requirements. The narrow requirements are easier to analyze, understand, articulate, fund, and solve. Thus, the planner is tempted to simplify his requirement statement, defining away peripheral problems, limiting the scope of his analysis. While this simplifies his immediate analysis problem, the method fails to give a complete picture of deficiencies, forces decision-makers to make judgments without a full analysis of the problem, and exacerbates interfacing and commonality problems.
It is neither possible nor desirable to do away with the analysis of discrete requirements, but it is necessary to increase that dimension wherein individual requirements can be considered as part of the larger context. In this way commonality can be better addressed, more deficiencies surfaced, needs better tied to objectives, and requirements “prioritized” and compared.
There are basically three steps to requirements development: collection, specification, and integration. Collection concerns the surfacing of requirements. Specification is the process of determining those qualitative and quantitative parameters that describe the requirement and yield design criteria. Integration involves presenting the requirements in a consolidated, time-phased plan and linking them to command objectives and operational concepts. Through all three steps, systems analysis and systems engineering techniques play a vital role. The following paragraphs emphasize the requirements process at a major command headquarters, but the same steps apply at other echelons as well.
the role of systems analysis
Disciplined analysis is essential to each phase of the requirements process. If properly applied, the methodology yields quantitative information about requirements to assist in establishing priorities, deciding when improvements are needed, determining which improvements are worth the cost, and gaining approval for programs. Van Court Hare lists six basic questions that systems analysis can help answer:
What are the system boundaries?
How does it operate?
Does it work as predicted?
Why does it fail to work as specified?
Can it be improved?
What are the effects of change?2
The first question is particularly important because we often define our systems in too limited a way. System boundaries are sometimes drawn at the point where communications hardware leaves off. Considerations of the user and his operations or of systems that must interface with the communications networks are then neglected.
For example, commands sometimes reduce the number of AUTOVON access lines at air bases when operations and maintenance funds are tight. Although the commands know how much communications money is saved, they can only estimate the cost of such cuts to the user. The system boundary for analysis purposes has been drawn between the telephone and the user. But calls take longer to establish, and users spend more time dialing. Who knows what this costs in terms of office efficiency? Perhaps only a little, perhaps a lot. The costs may considerably exceed the dollars saved. In any case, the cost of degraded service to to the user is a valid, essential economic consideration. It is easy to lose sight of such factors when system boundaries are too narrowly defined in the analysis process.
Hare’s other questions are more straightforward. Communications organizations have always been interested in the answers. However, formal analysis should be increased and used on a continuing basis to explore the answers in terms of basic operational requirements. More attention to the analysis disciplines can pay dividends by bringing precision to an otherwise subjective requirements process. The following paragraphs explain the steps and show in more detail how systems analysis can contribute.
The first step is collecting requirements. They can be surfaced in a number of ways: demand-pull; technology-push; analyses of system operations; study of operations, logistics, contingency, and other kinds of plans; and, finally, through interviews. Each of these techniques, assisted by thorough systems analysis, can make significant contributions to the development of an accurate, integrated picture of communications requirements. Used together in a systematic way, they can yield the steady flow of information necessary to keep the requirements picture current and to allow timely planning and forecasting.
Demand-pull is the source of most short-range requirements. The customer has a specific problem. Where the need relates directly to a unit’s mission, justification is straightforward. Needs for hot lines, closed-circuit television, or common telephones fall into this category. Some demand-pull requirements involve the acquisition of extensive communications networks or costly research and development programs. The Semi-Automatic Ground Environment (SAGE), for example, resulted basically from a demand-pull requirement as the Air Force sought a better means for controlling air defense operations.
Although all valid requirements for communications services and systems would surface sooner or later by this method alone, there is a major pitfall. If the communicator relies solely on demand-pull, he will frequently learn of the requirement too late to respond to the user’s required operational date. Lead times for system design and acquisition are usually measured in years, particularly for nonstandard facilities and services. Further, there is the increased cost associated with crash programs; systems come cheaper through orderly planning. This in turn requires forecasting and the aggressive collection of requirements.
Telephone service in New York City, for example, has been in relative chaos because New York Tel’s forecasting for the late 1960s and early 1970s failed to predict a future surge in demand. The company had curtailed investments in expanded facilities and was not able to respond fully.3 The result was lost revenue for the telephone company, inability of many customers to obtain the service they required, and a loss of public confidence. Air Force communications are susceptible to the same problem. Communications planners cannot rely solely on demand-pull. They need active measures to ferret out requirements and forecast resource demands.
Technology-push is one means of stimulating requirements inputs. Through a continued awareness of the capabilities available from an expanding technology, the communicator is sometimes in a position to suggest technological innovations to improve existing services or to offer entirely new ones to subscribers. Similar suggestions will also come from contractors. In either case, the mechanism is technology-push.
There are some dangers, however. According to Dr. Foster,
We have met with some success in the past by using the approach of selecting promising new technology and then identifying applications that improve our capabilities. But this approach—a solution looking for a problem—too seldom strengthens our weakest link. . . . Unless we emphasize the programs that are founded on valid deficiencies and also represent demonstrably effective solutions, we waste millions, we diminish deterrence, and we risk lives and property.4
Planners can best find the weakest link by thorough analysis of existing systems, but to do so they must be careful to define the boundaries properly. Most communications organizations employ regular procedures for analyzing such functions as switchboard operations, communications centers, radio networks, and maintenance performance. Although these procedures yield valuable measures of efficiency, responsiveness, and other factors relating to specific operations or systems, rarely do organizations analyze communications as a whole: relationships between systems, user considerations, value of the services performed, or the continued utility of services in a changing environment. This can be a serious shortcoming.
Communications organizations must apply the analysis disciplines more extensively to the examination of communications systems in a broader context. They do this from time to time through special study groups, but this does not maintain the continued emphasis on requirements analysis so essential at major command level. Requirements change. Their continued analysis is part of the command planning cycle and a valuable input to the decision process. The requisite up-to-date knowledge about them cannot be obtained through a periodic kind of analysis whose results soon become outdated.
A fourth source of communications requirements is the study of operations, contingency, developmental, logistics, and other kinds of plans. These plans often specify directly what communications are required for support. One must be careful, however, to analyze the plans for any hidden support considerations. When the plan is brought to fruition, hidden requirements will come out, usually on short notice. They are much easier to solve in advance.
Also, it is axiomatic that planners should assess the cumulative effect of various plans on the communications systems that support them. Taken individually, each of several plans may levy support requirements that are well within the capabilities of current systems. Taken together, however, the plans may call for more communications than are available. If the plans are likely to be executed in parallel, planners must assess the aggregate requirement.
The last technique, systematic interviewing, although infrequently employed, is a good way to survey a command or a headquarters to determine how the managers and operations personnel view their long-range needs for communications. The replies should be put together in a mosaic to form an input to the long-range requirement process. The interview process taps the flow of unstructured ideas that circulates within a headquarters or operational unit. In a sense, the interviewing is like an organized brainstorming session with the users of communications. It produces a wealth of information not otherwise available.
Each technique for surfacing requirements yields important results, but the techniques are best used in concert. No single method gives all the information needed for accurately projecting communications requirements. The emphasis placed on each method should vary with the circumstances. At the unit level, for instance, demand-pull and the study of plans would be more useful than the other techniques. At any organizational level these two techniques tend to produce the shorter-range requirements. Interviewing is more fruitful at major command level in the process of developing long-range requirements estimates, and then on a periodic rather than continuous basis. Although systems analysis techniques can be used at any level, the special expertise needed for full application is normally available only at major command headquarters and above. Again, to gain the needed insight into requirements, commands should use all five techniques and blend the inputs.
Requirements as originally collected are not sufficiently detailed to permit programming, approval, or systems design. Fully specified requirements must answer the familiar questions of who, what, when, where, why, and how many. Except for the why, discussed later, these details are called the parameters of the requirement. Specification is the process of quantifying the parameters, which in turn describe the requirement. A parameter is defined as “a variable or an arbitrary constant appearing in a mathematical expression, each value of which restricts or determines the specific form of the expression.”5
Parameters give form to a requirement statement in the same manner that they do for a mathematical expression. To enable the designer to find the best solution, parameters must be expressed in terms of the requirement and not a possible solution. For example, required data rates should be specified in terms of what is actually needed, not in terms of commercially available bandwidths or equipment; the designer can then best determine how to provide the required data rate. Air Force Manual 100-17 lists such typical parameters as the requesting agency, terminal locations, traffic volume, security needs, required operational date, operational concept, related plans, and compatibility and interface considerations.6
Parameters are the criteria for system design. Later, when system design and tradeoff decisions are made, it will be vitally important to know the basis for parametric values. If they were based on judgments, designers need to know the confidence level. Otherwise they might go to unnecessary expense or sacrifice of other capabilities in trade-offs to sustain one parameter at some arbitrary level. For example, in the design of digital command and control systems, it is essential, in order to provide sufficient transmission and switching capacity in the network, to know the allowed time to get a message from sender to receiver. Many other things such as traffic volumes, message lengths, and traffic distributions also affect capacity, but delivery times are sensitive parameters, especially when specified to be within the range of a few seconds. Sensitivity implies that changes in the parameter’s value cause significant changes in system cost. Very short delivery times associated with long messages equate to wide channel bandwidths, which cost much more than narrow-band channels. Because system costs can be sensitive to short delivery times, it is essential that such parameters be as accurate as possible and that the designer have some idea of how they were derived. Does one, for example, really need delivery within ten seconds instead of two minutes? If so, the designer can provide it, but at significant additional cost.
Parameters may also be operationally critical. Their values make a critical difference in a system’s responsiveness. Some of the most operationally critical parameters are the delivery times required for messages that launch the SAC bomber fleets or warn the National Command Authority of an impending missile attack. Any delay in these messages can be equated with the possibility of having a portion of the strategic forces destroyed. For these vital messages, time is operationally critical. Delivery times down to five or ten seconds can be readily justified, even at greatly increased cost. In such cases, the systems analysis and systems engineering disciplines are indispensable for determining sensitivity or criticality and in assessing trade-off considerations.
Although not defined as a parameter, another important element of the requirement statement is the justification. Essential for establishing priorities or gaining approval and funding, justifications explain the requirement and the consequences of not meeting it. Needless to say, the justification and impact statements must be strong and vital in order to gain approval in today’s funding environment. In this regard, one cannot overemphasize the importance of tying requirements closely to command missions. It is also critical, in the approval arena, that individual requirements be supportive and not compete with each other. This is one of the main values of having an integrated plan that encompasses all of a command’s communications requirements; mission and interrequirement relationships can be examined and articulated.
The development of a broad requirements plan is essentially the integration step. Integration itself involves a melding of requirements in such a way that planners can view the entire scope of a command’s needs for communications services, identify overlaps or shortfalls, show how requirements relate to higher objectives, and spell out actions needed to remedy deficiencies.
The process of transforming requirements and their parameters into an integrated plan is more of an art than a science. The goal should be to portray a command’s total requirements for communications—say over a five-year period—in sufficient detail to guide programming actions and assure that planners address problems as a whole. The plan need not include all parameters for each requirement; however, those details should be available elsewhere to furnish guidance to program managers and design teams. On the other hand, the plan must include such things as required operational dates, interface and commonality considerations, relative priorities, phase-out dates, general descriptions of the major requirements, and how they are to be satisfied.
Equally important is a narrative analysis of the key communications deficiencies and their impact on the command’s mission. This part of the plan should discuss relationships among requirements themselves and between communications requirements and the command’s mission. If new data systems are programmed, the requirements plan should show how communications support will be provided. If on-line communications are required for several data systems, the plan should explore the possibility of providing a single, common supporting communications system. If that is infeasible, the plan should develop the rationale to support the acquisition of special-purpose communications for those systems that require them, both supporting commandwide programs and integrating communications capabilities.
A systems approach toward communications requirements and the development of an integrated requirements plan are essential for laying a firm planning foundation. Communications requirements determine the missions of communications organizations. The interpretation of requirements and the way they are defined determine how well communications will be able to support the primary Air Force mission. This interpretation and definition, to be effective, must be applied on a broad requirements scale so that all deficiencies can be surfaced, interface and commonality considerations addressed, and requirements more effectively linked to each other and to higher mission considerations. The result will be a clearer understanding of communications objectives and better planning to achieve the primary mission.
Headquarters Pacific Command
1. John S. Foster, Jr., “Weapon Systems We May Face—and Better Have,” Supplement to the Air Force Policy Letter for Commanders, United States Air Force, March 1973, p. 17.
2. Van Court Hare, Jr., Systems Analysis: A Diagnostic Approach (Harcourt, Brace & World, Inc., 1967), pp. 237-41.
3. Allan T. Demaree, “The Age of Anxiety at A.T.&T.,” Fortune, May 1970, p. 264.
4. Foster, op. cit.
5. American Heritage Dictionary.
6. Air Force Manual 100-17, C-E Facility and System Planning, 12 June 1967, p. 9.
Major Chris N. Wilcox (B.S.E.E., Purdue University; M.A., University of Nebraska) is assigned to Hq Pacific Command, Directorate of Communications-Data Processing (J-6), Systems Division. His last assignment was with Hq Strategic Air Command in the SAC Automated Total Information Network (SATIN IV) Project Office. Other assignments have been with the Air Force Technical Applications Center and Aerospace Defense Command in communications-electronics activities.
The conclusions and opinions expressed in this document are those of the author cultivated in the freedom of expression, academic environment of Air University. They do not reflect the official position of the U.S. Government, Department of Defense, the United States Air Force or the Air University.
Air & Space Power Home Page | Feedback? Email the Editor