# Bad Requirements

## Summary


It's customary to develop product requirements before they're designed and implemented. A good requirement is clear, correct, complete, concise, well-structured, feasible, traceable, and verifiable. A bad requirement is just the opposite.  Bad requirements (aka poor requirements) can arise when requirements development is not done properly. 

Bad requirements are costly, particularly when they're discovered late in the development lifecycle. Many software defects can be attributed to bad requirements rather than implementation bugs.  

This article shows examples of bad requirements and how they can be improved. It shares some words and phrases to avoid when describing requirements. By following some best practices when developing and writing requirements, bad requirements can be avoided.

## Discussion

### What's a bad requirement?

Requirements are bad if they're ambiguous, incomplete, inconsistent, incorrect, outdated or technically infeasible. Sometimes they're written in highly technical jargon that only a few understand. Some bad requirements describe system internals without relating them to visible interfaces or scenarios. 

Badly structured requirements are hard to trace. Multiple requirements written as a single descriptive sentence is also problematic. Unstructured requirements are hard to verify or validate. Requirements not essential or relevant to the system are equally bad. This practice is sometimes called "gold plating". 

Some bad requirements describe how to build the system, thus imposing inappropriate constraints. Others describe system operations. Instead, they should set the expectation from subsequent phases (design, coding, integration, testing). 

Requirements without suitable metadata is also a problem. Priority, status, estimated cost/schedule, and unique identification number are examples of metadata. 


### What's the cost of bad requirements?

Bad requirements lead to more work, rework, and lower morale. This in turn causes cost overruns, delayed deliveries, missing features, and poor quality products. Requirements that impose constraints or describe a solution prevent innovative thinking. When requirements are not traced, impact analysis becomes difficult. Lack of requirements tracing is a technical debt. It becomes difficult to evolve the system. Highly volatile requirements incur expensive rework. 

One study found that requirements and design phases contributed 64% of defect costs. Engineers spent 19 hours per day addressing requirements-related defects. Test engineers spent a lot of time clarifying requirements. As much of 10% of testing budget could have been saved with proper requirements engineering. 

It's been found that fixing a requirements defect during integration and testing is as high as 78 times more expensive. Other studies showed that defects discovered in the field cost 50-200 times more. Rework is 50% of total development cost. 50% of defects and 80% of rework effort are due to poor requirements. Poor requirements have caused 40% of accidents in safety-critical systems. 


### Could you share examples of bad requirements?

Here are some illustrative examples: 

    + *The system must have good usability*: It's vague. It's unclear how to measure usability. Each user group or role interacts with the product differently.
    + *Response time should be less than 5 seconds*: Five seconds is an objective measure but there's no context. Product feature, scenario, system state or configuration are examples of context.
    + *The system has to be bug-free*: No system can guarantee this. Instead there should be well-defined processes for testing and change management.
    + *Round-the-clock availability*: Unrealistic and could be too costly in practice. Requirements should balance business, user, technical, and economic perspectives.
    + *The system shall work just like the previous one, but on a new platform*: Requirements can't easily be transferred across platforms or technologies. Newer technologies often offer better ways to implement features.
    + *Reporting*: Too brief. It's unknown what reports should include, the level of detail, who'll read them and towards what objectives.
    + *Authenticate with user IDs and passwords*: Imposes a particular solution rather than specifying a requirement.

### What words characterize bad requirements?

Even when requirements are correctly identified, they may not be written down correctly. Engineers are not necessarily good at writing. The choice of words matters. Words that're not precise enough should be avoided. One study grouped these and called them **requirements smells**. Here are some examples:   

    + **Unquantified**: all, always, every, never.
    + **Ambiguous**: most, many, several, some, sometimes, usually, normally, ideally, optionally.
    + **Vague Adjectives**: easy, appropriate, user-friendly, fast, graceful, flexible, versatile, efficient, robust, adequate.
    + **Vague Verbs**: handle, improve, provide, reject, support, maximize, optimize.
    + **Implied Multiple/Missing Requirements**: and, another, etc., other, including, not limited to, such as, including, for example.
    + **Pronouns**: it, this.
    + **Implied Uncertainty**: should, can, could, if possible, may.Context is important. Consider the use of "and" in "DADS shall display the number of requests pending and requests processed." There are two requirements here. They must be separated. However, the following is a single requirement even when "and" is used: "DADS shall display the combined number of requests pending and requests processed." 


