Web Application Development Starts with Good Requirements
The importance of complete, consistent and well documented requirements when developing software such as cloud based web applications is difficult to overstate. There is no greater risk to such a project than incomplete, misunderstood, or under-emphasized requirements. Software requirements and the efforts undertaken to gather them are key to successfully understanding the user’s problems and addressing those problems in a way satisfactory to them. Without requirements, there is no frame of reference and no benchmark to measure success.
One of the most important aspects of web application design is the quality of the finished product. But how is that quality measured and who measures it? The answer to that question is simple: quality is measured by the stakeholders and end user’s and it is measured by how well it satisfies their needs. Those needs will be exposed via requirements and input that they provide to the development team. These requirements and input should be provided throughout the design and development of the software system. Without the path provided by this information, the development team will quickly run off track and provide a product that does not satisfy the user’s problems and needs.
Written requirements provide a common shared view of the system, the value of which cannot be underestimated. It is all too easy to make assumptions about the behavior and functionality of a system and one person’s view of correctness may differ from another. By creating detailed requirements, reviewable by all stakeholders, one can reach consensus and have a common framework by which the whole team can work towards. This is critical if the development work is to be outsourced, and if one wishes to be able to scale the development. If there is only one developer who is also the envisioner of the system, then one can sometimes get away with less stringent requirements, but if this is not the case and you have multiple external developers, this is a recipe for disaster. You would not consider constructing a new building without blueprints, similarly one should not consider constructing a complex software system without requirements.
One of the other less tangible benefits of the actual requirement gathering process, is that it actually makes you think of how the system should behave. It may seem that the operation of the system should be obvious, but along with the obvious needs there will be many other requirements that will be exposed by investigation of the problem scope the software system is intended to address and analysis of each of the natural, obvious requirements. Creating detailed requirements provides the rigor and framework to fully expose ALL the needs of the system. One can almost guarantee that by simply stepping through each part of the system and creating requirements, you will expose areas of the system that have not yet been understood, or you will realize that your previous assumptions may be incorrect.
The literature over the last decade clearly shows that poor requirements are the prime reason for project failure.
- 68% of IT projects primary cause of failure is poor requirements.
- Companies with poor business analysis capability will have three times as many project failures as successes.
- 68% of companies are more likely to have a marginal project or outright failure than a success due to the way they approach business analysis. In fact, 50% of these groups projects were runaway which had any 2 of: taking over 180% of target time to deliver; consuming in excess of 160% of estimated budget; or delivering under 70% of the target required functionality.
- Companies pay a premium of as much as 60% on time and budget when they use poor requirements practices on their projects.
- Over 41% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts versus the optimal organization.
This leads us to the question of how much requirements are needed, and what is the scope of the effort to generate them. Ultimately one has to consider that every operation, action, response to user input, has to be coded. If there is not an individual requirement governing how this should be done then you are leaving that choice to the developer and they may or may not implement things as what ultimately is required by the system. This means that if you wish to ensure correctness then each individual page element needs to have a comprehensive set of requirements associated with it. This is not trivial and it can be surprising how many requirements are needed, but consider that if the page element is visible to the user, then there is surely a segment of code behind it, and if you wish to ensure that that code segment does the right thing then appropriate requirements are needed.
So this gets us to the guidelines for what percentage of effort should be directed towards requirements. Although one should separate requirements from design, and a good requirement should never presuppose a design or implementation, there is also often overlap between the two, especially in web application development. This makes it a little more challenging to determine the exact overall percentage but as a rule of thumb one should be considering 15% to 25% of the overall effort directed towards requirement gathering. This does not mean that all this effort needs to be applied up front, or that this prevents you from employing an agile development methodology. This is not the case, effective requirement gathering fits very well into an agile model, indeed sometimes better as most agile development processes force involvement by all stakeholders in the requirement gathering process. It is fair to say that at least 10% of the overall development effort should be allocated to early requirement gathering. It is far more costly to fix things later in a project and the initial investment in requirement gathering has a very high ROI. Rule of thumb is that it costs ten times as much to fix an error caused by bad requirements post implementation than in the requirements stage, and a hundred times more if it gets into production.