Methods for Requirements Gathering
I once worked for a creative agency that wanted to become a product development company. They had some great (vague) product ideas and wanted me to help make them a reality. Brainstorming sessions with a creative agency was a new experience for me. We sat around a long table and began talking about one of the products. Everyone had ideas for what it should include. As the discussion progressed, the ideas were flying fast and furious. Someone wrote each one on a whiteboard. Occasionally, someone would come up with an idea that seemed better than a previous one, and the new one would replace the former one. After 30 minutes or so, there was a twisted mass of confusion on the board, and the CEO said, “Yeah! Let’s do it!” She turned to me and said, “You can do that, right?”
Frantic brainstorming sessions are not good methods for gathering requirements. They’re fine for generating ideas, but they must be sifted and analyzed to determine what is feasible, important, and beneficial.
An endless stream of ideas, when treated like a list of requirements, becomes an infamous BFV.
There are many ways you might go about gathering requirements, and they don’t include brainstorming sessions. Here are a few that I typically find beneficial:
Business requirements brief
Client/stakeholder interviews
Real time observation
Business Requirements Brief
It’s always a treat when your client hands you a perfectly prepared document outlining all of the major requirements they have identified for their project. They know exactly what they want and what it will do for them. All they need is someone to plan and build it. In these cases, your job is a lot easier. The requirements brief becomes the "Where do we want to be?" section.
Not all clients will do this for you. In my experience, most don’t have a complete idea of what they want. They’ve identified a problem that needs solving, but they don’t know how to solve it or understand what the solution might require. It’s your job to help them help you.
Client/Stakeholder Interviews
Meetings and interviews with your client and/or stakeholders can be very productive ways of eliciting requirements. They provide an informal environment where the client can talk candidly about the problem, how they’ve tried to solve it, and what an ideal solution would look like. It’s a good idea to avoid relying on one person for input. If you can talk to a variety of stakeholders, you’ll get a much better overall picture of the problem and what is needed to resolve it. When designing a system, the people who have to use it daily are the ones most likely impacted by it. They can provide you with real insight regarding the problem and its effects, thereby enabling you to more clearly define concrete requirements.
Real-Time Observation
In certain situations, observing people interacting with the current system can provide you with information about problem areas. Using observation with interviews, or even a requirements brief, can be very helpful in defining requirements. Observation provides a context for the information you obtain from an interview or the requirements as defined by your client in a requirements brief.
The more information you can gather about the problem and the desired remedies, the better equipped you will be to write crystal clear objectives (requirements) for the client brief.
Ask the Right Questions
Fortunately, asking the right questions begins with the questions that are already part of the client brief. The two most important ones you can ask are:
Where are we now?
Where do we want to be?
The answer you receive to the first provides a description of and context for the problem to be solved. The answer to the second provides the foundation for the project’s objectives. When the objectives aren’t as clear as they need to be, begin asking those probing questions to get the clarity you need:
What is the rationale for investing in this particular objective?
What will it do for the business?
How will it be quantified and measured?
At what level of improvement is the greatest ROI achieved?
Categorize and Prioritize Requirements
All requirements can be categorized in two ways: functional and non-functional.
Functional requirements specify something the system should perform such as a function, behavior, or action. Some examples can include:
Administrative functions
Authentication
Authorization
Audit tracking
Certification requirements
Reporting requirements
Legal or regulatory requirements
While functional requirements describe what a system should do, non-functional requirements describe how a system works. Non-functional requirements specify how the system should behave. They define the criteria by which a system is judged, rather than specific behaviors. Performance requirements are a good example: “All stored procedures in the database must return results within 0.5 seconds.”
In addition to performance requirements, other non-functional requirements might include:
Availability
Capacity
Data Integrity
Environmental
Maintainability
Recoverability
Reliability
Scalability
Security
Usability
Once you’ve discovered and categorized the functional and non-functional requirements, you need to prioritize them. This is something you must do with your client, especially if you’re following an agile model since you’ll be producing small deliverables regularly. You’ll use this to plan your sprints.
Be sure to identify dependents. Some requirements are dependent on others being completed. When you build a house, you don’t try to put the roof on before the walls are in place to support it. Carefully analyze the requirements and identify those that depend on the completion of others, then make sure your prioritization reflects that dependence.
How About a Little Practice?
Let’s assume that you’ve just been hired to update an existing system for a client. Your contact at the company, Christie, doesn’t have time to prepare a formal requirements brief, and since she’s located on another continent, face-to-face interviews and observations aren’t very realistic. So Christie has sent you an email in which she has attempted to describe the problem her company is facing and what they believe to be a solution. Take a few minutes and read the email carefully, then identify as many requirements as you can, classify them as functional or non-functional, and determine any dependencies between them.
Greetings,
As you know, Brevity has been in the clothing business for a long time, and one of the keys to our success is adapting to new customer trends, provided they have staying power. We’ve become aware of an interesting online trend that we believe has enormous potential. A significant number of women shoppers are purchasing men’s briefs for themselves.
Twelve months ago we added a required field to our add-to-cart popup which asks, “Are you purchasing this item for yourself or someone else?” We don’t ask any follow-up details. Interestingly, our findings show that 43 percent of online women shoppers are purchasing men’s briefs for themselves rather than someone else. Subsequent research has shown that these shoppers wear our briefs primarily as lounge or sleepwear.
We've decided to expand the line and market it to women as “Men’s briefs, the way you like them, just for you.” We are adding smaller sizes (XS and XXS), a much wider and more playful variety of colors and patterns, and tagless waistbands.
We need to be able to analyze the sales in real-time and compare them to the historical figures for men’s briefs to women buyers versus buying for themselves. Using this and other relevant data, we need to be able to anticipate the weekly sales volume for the new line. We must also anticipate a reduction in sales volume for our regular men’s briefs, assuming more women will be purchasing the new line. We don’t want to waste money with overstocked items, so we need to reliably predict sales so manufacturing can make the necessary adjustments to both lines. We also need to know which colors and/or patterns are in greatest demand. An analysis may help us identify future best-selling combinations.
We need to collect, track, and analyze this data from all sources. Each of our brick-and-mortar stores throughout the U.S. and Europe will be carrying the new line. It will also be offered online as well as in our Amazon.com store. Data collected must be on a per-store basis. We would also like to analyze demographics within a 15-mile radius of each of our brick-and-mortar stores. We want to know what percentage of the local population is female, their age groups, whether they are single or married or otherwise involved, income brackets, ethnicity, etc., and be able to show demographic changes over time. If we can identify patterns between demographics and sales of the new line, we can better gauge how to stock each store. We can talk about how to analyze the demographic data later, but we need the system to collect it for each store area once per quarter and watch for significant changes.
That’s everything off the top of my head right now. It should be enough to get you thinking. If anything else comes to mind I’ll send a follow-up email.
Thank you, and I look forward to seeing your ideas for the project.
Christie
How did you do? Do you have a good list of requirements? How about clarity? Is your list clear or are some of the requirements vague? Can you make them clearer, or do you need more information?
Hang on to this list. You’re going to work on this more later.
Let’s Recap!
Some common methods for gathering requirements include: business requirements brief, client/stakeholder interviews, and real-time observation.
The two most important questions for gathering requirements are also headings in the client brief: Where are we now? and Where do we want to be?
Requirements can be classified as functional or non-functional.
Functional requirements describe what a system should do, while non-functional requirements describe how a system works.
In the next chapter, we’ll look at the flip side of requirements: constraints. The process of identifying constraints is very similar to gathering requirements, and they’ll help you define the boundaries for the project.
