3.2 software design specification · web viewfor the back end, the sms will use ms sql because it...

Sales Monitoring System Chapter 3

3.2 SOFTWARE DESIGN SPECIFICATION

3.2.1 Introduction3.2.1.1 Goals and Objectives

The Sales Monitoring System (SMS) is developed to incorporate the

problems existing on the merchandising industry. However, the proposed

solution won’t be enough effective unless incorporated with proper and correct

implementation.

The following are the goals and objectives of the proposed system:

To know and identify the business process and problem of the existing

system.

To get the right quality, right quantity of supplies, at the right time, at the

right place and for the right cost.

To create a user friendly interface to use for the employees.

To improved system security and prevention of unauthorized personnel in

accessing the data.

To improve the accuracy calculation of data by allowing just entering data

required and hence the system would handle that calculation.

To ensure data security by producing backups of data/information in

different ways.

Organization savings in consuming time and efforts.

Lessening of errors in inputting the records and reports.

Reward system for the customer.

Receives receipt generated by the supplier.

Graphical reports to monitor the sales of the business.

Project Study 2 82


3.2.1.2 Statement of Scope

This section contains the general description of the software functionality

followed by detailed requirements that will be traced throughout the project.

This system will improve and provide the security and accuracy in

handling goods sold as well as monitoring the inventory items by just entering

data required and the system would handle the calculation. It will enable easy

accessing and retrieving of required information rather than pursuing paper files.

Before gaining access to the SMS an employee will be required to enter

their user name and password. All the employees have the same authority when

using the system. Only the administrator has the supreme authority and will have

the unlimited access in the system.

The employee is the one responsible for creating the orders or the item to

be purchase. The item/s ordered will be delivered by the supplier with the

receipt. After receiving the item/s it will be added to the inventory of the system.

Regarding the item in the inventory, there will be physical count if the physical

count did not match in the inventory there will be loss of items. Another disposal

of the item is when the item is sold or by its warranty.

This system will also have a reward system for the loyal customer and to

those who get more of the products. When the customer earns reward they can

use these rewards to lessen their payments. If the customer avails 5 products

there will be given options to get the reward, it’s either the total payment will be

discounted if the customer choose the discount reward or will get a freebie

product if the customer choose to have a free item. There will be graphical

reports generated by this system.

Project Study 2 83


3.2.1.3 Software Context

The Sales Monitoring System is dedicated to most companies that use

sales monitoring system in handling business transaction. With this, company

may rely on a system that not only provide easy access but also provide a

secured system that would help the management to prevent furtive acts.

However, the management will be complacent that their business is safe when

they are not around. Having an advanced and computerized system in running

their business makes more productive, efficient, secure and convenient both to

their company and to its clients.

3.2.1.4 Major Constraints

The following are the software requirements of the proposed system.

Application DescriptionMicrosoft Visual Studio 2010 (C Sharp)

For the front end, All server side

code will be written in C Sharp.

Microsoft Structure Query Language (MS SQL)

For the back end, the SMS will

use MS SQL because it is the

compatible database application

for C#

The proposed system should be good enough to perform all the actions

fast. Listed below are the recommended requirements for the hardware.

Product Minimum RecommendedMonitor 15” 18”

Processor 1GHz Processor or

above

2 GHz

RAM 256 MB 1 GB

Project Study 2 84


Hard Disk Drive

Standard HD 2 GB

3.2.2 Data Design

To understand the data design of the proposed system it is important to

have looked at the overall design of the application. As the application is being

built in Microsoft Visual Studio (C Sharp) and Microsoft SQL the overall design

can be categorized into three parts based on the above mentioned application

developing languages.

Front End Graphical User Interface

Back End Data

Internal Functional Procedures

Graphical User Interface (GUI):C Sharp is a multi-paradigm programming language encompassing strong

typing, imperative, declarative, functional, generic, object-oriented (class-based),

and component-oriented programming disciplines. This application is being used

