Extracting user requirements from a person who does not know how to express himself

Question

I had an interview yesterday with a member of our organization who wanted to create a system to help him to do his job, the problem I had with him was that he had only a general idea about what he want. I tried to get more information from him by asking him specific questions which he had no answer to, such as what he expects to see in the first page when he opens the system..I told him that we will meet again in a few days because I wanted to think of a different approach to get clear requirements of him.

My question is what type of questions should I ask to get what he exactly wants, is there a guide that can help me go through this successfully?

Answer 1

There are a couple of different ways I'd suggest approaching this:

1. Job shadowing -> This is basically watching him do his job so that you know what he is doing and what connections are there between the systems and processes he uses to get his job done. This is totally observation from your end where questions may be asked but only to get a general idea of what something is.

2. Prototyping -> Try to walk through a paper-based version of how he would interact with the system. What parts does he do and what does he expect the system to do automatically?

In both cases you are trying to collect information from watching the experience of what is happening rather than asking him questions. There are a variety of reasons why he may not be able to answer your questions:

• Lack of self-awareness - perhaps he can't observe himself that well and thus doesn't know all that he does. For example, some people may be able to get from A to B but they couldn't give you directions because they don't know the streets or distances they drive before each turn.

• Lack of articulation - perhaps he can't articulate the process and thus while he knows what he does, he can't put it words well.

• Lack of structure - perhaps he can't put all the pieces together to answer your question.

Answer 2

It sounds like you're trying to get him to describe the solution rather than the problem. Non-programmers have a very difficult time thinking about software that way. To them, it's an unchangeable product rather than a flexible collection of components.

What you need at this point is a thorough problem description. He has no idea what the opening screen should look like as long as it solves his problem and doesn't introduce new ones.

For example, my wife told me she was looking for new budget software because with our current software she never knows how much money is really available. This surprised me because our current software is always synced with the bank and breaks things into nice categories, notifying us when we get too close to the budgeted amount. I asked why that wasn't enough, and she said it's too much work to keep up with entering receipts that haven't cleared yet, which often are for significant amounts, and there's no way to forecast based on transactions planned in the future. By the time transactions clear the bank it's too late to be useful in planning.

Notice she's describing the problem, not the solution. Part of the solution she didn't know she needed was a smartphone app with an ultra simple interface to quickly view the available budget by category and enter receipt amounts at the point of sale, and which automatically syncs the transactions to a more full featured application for use at home. As soon as I presented that to her, she said it fit her requirements perfectly, but she said she would have never thought of it on her own.

In other words, you need to gather requirements from the customer's point of view of the problem that needs solving, and leave the design details to the software professional. On the occasions when customers do care about the details, they usually have no problem letting you know. It's your job to present the design incrementally enough to allow them to provide feedback without causing yourself too much potential rework.

Answer 3

Ask them how they do their job now. Presumably they know that. From their description of their job, listen for clues that they collect information from someone. They might currently be writing in on post it notes, remember it in their head or if you're lucky, filling in an existing paper form, or if you are really lucky, into an existing computer system.

Much of what they do has nothing to do with information management, such as judging when a hair cut is done. But some of it will pertain to information, such as putting the money in the cashbox when the customer leaves (which is the same as filling in the amount received box and then inserting data in the receipts table).

Requirements gathering is an unsolved problem in computer science. Most advice is a sham, where we are imaging that typical line of business application consumers are capable of doing low level specifications just by asking them.

Another idea is to present a variety of options based on your own fuzzy understanding, and then once the customer has something to look at (drawn on paper of course, it's too soon to write substantial code) get some feed back and iteratively try to go from their. Again, depending on your customer, they might not do a good job of imagining themselves using the application, so be wary of thinking that even then that their feedback is final or an accurate representation of what they want.

Answer 4

I blogged about this last week. This can be very frustrating sometimes.

I'd start by asking questions like...

• What would make your job easier?
• What don't you like about how you do your job?
• Fill in the blanks... If I could to blank instead of blank it would make my work a lot easier.

You may have to have him show you what he's talking about. If that's the case then go visit him in his surroundings (it's more comfortable for him). Have him show you what he does and what he's like to do instead. Listen, I mean really listen. Try to understand as much about what he's doing without offering up changes or solutions or criticisms.

Once you have established a rapport with him he's more likely to open up and discuss what he really needs.

Then you can have him work backwards from what the expected output he wants and how to go about creating that output for him.

Answer 5

It is my general experience that end users don't know what they want. They know what they like and what they don't like. They know what is hard and what is easy, but the don't actually know what they want and don't want.

Start by asking them about the current way they do things. Ask what they like about this way and what they don't like. Ask what is the hardest part of the current system. Ask what shortcuts they currently use to make the current system more manageable.

Next ask what they have to do every time they do a process. Is there a form they have to look at every time? Is there some data they have to look up before they start? What metrics are most important to them.

Sit down and watch them actually go through the current system while they do a few tasks. Ask questions.

Finally, sit down and mock something up. Some screen shots or if you can a dummy page that doesn't actually do anything but allows the user to seen interactions and such. Get the user to look at it and use it. They will tell you what they like and what they don't like. They will ask you questions why things are where they are. Ask them questions to get better feedback.

I really find showing the user something gives them something to talk about. It makes sure everyone is mostly on the same page, and it helps you know that you are making something they can use.

Answer 6

If holding him by the ankles and shaking firmly doesn't work, you can try writing the entire application then showing it to him and having tell you why most of it is wrong. It's usually a lot easier for people to say why the don't like something than to tell you what they do want (which would be a lot more helpful to you).

If that takes too long, mocking it up in the simplest possible way that answers your questions and having him agree in writing that it's everything he wants might work. Hopefully your mockup is informed by an understanding of what he's trying to accomplish.

He most likely will want to make all kinds of changes, but at least you will be able to justify that the reason it's taking so long is that he's feeling his way through what he wants and making you change it as he does so. Stick with mockups as long as you can to minimize wasted time.

You can look up agile development (a giant topic) for further ideas - its a method that assumes everybody doesn't know up front everything they want to do.

Answer 7

Case Study

I recently embarked upon a re-write of our company's primary internal web app. To find out what features of the old app were used and which we not, and which related activities were too disconnected from one another, I logged all activity for three months beforehand, and analysed paths taken through the software. As I work in the same office as the users, I am also aware from past experience of how they tend to operate and what the larger business processes were. (The job shadowing mentioned in another answer, but done passively.)

Armed with knowledge of how the users were using the system, I then conducted user story interviews and produced a list of requirements. I selected a part of the application that had no dependencies as a starting point, and began iterative development using those requirements. The new software is already more testable and has a degree of separation of concerns that the previous software could not hope to achieve.

Answer 8

You can always take a fast first pass at it, maybe with some mockups. A lot of times that will get people going... it's easier for them to point at something and say yes or no.

Answer 9

Yes, job shadow, however, in the end, draw dataflow diagrams. I've done it hundreds of times. I've never run into a business person who could not understand a graphically clear DFDs (i.e not spaghetti). If you can't draw the DFD, you don't understand the workflow. If the client can't understand the DFD, you've drawn it wrong, so revised it.