An example requirements document.

Taken and adapted from "Correct systems - building a business process solution"  M. Holcombe & F. Ipate, Springer, Applied Computing Series, 1998. [See also the Departmental CD under COM221]
 

 This case study is based on a real software development project undertaken by M. Al-Qaed and one of the authors during June - September 1996. The client runs a postal philately business and wishes to computerise his operation. These notes describe the current business process and some initial outline requirements as captured by the software engineer during a number of discussions with the client. Later we will see a full formal development of this system using stream X-machines. The method is based around the identification of the structure of the user interface in consultation with the client and, eventually, the use of a visual programming language. The testing method was then applied be discussed in a later chapter.
 

$1. The current business environment :
The dealer sells new (mint) and used postage stamps from any country to stamp collectors, who collect stamps out of interest or for investment, some of the stamps are extremely rare and valuable. These stamps are categorized by countries and every group of stamps from the same category is located on one or more cards. The cards are simply small albums of two sizes - the small ones are more expensive than the bigger ones. The units consist of one or more cards, and those are filed ready for sending to customers. Units are the smallest part in the system and they have an identity number with a colour to make the search easier. In the normal course of business a customer will indicate the type of stamps they are interested in and on a regular basis the dealer will send a collection of stamps by post to the customer for their approval, the customer retaining the ones he/she wants and returning the rest with an appropriate payment. Currently the dealer stores all the information required in manual files and when he wants to send some units he adds all the data manually and ensures that the units to be sent have not been sent before to the same customer.
 

Current manual procedures.
1.1.  The dealer categorizes the stamps into groups and separates each group into units. Each unit contains a selection of stamps and all the stamps are from a specific country.

1.2.  He then numbers each group using three digits and four colours to make the manual search easier.

1.3.  All new stamps have to be categorized and numbered before they are added to the system.

1.4.  The customer, initially, contacts the dealer and indicates that they wish to buy some stamps.

1.5.  The dealer replies with a list of categories available.

1.6.  The customer chooses some categories of stamps and selects an appropriate time interval for receiving the stamps (for example, immediately, two weeks, one month or any other date).

1.7.  The dealer will check if these categories are available or not. He will send some units from the categories requested (if all the categories requested are not available then he writes to the customer asking him to choose others). He will write down the customer's name, address and the units to be sent.

1.8.  The customer selects some stamps from the units delivered and keeps them. He/she returns the others to the dealer with the money for the stamps purchased and gives their next choice of categories and the date when they would like to receive another package of stamps.

1.9.  The dealer writes down the cost of the stamps sold and puts the customer's name in the queue for his next order. This queue is subject to the choice of the customer for his next order date (if the customer does not give his/her next order then he/she will be deleted from the system automatically).

1.10.  Repeat steps 1.1 to 1.3 for new stamps to be added to the system.

1.11.  Repeat steps 1.7 to 1.9 for the process of selling the stamps (Steps  1.4 - 1.6 are for new customers only).
 

This is a simple business process model which was confirmed by the dealer/client as representing the way he wished the proposed system to work. This activity was relatively straightforward, since there were no technical computing issues raised at that time.
 

$2. Elementary data modelling.
We now start identifying some of the simple aspects of the system.

2.1. Units and customers.
Description of the sale units:
The system consists of 300-400 units (maximum).
There are two types of units (big/small).
Each unit has the following fields :
Number : Identity number (unique) to distinguish between cards.
Colour : To make the search easy.
Number : Number of cards in the units.
Category : Country or region.

Description of the Customers:
The system consists of 150 customers (maximum).

Each customer has the following fields :
Number : Identity number (unique).
Name : Customer's name.
Address : Customer's address.
Date of next order : immediately, one week, two weeks or one month.
 Categories : Stamps requested from specific categories.
Unit numbers : which units were sent to him/her (could be more than one) ?
Cost : How much has he/she spent ?
 

$3. Basic assumptions and the operating context.
The system will be installed in a "stand alone" computer and will be used by the dealer only, so no protections such as passwords are required by the dealer.

The dealer should have a basic knowledge of the Windows environment [87], and he must be able to run a suitable word processor application and be able to edit and print out texts.

The system must be easy enough to understand and use without a lot of  training. The system will use the Windows environment and must provide appropriate help when needed at every stage of the system.

A search facility is needed for customer numbers and names but not for addresses.

Only the last six month's records of requests are needed to be stored in the system for each customer.
 

Specific constraints.
The user owns an Intel PentiumTM PC with 8 MB of RAM, 800 MB of Hard Disk and 100 MHz processor.

