← Back to the Blog

Developing Good Requirements for your Web Projects

By Tim Butler
Developing Good Requirements for your Web Projects

Regardless of whether we think about it or not, much of our life is driven by requirements. From a simple task of going to the shops through to building a skyscraper, we end up with a set of requirements we need a product or service to meet.

So what exactly is a requirement? The Oxford dictionary defines requirement as:

“A thing that is needed or wanted”

With a background in project management, one of the best methodologies I became familiar with was Systems Engineering. This is a methodology of breaking up large projects into smaller, more manageable components. Even when looking at problems which are outside of a project (like renovating a house), this methodology can be applied to easily break up a complex task into smaller, more easily handled tasks.

The usual requirements

Of course when a project is in the definition phase, one of the key parts is having a good requirement. Regardless of a project size or complexity, if your requirements are unclear it will be close to impossible to manage or produce the desired solution.

Consider the following differing requirements:

  • I need this computer to be faster
  • I need a better website
  • I need a bigger car
  • I need a new phone

What do all of these requirements have in common? They’re difficult to test and verify. Without key goals to meet, each of these requirements could be interpreted in a thousand different ways. What one person considers fast could be completely different to another, and this will only lead to problems if you ask another person or company to implement.

Therefore, the key to a good requirement is if you can write a test case for it

Developing good requirements

Consider the way you would measure if you met the requirement of:

“I need a bigger car”

What’s bigger? The height? The length? The weight? The engine? When the person said this, what they probably had in mind was a better set of requirements. Would the person be happy if they got a car that was simply heavier? What they probably wanted is something more specific. 

Now let's take a look at a better requirement:
“I currently have a small hatchback and need to fit three kids (aged between 1 and 4), as well as the weekly shopping (about 10 bags) in the boot and still have room for the pram. I only have $20,000 to spend and I’d like something less than 5 years old.”

This is much easier to test and verify! We now have requirements that we can write test cases for. Our test cases would look something like the following:

  • Does the rear seating have enough room to fit 3 kids with car seats?
  • Does the boot have sufficient room to fit both a pram and 10 bags of general goods?
  • Does the car cost less than $20,000?
  • Is the car less than 5 years old?

We now have a clear way of evaluating what new cars will fit the user’s requirements. This means we’re now in a position to confidently present a solution and know it’s going to be what they want. In other words, a win for the user and a win for you.

Applicability to Web Development?

This also works in the world of web design and development. I often see poorly written requirements, which almost always result in the client not receiving the product they wanted. Trying to fix a problem or weak requirement exponentially harder at the end of a project rather than at the beginning. While it may delay the start of some projects, ensuring that you have good requirements before embarking is a critical step to save both time and money for both the client and the web design business.

The other point to make is that you need to ensure that only one test outcome can be produced. Lets take a look at a common request:

 “I want my website to be faster”

There’s a wide variety of ways that a test case can be written. Does 2 seconds quicker qualify? Does 50% quicker qualify? Does 60 seconds qualify? We have no concise way to test this requirement and it therefore needs to be updated.

Consider the following updated requirement: 

“I want my website to load on a typical 5mbit DSL connection based in Australia in under 5 seconds”

This is much easier to write a concise test case for (although not perfect!). We can clearly define a set of test parameter and there are tools available to verify this requirement.


Taking the time to write test cases for your project requirements at the very beginning of a project is vital to ensure you and your team stay on task, and on the right track. You'll minimise the risk of any major changes during the build phase and produce a product that meets (and hopefully thrills) your client. It's a simple idea of planning more, re-building less.

So, whenever you're looking at a project or a requirement, just remember:

"The key to a good requirement is if you can write a good test case for it"