What methods seem to work best to coax requirements out of non-tech business people? I am working with a team that’s trying to get a spec together for a project. Every time we have met and it comes down to expectations for the next meeting, we ask for the business people to bring back their requirements. They usually respond something like this: “Well, do you think you guys could whip up a prototype so we can see what we like next week…you know, not with any data or anything since it’s a prototype, just the functionality.” This is a 6 month plus project so that is obviously infeasible (we would have to develop the entire thing!), and we don’t even know what to prototype without some sort of spec. Frankly, I think like most people, they have some idea of what they want, they just are not thinking about it in the focused sort of way necessary to gather true requirements. As an alternative to simply telling them, “give us what you want or we can’t/won’t do any work” (we do want them to be happy with the results), are there ways to help them decide what they want? For example, we could tell them:

“Draw out some screens (in Powerpoint, on a napkin, whatever) that show the UI you would like with all of the data you want to see and a description of the functionality in the margins. From this, we will polish it up and build the backend based on this set of behavior requirements.”


“Don’t worry about how it will look right now (the number 1 hang up). Just give us a list of all the data you want about each thing the program keeps track of. So for “Customer” you might list: name, address, phone number, orders, etc. It does not have to be a perfect database structure, but we can work something out from this and get an idea of what you are looking for”

Do either of these alternative approaches to get business people focused on what they want make sense? Are there alternatives that you have seen in action?

  • 20
    I always used to daydream about hiring requirements analysts from organized crime. "Are youse gonna tell me who should have access to the accounting data, or is I gonna hafta get rough?" Apr 13, 2011 at 19:18
  • 8
    "Truth will sooner come out of error than from confusion." (Sir Francis Bacon, as quoted by Fred Brooks) Tell/show them what you think they want in specific terms, even if you're way off base. They will correct you. Iterate a few times until you come to an understanding.
    – anon
    Apr 13, 2011 at 20:18

11 Answers 11


I have spent the last 3 months in an exhaustive - and exhausting - requirements-gathering phase of a major project and have learned, above all else, that there is no one-size-fits-all solution. There is no process, no secret, that will work in every case. Requirements analysis is a genuine skill, and just when you think you've finally figured it all out, you get exposed to a totally different group of people and have to throw everything you know out the window.