### How can I avoid bad requirements?

Requirements development should involve all stakeholders, including testers and operational experts. Discussions should promote diverse perspectives. Involve all user groups. The idea is to fix problems early on. Formal inspections and informal reviews should complement each other. 

Techniques for functional requirements may not suit non-functional requirements. Use different techniques to elicit and develop requirements: storyboards, interviews, prototypes, use case diagrams, class diagrams, data flow diagrams, state transition diagrams, etc. Consider both normal and abnormal scenarios. Use these techniques to identify and analyze requirements. 

Use checklists and templates. Use tools to identify ambiguous words and phrases. Use tools to structure, track and trace requirements. Store requirements in a single repository. Link models and diagrams to requirements. Store metadata. Tools with these capabilities include Borland CaliberRM, IBM/Rational's RequisitePro, and Telelogic's DOORS. 

Requirements and even project scope can change, particularly with long-running projects. Requirements engineering and project schedules must embrace and manage this change. Adopt iterative and incremental development methodologies.  

## Milestones

1990

The U.S. Government Accountability Office recognizes that poor requirements are causing projects to fail. Through the 1990s, studies identify poor requirements as the main cause of missed deadlines and cost overruns.  

1993

Hooks proposes the following uses for words: "shall" for requirements; "will" for statements of fact; "should" for goals. In 1995, the MIL-STD 961D standard reserves the word "shall" to identify requirements. Words "will", "should" and "must" can be used in descriptions but not in requirements. 

1996

Alvarez et al. apply syntactic, semantic and domain analysis to specifications. While they develop some tools to do this, the focus of their research is to develop **metrics** to identify poor requirements. In the late 1990s, a similar research at NASA results in the development of the *Automated Requirements Measurement (ARM)* tool. This tool analyses text structure, specification depth and readability. 

2005

Arnold and Martin give the example "The system shall transmit data at least 100 kilobits per second." If the system delivers 99.8 kbps, it clearly fails the requirement. This binary approach to defining requirements unnecessarily constraints the solution space and forces designers to make the wrong trade-offs. Hooks observed this in 1993 and recommended the use of allowable tolerances. 

2006

Kasser et al. propose a way to define **metrics** for requirements. They adapt metrics used to assess code quality and apply them to requirements. They also consider metrics or indices commonly used to assess readability of English text. They use the presence of poor words to compute what they call the *Figure of Merit (FOM)*. These ideas are incorporated into tools named FRED, TIGER and TIGER Pro. 

Sep  
2009

The Requirement Analysis and Modeling Process (RAMP) project is started as a collaboration between academia and industry. It's objectives are to improve the writing of requirements in natural language, requirements analysis and context analysis. This research finds a gap between theory and practice. There are problems in formalization and consistency. Many requirements actually describe solutions. 

2010

Hooks observes that people are still writing bad requirements despite the availability of many tools and techniques. Twenty years earlier he wrote an article titled *Why Johnny Can't Write Requirements*. Over these years he has learned that many things have to come together to produce good requirements: tools, techniques, training, good metrics, continuous validation, inspections, ask-not-assume approach. 

2017

Femmer et al. coin the **Requirements Smell**. They identify nine smells and relate them to ISO 29148. They note that many automated tools currently available are inadequate in catching these smells. They develop a tool called *Smella*. Among it's techniques are POS tagging, morphological analysis, lemmatization, and dictionary search. 

2022

A Deloitte white paper talks about the role of a **Requirements Engineer**. This role overlaps partially with the role of a software architect. The requirements engineer must be from a testing background. He/she must look at user scenarios and testability. He/she must address any gaps between developers and testers. In one project, Deloitte reduces requirements-related defects from 23% to 4%. This includes improvements to requirements, design, test data and test scripts.