Three Types of Requirements Gathering

There are many different activities that are a form of requirements gathering. So many that it can be difficult to determine which approach to use in what circumstance. By classifying requirements gathering into three different types of activities we can simplify the choices.

The nature of a requirements gathering task should affect the mindset with which you approach it. Some tasks are “do it like this” tasks, while others are “you’re the expert – tell me what I need” tasks. Very different approaches to solving problems. We’ve presented ten requirements gathering techniques in the past. In this article, we categorize the situations in which many of them are more effective than others.

There is an over-arching or over-riding goal of only doing extremely valuable work. That will frame your choices about what requirements to gather. Any given product or project may have one or all of the following.

Gathering Existing System Business Requirements

In a migration project, the goal is to improve the way a company is doing something they are already doing.

There is a continuum that defines the boundaries within which the new system will be deployed. Essentially a massive design constraint in the form of explicit charter and often implicit budget limitations. The location of a given project on the continuum will determine how many of the requirements for the new system are expressed as “do it like the old system.”

The requirements gathering techniques that are most effective in this environment are the ones that help you identify the existing system’s behavior and requirements. Has anyone ever worked on a project where someone said “Here are the requirements we used to build the old system. Use these.” [A few hands pop up.] In how many of those projects did the requirements match the existing system? [Hands go down. Groans and chuckles and mumbles wash across the blogosphere.] And for the three people with thier hands still up – “And were those requirements still relevant?” [Roaring applause from completely swayed audience, followed by many links from other bloggers.]

In the real world, you have to validate, rework, and define for the first time the requirements that describe the existing system. Here are techniques that work best in this situation.

• Document Analysis. Those old requirements documents will have good information, as well as bad. Analyze the docs to find the gems. Also review training procedures, OOA/OOD diagrams, online forums, or call-center knowledgebases.
• Interview Subject Matter Experts. Interview the people who truly understand how the existing system works. These could be experts on the implementation (the developers who wrote it), people responsible for compliance or policy adherance, or simply the lady who remembers everything (correctly).
• Reverse Engineer Existing System. Document analysis may not get you completely there – you may have to [shudder] review the source code to figure out what is actually happening.
• Existing System Interface Analysis. An analysis of the user interface is the black-box equivalent of reverse-engineering the source code. The system has an event-response model of some sort. Map out the behaviors that the system exhibits in response to inputs and events.
• Observation. Ethnographic research is the study of users as they use an existing system. Watch how people do the work today. In addition to understanding the application better, it will present you with insights about the frequency of use of particular functionality.

This type of requirements gathering can be both difficult and thankless. Project sponsors have been known to say “make it like that.” and expect that that would be sufficient requirements definition. People (who haven’t gathered requirements) assume that if there’s a working version already in place, then defining the requirements to recreate it will be simple. It isn’t. There are often implicit requirements that are not obvious from reverse engineering an application.

Business analysts will run into this type of requirements gathering when displacing legacy applications. Product managers will additionally run into this form of requirements gathering when performing competitive assessments.

Gathering Known New Business Requirements

When a project has been funded, or a decision to create a new product has been made, there are already some well defined goals if not lower level requirements. Responding to an RFP (request for proposal) provides the first opportunity to gauge these “known” requirements. Usually the language of the RFP will tip the hand of the client, revealing their preconceptions and expectations.

The requirements gathering techniques that differentiate themselves for this type of requirement gathering are the ones that focus on communication. SME interviews help you reverse engineer an existing system and understand operating constraints. Interviews with other interested parties at a “step up” in perspective are the key here.

• Stakeholder Interviews. There are many stakeholders for a given project. In addition to the users, there are the people who’s objectives depend upon the user’s activities. Interviews with stakeholders will define these ultimate objectives, and present the context for making prioritization decisions. Active listening is one of the most effective ways to make your interviews valuable.
• JAD Sessions. JAD Sessions are great at bringing ideas to the table and vetting them amongst interested parties, who all contribute in a structured meeting format.

Gathering Unknown Business Requirements

Exploration of the unknown can be the most exciting part of product management and business analysis. The most concise difference I’ve come up with between the two is that product managers focus on extrapolating value and opportunity across customers to define a market, where business analysts are focused on the needs of a single customer.

• Brainstorming. Brainstorming removes the barriers of conventional thinking and can uncover great ideas, and really bad ideas that inspire great ideas. Brainstorming promotes lateral thinking that uncovers ideas that may be missed otherwise.
• Idea Seeding. Idea seeding introduces constraints into a “brainstorming-like” activity to make it even more effective.
• Prototyping. A physical (or visual) model often inspires people to great ideas. It also is very effective at validating your great ideas after you’ve had them.

Hat Tip

Thanks David for your article on the three types of requirements – concious, unconcious, and undreamt. It inspired us to flip the easel and write on the other side of the paper.

Summary

Every requirement gathering technique can be applied to any type of requirements gathering activity. Some techniques will be markedly more effective than others. The makeup of your team will affect the overall effectiveness of each technique. Our experience has been that these approaches are most apt, given roughly equivalent effectiveness with each technique.

They simply make the job easier.