I was reading a paper yesterday, and it was a pretty generic "why software development is like X" paper. One sentence, though, stood out:
"Requirements -- probably the most misused word in our industry -- rarely describe anything that is truly required."
That guy is dead on, at least in this one point. "Requirements" is a word we tend to use in a rather slapdash manner. In the strict sense of the world, a requirement is something we are compelled by law or regulation to do. That thing where the SEC says that all stock sales by insiders must be submitted within X days? That's a requirement. That thing where marketing says it absolutely must be blue? Yeah, not actually a requirement.
Other than semantically, it really doesn't matter. There are only three buckets:
Legal requirements (aka "true" requirements) better fall in the "must have" bucket, and they better stay there. Other requirements might fall into the first bucket, but they might move. Things in the "will take" bucket also move around. Later in a release cycle, things tend to move down a bucket - from must have to will take, and from will take to "don't want" (which at this point gets nicknamed "please don't destabilize things").
It's easy sometimes to get caught up in subtleties and semantics, but in the end, keep in mind that everything in the product falls into one of only three buckets. So cut through the details and find your bucket.