Here is the opinion of the Requirements & Concepts Panel for the Army Materiel Acquisition Review Committee (AMARC) of 1974:
In the opinion of our team, historically the most successful developments or the most useful operational equipment have not resulted from the “requirements” process, while building and trying equipment in response to a good idea has a much higher batting average — particularly if normalized to resources expended. Significant examples can be cited where the establishment actively resisted the introduction of a materiel system (Jeep, Christie Tank, P-51 Fighter Aircraft, SIDEWINDER and the previously mentioned US Army rifles).
And here is a contrasting opinion from the Production Panel of that same AMARC report:
… the Army cannot lose sight of the fact that the requirements (qualitative and quantitative) of a new program determine the cost and complexity of the system. Therefore, they must be solid at the beginning of the acquisition and carefully monitored throughout … There is a need within the Army for realistic acquisition planning early in the life of an acquisition program. Such a plan should be a part of the ASARC-I [i.e., Milestone A, prototyping] presentation and reviewed and updated throughout the acquisition cycle.
Notice how the Production Panel did not stress that requirements should be locked down ahead of the production decision (Milestone C, or in their parlance at the service level ASARC III). Instead, they wanted fixed requirements ahead of the prototyping phase — even ahead of full scale development. By contrast, this was viewed as far too early from both the Requirements & Concepts Panel and the S&T Panel who are active in those phases.
Of course, the whole formal acquisition process revolves around defining requirements up front, and then working a plan to create the necessary technology to get there. This is reflected not just in the JCIDS requirements process, but in the linear 5000-series milestone process and the PPBE budget process.
Certainly we have seen efforts in recent years to streamline requirements, such as through a Joint Urgent Operations Needs Statement (JUONS). But in most cases technology cannot get developed past the Milestone A phase with the intent of searching for a requirement to fill later, as more information becomes available. There are good discussions, however, on the DevOps concept of having a more rapid feedback between requirements and technology, rather than going in a straight line from the former to the latter.
The War on the Rocks article by Jason Rathje speaks to this notion of having the ability to mature technology and find a problem to fix with it.
I think it’s important to be careful with two words that are being used in two different ways (each), leading to confusion. Those words are ‘prototype’ and ‘requirement’.
In the formal acquisition process, programs are started in response to a mission need and capability gap(s). One might informally think of that as a ‘requirement’ for a new system that can do certain things, but that is not the kind of ‘requirement’ that is meant in the sentence “requirements must be solid at the beginning of the acquisition”.
Similarly, ‘prototyping’ can refer to one of two very different activities. Building systems in order to see what can be done with a new technology — aka technology demonstration — is one kind. It does not typically produce operationally useful systems, precisely because few or no operational requirements are placed on the system being developed. However, we also use the word ‘prototyping’ to refer to competitive designs against a full set of requirements, performed as part of an acquisition program. This can be a valuable activity, as with the JLTV recently, but it is not inherently innovative and can only happen after you know the (KPP-type) requirements.