Requirements and Design

I have recently found myself on an engagement where the is no clear line between requirements and design. Both activities tend to bleed together which creates a level of requirements complexity and they quickly become unmanageable.

I have read many books on requirements (including my personal favorite which authored by a good friend of mine Daryl Kulak, Use Cases: Requirements in Context) and have been producing them for the better part of a decade now. In most of my reading, authors typically stand firm on the idea that design is a separate activity and should be isolated from the requirements creation process. I have found that most effective practitioners will also agree with this approach.

And, while I tend to agree with this as well, is this a stance that can be taken in all organizations? More importantly, is this approach feasible when working with a COTS package?

So, while requirements generation and documentation is without a doubt an art (vs. a science), how much "creativity" can be embedded in requirements without bleeding into design?