The warfighter-driven requirements process aims to accelerate American armament by starting from the field, not from the office.
In Summary
The warfighter-driven requirements process represents a profound reform in how the U.S. military defines its military needs. Its principle is simple: start with the operational problems encountered by combatants, then build solutions around these real needs. This logic stands in contrast to an old culture dominated by lengthy documents, slow validations, and programs sometimes launched before the military problem to be solved has been clarified. The issue became central following criticisms of JCIDS, the Joint Capabilities Integration and Development System, which was long used to validate joint requirements. In 2025, Washington launched its most significant reform in over twenty years. The objective is clear: reduce lead times, better link requirements to budgets, involve industry earlier, and deliver useful capabilities before the technology is already outdated. It is an administrative revolution with direct operational consequences.
The Concept That Starts from the Field Rather Than from Technology
The warfighter-driven requirements process can be understood as a capability definition process steered by the combatant. The term is technical, but the idea is very concrete. A military should not start by asking for an aircraft, a drone, a piece of software, or a missile. It must begin by formulating the operational problem it cannot resolve.
The difference is major. A conventional approach might say: we need a new radio system, a new armored vehicle, a new command software, or a new sensor. A warfighter-centric approach first asks: which mission is failing, under what conditions, against what adversary, and with what constraints of time, range, discretion, survivability, cost, and interoperability?
This shift seems obvious. It is not in a military bureaucracy. Armament programs have long been structured around documents, budget cycles, approval procedures, and compromises between staffs. The combatant—that is, the end-user—often arrived too late. They tested a system after years of development. They would then discover that the tool did not perfectly match the terrain, that the interface was too cumbersome, that maintenance was impossible in operation, or that the adversary had already changed their methods.
The warfighter-driven requirements process aims to correct this error. It stems from a simple idea: a military requirement is not a document. It is a tension between a mission to fulfill, an adversary to defeat, an environment to master, and an absent capability. The role of the process is not to produce a flawless dossier. It is to transform this tension into a usable solution.
The Legacy JCIDS System Grown Too Slow for Modern Warfare
To understand the value of this reform, one must look at the system it replaces. For over twenty years, the Pentagon used the Joint Capabilities Integration and Development System, or JCIDS, to identify, document, review, and validate joint military requirements. This system had a serious justification. It was meant to prevent each service from purchasing its own equipment without coherence with the others.
The problem is that JCIDS became too cumbersome. Official American reports describe a complex, rigid process that is poorly aligned with budgets and incapable of keeping pace with commercial innovation. The system had to coordinate the Army, the U.S. Navy, the U.S. Air Force, the Marine Corps, the Space Force, combatant commands, intelligence, acquisitions, and industrial players. In theory, this coordination protected joint coherence. In practice, it frequently slowed down delivery.
The numbers speak for themselves. The Government Accountability Office found that available data showed approximately 800 days to validate certain capability documents within JCIDS. Other research works mention around 852 days to prepare and validate a combination of documents such as the Initial Capabilities Document and the Capability Development Document. Even if these numbers vary depending on the program, they provide the order of magnitude: more than two years can be consumed before the requirement is even fully stabilized.
In a slow industrial war, this delay could be absorbed. In a technological competition against China, Russia, Iran, or non-state groups capable of rapidly adapting drones, jammers, software, and munitions, it becomes dangerous. A requirement validated too late may already be obsolete.
The Military Problem Placed Before the Industrial Solution
The core of the reform rests on Key Operational Problems, or KOPs. The term designates the priority operational problems that the Joint Force must solve. This choice is fundamental. The Pentagon no longer wants to merely validate technical requirements. It wants to classify the military problems that truly matter.
A simple example illustrates this point. It is not a matter of asking for a “more performant reconnaissance drone.” It is about formulating a problem such as: how to detect, track, and neutralize mobile launchers in a contested zone, despite jamming, decoys, surface-to-air defenses, and the dispersion of units? This formulation is more useful. It leaves several possible solutions open: satellites, drones, ground sensors, loitering munitions, artificial intelligence, electronic warfare, special forces, manned aviation, or a combination of multiple means.
This change avoids a frequent trap: locking the military into a solution too early. Industrialists often prefer to respond with a product. Staffs sometimes prefer to defend an existing program. The combatant, however, needs an effect. The warfighter-driven requirements process therefore seeks to define the expected military effect before freezing the technology.
It is also a way to engage in a better dialogue with industry. Instead of publishing a long list of specifications that excludes certain solutions in advance, the government can present a clear operational problem. Traditional defense contractors and non-traditional companies can then propose different responses. This logic favors software, artificial intelligence, commercial sensors, low-cost drones, and modular solutions.
The New Role of the JROC in the Hierarchy of Requirements
The Joint Requirements Oversight Council, or JROC, remains at the center of the system, but its role is changing. In the legacy model, it participated in the validation of numerous requirements documents. In the new logic, it must focus on what is truly joint and strategic.
The American memorandum of November 2025 provides for the progressive end of JCIDS and directs the JROC to stop, as much as possible, validating documents specific to individual services. The requirements of the U.S. Army, the U.S. Navy, or the U.S. Air Force must return to being the responsibility of those services. Instead, the JROC must become the forum responsible for identifying and ranking the Key Operational Problems of the joint force each year.
This point is important. The reform does not seek to abolish joint coherence. It wants to stop confusing coherence with bureaucratic control. The JROC retains subjects that go beyond a single service: interoperability, multi-domain warfare, command and control, distributed sensors, cyber, space, missile defense, contested logistics, or operations against a major adversary.
The risk is real. If each service regains too much freedom, the military branches could recreate silos. The U.S. Army might prioritize its ground requirements. The U.S. Navy might defend its ships. The U.S. Air Force might push its planes and drones. The new system will therefore have to arbitrate without returning to past encumbrances. This is the most difficult balance to strike.
The Decisive Link Between Requirements, Budgets, and Acquisition
The true weakness of many weapons systems does not stem solely from the definition of the requirement. It comes from the poor alignment among three worlds: military requirements, the budget, and acquisition. In the United States, these three worlds have long operated under different logics. Requirements are driven by the mission. The budget is driven by the calendar. Acquisition is driven by technical milestones.
The warfighter-driven requirements process aims to connect these three flows. This is why the reform establishes the Requirements and Resourcing Alignment Board, or RRAB. Its role is to link priority operational problems to budgetary resources. Clearly, it is no longer enough to say that a requirement is important. It is also necessary to verify whether it can be funded, developed, tested, delivered, and integrated.
This logic addresses a well-known problem: the “valley of death.” Many military technologies work in demonstrations but never transition to scale. They remain stuck between the prototype and the funded program. The new system aims to reduce this divide. It also provides for a Joint Acceleration Reserve to more rapidly fund solutions derived from priority requirements.
This part is decisive. A process centered on the combatant is useless if the budgets do not follow. An urgent requirement without funding remains a wish. A technology without a budget line remains a PowerPoint presentation. A serious reform must therefore link the field to the appropriations bill. This is exactly one of the stated objectives in Washington.
The Practical Method for Moving from Requirement to System
Concrete operations rely on a shorter chain. First, forces and combatant commands identify an operational problem. Next, this problem is formulated in a precise manner: mission, adversary, environment, timelines, expected effects, constraints, and risks. Then, decision-makers rank the problems according to their strategic importance.
Once the problem is prioritized, mission engineering teams come into play. The role of the Mission Engineering and Integration Activity is to translate a military problem into technical options. This step can include simulations, exercises, prototypes, experimentation, field trials, exchanges with industry, and cost analyses.
The key point is iteration. The requirement is not set in stone from day one. It is adjusted as users test, as engineers discover technical limits, as industry proposes solutions, and as the adversary evolves. This logic is close to the agile methods used in software development.
The Software Acquisition Pathway already provides an example. Software programs falling under this pathway must demonstrate the viability and operational effectiveness of a capability no later than one year after the obligation of funds. They must also deliver new capabilities at least annually, with more frequent updates where possible. Users must be engaged continuously. This is exactly the warfighter-driven spirit: deliver quickly, observe usage, correct, improve, and repeat.
Concrete Uses in Modern Armament Programs
This process is particularly useful for domains that evolve rapidly. This is the case for drones, command software, electronic warfare, artificial intelligence, cyber, counter-drone defense, distributed sensors, and loitering munitions. In these sectors, waiting ten years to deliver a solution is often absurd. The adversary will have already changed tactics.
The war war in Ukraine has reinforced this lesson. Modified civilian drones, jammers, sensor networks, targeting applications, and low-cost munitions evolve in very short cycles. A military system that is too slow arrives outdated. The combatant then becomes the best sensor of relevance. They know if the tool works in the mud, under jamming, with little training, few parts, and a real threat.
The warfighter-driven requirements process can also help major programs. A combat aircraft, a ship, a tank, or a space system remain long-term projects. But even within these programs, software subsystems, sensors, data links, and interfaces can evolve faster. The challenge is not to freeze the entire system for fifteen years.
This logic also changes the relationship with industrialists. Companies can no longer simply wait for a highly detailed set of specifications and then propose a response. They must understand the missions, accept rapid testing, work with users, and deliver successive versions. This advantages certain non-traditional players. It also forces major defense groups to become more agile.
Expected Benefits for the Armed Forces
The first benefit is speed. An armed force that better defines its problems can deliver useful solutions more quickly. Speed does not mean improvisation. It means fewer useless documents, fewer redundant validations, fewer delayed decisions, and more concrete testing.
The second benefit is relevance. A system designed with users is more likely to function in reality. It better accounts for ergonomics, maintenance, terrain constraints, training, logistics, and human fatigue. These details often make the difference between equipment admired at a trade show and equipment actually used.
The third benefit is budgetary discipline. By starting from the problem, the military can compare multiple responses. It can avoid buying an overly sophisticated system if a combination of less costly means produces the same effect. It can also abandon a solution that does not work much earlier.
The fourth benefit is innovation. Innovative companies understand a clear problem better than a closed set of specifications. If the government describes the desired effect, the market can offer unexpected answers. This is particularly useful for commercial technologies, where innovation often comes from companies unfamiliar with traditional defense circuits.
The Risks of a Process Focused Too Much on Urgency
One must also be frank. The warfighter-driven requirements process is not a magic solution. It can create its own flaws. The first risk is prioritizing immediate needs to the detriment of long-term strategy. A combatant sees very well what is missing today. They do not always see what will be necessary in fifteen years against a different adversary.
The second risk is fragmentation. If every unit expresses its needs, the ministry can find itself with a multitude of local requests. Some are justified. Others are too narrow. The role of the JROC and staffs therefore remains essential to prioritize, merge, and sort.
The third risk is a decline in rigor. Reducing lead times must not eliminate analysis. Certain programs require lengthy testing, certifications, cyber protections, and safety validations for nuclear, aerial, or space security. A missile, a manned aircraft, or a strategic command system cannot be treated like a mobile application.
The fourth risk concerns industry. A faster relationship with the field may favor the most visible companies, not necessarily the most robust. It can also push to multiply prototypes without transitioning to scale. The reform will only succeed if it truly connects experimentation, funding, production, and sustainment.
The Cultural Transformation Behind Administrative Reform
The subject goes beyond procedure. It touches on military culture. For years, acquisition has frequently rewarded compliance with the process. The new model wants to reward operational effect. This is a profound change. It asks decision-makers to accept more risk, more testing, faster failures, and fewer administrative certainties.
It also requires military personnel to better formulate their needs. Saying “we need a new drone” is not enough. It is necessary to describe the mission, the environment, the threat, communication constraints, acceptable cost, production rate, maintenance, and loss conditions. A good operational requirement is precise without being closed. It must leave room for solutions.
Finally, it requires industrialists to get closer to the field. Programs can no longer be designed solely in corporate headquarters, engineering offices, and Pentagon meeting rooms. They must be tested by those who will use them. This proximity can be uncomfortable. It exposes defects more quickly. But it prevents discovering too late that a very expensive system does not correspond to actual usage.
The warfighter-driven requirements process is therefore not just an American reform. It is a lesson for all modern militaries. Technology advances quickly. Industrial cycles remain long. Budgets are constrained. Adversaries observe and adapt. In this context, the best question is no longer: what system do we want to buy? It becomes: what military problem must we solve, and how quickly can we give the combatant a usable response?
Live a unique fighter jet experience