Why is it so hard to find out exactly what is needed when designing changes to a system?

Requirements-Gathering-User-Experience-UX-Project-CartoonWhen adding functionality to databases I always like to dive in and start adding extra columns and new tables. But at some point you need to find out what is needed.

The process of gathering requirements that I have followed goes something like this.

My boss tells me that we need a system to solve x problem. This is the broad overview of what is needed.

Next I need to find out specifically how the system is being used and what things need adding. Discussing the specifics with my boss often results in a high level of confusion. I always try to speak with the users that will be using this system on a daily basis. If I create something that isn’t liked people will avoid using it and it won’t solve the original problem so I always think it is very important to speak to the day to day user.

After I have an idea of what is needed, I build something. Once I have something that sort of works, I will try and demonstrate this to the user to gather feedback. This feedback is invaluable as it will often reveal if I am going in the right direction and reveal missing requirements that need to be incorporated in the finished solution.

I will often repeat the last stage a few times especially if there is a big change needed, once I am happy I will demonstrate to my boss before deploying the solution.

After deployment there is often a period of fixing issues and gathering feedback before I can consider the project finished.

This whole process is very time consuming as there is a period of changes being tweaked back and forth following feedback. A better way is to gather a detailed specification of what is needed and work towards delivering that.

This post has already been read 1091 times!

Simon Foster on GithubSimon Foster on LinkedinSimon Foster on Twitter
Simon Foster
Web Developer
I have worked in SysAdmin and IT Management but now work as a Web Developer. I love everything IT related and I am trying to learn as much as I can especially about DevOps. Why not follow me on twitter?

2 thoughts on “Requirement Gathering

  1. Great post! I agree, feedback from the customer is essential. Very often, what the customer says he wants is very different than what he actually wants. Sometimes that is due to not getting detailed enough information from the customer, and sometimes the customer simply changes his mind.

    Having a perfect specification is always the ideal, but in practice I have never seen a perfect specification for a complex application, and I have been lucky enough to have worked with some very good business analysts over the years. The English language was not designed to be unambiguous. Expressing a design in written form in such a way that there can only be one interpretation is very difficult indeed.

    So I am in favour of the Agile approach. Start off simple and get the customer to feedback on the work throughout. The customer appreciates that you are working to produce the software that they want, and you have the satisfaction of knowing that you are building the right thing.

    • Thanks for the comment. The only way I can get things done is to start small and build on this, not really thought of this being Agile before

Comments are closed.