Perhaps the reader remembers the comedy routine in which a performer orates a lyrical, emotive passage in a deep, inspiring voice—except the quotation is in some unintelligible language. Another performer asks, “What does that mean in English?” The translation is something like, “The snake fell out of the tree, onto the baby and ate him.” As audience members gasp in revulsion, they hear the punchline, “It loses something in translation.”
Requirements managers, program managers and warfighters also gasp in revulsion after engineering teams translate requirements into specifications. Sometimes something gets lost.
More often, requirements turn into extensive and expensive specifications. The program managers decry “requirements creep” while the requirements managers—representing the warfighter—wonder what went wrong with their clear, specific and necessary operational requirements.
From Analysis to Requirement to Specification
Remember how everything starts with analysis. The Capabilities-Based Assessment starts with directives, policy changes and reports from the field to determine what the warfighter must be able to do. The assessment prioritizes the support and materiel for the warfighter, and the requirements managers write the appropriate documents. If nothing else fills a capability gap, requirements managers must make a case to develop something new.
Ideally, the requirements managers write the minimum number of measurable, unambiguous, results-oriented operational requirements. Every acquisition team member can read those requirements and immediately agree on how to meet them. Unfortunately, this is not an ideal world. Unfortunately, the reality of what is possible turns clear goals into complicated systems, subsystems and components. This amounts to an “explosion” of technical requirements and specifications after the initial validation of the operational requirements.
These technical requirements and derived technical specifications provide the details necessary to develop, design, manufacture, test and support the hardware behind a military capability. For example, a validated operational requirement may lead to developing a new tracked vehicle. Top-level operational requirements may lead to a technical requirement for treads necessary to transit areas with low traction. Since U.S. forces have a worldwide mission, the operational requirement may lead to derived technical specifications such as tread width calculated on maximum allowable ground pressure for the worst-case operational terrain.
The process of progressing from high-level operational requirements to technical requirements to component specifications looks something like the illustration from a recent Government Accountability Office (GAO) report (Figure 1).
Figure 1. How Operational Requirements Become Component Specifications
While supporting the warfighter is of overriding importance, meeting the warfighters’ needs becomes complicated and expensive in the translation from system to subsystem to component.
What Is a “Requirement?”
Part of the confusion comes from disagreement over the very word “requirement.” Too often, a reader must use the context to determine whether a document is about capability requirements, strategic requirements, technical requirements or any of the other requirements in the partial list below.
For the sake of clarity, the two documents behind the Joint Capabilities Integration and Development System (JCIDS)—the Chairman, Joint Chief of Staff Instruction (CJCSI) 3170.01 and the JCIDS Manual—do not use the single word “requirement” but consistently define and apply the term “capability requirement.” Both sources define capability requirement as “A capability which is required to meet an organization’s roles, functions, and missions in current or future operations.”
All Requirements Are Created Equal—Then It Gets Complicated
Once the requirements managers document the capability requirements, the translation to specifications begins. Part of the loss in translation comes from the need for technical specificity and clarity. For example, the International Council on Systems Engineering (INCOSE) Handbook has a more rigorous definition of a requirement: “A statement that identifies a system, product, or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand-alone (not grouped), and verifiable, and is deemed necessary to stakeholder acceptability.”
The confusion over terminology is exacerbated further by confusing requirements with specifications. Requirements managers at the top of the pyramid apply their operational experience to draft the “high-level” operational requirements. Systems engineers turn those operational requirements into technical requirements for the subsystems and into specifications for each component. This means both requirements managers and systems engineers write statements called requirements. To many program managers and program offices, anything called a requirement becomes non-negotiable. Failing to meet any requirement is unacceptable. The program office and the developing contractor will do their best to meet any and every requirement, whatever its source.
One saving advantage is the flexibility the Pentagon leadership had built into JCIDS. First, not every operational requirement has the very highest priority. Once the requirements managers develop the operational requirements for a proposed new system, the managers triage those requirements into three priority levels: Key Performance Parameters (KPPs), Key System Attributes (KSAs) and Additional Performance Attributes (APAs). See Figure 2.
Figure 2. The Requirements Hierarchy
The JCIDS Manual defines KPPs as: “Performance attributes of a system considered critical or essential to the development of an effective military capability.” Originally, failure to meet a KPP meant that the Department of Defense (DoD) would cancel the program. Declaring a requirement a KPP was tantamount to saying, “If the new system cannot meet this requirement, we don’t want it at all. We will keep what we have now.” This standard has softened to the point that a failure to meet a validated KPP will trigger a review. This validation authority review may lead to program cancellation, but it may also result in the modification of production increments or in an updated KPP value.
The authority that validated the KPP can modify the KPP. For an Acquisition Category I program, the validation authority is the Joint Requirements Oversight Council (JROC) chaired by the Vice Chairman of the Joint Chiefs of Staff. Managers approach the JROC with great trepidation, but Pentagon leadership strives to show the flexibility that requirements managers and program managers need in order to make necessary modifications and trade-offs.
KSAs are one step below KPPs. The JCIDS Manual defines KSAs as, “Performance attributes of a system considered important to achieving a balanced solution/approach to a system, but not critical enough to be designated a KPP.” A sponsor at the level of a four-star officer or an Agency Director can modify a KSA.
The APAs offer more opportunity to make trade-offs as the requirements managers and the program offices apply lessons learned during system development. APAs are performance attributes of a system that are not important enough to be considered KPPs or KSAs but still appropriate for inclusion in requirements documents such as the Capability Development Document (CDD) and the Capability Production Document (CPD).
One remaining area of confusion involves the difference between threshold and objective values. The threshold value is the minimum value that will have operational utility. In other words, a threshold may be the minimum range or payload that the warfighter will find useful. The objective is either the maximum parameter or the maximum feasible parameter that offers operational utility. Anything beyond the objective is beyond what the user will need. Capability beyond the objective amounts to the “gold plating” everyone wants to avoid.
Remember that KPPs, KSAs and APAs all represent capability requirements. When the systems engineers develop technical requirements, the sheer number of those technical requirements can become overwhelming.
High-level requirements—capability requirements derived from analysis and developed by requirements managers with operational experience—lead to many low-level requirements such as technical requirements and specifications. Congress decries this “requirements explosion.” Program managers scream “requirements creep.” All the warfighter really cares about are the high-level requirements, the capability requirements. At the operational level—when guns are firing and bombs are exploding or the rocks are getting too close—the warfighter does not have time to care about the technical requirements and specifications. The overriding goals remain defeating the enemy and protecting our forces, friendly forces and noncombatants.
The challenge becomes knowing when to make essential, effective trade-offs. Here is where program management and requirements management combine into a contact sport; bad things happen when each specialization works in isolation. The requirements manager—representing the warfighter—must work with the systems engineers within the program office. Managers and engineers combine their knowledge and experience to develop appropriate tradeoffs. At the inception and throughout the acquisition phases, all parties need coherent answers to critical questions such as:
- What capability does the warfighter really need?
- How do we know that stated need is valid?
- What are the costs and associated risks associated with meeting a threshold or an objective?
- Can we deal with the associated costs and risks of missing a threshold?
- What is the nature of the associated costs? —Are we talking about money? Delay? Reliability?
- Does missing a threshold really degrade the military capability?
- What are the payoffs of going beyond the threshold and achieving the objective?
- —What are the risks involved in going beyond the threshold?
- What do the ensuing risks mean to the warfighter?
- Who needs to validate the trade-offs?
As a development program progresses from analysis to production, many people have opportunities to apply the lessons learned from the Technology Maturation and Risk Reduction phase and the Engineering and Manufacturing Development phase. These lessons learned, for example, may show requirements managers new ways to apply new systems. These lessons also may help the systems engineers and the other technical experts understand what will and will not work in operational environments. Insight into the concepts of operations can guide trade-offs that make the difference between a good system and a transformational system—a system guaranteeing that our warfighters prevail.
The Clash of Cultures
The DoD has excellent reasons to combine three different management systems into what the Defense Acquisition University calls “Big A Acquisition.” JCIDS represents the warfighter and develops the capability requirements. The Defense Acquisition System turns those requirements into specifications and strives to meet those specifications. Planning, Programming, Budgeting, and Execution lines up the resources, including funding. These three management systems operate with different schedules, priorities and urgencies. Successful programs need experienced and talented management to keep the three systems working together.
While the warfighter first cares about accomplishing the mission, the engineers and the rest of the acquisition community focus on how to accomplish the mission. One cultural clash results from different group definitions of success. Success to the acquisition community does not necessarily mean success to the warfighter. Meeting every specification does not guarantee operational utility. It is difficult to achieve agreement between the different viewpoints. Here is where requirements managers and program managers need to be aware of the potential breakdowns that can arise from the clash between their two cultures. Both types of managers should anticipate additional confusion as they depend on the technical and professional expertise of diverse professions such as the system engineers, test managers and logisticians.
Solutions From Leadership, Management and Communications
Everyone can agree that great leadership and great management demand great communications. We cannot afford to waste time and money on unnecessary requirements and specifications. All of the specialists and managers live with the same funding limitations, scheduling priorities, state of technology and laws of physics. Everyone needs to recognize the differences between capability requirements and technical specifications. In the ideal situation, everyone agrees on which trade-offs would most reasonably help accomplish the mission on time and within the budget.
It isn’t easy to establish and maintain communications across the different groups. Every team member wants to do a great job for the warfighter. But the unintelligible language of a different professional culture and the confusion from different points of view can derail the best intentions. Requirements managers have a responsibility to communicate why they need the requirements that they write and validate. Great systems engineering shows a clear trail from the high-level capability requirement to the technical specifications. Everyone needs to avoid the confusing practice of calling technical specifications “low-level requirements.”
Great communication takes time, effort and understanding. To that end, we all are translators who cannot afford to lose important requirements and distinctions in translation. We all need insight into the DoD processes, into the different management systems within “Big A” Acquisition, and into the different disciplines that are needed to develop our programs.
Now, is that a carnivorous snake in the tree or a colorful ribbon floating in the breeze? Is the baby being eaten alive or is he simply giggling in delight over a harmless new toy? The differences are significant. In the same vein, we must work together to make accurate but necessary translations as we go from capability requirements to technical specifications and then to operational systems.
Court is the Requirements Center Director at the Defense Acquisition University’s Defense Systems Management College at Fort Belvoir in Virginia. He is a former Wild Weasel Electronic Warfare Officer, a test manager, a program manager, and an Air Force laboratory supervisor. His doctorate from Walden University specialized in Organizational Behavior.
The author can be contacted at email@example.com.