I have gotten to the point where I hate requirements gathering. Customer's are too vague for their own good. In an agile environment, where we can show the client a piece of work to completion it's not too bad as we can make small regular corrections/updates to functionality.

In a "waterfall" type in environment (requirements first, nearly complete product next) things can get ugly. This kind of environment has led me to constantly question requirements. E.G. Customer wants "automatically convert input to the number 1" (referring to a Qty in an order). But what they don't think about is that "input" could be a simple type-o. An "x" in a textbox could be a "woops" not I want 1 of those "toothpaste" products. But, there's so much in the air with requirements that I could stand and correct for hours on end smashing out what they want. This just isn't healthy.

Working for a corporation, I could try to adjust the culture to fit the agile model that would help us (no small job, above my pay grade). Or, sweep ugly details under the rug and hope for the best. Maybe my customer is trying to get too close to the code?

How does one handle the problem of "thinking for the client" without pissing them off with too many questions?

  • 1
    Why do so many people make disparaging comments about waterfall that demonstrate they either haven't worked in waterfall type environments or have but obviously don't know how to do it? Waterfall is not a you must do it this exact and only way specification. Smart developers would know they have to tailor for their specific needs. If the requirements are not clear and showing some working functionality to the user would be helpful (ie. your agile approach), then there's these things called prototypes. Agile wouldn't make life easier, Agile only makes starting easier, it makes the end harder.
    – Dunk
    Commented Mar 16, 2011 at 17:10
  • @Dunk - sorry if I offended waterfall fans. I am not a project manager. I qualified the paradigm with "" and my definition which may or may not be the way everybody understands and uses waterfall. I only mean to clarify my point with generally understood paradigms, not trash talk them. Commented Mar 16, 2011 at 18:56
  • 1
    I am not necessarily just a waterfall fan, but waterfall gets bashed all the time and so few people stand up for it, so I must do my part. The fact is that there are many types of projects that are best served using waterfall approaches. Safety critical systems, space programs, anything when hardware needs to be designed in parallel with software, any project where only a subset of functionality is useless to the customer are just a few examples. My point is that most companies that successfully use waterfall actually use waterfall-like approaches and the strict definition is just a guide.
    – Dunk
    Commented Mar 29, 2011 at 20:13

8 Answers 8


In most cases the customer is not aware of what else can be done. They've never had to describe what they need in a way that makes it unambiguous for us. In their minds, it is clear. Even the fact that they are thinking about converting user input to the number 1 is really going beyond the way they are used to thinking.

That's really as it should be. If they really new how to describe exactly what they wanted, they wouldn't need us to write it for them. As a result, our responsibility is to help them through the process. The process does require decisions to be made, so they also need our recommendations to make the decision process easier.

So let the customer be vague and talk at a high level. They know their business, and that's what they are good at (hopefully, or they won't be able to pay your bills...). Take what they talked about and think on it for a while. Eventually you get some great ideas to get them what they want and need, while ensuring that what you need is testable and consistent.

I highly recommend working in chunks. When you meet with the client have a set of requirements that are related to each other, and then explain how you intend to do what they want. Also explain why you made the choices you did. The customer can then look at what you provided and fine tune it. If you get a response like, "I never thought of that, but that would really help" you know you've got a pulse on how the client thinks. NOTE: that this isn't featuritis, it's selecting the right features to best fit the business problem that the client has.

If you have anything that looks like it might contradict what the client explicitly told you, then it's time to explain why. You'll need to bring out some issues the client never thought of, and how your alternative still gives them what they want/need but also avoids those potential issues. You may get a little pushback, but it also builds up customer trust as they realize you are trying to give them a product that they can really use. If they give some pushback, it forces them to expound on why they wanted something a certain way. That helps you understand your client more, and tailor the requirements as necessary.

The fastest way to wear out your client is to ask all the little questions one after another. You want to plan and schedule a series of meetings to review your approach. As long as you own the technical requirements (what your team uses to build the product) and your client owns the business requirements, and you can relate them together, you have a way to bridge the gap.

  • 4
    Also you need to spend some time understanding the business you're working in. Many of the programming questions will fall into place if you understand how the business works.
    – Michael K
    Commented Mar 16, 2011 at 14:39
  • Best overall answer, but @whatsisname article posting is a wonderful compliment to the answer (disagree with need to find another client though. I need to improve my view of the client). Commented Mar 16, 2011 at 15:06

