Well, that is for one simply completely impractical, those people are few compared to the amount of software the world needs and also very expensive. But it's only one of many reasons why there are better approaches so let's move on.
> Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value.
Many detailed requirements have, as matter of fact, been very visual, with detailed user interface mockups, process diagrams etc. When they are large in scope, they have been found not to be useful compared to the effort required to create them. When they are small in scope, they are actually used in real world agile software projects.
And, I have to ask something about this process where extremely experienced people create detailed visual blueprints for the entire scope of the project and then deviate very little from it. Is it something you've actually seen produce good results (repeatedly) for your run-of-the-mill software projects?
> If you are in a project where there are large numbers of unknowns about the functionality of the project
... that would be vast majority of them.
> I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality.
Well, every time you give concrete proposal about what to do in the face of uncertainty it sounds exactly like agile.
> scope reduction should be used until the unknowns have been reduced to a reasonable risk level.
That would, again, be agile. And I say that as someone who is not even particularly fond of of most standardized agile processes, such as scrum.