Paul Gerrard

First published 06/11/2009

Getting the requirements ‘right’ for a system is a pre-requisite for a successful software development, but getting requirements right is also one of the most difficult things to achieve. There are many difficulties to overcome in articulating, documenting and validating requirements for computer systems. Inspections, walkthroughs and Prototyping are the techniques most often used to test or refine requirements. However, in many circumstances, formal inspections are viewed as too expensive, walkthroughs as ineffective and Prototyping as too haphazard and uncontrolled to be relied on.

Users may not have a clear idea of what they want, and are unable to express requirements in a rational, systematic way to analysts. Analysts may not have a good grasp of the business issues (which will strongly influence the final acceptance of the system) and tend to concentrate on issues relevant to the designers of the system instead. Users are asked to review and accept requirements documents as the basis for development and final acceptance, but they are often unable to relate the requirements to the system they actually envisage. As a consequence, it is usually a leap of faith for the users when they sign off a requirements document.

This paper presents a method for decomposing requirements into system behaviours which can be packaged for use in inspections, walkthroughs and requirements animations. Although not a formal method, it is suggested that by putting some formality into the packaging of requirements, the cost of formal inspections can be reduced, effective walkthroughs can be conducted and inexpensive animations of requirements can be developed.

Registered users can download the paper from the link below. If you aren't registered, you can register here.

Tags: #testingrequirements

Paul Gerrard My linkedin profile is here My Mastodon Account