As a project manager, you should facilitate and organize the efforts to collect requirements. However, from time to time, you may need to write requirements yourself. So, below I’ll explain everything a project manager needs to know about collecting project requirements.
Collecting requirements is the process of identifying, documenting, and controlling changes to the project requirements. The outcome of this process is detailed requirements documentation, for example, user story, product backlog item, or specification.
Full disclosure: I’m not a qualified business analyst. What I’m about to explain doesn’t come from a formal education but 11+ years of practical experience.
The information below should be enough for most project managers. However, if you want to combine the role of a project manager and a business analyst, you need additional training.
I believe that business analysis is a full-time job. A project manager should not spend time and effort writing out specifications and user stories.
Why is Collecting Requirements Important?
The first thing you need to do is accept that systematic requirements management is crucial for project success.
Second, stakeholders should understand the negative impact of poorly defined requirements. It’s your responsibility to communicate it!
Also, a business “vision” has nothing to do with the specifications required by the project team. Without proper requirements management, their expectations will not be met.
Third, don’t expect project owners to have skills in requirements management. You need to educate them about the overall process and their role within it. You need to help them express their needs in simple terms while you and your team offer ways to meet these needs, again explained in layman’s terms.
Fourth, project owners may not know what they want until they see it. So, once you create something tangible, stakeholders start generating new requirements at once.
Here, you must control their appetites. You need to focus them on reaching the initial project objectives within the constraints they set. Or you need to persuade them to update the objectives and constraints. Otherwise, you may spiral down a rabbit hole of improvements that drags you away from the project objectives.
The Biggest Challenges with Collecting Requirements
As a project manager, I’ve done this various ways
- I had a dedicated person (business analyst) responsible for defining requirements on one project.
- And there were projects when I had to write out requirements on my own.
I can tell you that, in both cases, the challenges are the same.
First of all, you need to work with project owners and stakeholders who are always short on time.
Second, stakeholders usually do not see the value of the requirements management process. They often think that it is a part of the execution phase. That’s why project owners try to keep the time spent on requirements to a minimum.
Instead, they want to “start the work” as soon as possible. So, they say, “We’ll get all the details as we move forward. Let’s just get started.”
However, they don’t know that high-quality requirements streamline the development process.
Hierarchy of Requirements
First of all, requirements have a hierarchy. You can imagine it this way:
- Business requirements.
- Stakeholder requirements.
- Solution requirements.
- Functional requirements.
- Non-functional requirements.
By the way, you can find a real-life example of how I organized requirements gathering event of a software project. Read this article next (opens in a new tab):
Requirements Gathering Example (Real Software Project)
Business Requirements
These describe the overall business need. They explain why project owners decided to start a project and invest resources.
In an ideal world, project owners describe business requirements in a project charter by including a problem statement, business case, project justification, business objectives, etc.
But, in the real world, project managers never see those documents, or project owners never create them in the first place. In this case, you must ask project owners why they initiated the project and what they want to achieve from a business perspective.
Don’t force them to create those formal documents. In most cases, they don’t know how to do it. Just let them explain their expectations as best they can.
Business requirements often lead us towards a specific solution or approach that we need to take. So, you should be careful here.
You see, project owners identified a solution. They thought it would help them achieve their business needs. Sometimes it’s true, and you can accept the solution. But, sometimes, you’ll need to ensure that the proposed solution is valid. In this way, business requirements dictate the boundaries and constraints of the project scope.
Stakeholder Requirements
In essence, stakeholder requirements elaborate on how to achieve the business requirements. They describe the product or service from a stakeholder perspective. In this case, it is someone who will own or use the product or service.
Usually, project owners explain what capabilities end users should have in the product or service, what action they should take, what results they’ll get, etc.
But keep in mind that the project owners are not the end users in most cases. Instead, they create a product or service for a broader audience. So, there’s a serious challenge here!
Project owners provide requirements that they think the real users want. That’s why, if you’re working with an external client, you may want to help them identify the correct stakeholders’ requirements. But the overall responsibility still rests with the client.
On the other hand, if you develop an in-house product, you may need to collect the stakeholder requirements yourself. Therefore, you may need to work with the end users. Or you’ll work with a product manager who knows the users’ pain points and analyzes their needs.
In most cases, project owners don’t have the required depth of knowledge to propose an efficient solution. Therefore, ask them to provide these requirements only from a business or user perspective. Detach them from the technical aspects of implementing these requirements or the product you already have. It will give you enough space to develop the most efficient solution or generate several alternatives to choose from.
Here’s another tip from practical experience:
I learned that stakeholders need to see what they ask you to produce. So, visualizing the end result or product helps them a lot. Insist on creating designs, wireframes, or mock-ups right at the start of the project to help them do this. They will then find it easier to express their requirements in simple terms.
Solution Requirements
You or a business analyst will create these solution requirements based on stakeholder requirements.
They consist of functional and non-functional requirements.
Functional requirements describe what the end user will experience. It’s something you can test and play with. Non-functional requirements cover other capabilities of your product or service, such as security, performance, stress tolerance, maintainability, and continuity.
Just to be clear:
There’s no direct connection between stakeholder requirements and solution requirements. One stakeholder requirement may generate numerous specification documents, user stories, and designs that will form functional and non-functional requirements.
You can use requirements traceability matrix to organize requirements documentation. Moreover, you can connect solution requirements with the specific business need.
Solution requirements are primarily for your project team. Therefore, they are very detailed. You need to describe, in simple language, what the project team needs to implement and how it should behave.
This could be in the form of a specification document. Or you may draw on user stories to describe individual functionalities.
Each industry has its best practices on how to create solution requirements. So, you need to check what works best for your project.
How to Write Requirements Documentation as a Project Manager?
You failed to hire a dedicated business analyst. Now project owners and your boss want you to write all the requirements. What should you do?
First of all, you need to be honest about your skills in business analysis. You need to communicate that you’ll do your best, but you can’t promise it will meet industry standards because you are not qualified.
This might feel like shooting yourself in the foot. But, believe me, it’s better to be upfront rather than hide the problem and get into issues later on.
In most cases, project owners will accept the risk and support you. On the other hand, some projects are relatively simple. You can handle requirements management without any extra training.
Second, you need to give yourself permission to write requirements in the simplest form possible. Use narrative language as if describing a product to a friend. Also, a picture or a diagram is usually worth more than a hundred words. Use more visualizations. Your only goal is to ensure that the project team understands the solution requirements.
Likewise, you need to discuss the requirements with the team to discover any ambiguity. You should delegate writing non-functional requirements to the most knowledgeable team member. And delegating, in general, is a must. Let team members help you create initial drafts that you’ll tidy up.
You can also go with user stories, which anyone can master. Search the internet for the best practices.
Overall, you need to choose a form of requirements documentation that you can handle and that doesn’t require special training. It will be a learning process. Your first requirements will likely be not very good. But take feedback from the team and improve them bit by bit. You’ll get the hang of it in no time.
Here’s How I Gather Requirements in the Real World
Step #1: Understand the Business Need
We (the project team) get a high-level draft of requirements from a customer (product owner, product team). It can be as simple as a short description of functionality.
We teach our project owners to provide stakeholder requirements without attachment to any technology we use. So, they state these requirements as a “user need.”
We get strange requirements from time to time. They simply don’t fit into our vision of the product. In this case, we don’t shy away from asking how they relate to the business need of the project and product. This way, we ensure that stakeholders align their requests with the ongoing project’s goals.
Step #2: Quick Research of the Need
Then, the business analyst and I try to expand and explain the user needs to the project team. It’s a short, high-level discussion. (here you can find an example)
It’s up to you to decide whether you need the whole team or not. However, I recommend having at least one person from every function or department.
After a quick chat, we write down our recommended solutions, concerns, questions, and assumptions and send them to the project owners.
This short meeting saves us time and effort in the long run. We show the areas where we want them to focus. Sometimes we conclude that we need to discuss requirements with SMEs or other teams. We plan those meetings at once and prepare the agenda.
Step #3: Business Analysts Draft Solution Requirements
Then, the business analyst works with clients and stakeholders. He collects all required details in a few days and writes out a draft specification (user stories in our case).
These are our functional and non-functional solution requirements. We also get answers to all our outstanding questions and concerns.
Step #4: Analysis of Requirements
Next, I ask the team to read and think through the draft requirements. They need to understand and discuss them among themselves. Then, we have a grooming session.
I ask one of the team members to explain a requirement to the rest of the team. The goal is to ensure that we are all on the same side. We need a shared vision of what we need to deliver.
Usually, by this time, there are quite a lot of questions. Someone might have understood it in another way. Someone might point out some dependency or a conflict with other requirements. Or possible difficulties in implementation, testing, or a flaw in the design. The business analyst takes notes and updates the user stories.
In the end, as the project manager, I ask several additional questions:
- What is the possible impact on other areas of the product?
- How complex is this requirement in general?
- Who is the best candidate to implement the requirement?
- How will we test it?
- Are there any risks here? (You should educate the team in risk management.)
By the way, the analysis of requirements is a crucial part of risk identification process.
Step #5: Review Draft With Project Owners
The business analyst takes all this feedback and tries to clarify outstanding questions with clients and stakeholders. Then, he updates the user stories and we get the final draft of acceptance criteria.
Step #6: Get Sign-off from Project Owners
Next, he sends them for approval to the client. It all happens in our project management software. So, project owners approve requirements by setting a correct status to the user story.
Collect Requirements Techniques
As you see, there are two distinct phases here.
In the first phase, we need to understand business needs and stakeholder requirements. Usually, this is purely communication between project owners, you, and the business analyst.
One technique that helps here is creating avatars (buying personas, user profiles). In this technique, you put yourself in the end user’s shoes. You need to understand their pain points, needs and wants.
You may have several avatars for the product or service that you develop. These are particularly helpful when establishing stakeholder requirements, which should come in a narrative form as if from a real user.
There are several other techniques that you should be aware of. They include:
- Facilitated workshops
- Focus groups
- Nominal group
- Mind mapping
- Affinity diagrams
- Observations
- Questionnaires
- Surveys
- Benchmarking
In rare cases, you might need to conduct such information-gathering events. But not on a daily basis. Most stakeholder requirements come from project owners.
What Does It Mean to Elicit Requirements?
The second phase is to come up with a solution to implement stakeholder requirements and describe it in the solution requirements.
This is where you mostly work with the business analyst, project team, and SMEs. You may need to clarify and adjust stakeholder requirements during this process. There are dozens of techniques. But there are four that you will need to use most of the time.
Document Analysis
One way or another, stakeholders will provide you with different documents. They may be in the form of laws, software manuals, guidelines, use cases, policies, process workflows, or business plans.
As easy as it sounds, you need to read, analyze, and capture relevant requirements from them. Then, at some point, you need to discuss whether these requirements are applicable to the project’s success.
Documentation can also be a source of stakeholder requirements. For example, Apple has guidelines on how all applications for iPhone should feel and look. All developers should comply with these guidelines.
However, Apple does not provide the solution requirements on this matter. Therefore, you need to determine how to comply with their stakeholder requirements.
Brainstorming
You’ll use good old brainstorming to develop solutions to stakeholder requirements. Thinking creatively in this way can also generate functional and non-functional requirements. First, gather relevant stakeholders or project team members. Then, let the ideas flow – you want to encourage as many as possible. You can prioritize them later.
Interviews
Talk to stakeholders directly. Record their answers. Analyze their ideas and convert them into requirements.
Prototyping
Create a working model of a future product. Your project owners can then play around with it to generate more stakeholder requirements. It’s an interim stage to come up with the requirements for the final product. You can also use storyboards: A sequence of images that show how a real product will behave.
What Does It Mean to Analyze Requirements?
So, now you have documented a bunch of requirements that have come from different sources.
First of all, you need to review them all and ensure that they are aligned with the business needs of the client. Each requirement should be connected to a business case described in the project charter. Otherwise, you are planning to do something that project owners did not request. This is bad practice.
Second, you need to prioritize all requirements because your project has time, money, and scope constraints. When your plan goes beyond a constraint, the low-priority requirements should be the first to go. But you need to discuss all of this with project owners.
Third, you need to identify requirements provided by different stakeholders that contradict or conflict with each other. Keep in mind that stakeholders don’t discuss requirements with each other. Therefore, you will have to resolve such conflicts.
You need to communicate or meet with all owners of contradictory demands. Then, act as in any case of conflict resolution.
You can achieve the best results by collaborating and compromising. Forcing, avoiding, or smoothing the conflict in requirements usually backfires later.
Quite often, project managers are afraid to question the soundness of requirements because it always leads to a conflict with stakeholders. You need to be self-aware about such notions. You need to define all requirements and resolve all disputes. Otherwise, you’ll simply delay the problem. It will appear later in any case.
How Do Requirements Impact Your Project Management Approach?
There’s a strong relationship between requirements, scope, and quality.
The better you know the requirements, the better you can define the scope. The better you understand the project scope, the better quality you can achieve.
And, in general, the better you identify the scope, the more accurate the project plan you’ll create. On the flip side, ambiguity in requirements leads to uncertainty of scope, resulting in poor quality.
However, in the real world, requirements are never finished or settled. You may finish implementing an approved requirement. But then, you show it to the project owners and they want to tweak it a bit. Or they simply add new functionality to the product that impacts existing capabilities.
So, you need to update requirements all the time. You can’t change this. Instead, you need processes and tools to collect, maintain, and adjust requirements with as little extra effort as possible.
Therefore, it’s a matter of selecting a proper project management approach. Should you use Scrum, Kanban, or a plan-driven approach (waterfall)? They all work well under certain circumstances, but they all have pros and cons. Consider the following.
Are you able to clearly and comprehensively define requirements in advance? If yes, it may be better to choose a plan-driven approach. You can use resources more efficiently by having a long-term plan.
If there’s no efficient way to collect all requirements in advance, or they change quickly, then you’re better off adopting an agile approach. You’ll need to adapt quickly to the changes rather than constantly wasting time changing the plan.
https://www.youtube.com/embed/HFNGW2jp0vc?feature=oembedThis video can help you understand the pros and cons of different approaches.
But, as I said before, the industry and environment you work in have made a choice already. If you’re new to the industry, you should research the best practices in requirements management.
On a practical level, it will boil down to a set of selected processes and tools. Here’s a couple of examples using the approaches outlined above:
1. In an agile approach, you organize requirements through the hierarchy of epics, features, and user stories. As a result, you control the user stories implemented during an iteration. So, for example, when you implement all the user stories from one feature, you can close it.
2. In a plan-driven approach, you manage requirements in an RTM, which connects requirements to separate specifications, designs, and test cases. In addition, the RTM allows you to connect all requirements to a specific WBS element. Once finished, you can close related requirements, marking them as “finished.”
How to Collect Requirements
Let me summarize all we have learned so far. Here are four things I want you to remember:
#1. You will need to focus your efforts on managing processes to define requirements. You should act as a facilitator. Try not to get bogged down by writing specifications on your own.
You should have a dedicated, trained, and experienced expert to do the work. Delegate these activities as much as possible. You need to stay at the management level to see the whole picture.
#2. Customers or sponsors will be interested in the project’s success. So they will be engaged in the process and motivated to provide all the information they can. Unfortunately, though, they might not have enough expertise to describe what they want in technical terms. In addition, they might not think through all the specific details. So, you need to use the right techniques and ask the right questions if they are going to provide you with business and stakeholder requirements.
#3. Most key stakeholders will not provide you with requirements until you ask for them. They may know nothing about your project. They might be busy with other projects. So, you need to be proactive. Contact them as soon as possible. They may help you to define critical requirements before your planning is over. So, stakeholder management is a must. Remember, stakeholder = requirements.
#4. Don’t think about requirements only in terms of the product or service you need to create. You also need to consider requirements to the project management, processes of testing, getting sign-offs, rules of compliance, etc. Once you finish working on the product itself, there might be dozens of steps to take before it goes to the market or production line.
In the long run, you need to strike a balance between a rigid process and no process at all.
Get My Scope Management Plan Template
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.