4 ms·
The waterfall method (which is what is being invoked when "comprehensive requirements spec" is stated) was, and is, always a fictional story told by people both
by gilbetron 5y ago
The waterfall method (which is what is being invoked when "comprehensive requirements spec" is stated) was, and is, always a fictional story told by people both during and after the project. The entire difficulty of a software project lies in figuring out what needs to be done. Well that and fighting with the tools and modules ;)
- Jtsummers 5y agoI’ve said it before, and I’ll probably say it again, it’s not a fiction. I’ve watched millions of dollars get wasted by that approach. It’s a great way to deliver nothing on time unless you know the domain well and your customer really knows what they want. But it is, sadly, quite real.
- gilbetron 5y agoOh it's real, I agree. What I meant by "fiction" is that the success of waterfall, and the specifics of how waterfall are implemented, is fictional. As in during the "delivery phase", it is found that requirements were missed and so people will retroactively act as if those requirements were actually in the "requirements phase" all along. I did a lot of government contract work and saw the insanity in action. Lots of retroactive changing of gantt charts, too :)
- Chris_Newton 5y agoTo be clear, having a comprehensive requirements spec has nothing to do with using a waterfall model, and I absolutely was not invoking that model when I used the term. The point is that at any given point in time, either you know what you are currently trying to build or you don’t, and you can only meaningfully define whether your software is working to the extent that you do.