I’ve seen different requirements gathering processes throughout my 12+ years as a software project manager. Nevertheless, they all have the same structure. I’ll show you an example.
Requirements gathering is a process of identifying detailed requirements for the product, service, or results that the project team needs to create. The outcome of this process is specifications and other requirements documentation.
Here’s a critical insight for you:
The Main Types of Requirements Gathering
In theory, we use requirements gathering techniques. The most common ones are:
- Interview
- Meeting
- Competitors analysis
- Documentation analysis
- Brainstorming
- Workshops
- Surveys
- Questionaries
- Focus groups
In practice, you’ll mostly use meetings, interviews, and brainstorming. So, don’t worry about everything else. Try to notice how we used these techniques in the requirements gathering example below.
Requirements Gathering Example
In general, I try to elaborate requirements bit by bit. We may work on several requirements at once. They’ll still follow the same approach of a series of short meetings. I explain the whole process in this article:
How to Collect Requirements (as a Project Manager)
However, I also have to participate in several requirements-gathering “events”. So, I want to show you the other possible scenarios. The one below is a real story.
By the way, I’m sorry for missing out on the details, but I cannot share them due to a non-disclosure agreement (NDA). For a project manager, that’s always the case. Everything you create as a part of the project is the intellectual property of the project owners.
But I can say it was a software project – a rather big one considering the fast-paced Scrum life cycle that we had. Our project owners were from a large enterprise organization and had all been in software development for many years already.
Phase 1: Waiting for Stakeholders
There are many layers of stakeholders that provide requirements in the corporate world. However, product managers triage all the business needs for us. They are the champions of a product. They decide where the product is heading.
But, this time, the goal was to avoid redundant communications. So, in this case, we had to collect requirements directly from executives of a business unit that used our product.
First of all, we had to wait three weeks for an opportunity to communicate with that business unit. They had tight schedules, and it was hard to find a window. That’s the price of getting insights directly from executives.
I knew my project owners and their availability. That’s why I had to plan this activity well in advance.
Usually, I prepare for the next project while we work on the current one. So, we planned to have around five meetings spread over seven working days. We had to collect and clarify all the stakeholder requirements during this period.
Phase 2: Requirements Gathering
I have worked with many different clients from many different countries. All of them had different preferences. These stakeholders liked to solve problems in online meetings. But these could drag on for four hours, which was too much for us.
Moreover, there was a huge list of participants, including several business analysts, technical experts, some managers, and the executives. Not ideal.
So, what does it look like to gather requirements in the real world? Well, project owners just speak and share their thoughts. They don’t give you “requirements” or “specifications.”
Instead, they describe what their problems are. In addition, they use business jargon and they get distracted easily.
This can therefore be a long drawn-out process. It’s not worth recording such sessions – no one has time to review dozens of hours of footage. It’s much more efficient to do it on the spot. That’s why we try not to multitask and we remove all distractions. We focus on the conversation to capture requirements in the here and now.
By the way, the high-level business requirement was:
“We need in-depth analytics on the items we have in a project. It should be heavy on visualization with an ability to drill down into the data.”
Breaking Down Business Requirements
The first requirements came from a slide deck. It was some wireframes. These explained a vision of the user interface (UI). Second, we got a bunch of stakeholder requirements in the form of:
“As an administrator, if I click here, I will see a chart …”
“If I click on this chart, I want to see more details … well, we are not sure in what format. You will need to come up with recommendations.”
“On this screen, we should see all the information about this entity. Then, we can click on any chart to drill down further into details.”
In most cases, you can’t take these down as is. You need to convert them into solution requirements. Moreover, they don’t cover all use cases. They are focused only on the primary case that covers a pain point or a need.
Again, business stakeholders may not understand the risks of unclear requirements. And, frankly speaking, they don’t care. So, instead, they hire a whole team of experts to implement what they need into a product.
It’s your responsibility to lead them through a structured process – which brings me on to Phase 3.
In this video, you can find more examples of requirements gathering.
Phase 3: Requirements Specification
Keep in mind that the stakeholders had committed to helping us only for the next seven days and a certain number of hours. After that, the business unit would go on with its priorities, and we could expect only sporadic involvement and communication in emails.
Usually, stakeholders think they have provided exhaustive requirements during the meeting. But the devil is in the details.
Once you start digging into these requests, you will find many inconsistencies, questions, and challenges. That’s precisely why we planned more touchpoints.
So, we had a half-day meeting to listen and collect high-level information. Then, we had half a day to specify what we had heard.
First of all, we needed to create a structure for the requirements. We work with Scrum, so we use epics, features, and user stories. At this point, we created placeholder user stories with just a title and a few notes on what should be inside.
By the way, you can also use a requirements traceability matrix as well. It can help you organize and prioritize all requirements.
Second, our business analyst started to draft acceptance criteria for those user stories. This was only preliminary, but it helped to identify all unclear or conflicting requirements.
Third, we needed to provide a list of questions and discussion points to structure future meetings and run them efficiently.
Finally, we needed to check the technical feasibility, at least on a high level. We needed to identify the limitations of existing solutions. So, during this phase, many SMEs brainstormed as follows:
- Business analysts tried to break down and structure requirements.
- Technical experts came up with quick proofs of concepts.
- Designers tried to visualize the elements on a conceptual level.
Phase 4: Questions and Answers
The vision in the stakeholder’s head is usually different from what we understand. Therefore, it is important to reframe the business needs in terms of an actual tangible product.
During these meetings, we showed the sketches and designs that we had created. It helped us provide a better context for the questions and issues we discussed.
The worst-case scenario is to hear something like, “We didn’t think about it. We don’t know.” Sometimes, this may mean that we need to revisit the fundamental concepts behind the business need. Sometimes, it means that we need another four hours to discuss it.
This time, we even had to have two Q&A sessions in parallel. This way, we could focus on different aspects of the requirements in more detail.
Phases 2–4 iterated several times during the following six days. Did the work on collecting stakeholder requirements finish here? No, not even close!
After these several days of intense work, we developed our own champions for the business needs.
Finally, our business analysts and designers had enough information to put themselves in the shoes of that business unit. They imagined the pain points and could specify requirements further without the participation of all the executives.
So, we would get in touch with the business unit several times more. But only on some critical topics or decisions.
Later in the process, product managers (not the business unit) had to read through all the specifications and acceptance criteria to verify and approve changes to the product.
Phase 5: Solution Requirements
Another interesting fact about this case:
We analyzed all the requirements and available solutions. In the end, we concluded that it was much more cost-efficient to use a ready-made solution from a third party.
Therefore, we had to hand off this project to another team, including all the work we had done on specifying the requirements. Why? Well, for the good of the client and his business. It paid off later.
That’s why it’s also essential to keep requirements in good shape. There’s a possibility that you’ll have to give them to another team or outsource them to a vendor. If you do it well in the first place, creating a statement of work for a vendor is just a copy-and-paste job.
As you can see, processes in project management can have different forms. Quite often, they can be messy and unstructured.
You work with real people. Some of them are busy and influential. You need to adjust to their style of work. Still, you need to explain their role in the process and let them provide the business requirements while the project team comes up with a solution.
Conclusion on How to Gather Requirements
You can scale this example either up or down. Imagine that you work with a single person. The rest of the process would stay the same:
- The project owner describes a business need and high-level stakeholder requirements.
- You and the project team develop possible solutions.
- You discuss the solutions and details with the project owner.
- The team writes detailed requirements.
- The project owner approves the requirements, and you start planning how to implement them.
Templates You Need for Scope Management
Unfortunately, this article was just one piece of a complex project scope management framework: Many other processes happen before and after this one.
If one part doesn’t work, the whole system breaks.
My Scope Management Plan Template connects all processes and tools into one cohesive system. It also provides access to other articles and videos on scope management.
Don’t put your projects and reputation at risk. Ensure you know how scope management works in the real world.
All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). Tap into my 12 years of practical IT experience and get the Scope Management Plan Template.