Writing Good Requirements

Abstract

The primary reason that people write poor requirements is that they have had no training or experience in writing good requirements. This paper will address what makes a good requirement. It will cover some of the most common problems that are encountered in writing requirements and then describe how to avoid them. It also includes examples of problem requirements and how to correct them.

Discovering System Requirements

“…Also, requiring that the inside of the CPU box be painted pink is probably an unnecessary request. Overspecification (of both types) is how $700 toilet seat covers and $25,000 coffeepots were created (Hooks, 1994). Each requirement should include a statement of its rationale.…”

6.2.2 A Program of Research into Systems Engineering

“…The situation has been described by Cobb's Paradox (Voyages 1996), which stated "We know why projects fail, we know how to prevent their failure --so why do they still fail?" One of the known contributing causes of these project failures is poor requirements engineering and management, which has been repeatedly and widely discussed and documented for at least 10 years (Hooks 1993;Kasser and Schermerhorn 1994;Jacobs 1999;Carson 2001;etc.). However, this continual documentation and discussion of the problem of poor requirements engineering and management has not resulted in a practical solution to the problem.…”

Industrial Challenges for Numerical Simulation of Crystal Growth

“…It is claimed that terms such as "userfriendly" or "easy-to-learn" are ambiguous because they are subjective and thus unverifiable [15]. On the other hand, they can be measured (in relative units) -one easily can compare two codes using time needed to master code operation by uninitiated user or time required for specification of geometry and problem parameters.…”