I look forward to reading the book as soon as I can get a copy.
In my military life I was involved in "requirements" and for the past three decades I've had similar roles in the civil aviation and airports spheres. The continuing lesson senior management fail to understand is the need to start with a CONOPS and then derive functional requirements leading to an operational requirements list AND THEN TO STOP DEFINING and let the technical folk decide the colour of wires and impedances and so on. The second greatest mistake made, in my experience, is people without extensive AND CURRENT domain knowledge sitting down with glossy brochures gathered on a trip to a trade show in an exotic location and cherry picking "features". [Go back a sentence and reread the "continuing lesson".]
I've written several papers on the subject and delivered a number of presentations where I produce my fountain pen and say, "If you give me a requirement for a blue fountain pen because you've seen me use this one I have little choice but to offer you products that cost a hundred dollars or more and may leak blue ink in your white business shirt pocket; however, if you ask me to provide "an instrument which can be held in the hand and makes marks on paper, cardboard, matt painted walls" I can offer you a range of items including pencils, ball point pens and fountain pens, several of which may meet you operational and financial needs much better."
Many years ago I took a 55 page ASMGCS requirement and reduced it to 211 words (33 lines) as a generic surveillance functional requirement. Several folk have used this over the ensuing years as the basis for a functional requirement, including a prison governor!
On two occasions I've had to tell my client after an extensive period of "acceptance" testing that they had to accept the "system" contractually because it met (and in one case, exceeded) the very detailed "requirements" in the contract even though it was not able to be put into operation without extensive modification. The value of putting operational and functional requirements in performance based SORs and leaving the technical details to the OEM/tenderer is that the failure of delivered systems to meet the stated requirements is the problem for the OEM/tenderer and not the result of poorly or ill defined technical requirements. Before you jump down my throat about ICAO/EASA etc. requirements: these form part of the requirements to be met by the OEM/tenderer - " demonstrate conformance with relevant ICAO/EASA requirements".
Classic Example: A seven page RFQ for an airport lighting system for a remote island which required the tenderer to show in their tender the proposed layout, provide a safety case and a compliance matrix. This delivered a fully operationally and regulatory compliant system which is still functioning 8 years later and has in that time required less than 2K costs in maintenance. BTW that system was nearly USD1M less in cost than one delivered to a nearly 300 page World Bank requirement which, to my knowledge, has never been commissioned and if/when commissioned will have annual maintenance costs 200 times greater. [One is individually solar powered lights and wifi controlled and the other conventional wire in the ground.]
If you are continuing the series, drop me a note and I'll supply plenty of examples of good and bad (mainly bad, unfortunately) aviation projects both military and civil from around the world.
Gne
Last edited by Gne; 1st Jan 2024 at 00:24.
Reason: usual raft of typos