GUIDELINES TO VALID REQUIREMENTS

Extracted from: Business Analysis: A Systems Approach to Solving Business Problems

1. Single sentence (paragraph) per requirement Explanations differentiated (different font/size, indented) Explanations can be included in a requirements document provided it is absolutely clear that it is an explanation and not a requirement. Make things easier for all readers of the requirements by setting explanations off from the requirements by placing the explanation in parentheses, in a different font/size, indented, in a different color, and so forth. It might also help to make it clear in the front of the document what is being used to distinguish the explanations from the requirements. 2. Numbered (identified) Each requirement must be identified with a unique number or label. 3. CompleteSelf-contained, stand-alone Every requirement must be self-contained and stand-alone. The understanding of a requirement must not depend on the content of another requirement. Understanding may depend on language defined in the glossary. Where completeness cannot be obtained (information not available, decisions not made, etc.) the requirement can be defined later, but needs a date or a point in time (or process) by which it will be defined. When dealing with an approved or baselined set of requirements, removing the TBD and replacing it with the real requirements requires a new version. 4. ConsistentLists only WHAT is required, not HOW Does not conflict with any other requirements Use same terminology throughout Lack of consistency in requirements is one of the major reasons for failures due to requirements errors. When inconsistency exists, assumptions will be made and chances are the assumptions could be wrong. 5. TestableUsing inspection, demonstration, execution or analysis Single test per requirement with pass/fail results

Copyright Steven P. Blais, Parkson International, Inc., 2010

Page 1 of 5

Guidelines to Valid Requirements

6. Feasible In scope States no requirements for anything or anyone not in the system Technologies Does the technology exist to do what is needed? Can the technology be accessed/acquired (Buy. Build. Borrow)? Can the software team actually do it? Economic (e.g., Cost / Benefits Analysis) Legal and regulatory Do all the requirements meet or conform to all applicable regulations? Usability Will the user actually be able to understand and use the feature to solve the business problem? Feasible means that it is possible to implement each requirement within the capabilities and limitations of the known technical and operational environment. 7. Traceable Traceable to scope, concept of operations, etc. Traceable to source of requirements 8. Written for the correct audience User requirements UserFunctional requirements User / customerSystems requirements Architect / designerSoftware requirements Analyst / designer / developerProgram requirements Developer / testerHardware requirements Analyst / procurement / testers 9. Word Choice Precision Precision in professional language has two purposes: to make communication with fellow professionals specific and unambiguous, and to inform people on the outside meaningfully and clearly [Holmes, Neville, In Praise of Professional Precision, IEEE Computer, 4/2006]. Choice of words is important. There are a number of imprecise words that we think are precise. These words should be avoided. (See next page). Technical words or jargon tend to obfuscate, and should be avoided unless defined specifically in the glossary. Ambiguity Ambiguity exists when any word or phrase may be interpreted in more than one possible way. This can be verified by having another Business Analyst read the requirements aloud or have a Business Analyst paraphrase what she or he thinks the requirement is saying. If the meaning varies from the authors intended meaning, ambiguity exists and must be eliminated by rewording the requirement. Note that

Copyright Steven P. Blais, Parkson International, Inc., 2007

Page 2 of 5

Guidelines to Valid Requirements the requirement itself may not need to be changed to eliminate the ambiguity. A clearly defined and unambiguous entry in the glossary may eliminate the problem. Use rule-based verbs will, must, active verbs Avoid statements of volition May might Should could If can Use present rather than future tense, if possible No conjunctions: and, but, semicolon, or (and may be used as a connector only) Positive voice Avoid hyphenated phrases Well-organized Fully-automated Trouble-free State-of-the-art Working-condition User-friendly Use nouns rather than pronouns or proper nouns Consistent (not contradictory same use of word) Use Glossary for consistency Avoid vague or imprecise words
ability acceptable appropriate aspect case communicate detect easy enable enough factor feature* instantaneously large many modern operate perform present (v)* realistic satisfactory several about adequate approximately characteristic* comprehensive different* efficient every fast high kind logical matter note (v) practical quick reasonable set safe all around current convenient employ everyone function immediate low measure(n) numerous present (adj) run* simple small

Copyright Steven P. Blais, Parkson International, Inc., 2007

Page 3 of 5

Guidelines to Valid Requirements

*without qualifying attribute **unless dealing with mathematical specifics

Avoid automatic words (without glossary definition) accessible* apply architecture automate(d) batch check (v) component database* deployment documentation effective encode* execute feature function generate header input (n) infrastructure install maintain middleware network operation(s) phase part provide read* relationship scale(v) seamless segment set support synchronize transaction write* accessibility* architectural automation client concurrent decode* disk* drive(n) efficient entity field functional gui implementation input (v) implement integrate* manual module output (n) port (v) partition real-time robust scan secure (v) server simultaneously survey(v) synchronous unit* application artifact availability* asynchronous build(n) communication* connection(s) design* display* element executable firmware functionality interface integration monitor (v) output (v) package populate record runtime screen secure (n) serviceable supply switch (n) update

Copyright Steven P. Blais, Parkson International, Inc., 2007

Page 4 of 5

Guidelines to Valid Requirements

Phrases to avoid more or less present time the ability to web-based network layer real-time throw an error physical design round-trip user friendly

Avoid comparative adjectives or phrases a little best considerable easier extremely faster large lowest maximum* really smaller very as little as* better considerably enough good larger mega-** more smallest worse as much as* bigger definitely exceeding(ly) highest least meta-** most somewhat bad cheaper excessive(ly) huge less minimum* overly too

*without a qualifying quantity (e.g., a minimum of twelve will be allowed) **when referring to size rather than quantity

Copyright Steven P. Blais, Parkson International, Inc., 2007

Page 5 of 5