Several lessons that I've learned:

  • Different stakeholders think at different levels of abstraction.

    It is easy to say "talk at a business level, not technical", but it's not necessarily that easy to do. The system you're designing is an elephant and your stakeholders are the blind men examining it. Some people are so deeply immersed in process and routine that they don't even realize that there is a business. Others may work at the level of abstraction you want but be prone to making exaggerated or even false claims, or engage in wishful thinking.

    Unfortunately, you simply have to get to know all of the individuals as individuals and understand how they think, learn how to interpret the things they say, and even decide what to ignore.

  • Divide and Conquer

    If you don't want something done, send it to a committee.

    Don't meet with committees. Keep those meetings as small as possible. YMMV, but in my experience, the ideal size is 3-4 people (including yourself) for open sessions and 2-3 people for closed sessions (i.e. when you need a specific question answered).

    I try to meet with people who have similar functions in the business. There's really very little to gain and very much to lose from tossing the marketing folks in the room with the bean counters. Seek out the people who are experts on one subject and get them to talk about that subject.

  • A meeting without preparation is a meeting without purpose.

    A couple of other answers/comments have made reference to the straw-man technique, which is an excellent one for those troublesome folks that you just can't seem to get any answers out of. But don't rely on straw-men too much, or else people will start to feel like you're railroading them. You have to gently nudge people in the right direction and let them come up with the specifics themselves, so that they feel like they own them (and in a sense, they do own them).

    What you do need to have is some kind of mental model of how you think the business works, and how the system should work. You need to become a domain expert, even if you aren't an expert on the specific company in question. Do as much research as you can on your business, their competitors, existing systems on the market, and anything else that might even be remotely related.

    Once at that point, I've found it most effective to work with high-level constructs, such as Use Cases, which tend to be agreeable to everybody, but it's still critical to ask specific questions. If you start off with "How do you bill your customers?", you're in for a very long meeting. Ask questions that imply a process instead of belting out the process at the get-go: What are the line items? How are they calculated? How often do they change? How many different kinds of sales or contracts are there? Where do they get printed? You get the idea.

    If you miss a step, somebody will usually tell you. If nobody complains, then give yourself a pat on the back, because you've just implicitly confirmed the process.

  • Defer off-topic discussions.

    As a requirements analyst you're also playing the role of facilitator, and unless you really enjoy spending all your time in meetings, you need to find a way to keep things on track. Ironically, this issue becomes most pernicious when you finally do get people talking. If you're not careful, it can derail the train that you spent so much time laying the tracks for.

    However - and I learned this the hard way a long time ago - you can't just tell people that an issue is irrelevant. It's obviously relevant to them, otherwise they wouldn't be talking about it. Your job is to get people saying "yes" as much as possible and putting up a barrier like that just knocks you into "no" territory.

    This is a delicate balance that many people are able to maintain with "action items" - basically a generic queue of discussions that you've promised to come back to sometime, normally tagged with the names of those stakeholders who thought it was really important. This isn't just for diplomacy's sake - it's also a valuable tool for helping you remember what went on during the meetings, and who to talk to if you need clarification later on.

    Different analysts handle this in different ways; some like the very public whiteboard or flip-chart log, others silently tap it into their laptops and gently segue into other topics. Whatever you feel comfortable with.

  • You need an agenda

    This is probably true for almost any kind of meeting but it's doubly true for requirements meetings. As the discussions drag on, people's minds start to wander off and they start wondering when you're going to get to the things they really care about. Having an agenda provides some structure and also helps you to determine, as mentioned above, when you need to defer a discussion that's getting off-topic.

    Don't walk in there without a clear idea of exactly what it is that you want to cover and when. Without that, you have no way to evaluate your own progress, and the users will hate you for always running long (assuming they don't already hate you for other reasons).

  • Mock It

    If you use PowerPoint or Visio as a mock-up tool, you're going to suffer from the issue of it looking too polished. It's almost an uncanny valley of user interfaces; people will feel comfortable with napkin drawings (or computer-generated drawings that look like napkin drawings, using a tool like Balsamiq or Sketchflow), because they know it's not the real thing - same reason people are able to watch cartoon characters. But the more it starts to look like a real UI, the more people will want to pick and paw at it, and the more time they'll spend arguing about details that are ultimately insignificant.

    So definitely do mock ups to test your understanding of the requirements (after the initial analysis stages) - they're a great way to get very quick and detailed feedback - but keep them lo-fi and don't rush into mocking until you're pretty sure that you're seeing eye-to-eye with your users.

    Keep in mind that a mock up is not a deliverable, it is a tool to aid in understanding. Just as you would not expect to be held captive to your mock when doing the UI design, you can't assume that the design is OK simply because they gave your mock-up the thumbs-up. I've seen mocks used as a crutch, or worse, an excuse to bypass the requirements entirely; make sure you're not doing that. Go back and turn that mock into a real set of requirements.

  • Be patient.

    This is hard for a lot of programmers to believe, but for most non-trivial projects, you can't just sit down one time and hammer out a complete functional spec. I'm not just talking about patience during a single meeting; requirements analysis is iterative in the same way that code is. Group A says something and then Group B says something that totally contradicts what you heard from Group A. Then Group A explains the inconsistency and it turns out to be something that Group C forgot to mention. Repeat 500 times and you have something roughly resembling truth.

    Unless you're developing some tiny CRUD app (in which case why bother with requirements at all?) then don't expect to get everything you need in one meeting, or two, or five. You're going to be listening a lot, and talking a lot, and repeating yourself a lot. Which isn't a terrible thing, mind you; it's a chance to build some rapport with the people who are inevitably going to be signing off on your deliverable.

  • Don't be afraid to change your technique or improvise.

    Different aspects of a project may actually call for different analysis techniques. In some cases classical UML (Use Case / Activity diagram) works great. In other cases, you might start out with business KSIs, or brainstorm with a mind map, or dive straight into mockups despite my earlier warning.

    The bottom line is that you need to understand the domain yourself, and do your homework before you waste anyone else's time. If you know that a particular department or component only has one use case, but it's an insanely complicated one, then skip the use case analysis and start talking about workflows or data flows. If you wouldn't use the same tool for every part of an app implementation, then why would you use the same tool for every part of the requirements?

  • Keep your ear to the ground.

    Of all the hints and tips I've read for requirements analysis, this is probably the one that's most frequently overlooked. I honestly think I've learned more eavesdropping on and occasionally crashing water-cooler conversations than I have from scheduled meetings.

    If you're accustomed to working in isolation, try to get a spot around where the action is so that you can hear the chatter. If you can't, then just make frequent rounds, to the kitchen or the bathroom or wherever. You'll find out all kinds of interesting things about how the business really operates from listening to what people brag or complain about during their coffee and smoke breaks.

  • Finally, read between the lines.

    One of my biggest mistakes in the past was being so focused on the end result that I didn't take the time to actually hear what people were saying. Sometimes - a lot of the time - it might sound like people are blathering on about nothing or harping about some procedure that sounds utterly pointless to you, but if you really concentrate on what they're saying, you'll realize that there really is a requirement buried in there - or several.

    As corny and insipid as it sounds, the Five Whys is a really useful technique here. Whenever you have that knee-jerk "that's stupid" reaction (not that you would ever say it out loud), stop yourself, and turn it into a question: Why? Why does this information get retyped four times, then printed, photocopied, scanned, printed again, pinned to a particle board, shot with a digital camera and finally e-mailed to the sales manager? There is a reason, and they may not know what it is, but it's your job to find out. Good luck with that. ;)

  • 4
    +1 for being one of the most exsaustive answers I've seen on Programmers SE!
    – user3792
    Apr 14, 2011 at 13:26

