Poor Requirements - What’s the Cause?

In the previous blog posts we discussed what constitutes a poor requirement and what the IT and business impacts are, at a high level. In this post we'll take a look at the classic causes of these issues. The diagram below builds on the diagram shown in the previous blog posts by adding ‘causes’ in a column on the right. 

Poor requirements can stem from a multitude of causes, but some of the most common are listed in the diagram and described here:

• An inability to share Requirements, or reuse requirements, means that all the work that went into defining that requirement in the first place has to be repeated a second time which not only wastes time but introduces the possibility of errors and inconsistency.
• Inadequate stakeholder involvement is one of the most-reported causes of poor requirements from the beginning during requirements elicitation, through validation, and later while the requirements are managed throughout development, test, and delivery. In all these areas of the requirements lifecycle stakeholder involvement in crucial and when it is lacking, requirements quality is at risk.
• When requirements are not aligned with business needs the resulting development and testing effort is not optimal and may be wasted entirely once the misalignment is noticed and rework occurs.
• When requirements are not cross validated with the other requirements there is a huge risk of redundancy and inconsistency among the set.
• Most requirements are dependent to some degree on other requirements which need to be taken into account when working with requirements, implementing changes, and otherwise managing them. When not recorded or simply overlooked, these missed dependencies will result in errors.
• The purpose of validation is to ensure, with stakeholders, that the requirements are complete possess the qualities described in the first blog posting of this series, both individually and as a set. Issues not detected during validation means that poor requirements are being delivered to development and test. Inadequate validation can be due to a number of reasons ranging from inadequate time or involvement, to poor process or tool support.

There are a number of issues that don’t necessarily drive poor requirements, but cause related issues:

• Tedious error-prone test authoring is inefficient and wastes time, and can result in test assets being flawed and having to be reworked. Wasted time and inefficiencies are also caused by poor test prioritization, tedious error-prone document authoring, disconnected toolsets, and tool workarounds when they don’t directly support the process being used.
• Misunderstanding requirements, even when the requirement themselves are of high quality, is yet another source of error that drives incorrect designs and incorrect tests.
• Inadequate coverage and scope control means that there’s no guarantee that all needed features will be built, or that extra features that aren’t needed show up in the finished application.
• And finally, complex tool administration contributes to overall cost of development and maintenance.

As stated multiple times before this is not an exhaustive listing of causes and effects of poor requirements and related issues. It does however capture many of the common ones and can also serve as a brainstorming tool for discovering the specific ones you may be encountering.

Stay tuned for the next blog post in this series which will show proven solutions for these ailments.

---

Poor Requirements – What impact do they have?

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.

---

Poor Requirements – What Are They?

On application projects requirements are the 'blueprints' for what gets built and tested, so when the blueprints are ‘lacking’the project and the resulting application suffer. We’ve all heard the statistics on software project challenges and failures whose cause can be traced back to poor requirements - but what exactly are ‘poor requirements’?

There are many sources that try to dissect and group requirement faults into convenient categories, but after reading several I would categorize them as ‘missing’, ‘irrelevant’, or ‘bad’ requirements. To help explain I’ll first propose a simple notion of requirements: requirements exist to constrain design choices. With a requirement like ‘build me a vehicle’ pretty much anything from a bicycle to the space shuttle could be delivered and technically would satisfy the requirement. Adding more requirements like “the vehicle should float”, “the vehicle should seat four people”, “the vehicle should have two oars”, “the vehicle’s total length should be between 12 and 14ft long”, “the vehicle should be transportable out of the water using a trailer towed by Honda Civic”, we constrain the possible design choices and are more likely to get what we actually need.

Missing Requirements: Given the large number of requirements you’ll find on a typical software project it’s not surprising that some get overlooked no matter how diligent the team is. Missing a requirement basically means it is left up to the designer to decide on that aspect of the solution. In the example earlier the client neglected to state a requirement that the vehicle needs to support an outboard motor at the rear of the boat. Whether they get this or not is, to a degree, up to chance. It depends on whether someone notices the missing requirement in time, or whether the designer simply makes that design choice based on experience, preference, available components, etc.

Irrelevant Requirements: Irrelevant requirements aren’t ‘wrong’ but are redundant with other requirements or don’t help to further ‘constrain’ the possible design choices. In very simplistic terms it’s like having a requirement in the previous example that states “the vehicle will be able to move”. This is inherent in the definition of what a vehicle is and so is unnecessary. The impact of irrelevant requirements is largely the drag they place on the process by having to be considered, analyzed, managed and dealt with at every step, wasting time and energy.

Bad Requirements: Bad requirements can be at the level of the individual requirement, or the set of requirements as a whole. It means that the requirement (or set) is lacking in one or more of its necessary qualities. Again there are multiple lists of the qualities requirements should have, but I’ll use those promoted by Karl Wiegers [2]. However I will divide them into two sets – those that apply to individual requirements and those that apply to the set of requirements (See Fig2).

For example an individual requirement such as “the vehicle should be able to travel at 70knots” wouldn’t be feasible. An additional requirement saying “the vehicle should allow for three passengers to row simultaneously” would mean the set of requirements is inconsistent because we already have a requirement stating there will only be two oars.

With this description of what poor requirements are, the next blog post will illustrate the impacts that poor requirements have on both technical and business stakeholders.

Key Sources:

1. Evaluating Requirements, Richard Griffiths
2. Writing Quality Requirements, Karl Wiegers
3. Mastering the Requirements Process, Suzanne Robertson, James Robertson

---

Average 34% Projects in Backlog. Are you Average?

Throughout the 1990’s and 2000’s enterprises undertook many large and complex projects that often spanned multiple years before reaching end users. The time it took to define the requirements was measured in months and sometimes years. Today’s business environment is fast paced, highly competitive, web-enabled, mobile, and increasingly social. Add to this the extreme pressures of competition, cost reduction, and regulatory compliance, and the long delivery cycles of the last two decades have become unacceptable to business stakeholders.

With 34% of approved projects now sitting in backlog and IT unable to respond quickly enough, demand for cycle time reduction has reached record levels. Immediate business impacts include lost opportunity to drive top-line revenue and reduce expense, and ultimately lost competitive advantage and long-term business viability.

Download Blueprint's new paper, define better, together, that shows how business and IT collaboratively define applications, improve requirements and unblock the backlog.

---