Wednesday, September 12, 2007

Quality Software Requirements

A few pointers to evaluate requirements:
  • Correct - a true statement of something the system must do
  • Complete - describes all significant requirements of concern to the user
  • Consistent - does not conflict other requirements
  • Unambiguous - subject to one and only one interpretation
  • Verifiable - can be tested cost effectively
  • Ranked for Importance & Stability - can be sorted based on customer importance and stability of the requirement itself
  • Modifiable - changes do not affect the structure and style of the set
  • Traceable - the origin of each requirement can be found
  • Understandable - comprehended by users and developers

Signs of bad requirements:

  • Undefined jargon is used
  • The word 'use' is used
  • Conjunctions can be found e.g. and, or, also, with
  • Exception statements are used e.g. if, but, when, except, unless
  • Graphical depictions are used in lieu of a detailed textual description
  • Generalisations are used e.g. generally, usaully, approximately
  • Relative terms are used e.g. user-friendly, fast, flexible, intuitive
  • Suggestive terms are used e.g. could, should, may, might, probably
  • Clarifications are used e.g. that is, for example, like
  • The word 'not' is used e.g. not exhaustively saying what 'is' allowed

Managing Software Requirements: A Use Case Approach

1 comment:

Craig said...

This post has been included in the 5th edition of the Carnival of Business Analysts which has been published at Better Projects.

The Carnival is a series of blog posts that collect other qualityblog posts on topics themed around the BABOK knowledge areas. Edition 5 is on Requirements Analysis.

Read the Carnival of Business Analysts at Better Projects.