I'm sure everyone has experienced something like this. You go into a meeting with a client who has a project. They have no/few requirements in mind and the vaguest understanding of what they want/need. At this point, there seem to be two options:

1) Tell the users, "Ok, so I can't build something for you if you cannot even describe it yet. Why don't we get back together in a few weeks when you know what you want".

2) Meet with the users a few times and help them figure out what they want by guiding them through with the good ole Socratic method. "Do you need to track X?", "How about Y?", "Do you need functionality Z?"

With the first option, you don't get stuck doing someone else's job, or having gain psychic powers, however, the users might never present you with a coherent specification, or they might take forever as the deadline continues to approach. With the second option, you waste a bunch of time becoming a business analyst, and have to cram a bunch of business knowledge into your head that you will probably never use again, but you will be much more likely to come out with a spec that makes any sense.

To me, this is one of the most challenging aspects of development, and I have a feeling I'm not alone in this sentiment. In your experience, which of these options tends to work better?

  • curious question: why do you think requirements analysis is someone else's job? Commented May 10, 2011 at 23:06
  • @Stephen - Well, because I actually get the requirements from internal business analysts who are supposed to be getting gathering the requirements from the actual users. You could be correct, that it really should be my responsibility, but their job seems awfully redundant if that is the case. Like testing, I understand that I have to do a certain amount of testing, but I am most productive when I let our testers do that work. Certain things cannot be tested by testers, and I know certain requirements cannot be gathered by BAs, but if that is their job I probably should not be doing it all.
    – user3792
    Commented May 10, 2011 at 23:59
  • 1
    thanks for the context, your question makes a lot more sense now. On the one hand it sounds like your internal business analysts are not doing their job, on the other hand if they are not developers I wouldn't trust their analysis to be complete or correct - but that's just me ;-) Commented May 11, 2011 at 20:59

8 Answers 8


I have to admit that sometimes I choose option 3)

3) Listen to the clients vague ideas, blanch at the idea of spending weeks helping them figure out exactly what they want... so figure out what it is they need, build that, and refactor as required.

This works, particularly for small jobs, because it helps avoid those situations where clients have this brilliant idea in their head, which is impractical in the real world.

It happens to me all the time; "surely we could do..." is a very frightening phrase. Especially as the things being mentioned are almost always the bells, whistles and "nice to have" class of features. They don't quite get that in the statement "well a bug tracker obviously, and then..." the bulk of the potential work rests in the first four words.

So, sometimes it is nice to take a clients vision, apply a decent dose of programmers-common-sense, and build something that fits their needs.

In terms of the original question; I find it depends a lot on the context. If stuck with the client (i.e. it is through a work contract I am tied to, or there is no alternative work) then #2 is the sanest approach. Otherwise there is a high likelihood that in a week you will be presented with a wonderful and detailed spec... which is completely useless to you as a programmer.

Much the same problem as mentioned above (#3) and one that leaves you having to do #2 anyway.

  • 1
    +1: Talking hypothetically about "Required", "Desired" and "Optional" is almost impossible for a lot of people. Talking about a concrete implementation is much, much easier.
    – S.Lott
    Commented May 9, 2011 at 17:10
  • I find putting non negotiable, realistic $ (or time) figures against "Required", "Desired" and "Optional" is a hugh help......
    – mattnz
    Commented May 9, 2011 at 21:24
  • @mattnz: It could work for some users to try to and be "realistic". It's even easier to negotiate over a concrete implementation. Users can ask for actual concrete features to be added, changed or removed. Less hypothetical. Less "realistic". More actual, tangible and concrete.
    – S.Lott
    Commented May 10, 2011 at 1:39

if you want to be just a programmer, then you wait until someone else has figured out what the client needs and then code that

if you want to be a developer, and this is your client, then you take your client's hand and gently walk them through the dense scary forest of possibilities until together you find the happy bunny-filled meadow at the intersection of Wants and Needs.

ADDENDUM: this process is called "systems analysis and design" aka Consulting, and it should never be done for free

  • 1
    +1 for the FREE bit :) never get suckered into doing that couple of hours website layout for a mate....
    – Errant
    Commented May 9, 2011 at 21:00
  • 1
    The "should never be done for free" is worth expanding to another question IMO. Commented May 16, 2011 at 12:36

Programming is preliminarily about solving users' problems. So to me, getting into "extra" effort and pain in order to get a working, satisfiable solution to our users almost always wins over avoiding the "extra" hassle, and not delivering anything useful in the end.

(Of course, there are real users out there who have really no clue what it is they want, and no effort can get them into a state where they can make any meaningful decision. But I believe that in most of the cases they do have a real problem, they are willing to spend effort and cash to get it solved, and they will be happy if we can help them closer to a working solution.)

