I've been wondering (again) whether or not we should seek a new name for the term "Feature" in FDD.
As we know a Feature is a post-modeling (post-analysis) artifact which describes a piece of client-valued functionality using Peter Coad's template - "action" "result" "object" and often with "parameters" added to the end of the term.
The trouble with the name "Feature" is that Marketing, probably correctly, thinks that they own it. Marketing Requirements Documents (MRDs) often contain the product features required for a piece of software. Product Features are not FDD Features!
Recently, I was forced to introduce, for a brief time, the term DWU (Development Work Unit). Our new VP of Marketing had declared "Marketing owns the feature list and Engineering has nothing to do with it". We were being asked to give up FDD and we couldn't do that, so we renamed Feature to DWU - even though everyone hated that term.
After 4 weeks or so, Marketing was no longer threatened and we were allowed to go back to using the term Feature though on all executive communications they are labelled "Coad Features" and explained as "object-oriented Function Points".
I therefore feel the need to discuss whether or not it is time to rename Feature to something else. What are the consequencies of this? I am certainly not advocating that we rename FDD - I love that name. FDD communicates delivery of client-valued functionality and that's great!
Do we stick with "Feature"? refine the definition with say "Coad Feature" or "FDD Feature"? or rename with something else?
Ideally, I would like something which doesn't need explaining, i.e. sounds too technical for someone to ask or cannot be misconstrued for something else. What about "Object-Oriented Function Point" [OOFP] or "Client-valued Function" [CVF]?
Approach to Changes
I've wondered this myself from time to time but not for the reasons you've mentioned.
Because Feature is such a generic and overloaded term, occasionally, people confuse the FDD Feature (which is the component of the output of process #2 Build a Features List) with descriptions of functions (be they wants or requirements or whatever) prior to the execution of process #1 Develop an Overall Model.
With the FDD processes though, I've taken a stand inspired by Gosling's stand on Java during it's development. That is, he would not incorporate any changes unless they were absolutely compelling.
So, even though I've asked myself this question of renaming the FDD feature, I've never found it absolutely compelling and thus have not changed the processes.
Now, there are several other points you make in your comment. I never disconnect the client from the features list (which I interpret - perhaps incorrectly - as Marketing vs Engineering in your example). The whole point of the features is that they are client-valued and that the client owns the feature list. I want this. It's fundamental. On any (especially fixed price) project, I want the client to sign off on the features list as an expression of the scope.
Jeff