for the development of the front end GUI. The GUI components temporarily

stores the keyboard input by the users till its being used by the functional

procedures.

Back End Data:Microsoft SQL Server is a relational database management system

developed by Microsoft. As a database, it is a software product whose primary

function is to store and retrieve data as requested by other software applications,

be it those on the same computer or those running on another computer across a

network (including the Internet). There are at least a dozen different editions of

Microsoft SQL Server aimed at different audiences and for different workloads

(ranging from small applications that store and retrieve data on the same

Project Study 2 85


computer, to millions of users and computers that access huge amounts of data

from the Internet at the same time).

The team use MS SQL database management system at the back end for

storing all information in the form of tables. These tables will be globally available

to all the internal procedures. The DBMS system will be locally available on the

machine where the application is running. However the same database can be

accessed remotely as well.

For adding, deleting, accessing, and updating the data we are using SQL

queries built in the internal procedures. Rest all the file and data management

functionality is being provided by the DBMS.

Internal Functional ProceduresThe internal functional procedures are the logical entities that carry out

different tasks of adding, updating, deleting, viewing, or printing the database. It

also provides a link between the GUI and the database. All server side code shall

be written in C Sharp.

3.2.2.1 Internal Data StructureThere are no data structures available to the internal software architecture.

When adding or updating, button is pressed the information in those text fields is

directly sent to the database for add or update. For report printing temporary

local variables have been defined in the procedures with meaningful names to

store different values and then print the report.

3.2.2.2 Global Data StructureThe only kind of data available globally to the whole system is the

database itself stored in Microsoft SQL. For more information regarding the

database stored refer to section 3.2.2.4 of the document.

Project Study 2 86


3.2.2.3 Temporary Data StructureSQL Server supports temporary tables. These tables have names that

start with the abbreviation of the proposed system (SMS). If a temporary table is

not dropped when a user disconnects, SQL Server automatically drops the

temporary table. Temporary tables are not stored in the current database; they

are stored in the tempdb system database.

There are two types of temporary tables:

Local temporary tables

