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

  • 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
Create An Account
To Start This Course Today
Used by over 10 million students worldwide
Create An Account
Try it free for 5 days
Lesson Transcript
Instructor: 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.

To unlock this lesson you must be a Study.com Member.
Create your account

Unlock Your Education

See for yourself why 10 million people use Study.com

Become a Study.com member and start learning now.
Become a Member

Already a member? Log In

Earning College Credit

Did you know… We have over 100 college courses that prepare you to earn credit by exam that is accepted by over 2,900 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.

To learn more, visit our Earning Credit Page

Transferring credit to the school of your choice

Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.

You now have full access to our lessons and courses, watch the lesson now or keep exploring.
You've watched a video! Now you are officially smarter, check out the next video or take the quiz to keep learning.
You took a quiz! Getting a perfect score on a quiz is how you gain course progress. If you aced it, great job! If not, don't worry, you can try again.
You now have full access to our lessons and courses, watch the lesson now or keep exploring.
You just finished your first lesson. Study.com has thousands of lessons to help you meet your educational goals.
You're making great progress. Aim to watch at least 30 minutes of lessons each day and you'll master this before you know it!
You've learned so much, but only scratched the surface. Wait until you see what we have in your next lesson!
Getting a perfect score on a quiz is how you gain course progress. If you aced it, great job! If not, don’t worry, you can try again.
You're getting the hang of this! Keep taking quizzes to make progress on your learning goals.
Look how far you've come! Take all the quizzes in a chapter and you'll master this topic in no time.
Keep clicking that 'next lesson' button whenever you finish a lesson and its quiz.
You're 25% of the way through this course! Keep going at this rate and you'll be done before you know it.
Two days in a row, nice! Keep your streak going to get the most of your learning and reach your goal faster.