By: Michael Cooper, Appnovation Frontend Dev
When it comes to completing large software projects, one of the most important factors in achieving success is to lay the requirements out clearly. Unfortunately, this is a lot easier said than done. This article will outline a few of the ways that requirements affect development and what happens when they aren't clear from the onset.
Preparation (presale/predevelopment):
In the early foundational stages of a project, it is the objective of both the client and the team to try to come up with a set of technical requirements to define what a piece of software should do and it how it should work. This step is integral when it comes to accurate estimates and saving money during the development process. Since there is a constant flow of communication between the client and the developers, clarifications are fairly straightforward and edge cases can be covered without issue. If these are missed until later, it can disrupt both parties adding additional costs and throwing off previous estimates.
Feature Development
This phase is the most dependent on strong, detailed requirements. Developers will use it to frame every decision they make when it comes to constructing code. On top of that, it is a basis for communication between non-technical staff that allows a common context for how things should be done. Detailed requirements mean fewer decisions for developers to make (that could end up wrong in the client's eyes) and less time used on meetings and bothering clients for more details.
Quality Assurance
The entire basis for performing accurate and complete Quality Assurance testing is the initial requirements. The more in depth those requirements, the easier it is for the testers to check off their acceptance criteria, without having to clarify with a developer or project manager.
Maintenance
In most cases it is not possible for a project to reach maintenance without clear requirements as otherwise it would not be possible to say when it has been completed! However, once in this phase, if issues arise or if new functionality is requested, the original requirements can be used as source material to determine how best to implement new features as well as understand what the feature will be implemented with. In the case that no formal documentation is written alongside the project, the requirements can act in place of it.
Ultimately, the more time spent on determining clear, detailed requirements at the start of a project, the more time and money is saved in every subsequent phase.
Share this Blog with colleagues
