14 Best requirements gathering techniques

Did you know that, according to the statistics, up to 50% of project rework is a result of requirements problems and that 70% of failed projects go downhill due to poor requirements?

To avoid this worst-case scenario and identify possible project risks on time, you should try some of the requirements gathering techniques we’ll cover in this blog post.

So, keep reading.

Requirements gathering techniques - cover

What are requirements in project management?

As stated by Elizabeth Larson and Richard Larson

“A business requirement is a description of the features and functions of a product (something you will deliver) that satisfies a want or need…”

More generally, the PMBOK® Guide defines a requirement as: 

“A condition or capability that is required to be present in a product, service, or result to satisfy a business need”.

In his article, Creating clear project requirements, Paul Burek distinguishes 2 general requirement types that every project has:

  • Business requirements — they define what the organization wants or needs to be able to do once the project is completed.
  • Technical requirements — they define solutions for how each project need will be satisfied.

All in all, requirements are all tasks that must be completed to finish a project successfully

What is requirements gathering in project management and why is it important?

As defined in the PMBOK Guide, requirements gathering “is the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.”

Also, collecting requirements is the first step in creating a project scope management plan — which makes it one of the most important steps toward a successful project. 

However, eliciting requirements from stakeholders is also one of the most difficult phases, as requirements are often vague and difficult to define.

In addition, the requirements are expected to change often, and there can be many hidden or misunderstood requirements, especially in an agile environment. 

Luckily, using certain requirements gathering techniques might be a significant help in building a strong foundation for your project. 

Now, let’s analyze these techniques in more detail.

The best requirements gathering techniques

So, before embarking on the new project mission, you’ll need to elicit project requirements.

As every project is unique, there isn’t a single technique you should use. 

Actually, a mix of several techniques might be the best way to go, as it will cover more project areas, and provide the most reliable data.

If not sure how to organize the entire requirements gathering process well, or manage the project in general, our suggestion is to use a project management tool like Plaky to help with planning.

Here is the list of 14 requirements eliciting techniques:

  • Interviews
  • Focus groups
  • Facilitated workshops
  • Questionnaires or surveys
  • Brainstorming
  • Mind mapping
  • Role-play
  • Observations
  • Document analysis
  • Reverse engineering
  • Prototyping
  • Benchmarking
  • Context diagrams
  • Use cases and scenarios

Technique #1: Interviews 

An interview is a technique of eliciting information from stakeholders by directly talking to them. 

You conduct the interview by asking project participants either prepared or spontaneous questions, and take note of their answers.

Certainly, being prepared for the interview increases the chances of gathering the required information. 

After all, when you know exactly what your goal is, you’re more likely to actually achieve it — i.e. get the answers you need.

Of course, stakeholders as well should have a general idea of what the conversation will look like. 

Knowing what topics you plan to cover in the meeting will give stakeholders a chance to prepare and, consequently, perform better during the interview.

And, here are some more useful interview tips: 

  • Start out the interview by asking general questions — this gives stakeholders the opportunity to describe what they need, in their own words, and give you insight into their goals and expectations. 
  • Avoid asking open-ended questions that can be answered with short answers — you want to gather specific information, and “Yes” or “No” answers simply won’t provide relevant data.
  • Restate what you hear — this is a good way of reaffirming what the stakeholders want, as it reduces the chances of a misunderstanding. For example, a restatement such as: “This is important to you because it makes your business more secure?”, allows a project manager to confirm to what degree the security issue is important to a particular stakeholder.
  • Ask a lot of follow-up questions — it enables eliciting all the specifics.
  • Always listen carefully — practicing good listening skills and establishing a good rapport with stakeholders is key to truly understanding their needs.

Technique #2: Focus groups

As defined in the PMBOK® Guide: 

“Focus groups bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result.”

In simpler terms, focus groups are small group interviews that include a moderator, and stakeholders, who all engage in an interactive discussion trying to elicit necessary project requirements, or refine the ones already established. 

Compared to one-on-one interviews, focus groups are designed to be more conversational. 

Technique #3: Facilitated workshops

Similarly to focus groups, facilitated workshops are focused sessions that bring key stakeholders together to define product requirements. 

However, workshops are much more:

  • Collaborative, 
  • Creative, and 
  • Action-oriented.

Workshop participants usually work together in teams — they engage in different activities to create solutions to a certain problem. 

And, as stated in the PMBOK® Guide, facilitated workshops “are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences.”

Furthermore, because of their interactive nature, workshops:

  • Build trust, 
  • Foster relationships, and 
  • Improve communication among participants.

Here are 2 specific examples of facilitated workshops in different industries:

  • Joint Application Development (JAD)
  • Quality Function Deployment (QFD) 

Joint Application Development (JAD)

Joint Application Development/design sessions are a technique used specifically in the software development industry. 

The goal of JAD workshops is to bring together subject matter experts and the development team to improve the software development process and clarify the requirements. 

Quality Function Deployment (QFD) 

This is a technique used in the manufacturing industry. 

The goal of the Quality Function Deployment (QFD) workshop is to determine critical characteristics for new product development. 