So the bottom line is, our focus should be solving users' problems. This may sometimes require asking some targeted questions and giving them more time to figure out the answers. Sometimes it requires charting the domain together, in close cooperation. Sometimes it requires spending some time making simple sketches / prototypes / mockups, then showing them the result and asking "does this look like what you had in mind?" (then throwing the prototype away when they say "actually, I was thinking about something completely different ..." and starting over... :-)

The real skill is in choosing the right approach for the right time.

Last but not least, in my experience, good solutions almost always require at least some domain knowledge from the developer's part. Without this, you have no real common language with the user, thus there is no guarantee whatsoever that what you deliver will really be useful to them. Users typically don't have much clue about technology, so have no idea of what is and isn't possible, and what the cost of different approaches / features is. Since we can't reasonably expect them to learn technology to sufficient detail, we should take that extra step from our end of the bridge.

This might be seen as "extra" effort which doesn't pay back - however, I prefer to see it as investment, for two reasons:

  • it helps me deliver good solutions, which in the long run increases my market value as a developer, and
  • different domains are not completely distinct, so at least part of that domain knowledge will be probably reusable in future gigs.

As a software developer, part of your task is to gain a sufficient understanding of the domain the software is going to be used in. Thus, being part of the nascent phase of a project is extremely valuable (in terms of time and customer experience). Yes, this means doing a thorough domain and requirements analysis. It is the perfect time to incorporate the target users, interview them or walk around the location where your software will be used.

But, to gain this skill is almost an art form, especially when the domain is not connected to an engineering discipline. Your obvious questions may appear daunting to the customer, your in situ presence may not be wanted, your lack of understanding of the social structure of your target audience might crumble the still fragile connections.

Failing to understand the intricacies of this phase often leads to disappointment, both with the software developers, as with the customer. We'd like to get through this phase ever faster or do away with it completely. The results are often disastrous: after the hastened start, during development the stakes of succeeding are getting ever higher and it becomes ever more difficult to go back to the drawing board. When the system is finally finished and millions have been spend, neither the customer, nor the engineering firm is willing to admit its failure, leading to the forced introduction of a failed system.

An alternative is to let a business analyst do the job for you. This might be sensible for some products, and the analyst often is able to be an intermediary, but it will only create more communication channels (and thus a higher chance of error).

In any case: rewriting a piece of code never outweighs rewriting a piece of requirements.

p.s. maybe you think I'm advocating the waterfall method. I'm not a believer of 'big design up front', but I do believe the domain analysis effort should be in proportion to the implementation effort. One can make multiple cycles (prototype, release candidates, etc.).


Definitely option 2 unless your users are developers (even then option 2 might be needed).

A lot of most software development lifecycles focus on requirement gathering. Not only do most users not know what they want, they also don't know what is possible, so working with the user to understand what the user needs is a critical software development task.


I think you need to go with both options. Let them go off and decide what they want. Then, when there's a concrete idea to use as a starting point, guide them to help refine the requirements to something useful.

You don't want to jump into Option #2 when they can barely articulate what they want as it will make the whole process slower and more frustrating (unless they already have a very clear idea of what they want when they come to you, but in my experience this is very rare). Make them get their ideas together. Have them write something down on paper, make describe what they want in terms of existing systems if possible (ex. "we want a website like blahblah.com but with these differences... we want a tool that does Task A like Product X, but UI must also do Task B..."). Then it's a good time to start refining what they want into very specific requirements you can use to build the system.


In general, clients will come to you knowing exactly what it is that they think they need. Unfortunately, this is what they will tell you, instead of describing the problem(s) that lead to the solution they think you will provide.

To design something that will meet their needs, you must identify those needs, and to do that, someone will have to hold the client down and extract those needs. If no one else can do it, then you must. (If someone else thinks they can, you might have to sit down with them and extract the real needs later ...)

With option 2, over a number of meetings, you can hopefully train the client to share problems with you rather than solutions. (Even if the client has technical ability - for example, they have no availability to do this work and need you to do it instead - they may still be focusing on an implementation that is not ideal for the end client.) It doesn't matter much what development process you use, you'll still need to go back and forth a few times until they can answer questions in ways that will define specs for you.

Remember, you want to catch defects as early in the development cycle as possible. If you can catch them during requirements rather than during coding or testing, you'll save yourself a lot of time.


Option 1 is an excellent way to avoid doing some work. I've used it when I believed the work to be unnecessary or I had more important things to do.

First, users don't know what the computers can do. Most of us have spent years learning to understand computers and computation, and what's obvious to us might not be readily understandable for somebody who's spent those years learning other things.

Second, users don't necessarily know what they need, and usually don't know what they want, in any actionable sense.

To give an analogy, when I bought my current house, an interior designer selected wall colors for the rooms on the main (US first, UK ground) floor. I would never have chosen those colors myself. I wanted a house that looked good, and got it. If the designer had listened to me and given me anything I could articulate, it wouldn't have come out nearly as well.

The only way of giving users something that does what they need in a way they like is to work with them yourself.

Your Answer

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