2.1 Data Objects (internal data tables)
Design Specification Document For A Client/Server Purchasing System
March 24, 1998
by Pat Ellis, Bill Miller, An Q. Nguyen, Al Williams
Design Specifications for Client/Server Purchasing System by NU Software
1. Introduction
NU Software will develop a comprehensive client/server application that will have a web interface for external customers and 32 bit graphical user interface for internal employees. Both interfaces will interact with a server based database for ordering personal computers. This product will be designed for a company who specializes in selling business PC's, and networking solutions to wide range of both small and large customers. The company arranges to be the sole provider of all computer equipment for its customers, and in return provides its customers with discounted pricing, reliability, and added services. One of the services the company wishes to provide is an on-line ordering system where their customers may order new computer systems, or computer components, through the Internet. This will service will give their customers the opportunity to order new equipment at their convenience, and allow the customer to browse through the companies complete on-line catalog of products. At the same time, company wants the same ability to interface with its on-line catalog from their office. This will allow the company to more effectively take phone orders for new equipment.
The Purpose of the design specification documentation, hereafter known as DSD, is to describe in detail the interface design, function and limitations of the software application designed by NU Software. This DSD is designed for the engineers and software developers who will be assigned to develop NU Software’s product.
This software application developed by NU Software herein will be known as "Corporate PC".
Corporate PC will be a 32 bit client/server application that will have a customer web-based browser interface that is external and PC based interface for clerical use that is internal. The web interface will allow a company's external customers to order products via a series of drop down menus over the web. The web interface will interact with an internal database that will generate the customer's order. Once the order has been placed, it will be evaluated for credit approval. After credit approval, the order will be rejected (with a subsequent rejection letter sent) or approved and a pick-list is generated. Once the pick-list is generated the order is assembled and then shipped to the customer via a land based forwarder.
The internal clerical interface is for orders that are sent in via phone or fax. The internal interface is similar in function to the web interface with some differences. The internal interface will also allow the clerical worker to enter and update relevant customer information. Also, the credit standing will be readily apparent to the clerical worker.
The server-based database will hold information as it relates to customer contact, shipping information and company products offered. It does not contain a comprehensive accounting package for managing Accounts Payable, Accounts Receivable or General Ledger activity. Also, Corporate PC does not have a Procurement function. These features should be obtained through third party application components.
The web interface will support browsers that are non-Java and non-frames enabled. The internal clerical interface will be in a 32 bit environment and will support Windows 95 and NT 4.0 as the PC operating system. The server side database will be supported only with NT Server 4.0.
1.3.1 Definitions
Accounts Receivable - Accounting department that receives customer payments
Client/Server - System architecture whereby a variety of computer hosts can send to and receive from the server centralized data that is shared.
Discount Rate - Pricing will be based on discount on gross invoice total
Frames - A window partition formatting for HTML pages.
General Ledger - Theory of double entry bookkeeping in which all accounting transactions are recorded in separate accounts broken down by category.
Java - A programming language that relies on a "virtual machine" to be resident on the client.
Just in Time - An inventory methodology in which inventory is maintained for only for the orders on hand.
Internet Latency - The amount of time between packets of information traveling via the Internet.
Pick-list - List of products ordered per customer that the warehouse must physically pull from inventory
1.3.2 Abbreviations
CPCS - Corporate PC System
DB - Database
DO - Same as above
DSD - Design Specification Documentation
GUI - Graphical User Interface
MS - Microsoft Corporation
N/A - Not Applicable
NT - Microsoft Windows NT Workstation 4.0
NTFS - NT File Structure
OS - Operating System
PC - IBM compatible personal computer
SP3 - Service Pack 3
SRS - Software Requirement Specification
SSL - Secure Socket Layer for secure Internet connection
VB - Visual Basic
The Institute of Electrical and Electronics Engineers, Inc., IEEE Recommended Practice for Software Requirements Specifications, 1994
Roger S. Pressman, Software Engineering A Practitioner’s Approach, McGraw-Hill 1997
Pat Ellis, et all., Software Requirement Specification for Client/Server Purchasing System, February 28, 1998
1.5 Overview
The rest of the SRS will contain the following:
Section 1 Overview
This will give a general overview of the layout of the DSD including the purpose, the scope of the project, and a description of the project. Also, a list of definitions and abbreviations are included to increase the readability of the DSD.
Section 2 Data Design
This section describes the major data objects and data structures of the system that are both internal and external.
Section 3 Architectural Design
This section details the system architecture with the System Architectural Diagram that shows the module hierarchy. Also there is the module description, which shows the inputs/outputs of the each module. The procedure design language is a pseudocode of the software processes of the system. Lastly, the internal data structures are logical representations of the internal databases.
Section 4 Interface Design
The Interface Design section gives a complete description of the user interface of the system. Included are screenshots of the web interface and the internal "clerical" interface and descriptions of the form objets. Also, there is a description of the external interfaces including hardware, other software packages and communication.
Section 5 Requirements Cross Reference
The requirements cross reference compares the functional requirements of section 3.2.1 of the SRS for this system dated February 28, 1998. This compares the requirements of the SRS to the DSD modules that will address those issues.
Section 6 Test Provisions
The test provision section details the test parameters of the different modules in the system. Most notably is testing the data entered to see if matches the correct data type.
Section 7 Design Constraints
The assumptions and dependencies are listed here. Many of the items listed are due to the constraints of the systems high dependency of third party software.
Section 2 Data Design
This section describes the major data objects and data structures of the system that are both internal and external.
2.1 Data Objects (internal data tables)
2.2 External Database
Parts Data Base
| Part# | Part# | Pre-Built# | |
| Manufacture | Price | Price | |
| Type | Quanitity | Quantity | |
| Description | Description |
Customer Data Base
| Cust# |
| Cust Name |
| St. Address |
| City |
| State |
| Zip |
| Discount Rate |
Section 3 Architectural Design
This section details the system architecture with the System Architectural Diagram that shows the module hierarchy. Also there is the module description, which shows the inputs/outputs of the each module. The procedure design language is a pseudocode of the software processes of the system. Lastly, the internal data structures are logical representations of the internal databases.
3.1 System Architecture Diagram
/* Definitions */
DEFINITION TRUE 1
DEFINITION BAD 0
DEFINITION GOOD 1
CONST LINELIMIT 20
/* Data Structures */
TYPE part is STRUCTURE DEFINED
part desc. is STRING
stock qty is INTEGER
unit price is REAL NUMBER
END part TYPE
TYPE customer is STRUCTURE DEFINED
cust name is STRING
st address is STRING
city is STRING
state is STRING
zip code is STRING
discount rate is REAL NUMBER
END customer TYPE
TYPE order is STRUCTURE DEFINED
part# is STRING
order qty is INTEGER
b/o qty is INTEGER
ship qty is INTEGER
END order TYPE
TYPE credit is STRUCTURE DEFINED
order# is INTEGER
credit is BOOLEAN
END credit STRUCTURE
TYPE cust order is STRUCTURE DEFINED
order# is INTEGER
Complete Status is BOOLEAN
BO Status is BOOLEAN
END cust order TYPE
GLOBAL VARIABLE
Parts is ARRAY of type part
Customers is ARRAY of type customer
Orders is ARRAY of type order
Cust_order is ARRAY of type cust order
Credit is ARRAY of type credit
/* ----------------------------------------------------- */
PROCEDURE cpcs executive
INTERFACE RETURNS no value
REPEAT UNTIL SUBMITS or ENDS PROCEDURE
CASE OF user choice
WHEN user choice = "web order"
CALL order admin
WHEN user choice = "check stock status"
CALL get stock status
WHEN user choice = "phone order"
CALL order admin
WHEN user choice = "confirm shipped order"
CALL confirm ship order
ENDCASE
ENDREPEAT
END cpcs executive
/* ---------------------------------------------------------- */
PROCEDURE confirm ship order
/* This procedure requires manually input of data. The operator must know the
which order is completed before hand. */
INTERFACE RETURNS no value
REPEAT UNTIL USER SUBMITS or EOF
PROMPT USER for Cust_order.Complete Status
READ Cust_order.Complete Status
ENDREPEAT
END confirm ship order
/* ---------------------------------------------------------- */
PROCEDURE order admin
INTERFACE RECEIVES: customer# and order#
INTERFACE RETURNS no value
CALL accept order
CALL prove cust status(customer#, order#)
END order admin
/* ----------------------------------------------------------- */
PROCEDURE get stock staus
/* this procedure is to help the customer to know which part# they
need to have in their order. */
INTERFACE RETURNS no value
LOCAL VAR:
USER_STOP: BOOLEAN
partdesc. is STRING
stock qty is INTEGER
unit price is REAL NUMBER
REPEAT UNTIL USER_STOP
PROMPT USER FOR part#
READ part#
GET part#, partdesc, stock_qty from External Database
DISPLAY part#, partdesc, stock_qty
ENDREPEAT
END get stock status
/* ------------------------------------------------------------ */
PROCEDURE accept order
LOCAL VARIABLE: Line_Item# is INTEGER
INTERFACE RETURNS no value
GET SYSTEM GENERATED order.order#
Initialize Line_Item#
REPEAT UNTIL user SUBMITS or ENDS PROCEDURE
CASE OF user choice
CALL pre-built(Orders.order#, *Line_Item#)
WHEN user choice = "parts only" SELECT
CALL parts only(Orders.order#, *Line_Item#)
ENDCASE
ENDREPEAT
END accept order
/* --------------------------------------------------------- */
PROCEDURE pre-built
INTERFACE RECEIVES Cust_Orders.order#
Line_Item# by reference
RETURNS no value
Orders.order#=Cust_Order.order#
REPEAT UNTIL user SUBMITS or ENDS PROCEDURE or Line_Item# > LINELIMIT
READ (Orders.order#).part#
READ (Orders.order#).order qty
Line_Item# ++
ENDREPEAT
END pre-built
/* ------------------------------------------------------------------------- */
PROCEDURE custom built
INTERFACE RECEIVES Cust_Order.order#
Line_Item# by reference
RETURNS no value
Orders.order#=Cust_Order.order#
REPEAT UNTIL user SUBMITS or ENDS PROCEDURE or Line_Item# > LINELIMIT
READ (Orders.order#).part#
READ (Orders.order#).order qty
Line_Item# ++
ENDREPEAT
END custom built
/* ------------------------------------------------------------------------- */
PROCEDURE parts only
INTERFACE RECEIVES Cust_Order.order#
Line_Item# by reference
RETURNS no value
Orders.order#=Cust_Order.order#
REPEAT UNTIL user SUBMITS or ENDS PROCEDURE or Line_Item# > LINELIMIT
READ (Orders.order#).part#
READ (Orders.order#).order qty
Line_Item# ++
ENDREPEAT
END parts only
/* --------------------------------------------------------------- */
PROCEDURE prove cust status
/* this procedure will check the credit status of an existing customer
and then based on the status, processes the order accordingly. */
INTERFACE RETURNS no value
PROMPT USER for Customers.cust#
If ((Credit.Customer#).credit status = BAD )
CALL Print_Reject_Letter(Customer#, Order#)
else
CALL Process_Order(Customer#, Order#)
}
END prove cust status
/* -------------------------------------------------------------------- */
PROCEDURE Print_reject_Letter(Customer#, Order#)
INTERFACE RECEIVES: Customer# is type STRING
Order# is type INTEGER
RETURNS no value
Merge Customers information into the letter form
Print the letter
END Print_reject_Letter
/* ---------------------------------------------------------------------- */
PROCEDURE Process_Order(Customer#, Order#)
INTERFACE RECEIVES Customer#, Order#
RETURNS no value
LOCAL VARIABLE Back_Order is type BOOLEAN
Line_Item# is type INTEGER
Initialize Line_Item#
Back_Order = NO
WHILE ((there is a line item on Orders.Order#) AND (Line_Item# < LINELIMIT)
{
If ((Orders.order#).part# in NOT in Internal Database)
then
/* now part is in Internal Database */
If (Orders.orderqty <= Parts.stockqty)
then
{ Orders.backorderqty = 0
Orders.shipqty = Orders.orderqty
Parts.stockqty -= Orders.orderqty
}
else /* order qty > stock qty */
{
If (Parts.stockqty > 0)
then
{
Orders.backorderqty = Orders.orderqty – Parts.stockqty
Orders.shipqty = Parts.stockqty
Parts.stockqty -= Orders.orderqty
}
else /* now stock qty already negative */
{
Orders.backorderqty = Orders.order qty
Orders.shipqty = 0
Parts.stockqty - = Orders.orderqty
}
Back_Order = YES
}
END WHILE
If (Back_Order == YES)
then Cust_Order.BOstatus = YES
else Cust_Order.Bostatus = NO
CALL Print pick list (Customer#, Order#)
END Process_Order
/* ----------------------------------------------------------------- */
PROCEDURE Print pick list(Customer#, Order#)
INTERFACE RECEIVES Customer#
Order#
INTERFACE RETURN no value
If (Cust_Order.BO status = NO) AND (Credit.credit status != BAD)
then
{ Merge information from Customers, Orders, and Parts to the form
Print pick list
}
END Print pick list
/* -------------------------------------------------------------------------- */
3.2.3 Internal Data Structures
Section 4 Interface Design
4. Interface Design:
The CPCS has been designed with both physical and logical user interfaces.
The physical interface is twofold:
The logical interface, facilitates customer/user browsing via web-site (http://www.wmiller.com/cpcs/) to view a PC parts catalog. It will also enable established customers to requisition either a pre-built PC system(s)or customized PC system(s) and/or PC parts.
4.1 User Interface Specification
For any one instance of the user interface it is based on a point and click access system for each function. A mouse or another suitable pointing device is used to click various 'buttons' that correspond to various system functions. These interface designs are not unlike that seen in popular Microsoft Windows applications.
To select functions, the user simply has to 'point and click'. Manipulation of text data will then be done using the keyboard. This type of graphical interface was chosen to make the system unimposing and user friendly. The chief goal of the interface design team was to build a system interface that most individuals could utilize with minimal training. A good system is one that gets used!
The system has a main dialogue screen that enables the user to select primary function groupings. These groupings are identical to those found in section two of this document. Whenever a particular function grouping is chosen, a screen particular to that group will be displayed, allowing the user to direct data processing as required. When a particular function is exited, the system will return to the main selection screen. It should be noted that unless the user chooses to exit a particular function screen, the system will remain active at the screen. This feature was chosen to facilitate ease of performing multiple iterations of the same task.
4.1.1 Screen Name: Administrative Clerk/User Screen:
data base.
screen and to close the screen.
get to the individual fields one should use the tab button.
Records the following information:
Order Number
Customer Number
Name
Address
City
Zip Code
Phone number
screen and to close the screen.
Submits the following information:
Order Number
Customer Number
Customer Name
Pre-Built System
This screen allows you to perform the following functions:
Label Parts:
screen and to close the screen.
Submits the following information:
Order Number
Customer Number
Customer Name
CPU
Motherboard
SCSI
RAM
SoundBoard
HardDrive1
HardDrive2
Monitor
VideoAdapter
CD-ROM
OperatingSystem
Joystick
screen and to close the screen.
Submits the following information:
Customer Number
Customer Name
CPU
Motherboard
SCSI
RAM
CD-ROM
SoundBoard
Speakers
Monitor
OperatingSystem
4.1.2 Screen Name: Shipping Clerk/User Screen:
three additional buttons as follows:
screen, cancel the operation and close
the screen.
Displays the following information:
Order Number
Customer Number
Customer Name
4.1.3 Page Name: Website Customer/User Screen:
Invokes the following:
Image: http://www.wmiller.com/cpcs/order.gif
Image: http://www.wmiller.com/cpcs/demo.gif
Image: http://www.wmiller.com/cpcs/Email.gif
Image: http://www.wmiller.com/cpcs/cpcs.gif
Invokes the following:
Encoding: application/x-www-form-urlencoded (default)
Method: Post
Image: http://www.wmiller.com/cpcs/
Page Name: CPCS Ordering System Invokes the following pages:
http://www.wmiller.com/cpcs/order_splash.htm
Action URL: http://www.wmiller.com/cpcs/
Method: Post
Form 2:
Action URL: http://www.wmiller.com/cpcs/
Method: Post
Form 3:
Action URL: http://www.wmiller.com/cpcs/
Method: Post
Form 4:
Action URL: http://www.wmiller.com/cpcs/
Method: Post
The other field will receive a desired quantity.
Submits the following information:
Form 1:
Encoding: application/x-www-form-urlencoded (default)
Method: Post
Form 2:
Pre_built.htm
Method: Post
Invokes the following pages:
http://www.wmiller.com/cpcs/Customer_order.htm
Form 1:
Encoding: application/x-www-form-urlencoded (default)
Method: Post
Form 2:
Customer_order.htm
Method: Post
Invokes the following pages:
Form 1:
Encoding: application/x-www-form-urlencoded (default)
Method: Post
Form 2:
Encoding: application/x-www-form-urlencoded (default)
Method: Post
4.2 External Interface Specification
The CPCS has a GUI interface operating within a 32 bit environment and must be supported by Windows 95 and Windows NT workstation version 4.0 with service packs 1 or 3.
4.2.2 Communication Interfaces
The CPCS will provide an interface for both a telecommunications and internet connection.
The hardware interface has two aspects.
Section 5 Requirements Cross Reference
The requirements cross reference compares the functional requirements of section 3.2.1 of the SRS for this system dated February 28, 1998. This compares the requirements of the SRS to the DSD modules that will address those issues
SRS Requirement | DSD Implementing Module |
| As stated, the system shall use a friendly graphical user interface to assist a customer to make an inquiry to the system for a product by providing either a pre-defined product identification (ID) number or a description of a product. | Phone Order and Website Order |
| Based on the information provided by the customer, the system shall respond to the query by showing both the product ID number and its description, along with the listing unit price. | Get From Ext Database Stock Status |
| In case of an incorrect product ID number entered, the system shall prompt an error message, and let the customer try again. | Prove Cust Status |
| The system shall also provide the customer some pre-determined lists of products, grouped by product types, in order to ease the searching process for the customer. All they have to do is to choose the product they want to order from the lists. | Design Implementation |
| Once the customer knows what to order, the system shall let the customer submit their pre-assigned customer number. Customers without a valid customer number shall not be able to place an order at the time, and they must go through a separate process to obtain a customer number, which is not in the scope of this system. | Prove Cust Status |
| The system shall allow customers with a valid customer number to order up to 20 different line items per order. | Process Order Controller |
| With a valid customer number provided, along with the information of the products on order, the system shall accept the order for further process, and issue a unique order number to the customer for reference | Process Order Controller |
| In regard to the customer’s credit status with the seller, the system shall either issue a rejection letter or a notification: | Prove Cust Status |
Section 6 Test Provisions:
6.1. Objectives of the Test Plan:
This test plan is designed to verify the logic used in the implementation of the Client/Server Purchasing System, also known as Corporate PC. The test will help software developers to ensure the correct program flow, and to determine the error-handling capability of the system.
6.2. Modular Testing:
6.2.1.Main Menu Testing:
. Objective: To ensure that the system will be able to choose a correct interface depending on the initial request.
. Tests:
6.2.2.Validity test of customer number:
. Objectives: To ensure that only valid customer numbers will be accepted by the system.
. Tests:
6.2.3.Different line items on an order:
. Objectives: To ensure that an order can have one, or two, or many different line items.
. Tests:
Every time exiting an order, the system should record the order into the internal database correctly.
6.2.4.Maximum number of line item:
. Objectives: To ensure that the customer will not enter more than the maximum number of line items on one order.
. Tests:
6.2.5.Customer credit status:
. Objectives: To ensure that the order originated by a customer with a bad credit status will not be processed to ship, but a rejection letter will be sent instead.
. Tests:
6.2.6.Back Orders:
. Objectives: To ensure that any available quantities will be allocated to the items on order, stock quantities will be accounted for appropriately to reflect the back order quantities, and a pick list will not be generated.
. Tests:
Request a new order. Enter 2 part numbers with quantities less than the available quantities, and 1 part number with quantity greater than the available quantity. The system should mark this order as back order, change the stock quantity of the item on back order (item# 3) correctly (to a negative number,) and put this order on hold.
Section 7 Design Constraints
This section contains the design constraints and assumptions that were made by the designers of CPCS. Some of the provisions below are forced due to the high dependency on third party software.
7.1 Constraints
Interfaces to other applications - Must be 32-bit operating system. 16 bit applications may not be compatible.
Parallel operations - web server must run with database server.
Higher-order language requirements for customer server client must have language specific run time dynamic link library.
Criticality of the application - though this application will be a tremendous benefit to both the customer service and the web clients, manual disaster recovery operations may be implemented at any time due to software system failures.
7.2 Assumptions and dependencies
Because of the use of third party products such as Microsoft Access and Microsoft SQL server, all operating system requirements as stated previously in the DSD will need to be strongly followed.
