Poor Requirements – What impact do they have?

Posted by Tony Higgins on May 15, 2012

In the previous blog post, Poor Requirements – What are they?I discussed at a high level what constitutes poor requirements. In this post I’ll point out the impacts that poor requirements can have, both to the IT group developing the application and to the business side who needs the application.Poor requirements are a well-known key root-cause for challenged and failed software projects. The figure below illustrates some of the principle impact areas both for the IT group who is developing the application, and for the business whose operation depends on the application. (Note that this is intended to cover the most common impacts and is not an exhaustive list)

IT Pain

Poor requirements have a very real and significant impact on application projects:

Late Product Delivery:

Requirements are the ‘Blueprints’ that virtually everyone on the project works from. When those blueprints are flawed, the work-products of all team members who depend on them suffer. Poor requirements lead to poor designs and tests and depending on when these issues are uncovered, development and testing rework is the result. This, along with the requirements revisions themselves, contribute to late product delivery.

Poor Product Quality:

There is never enough time to completely test every scenario through an application. For this reason, testing must be ruthlessly prioritized to focus on what’s important and must be as efficient as possible to perform the maximum amount of testing. The rework along with resulting wasted test runs severely reduce the overall amount of testing that can be done. Testing priorities are also at risk when requirements and designs are in flux, so not all testing effort is necessarily focused on what’s important. Depending on how poor the requirements are that drive this inefficiency and mis-prioritization, the result can be poor product quality.

Degraded Design and Documentation Integrity:

Great designs are extensible, maintainable, configurable and more, and they consider a wide range of factors, use proven patterns, and involve a high degree of skill and experience on the part of the designer. When requirements are poor a series of changes occur as the flaws are uncovered. This can incrementally degrade the design, chipping away at its integrity with each change, until it has lost much or most of these desirable characteristics. Worse still, this affects not only the design itself but related assets like documentation as well. The net result we call degraded design and documentation integrity.

Invalid Features Delivered:

For those requirements flaws that are not uncovered during development or discovered too late to change end up as invalid features being delivered. These could be features that are out-of-scope or simply incorrect features which must then be handled by workarounds.

Business Pain

As indicated from the diagram, late delivery of the product, poor product quality, degraded design and documentation integrity, and invalid features being delivered, all have direct business impacts. The emphasis and severity of course varies depending on the situation, but none of it is positive and it can be severe. These results impact customers, end users, the business results (e.g. marketshare, profitability, etc.) and business aspects of application development and operation including development costs, maintenance costs, administration costs, related whole-product work, project failure or cancellation, and negative impact on application portfolio backlogs. As mentioned, this is certainly not an exhaustive list but does capture many of the common impacts and also illustrates the ripple-effect of poor requirements. Now that we’ve explored the impacts of poor requirements, in the next blog post we’ll look at what causes poor requirements in the first place.