Requirements Specification
This is to give you an idea of how to arrive at a requirements specification.
Acme Widgets Inc is an hypothetical company whose management wanted to do things the easy way. They wisely decided to contact Database Applications and see what can be done.
High level overview
Acme makes widgets and sells these to customers who resell them. The customers place orders for widgets which Acme fills from stock. Infrequently, it takes several shipments to fill one order.
What Acme wants
Acme wants orders to be placed online. Warehouse staff then will look at incoming orders and make up shipments. Widgets placed on a shipment will be taken out of the existing stock and the stock number for that widget will be decremented with the number of widgets on that shipment. If a predetermined level is reached, a warning that that widget should be replenished will be displayed. A shipment ready for shipping will be marked as such.
The shipping department will look at all shipments ready for shipping, but not yet shipped. These will be shipped and marked as such.
Acme wants to be able to see:
- Orders by customer by dates - orders for one or all customers between any two dates
- Same as above, but only those orders not yet fully filled
- Inventory levels
- Unpaid, filled orders
- All payments for all orders and payments by order
Data Objects
After some head scratching and with some prompting, Acme came up with the following data objects:
- Customers
- Orders
- Line Items
- Shipments
- Payments
Customers
Acme said customer data should be "the usual". This is what "the usual" turned out to be:
- Name of company (text)
- Description (text)
- Tel No (text)
- Fax (text)
- Email address (text)
- Street Address (text)
- Suburb or town (text)
- Post code (text)
- State (text)
- Any number of notes about this company
- Any number of contacts in this company
Orders
- The date of this order (date)
- Connections to the company from whom it came, the line items on it, the shipment details and payment details
Line Items
- Part No (text)
- Description (text)
- Formal spec sheet for downloading (document)
- Price (decimal)
- Number in stock (integer)
- Dates of replenishment and the number of the replenishment with each date
Shipments
Shipments can be for part of one order, one order, several orders in whole or in part.
- Date and time ready to be dispatched (timestamp)
- Date and time shipped (timestamp)
- Destination - just "customer" if shipped to the customer (text)
- Connections to the order or orders and the line items contained in this shipment
Payments
A payment can be for part of one order, one order, several orders in whole or in part.
- Date of payment (date)
- Amount of payment (decimal)
- Type of payment - cheque, direct deposit, etc. (text)
- Connections to the order/orders for which this payment is
Something missing?
You will notice that nothing is mentioned about wheter an order was fully shipped or fully paid. One can use check boxes for these, but that leads to problems. It means an order will be reagrded as fully paid or fully shipped if the correct box has been ticked, and not when it really was fully paid or fully shipped. The program can look at the total cost of an order and all payments against the order to determine if it has been fully paid. Similarly, it can look at all line items on the order and all line items on shipments for this order to determine if it has been fully shipped. The probability that the computer will make an error is far, far less than the probability of a human making an error.
Of course, "company notes" and "contacts" are data objects as well. They have the right relationship with their owning data objects.
Please contact us for more details.