CHAPTER THREE SYSTEM ANALYSIS AND DESIGN 3.

1 DESCRIPTION OF THE EXISTING SYSTEM

For a retailer, like Goodies Supermarket, Point of Sale information system is critical to gathering and applying information effectively in today's ultra-competitive markets. It offers a wide selection of features to improve control of your business and save time spent on inventory, purchasing and accounting. The existing system is still majorly paper based as most of the processes are manual. The supermarket still does a manual count of stocks to determine stock levels and they have an accountant and a supervisor that monitors the sales and inventory of the supermarket. The features listed here are all available in the Goodies Supermarket though manually done. Manual count of the food, snacks, and drinks to be sold for a day is done, and recorded on a paper by the sales dept. Customer make an order based on the varieties of foods, snacks and drinks available, the order is punched in a cash register which automatically generate receipt manually, then issued to the buyer.

3.2

PROBLEMS OF THE EXISTING SYSTEM

Because we want to improve on the current operation of the existing system, we need to first identify the problems of the existing system. This problems are: Costs of production Respond to trends slowly Lack of Customer Service

Poor Marketing Manual control of the money

The main problem of the existing system are inventory doesn't match sales tallies. Sales are going unrecorded. Staffs are spending far too much time chasing mistakes instead of attending to customers. These and other problems are the reasons a business need to do away with its cash registers and step up to a point-of-sale (POS) system.

3.3

REQUIREMENT SPECIFICATIONS

A POS (Point-Of-Sale) system is a computer system typically used to manage the sales in retail stores. It includes hardware components such as a computer, a bar code scanner, a printer and also software to manage the operation of the store. The most basic function of a POS system is to handle sales. Problems arise when requirements are not precisely stated. Ambiguous requirements may be interpreted in different ways by developers and users. Manage sales and handle sales mean the same thing.

3.4

PROPOSED SYSTEM REQUIREMENTS

The interfaces required for the computerized point of sales system are on the physical level; Screen, keyboard and internet connection and on a logical level; GUI (Graphical User Interface), web services (functions to be described, data exchanged, PHP My SQL)

3.4.1 FUNCTIONAL REQUIREMENTS OF THE PROPOSED SYSTEM This requirement includes the Description of services / behaviors provided by the system. The following better explains the functional requirements in detail. 1 .The system must be able to accept payment with credit or debit card. 2. The system must sum customer purchase as they are made 3. The system must update the inventory as sales occur 4. The system should be able to handle sale transaction 5. The system should be able to start sale transaction 6. The system should be able to end sale transaction 7. The system should be able to Log in and Log out 8. The system should be able to generate reports of sales 3.4.2 NON FUNCTIONAL REQUIREMENTS Non-functional requirements sometimes is preferred than when a functional requirements goes wrong. If these are not met, the system can be slow, late or early. The non-functional requirements of the proposed system are: 1. Efficiency: The system should be efficient in stock update, sales inventory, time management and proper register of items pictorially, the processor consumption is below 5% and memory usage which is less than 10mb. Usability: The system should be flexible for both administrator and sales representative. since it is web based ,it takes inventory records of sales of product(stock in-stock out), It accept barcode of product, capacity to register staffs(sale representatives) by the administrator. The customer will be able to see a large-monitor display of the POS. Therefore; Text should be easily visible from 1 meter.
Avoid colors associated with common forms of color blindness. Speed, ease, and error-free processing are paramount in sales processing, as the buyer wishes to leave quickly, or they perceive the purchasing experience (and seller) as less positive.

The cashier is often looking at the customer or items, not the computer display. Therefore, signals and warnings should be conveyed with sound rather than only via graphics.

2. Reliability: The system should process request without error. It interfaces to various service applications, such as a third-party tax calculator and inventory control. These systems must be relatively fault-tolerant; that is, even if remote services are temporarily unavailable (such as the inventory system), they must still be capable of capturing sales and handling at least cash payments so that the business is not crippled.

