This might not catch all the surprise requirements, but it might catch the worst ones.
A sure way to get surprised is to do the opposite:
- don't talk to the people who use your software, but some middle-men
- just take the customers first idea as gospel and assume they disected the problem space themselves
- keep everything constrained and never let anybody get wild or crazy with ideas
- don't anticipate potential future requirements and don't let them influence your decisions ever
Of course those things don't come for free, but it is important to realize that the initial phase of a project is crucial also for the impression your shop will leave behind. If people feel they have been heared and had a chance to come to a shared understanding with you, they are less likely to view your software in an unfairly harsh light later on. They will remember this and will hire you for the next thing.
But if your software managed to survive a decade of good use without any major issues I'd already count that as a job well done.
And for the unreasonable ones you can always say: "The system we originally intended wasn't meant to do this technically. If you want to have this feature we can help you but it will cost $X and this is a entirely new project."
If a graphic designer designs a logo and the customer in the end has the idea that they want that logo as a stamp or in a black and white version ANY graphic designer worth their salt will have anticipated this. If they want a 3D animated video of the whole thing rotating that is a different thing.
In one of the projects I worked on there suddenly came the requirement that they need metrics on how long people were working on different screens, completely unrelated to the actual business. No big deal in general, just put some code in some base class to collect the current time on enter and on leave. But the application framework we used just does not allow this, you can not modify the base classes used for screen, you have to add code for the enter and leave event on each screen individually. It just never occurred to the people that made the framework that you might want to do the same thing on all your screens and nobody expected that we might ever need this either, until we did.
Next step is, of course, to extend the XML validation to make sure it conforms to your application's expectations. And suddenly you have invented a compiler as well.
I most certainly hope so. But I've been involved in extending a system as I described as recently as a few years back. Everything was supposed to be configurable (by no-code customers) and XML was the language of choice, so the XML was... complicated.
Since then the developers took over and killed waterfall and 4GL in the process.
There was one product really popular then, but forgot the name. Sorry.
A product I personally know is Oracle Designer. This could generate fairly complicate applications (like master-detail-detail layouts) based on the ERD.
Another product I also forgot it's name, was considered very good, but used only within the IBM ecosystem. Fun fact, I was the product owner for a project where the IBM team vastly outperformed the web team (think half the size, twice the speed).