You definitely do not want the "one-feature-at-time" combined with some twisted form of YAGNI to lead to what often happens:
"Oh, so we need to allow the customer to store 3 addresses, so I'll
just add three columns to the customer table."
"Shouldn't we try to maintain a relational model with a seperate
address table and a surrogate key in case at some point a customer
needs 4 addresses."
"YAGNI, they are really gonna need to put in another feature request
for us to allow for 4 customers. You're overengineering for a use case
that doesn't exist"
A certain amount of "looking ahead" is always required. If this was not the case, then no one would bother with patterns and best practices. Without a high level functional spec, how are you supposed to prioritize which feature comes next. I am not huge on UML, unless its a rough 1st iteration sketch on my legal pad, but the design phase always must include some sort of functional description of how things should behave. This might be contraversial, but I really do not even think it matters all that much what you even do with the spec once it is written down (update it as you go, put it in a folder no one goes to, delete it, etc.). The main benefit of the design process, and coming up with a loose spec, is that it forces you to write all of your ideas down, and see if they make any sense.