How to Clearly Define Project Requirements

Like a construction blueprint, project requirements serve as a clear representation of everything that needs to be done in order for a project to be deemed complete. However, unlike in construction where even the simplest project begins with a blueprint, there are innumerable cases (read: horror stories) of developers taking on large-scale projects with little-to-no definition. 

At Vivify Ideas, we’ve had to do our fair share of postmortem analysis to figure out how to mitigate the problems that are caused or exacerbated by undefined project requirements. 

Here’s what we’ve figured out so far.

Discovery Phase

More often than not, clients come to us with ideas that aren’t completely defined, which is perfectly understandable. 

At that point, nobody expects to have a fully-fledged and failproof project on their hands. As most of you know, it’s the small issues that tend to cause the biggest problems, yet you’re likely to oversee them until you start asking yourselves (and the clients) the hard questions. 

It is therefore critical that you don’t immediately start the development phase, as much as the client may object (and they will).

Instead, we begin our collaboration with the Discovery Phase, during which we actively work on identifying and understanding clients’ motives to develop that particular project in the first case (Business Case). 

This will not only serve us as a solid starting point for the entire work on the project ahead, but also aid in creating the ideal outcome of this phase: the Product Roadmap.


The discovery phase is followed by workshops between the client and our UX designers, as well as our Solution Architects. Here we use our knowledge and experience from past projects to fully define the scope of the project, as well as discuss and agree upon mutual expectations. 

On the technical side of things, we’re looking at what technologies we’ll be working with, as well as how they will contribute to the main functions that essentially define the project. On the conceptual side, we’re inspecting the target demographic for the product, their behaviour, habits and what solutions (if any) are currently on the market.

Of course, no glove fits all and our approach will depend based on the clients’ experience. With a big business, we’d want to focus on finding a Lingua Franca and discussing the technologies in greater depth. A smaller startup client, on the other hand, might require a little more mentoring, and we’re happy to help. 

Once all of the above (and more, but we won’t get into it right now) are clearly defined, we proceed to the Design phase, followed by the Development phase.

What it Means for Us and the Client

By going through this process, we effectively set up clearly defined goals of the project, get a deep understanding of the clients’ needs and user expectations. It not only saves a lot of time, but results in greater productivity and motivation as the entire team works towards a tangible goal. 

Of course, the chances of unknown issues popping up are significantly decreased too, which, as you can imagine, works wonders for the clients’ budget.