Requirements Engineering for Website Developers

Reading Time: 5 minutes

As programmers we always strive for the best product possible for our clients. The gap in understanding between client and developer is a common issue in the industry. Non-technical people will have certain hidden expectations about what their product should do. We can use requirements engineering to ensure we understand fully what those hidden expectations are and whether they should be within the scope of the software or website.

#1 Set Out Clear Roles

At the 11th hour of the project you as the developer are responsible for this project’s completion and that’s when a clear set of requirements are so important. So, let’s rewind to the beginning of the project. Before any code is written it is important that your client trusts your expertise in this area. If they are under the impression that they are commanding the development of the project or extremely disinterested. Then it’s down to you to make the roles clear. You are the development expert and they are the domain expert. 

Their role in this project is to provide you with knowledge. Knowledge they have about the end user in order to write a concise list of requirements. Now, as you will have probably experienced, it almost never happens like that.

Here is a list of responsibilities that will need to be carried out by someone in order for the project to succeed. 

Responsibilities for the domain expert include:

• Supporting the definition of requirements for the project
• Setting out use cases on behalf of the end user
• Validate the requirements of the project and agree to the deliverables
• Support the team throughout the project by providing insight and answering questions
• Approve or obtain approval when requirements are delivered
• Support the change in requirements as the project progresses (If needed)
• Be an active supporter of the project by engaging in meetings and demonstrations
• Respond to communications in a timely manner so as not to hinder process and frustrate deadlines

If the client is unwilling to take on certain responsibilities. Then it would be preferable to the project to have a discovery phase with a product manager. This allows you to garner the required information to fulfill these responsibilities.

#2 Make the client a part of the process

As you’ve probably gathered, a great project requires input from the client throughout the lifecycle of the project, not just at the beginning and end. As a programmer, it’s so disheartening to realise that the project you’ve been working on for weeks doesn’t meet the needs of the end user. The easiest way to mitigate that is by asking a lot of questions. Once you have a concise list of requirements for the project now you need to interrogate these requirements to confirm their validity and importance.

Not only does making your client a part of the project make the end product better. That continued conversation means that your client is not only invested in the process but more likely to be understanding. They will work with you on solutions when something unexpected may occur. It’s harder to understand why a project needs to be pushed back 4 weeks when you’ve had no contact with the team.

I’m not suggesting here that you talk with them about the minutiae of what you’re doing. No one needs that amount of detail. However, discussing project direction, readdressing importance of features and progress updates. These are all key to keeping client trust and optimal engagement.

Ensure that any actionable outcomes from conversations had are added to the requirements and deliverables. The client can then reapprove those changes.

#3 Separate Deadlines

You may not be the project manager but you are the person who is going to be pushing this live with a looming deadline. All too often a project is taken on where someone in the pipeline takes longer than anticipated. This leaves you with less time to work on the project. This doesn’t ultimately work and leads to a grave amount of frustration. Also with you being the last one in the production line with the least amount of time. 

In order to counteract this issue. Using different deadlines for the project ensures the client’s expectations are met and you still have the amount of hours required to comfortably complete the project. I believe deadlines are good if the expectations are reasonable. However, arbitrary deadlines placed on a team that only one person ends up being responsible for just doesn’t work.

You might not consider this to fall under requirements engineering. I would ask you to just consider that ample time to code the product is a constant requirement of every project you do.

#4 Versioned Deliverables

We’ve all been in the room when a client has come in and asks for a huge project. That inevitably leads to a massive brief or worse still a vague brief promising to do all the things. Requirements engineering tells us that we first need to ascertain a concise set of requirements and prioritise them. When this leads to a long list that could take months of development time we need to ask ourselves the important question. How do you eat an elephant? The answer is; one bite at a time. When taking on a project of this size. We need to review the feature set with the client to build up what is called a minimum viable product (MVP). 

Basically what an MVP boils down to is one question. What are the least amount of features this product can reasonably launch with? It’s an important question. Because the ability to deliver this product in a timely manner and add to it overtime allows the client to accrue value from the product earlier. It also allows the client to change their mind, add new requirements, reprioritise and react to the evolution of their product.

If you would like to add/update anything regarding requirements engineering in this blog post. Please comment below.

Thank you for taking the time to read this, I hope that it helps you in future projects. I will be adding a new blog every week!