Chief Quality Officer

Scenario: “Go find the requirements for this project you’ve never seen before. Oh yeah, they’ve never been formally laid out. No handholding!”

What do you do when you’re asked to gather requirements and you have no guidance? Since it happens a lot (more often in small companies than large ones), you gotta do some legwork. Let’s talk about how it’s going to have to happen.

Ultimately, you’re going to have to talk with a number of people (management, marketing, engineering, etc.), and you’re going to have to get them to sign off on those requirements, saying “Yeah, this is what we want.” Now, you can walk up to all these stakeholders and say “Hey, spill your guts!”, but that’s probably not going to fly. They’re busy. No, they’re overloaded. And they want you to figure it out, not to ask them to come to a full stop and serve you.

Not fun. But there’s a way out of it, as long as you remember the CQO’s #1 Rule Of Information Gathering: It’s easier to get someone to edit a document than to write it. In other words, if you come to someone saying “Gimme all the info I need!”, you’re going to get a big fat “I-don’t-have-time.”

So Don’t Do That. Do This Instead
On the other hand, what if you arrive with a document full of bullet points and concise paragraphs, and you say “Hey, Chester, I’ve been hammering at this document and chunking in all the info I think I need, but I know I’m missing a few things. Can you please take a look at this with me and help me fill in the blanks?”

Ding! Bingo. Now instead of showing up like a hapless newbie you’re coming across as Mr./Mrs. I-did-my-homework and the other person is going to be MUCH more likely to help you, because you just made it easy on them. They will look at your info and respond with a whole big mess of hey-you-forgot-to-include-this and wow-I-just-thought-of-that gems that will help you round out your document. They will respect you more and be more willing to work with you in the future because they know you don’t want to waste their time.

So How Do You Get That Document?
Let’s talk about how you do your homework and get that requirements document started anyway. Below are a few good tips but are by no means the be-all and end-all of the requirements-gettin’ universe. But it’s a start, and a start is what you’re after.

• Dig Into The User Manual. If you’re lucky enough to have one of these, it can be a veritable goldmine of often outdated information. But it’s a start point. Open up that PDF/HTML and fire up a brand new document. Go through the user manual and pull out everything that talks about what the program should do.Don’t get into the gory detail of how you perform the functions, just get the purpose. It’s enough to know that the program needs to import 3 specific types of data files; you don’t care whether it’s by file/open or edit/import at this time. You should end up with a nice solid lists of “whats” (and not a single “how”), broken down by functional area.

• Dig Into The Marketing Material. Go to the product website. Scour the product packaging. Look at the press releases. Find anything anyone has ever sent that promises that your Widgetizer 2.0 really does whiten your widgets - and any other promises made. These get to be bullet points as well.
• Dig Into the Product Itself. Fire up the product and use it. Try to do the things that your previous exercises told you it should do. See if there are any features in there that weren’t covered anywhere else. Is there anything inside the program that suggests conformance to some outside requirements? You may not get a whole lot of additional functional bullet points here, but by the time you’re done you’ll have enough product knowledge to enter into conversations about requirements more intelligently than before.

Now, Start To Put It All Together
By now, you’ve got a boatload of bullet points that spell out your product’s functionality. Now,

• Take a look at all of them and try and figure out what kind of high-level functional or business requirements could have driven these functions to be created.
• Group the functions under the requirements where they make sense
• If you’ve got leftover “is-this-really-necessary?” functions, put them in their own group.

When you’re done with this part, you should have a pretty good looking list of requirements. Granted, they may all be wrong (since you guessed at them), but it’s a start - and that’s what you’re after. Your SMEs (Subject Matter Experts) can correct you later.

Take It To The Streets
Now it’s time to start meeting all those wonderful SMEs.

• I’d suggest meeting with marketing people first, the rationale being that regardless of what management and engineering are working on, these people are PROMISING CUSTOMERS THINGS. And since it’s not unheard of for marketing to promise the big, comfy chair to customers, you need to know about it so that you can catch any disconnect between their priorities and those of development. Ask them to look at your homemade list of requirements and add/subtract/edit as best they can.
• I’d recommend talking to the project manager next to find out what expectations the customer has. If you can talk to a customer, that’s a bonus, but often you will need to go through the PM. They should know what they’ve committed to, and should be able to point you towards some sort of signed contract (Statement of Work, Service Level Agreement, etc.), that can give you an understanding of what your product is on the hook to deliver.They may also balk at what marketing is promising, and it’s a bonus for you to catch for them. Ask them to look at your homemade list of requirements and add/subtract/edit as best they can.
• Then you can meet with the development folks and find out where they get their marching orders from. Ask them to look at your homemade list of requirements and add/subtract/edit as best they can.

At this point you’ll have met with the major stakeholders and you’ll have an idea about the expectations of each. And because you did your homework, you were probably able to ask a lot of questions to uncover additional requirements that had never been put to paper before.

Your requirement-gathering job ain’t over, but it’s well begun. I’ll write more on that later - chew on this for now and don’t be shy with the comments.

- Dave Navarro, CQO