Effectively Estimating and Understanding Software Requirementsby Applied Informatics
One of the hardest things to do as an engineer is learning how to effectively understand and properly estimate software requirements. This is something that cannot be learned from a book or taught in a class and can only be learned from the tried and true method of trial and error. In this article I will break down and detail the three simple steps I have learned over the years that have, at least to some extent, allowed me to somewhat understand this every day challenge.
Understand your team’s ability
The first requirement for properly breaking down and understanding requirements is understanding you and your team’s ability for turning out production quality code, this means code that has been thoroughly battle tested through multiple sources and ready to hit the open seas without worrying about it sinking once the first storm hits. This is without a doubt the most critical part of understanding software requirements and easily the most overlooked, simply because many a time engineers tend to only think about the actual writing part of the software and not the entire process it will go through.
For example, if we have a piece of functionality that needs to be added, it is extremely simple and as an engineer you know logically you can write this code in about an hour or less and come back with that time to the client. Two weeks go by and you are still testing this simple piece of functionality and the client is asking why it is taking so long and this simple one hour task has now turned into a 2 week long nightmare that is keeping you up till 3 am! Granted this is somewhat of an extreme case scenario, but it happens quite a bit more than it should.
Know the project and client
The second part is understanding your client and project as a whole from not just an engineer’s point of view but also the end user. This means that you don’t simply look at a set of requirements as a bunch of ‘if and else’ statements but as the final product. Think about how someone will logically interact with the software and try to understand how, where, and why certain things will behave, look for flaws and impossibilities that exist. Understanding your client, regardless of who it actually is, is extremely critical, because, if you know that every time you build some functionality it gets changed five more times before the final software is shipped, you know to account for this when estimating a requirement.
Breakdown project specifications
The third part of understanding software requirements is simply just breaking down every piece of the software into the smallest possible form. For example, given a requirement specification that is 600 pages long would seem like an impossible task to estimate and looking at it as a whole it is. But, if you take that same 600 page spec and break down each and every piece of functionality into hourly and at the most daily tasks, it makes it no harder than understanding a two sentence requirement for adding dates to a blog post. The key is to look at each and every piece of requirement individually while still retaining the mentality of how everything is eventually going to connect.
The final thing to note when estimating and understanding requirements is whatever time you think it will take, multiply that by about 3.5 because no matter how good you are at understanding your client and the software something may go wrong. Never be afraid to send out an estimate because it seems high and always follow what your gut tells you, because usually it is right and you don’t want to be sitting at your desk 6 months later telling yourself ‘you should have‘.