Many, many, too many times over the past 20 years or so I've been faced with clients who "knew" what they wanted (e.g. "silver fountain pen" or "that electronic strip display I saw at the trade show last month" ) but could not state their requirements in any way, manner, shape or form that would enable development of technical specifications. Trying to get operational folk to understand the logical flow from performance/outcome to functional requirements to operational requirements to technical requirements to technical specifications is nigh on impossible in 99 cases out of 100. Do you really care if the yellow wire is 2cm or 2.35cm long if the gizmo performs as you need it to ?
Let the people hoping to supply the gizmo show you in their proposal that it can match your performance/outcomes requirements (and comply with any necessary "standards"). Then test it to see if it meets those performance and outcomes based requirements. Does how it does that, as long as it complies with the standards, really matter operationally? After a very long slog we finally convinced the powers that be to replace "radar" with "ATS Surveillance system" and define that system in performance and outcomes terms. Look how we have been able to move ahead in performance and cost effectiveness.
I have actually been involved in an acceptance testing activity where the system met and in many cases exceeded all the technical requirements but as they were the only ones stated in the RFT had to be contractually accepted but could not be commissioned to operational use because it did not meet the operational requirement.
PM me if you want a copy of a half page performance and outcomes based description of ASMGCS, which has also been used to define the requirements for a prison surveillance system and the security system for an apartment block. .