Change is hard. Project teams frequently resist the addition of new processes and procedures, and one process frequently fought is the creation and review of requirements. The reaction is understandable—it’s most likely resistance to creating more work in the midst of already tight schedules. On the other hand, some of the consequences of not having requirements or having poorly thought out requirements are:
- Developers guessing how the application should behave
- Secondhand guessing: testers guessing how the developers guessed the application should behave
- Customers not liking or having difficulty with the product
- Spending time and money reworking a product to remove ambiguities
- Inability to map test case to requirements, which can lead to not really knowing if the testing is complete
The benefits of creating requirements and making them clear in the first place are numerous. Here are just a few:
- Understanding the purpose of a new feature
- Understanding the workflow of a new feature
- Understanding the options of a new feature
- Understanding how a new feature integrates with existing functionality
And that’s just the beginning of what ultimately amounts to a little time spent upfront for maximum gain and minimizing stress on a project.
Creating requirements does not have to be an exercise in torture. Even the most basic requirements list is better than no requirements at all. Whenever there is functionality without requirements, developers and testers will make assumptions on how each thinks the functionality should work. Those assumptions may not match the intended behavior. By at least starting a list with the most basic of the requirements, early misunderstandings of what is expected can be avoided.
Additionally, the more people that review the requirements as early as possible, the sooner questions about functional behavior and whether certain functionality is even possible can be raised and potentially save large amounts of time and money. Reworking requirements adds delays and costs to any project, so the better the requirements are to begin with, the more efficiently the project schedule and budget can be maintained. Reworking code over and over and the subsequent testing of that code can add even more costs and delays until the project team can agree on the desired functionality. The earlier everyone has the same understanding of what needs to be done and the desired outcomes, the more quickly a project can progress and the more quickly new personnel can get up to speed on what they need to do to help complete the project.
When requirements are organized well and are succinct and clear, it is easier for developers and testers both to meet those requirements and map specifications and test cases to those requirements and improve the product quality from the beginning. By having better quality early on, the odds of getting a project completed on time and on budget are greatly improved.