Trick or Treat – A Technique for Gathering Requirements?

As Halloween approaches I watch the children getting excited about their costumes and their favorite activity for gathering loads of candy. I remember teaching my little ones to say “Trick or Treat” when they go to the door. We spent weeks selecting just the right costume; we rehearsed going to the door and saying “Trick or Treat” and then “thank you’. We planned our route for Halloween night. You could call this the “Trick or Treat” process.

The result is a bag of candy – all kinds of candy that you can imagine. One of the first things we would do when we got home was to go through the bag of goodies and sort it – a pile for gum, a pile for chocolate, a pile for fruit flavored candy, and so on. Once the candy was sorted the little ones would then organize it by the favorites – so they could make sure and get their favorites first, since they weren’t allowed to eat the entire bag that night.

You’re probably reading this and thinking cute story, but what on earth does this have to do with requirements? So I will make a couple of points here.

First, if you are interviewing users and basically say “Trick or Treat – give me some good requirements” guess what you will get? You will get a hodgepodge of things that the users would like to see. Some will be important to you and some will not. You will have to sort through all of those needs and sort them into categories. We usually call those categories features. Some of those features will be pertinent to the project and some will not. So if you are beginning to gather requirements why not be more focused in the questions that you ask? Do some research and look at any information available that is pertinent to the system. Identify end users (you don’t have to trick or treat in the entire subdivision, focus on a couple streets where the really good treats are given) and set up meetings with them.

Identify processes that are affected by the project – which ones are changing, which ones are new, are any no longer needed? Ask the users what processes are working well for them? Work to understand how they are doing their job today.

Second, once you have sorted the requirements into features, you will need to prioritize those features. What are the customer “favorites” for getting done first? Sometimes we fail to really prioritize and end up working on the easy parts of the system first, instead of focusing on parts of the system that are high risk or not well understood.

At the end of the project, revisit what happened. We might ask if we went on the right streets, if we followed the process or deviated for some reason, did we get as much candy as we expected? What worked well? What changes could be made to improve the process? Did we get the expected end results? Were the users satisfied with the product?

So even though this is written with a little Halloween humor, hopefully the points made here will hit home when thinking about gathering requirements! Happy Halloween!

By: Marcia Stinson