Chapter 12. Defining Requirements
Once you have analyzed your data and represented your findings as models, you have finished the necessary description of the world as it is today. The next step is to begin thinking about the future: what the product or service must do in order to succeed. In the language of product development, these needs are expressed as requirements. Using this term tells all project participants that you're talking about product definition and not just hardware styling or the arrangement of widgets on the screen. Unfortunately, this little word carries a great deal of baggage with it.
The Problems with Requirements
Most requirements processes are fraught with problems. Marketers or product managers spend prodigious amounts of time developing requirements and are disappointed when a stellar product does not result. This is partly due to how requirements are generated, how they're communicated, and a problematic view of their role in the process.
Requirements cannot be "gathered"
Ask the average engineer how the marketing team develops requirements, and he'll probably say (only half facetiously) that the product managers lock themselves in a room with a bunch of competitive products and a lot of beer. Believe it or not, I have seen companies where this was the case, though most take requirements far more seriously. Even in the most structured process, many requirements ...