Project Requirements: The What, Why, and How
This blog is reader-supported. When you purchase something through an affiliate link on this site, I may earn some coffee money. Thanks! Learn more.
Have you ever been a part of a project that just didn’t seem to be going anywhere?
Maybe it felt like there was no clear goal, or that the requirements kept changing.
If so, then you know how frustrating and even maddening it can be to try to work on something without having a good understanding of what is required. Requirements are essential for any project, yet they are often one of the most difficult aspects to get right, especially if you work in an environment where there are high levels of uncertainty or change. It might feel like you’ll never nail down what you’re supposed to be doing (GDPR project, I’m looking at you).
Stick with me, and we’ll explore what project requirements are, why they’re important, and some tips for developing good ones. We’ll also discuss when you need to rework your requirements and who should be involved in doing so.
By the end of this article, hopefully, you will have a better understanding of how to approach requirements gathering (which we should really call eliciting requirements) for your next project!
First, let’s make sure we know what we are talking about.
What are project requirements?
Project requirements are the foundation for a successful project. By understanding and documenting the project requirements, you can ensure that the project is completed on time, within budget, and meets the expectations of the stakeholders.
Requirements also help you cover off other success criteria like quality expectations, sustainability requirements, and more.
Project requirements can be divided into two categories: Functional and non-functional.
Functional requirements are the specific actions that the deliverable must be able to perform (or meet), such as creating an account, being blue, adding items to a shopping cart, or sending a message.
Non-functional requirements are the quality attributes that the system must meet, such as performance, security, auditability, and usability. Being able to manage non-functional requirements is something you’re probably going to have to help users with, as in my experience, they tend to default to thinking only about features.
They are the product specifications.
Why are project requirements important?
Duh.
I feel I have to include this, even though the answer is pretty obvious if you’ve been around projects for some time. If you haven’t, or if you work for people who think you don’t need to spend any time working out what they actually want, then this section is for you.
By taking the time to understand the needs of the stakeholders, you can ensure that the project is successful. Or at least, give yourself a decent chance of delivering what stakeholders will actually use (which is often aligned to the main things every stakeholder wants out of any project).
Your project requirements are the why, what, and how of your project. In other words, they explain the motivations, objectives, and approach of your project.
So why do stakeholders need to give you the time of day about requirements and treat them like they are important?
Because they provide the rationale and context for your project decisions.
First, they provide the project team with a shared understanding of the project’s goals and objectives. Second, they help to ensure that the project team can balance scope, timescale, budget, and resources to get them an output they will find acceptable.
Third, they can help to resolve conflicts between stakeholders. Requirements can be prioritized. The priority requirements get built or delivered first.
Finally, they provide a baseline against which the project’s progress can be measured.
Project requirements are the foundation of a successful project. By taking the time to develop clear and concise requirements, you can set your project up for success.
What if you don’t know the requirements at the beginning?
Well, this is my life!
I have worked on many projects where it hasn’t been possible to have a full picture of all the requirements. Not least when we were working towards implementing changes for GDPR, and the full impact and details of the regulations had not yet been released by our regulator in the UK.
We were flying the plane while we built it… not something I would recommend, but in highly emergent situations where there is uncertainty, there’s not much you can do about it.
Stick with what you can influence: you know broadly what the objectives and goals are. Adapt and flex as you go, reviewing priorities and working on what you can while the other stuff unfolds. That’s the best you can do, and as an approach to managing uncertainty, it works pretty well.
Tips for developing good project requirements
Requirements are the foundation for any project. Without a clear understanding of what is needed, it is difficult to create a plan, set expectations, or allocate resources.
Whether you call them use cases, user stories, just ‘requirements’ or something else, they are the expression of what you want from the project.
Good solution requirements help ensure that everyone is on the same page from the start, which can save a lot of time and frustration later on. Even if the needs of users, stakeholders, and/or the project change later on.
There are a few key things to keep in mind when developing requirements for a project.
1. Be clear and concise
Requirements should be stated in plain language that can be understood by everyone involved in the project. They should be specific enough to provide guidance, but not so specific that they constrain the team’s creativity.
They also need to be clearly linked to the project objectives.
2. Be realistic
It’s important to be realistic about what can be accomplished given the time, resources, and budget that are available. Trying to do too much will only lead to frustration and a feeling of being overwhelmed.
By all means, put everything on the list, but then you’ll want to use a technique like MoSCoW to help stakeholders prioritize what they can actually have.
3. Be flexible
As the project progresses, there will inevitably be some changes to the requirements. Be prepared to adjust the plan as needed to accommodate these changes, and any new project activities required.
If you work in an agile team, this happens through backlog grooming and sprint planning. The project process has flexibility baked in, which is great.
4. Be consistent
Top tip! Use the same terminology throughout the requirements document to avoid confusion. This will help ensure that everyone is interpreting the requirements in the same way.
You can (should? I don’t always) use a requirements traceability matrix that numbers each requirement so you can track them through the project. Very handy for when there is a lot of software testing to do.
5. Be complete
Make sure that all of the requirements are accounted for. It can be helpful to create a checklist of sorts to make sure that nothing is forgotten.
I know you can’t always do this, as we’ve said above, and in
But in general, the more you know, the easier it is to stay within time and cost expectations.
Developing good project requirements is essential to the success of any project. By taking the time to create clear, concise, and realistic requirements, you can set the project up for success from the very beginning.
Read next: How to compile business requirements.
When do you need to rework your requirements?
Let’s assume you created a great big requirements document, with a lovely traceability matrix, and breakdown structure to sit alongside. Should you ever rework them? Of course!
Here are a few scenarios where reworking requirements would be sensible.
1. When the project’s goals change
If the goals of the project change, then the requirements will need to be changed in order to align with the new goals.
2. When the project’s budget changes
Otherwise known as: When the project sponsor tells you that you have to do it cheaper.
If the budget for the project changes, then the requirements will need to be changed in order to align with the new budget i.e., you can do less.
There is a chance you could deliver the same scope for the same money if you are able to use internal resources and don’t mind the timescales being pushed out. Juggle your constraints and see what creative solution you could come up with that doesn’t increase costs.
Of course, you might be offered more money to include more stuff in scope! Happy days. Just make sure you are actually working on a project and not something that is going to turn into a never-ending ‘can you just’ job.
3. When the project’s timeline changes
If the timeline for the project changes, then the requirements will need to be changed in order to align with the new deadlines and project plan.
4. When the project scope changes
If the scope of the changes, then the requirements will need to be changed in order to align with the new project goals. See where I’m going with this?
5. When the project team changes – maybe
There is a chance that if the team working on the project changes, then the requirements will need to be changed in order to align with the new team.
For example, if you lose a key resource and you can’t backfill the individual, you might have to change what is done to accommodate that. In this situation, I’d consider bringing in a contractor or outsourcing the work, both of which might mean changes to the budget, procurement plan or timescales, and maybe the deliverables.
6. When the project’s stakeholders change
People change their mind. New leadership likes to make a mark on things. Whatever the reason, sometimes, when stakeholders change, they want the project done in a different way, and that impacts the requirements.
Let’s just hope it doesn’t affect what you’ve already built, although in my experience, stakeholders rarely like to waste work – especially if they can pick up the credit for it being delivered on their watch as someone else has left!
7. When the project’s environment changes
Let’s say that your company is bought out during a project. You’ll probably have to refine the requirements to make changes to branding. At the most simple level, your new project deliverables might need to now be a different color or align with some other brand guidelines.
8. When the project’s technology changes
This happened to me: a supplier was under threat of bankruptcy, so we decided to move away from them and use a different supplier. And that supplier had a slightly different solution which changed up what we had in scope for the project.
It all turned out fine in the end, but it was a hair-raising experience at the time.
Tech changes also introduce project risk, which is something you should be watching out for all the way through the lifecycle.
Read next: How to manage constantly changing priorities (that’s a chapter I wrote for a book, Project Pain Reliever).
Involve the right people in eliciting and managing requirements
First up, I’d recommend taking advantage of any business analysis skills in the team. While the project manager can lead on requirements elicitation, it’s not easy, and it is time-consuming. That pulls you off your other work. BAs are experts in this, so if you have that resource in the team, see if you can get them on the team.
Learn what the business analyst success path looks like, and what your specific next step is to start or grow your business analyst career.
The other key stakeholder group to involve in the requirements work is the people who have the requirements: users, customers, and stakeholders. The most common method of engaging them in this process is to hold interviews.
Other methods include focus groups, surveys, and document analysis. We do a lot of workshops and process mapping, looking at as is/to be or current state and future state. Stakeholder requirements drop out of the process maps.
When in doubt, always involve stakeholders in the requirement development process to get their input and feedback. Better that they have their say than they feel like they were not listened to.
Documenting requirements
Requirements must be documented. The way you approach this will be covered in your requirements management plan, and there is another article on this blog about how to compile business requirements that might help.
The most common format for requirements documentation is a requirements document (surprise!). Include a description of each requirement, who requested it, and why it is needed. Add in any success criteria or measures, and give it a unique identifier.
Keep your requirements documentation up to date as the project progresses, because, as we’ve seen, things change.
This includes ensuring that new requirements are added as they are identified, that existing requirements are not changed without approval, and that all requirements are met before the project can be considered complete.
I’ve already mentioned the traceability matrix, which is another useful tool to track the original requirements and create alignment with the scope management plan.
FAQs about Project Requirements
What are examples of project requirements?
Some examples of project requirements are:
-The project must be completed within a certain timeframe
-The project must use certain materials or follow certain methods
-The user interfaces must return results within 0.01 of a second
-The software must interface with key business applications (and then you’d go on to list them)
How do you write a project requirement?
There is no one answer to this question as it can vary depending on the project requirements and what is needed for the specific project.
However, some tips on how to write a project requirement include being clear and concise about what’s needed, using language that can be understood by even non-experts, and providing enough detail so that the requirement can be worked on and delivered.
In summary
So where are we now? To wrap up what we’ve covered in this article, requirements are essential for any successful project. By taking the time to develop good requirements, you can avoid many of the pitfalls that can make a project fail, like miscommunication, poor prioritization, and wobbly leadership.
