Gathering User Requirements: Meetings, Observation & Surveys
- 0:05 Introduction
- 1:59 Document Review
- 2:23 Observation
- 3:20 Meetings & Surveys
- 4:10 The Requirements Document
- 6:28 Lesson Summary
This lesson introduces requirements gathering and describes the four tools programmers use to find out what their customers want: document gathering, interviews, observation and surveys.
Before you start writing any program, you need to know what it is supposed to do. And that is the definition of requirements gathering - finding out what the program you are going to write is supposed to do.
Requirements gathering has four different tools that you may use: document gathering, interviews, observation and surveys.
As you gather your requirements, you will write them up in a requirements document. You will have the customer review this document to make sure that you both are in agreement about what the program will do.
In this lesson, we'll look at each of these tools used to start and update the requirements document. We will look at updating and refining it in another lesson.
Requirement Gathering: The Pancake House
Fred says, 'So, Lee, you're going to try and program Foobar to make pancakes. I've been thinking of getting a robot like him to replace my grill man, who is retiring in three months. I want to name it 'Foober.' Do you think I could use your program in my new grill-bot?'
My answer to Fred is, 'Let me get back to you...'
Before I can program Foober, I need to know what Fred wants him to do. I have a general idea of what a grill cook does, and I also know that what a cook does at one place is probably different from what another cook does somewhere else. Does Fred want Foober to make just pancakes? What kind of pancakes - just plain ones, or should they be fancy too, like blueberry or with bacon cooked in? What about crepes? Are pancakes the only thing that the grill cook makes, or is he responsible for other things, like bacon and eggs?
Here's how I approach the problem: for starters, I get a copy of the menu. That will tell me what kind of pancakes Foober will have to be able to make.
Then, I'll need copies of the recipes for each flavor of pancake on the menu. The recipes will tell me what ingredients Foober will need for each pancake and how to mix and cook each one.
But wait, there's more!
Fred and I decide that I will need to spend some time in the kitchen, observing and taking notes about what the cook does. So, I do. I take a few days and hang out in the kitchen. I discover that the cook not only cooks up the pancakes, she also 'plates' them and garnishes each plate based on the flavor of the pancakes. She then puts the order at the pick-up station and notifies the appropriate server that it's ready.
She tells me that she not only makes the pancakes, but is also responsible for cooking up anything else on the menu that comes from the grill, like bacon, sausage or eggs.
She also tells me that she doesn't do prep work. Someone else whips the whipped cream or washes and slices the fruit. Someone else also makes the pancake batter.
As I suspected, I'm not just writing code so Foober can make pancakes. I'm writing code to make Foober a competent grill-bot.
Meetings and Surveys
When a business is being automated for the first time, that may be a good time to look at what the business is doing and how it does what it does.
In this case, Fred thinks that making some changes to the menu might be in order, so he and I sit down and put together a customer survey. Because Fred's customers are important to his business, he wants to find out what the customers like (and don't like) about The Pancake House and the menu.
Finally, I need to know when he wants me to deliver the programs. Fred tells me that Foober won't be delivered for three months, and that the code needs to be ready to run when he arrives.
The good news is, I can develop and test my code using Foobar at home - but this is definitely going to cost them more than just a few free pancake breakfasts!
The Requirements Document
I now have enough information to write up a requirements document, defining what I think the customer wants from the project. Notice that I didn't say, 'What the customer wants!' That's because with just one round of requirements gathering, it's very likely that both Fred and I have missed things. This is why part of the process includes 'requirements validation,' which is discussed elsewhere.
Based on what I found out talking with Fred and hanging out in the kitchen, the outline of my requirements document looks like:
- Write program to make Foober a competent grill-bot:
- Know how to make each pancake dish on the menu
- Know how to prepare other grill items on the menu, such as eggs, sausage or bacon
- Know how to plate and garnish each dish on the menu
- Know how to place orders at the pick-up station
- Know how to call the appropriate server to pick up an order
Foober will not be programmed to mix pancake batter or do any prep work, such as washing and cutting up fruit.
Based on reading the menu, I will expand the document to list the various pancake dishes ('Crouching Bacon, Hidden Eggs,' 'Pigs in a Blanket,' 'Sauerkraut and Onion') and describe the other grill items (bacon, eggs, sausage, ham, egg substitute, hash browns, etc.).
I will also document plating and plate garnishment, as described and shown in the menu. Finally, I'll briefly describe putting orders up, and calling the appropriate server.
At this point, I have a preliminary (or 'draft') requirements document. It won't be complete until Fred and I go through the surveys and add that information in. But the idea is to get this back to Fred as quickly as possible, so he can read it and let me know if I'm on the right track. He will probably return it with comments, suggestions or requests.
While Fred is reading the draft, I can start to do some preliminary analysis to begin to understand what I will need to do to meet his requirements. In this case, it pretty much means how I'm going to make Foober a competent grill-bot!
As you have seen, I've used all of the four requirements gathering tools to begin figuring out what Foober will need to do as a competent grill-bot.
Document review: I got a copy of the menu, which documents what pancakes need to be made and how they are served.
Observation: I spent time in the kitchen so I can see what she does - and doesn't - do.
Meetings: I had meetings with Fred, the owner, to talk with him about what he wanted.
Surveys: Fred and I developed a customer survey to find out what his customers thought and wanted.
Requirements document: Using these four tools, I was able to create a draft of a requirements document which, when finished, will be Fred's wish list, telling me what he wants Foober to do. I've given it to Fred for review, so the next step is to start making sure that I have everything Fred wants and that I understand each part. This is what we will talk about in the next lesson: requirements review. See you then!
Chapters in Business 104: Information Systems and Computer Applications
People are saying…
"This just saved me about $2,000 and 1 year of my life." — Student
"I learned in 20 minutes what it took 3 months to learn in class." — Student