What questions should I ask during an initial requirements gathering meeting?

Question

The boss is out sick for a week, and so it has fallen to myself and a coworker to get the initial requirements and start planning for a new project. Neither of us has any experience in gathering requirements (I'm an intern), so we are scrambling to get our act together and come up with the right questions to ask to elicit the requirements correctly.

We do have a good idea of what the project is intended to do, thankfully, as the purpose of the project is simply to move from an Access app to VB.Net/SQL.

What questions should we be asking to get the right answers so that we can begin the planning phase? We've been going through Code Complete 2 and Software Requirements 2 from Microsoft Press, and have gotted a vague idea of a few general questions, but does SO have any input?

Answer 1

• Are you going to be doing a straight Access-to-SQL port, or are you going to have to normalize parts of the database along the way?
• Are there any portions of the app that are buggy and will need to be cleaned up?
• How soon are the clients/co-workers expecting to have a working VB.Net/SQL app?

Answer 2

Off the top of my head:

1. Who will the users be? What groups can they be divided in? How strict do you want to enforce access to various parts of the application? 1a. Any other stakeholders you feel I should be aware of?

2. Could you tell me what you want to store? Could you show me the forms (or in this case, the existing application), and how you use it?

3. How many <X> will the application be handling? How much <Y>? What kind of growth rate do you expect?

4. When do you need the application to be available, realistically? ('opening hours')

5. What browser version will the users be using? (pray that IE7 or higher is mentioned!)

6. In case of an emergency, what timewindow do we have to get things back up?

7. From where will you need access to the application? (internal or external)

8. What is the goal of this rebuild project? (ie: What is the reason they want to move from Acess to .Net)

9. What is the goal of the application? (ie: Make sure you understand what it is the application does)

10. Find out which limitations there are to the environment in which you'll deploy the application (which windows version, which .net version, etc - this helps prevent surprises)

Please note that I've only been asked to deliver input for such sessions, haven't been part of them yet (apart from a school-context).

Answer 3

Whatever questions you decide to ask, I always remind myself that when dealing with a new client, or a new project... my mantra becomes "Hear what the client means, not what they say."

It seems impossible, but think about things from their perspective: if they knew exactly what they needed or wanted, then ANYONE could do the work. Even someone in-house.

If they are going outside their company, then they probably need some help in solidifying what they they really need.

Clients usually know what they DON'T want, but only after they see it. To find out what they DO want, you need to do a little detective work. Ask similar questions (when appropriate) and see what patterns emerge in their answers. Re-stating a client's answers back to them can also sometimes help them feel like you understand what they are trying to say.

I really try to ask questions and narrow my focus until we are all talking about the same things, functions, user-personas, budgets, etc....

Answer 4

The important thing in gathering requirements are the five Ws http://en.wikipedia.org/wiki/Five_Ws: Who, What, When, Where, Why, How.

It sounds like you are migrating an existing application from access to VB.NET. For me, the most important question here is:

Why?

Why are they moving from access to VB.NET? What is driving this change? Is it new functionality? Customers don't spend money for nothing. If the current app was doing everything they wanted, they wouldn't change.

The place to start is the business process, what do they actually want to achieve with the new application. Customers sometimes say 'We want it to do exactly what the old one does', but this is never true.

If there are two people at the meeting with the customer, then one of you should run the meeting and the other one should take notes. Record all of the 'decisions' made in the meeting and review them at the end of the meeting to make sure that you've recorded them correctly and that stuff as been fully understood.

Don't commit to anything with the customer. If the customer wants a commitment, say you need to clear stuff with your boss before commiting to anything.