Like?

Using Validation Tools: Prototyping, Survey Review, Document Review & User Requirements

Start Your Free Trial To Continue Watching
As a member, you'll also get unlimited access to over 8,500 lessons in math, English, science, history, and more. Plus, get practice tests, quizzes, and personalized coaching to help you succeed.
Free 5-day trial
It only takes a minute. You can cancel at any time.
Already registered? Login here for access.
Start your free trial to take this quiz
As a premium member, you can take this quiz and also access over 8,500 fun and engaging lessons in math, English, science, history, and more. Get access today with a FREE trial!
Free 5-day trial
It only takes a minute to get started. You can cancel at any time.
Already registered? Login here for access.
  1. 1:09 Requirements Validation
  2. 1:54 Requirements Document Review
  3. 4:38 Survey Review
  4. 6:00 Prototyping
  5. 10:10 After the Reviews
  6. 10:53 Lesson Summary
Show Timeline
Taught by

Lee Webber

Lee holds a master's degree in Information Systems Management. He has taught college-level computer classes.

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.

Introduction

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

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!)

Survey Review

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.

Prototyping

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.

Unlock Content Over 8,500 lessons in all major subjects

Get FREE access for 5 days,
just create an account.

Start a FREE trial

No obligation, cancel anytime.

Want to learn more?

Select a subject to preview related courses:

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

See more testimonials

Did you like this?
Yes No

Thanks for your feedback!

What didn't you like?

What didn't you like?

Next Video
Create your Account

Sign up now for your account. Get unlimited access to 8,500 lessons in math, English, science, history, and more.

Meet Our Instructors

Meet all 53 of our instructors