The system was to be implemented using a Visual Basic [88] interface to an Access [89] database. This decision was made, primarily on the basis of what was available to the developer but also to see if the specification and testing methods were suitable for such a commonly used languages.
The system must be reliable and fully documented and  must be developed rapidly (3 months at most).
 

$4. Informal initial functional requirements.
Req. 1.  To produce an application to automate the manual operations of the stamp dealer system. This application must do all the functions of the system that can currently be done manually quickly and provide the necessary data for the user at the appropriate time. The application should be easy to use and the process must be faster and easier than the manual method.

Req. 2.  The manual method consists of units and each unit consists of cards that contains many stamps of the same category. These units have identity numbers and colours to distinguish them. The user should be able to edit units' data (unit number, colour, category, number of cards and type). The units' data should be stored in the computer to use them at the sale time (request and send orders' process).

Req. 3.  The maximum number of units in the system is 400 units and there are four colours (Red, Blue, Yellow, Green). There should be no restrictions in permitted category names except the length, which is 30 characters in maximum. The card type is either small or large and number of cards is not more than 20 and not less than 1.

Req. 4.  Customer names and addresses need to be stored in the computer database, so identity numbers are important in order to identify each customer. There will be no more than 200 customers in total, so three digits could be enough for the identity numbers.

Req. 5.  The dealer should be able to add new units or customers to the system. He should be able to  modify, browse, or delete the existing ones.

Req. 6.  The dealer could send existing units to existing customers at any time. This process is done in two steps: the first, the customer requests to see some stamps from a particular country (category) and gives a preferred date for receiving these stamps. The dealer opens a request transaction for the customer and notes the categories needed, with the date. If this is not the first request for the customer, then the dealer notes the cost of previous stamps sold to the customer to provide a check on the customer's usual purchasing habits.

Req. 7.  When the dealer wants to send stamps to customers the system should suggest the first order to be done. The suggestion comes from the first due date of the requests, but the dealer should also be able to examine the order and select any request from the list.

Req. 8.  The system should be able to display a customer's record (number, name, and address). Some useful information must be displayed with the customer record, this is the total number of orders the customer has made previously and the total value stamps purchased by the customer. This will give an indication about the customers previous purchasing record to allow the dealer to send him/her a suitable number of units.

Req. 9.  The system should suggest the units to be sent to the customer, which should be different from those sent during the last six month's transactions with that customer. These units should, naturally, be available from stock and also from the same category requested by the customer. This suggestion will assist the dealer in sending suitable units that had not been sent before to the customer. This must be flexible and allow the dealer to select from the units sent to the customer before if he prefers.

Req. 10.  The replies from a customer with his/her next request and the send to customer process should be repeated until the dealer deletes the customer from the system.

Non-functional requirements.

NFR.1.
Reliability.
NFR. 1.1. The system should fail - that is crash - no more than 1 time in any 8 hour period.
NFR. 1.2. The system functions need to be 100% accurate.

NFR. 2.
Usability. User profile: minimal experience of PCs, with basic experience of simple documents and letters using WordPerfect. Basic knowledge of file management through Windows 3.11 (save, copy, delete, subdirectories).

NFR. 2.1 Task: Create new customer details - achieved within 2 minutes with no more than 4 errors (other than mistypes) in 50 trials.
NFR. 2.2. Task: Create a set of new units - achieved within 2 minutes with no more than 4 errors (other than mistypes) in 50 trials.
NFR. --- other appropriate tasks identified with suitable target performance criteria.

NFR. 3.
Efficiency.
NFR. 3.1. On the intended platform the system should load up within 15 seconds.
NFR. 3.2. The browsing  for customer names  through 100 customer records should take no more than  30 seconds.
NFR. 3.3. The response of the system to a query (Req. 7.) should take no more than 30 seconds when the database has 100 customers and 400 units.

NFR. 4.
Maintainability.
NFR. 4.1.Full formal documentation is required - this includes design information, formal specifications, testsets and test reports..
NFR. 4.2. The system should have clearly defined modular software architecture to permit future modles offering extra functionality to be integrated at a later date.

NFR. 5.
Portability.
No portability requirements are identified,

Interface requirements.
The screen shots and the order in which they are organised would also be required. This latter information would be provided in an English commentary.

Remarks.
As described in the book this system was formally specified, the specification used to generate test sets, implemented in Visual basic on and Access database. It took 3 man months to develop and was delivered on time. It has been operational for over 2 years, has been in daily use and no bugs have been reported. later on an automated back-up facility was built and integrated into the system and a more sophisticated style of report/letter generated for use with the system.