3. Maintainability: The system should be flexible in operation, easy to manipulate and open to update. Since it is a capable to work online and on offline mode, its open to improvement and maintenance with the use of online tools, or improved version of software used. Portability: The system must be very portable. The Point-of-Sale terminal is a computerized system used to record sales and handle payments; it is typically used in a retail store. It includes hardware components such as a computer and bar code scanner, and software to run the system. A POS system increasingly must support multiple and varied client-side terminals and interfaces. These include a thin-client Web browser terminal, a regular personal computer with something like a Java Swing graphical user interface, touch screen input, wireless PDAs, and so forth.

3.4.3 USERS OF THE SYSTEM The specified users of the system can be further divided into: 1. Primary actor/ player Cashier at POS (profile 1) Supervisor, inspector (profile 2) Customer at POS (indirectly through cashier)

2. Administrator POS application administrator (profile 3)

IT administrator (profile 4) which Manages all applications in the supermarket Security manager (profile 5) Responsible for security issues DB administrator (profile 6) which manages DBMSs on which applications are based

3. Buyer (CEO and/or CTO of supermarket)

3.5

SYSTEM DESIGN

Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements. Systems design could be seen as the application of systems theory to product development. There is some overlap with the disciplines of systems analysis, systems architecture and systems engineering This section which explain the software design of the project, we will talk about the programming language use, data requirements, features of the language, flowchart and system architecture.

3.5.1 USE CASES A case diagram at its simplest is a representation of a user's interaction with the system and depicting the specifications of a case. A use case diagram can portray the different types of users of a system and the various ways that they interact with the system. This type of diagram is typically used in conjunction with the textual case and will often be accompanied by other types of diagrams as well.

An example of UML use case diagram for Point of Sale (POS) Terminal or Checkout. A retail POS system typically includes a computer, monitor, keyboard, barcode scanners, weight scale, receipt printer, credit card processing system, etc. and POS terminal software. Checkout use case involves Customer, Clerk and Credit Payment

Service actors and includes scanning items, calculating total and taxes, payment use cases.

Top level UML use cases for Point of Sales Terminal (POS). Note: Checkout use case requires Customer actor, hence the 1 multiplicity of Customer. Clerk can only participate in a single Checkout use case. Credit Payment Service can participate with many Checkout use cases at the same time. Checkout use case may not need Credit Payment Service (for example, if payment is in cash), thus the 0..1 multiplicity. Checkout use case is an example of a large and complex use case split into several use cases each describing some logical unit of behavior. Note, that including use case becomes incomplete by itself and requires the included use cases to be complete. Checkout use case includes Scan Item, Calculate Total and Tax, and Payment use cases. Payment use case is represented using generalization relationship. It means that only one specific type of payment is accepted - either by cash, or by credit, debit, or with check. An alternative to such representation could be to use include relationship so that not just single but several forms of payment could be accepted from the same client during checkout.

Use case: Actors: Type:

Buy Item Customer (initiator), Cashier Primary

Description: The Customer arrives at the checkout with items to purchase. The Cashier records the purchase items and collects a payment. On completion the Customer leaves with the items

Use case: Actors: Type:

Login Cashier/Administrator (initiator) Primary

Description: The Cashier/Administrator logs into the system to perform any transaction and he is required to input a username and a password on the logon screen, if this is correct, he gains access into the software.

Use case: Actors: Type:

Generate reports Administrator (initiator) Primary

Description: The Administrator logs into the system and thus gains accesss to the reports module due to his user type. From this module, there are checkbox and textbox for him to specify the conditions to generate specific reports like total sales for the day, week, month or even the year

Use case: Actors:

Logout Cashier/Administrator (initiator)

Type:

Primary

Description: The Cashier/Administrator logs out of the system at the end of the transaction using a simple log out link at the top left of the software.

Fig: A summary of the possible use case scenarios in the system.

3.5.2 CLASS DIAGRAMS

Figure: Class Diagram

3.5.3 DATABASE DESIGN

The new system will store information with easy, allow easy retrieval of existing sales transactions, inventory of items in store, generate reports and can print information from any date and year as hard copy (i.e. on a paper).

This phase of the design illustrates the database used to store all data accepted and processed from the entry of the user.

3.5.4.1 TABLES AND THEIR STRUCTURES Customers Table

