Case Study: Generic Sales Order Processing System

Case Study: Sales Order Processing System

Background

Most of the case studies require some form of sales order processing.

Use the attached material to generate a generic sales order processing system.

Or consider improving existing ICA case studies to incorporatedthe attached material.

Generic functions are covered by the Core Module diagram below. These are also the modules to consider when extending the ICA case study requirements

Most systems will require some or all of the following tasks…..there may be more!

In addition also consider the ADMIN functions of the system.

There are many ways to organise the functional requirements. Here are some examples:

Example 1

Site Administration
Logging in to Admin
Changing Admin Login and Password
Adding/Changing company logo
Changing Company details
Changing Colour of Website
Changing About Us Page
Changing Terms and Conditions Page
Changing Delivery Page Details
Change Credit Card, Free Delivery and VAT settings
Products
Change Product Information
Add a New Product
Product Selection and Pricing
Selecting Types and Categories and Setting Margins
Show Map of Website by Categories
Show Map of Website by Manufacturers
Custom Pricing by Product
Special Offers Page
Customer Administration
Adding a New Customer
Customer Maintenance
Automatic Email Facility
Emailing your Customer database
Reports and Order Tracking
Sales Report with Order Detail
Total Sales Summary by Customer or Date
Product Usage Summary by Customer or Date

Example 2

Customer:
Sales
Quote
Order
Despatch (EPOS and/or Tracking)
Invoice
Returns

Supplier:
Purchase
Quote
Invoice
Product / Price Catalogues
Returns

Admin:
Product Maintenance
Accounts Maintenance (for suppliers and customers)
Reports
Report Templates
Backup & Restore

Also consider identify sub-events (event partitioning for major events

1.1 Sales processing

1.1.1 Log new customer

1.1.2 Amend customer details

1.1.3 Customer requests quote

1.1.4 Customer generates an order

1.1.5 Customer makes payment

Etc

2.1. Purchasing

2.1.1 Log new supplier details

2.1.2 Amend supplier details

2.1.3 Supplier makes delivery

etc

Example 3

Some more ways to start event partitioning systems (used in last years ICA: PowerQuotes)

1. Quoting

2. Invoicing

3. Purchase Order

4. Products

5. Contacts

6. EPOS

7. Tracking

8. Returns

9. Report Designer

Example 4

Generic Functions:

Consider developing generic DFD function models which can be combined to formulate a full system DFD.

ASCENT FILES / genLOGIN.ASC
Terms of Reference / Login Function
Statement of Purpose: / A generic login function
Requirements: /

allow users to login
obtain forgotten password
validate login
register new user

Context Diagram Description
A user may login to the system by providing the userid and password. These details are validated against a user list. Valid users are granted access rights and invalid users are notified. Users may request a forgotten password which is emailed to the users registered email address. New users may apply for a userid and password.

Context Diagram : LOGIN

Events List:

User submits userid and password
user request password (forgotten)
New user registration

SHOPPING BASKET Function – Context Diagram

ASCENT FILES / genBASKE.ASC

Context Diagram : SHOPPING BASKET (generic)

DFD Top Level : SHOPPING BASKET (generic)

PRODUCT SEARCH Function – Context Diagram

ASCENT FILES / genPRODU.ASC

Context Diagram : (generic)

DFD Top Level : PRODUCT SEARCH (generic)

Example 5

If you come across features of a system you like you can consider backwards development to produce a system model. The following has been produced as a backwards model for PC-Worlds web site. Goto and review their system. Develop a PC World DFD model.

ASCENT FILES
PCW.ASC

Draft Context Diagram

Draft TL-DFD Diagram