Just because the customer asks for something doesn’t make it a requirement. It makes it a discussion point. For questions to ask, see my other blog post when should I question a technical business requirement
I tend to see five categories of non business requirements. Many of these come from posts I’ve seen at JavaRanch rather than my actual users.
1. The customer is making assumptions about the technical implementation
Any requirement starts with an actual need. Sometimes this is what gets stated as a requirement. Other times, an implementation is given as the requirement without mention of what the original requirement is.
2. The requirements are technical and suggestions slip in
Some requirements, such as when you are interacting with other systems are technical. Making it harder to differentiate the actual requirement from implementation suggestions. With such a technical customer, it’s going to be harder for the customer to separate what is really a requirement in his/her head. Questions can often draw this out. And the technical customer may provide more useful insights during this process.
3. The customer is trying to pre-optimize
Some customers give you requirements based on what they think is easiest rather than what they really want. This happened to me recently. My customer asked for something that was acceptable rather than what he preferred because it sounded easier to implement. (In reality, it was an order of magnitude more work.) When we talked about it, we decided to go with the actual easier solution. Talking about it worked out very nicely.
4. The customer doesn’t really know what he/she wants
I think this is the hardest case. It’s more than asking questions until you find out what is in the customer’s head. It takes more discussion to help the user figure out what he/she wants. Often technical mockups/prototypes help. When you don’t know what you want, you may recognize it when you see it. Or at least recognize what you don’t like in what you see.
5. The customer isn’t aware of what is out there
Sometimes a customer gives interaction requirements based on the desired behavior. This makes sense. At times, this description is extremely similar to an existing widget. Either a built in one or one that’s already been implemented. Showing the existing widget often results in something the customer likes better. (or likes that he/she can get for little effort.) Of course, technical people don’t always know the name of the widget either as evidenced by my what is this widget called thread!
What other categories can you think of?