A Toy Sales Order Entry & Processing System

I give below the functional specifications for a toy sales order entry and processing system. The specifications given are for the logical aspects of the system only, and therefore are, incomplete. They are also incomplete in that the behavior model is absent. They are given as illustrations only. They consist of:

  • Context diagram
  • levelled logical dataflow diagrams
  • Relation specifications for a Relational Database
  • Specifications for the dataflows
  • Process descriptions in raw prolog code. (Prolog is a relational language. The code is given
    here, since prolog code is generally easily grasped). The code given here, with very minor
    changes, should be executable.

I will not provide the physical DFDs below, since they are implementation dependent, and I have not based this toy system on any real-world accounting system.

We have yet to discuss the data models and databases. We will not be discussing programming aspects of systems. Therefore, the database specifications are given as a prelude to our class discussions on databases later in the semester. The code is given just for the purpose of appreciation.

We are talking about a very small firm that considers orders from customers for one item. You should be able to add bells and whistles as you wish. The situation considered is rather unrealistic, but it makes important points about specifications for an accounting system and its documentation.

Table of Contents

  • Context Diagram
  • Level 0 Logical Dataflow Diagram
  • Level 1 Logical DFD: Sales Order Entry Sub-system
  • Level 1 Logical DFD: Sales Order Processing Sub-system
  • Dataflow Specifications
  • Datastore Specifications
  • Process Specifications

Context Diagram: (Sales Order Entry & Processing System)

Level 0 Logical Dataflow Diagram:(Sales Order Entry & Processing System)

Level 1 Logical Dataflow Diagram:(Sales Order Entry Sub-system)

Level 1 Logical Dataflow Diagram:(Sales Order Processing Sub-system)

Dataflow Specifications

Syntax: dataflowName(attribute1, attribute2,…..)

order(CustomerName, CustomerAddress, Item, Quantity)
pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
weDontSell(CustomerName, CustomerAddress, Item)
sorryBadCredit(CustomerName, CustomerAddress)
approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
sorryNotInStock(CustomerName, CustomerAddress, Item)
acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
billOfLading(CustomerName, CustomerAddress, Item, Quantity)
invoice(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)

Datastore Specifications

Syntax:relationName(attribute1, attribute2,……)

priceList(Item, Price)
customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit)
inventoryMaster(Item, QuantityOnHand)
salesOrderMaster(CustomerName, Item, Quantity, OrderPrice)
billOfLading(CustomerName, Item, Quantity)
openInvoices(CustomerName, Item, Quantity, OrderPrice)
customer(CustomerName, CustomerAddress)
order(CustomerName, CustomerAddress, Item, Quantity)

Process Specifications:

Syntax:prolog clause
/*    Orders are priced by multiplying the quantity ordered by the */
/*    price for the item on the price list               */

pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
      if
         order(CustomerName, CustomerAddress, Item, Quantity),
         priceList(Item, Price),
         orderPrice is Price * Quantity.

/*  We don't sell the item ordered by the customer if such item   */
/*  is not on the price list                 */

weDontSell(CustomerName, CustomerAddress, Item)
      if
         order(CustomerName, CustomerAddress, Item, Quantity),
         not priceList(Item, _).

/*  A customer order for an item is approved if the order is priced         */
/*  and the account balance after the order is less than the credit limit  */

approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
      if
         pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
         customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit),
         NewBalance is Balance + OrderPrice,
         NewBalance < CreditLimit.

/*  A customer order is rejected on account of bad credit if the  */
/*  order is priced and the account balance after the order         */
/*  exceeds the credit limit for the customer                                  */

sorryBadCredit(CustomerName, CustomerAddress)
      if
         pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
         customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit),
         NewBalance is Balance + OrderPrice,
         NewBalance >= CreditLimit.

/*  A customer order is accepted if it is approved and the quantity on      */
/*  hand of the item ordered is at least as much as the quantity ordered  */

acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
      if
         approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
         inventoryMaster(Item, QuantityOnHand),
         QuantityOnHand >= Quantity.

/*  A sales order is prepared if a customer order is accepted  */

salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
      if
         acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),

/*  A bill of lading is prepared if a sales order is prepared   */

billOfLading(CustomerName, CustomerAddress, Item, Quantity)
      if
         salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice).

/*  An open invoice is prepared if a bill of lading is prepared  */

openInvoices(CustomerName, Item, Quantity, OrderPrice)
      if
         billOfLading(CustomerName, CustomerAddress, Item, Quantity).

/*  A customer's account is updated by adding the order price to the   */
/*  current balance in the account if open invoice is prepared               */

updateCustomerAccountsForInvoices
      if
         openInvoices(CustomerName, Item, Quantity, OrderPrice),
         retract(customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit)),
         NewBalance is Balance + OrderPrice,
         assert(customerMaster(CustomerName, CustomerAddress, NewBalance, CreditLimit)).

References

Alexander, C. (1971). Notes on the Synthesis of Form, 2d ed. Cambridge, MA: Harvard University Press.

Alexander, C. (1979). A Timeless Way of Building. New York, NY: Oxford University Press.

Eberhard, J. (1970) “We Ought to Know the Difference”, in Engineering Methods in Environmental Design and Planning, Gary T. Moore, ed. Cambridge, Mass.: MIT Press. pp.364-365.

Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, pp.231-274.

Horner, K. (1993). Methodology as a Productivity Tool, in Software Productivity Handbook, J. Keyes (ed), New York, NY: Windcrest/McGraw-Hill, pp.97-117.

Pressman, R. (1987). Software Engineering: A Practitioner’s Approach, 2d ed. New York, NY: McGraw-Hill.

Teague, L and C. Pidgeon. (1985) Structured Analysis Methods for Computer Information Systems. Chicago, Ill.: Science Research Associates.

Yourdon, E. (1989) Modern Structured Systems Analysis. Englewood Cliffs, NJ: Prentice Hall.

Yourdon, E. (1993). A Natural Productivity in Object-Orientation, in Software Productivity Handbook, J. Keyes (ed), New York, NY: Windcrest/McGraw-Hill, pp.97-117.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s