CM: The Next Generation of SCM Standards

problem.  Feature Request implies feature.  Change Request (CR) is good except that it doesn't always imply that change is required.  So I like simply Request, although I don't mind CR as long as there is no confusion with the Change itself.  A Request lies in the customer domain.  A Problem or Activity lies in the product development domain, eliminating duplicate requests and change-free requests.

My Vote:  Request, Change Request

Requirement
This one seems fairly straightforward.  We don't have other terms for it, as long as we understand that a request may be an impetus for Requirement change as opposed to a requirement itself.  But alas, although the choice of term is fairly standard, the meaning tends not to be.  

There are basically two camps.  One says a Requirement is a requirement on a Product.   The other says a Requirement is a requirement on someone doing work.  In the later case, we start with product requirements, and then map them into the design phase and "allocate" new requirements for the design team.  This may be a single step allocation, or there may be multiple steps (e.g. from high level design to software detailed design).  

There's a big difference between a product Requirement and a design Requirement though.  A product Requirement is a "marketing" input - either as part of a contract, or as part of a market standard.  A product team doesn't control product requirements, though it does control everything derrived from them.  In fact it has to do project management on everything derrived and as such, it would be best to turn the derrived artifacts into project activities rather than having parallel activity and requirement artifacts for product management and project management. Note that there is a lot more data associated with planning and tracking activities than just the "requirement" description and a few attributes such as weight.

Still, it doesn't matter how hard we try, the requirement flow down (i.e. allocation) process is deeply rooted in many projects.  As such, it might be unreasonable to expect the terminology to ever change.  So instead, I recommend prefacing the term:

Customer Requirement:  a requirement expressed by the customer
[Product] Requirement:  a requirement for how the product will function, taking into account customer/market requirements.
Design Requirement: any lower level requirement allocated from a Product Requirement

In this scenario, I recommend that Requirement alone imply Product Requirement, that is, a requirement on how the product will function.  Note the difference between Customer and Product Requirement.  A customer may request the ability to automate backups once a week.  A product requirement might instead say that automated backups can be done according to a custom schedule [which might include weekly].  Both of these are "product" requirements (i.e. how the product must/will/should function, but the latter is applicable to a greater market.

Also, be careful of those who distinguish between allocated requirement levels based on the amount of detail.  Product Requirements and Design Requirements both need full detail.  It's just that one details how a Product functions, from a black box perspective, while the other details the implementation architecture used to build the product.  True enough, a Product might have sub-Products, each with its own set of Product requirements.  But this again is different from Design reqiurements.  For example, a Product might need a million pounds of thrust, and it might involve several engines, products in themselves, as sub-products.  But the design identifies whether four 1/4 million pound thrust engines are to be used, or five 200,000 pund thrust engines.

Now despite all of this discussion, there are still numerous labels on requirements: System