If you can't get something out of them, write something up and get it approved. It is a lot easier for non-technical people say 'no, I don't like that' than 'this is how you should do it.'

Often times what they want and what they tell you are two very different things. Take some time to write up a first draft of the spec with the info you currently know. Ask it the stakeholders to read it and approve it. When they read it, they will more than likely see things they don't like or agree with. Get their feedback and then revise.

If there is something that you could go one way or another on, online both options and get the decision maker to make a choice. Don't leave them alone until they do.

As for prototypes, make screen mock-ups, and explain how things would work instead. Again, seeing something helps them visualize what is going on. Take new screen mock-ups with you to meetings and get answers.

In the past, I've actually opened FireBug and added in the changed that the customer had requested right in front of them so they could see what it would look like. They gave their feedback, I took a screen shot then implemented the changes. They really liked being able to see what the change would look like, and I liked it b/c it was fast and I got my answer in that meeting...not the next one.

  • 2
    +1. The strawman technique is frequently the only way to get end users to think about what they do - their job is so automatic to them that it's actually hard for them to think about it.
    – DaveE
    Apr 13, 2011 at 20:44
  • I honestly think that anyone(including programmers) can give requirements easier as a "no, I don't like that. I want this changed" rather than "I want this". I think it helps focus on the immediate task at hand rather than trying to think of the entire project at once
    – Earlz
    Apr 13, 2011 at 23:38
  • +1 for getting them to say "No I don't like that" instead of "I want this". If a company doesn't know exactly what they want, this is the approach I try and take.
    – Rachel
    Apr 14, 2011 at 13:23

Get them to talk more about their business and less about applications. Find out what the real problems are: month end reporting takes too long, data entry errors, they've outgrown their current application, company growth is getting out of hand.

I'm guessing these meetings are with the people doing the purchasing but not the people who will actually do the work involving the application. Ask if you can meet with a select few of these people. They can show you how things are really done. Make sure you are dealing with clients who have budgeted their time as well as the cost.

