| Guideline: Requirement Pitfalls |
 |
 |
|
| Related Elements |
|---|
Research and experience shows that requirements errors are very common, accounting for as much as 56% of all errors made during development [TAV84]. Compounding this problem is the fact that the cost of correcting requirements errors increases exponentially throughout the software development lifecycle [BOE88]. Frederick Brooks summarized this situation nicely: The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements…. No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later.[BRO87] Therefore, it is critical that you detect requirements errors as early as possible, before they propagate to design, implementation, and test artifacts. What to avoid when writing requirementsAlthough there is sure way to eliminate requirements errors in general, there are common pitfalls in writing requirements that are relatively easy to avoid [TEL06]. AmbiguityAvoiding ambiguity is one of the most difficult mandates in writing requirements. Try to write as clearly and explicitly as possible. Be specific. If you must use vague or ambiguous terms, make sure that you define them in the glossary. Have several colleagues and stakeholders review your requirements to ensure a consistent, common understanding. Although there is no definitive test for ambiguity, other than consensus, some dangerous ambiguities can be caused by the use of the words for, or, and unless. Example Multiple requirementsRequirements that contain conjunctions (words that join independent clauses together) are dangerous. Problems arise when readers try to figure out which part applies, especially if the different clauses seem to conflict or if the individual parts apply separately. Multiple requirements also make verification more complex. Dangerous conjunctions include: and, or, but. Example Let-out or escape clausesRequirements that include options or exceptions are dangerous. They seem to ask for something definite, but at the last moment, they back down and allow other options. Problems arise when the requirements are to be tested, and someone has to decide what (if anything) could prove that the requirement was met. Dangerous words that imply exceptions include: if, when, but, except, unless, although. Examples RamblingLong, rambling sentences, especially when combined with arcane language or references to unreachable documents, quickly lead to confusion and error. Example Premature designRequirements should specify the design envelope without unnecessary constraints on a specific design. If we supply too much detail, we start to design the system. Going too far is tempting for designers, especially when they come to their favorite bits. Danger signs include names of components, materials, software objects or procedures, and database fields. Example Mixing different kinds of requirementsThe user requirements form a complete model of what users want. They need to be organized coherently to show gaps and overlaps. The same applies to system requirements, which form a complete functional model of the proposed system. A quick road to confusion is to mix up requirements for users, systems, and how the system should be designed, tested, or installed. Danger signs are any references to system, design, testing, or installation. Example SpeculationRequirements are part of a contract between customer and developer. There is no room for wish lists, meaning general terms about things that somebody probably wants. Danger signs include vagueness about which type of user is speaking and generalizations, such as usually, generally, often, normally, typically. Example Vague, undefined termsMany words used informally to indicate system quality are too vague for use in requirements. Vague terms include, among others: user-friendly, versatile, flexible, approximately, as possible. Requirements using these terms are unverifiable, because there is no definitive test to show whether the system has the indicated property. Examples Expressing mere possibilitiesSuggestions that are not explicitly stated as requirements are invariably ignored by developers. "Possible options" are indicated with terms such as may, might, should, ought, could, perhaps, probably. Example Wishful thinkingWishful thinking means asking for the impossible. Engineering is a real-world activity, and no system or component is perfect. Wishful-thinking terms include reliable, safe, handle all unexpected failures, please all users, run on all platforms, never fail, upgradeable to all future situations. Examples |
This program and the accompanying materials are made available under the |