Using Validation Tools: Prototyping, Survey Review, Document Review & User Requirements
- Track Progress
- 1:09 Requirements Validation
- 1:54 Requirements Document Review
- 4:38 Survey Review
- 6:00 Prototyping
- 10:10 After the Reviews
- 10:53 Lesson Summary
Programmers uses validation tools to make sure that they have a clear understanding of what the customer wants their program to do. This lesson will look at requirements document review, survey review, and prototyping.
I'm doing some work at The Pancake House, programming Fred's robot Foober to work the grill there. During my requirements gathering to document Fred's expectations, I obtained a copy of the menu, observed the cook, and talked directly with Fred to learn his vision for Foober. I will take what I learn from these activities and write a draft of a requirements document. Fred gave his customers a survey, which we will review at the same time we review the requirements document. I will probably make changes to the requirements document based on my conversation with Fred about it (the review), on the responses to the surveys, and on Fred's comments about Foobar's pankcake-fu.
Requirements validation is what I do to make sure that I understand what my customer wants the program I'm writing to do. For the Pancake House project, this means reviewing my requirements document with Fred and analyzing the surveys to see what changes should be made to the menu.
I've also written a prototype program using my robot, Foobar, to test and demonstrate a small part of robotic pancake making. This is all part of what should be an ongoing conversation with the customer. As we go through the process of validating these requirements, they may change, requiring some accommodations to be made.
Requirements Document Review
Now it's time to review my requirements document to make sure that it truly represents what Fred wants. This is the first place to start in the validation process because the document details what the customer wants. If the requirements document does not match the customer's expectations, the program won't be right.
My requirements document draft details how to make Foober a competent grill 'bot. He will have to:
- 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
I've attached a menu to document the pancake dishes, plating, and plate garnishment that Foober will need to know. Finally, I've described putting orders up and calling the appropriate server. Foober will not be programmed to mix pancake batter nor to do any prep work, such as washing and cutting up fruit.
Fred is happy with most of the document but wants a couple of changes: 'I'd like Foober to be able to do prep work, just in case the prep guy is out for some reason. And I think he should be able to mix pancake batter, too.'
We discuss that a bit so I can get a better idea of the details. It will include not only washing and slicing fruit but also setting up other ingredients like chocolate chips, pre-cooked bacon, and the items for different pancake dishes.
After thinking about it, I tell Fred, 'I can program Foober to do the prep work, but it's going to take longer than the three months you've given me, and of course, that will cost extra. Here's a suggestion - let me get Foober programmed like we discussed. I can do that in the original three months, at the quoted price. Since the food prep is not the highest priority for you, why don't we revisit that after Foober is making, plating, garnishing, and setting out orders?'
Fred thought about it for a bit and agreed that the prep work wasn't the priority right now so it could wait. This is fairly typical of such a meeting. The earlier we can get these kinds of requests out in the open, the easier (and cheaper) it is to take care of them.
Because Fred's cook is retiring in three months, the most important objective is to replace her with Foober. Prep work is already done by someone else, so it's not as important as the grill work. Plus, Fred's budget doesn't allocate any funds for extra programming right now. (And I won't work for just pancakes!)
The next thing to do was look over the surveys. Survey review lets us look at possible changes to the business, which may (or may not) affect the programming project.
We found suggestions on decor and hours of operation, which didn't affect my work. We also found menu suggestions, which did affect my work. Fred told me, 'It looks like the sauerkraut and onion pancakes aren't a big a hit. Let's go ahead and take those off the menu.' (Why was I not surprised?)
Fred also got some interesting requests for new flavors. One suggestion was Banana Split Pancakes - pancakes with banana slices, strawberries, and chocolate chips with whipped cream, with a side selection of syrups. Another one was Peanut Butter and Banana Pancakes with whipped cream and maybe some chocolate syrup! Fred thought they might be something to try. I told him to come up with recipes and I'd add them to Foober's programming.
So far in our review and validation, we've added a possible second phase of the project to teach Foober prep work, instead of extending the project past the date the new cook was needed. The surveys didn't have too much effect on what I needed to program besides taking one recipe off the menu and adding two new ones.
Over the years I've discovered that even written requirements, reviewed several times, can still have holes and misunderstandings. Sometimes they are a result of unspoken assumptions. Sometimes they result from a misunderstanding of what a term means.
One of the best ways I've found to get out of this sort of trap is to build a simple prototype to demonstrate what I understand the requirements to be. The prototype is intended to be a simple model of what the real program will do. Once the prototype is built, I get as many users as possible to come in and, as we say in the business, bang on it to see how it works and give us feedback. That's the point of prototyping - demonstrating the core elements of what a program should do to get user feedback.
While Fred was looking over the requirements document and the surveys, I did some preliminary work at home with Foobar. I programmed him enough to be able to make plain pancakes and put them on a plate. My thought about doing that part of the program first was simple - if Foober couldn't make plain pancakes and get them on a plate, he couldn't make the more complicated ones, let alone garnish and set them up for pickup.
For my prototype, Foobar wasn't going to garnish or set out for pickup. He was just going to make plain pancakes and get them on a plate. My code was downright quick and dirty, and I did quite a bit of fudging. For example, because these were plain pancakes, I didn't have to code Foobar to add extra bits like chocolate chips or blueberries. That meant I didn't have to get Foobar talking to a recipe database, which would have taken way more time and was outside the scope of my prototype. I needed to demonstrate Foobar's pancake making skills and nothing more.
Once I had the code done, I ran Foobar through his paces. I was happy with the pancakes he made, so I told Fred that Foobar was ready to demonstrate his mastery of pancake-fu! Fred invited us over to the Pancake House one afternoon when things would be slow. It could have gone better...
When we got there, Fred had part of the kitchen set up for the demonstration, pancake batter ready, and some plates so Foobar could put pancakes on them. Foobar got up to the grill, picked up the spatula and pitcher of batter, and...stopped.
'Foobar', I said, 'it's time to make pancakes.'
'Foobar, show Fred how you make pancakes!'
'Foobar, are you going to make pancakes or not?!'
'Can't, boss!' he replied.
'Griddle is too cold, and I can't turn it high enough!'
'The griddle is set to 260 degrees. It needs to be at 500 degrees, and it only goes up to 300 degrees!'
I looked at Fred, who started laughing. 'All of my kitchen equipment is European, which means all of the controls are in degrees Celsius, not Fahrenheit.'
'Oh,' I said. I plugged my laptop into Foobar and changed the required temperature to 260 degrees. Because Foobar didn't care about the difference between Celsius and Fahrenheit, all he had to know right now was what the grill should be set for. With that done, he began making some pancakes, one at a time.
Fred got a worried look on his face. 'Is that the only way he can make them - one pancake at a time?' he asked.
'Well,' I said, 'at this point, I just want him to make decent pancakes. When I start programming the menu into him, he'll know how many pancakes are required for each dish and handle as many dishes as you have seats for customers, all at one time.'
'What happens when we get slammed with a full house and takeout orders? What will he do then?'
I looked Fred in the eye and said, 'What do you want him to do?'
After the Reviews
So, I brought Foobar into the Pancake House to cook some pancakes and found that, like NASA, I had a 'measurement units' problem, which caused Foobar some confusion until I tweaked his program. Fred also expressed concern when Foobar started to make one pancake at a time, which led me to find out that I needed to increase the number of dishes Foober needed to manage to account for a full house and take-out orders!
The result of the meetings and demonstration was that I would go back and update the requirements document to reflect what Fred and I had learned. I will also update the prototype programming to demonstrate Foober managing multiple orders.
So, to summarize: requirements gathering and requirements validation should be a continuous conversation between you and your customer. You will work with your customer to validate what you understand his requirements to be. This conversation will probably take several turns through the cycle, updating and changing your requirements document.
Tools you will use to get this validation are:
- Requirements document review to verify that your requirements document accurately describes what the customer wants the program to do. In our case, Fred decided that he wants Foober to do prep work as well as cooking.
- Survey review to analyze the results of surveys given to your customer and/or his customers. These surveys are not necessarily limited to topics about your program. They may include other business-related questions that won't directly affect your code. Fred's survey found some possible new menu items but also had other data about hours and decor. I will have to program the new menu items, but I won't have to worry about store hours or re-decorating the place.
- Prototyping is by far my favorite tool because I can get a sample of the program into the customer's hands and generate much more valuable feedback than a document review. My prototype with Foobar did just that!
And, now that it looks like we have the major requirements nailed down, I need to start doing some serious analysis.
Ask Our Experts
Response times may vary by topic.
Our experts can answer your question related to:
- Requirements for Different Careers
- Enrolling in College
- Transferring Credit
- And More…
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