See if they have any reports they are currently using or want to use. Obviously you can't create the report if you don't collect the data properly. They have to be doing something unless this is some line of business they haven't started yet.

Many have these general notions that you're the programmer, so you know how to build all programs. eCommerce sites are all the same, right?

Start small. Unfortunately, until you get something in front of them, the process just doesn't register. If you have nothing to go by, then just fake it.

  • Jeff is right. Get them talking about the actual business problem they need to fix. Then come up with something that can be done quick and cheap. If you deliver on that, you'll never be hungry. Apr 13, 2011 at 22:58
  • +1 for "Get them to talk more about their business and less about applications." That is one golden rule.
    – DPD
    Apr 14, 2011 at 4:12

A lot of this has to do with generic interpersonal skills and how you communicate with the client in the first place. There isn't much I can say about that, beyond - make sure that you explain the process as an interactive one, where you expect feedback and effort on the clients' part, too.

Specifically for the scenario you described, here's some more advice: Start by describing what you would find useful to have, and provide vehicles for describing the information in terms which do not require technical specialization or knowhow:

  • User stories/use cases Ask for detailed descriptions of what the users are expecting to do, what information they need in order to do it, and what you should and can expect the users to input themselves. Once you have this information, walk through it with them and make sure that everything is covered with stories - there shouldn't be anything that's going to go into the application, where you don't have stories covering what the user will do there.

  • Compelling demonstrations What is more important in order to win customers? Which portions of the program or functionality need to stand out, and have to be completely polished? Can you provide me with a mockup demo, using post it notes or cardboard boxes or other stand-ins, which you'd like to have working?

  • Market/competitive information For each user story, what are we doing which is similar to our competitors? Different? What story do our competitors tell, and are we trying to copy/emulate/improve/innovate/be purposefully different?

  • Open questions What, of the requirements and design, is information which you are certain of, and what is an experiment? Where are we going to try alternatives to see which one works? If you're looking at multiple alternatives, and you've only told us one, what are the others you're considering?

Then, draw out some boundaries:

  • Please don't place technical restrictions on me. A business person shouldn't be telling you "use windows because it's better than linux". They can, however, provide instructions along the lines of "all of our target market uses windows, our application will have to run on windows to succeed"

  • Don't worry about the design Especially if you're dealing with sales or marketing oriented people, they will tend to get bogged down with design issues. Again, narrow down the scope of information to what they specialize in - "blue is more beautiful here" is probably not appropriate. "Our competitor is using a blue color theme, and has been around since the 80s, for portions of our program where we are not innovating, we should use a blue scheme to communicate that we're not new", probably is appropriate. "The name should be at the top of the screen" is probably not appropriate, but "the most important information on this page is the user's name and bank account balance", probably is. Make sure a designer is involved in translating these requirements into a UI.

  • Write decisions down Preferably build these into contracts or other commitments you make. Remember, though, that a decision wich the customer doesn't understand, isn't worth the paper its written on. A customer signing off on "the application will run on port 1521" isn't worth as much as the customer signing off on "the application will run on a custom, configurable, port, which may require special configuration for firewall and security when deployed"

From your point of view, in order to encourage the process to continue:

  • Provide feedback at the same level of abstraction This is across the board, for example, for units - if the customer is talking monthly volume of users, don't respond in gigabits of bandwidth. Or, for use cases - describe functionality in terms of the working use cases, rather than modules or bug fixes or features.

  • Provide meaningful communication Phrase the questions you have, and additional information you've discovered or are looking for, in terms of the information that was provided to you. "We're going with linux" is probably poorly written feedback, while "our tests show that the application runs smoother when hosted on linux machines and accessed with IE on windows" might be more appropriate.

  • Iterate quickly To keep the client engaged, provide quick, meaningful updates and iterations. Specifications and information which wasn't available or easy to obtain when the process started may take a lot of effort from your customer, who is, probably, paying you, while you're not paying them for any of their work. Getting the client to be engaged and invested in the process can help when the work ends up being something they have to spend time and effort on.