Among other things, during a requirements workshop, participants develop so-called user stories — i.e. short textual descriptions of required functionalities, widely used with agile methods.

Technique #4: Questionnaires or Surveys 

In contrast with an interview, which is often too time-consuming, questionnaires or surveys might come in as a useful replacement — especially when dealing with several stakeholders, and a large amount of data.

Moreover, questionnaires or surveys are great if there are multiple stakeholders in different geographical locations. 

Surely, the information you collect using this technique is easy to analyze and interpret.

However, you should be extra careful how you frame questions, as different framings can result in different outcomes. 

Technique #5: Brainstorming

The PMBOK® Guide defines brainstorming as a technique used to generate and collect multiple ideas related to project and product requirements.

It is a group creativity technique that can be great as a starting point for your requirements gathering. 

Using a simple tool, such as a whiteboard, you can quickly start brainstorming all the ideas that pop into your mind — and then write them down. 

At this point, the more ideas you generate — the better. 

After the brainstorming session has ended, you will take time to analyze the elicited ideas in more detail, focusing on the good ones.

Technique #6: Mind Mapping

Mind (or idea) mapping is a creative technique of organizing ideas visually. 

With mind maps, you can group all the previously brainstormed ideas (i.e. requirements) into different groups.

Having all the ideas transparently displayed in front of you, mind maps will facilitate further idea generation.

Technique #7: Role-play

The role-play technique is excellent for discovering diverse users’ viewpoints, and generating new ideas. 

During role-play, different people play roles of the different user types. 

This interactive approach helps you understand various user perspectives and their individual product requirements and needs. 

Technique #8: Observations

Sometimes, users can’t point out certain requirements simply by telling them, as they’re not even aware of them. 

So, observation can be useful in uncovering these hidden requirements.

Observation is the action of monitoring somebody or something in order to gather information.

Seeing users in their natural environment, and observing how they use a product, or what difficulties they might face, allows you to identify precisely what the users need.

Technique #9: Document analysis

Document analysis includes eliciting requirements by analyzing existing documentation and identifying information relevant to the requirements. 

Here’s a list of documents that you can analyze: 

  • Business plans,
  • Marketing literature, 
  • Agreements, 
  • Requests for proposal, 
  • Current process flows, 
  • Logical data models, 
  • Business rules,
  • Repositories, 
  • Application software documentation, 
  • Business process or interface documentation, 
  • Use cases, 
  • Other requirements documentation, 
  • Problem/issue logs, 
  • Policies, 
  • Procedures, and 
  • Regulatory documentation (e.g. laws, codes, ordinances, etc.).

Technique #10: Reverse engineering

Reverse engineering is the process of deconstructing an existing system to learn how it is built.

This technique is a systematic way of developing a comprehensive list of functional requirements by understanding how something works. 

After you have gained knowledge about the subject in question, you can then duplicate it or enhance it.  

You can apply reverse engineering to many things, including software and physical machines.

Technique #11: Prototyping

Prototyping is a technique of obtaining early feedback on requirements by providing a working model of the expected product before actually building it. 

So, basically, it’s a mock-up of the final product that you can experiment with.

Though they can be pretty costly, prototypes are useful for 3 reasons:

  • They allow the trial of mock-up versions of products by users, before the final product release, 
  • They are excellent for feedback generation, and
  • Based on the prototype performance, you can make necessary adjustments. 

Various modern prototyping tools facilitate making mock-ups — they are particularly used on agile and other software development projects. 

Technique #12: Benchmarking

In simple terms, benchmarking is the performance comparison of your company’s product with the competitor’s product which is considered to be the best in the industry. 

Benchmarking is a great technique, as it allows you to:

  • Identify best practices, 
  • Generate ideas for improvement, and 
  • Provide a basis for measuring performance. 

Technique #13: Context diagrams

Context diagrams are a visual requirements gathering technique.  

As their name suggests — they are used for presenting the entire context of the process. 

They depict a business system (e.g. a process, equipment, a computer system, etc.), and how people and other systems interact with it. 

Technique #14: Use cases and scenarios

Use cases are an excellent technique for collecting specific requirements in various situations. 

So, by exploring different scenarios, you will learn which feature or functionality should be used in which specific case. 

Use cases are expressed in step-by-step lists of tasks that should be performed to accomplish business objectives.

On the other hand, scenarios, also known as user stories, are short textual descriptions of required functionalities, in the form of a narrative. 

User stories describe:

  • The stakeholder who benefits from the feature (i.e. the role of each stakeholder in the product development process), 
  • What the stakeholder needs to accomplish (i.e. the goal of each stakeholder), and 
  • The benefit to the stakeholder (i.e. motivation that drives stakeholders to develop specific features). 

Conclusion: It’s best to combine several requirements gathering techniques

Each project includes requirements. 

To ensure the success of your project — you just need to choose the appropriate technique for eliciting its requirements.

Our advice is to combine several techniques, as they will supplement each other and result in gathering a complete list of requirements.

✉️ Can you think of any other effective requirements gathering techniques? If yes, feel free to contact us at blogfeedback@plaky.com, and we may include your ideas in this or a future blog post. Also, if you liked this blog post and found it useful, share it with someone you think would also benefit from it.