The driver for requirements typically falls into one of two categories: a specific contract/customer or a general marketing strategy. One of these things is going to drive your requirements. If you have a $1B NASA contract, you'll be focused on that, largely to the exclusion of any other product requirements. If you're trying to capture market share, you be focused on both innovative and me-too features. If you've got a new high-priced product, you're likely going to focus on one or two contracts to get credibility before addressing the issue of market share.
Customer Requirements versus Product Requirements
So we have customer requirements and product requirements. Sometimes we build something specifically for a customer and the two are the same. This is called the customer requirements document (CRD) and it becomes becomes the PRD. The PRD is an important document for the development team, as it describes what it being built. If there is one or more CRD, traceability from the PRD back to the CRD is essential. The customer must still be able to verify that all the requirements in the CRD have been met.
Before going any further, there are a couple of other things to keep in mind. First, some PRDs describe the first "release" of the product, with subsequent release PRDs to follow. In other cases, the PRD describes the product and the product team may address it across a series of development streams, each culminating in a significant release.
Second, the PRD is not the sole source of input to product definition. Change requests (CRs) tend to filter in as well. CRs are typically customer centric. The customer request usually arises from having used the product (or a prototype of it).
2D Version Control of Requirements
Your requirements management tool should provide adequate facilities to manage your customer requirements Tree. Each element of the tree should be under both version control and change control. The tree itself may be baselined and frozen often. It should support 2-dimensional version control, with release streams forming one dimension, and within each stream, revisions. So the requirements tree can evolve within each release stream and can also evolve across release streams. This allows us to compare baselines across streams for identifying new release requirements, as well as within a stream, for identifying changes to the requirements and "requirements creep" within a release cycle.