Developers often tell me that the requirements they receive are usually vague and unclear. Another common complaint is that the requirements change midway, causing them to get stuck. Additionally, sometimes the deadline is set before the requirements are even clear. In this article, I will try to help you solve this problem.

Embrace it!

You will have to embrace the fact that the requirements will often be vague and unclear. It is our job as engineers to make them specific. This is a problem that we have no control over.

The requirements usually come from people who are non-technical or may not know about the internal implementations of the project. So when they explain the requirements, they will speak in high-level language.

Another case could be that the requirements may be passing through multiple people, and by the time they reach you, important details may be missing. Just like the Chinese whispers game.

"Complete the circle" framework

The "Complete the Circle" framework is a simple method I developed to turn vague, ambiguous, or unclear requirements into very specific ones.

Let's imagine a full circle represents the requirements or the scope of the feature. This is the goalpost, or the final state you want to achieve.

But in real life, this is not the case. You will only receive an incomplete circle as the requirements.

Some of the incomplete parts of the circle are the details missed by the person giving the requirements. They may know the requirements but forgot to tell you, or it got lost in communication. This part of the circle can be easily completed by asking questions. Once the person answers the questions, you can complete this part of the circle as well.

Now, the circle is still incomplete. This is the area where the person giving the requirements might not have a clear answer. Maybe someone else has the answer, and we can complete the circle. If nobody has the answer, then as engineers, we should come up with some assumptions or solutions. We can decide to raise an error in this scenario, handle it like a previous case, or let the system break. Depending on the use case or feature, you can propose some solutions here. This is how you can get to the final state.

Documenting

Once you have determined the scope of work, it is very important to document it. If you are using Jira or similar tools, the best place to add this information is in the comments of the tickets. You can document things like -

1. What you are going to do?

2. What you are not going to do? like if there are any edge cases that you will not be handling.

3. Include any assumptions you made for solving specific items.

4. Add some example user flows.

Tag all the important stakeholders here and get their approval.

Listening.

Communication is more about listening. You should not listen just to reply. We are always eager to build, which is great, but it is very important that we actually build what is needed.

During requirement gathering sessions, I only listen and write down what the person is saying. I do not reply to anything. There may be things the person says that do not make sense or seem contradictory, and you might feel the urge to interrupt, but don't do it. Sometimes, when you interrupt, it can break the other person's train of thought, causing them to miss important points. Even if the person stops, you can still ask if there is anything else they want to add or if they missed discussing deadlines or case A. You want the person to share everything they have in mind.

Once you return to your whiteboard, review the notes and create questions for clarification. If some points seem contradictory, address them. If any points are missing, ask about them. By doing this, you minimise the chances of missing important details.

Requirements changing mid way?

Always assume that the requirements will change midway. Even if someone tells you that these are the final requirements and nothing will change, listen to them but remember that changes are likely. It's better to be prepared.

You can design your solution so that in the future, if you need to add, remove, or update something, it will be easier to do. It's better to keep your options open.

Example: Let's say you are building a blog application and you need to add drafted and published states for a blog. The person giving the requirements might say there will only be 2 states for a blog. If you decide to add a boolean in the database called is_published, where true means the blog is published and false means it is drafted, this will work.

However, if in the future they want new states like archived or under review, you will not be able to accommodate it easily. So, it would be better to use an enum or something similar, where new states can be added easily, rather than using a boolean.

Get feedback fast!

It is very important to get feedback quickly from stakeholders. You don't want to build something only to find out later that it isn't what they wanted.

You can create UI wireframes or diagrams to validate this. Alternatively, you can develop the MVP first and get it validated.

Communicate blockers.

If you realise that there are blockers, it is better to communicate them as soon as possible. You can mention them on the ticket or discuss them during the stand up call. You want to make everyone aware of this.

This is important because if a deadline is approaching, expectations can be set correctly, and there will be no surprises at the end.

Huge task with a deadline!

If you have a task that you know will take 4 weeks to complete, but the deadline is in 2 weeks, you need to adjust the scope or ask if the deadline can be extended.

To adjust the scope, identify the less important parts that can be removed. If some parts cannot be removed, consider ways to complete them faster, such as hard-coding or using a dummy JSON instead of building a full API, etc. You can identify the core part of the feature and complete that first and the rest can follow.

Building trust

Communication is key in software engineering. Most problems stem from miscommunication.

If there are two developers—one technically very strong but poor at communication, and the other technically good but excellent at communication—the second one will perform better. This is because the first developer might build something that doesn't meet the actual requirements, while the second one always knows what to build and what the expectations are. This will automatically build trust among the team for the second developer.

Try to be the second one. Thanks for reading!