Ever taken a “20 questions” approach to requirements elicitation? According to The Bitter Project Manager, there are good reasons for doing so. Querying the user/customer in 20 questions fashion helps to determine s/he wants by eliminating the things s/he doesn’t.

[It] divides the population of potential answers then continues to refine/divide until there is a small population remaining.

When you go out for lunch or dinner, what is easier to highlight … what type of food you want or don’t want? For most people, it’s usually easier to identify what you don’t want. That dramatically reduces the population of potential answers.

I can’t vouch for whether it is easier for people to identify what they want or what they don’t, and I haven’t really tried a true 20 questions approach to elicitation myself, but I wanted to make mention of it because it provided a just-different-enough take to make me stop and think it through. I was intrigued by the notion of getting to a solution by dividing and refining a greater set of potential solutions until you reach the right one. And experience tells me that there is truth in the notion that in software engineering, users may not be always be able to articulate exactly what they need, but they certainly have no problem telling you what they don’t want when they see it!

In any case, the point of the post wasn’t that we make a cute, gimmicky game of elicitation, but that “[d]uring requirements gathering, [we should] try to understand what the customer doesn’t want.” And I am on board with that notion. In fact, I think a good way to get the benefit of the “20 Questions” (refine/divide) effect – or at least reach the same desired result – is by going through iterations of requirements elicitation, analysis and then validation that includes a form of prototyping (even if it begins with super low-fi mock-ups) of what we understand the customer to want. Through early and continuous feedback on what the user/customer likes and doesn’t like, our understanding of the desired solution begins to merge with the customer’s vision.

This process helps us reach the point where the customer and the delivery organization are both thinking of the same solution in a way that is not so different from the refine/divide method.

Anyway, thanks again to The Bitter Project Manager for making me use my noggin’.