Turning “Desirements” into Requirements

Author: Charles Court

Court is the Requirements Center Director at the Defense Systems Management College at the Defense Acquisition University at Fort Belvoir, Virginia. He is a former Wild Weasel Electronic Warfare Officer, a test manager, a program manager and an Air Force laboratory supervisor.

Because we are humans, everything we need either starts or finishes with something we want. As students, we could take the bus to school, but we wanted a car. Moreover, we did not want just any car. A Corvette, a Porsche or a Mustang would do much better. (The author wanted the Aston Martin from the movie “Goldfinger.” You know: The one with the ejection seat, automated license plates and electronic tracking.) On the professional military level, the Services and agencies fall into the same trap. There are things we need, but many more things we want. Why settle for tanks, ships and aircraft if we could have cloaking devices, The Death Star, Mr. Fusion and phasers?

One way to look at this conundrum is to see the difference between “desirements” and requirements. The word “desirement” is new. You cannot find it in most published dictionaries. The online dictionaries define “desirement” as something desired but not absolutely required. Unfortunately, the word “requirement” means different things to different people. As the Defense Acquisition University (DAU) develops and teaches classes, faculty members hear much about “‘Big R’ Requirements” versus “‘little r’ requirements” and volumes about “requirements creep.” The challenge is how to turn desirements into requirements. How can requirements managers make the case that something is absolutely required?

There are several schools of thought. Some contend that a requirement is not a requirement until it is funded. Others argue that a requirement is nothing until staffing is complete and the appropriate authorities validate it. Still others contend that requirements can exist only under a Program of Record where there is overlap between the three Department of Defense (DoD) management systems of requirements, acquisition and funding. The most confounding approach is, “The President/General/Admiral wants it.”

sep-15-article-6-secondary-2Over the course of many classes and Mission Assistance efforts, the DAU requirements faculty contends that a requirement has the support of a continuing process of analysis. A desirement lacks such objective analysis. To begin the necessary objective analysis, managers must understand the level of the requirement. Next, a Capability Based Analysis (CBA) must begin the intellectual support behind the requirement. Finally, requirements must evolve and adapt to changing threats and to lessons learned during development. Throughout this evolution, requirements managers and program offices must keep the requirements focused. Everyone must avoid the messy, time-consuming and expensive changes everybody calls requirements creep.

Different Levels of Requirements

On the grandest scale, decision makers should ask: How can we prevent any conflict? How can we turn potential enemies either into noncombatants or (better still) into friends? At the extreme level, DoD has two essential requirements:

  • Neutralize the enemy.
  • Protect friendly forces and noncombatants.

Essentially, in combat we want the enemy defeated and all of our troops and all of our friends to come home unharmed. Achieving these two overriding goals gets complicated quickly. How do we find and identify the enemy? What do we need to know about the enemy’s intent and capability? How do we determine that intent and capability? What means do we have to defeat the enemy? How do we communicate with our forces? What steps will protect our forces, our allies and the noncombatants? How do we get ourselves and our equipment into the fight and then back home?

Raising such questions helps us identify different levels of requirements. The “Big R Requirements” include identifying the mission and answering the broad questions above. These “Big R Requirements” lead to “small r requirements” that specify the capabilities our troops need to accomplish various missions in diverse operating environments. For example, what range, payload and speed do transport aircraft need either to respond to a crisis or to resupply a sustained effort? What meets the military utility as opposed to excess, surplus and overpriced capability frequently derided as “goldplating”?

Start with Analysis—The CBA

So how does a manager turn that desirement into a requirement? First, recognize the difference between the desirement (“I want a new tank/ship/airplane/missile”) and a required capability (“We need to resupply our troops”). The thought progression usually goes through four steps:

  • What do we want?
  • What do we need?
  • What do we need to be able to do?
  • What can we afford?

