Re: "it's important to get the big picture of what the system might grow into"
Beware, it could also lead to an over-engineering trap - if you don't have really clear "what the system might grow into", and how long it will take to get there.
But beware also the under-engineering trap. I had a client who had a slew of small applications, each hacked out to solve almost the same problem. Every time a customer gave them a slightly different job they wrote a new application to do it. Could a single application replace them all and tackle all the other jobs in the same category? Yes it could.
And they still didn't learn. The next, far more complex requirement came along. The contract required two types of job, both basically take in the data (in XML) rearrange it to drive the production process, batch it up, inspect the result and recycle items that failed QA into the next batch. Result: they insisted on writing two systems, one for each job.
The next, more complex contract after that I got far more of a hand in specifying as well as developing. Most of the code to be inherited from the previous one got thrown out (in retrospect I should have thrown more out) and the replacement made more versatile so, with minor extensions, it coped with more and more additions to that contract and a subsequent one. After all, when you looked at the general problem it was just a set of rules engines to provide different bits of the functionality - and being XML, XMLT is a pretty handy rules engine. Just throw in some new rules (mostly style sheets).