Yeah this sort of hypothetical paper prototyping is really useful because you can map out the whole territory you're operating in, instead of just finding a single point to work towards. I think the approach actually applies beyond just UI mockups - if you can mock out whole workflows in the business with the right stakeholders/personas represented, you can also start to build up a loose dataflow model right there, and also understand some of the likely articulation points of the resulting systems, just by having conversations like "what if we needed this human process to happen first" or "what if we eventually built a model to automate this process" etc.
I specifically did say you won't catch all future requirements this way. But you want a mechanism to catch the reasonable and likely ones.
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.
This is no problem for the initial version but businesses and the environment they operate in change, you are in general not going to figure out what you will need ten years down the road. And then it really depends, maybe everything is fine, but maybe you also made choices early on that allowed you to save time and the price of limited flexibility and this eventually bites you.
I'm not sure what you're responding to. I'm suggesting you specifically model how things might change to give you a better chance of identifying the right articulation points for your architecture - as in, what if I have to drop one side of this because our assumptions were wrong, but I don't want to lose _everything_? You can't predict the future, but you can built at least _some_ flex into your business and platforms.
What you say is correct. But there is literally no way to figure out what will be needed 10 years down the road using any kind of methodology. If you are clever you try to use stable things, technology that is likely to be an ok choice years down the line and maintain an architecture that is easy to maintain and modify.
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.
I think there is a tradeoff, you can pick some customizable off the shelf software or some low code platform that fits your initial needs, that will give you speed at the risk of not being flexible enough later. Or you fire up your IDE and start from scratch, do everything on your own, that will make you slow, at the very least in the beginning, but you get all the flexibility and also all the opportunities to screw it up.
