There is a big misconception of what an early career software developer thinks a software developer does. They tend to think all a software developer does is write code and that’s it. Although software developers do spend a fair amount of time writing code it is not the only thing they do. For example, understanding requirements and what needs to be built is also part of software development. Understanding requirements is something early-career developers tend to neglect despite it having a crucial role in the software that they build.
In this post, I will be sharing 4 reasons why understanding requirements is important for software developers.
1. Build the Right Things
It is very difficult to build something when you’re not clear what you’re supposed to build. An issue that inexperienced developers have is that they start interpreting things their own way and try to fill in the gaps with assumptions. Then after a week of work, they find out what they are building is not remotely close to what is wanted. Then that is when the discussion about the requirements happens to clarify things and the developer ends up starting from the beginning again.
Instead of going through such a scenario, it is better to understand what you’re building upfront. If it is not clear, don’t start building anything. Ask questions and fill in all the unknowns you need answered then start building. If you have questions mid-way then stop and have it answered before you continue building.
2. Understand What Problem You Are Trying to Solve
Building software to meet some requirements passed down to you doesn’t mean you understand the problem you’re trying to solve. Although your software meets the specification, it could actually not address the problem fully. That’s because to really build software for the user, you need to be able to empathize with the troubles that the users are having. For example, adding a new option in a clustered menu isn’t going to help the user find it. It might meet the specification of adding a new option to the menu, but as a user, it wouldn’t matter if I can’t find it in the first place.
So, if the problem was a helpful option that wasn’t available before and now it is to add a way to access it then putting it in a cluttered menu is not going to work. Although it is somewhere and available, it is not discoverable. So now knowing the problem, you might think since this new option is only related to X, it might be better to show it after the user selected X. That way the location for the option is more discoverable and relevant.
3. Helps With Prioritization
The goal of a requirement is to address a problem. In most cases, it is a pain point that the user of the software is experiencing. However, when you’re not sure what problem a requirement is trying to address it can make it difficult to decide on the priority.
If you know the problem a requirement is trying to address then you can prioritize it based on impact for the user and technical feasibility. For example, give a higher priority to the requirements that will yield a high impact for the users and a low effort on the technical side. Leave the low impact and high level of technical effort ones for last.
4. Helps Negotiate a Balance Between Need and Technical Limitations
Sometimes, you’ll come across situations where a requirement doesn’t fit in with the way how the project is built. That may mean a massive engineering effort to do one thing for little gain. Naturally, this would make you want to search for an alternative solution. But without understanding why the requirement was needed in the first place, it is difficult to arrive at an alternative solution. When you understand the reason for the requirement, it will allow you to offer alternatives to satisfy the need and fit in with the project.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What are your experiences with software requirements?
To get in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.