1) I've got X dollars and Y months - what capabilities can I get?
2) I need to be able to do X - what's it going to cost me and how long will I have to wait?
In both cases, we have constraints. In the first situation, the constraint is resources. In the second, it's the need. I'm going to suggest that in reality, scenario #2 is much rarer than scenario #1. However, we all too often act like #2 is the only way to do business.
Here's the thing - we often don't really know what we need. We generally have some idea, but our understanding of the ultimate objective is going to change over time. The longer the time, the more it'll change.
That's not bad!
We should expect some change, plan for it, and seek it out. Attempting to lock down our requirements on Day 1 (when we know the least about the project) is pretty stupid... unless delivery is scheduled for Day 2. And it's entirely possible to end up with something that is simultaneously different than what we thought we needed and better than what we originally aimed for.
Let me put it bluntly: on a long project (i.e. anything over 6 months), requirements creep is good. It shouldn't be a surprise, and we shouldn't resist it. We should count on it and perhaps even insist on it.
Two additional comments: It's important for the user to be informed, educated and involved. The ultimate customer (warfighter, user, etc) needs to be continually involved in the development effort, communicating truths about the operational environment and learning about the possibilities and limitations of technology. It's also important to foster a trusting relationship between all involved. I refuse to do business with people I can't trust.
