So it is with requirements and systems. While we might like requirements and systems to conform to a Parmenidean view of the world that "All is one" and "Change is impossible", my experience, and I suspect the experience of most of you out there, is that we need to adopt more of a Heracleitan view. To pop out of my reminiscing about my academic background and displaying my extraordinary erudition and to speak plain English, we need to be more iterative and agile in dealing with requirements.
When I talk about requirements, I make the following observations.
Let's say you start a project with 10 use cases (or their equivalent). Your first iteration (or two) of the project should develop one or two of those. You are, of course, trying to explore, establish and exercise the architecture and deliver highest immediate value. Almost invariably, when you finish the iterations, you will find that the priority ranking of the remaining use cases has changed--you may have learned something that changes the prioritization, your stakeholders may have changed their minds (never happens!), or the business situation has changed in such a way as to make some of the remaining use cases irrelevant and has introduced new needs. In other words, the river has moved on. Everything flows. Without a good strategy for dealing quickly with change, both in your projects and in the external environment, that is, without some way of being agile in today's complex world, you will be up that river without a paddle.
My colleague Eric Naiberg wrote a blog entry on this topic last October: http://su.pr/5SWJwK. In November, we held a Virtual Roundtable on Agile Systems Engineering: http://su.pr/1OROS0 which also touched on the topic in several posts. In the meantime--Go with the flow!