Notice how these steps start with a question centered on some hardware or service and then move to a capability. The thought process begins with “we want something new,” considers the essential “what we need,” and finally recognizes the capability with a statement such as, “We need to determine the enemy’s intent.” The process must return to feasible solutions when we face the budgetary limits. The DoD has a huge budget, but we cannot spend all that money on just one thing.

Good analysis to support this thought process becomes simple and complicated at the same time. The steps are straightforward and repeatable. However, each problem has unique elements and technical challenges. Diverse technical problems call for subject-matter expertise from different disciplines with different terminologies, different priorities and different points of view. Here is where leadership and experience count. An analysis team leader must know the steps, get the necessary support and schedule everything to provide a timely answer.

At the very beginning, the leader and the analysis team must identify the mission or problem the analysis must address. To keep things on track, everyone must agree on the study scope: Is this analysis a complicated new mission area or a straightforward recapitalization of aging equipment? Are there previous studies that help this effort? How much rigor must this team put forth to prove that its analysis presents essential requirements and not just documented desirements?

Once the team determines the study’s preliminary needs, the analysis identifies the needed capabilities, the capability gaps, and the operational risks on a prioritized list. Most teams face the same questions: What do we need to do that we cannot do now? What do we need to do better? What are the problems and the risks?

sep-15-article-6-secondary-3In the final CBA step, the team considers alternative solutions. Any action assumes associated costs and often initiates risk. Perhaps it is smarter to do nothing at all. If too much risk emerges from doing nothing, the next consideration is a nonmateriel solution. Perhaps changing Doctrine, Organization, Training, Leadership, Personnel, Facilities or Policy can solve the capability gap problem. Perhaps DoD does not need to develop anything new, but rather take a nondevelopmental approach by ordering more of an existing weapon or system. The acronym DOTmLPF-P sums up this overall non-materiel approach—Doctrine, Organization, Training, materiel, Leadership (education), Personnel, Facilities or Policy (DOTmLPF-P). The m is not capitalized because it represents nondevelopmental hardware, which differentiates it from developing something new.

The final alternative is to develop a new system or a new technology. Developing something new almost always is expensive. Under typical tight budgets, assessment teams must wonder when to consider the cost of a particular solution. The DoD management systems wisely separate requirements generation from systems acquisition. Rather than have the CBA team worry about costs, the thinking today is that the requirements team members are not cost or development experts. The essential CBA task is to identify the problems and the alternative solutions. Let the acquisition experts develop the cost estimates so the decision makers have the most credible information. This approach also helps avoid the temptation to ignore a capability gap because the solution may be too expensive.

The CBA Is Just the Beginning

The product of a CBA can be either an Initial Capabilities Document (ICD) or a DOTmLPF-P Change Recommendation (DCR). The ICD supports developing a materiel solution; a materiel solution usually calls for additional nonmateriel changes such as new facilities and new training procedures. Hence, a new materiel development usually has a supporting ICD and a supporting DCR. If the CBA recommends a nonmateriel solution, a DCR will suffice.

Completing the CBA does not finish analysis or requirements development. Arguably, analysis never is finished because requirements managers must keep refining those requirements to respond to changes in threats, to apply lessons learned during system development, and to prevent requirements creep. The requirements listed in the ICD usually have a minimum value. Subsequent requirements documents, the Capabilities Development Document (CDD) and the Capabilities Production Document (CPD), propose refined capability requirements in the form of Key Performance Parameters (KPPs), Key System Attributes (KSAs) and Additional Performance Attributes (APAs).

The specifics of the KPPs, KSAs and APAs can get programs into trouble when operational considerations lead to derived requirements. For example, an aircraft may have a requirement to operate off an aircraft carrier. Carrier operations limit aircraft weight and size. The one requirement for carrier operations now leads to the two additional requirements to limit aircraft weight and limit aircraft size. A vivid example involves a missile that needs to fly at a very high Mach number. High speeds mean high temperatures. High temperatures mandate expensive materials such as titanium. The need to fly at a high Mach leads to a derived requirement that the development contractor must make the missile out of titanium or something even more exotic. (Unobtanium, anyone?)