Fields Name Id Name Tel Address Gender Status City Country Data Type Int (5) Varchar(20) Varchar(12) varchar(50) Bit Bit varchar(20) varchar(30) Null No No No No Yes No Yes Yes Key Primary key Description Unique identifier of every customer Store name of a customer Store contact phone of Customer Store address of Customer Store gender of Customer Store status of Customer Store City of Customer Store Country of Customer

Users Table
Fields Name Data Type U_ID UserName PassWord Name Phone Email Address LastLogin U_Status varchar(5) varchar(30) Null Key No No Description

Primary key Store Id of User Store username of User Store password of User Store Name of User Store contact phone of User Store contact Email of User Store address of User Store the last time when User login to system Store status of User, Default 1

Varchar(16) No Varchar(50) No varchar(12) No

Varchar(30) No varchar(50) DateTime Int No No No

Product Table
Fields Name Data Type I_ID I_Name I_Unit I_Price I_Quantity I_Status varchar(5) varchar(25) Null Key No No Description

Primary key Store Id of Item Store name of Items Store measure of Item Store price of Item Store quantity of Item in stock Store status

Varchar(15) No Float Int Int No No No

3.5.4.2 ENTITY RELATIONS DIAGRAM

Product description Product Id

Price product name

Product

product category

name

date Quantity product id

Authorize staff

Order id

Has
Quantity Stock Id Product Id

ORDER
Authorize

Stock
Delivery

make
Contains

Customer
Product id date Invoice Id Pay

date

INVOICE
UNIT PRICE Product id Invoice Id Quantity

Date

3.5.4.3 LOGICAL DATABASE MODEL Order Table

Fields Name Data Type ORDER_ID ID I_ID I_Unit I_Price I_Quantity I_name varchar(5) Int INT (5) Null Key No No No Description

Primary key Store Id of ORDER Foreign key Foreign key Store ID of Customer Store product id of Items Store measure of Item Store price of Item Store quantity of Item in stock Store name of product

Varchar(15) No Float Int No No

Varchar(10) No

3.5

ARCHITECTURAL DESIGN

This specifies the structure of the whole computerized point of sale system integrating all modules to better understand its functionality. Since the application will have Model-ViewContoller (MVC) architecture, it will have three-tier architecture.

Fig 3.6: System Architecture Client sends the request operations such as adding, deleting, and updating via Internet to Business Logic Server. Server to receive and process those requests and then sent via Internet to Database Server. Database Server receives service requests and manipulates the database and return relevant results for Business Logic Server. Business Logic Server receives the result from Database Server and return to the Client.

The model here is any of the logic or the database or any of the data itself. The view is simply how you lay the data out, how it is displayed. If you want a subset of some data, for example, my opinion is that is a responsibility of the model. The model knows how to make a subset. The controller in this web app is a bit more complicated, because it has two parts. The first part is the web server (such as a servlet container) that maps incoming HTTP URL requests to a particular handler for that request. The second part is those handlers themselves, which are in fact often called "controllers." So the C in a web app MVC includes both the web server "overlord" that routes requests to handlers and the logic of those handlers themselves, which pull the data from the database and push it into the template. This controller also receives HTTP POST requests and processes these, sometimes updating the database.

3.6

OUTPUT DESIGN

The output specification can will be viewed from the receipt issued after sales, which contains the following.

Fields Product Quantity Total Receipt Num

Description Name of the products Quantity of each product bought Total amount Receipt ticket issued to customer

Data type varchar(5) Int Float Int

Table 3.3: Output File Design

The software can also generate reports and this can be viewed in the following format

Fields Product Quantity Total Date Customer

Description Name of the products Quantity of each product bought Total amount Dates of sales of products Name of customer item was sold to

Data type varchar(5) Int Float Datetime Char (20)

3.4.4 HARDWARE REQUIREMENTS The minimum hardware requirement for the system should be: i. ii. iii. iv. v. vi. vii. viii. ix. x. An Intel Pentium IV MMX with a minimum speed of 1.6 GHz. Hard Drive with capacity of 80GB Minimum of 512MB of RAM CDROM drive Internet Connection SVGA Monitor and Adapter Standard Keyboard and mouse Scanner UPS (650va) Printer

3.4.5 SOFTWARE REQUIREMENT The following are the minimum software requirement for the system:

i. ii.

Operating System: Microsoft Windows XP with service pack 2 WAMP software