I’ve always been a big fan of specifying the bare minimum that touches on all system components, but doesn’t go into detail of some interactions ahead of the first release. Far too often I see companies, adopting the waterfall model so well, seeing senior and mid level management spent days, weeks (and believe me – months) just to watch whole Babble tower collapsing under its own weight on day first release reaches business eyes. Release after release are deemed as not fit into production, just because weak management focuses on entirely technical side of implementation.
Worse still, there are still oases of proud in technical superiority of IT departments able to deliver products aligned perfectly to specifications, even though not fit for purpose. Even if that lets you turn the blame game around, it doesn’t get you any closer to winning and surely, not closer to bringing any tangible business benefits. This attitude simply leaves huge opportunity for improvement.
More mature software management requires taking into account many more factors of development cycle, with psychology of the industry in particular. Senior, mid management, as well as senior developers ought to accept how hard it is to successfully sell conceptual models to the business and how much harder for business stakeholders to get a grasp of something that is less tangible than glass palaces. It takes understanding that fine level functionality can be captured by paper, even embellished by screenshots and impressive diagrams, but really every single interaction gets captured that way so rarely that I’d personally would attribute any success of such specifications to luck, rather than anything else.
As long as you’d be leave yourself in a position of being cut by paper, and the aforementioned psychology of interactions it carries with it, you will systemically fail to deliver. You might even get lucky once or twice, but sooner or later laws of great numbers will catch up. Therefore, what you need instead (apart of the whole new layer of management and developers) is to acknowledge and understand your own limitations as well as limitations of non-engineers and completely change the development and release process, so that you release frequently and early (opposite to what you’d expect in waterfall model) giving end-users opportunity to draw specs in short iterations based on the de-facto spec which is the current spot (call it beta release, if you prefer) in your development cycle.
Early release documents business processes and works as a model much, much better than any other spec would do. With modern programming tools and languages releasing early and frequently got far easier and cheaper than before. Different virtualization technologies come with further opportunities to create control environment for your early releases. Most importantly, release early, release frequently, creates a whole new model for presenting the interactions, interfaces and use cases for the business that is easier to understand and capturing many more subtleties of software in general. It also allows engineers and business to discuss the details of their requirements at the required level of granularity by having much fewer balls to juggle at a time, precisely the ones that are required in between cycles of improving the model.
This also takes whole culture change, whereas software development is no longer equal to software delivery. Development becomes mostly a technique of capturing requirements, part of a process which not necessarily ends with shrink-wrapped product being delivered to a market. It becomes part of research and analysis leading to a very decision whether to develop particular software, patch or improvement in the first place. It takes strong management to reconcile the cost of software development with purely research and exploratory part of company’s activity.