Requirements Elicitation: How I Ask the Right Questions!


As a business analyst who is trying to get the right solution delivered, it's your jobs to figure out the right questions to ask so you can eventually come up with a solid set of requirements, but how do you know what questions to ask? As always, I like to be like to make my work a little more fun than it has to be, so one way make things a little more interesting is to inject yourself into a criminal investigation. 

1. Understand the crime

detectivePolice investigators typically already have a crime on there hands and the goal is to use the evidence and interrogations to figure out how the crime came to be. It so much easier to know what questions to ask when you already know the end result is (a stolen briefcase or a burned building) and you are just trying to put the pieces of the puzzle together. As a business analyst, the first thing you need to do is get a clear picture of what the end result should be, and by end result, I mean what the busines objective is. Then via evidence (existing documentation and systems), and interrogations (interviews), you put all the pieces together. It might help to start with a diagram, so you can more easily picture the scene.

2. Be Open to New Evidence

While its important that you start with a clear picture, always remember that new evidence might change the way a picture should look and you should be open to that. Don't dismiss incoming data because it doesn't mesh with your picture. (For example, what looked like a break in might actually be insurance fraud.) Always assume your picture of the truth has a potential to be wrong, and that you are conducting your investigation to not just fill it out, but correct it. 

3. Don't Leave Holes In Your Investigation

As you start trying to fill in the picture, you'll find yourself with holes. Sometimes, your suspects might even tell you, "Yes, that is an odd bit of missing information, but don't worry about it, its not important." Its your job to worry about it. Chase down all holes, and verify that indeed that information isn't important. Not doing so will either lead to embarassment or defects/rework. Don't label something as unimportant until you know enough about it to say with certaintly, that its unimportant.



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>