[Click these links for the first and second posts in this series.]

There's no way around discussing features. Every release, you're going to add some piece of functionality. You can come up with academic-sounding names, or cute nicknames, but at the end of the day, you're talking about a feature.

However are features the right place to start? If you had to invest your time in documenting what customers want, is it better to describe a use case or a feature? Or, to use other language, should you be writing a story, or a vignette that fits into the larger story?

Increasingly, technology companies are putting more emphasis on stories, a.k.a. use cases. (Yes, I know, many people prefer to keep stories distinct from use cases different. However, for sake of this post, I'm going to blur these differences.) That's a very good thing, but not without its costs.

Looking at the choice between (a) a use case, and (b) a list of features, there's almost no contest between them. Use cases have several immediate advantages:

• Clear definition of how technology provides value. In other words, use cases make it easier to figure out why someone would want to use a piece of technology in the first place. Or, perhaps more importantly, why not. For example, entering "activity" into a CRM system seems on the surface like a good thing to do--except when it gets in the way of the daily work of a salesperson.
• Easier decisions about the relative priority of new capabilities. It's easier to answer the question, "What would help our target user more successfully complete this task?" than, "What's more important, a hyperspace shunt or an ion flux regulator?"
• More meaningful success parameters. Every feature has a few ways you can implement it well, and a thousand ways in which you can implement it badly. You can give someone powerful business intelligence capabilities, but it's not useful to them if they need a Ph.D. in mathematics to use them. Use cases make it easier to figure out what constitutes a successful implementation.
• Clues to successful adoption. Every technology vendor has an interest in getting people to use their products, even if they don't always pay close attention to adoption. If you think through a use case, you can determine what will get someone excited enough to use your technology. These shiny baubles--coolness factor, sizzle on the steak, call it what you will--are often more important than a profound increase in capability.
• Fewer steps to product marketing. Product marketing, the fine art of explaining "What will this technology do for you?" becomes way, way easier when the development team has done this work for you already.
• Inspiration for innovation. Often, when pondering what people unlike yourself (developer, product manager, QA person, product marketer, etc.) will do with a piece of technology can get the innovation juices flowing. Even thought experiments about use cases can unlock new ideas. Einstein didn't start his career as a scientist by saying, "I'm going to overthrow Newtonian physics!" Instead, relativity began with the question, "What would happen if I tried to race a beam of light?"

The big downside to use cases is the time and effort needed to research them. You can think of a feature without ever leaving your desk. Usually, to understand a use case, you're going to have to do some field research. You can be smart about cutting down the amount of research needed, or filling in details as you go. However, the amount of information needed will always be more than if you just sat at a white board and came up with a list of "things our product does not do today that it might do tomorrow."

However, for all the reasons cited above, use cases are more helpful than features, and they're a better starting point for planning, too. Therefore, requirements documents should document use cases, and then propose features that will contribute to them.