In this post Glen Alleman retorts the commonly lauded platitude that:
“There is no way to prove that the requirements we have are complete and correct until we have working code.”
And as Glen is a very smart guy, from the perspective of the domains within which Glen most frequently works and thinks, his perspective that this is wrong, is essentially on target.
In those domains, requirements are imposed by the overall design of the program (not the software) with tremendous specificity:
The emergency shutdown system shall stop the turbine driving the compressor in 1.3 seconds or less to prevent overspeed of the RB-211
But in the domain of service business operations (investment management), a requirement for the program might look much less specific:
The investment platform shall allow portfolio managers to rebalance open architecture portfolios without requiring any non-trade transaction instructions implemented outside the investment platform. This operation shall take no more than 2 minutes from initiation to completion for portfolios with up to 500 positions.
These requirements sound similarly specific. The thing is they are not. What is missing in the service business case is how many steps in the process require human interaction. When the human interaction is taken into account, human variance and experience is important.Continue Reading