The Art of Requirements Gathering
Posted in Project Managment on October 25th, 2010 by Rachael
“The best software practices are useless if they are focused on implementing the wrong functions” – Watts S. Humphrey, 1989.
Requirements play many roles in the project; they encapsulate the client’s needs, create a contract between developers and the client as well as provide a basis for system and acceptance testing (Humphrey, 1989, p. 233). Any one involved in the development of a large project will agree that poor requirements gathering leads to problems later in the project lifecycle.
At Kintek we know that flimsy requirements can lead to rework in the project which costs time and effort, and subsequently money (for both parties!). For example, we often get clients who want simple design and content changes made to their pre-existing websites. Most of the time the client knows what they want and we completely meet their needs. However, sometimes we get clients who don’t really know what they want and ask us for our input. Again, this usually works well, however once in a while we go away do what we think is correct, and the client completely rejects our ideas because it wasn’t what they had in mind. This process may swap back and forth for a few iterations before the client is finally happy.
We can’t blame the client for not knowing how to express their opinion; we should be the one forcing them to specify what they want and then refining the requirements into something we can work with. It is our job to either do what you want and find out what you want. This is why at Kintek, we will ask many painstakingly obvious questions about the way you want your website. We do this because we want your website to be exactly the way you want it. If you want to know more about how we design your website, visit Our Process.
References
Humphrey, W., S. (1989). Managing the Software Process: Addison-Wesley.
