As we discussed in our last post, requirements gathering and analysis are the critical first steps in a successful and well-organized waterfall development process. Taking enough time and effort to execute these steps properly ensures that the rest of development will be on-track and to the customer’s expectations (as much as possible).
The most obvious reason for gathering and analyzing requirements properly is to avoid the scenario where you and your team show a nearly finished product to the customer only to find it doesn’t meet their needs or expectations. Necessarily, proper requirements gathering forces you to deal with these potential problems during the initial phase.
More often than not, issues during this phase come from the customer. As TechRepublic notes in this article, customers often don’t know exactly what they want and need. This leads to ambiguous requirements, and without clear requirements there’s no telling if the product developed will be satisfactory to the customer.
Another frequent issue that stems from the same cause is requirements changing during development. You’ve seen this one play out in any number of ways – the customer sees another product with features they like, they preview the product in development and decide something needs changing, or they just change their mind out of the blue.
Through the requirements gathering and analysis phases, these problems can be avoided. Proper and thorough communication with the customer is at the root of eliminating these issues. As the developer it’s your job to help the customer define exactly what they need and desire out of the product. As Martin Bauer puts it in his article, “There’s little use writing requirements if they are not an accurate reflection of what the client wants.”
Sometimes, getting the requirements straight is a matter of meeting with the customer multiple times and/or with multiple people, such as stakeholders. Discuss the full timeline of the project; not just the timeline to the final delivery, but milestones and progress checks along the way. This allows you to avoid spontaneous (major) changes in requirements – decide together with the customer that no changes may be made past certain milestones, etc. With proper communication, the customer feels involved and in the loop on development – avoiding unwelcome surprises later.