Testing Requirements
advertisement
EuroSTAR '94, 10-13 October 1994, Conrad International Hotel, Brussels, Belgium.
Testing Requirements
Paul Gerrard
Gerrard Consulting Limited
PO Box 347, Maidenhead
Berkshire, SL6 2GU, UK
Tel: +44 (0)1628 639173
paul at gerrardconsulting dot com
www.gerrardconsulting.com
Abstract
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.
Prerequisite Key Words:
Topic Descriptors:
© Paul Gerrard
none
Requirements Testing, Inspection, Walkthrough, Animation.
Testing Requirements
Page 1
1.
INTRODUCTION
The importance of getting the requirements for a software development project ‘right’ is
universally regarded as a pre-requisite to achieving success. In the past, requirements were
often seen as unimportant by developers, when compared to the ‘technical’ documentation
such as the designs and program specifications. But, as failure to deliver acceptable systems
became more common (and expensive), pressure from users has forced developers to
concentrate much more effort on requirements gathering and validation stages. Inspections,
reviews, walkthroughs and Prototyping are now widely used to refine and validate
requirements.
Even though progress has been made, these techniques are not as effective as they could be. A
significant difficulty has to do with the format and structure of the requirements document
itself. They are usually difficult to navigate, are written in widely varying levels of detail and
are too far abstracted from the system envisaged by the users to allow them to conduct
efficient inspections, or systematic walkthroughs. Currently available tools which facilitate
requirements animation either need the requirements to be documented using a formal
notation, or are inexpensive presentation packages which can only step through static
presentation slides.
The techniques described in this paper attempt to introduce some formality into the process of
validating requirements so that inspections are easier to organise and implement,
walkthroughs can be structured and conducted efficiently and facilitate basic, but effective
animations using simple PC based tools.
The Behaviour Analysis technique adopts a pragmatic approach to structuring requirements
into manageable elements called system behaviours. System behaviours are elementary
descriptions of the functionality of the required system. They are easily understood by users
because individually, they describe only a very small part of the whole system. Because all
behaviours have the same structure, the approach to validation is the same for every one. The
biggest advantage to users is that the difficult task of interpretation of the requirements is
done once, by the author, on behalf of all users.
Each behaviour can, with some compromise to good grammar, be presented in the form of a
single statement. Because of their structure, they are easily recorded and manipulated in a
spreadsheet or simple database.
This technique aims to supplement existing methods for validating requirements by:
making inspection material easier to inspect
providing a framework in which structured walkthroughs can be conducted
enabling the analyst to create simple animations.
Tables of behaviours introduce more formality into the process of requirements validation
than most development environments are used to, but are justifiable based on the benefits of a
more rigorous requirements definition, the ease with which requirements can be reviewed,
and the direct translation of behaviours into test cases which can be used later on in system or
user acceptance tests.
This technique is not intended to be used to decompose requirements documents completely,
as it does not support non-functional requirements, at least directly. Further, complex
functionality such as rule based processing, in the form of combinations of conditions are
usually presented in the form of decision tables which are already in a form suitable for
inspection.
© Paul Gerrard
Testing Requirements
Page 2
1.1
The Problem with Requirements Documents
Requirements can be documented in many ways and styles. In safety-critical applications, the
format, language, style and structure of requirements specifications must adhere to strict
standards. For example, every sentence in the document is numbered; copious crossreferences between text, diagrams and related documents must be included. Sentences are
“tagged” to reference objectives, constraints or other attributes of the specified system.
Such specifications can be loaded into a database and reports of cross-references, impact
analysis, change history, etc. can be produced. They can be cross-checked for completeness
and consistency, and analysed by expert systems. If only all requirements were so.
It is towards the other end of the spectrum, however, that most requirements documents are to
be found. These are often badly organised, incomplete, inaccurate and inconsistent.
Why is this so?
There are several, seemingly inevitable problems with requirements:
Interpretation - the requirements of the customer are often written by the supplier detailed requirements may not use the correct terminology and language so users don’t
understand them; terms that are used may have been misinterpreted by the supplier.
Language - they are written in English (or other natural language) that is prone to
ambiguity and misinterpretation.
Informality - few analysts or users have any training in formal methods of specification,
so each tend to have their own informal style of recording requirements.
(Un)Testability - requirements are often presented in the form of an inventory of features
qualified by conditions which the system must respond to - it is usually very difficult for
users to interpret such requirements and to ‘test’ them against their expectations.
Over Abstraction - the requirements are usually stated in terms of rules - the user cannot
envisage how the system will behave when he interacts with the system, so is unable to
verify that the system will work in their environment.
Under Specification - analysts have always got away with under-specification - they
assume it is the responsibility of the users to ensure all requirements are captured, and
that missing features and conditions are probably minor - the programmer can add them
in his spare time.
As a consequence of poor requirements, the effort spent designing and coding has been
increased significantly both in development, to clarify requirements, and in maintenance to
correct errors in specification that have found their way into production. The usual excuses
are that the ‘users don’t know what they want’, or ‘they always change their mind’. This is
not an acceptable state of affairs nowadays.
Errors in requirements are potentially the most serious errors, because they are usually the
most expensive to correct later in a project (if the project hasn’t already folded).
© Paul Gerrard
Testing Requirements
Page 3
1.2
Problems with Inspections
The argument for doing something about testing requirements seems to be overwhelming.
Clearly, we should spend more time validating requirements to ensure they reflect the needs
of the business, are accurate and can represent a common view on what the system should do.
Inspections are the answer of course! The evidence for the effectiveness of inspections in
finding errors in documentation and code has accumulated steadily for many years.
Inspections have been shown consistently to be effective in finding errors if the inspection
process is properly applied and adhered to. However, when it comes to implementing
inspections the biggest barrier to implementation is that of cost. Where the potential cost of
errors is considered high as in, for example, safety critical or military software, it is easy to
justify inspections. In many circumstances, however, inspections are difficult to justify
because the risk of error is simply not deemed to be high enough.
Inspections Can be Difficult to Justify
In a RAD project, for example, the nature of the method implies an iterative approach to
establishing user requirements and then evolving a system to meet those requirements. RAD
focuses on delivering business benefits as its main aim, so it is common for a system
developed using RAD techniques to have redundant features or have many errors in parts of
the system which do not directly deliver a benefit to the user. Error levels in software
developed using RAD techniques may be high, but it is difficult to justify inspections in such
projects because the costs introduced are unacceptable. Delays defeat the object of RAD in
the first place and the benefits of inspections are not so great anyway - users will put up with
buggy software, as long they get the business benefits.
A typical inspection productivity rate for documentation is around 1 page of text (c. 600 noncommentary words) per hour per checker. To a project manager, a significant delay in signing
off user requirements is often unacceptable. Consider, for example, a typical project with a
nine month deadline; the requirements document is 200 pages long. It could easily take an
additional 6-8 weeks elapsed time to co-ordinate the inspection of the requirements by the
relevant users. Not many project schedules can bear such a delay.
Other Difficulties
When it comes to inspecting requirements documents, users have several difficulties:
1.3
Lack of a source document. System designs can be inspected against requirements
and program specifications can be inspected against designs, but for requirements, there is
usually no source document. The inspection is most often performed with reference to the
expectations of the user, which only exist in the users’ heads, of course.
Lack of user resources. In the example above, users might need to inspect 100 pages
of requirements. Getting a commitment for around 100 man hours for each user is not
very easy in most companies. The chances of getting a 50% commitment from users for
two months are slim. Inspection productivity rates are prohibitive.
Long Documents. Although requirements documents need not necessarily be very
long, in practice, it can be difficult to break up such documents into ‘inspectable chunks’.
Unlike the system design, the document will not be broken up into functional
components, but is more likely to be structured into broad business functional areas. The
effectiveness of inspections is adversely affected by both the size of the document under
inspection and the difficulty in tracing explicit cross-references and implicitly related
sections.
Why Behaviour Analysis?
So inspections are effective, but expensive. How can inspections be made more productive
without compromising their effectiveness?
© Paul Gerrard
Testing Requirements
Page 4
We can summarise our needs as follows:
increased page inspection rates
more systematic inspections
reduction in the material to be inspected.
Most requirements are documented in terms of narrative text. A difficulty that all users face is
that they need to perform several ‘transformations’ of what is on the page before they are able
to approve a statement. They need to:
relate an abstracted requirements statement to the ‘envisaged system’
relate the behaviour of the system to their business process (current, or envisaged)
compare and contrast the behaviour of the system with other similar behaviours (if they
can find them).
This convoluted process must be repeated for every sentence in the requirements. A poorly
structured document will be impossible to check for inconsistencies because of the constant
need to compare every system behaviour with every other in the vicinity. Because of this,
inspections of requirements documents are made doubly difficult.
2.
BEHAVIOUR ANALYSIS
2.1
Behaviour Model
A requirements document is intended to describe all the functions required to be performed by
the system. The problem with testing requirements documents is that functions can be
described in many ways, often in varying levels of detail.
The objective of the behaviour model is to structure the requirements into a form that can be
presented to users for them to review directly. Only if the material to be reviewed can be
matched with their expectations will they be able to identify errors, omissions and
inconsistencies.
Figure 1 is a schematic representation of dynamics of events, users, the system and functions
(or transactions) executed in the system.
The components of the behaviour model are:
Events - which trigger the user to do something
Functions - the function or facility of the system to be executed
Conditions - the condition which determine the response of the system
Responses - the response of the system predicted by the requirements.
C o n d itio n s
Event
U ser
F u n c tio n
R esponse
Figure 1. Model of a Requirement
© Paul Gerrard
Testing Requirements
Page 5
The functional requirements of a system can be decomposed into a collection of behaviours
each of which consists of a unique combination of function and condition. Every functioncondition combination must have a response predicted by the requirements specification.
Each function-condition-response triplet is called a behaviour.
We can use the behaviour model to analyse the requirements document into tables of
behaviours. The tables of functions, conditions and responses, mapped to the sentences or
sections in the requirements document are the elements we use for inspections, walkthroughs
and animation. Because of their uniform structure, behaviours are easily tabulated and are
amenable to capture and manipulation in a database or spreadsheet.
Behaviour analysis consists of four stages:
Pre-Processing - the requirements document is scanned to select and package the
sections in the document to be analysed.
Analysis - the requirements packages are analysed one by one and lists of functions,
conditions and responses for each package are created.
Rationalisation - for each package the lists are examined in turn, duplicates removed,
and standard phrases used for each element.
Synthesis - for each package in turn, sensible combinations of function and condition
are identified, and for each, a behaviour is derived.
Each behaviour is numbered and referenced to the package in the requirements document.
The four stages are outlined below.
2.2
Pre-Processing
The purpose of pre-processing the requirements document is to filter out all those sections
which describe functional requirements and to break up the functional requirements into
manageable packages for analysis.
A manageable package is normally a section in the document which describes a particular
feature in detail. Such a section would normally be less than one page and would not span
more than two pages of normally spaced text. A rule of thumb is that a package should not be
comprise more than twenty sentences or a thousand words. The reason we limit the size of
packages is that we need to limit the number of functions and conditions identified. When we
come to look at the combinations of functions and conditions, many will be irrelevant so we
reduce the number of irrelevant combinations now.
Packages can be initially identified using a highlighter pen on a copy of the requirements. If
sections are of a suitable length, the table of contents can be used directly to identify the
packages to use.
2.3
Analysis
For each package in turn, the text is scanned, sentence by sentence, for occurrences of
functions, conditions and responses. For each package, lists of the functions, conditions and
responses found are made. At this stage, the analyst should concentrate on identifying all such
references rather than refining his precise definition of each function or response. The lists
will be rationalised in the next stage.
© Paul Gerrard
Testing Requirements
Page 6
FUNCTIONS
Requirements
2.2
1.
The system will accept orders for
customer with a goo credit rating
and reject orders for bad debtors.
2.3
Order Entry
2.3.1
Order numbers must be entered.
If the order number exists and
has been issued, it will be
rejected.
2.3.2
2.3.1
add an order
2.
add an order item
3.
list orders
RESPONSES
1.
Items may be added to orders.
Items must be unique and be in
stock for them to be accepted.
Orders may have a status of
issued or cancelled. Orders which
have been issued may be
cancelled. Orders may not be
changed once cancelled.
order accepted
2.
order item accepted
3.
order item rejected
4.
order cancelled
5.
orders listed
CONDITIONS
1.
customer credit OK
2.
customer is bad debtor
3.
order issued
4.
item in stock
5.
item out of stock
Figure 2 Analysis of Requirements into Functions, Conditions and Responses
For most reasonably well written documents, the three elements should be straightforward to
spot, when they appear explicitly:
section headers often name functions explicitly
functions can be described explicitly with phrases like “the system will allow the user to
add, amend and delete records...”
explicit conditions are often presented in constructs like “if ... then ....” phrases
responses often come early in sentences in phrases like “the system will reject entries with
....” or late in sentences like “... entries with ... will be rejected”.
Implicit elements are obviously more difficult to spot:
‘if...then’ phrases imply some different behaviour if the condition is false
some verbs like ‘update’ imply system functions, but others, such as ‘reject’ indicate a
response with the relevant condition described elsewhere
conditions are often equivalence partitions - other partitions may obviously be relevant
but may never be explicitly defined at all.
With practice, it becomes much easier to spot the functions, conditions and responses, and
most analysts use stock phrases again and again. When you see one of these phrases, it should
alert you as these phrases are often signposts to one element or another.
The process of analysis when performed by the author of the document is an excellent
technique for inspection itself. It is likely the author will find at least as many errors,
particularly omissions, during this process as the checkers will later.
2.4
Rationalisation
Having analysed a requirements section into three lists, the next task is to rationalise each list
in turn. The purpose here is to remove duplicate functions and conditions and give each
element a brief description which is consistent with its origin in the requirements.
2.5
Synthesis
This stage consists of synthesising behaviours from combinations of functions and conditions,
matched with responses. The process is quite simple:
Select each function in turn
© Paul Gerrard
Testing Requirements
Page 7
For each condition in the list, consider whether the condition is relevant to the function
selected. If it is we add a new row to the table of behaviours.
Scan the list of responses, and select the response which the requirements document
predicts, if there is one.
Repeat the above for every function and condition building up the table of behaviours.
Figure 3 Synthesising Behaviours illustrates how the synthesis process works. The behaviours
for a chunk can usually be presented on a single page, and this makes the tables very
convenient for inspection later.
1.
FUNCTIONS
CONDITIONS
RESPONSES
1.
add an order
1.
customer credit OK
1.
order accepted
2.
add an order item
2.
customer is bad debtor
2.
order item accepted
3.
list orders
3.
order issued
3.
order item rejected
4.
item in stock
4.
order cancelled
5.
item out of stock
5.
orders listed
Function
Condition
Response
Figure 3 Synthesising Behaviours
3.
TEST BY INSPECTION
3.1
Preparing Behaviour Tables
Where the requirement document, as written, does not allow a response in a certain situation
to be predicted, the response should be left blank. The user will be asked to supply a required
response for the behaviour.
The order of presentation of the behaviours make it easy to spot errors and inconsistencies.
Responses to functions triggered by events under similar conditions appear next to each other.
3.2
Packaging Behaviours for Inspection
An objective of creating the behaviours tables is to reduce the volume of material to be
inspected by users by giving them only what is relevant. It is likely that the tables of
behaviours created for each package can be selected from according to their relevance to each
users role, responsibility or area of expertise. The package of behaviours should be
accompanied by the corresponding version of the requirements document.
Packages do not necessarily have to be presented in the order they occur in the requirements
document. Often, certain system requirements are ‘generic’ and have to be separated from the
other sections to which they are relevant. Packages that are widely separated in the
requirements document can be bundled together for the purpose of inspection.
Users are requested inspect the tables of behaviours using the requirements document for
reference, where necessary.
© Paul Gerrard
Testing Requirements
Page 8
3.3
Individual Checking
The users should inspect the tables of behaviours in conjunction with the corresponding
sections in the requirements document. Each entry in the behaviours table is checked:
for correctness
missing responses
inconsistent responses.
New, missing or incomplete conditions can often be identified once the user sees all the
conditions for a particular function listed together.
Some users prefer to think through the meaning of a behaviour by transforming the behaviour
into a sentence by using some simple phrases. In the same way that entity models can be
‘read’ and reviewed, the user can build up a plain English sentence and asked simply to
approve it or not. The sentences are often imperfect grammatically, but this does not usually
impede the user from understanding the meaning.
A Behaviour can be transformed into two sentences as follows:
1.
{event}, so the user/system {function title}.
2,
If {condition} [,and/or [condition...]] the system will {response}.
© Paul Gerrard
Testing Requirements
Page 9
For example, if the Behaviour is:
Function
Request Part From Stock
Event
a parts requisition is received
Condition
part IS out of stock and
a substitute part exists
Response
reject the partcode and display a ‘Part out of Stock substitute part: XXXXXX’ message
The sentences becomes:
1. A parts requisition is received, so the user Request Part From Stock.
2. If part is out of stock and a substitute part exists the system will reject the partcode and
display a ‘Part out of Stock - substitute part XXXXXX’ message.
The sentence is not perfectly grammatically correct, but with that aside, it should still be clear
to a user as to its meaning.
When tables of behaviours have been checked by all users a review meeting, if deemed
necessary, can be arranged to agree on the list of errors found. It should then be possible for
the analyst to correct all errors found and re-issue the behaviours tables and amended
requirements document for sign-off.
4.
TEST BY SCENARIO WALKTHROUGH
It is common for users to fail to see errors and omissions in requirements because they cannot
relate the requirements document to the system they envisage. System requirements which
will be used in sequence in support of a particular business process are likely to be
documented in dispersed sections of the requirements document. Requirements for integrated
or workflow-oriented systems with multiple user roles are difficult to test using inspections as
a fundamental requirement for such systems is that they support a sequential sequence of
tasks performed by different users.
Since the system will be judged a success or failure based on how well it support the business
process, if we can simulate, in some way, the system’s behaviour in the context of the
business process we should be able to catch workflow-oriented errors which an individual
user could never detect.
4.1
Deriving Scenarios
Business scenarios are what we can use to ‘drive’ a walkthrough of the system behaviours.
The scenarios should reflect real business histories so they could reflect one-off projects, life
histories of entities of importance to the business or cyclic business routines. Examples of
business scenarios appear in the table over the page:
We select broad scenarios to provide a realistic framework within which to execute a
selection of the behaviours we wish to test. In this way we use the scenarios to ‘cover’ the
behaviours.
Scenarios are split into stages. These reflect the key tasks or activities of the scenario, e.g.
tasks of a project, the key stages in a product life history, or the management checkpoints
associated with the preparation of a complex business plan.
Scenario Type
© Paul Gerrard
Example
Testing Requirements
Page 10
Life history
Customer life history
Stock item life history
Projects
Launch a product
Build an oil platform
Business Cycles
Daily, weekly routines
Monthly billing run
Quarterly business planning
End of year process
Table 1 Types of Scenarios
Each scenario stage represents a selected event, a function to be executed, and the conditions
that could occur. We select the scenario stages to cover each behaviour on the behaviour table
in turn. As we develop our scenarios, we cover more and more of the Behaviour table.
Variations in normal scenarios can be introduced to ensure total coverage is achieved, but
unusual convoluted scenarios can also be used to cover obscure behaviours.
4.2
The Walkthrough
It is most important that the participants in walkthroughs are selected users who understand
the business processes involved in the scenarios. Users who are unfamiliar with the
requirements document, but who will use the new system are just as effective in identifying
problems with the requirements - they do not have any assumptions about the system other
than it should fit into their business practices.
Scenario walkthroughs can be conducted as round the table sessions, and this is appropriate
where the system is for a single user, or where all users make the same use of the system.
Where the system provides integrated functionality and the scenarios require the collaboration
of different user groups, the walkthrough is most effective when it is ‘staged managed’.
Users are encouraged to play their distinct roles within the test scenario. Each users role can
be highlighted on the scenario listing. The walkthrough can be made more realistic for the
users by providing ‘props’ which ensure the session simulates the production situation
closely. Standard forms, documents, written procedures, clipboards, PCs can all be used to
help the users relate the simulation to their current practices and to record any data which can
be used in a re-run of the scenario, if required, or for later system and acceptance tests.
Scenario walkthroughs are particularly useful where new or changed business procedures
must be implemented at the same time as the new system.
5.
TEST BY ANIMATION
5.1
When Animations Are Useful
Walkthroughs are effective in testing requirements and procedures in parallel but it is
expensive to assemble teams of experienced staff for days at a time. Animation of
requirements can be both cheaper and more effective when
the system is a single user application
it is difficult or impossible to assemble teams of users
developers need guidance on what navigation paths through the software are required.
Where the system under test is a single user application, it can be more profitable to animate
the requirements so that individual users can experiment with a simulation of the system.
© Paul Gerrard
Testing Requirements
Page 11
5.2
Animation in Practice
Animation does not require expensive tools. A single table, single-form database on a PC
which holds details of the scenario stages, system behaviours and fields to record user
comments can be presented to users.
Figure 4 presents an example of a simple requirements animation. The screen presents the
following information for the user to examine:
scenario title
scenario stage description
behaviour details; function, condition and response.
To be effective, the screen need only provide basic functionality, based around the navigation
and update of records in a single table. In the example below, The user can:
navigate through scenario stages and behaviours using first, last, next and previous
buttons
record whether they approve, reject or suggest amendments to the behaviour or scenario
stage
record their suggestions, comments or reasons for rejection.
Requirements Animation
Figure 4 Example of a simple requirements animation
Users can run and re-run the animations as many times as they wish and independently of
both other users and the developers. Users can ‘get to know’ the animation before passing
judgement on the scenario or any behaviours it references. The value of even such a simple
animation is potentially very high because:
many users get a better ‘feel’ for the proposed application using animations
animations give users confidence that the system fits their business process
users can register their approval or rejection with comments made promptly and directly
© Paul Gerrard
Testing Requirements
Page 12
the user can record other ideas and suggestions for improvements.
The advantage of capturing such user feedback directly, is that the resulting approvals,
rejections and suggestions can be reported on using the database tool. Where multiple
animations have been logged by several users, the results can be merged. The analyst can
identify all behaviours for which there is a consensus approval of course, but more
importantly, can focus effort on resolving the discrepancies found by the user reviewers.
When the requirements have stabilised, the animations can also be used by the developers of
the system. Like a prototype, the animations give developers a very good reference model for
the subsequent development, and can help them to identify the most useful navigation paths
through the application, among other things.
6.
CONCLUSION
This paper has outlined three techniques which can be used for testing requirements. The
three test techniques are all based on Behaviour Analysis which enables analysts to convert
narrative text into a tabular representation. In its own right, Behaviour Analysis helps to find
errors in requirements because it demands the analyst adopt a systematic approach to
extracting functions, conditions and responses from the requirements text before synthesising
elementary test cases which can be validated individually.
Even if the three test techniques are not used, Behaviour Analysis is an effective method for
finding errors in requirements. The technique is easy to learn and implement, and can be
applied to requirements documents of any size by selecting only critical sections for analysis.
Behaviour Analysis is a pre-requisite for the three test methods; inspection, walkthrough and
animation, and each test technique has its own area of applicability and benefits:
test by inspection is useful where traditional inspections would be too difficult, timeconsuming or expensive to implement in the user community
test by scenario walkthrough is useful where the fit between proposed system and new or
changed business process is a key consideration
test by animation is most useful where requirements are not stable, where the system is
aimed at individual users or where a more controlled Prototyping technique is required.
Errors in requirements present a most difficult challenge.
Developers find it almost impossible to detect errors in requirements without the help of
users. New methodologies such as RAD and JAD involve users much more intimately, but
these techniques are successful in specific situations where the risk of errors is low and
overall project size is small.
Traditional developments of larger systems still use a staged, rather than an iterative
approach. Users are intimately involved only in the earliest stages and at the very end. The
risk of requirements errors is extremely high in such projects, but in most cases requirements
are not adequately tested. Many of these projects fail in the end, when the cost is highest,
because they could not deliver the required business benefits.
Testing of requirements is potentially the most valuable testing we can do, because errors in
requirements are usually the most expensive to correct later, and present the biggest threat to
the project’s success. Behaviour Analysis, testing by inspection, testing by walkthrough and
testing by animation offer some hope that requirements can be ‘got right first time’.
© Paul Gerrard
Testing Requirements
Page 13
