There is a common myth in the development of software starting with the developers paradigm.
This approach is missing a critical role not found in many IT or business softwware domains, that is found in most other software intensive domains - The Systems Engineer. This role defines the Needed Capabilities of the resulting system in units of Measures of Effectiveness. These MoE's speak to the customer satisfaction with the results of the project
To develop the Needed Capabilities there some simple steps to start to establish the bounds of what is needed for project success.
The next level down of identifying the needed capabilities takes place using these activities.
Now we can arrive at a set of Needed Capabilities to be produced by the project. The requirements that fulfill these capabilities can be emergent or they can be predefined.
Predefined requirements are common in large enterprise system, embedded systems, or mission critical systems. The emergency shutdown system shall stop the turbine driving the compressor in 1.3 seconds or less to prevent overspeed of the RB-211 is a mandatory requirement on a compression station process control system.
Emergent requirements are of a different class - the emerge as we develop the system. But having the final working code may or may not impact our ability to verify the requirements. Simple platitudes and pithy phrases don't usually add much to the Probability of Success for the project or the product.
So when we hear words like those stated in the #NoEstimates paradigm, in the absence of a domain or a context in that domain - take care. It may be just anecdotal, or worse just an opinion. The requirement to shut down with RB-211 does not need working software to verify it is the correct requirement. It needs working software to verify the requirements has been met. This is the role of the Measure of Performance, the Technical Performance Measure, and the Key Performance Parameters.
There are likely other capabilities and fulfilling requirements that do need to be on station and working before we can verify they are the correct ones. But care is needed here as well. By working do we mean working in the final environment? If so, the Guidance, Navigation, and Control software for Mars Reconnaissance Orbiter can oly be verify at Mars - not a very good way to confirm you've got the right requirements - a bit late in the development cycle.
So we're back to the core problem in discussing any process, technique, method - in what domain and in what context in that domain is this suggested approach applicable? And critically important - if it is suggested that it works in one domain and context (outside of personal anecdotal experience) - how can we assure it will work in in another with sufficient confidence to actually spend other peoples money trying it out?