The names of these tables begin with one number sign (#). These

tables are visible only to the connection that created them.

Global temporary tables

The names of these tables begin with two number signs (##). These

tables are visible to all connections. If the tables are not dropped

explicitly before the connection that created them disconnects, they are

dropped as soon as all other tasks stop referencing them. No new

tasks can reference a global temporary table after the connection that

created it disconnects. The association between a task and a table is

always dropped when the current statement completes executing;

therefore, global temporary tables are usually dropped soon after the

connection that created them disconnects.

Project Study 2 87


3.2.2.4 Database DescriptionThe following information shows the database tables and its attributes and

descriptions.

Table Customer

Attribute cusID, lname, fname, mname, birthdate,

contactno, address

Descriptio

n

This table holds all the information about the

customer.

Table User

Attribute userID, user_lname, user_fname, position,

birthdate, gender, username, password

Descriptio

n

This table holds the information of the

employee that was using the system.

Table Invoice

Attribute InvoiceID, SuppID, POid, Date, EmpID

Descriptio

n

This table holds the invoice from the supplier

giving it to the employer.

Table Order

Attribute OrderID, cusID, orderDate, PaymentType,

paymentNum, total, amount_rcvd, purquotID

Descriptio This table holds all orders and the date when

Project Study 2 88


n did the customers ordered.

Table OrderDetails

Attribute orderDetailsID, prodID, price, quantity,

subtotal, orderID, productCode

Descriptio

n

This table holds the details of the orders of the

customer.

Table Product

Attribute ProdID, Prodcode, Name, Quantity, Category,

WarrantyDate, Price

Descriptio

n

This table holds the information and the

quantity of the products.

Table PurchaseOrder

Attribute POID, purchaseCode, date, total, suppID,

purchase_status

Descriptio

n

This table holds the purchase order of the

employee and the company and the date when

did they create a purchase order.

Table PurchaseOrderDeatails

Attribute poDetailsID, prodID, poID, quantity, unit_price,

subtotal, product_code

Descriptio This table holds the details of the purchase

Project Study 2 89


n order and the quantity of the products ordered.

Table Supplier

Attribute SuppID, lname, fname, mname, birthdate,

contactno, address

Descriptio

n

This table holds all the information of the

supplier needed.

Table PurchaseQuotation

Attribute purquotID, date, total

Descriptio

n

This table holds the purchase quotation or the

preparation of the order of the customer before

he/she orders.

Table PurchaseQuotationDetails

Attribute purQuotDetailsID, prodID, purquotID, quantity,

unit_price, subtotal, product_code

Descriptio

n

This table holds the purchase quotation details

or the preparation of the order of the customer

before he/she orders.

Table Return

Attribute returned, suppID, poID, date, reason

Descriptio This table holds the products that should be

Project Study 2 90


n return to the supplier because of valid reason

like defective.

Table Reward

Attribute rewID, rewName, rewDescription, cusID

Descriptio

n

This table holds the rewards that could receive

by the valued customers.

Table Warranty

Attribute WarID, prodID, SuppID, ITID, years

Descriptio

n

This table holds the warranty of the products.

3.2.3 Architectural and Component Level Design

3.2.3.1 Architectural Diagram

The Architectural Context diagram for the system is shown below. Only

the employee from the left side of the view is the only one who can use the

system but as we detailed it, employee describes the admin of the system. The

subordinate systems that will be used by the system are the C Sharp

Programming Language (MS Visual Studio) and Database (MS SQL Server).

Maintaining the system is the most prioritize in this diagram so that whenever

bugs and other suspicious happenings would be resolve immediately and also

the system’s testing and maintenance purposes.

Project Study 2 91


Architectural Context DiagramThere are various types of architectures to represent the context. The

system architecture is one we described above as Architecture Context Diagram.

Also we included two application architectures: the call and return and object-

oriented architecture.

First, the call and return architecture is drawn. In this diagram, there is a

main function (the system) which calls the controller functions and these

functions further call the application functions. These functions then return the

required data information.

Project Study 2 92


The call and return architecture for the purchasing and inventory system is

shown below:

Figure 1 – Architectural Context Diagram

** Basic Info describes the Name and other important info about it.

The Call and return architectureThe Call and return architecture has a main program on it, which controls

all other functions. Basically it selects the functions describe below. The main

Project Study 2 93


program calls External communication management, which further calls the GUI

implemented in the project. And the other function’s returns some values that are

data. Also the user can call print reports, which will generate various reports

about the desired report of the user.

Object Oriented architecture (cont’d)

Project Study 2 94


Figure 2 – Object Oriented Architecture

3.2.3.2 Description of Components3.2.3.2.1 Component User/Employee

Project Study 2 95


3.2.3.2.1.1 Processing narrative of component EmployeeThe component employee contains the class employee. It contains the

attributes which are the basic information about the supplier and the customer.

The main function of this component is to declare the data information of the

employee and implementing functions which set data in the database and

retrieve from database.

3.2.3.2.1.2 Interface description of the component EmployeeThe component employee has an interface has an interface with the class

person from which it inherits the attributes, functions and all the related data on it.

3.2.3.2.1.3 Algorithmic expression of component EmployeeComponent Employee;

The intent of this component is to set the basic employee data into the database

and get the data from the database.

Start

Declare variables of the basic data

Set the basic data of the employee in the database

Get the data from the database

End

3.2.3.2.1.3.1 Design class hierarchy

3.2.3.2.2 Component Supplier

3.2.3.2.2.1 Processing narrative of component Supplier

Project Study 2 96


The component supplier contains the class supplier. It contains the attributes

which are the basic information about the employee. The main function of this

component is to declare the data information of the supplier and implementing

functions which set data in the database and retrieve from database.

3.2.3.2.2.2 Interface description of the component SupplierThe component supplier has an interface has an interface with the class


3.2.3.2.2.3 Algorithmic expression of component SupplierComponent Supplier;

The intent of this component is to set the basic supplier data into the database


Start


Set the basic data of the supplier in the database


End


3.2.3.2.3 Component Customer

3.2.3.2.3.1 Processing narrative of component Customer

Project Study 2 97


The component supplier contains the class customer. It contains the attributes

which are the basic information about the employee. The main function of this

component is to declare the data information of the supplier and implementing

functions which set data in the database and retrieve from database.

3.2.3.2.3.2 Interface description of the component SupplierThe component supplier has an interface has an interface with the class


3.2.3.2.3.3 Algorithmic expression of component SupplierComponent Supplier;

The intent of this component is to set the basic supplier data into the database


Start


Set the basic data of the supplier in the database


End


3.2.3.3 Dynamic Behavior for Component

3.2.3.3.1 Interaction Diagrams

Project Study 2 98


This is a sequence diagram where the use-case component is an

Employee. The first event, system ready, is derived from the external

environment and channels behavior to an Employee object. The employee then

Project Study 2 99


enters an ID and password. A request look up event is passed to the system that

looks up the ID and password in the system and returns a result (found or note

found) to Monitor. A valid password results in a password = correct event to the

system which then gives access to the employee and the employee now can

add/update/delete the data information which he/she decides on. And this data

information can be displayed on the monitor or printed from the printer up on

request.

3.2.4 User Interface Design

The application has a Graphical User Interface which is built completely in

ASP.NET forms. All of the required components of the .net forms and its sub

components are being used so that we would take advantage of the errors that

would happen in the future.

3.2.4.1 Description of the User Interface

3.2.4.1.1 Screen Images.

The GUI for the SMS has been kept quite simple and follows a readable

style. It is very user friendly but still for the better handling on the system the user

must undergo to the training so that the user must know well the system.

Below is a detailed images and description of the GUI. The object and

actions performed when you click them are also identified.

The first image is the login screen. The user is supposed to have a login

and password in order to login. Username and password can only be created by

the administrator (employee) of the company when he hires a new employee.

Project Study 2 100


After entering a valid username and password, the program verifies the

information entered. Upon verification, the program either allows you to log in or

a message will be displayed at that the login was not verified.

The system also checks whether the user is the administrator or

employee. Depending upon this information the program gives the respective

interfaces hence there by restricting user to perform any other task except that

can be performed by him/her.

Below is the homepage of the system. This interface is accessible only to

an employee that is on the task to use the system.

Project Study 2 101


This above GUI is self-explanatory. The employee that log on to the

system is supposed to click on any of the available options to add, update, or

access them. Once an employee click to any of the available options, another

GUI will appear that will have further option in any of the above category that has

been clicked.

Now for example is that when the user clicks on the forms on the system

setup, another GUI will appear as follows:

Project Study 2 102


Customer

Category

Project Study 2 103


Product

Supplier

User/Employee

Project Study 2 104


Warranty

Project Study 2 105


On the following GUI’s, the user is supposed to be viewing a form to add,

edit and delete on this form. The user must specify all the details to prevent error

related constraints.

Now for example is that when the user clicks on the forms on the

transaction, another GUI will appear as follows:

Purchase Order

PO Delivery

Project Study 2 106


PO Inventory

PO Returns

Project Study 2 107


Purchase Quotation

PQ Sales

Project Study 2 108


Inventory

Invoicing

Project Study 2 109


Reward

On the following GUI’s, the user is supposed to be viewing a form in the

transaction to add new transaction in each form, edit transaction in each form

and print reports on other form. The user must specify all the details to prevent

error related constraints.

After using the system, this is the verification is you click the log out in the

control panel at the left side part of the system.

Regarding the reports, the selected report form will appear. There are also

sub reports but the same kind of options window appears.

Project Study 2 110


3.2.4.1.2 Objects and ActionsThe above shown GUI has the Microsoft .NET components. A frame of

800 * 500 is being used as a container for the other components. The frame

consists of label for displaying text. Text fields for entering or editing text. And

command buttons are used for execution of procedures.

3.2.4.2 Interface Design Rules

To improve the usability of an application t is very important to have a

well-designed interface. The following characteristics we have used are shown

below:

Consistency of every interface.Consistent sequences of actions should be required in similar situations;

identical terminology should be used in prompts, menus, and help screens; and

consistent commands should be employed throughout.

Enable users to use shortcuts.As the frequency use increases, so do the user’s desires to reduce the

number of interactions and to increase the pace of interaction Abbreviations

function keys, hidden commands, and macro facilities are very helpful to an

expert user.

Informative feedback.For every operator action, there should be some system feedback. For

frequent and minor actions, the response can be modest while for infrequent and

major actions, the response should be more substantial.

Simple error handling.As much as possible, design the system so that the user cannot make

serious error. If an error is made, the system should be able to detect the error

and offer simple, comprehensible mechanism for handling the error.

Project Study 2 111


Reduce short-term memory load.The limitation of human information processing in short-term memory requires

that displays be kept simple, multiple page displays be consolidated, window-

motion frequency be reduced, and sufficient training time be allotted for codes,

and sequences of actions.

3.2.4.3 Components Available

.NET library have many components available and all these components

are being used so that error would be handle according to its functionality. More

components may be added in the future if necessary.

3.2.4.4 UIDS Description

No user interface development system has been used in the development

of the SMS.

3.2.5 Restrictions, Limitations and Constraints

The following are the restrictions, limitations and constraints of the

proposed system (SMS):

The system will automate the new process of purchasing and inventory by

creating the database of the system.

For the front end, the Microsoft Visual Studio (ASP.Net) will be used for

the development of the proposed system.

For the back end, the Microsoft SQL 2008 will be used for creating the

database of the proposed system.

All server side code shall be written in C Sharp.

All the employees have the same authority when using the system.

Project Study 2 112


Only the administrator (employee) has the supreme authority and will have

the unlimited access in the system.

3.2.6 Testing Issues

Class of Testing

Description Expected Software Response

Performance Bounds

Components to be

IdentifiedLogging on to

the System

This test class is

defined to validate

whether the user is

able to login with the

ID and password.

The specific

user will be

able to log-in

when he/she

enters the

user ID and

password.

The specific user

will not be able

to log-in when

he/she enters

the wrong user

ID and

password.

TestPurchase

Order

This test class is

defined to validate

whether all the

purchase order

details is being

displayed or not. All

functions related to

purchase order data

are called in this test

class.

This test will

print the

purchase

order

information

Employee,

Supplier,

Reports

TestPurchase

Quotation

This test class is

defined to validate

whether all the

purchase quotation

details is being


This test will

print the

purchase

quotation

information

Customer,

Employee,

Reports

Project Study 2 113



purchase quotation

data are called in

this test class.

TestInvoice This test class is

defined to validate

whether all the

invoice details is

being displayed or

not. All functions

related to invoice

data are called in

this test class.

This test will

print the

invoice

information

Supplier,

Employee,

Reports

TestInventory This test class is

defined to validate

whether all the

inventory

information is being



inventory data are

called in this test

class.

This test will

print the

inventory

information

Employee,

Supplier,

Reports

TestReturns This test class is

defined to validate

whether all the

returns details is

being displayed or

not. All functions

related to returns

data are called in

This test will

print the

reward

information

Employee,

Supplier,

Reports

Project Study 2 114


this test class.

TestReward This test class is

defined to validate

whether all the

reward details is

being displayed or

not. All functions

related to reward

data are called in

this test class.

This test will

print the

reward

information

Customer

Table 3.2.6.1 Testing Issues

Project Study 2 115

3.2 software design specification · web viewfor the back end, the sms will use ms sql because it...

Documents