Ruminating on Requirements Elicitation

Last night, I was ruminating on the lessons learned during my experience in business architecture, business analysis and requirements elicitation. I think at the broad level, there are 2 kinds of requirements.

The first kind is - Where we know, what we don't know: These requirements are easy to capture since we have an idea about the pain areas of the customer, we know what is the vision of the project, what is being planned to be done, etc. Hence we can ask appropriate questions, dig deeper and after a few iterations of interviews can get a pretty good understanding of the requirements.

The second kind of requirements are - Where we don't know, what we don't know !
Digging out these requirements is the most challenging task - because we never ask the right questions about things that don't know, our past memory/experiences make implicit assumptions on certain things. Such kind of requirements result in last minute suprises and everyone wonders why these points were never discussed or brought out !!!

How do we elicit these requirements? I think the following techniques during requirements elicitaiton would help:
1. Question each and every assumption - both implicit and explicit. Assumptions may not hold true in every scenario. Check if the assumption is valid for the current scenario.
2. Ask 'stupid' questions - Yes, this works !!!...I have seen that often, analyst's refrain from asking questions because they are self-conscious, are afraid of being ridiculed for lack of knowledge in a domain area, etc. i.e. they are afraid of sounding 'stupid'. But clarifying even the simplest doubt could open up a plethora of new requirements.

iRise visualization software

Recently on request of one of our clients, we were asked to evaluate iRise V (isualization products.
A quick perusal of what the product offered made me smile. There are so many projects that fail because the end-product is not what the business required. Sometimes the business itself is not sure of what it wants or how the end product should look like.
It's estimated that 60% of projects fail because of misunderstanding of requirements.

Using iRise visualization products, business analysis can quickly build UI elements that have the same look-and-feel and navigation as the final end product.
More information at http://www.irise.com

P.S: Just got a mail from Tom Humbarger (iRise Project Manager) that an evaluation copy of iRise Studio PE is now available for free 30-day download from Download.com. Would highly recommend it for a try.