The great risk in both examples is that the requirements managers and the program managers may overlook alternatives and compromises. Revised operational concepts could allow for different carrier-based aircraft or mission profiles that do not involve carrier operations. A slower, cheaper missile would allow less research and development, simpler test and evaluation, and more production. It is all too easy to make the illogical leap, “The user needs a high Mach number. That means the user requires titanium. Titanium is a requirement.” What matters here is the operational capability. In this example, the user asked for high speed; the user did not tell the developer how to achieve that high speed. The need for high speed may not be as important as other considerations such as accuracy, availability and reliability. Requirements managers, program offices and developers must be open to these kinds of tradeoffs.


A Good Requirement’s Characteristics

As systems development progresses, the requirements documents support the succeeding milestones and the requirements become more specific. Ideally, the requirements manager works with the program office to apply the lessons learned from the development phases. These lessons learned should combine with the results of the analysis so the
requirements describe the overriding military or operational utility. Good requirements avoid the common pitfalls of being too vague, subjective, expensive and restrictive.

Bad requirements can be vague, subjective, expensive and restrictive. Effective requirements have the following characteristics:

  • Measurable—The requirement must be quantifiable and verifiable through inspection, analysis, demonstration, simulation or testing.
  • Attainable—The requirement must be feasible and achievable with today’s technology, the available time, and the available money.
  • Necessary—The requirement must be necessary to accomplish the mission; there is no room for the frivolous or the “nice to have.”
  • Correct—The requirement must accurately describe the capability the program office and the developer need to deliver.
  • Unambiguous—The requirement is not open to interpretation; everyone—from the requirements shop, the program office, and the contractors—can agree on what to develop and deliver.
  • Orderly—Requirements are clearly prioritized so the program office can make trade-offs.
  • Organized—Requirements are grouped into categories to avoid duplication, inconsistencies and contradictions.
  • Results-Oriented—The requirements are based on operational capabilities; they describe what the system needs to do.

Clear, effective requirements allow the requirements managers to work with the systems engineers to develop specifications for the contractors. Then industry can develop, produce and support the equipment the warfighter needs.

Bring New Systems Together

At every level we must remember how each Service and each agency is part of a greater whole. Many capabilities come together to serve the warfighter and to defend the nation. As technology moves forward, new technologies often have the potential to do what once appeared impossible. Our ability to innovate and to apply technology is among our greatest strengths. The great challenge remains communicating what the warfighter needs to do and what the acquisition system—with its laboratories, engineers and contractors—can provide on cost, on schedule, with worthy performance.

sep-15-article-6-secondaryNone of these communications steps are easy. The abilities to innovate and to imagine often begin tortuous processes to turn ideas into capabilities. The teamwork of multiple disciplines must come together to develop results. The communications and development processes become rigorous and time-consuming because we expect so much from ourselves, from our partners, and from the warfighter. In turn, the warfighter—the man or woman who goes into harm’s way—has every imperative to expect much of us as requirements managers, program managers, and resource specialists.

We probably all have stories about how someone in our chain of command expressed a desirement and expected us to make it happen. We have all heard stories of how analysis gave an answer the boss did not want. Nevertheless, many steps must combine the contributions from many disciplines to complete sound analysis, document the need for new or for improved capabilities, get the necessary documentation validated, and get a new effort funded. A subjective desire for something new must evolve into a sound objective requirement as we develop new capabilities that continue to allow our forces to prevail.

Experienced leaders know that good communications takes time and effort. Good communications, solid analysis and insight into the potential pitfalls remain at the center of any effort to turn desirements into requirements.

The author can be contacted at charles.court@dau.mil.

To print a PDF copy of this article, click here.



Leave a Reply

Your email address will not be published. Required fields are marked *