Your clients, the business people, may have some sort of problem, desire some sort of technical solution, but have little idea of how the solution might work, and thus have little idea of how to spec any potential solution. If so, the role missing is that of a business solutions analysts, who can study the customer, their problems, their workflows, etc., and how any possible solutions might fit their corporate procedures, culture, etc., as well as whether any particular solution might be feasible to implement in time, under budget, etc. This may be a highly interdisciplinary role, requiring some knowledge of both business practices (law, accounting, logistics, etc.), user psychology, as well as software technology.

It sounds like you want to force the customer to be their own business solutions analyst. This may not be a role they have enough expertise in to ensure a reasonable spec. And it sounds like you don't want to take this role either. If neither you, nor your customer has the expertise to fill this role, you may not have all the people needed for a successful project.

Sometimes a bunch of rapid prototypes that the customer can play with might be the only way to experimentally discover and converge on some sort of usable solution for the customer's (voiced and unvoiced) needs. This may or may not be suitable for any kind of non-open-ended contract.

ADDED: If you try to force a requirements document out of customers who don't have the requisite expertise, this could potentially be a huge red flag indicating an oncoming disaster.


Don't ask for UI or Data requirements, ask for Functionality requirements.

Ask them about what they want the application to do. Have them walk through how they would like to use the application. Leave details such as UI, Data, etc out of it for the beginning.

I've been finding that often users don't know what they want in terms of UI or Data, but they do know what they want as far as functionality. For example, they'll tell me "I want to login and see all the Customer Info." Don't get into what the screens will look like, or what data they want, just get the functionality from them.

Once you have that, do a quick mockup (I like Balsamiq). Just assume what the UI/Data will be, and don't spend a lot of time on it. Then take that mockup back to the Customer. From there, they can tell you "we don't need these fields" or "We actually want a list of phone #s, not just one", or "this should be a dropdown, not a listbox".

Once you have the starting point it's much easier to flesh out Data and UI, and I find determining the Functionality is the best starting point.


I suggest you try to focus them on business process first and foremost. Get them to define, either in a document, or a discussion, how they currently do whatever tasks would be handled by your software. Then focus on what parts of the process they would like to see changed (the reason they want your software). Use that as a starting point for discussion of which other parts of the process might be improved, or even removed altogether, by using your software.

If your client isn't used to providing software requirements, your team should draft the requirements for them. Expect to go through multiple revisions, but you should at least provide them with an initial document to help communicate what it is you are looking for.

Once you've gotten a good idea of the functional requirements of the expected end-result process that will incorporate your software, you can start drafting mock-ups of the interfaces. If you'd like to let them take a stab at it first, you can, but usually you're better off providing the initial ideas, and letting them tweak them around. You don't need functional code for this. Screenshots of UIs under development, HTML representations of the layouts using static filler text, or even drawings (if you have a decent artist on staff) could be used for the initial UI discussions.

Once you've gone through a couple of revisions, and everyone agrees with what is presented, get the customer's approval in writing! No matter how much they resist, this step is crucial. You may need to reassure them that signing off on the requirements does not mean that they can not have any further input into the project (depending on the nature of your relationship with the client), in which case you should outline how revisions to the requirements will be handled (e.g. subject to review and approval, pushed out to a subsequent version, priced separately as an enhancement, etc.).


I would tell them you will develop the program feature by feature. Until a next meeting, say in 1-2 weeks you are going to work X number of features. This could be 1, 2, 3 or more.

