Requirements documents are often badly put together - it is common for omissions, inconsistencies and errors to be ignored. When the time comes for system testing, badly written requirements can be impossible to organise into a useful baseline for use in the test, so the obvious fallback is to use the design document instead. It should come as no surprise when system tests fail to reveal errors in requirements. We ask users to undertake acceptance by testing the delivered system against their original requirements. From the users' simple view of what was required originally, the requirements grew into a voluminous tome, which they thought they had seen the last of months or years earlier.
Systems usually bear little resemblance to the requirements as signed-off.
To get the users going, they may then be given an inventory of the screens and reports in the system which they then use as a check list. In the worst case, acceptance becomes an extension to the training they may have received the week before. Testing Requirements Tales of woe described above are unfortunately all too common. Advocates of good test practice have been saying for some years that testing accounts for around half the cost of a typical project. The reality is somewhat different.