DPSproject  Requirements Specifications

If you are not sure about the requirements or have other questions, ask Prof. Grossman (fgrossman@pace.edu) for clarification or additional information.

Your assignment is to:


Extend the attributes for an order and an invoice. The skeleton Java code you were given minimally represents this.

An order consists of the following information:
order ID  -  unique identifier for the order  (system generated)
customer ID - unique identifier for the customer (system generated)
order date - date order is entered
requested ship date - specified by the customer at order entry, modified by system
cancel date - specified by the customer at order entry, modified by system
bill to address - street, city, state, zip
ship to address - street, city, state, zip
billing terms - currently 2 options: net 10 days, net 30 days
order line(s):
  item ID - unique identifier for the item
  item description
  item quantity
  item price

An invoice contains all the data on the order except for requested ship date and cancel date, plus the following:
extended price - quantity * price
invoice date - date the order was shipped
payment due date - the invoice date plus the terms days, e.g. 10 or 30
invoice total - sum of extended prices

Note: Assume for this phase that the order is shipped on the requested ship date.

Business Rules:

The following four requirements specifications will ultimately have two structural components, a file maintenance function and the incorporation of the file into the main order processing system. First the file maintenance should be completed and tested. Then the integration with the system can be effected. The four files are: Customers, Products, Inventory and Open Orders. Initially, simply perform the file maintenance and later integrate the files into the system.

The Customers file contains the following attributes:

The CustomerID is a unique identifier for a customer. It is taken from a system controlled sequentially numbered sequence.
The ShipToAddress must be specified. If the BillToAddress is not specified it defaults to the ShipToAddress.
There is a DefaultBillingTerms. If  BillingTerms is not specified for a customer, use DefaultBillingTerms. Assume the default is NET 30 for now.

Assume the transactions for customers are in a file just as the orders are in a file for the current version of the system.
All transactions are to be edited and appropriate error messages output. The editing constraints are that they are of the correct type and are present if required to be.

The maintenance functions to be supported are:

The Products file contains the following attributes:

ItemID must be unique.
ListPrice, PriceEfectiveDate and ItemDescription must be specified.

Assume the transactions for products are in a file just as the orders are in a file for the current version of the system.
All transactions are to be edited and appropriate error messages output. The editing constraints are that they are of the correct type and are present if required to be.

The maintenance functions to be supported are:

The Inventory file contains the following attributes:

ItemID (i.e., the item) must exist in Products.
QuantityAvailableForSale must never be negative.

Assume the transactions for inventory are in a file just as the orders are in a file for the current version of the system.
All transactions are to be edited and appropriate error messages output. The editing constraints are that they are of the correct type and are present if required to be.

The maintenance functions to be supported are:

The OpenOrders file contains the following attributes:

All attributes come from the Order, i.e., if they exist on the Order they are put in the file. For example, OrderShipToAddress will only appear in the OpenOrders file if it was entered on the Order and is not taken from the Customers file. Input for this file comes from order entry.

Assume the transactions for open orders are in the order file for the current version of the system.
All transactions are to be edited and appropriate error messages output. The editing constraints are that they are of the correct type and are present if required to be.

The maintenance functions to be supported are:

Integrate the Products file and the Open Orders file into the Order Processing system. This development is being performed using eXtreme Programming (XP) methodology.
 

The Products file contains the following attributes:

ItemID must be unique.
ListPrice, PriceEfectiveDate and ItemDescription must be specified.

Assume the transactions for products are in a file just as the orders are in a file for the current version of the system.
All transactions are to be edited and appropriate error messages output. The editing constraints are that they are of the correct type and are present if required to be.

The maintenance functions to be supported are:

The OpenOrders file contains the following attributes: All attributes come from the Order, i.e., if they exist on the Order they are put in the file. For example, OrderShipToAddress will only appear in the OpenOrders file if it was entered on the Order and is not taken from the Customers file. Input for this file comes from order entry.

Assume the transactions for open orders are in the order file for the current version of the system. All transactions are to be edited and appropriate error messages output. The editing constraints are that they are of the correct type and are present if required to be.

The maintenance functions to be supported are:


The Product class must act as a server and must be able to verify that an ItemID exists (Product in file) and be able to return (separately)  to the client the List Price. The ListPrice is associated with a PriceEffectiveDate, so the ListPrice to be returned is that which is associated with the earliest date after the parameter date. For example if we have the following for an Item:

            PriceEffectiveDate            ListPrice
                11/15/00                            10
                12/15/00                            11
                12/25/00                            12

and the parameter date for this Item is 12/20/00, then the ListPrice returned would be 11.
 

Each ordered item is to be checked as follows:

The ItemID on the order must be a valid product. Each item on the order must be verified by asking the Product class whether an ItemID is valid. If an item on the order is not a valid product, an appropriate error message should be generated and the order item ignored. If the item is valid and if the Price is not on the order, the Item ListPrice should be obtained from the product class and entered into the order. The ListPrice has an EffectiveDate associated with it. The date used for the price should be the OrderDate. If there is at least one valid order item on the order, write the order to the Open Orders file.
 
This project phase is concerned with integrating the Customers file and the Open Orders file into the Order Processing system. This development is being performed using eXtreme Programming (XP) methodology.

Each order is to be checked as follows:

The CustomerID on the order must be for a valid customer, i.e., must exist in the Customers file. If the Customer on the order is not valid, an appropriate error message should be generated and the order is rejected. If the Customer is valid then the additional fields in the Order must be checked before the Order can be written to the Open Orders file.

The OpenOrders file contains the following attributes:

All attributes come from the Order, i.e., if they exist on the Order they are put in the OpenOrders file. For example, OrderShipToAddress will only appear in the OpenOrders file if it was entered on the Order and is not taken from the Customers file. Input for this file comes from order entry. However, all attributes not entered on the Order must exist as default values in some file. In this task, the defaults relating to Customer are Billing Terms, OrderBillToAddress and OrderShipToAddress. If these are not entered on the Order, they must be in the Customer file. They are not written to the OpenOrder file however. If any are missing, an appropriate error message should be generated and the order rejected. NOTE: The BillingTerms attribute will have a system default value of NET 10, Thus if there is no BillingTerms entered on the Order and there is no Customer BillingTerms value in the Customer file, then the NET 10 should be entered into the OpenOrder attribute BillingTerms. At appropriate times, e.g., invoice generation or Open Order Report generation, these values will be obtained from the Customer object associated with the Order.
 

This project phase is concerned with creating a GUI input for the Product file maintenance. This development is being performed using eXtreme Programming (XP) methodology.

The following story describes the actions for the GUI input for the Product file maintenance. The team must first design a GUI layout and have it approved by the System Owner (XP Customer) and the Big Boss.

Products File

The Products file contains the following attributes:

ItemID must be unique.
ListPrice, PriceEfectiveDate and ItemDescription must be specified.

All transactions are to be edited and appropriate error responses output. The editing constraints are that they are of the correct type and are present if required to be.

The maintenance functions to be supported are:

The GUI entry should not permit an invalid Product record to be created; either the corrections are made during entry or the transaction is cancelled.

There will be more than one price and effective date pair.

Assume that the first GUI will be an application rather than an applet.