Say you will start by developing the most important fonctionality first. You need to start with the core features. Let's say you are making a teller machine (for the sake of argument). Tell them, ok the first (or next) in the list of most important features is asking the user's birthdate as a confirmation when making a large withdrawal (substitute for a fonctionnality on your project you know isn't one of the main core feature that would be implemented next).

This naive assertion should elicit a reaction from the client. When it does ask them what would they do next? What is the most important feature that's not yet done on the project and better than the one you mentioned.

Reusing the previous example the client might tell you it's validating the user's card or making deposits, etc. Then ask them to define it for you. Don't be afraid to ask a lot of questions, even naive questions if need be.

After you have discussed this with the client you should have some requirements for this one piece of fonctionality. You could define more than one piece of fonctionality but I would keep the number very low.

In 1-2 weeks meet up again with the client to present them what you have done and get their input on it. Present it to the client and get their input if anything needs to be changed or added.

Then repeat the previous exercise for the next bunch of features. Continue with this process in an iterative manner for the rest of the project, making sure you stay in contact with the client and have meeting at regular intervals to show your work and plan what will be done next (always staying with small chunks).


Without a manager that knows something of programming I've never had one bit of success at this. Rather, the only approach I've found that works is to observe what's actually going on.


You're talking engineering talk and they don't care about that, in my experience; they also don't want to commit to do anything (esp. in writing) and they don't really want to do any work, though that's not particular to business types -- nobody wants to do a bunch of work in a domain they don't know and don't care to know. That's your job (in their minds).

What I do is this: talk to them about what they want, in their domain-language. They won't be able or willing to be precise the way you'd hope for (use cases, design by contract, etc.) but you can be precise in translating their kind of vague and breezy list of desiderata into actual design, and, consequently, a design document. If they'll budget you the time to do this formally, so much the better. If not, create an impromptu, informal one that you can iterate on.

This isn't a super happy answer, I know, but I've found life to be easier when I stopped trying to get clients (or anyone, really) to step into my universe and talk my language. Even though I wind up asking the same questions over and over as I come to terms with the domain and the requirements (which are often only vaguely understood by the client) the counterintuitive thing is that the discussions aren't frustrating. In fact, the relationships with the clients tend to get stronger, I suppose because people like to talk about what they know, and you wind up understanding their POV more roundly than you might if left to a more rigorous designy approach.


I guess programmers have a better ability to envision what a program will look like before it's built. Paper prototyping may be an effective technique to overcome this. Paper prototypes are relatively "cheap" to build. By walking your clients through a simple paper prototype, you demonstrate the need for thinking "in the focused way necessary to gather true requirements." And it gives a specific way to focus: actually trying to use the application that is in your head!

Also, you can iterate very quickly from your best guess of what the client wants to the application the client truly wants, but has difficulties conveying. It is easier to look at a prototype and decide why it doesn't match the ideal application in your head than to list all the requirements of that application.

I worked on a web site where the other partners were more business-oriented. I kept asking for specific requirements in many different ways. Their response was basically, "You're the computer guy, we expect you to figure this stuff out. We prefer to do the business stuff." They were not concerned with the specific details... until the first version was released! They were much more enthusiastic about requirements after release, giving all sorts of feedback which would have saved me a lot of time up front when I had initially asked.

So I decided iteration is the key: build the minimal viable version and improve it based on feedback. If the requirements are too vague and general, make decisions based on "What is the simplest, fastest implementation?" (barring fundamental system design/architecture). Do not weigh too much on assumptions based of what you think is "right." It will just end up wasting time because chances are highly likely your thought process is different from your clients.

For example: client asks for image upload feature; won't elaborate any more specific requirements. Build it as naively as possible. Even though you think it's what the client will want, do not add automatic cropping, resizing, and thumbnailing features. Let the client see the minimal viable version (which you can develop much faster than the non-naive version), and the requirements will start flowing in as "This is what's wrong with the current version." Log each of these new requirements as "bugs." You can prioritize by which ones are easiest/most beneficial.

Actually happened to me: Request for sign-up form with special invite code. The idea was to create a viral registration process where each new user received a few invitations. I spent a lot of time ensuring the codes were unique and could only be used once. I also put a lot of effort into making the process as frictionless as possible by making first and last name fields optional. In the end, partners asked for these changes: first and last name mandatory, sign-up "code" valid if anything at all was entered into the field... sigh~