If you are 'pissing them off' from too many questions, get a better client.

The customers don't know what they want. They won't necessarily recognize their solution when they see it. That is a problem, and that is the job you are solving: translating their requirements into something that can be delivered as a software package.

To do that you have to learn about what you are doing. You shouldn't be asking "what should happen when they put a number in a text box", you should be asking "why is this number important? What is it used for?" Have them teach you how they do their job. And don't listen to what they say, because they don't know what they want, but watch what they do and where their eyes go.

Read this for more info: http://www.joelonsoftware.com/articles/fog0000000356.html


Assuming you're an employee at some sort of corporation, it sounds like you're in need of a good business analyst to help mediate those details between the client and yourself. I'm going to guess you don't have enough influence to make that happen, so my next best advice would be to learn more about the domain your clients are working in. By understanding the business and the processes they work with, you'll have a better idea of what they really want done, in spite of the loose and possibly wrong way they are describing it. That lets you analyze what they've asked for, and you can come back later in a separate meeting with an interpretation of what they want, and a possible suggestion for giving them what they really want. If you consistently work with the same clients, you'll get a better and better understanding of the domain and this should become easier, and you'll eventually train the client to present things consistently to you.

If that seems very difficult, painful, extremely unpleasant, or unrealistic, my final advice would be to start looking for a new job somewhere they have business analysts, because it isn't going to get easier for you without putting in some effort.


If you are requirements gathering then it's your job to ask these questions.

Yes the client could get annoyed, but in that case you need to explain why you are asking "all these questions". You need to understand their business before you can write the code that will automate that business. The clincher would be that if you didn't they would spend a lot of money developing a system that doesn't actually do what they want.

The side effect of this is that you should end up helping the client refine their requirements.

This applies whether you are doing Big Design Up Front or Agile.


Sadly, it's your job to think for the client if he can't or won't do it himself.

I've had both possible results:

  • the customer is happy that you're actually thinking about what he tells you, he feels that he is in the right hands, or

  • the customer is annoyed because you force him to think again about his requirements. But then, this type of customer will get annoyed with you anyway, sooner or later. He will certainly be very annoyed if he finds out too late that you didn't think for him in the beginning. I'd say: avoid this type of customer if possible :-)


A Rapid Application Development (RAD) addresses this problem well.

Start out "thinking for the client" by making a very rough non-functional UI for the program based on your best guess at what they need. Then show it to them and work iteratively until you meet their actual needs.

It isn't that they don't know what they want. It is that they don't know what they want until they see it, and sometimes you can determine what they want by exclusion. That is, showing them something they DON'T want and paying attention to how they criticize it.

The main problem with BFUD (Big Up Front design) is that it insulates the developer from blame by forcing the customer into a contract that explicitly describes what they are going to get. And unfortunately this is done at the time when no one on the project has a good idea of what is really needed. In the end, this just makes the customer accept what you built because they signed off, but grudgingly.

If the customer isn't happy with the deliverable it is only a Pyrrhic victory.


The customer's job it to relay to you what they need. Your job is to understand what they need well enough to be able to program what they need. An obvious question to the issue of changing all input to one would be to say "Why do you want it to change all input to 1?" Then the customer can explain the reasoning behind it so that you'll understand the need and then be able to provide not necessarily what they ask for but what they need. If you're confident you know what they need then I don't think you necessarily need to "correct" their line of thinking. They'll use the product and thing "Oh! that's perfect". But unless you are confident you know what they need you'll need to then explain what you're thinking and work it out with the customer. Unfortunately there's no way to perform this part of the process with out a lot of communication which involves real listening on both parts. Be careful of getting annoyed with the situation and saying things you may or may not really want to say.


Honestly: Unless it's 'big functionality' then have the person with the most domain knowledge make their best guess as to what should happen, and implement that. It'll get fleshed out in acceptance testing - which is what that is for.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.