OOAD for Supermarket System

Analysis of the System Requirements for a Business Problem

Introduction and Background Information

Highways supermarket is the second largest shopping mall that is located in the central city of Mumbai, India. In 2015 the customer research revealed that the company was ranked fifth and claimed a customer membership of around 1.2 million. Moreover, the staff of the company amounts to 540 as of December the 1st in 2015.

Since the opening of Highways supermarket, every customer wanted to make the daily operations easier to manage and ensure transparency in their ordering practice. The customers have always waited for a time that will make it possible to place orders online and receive the orders while being at home. However, such opportunities are still unavailable for the customers as the operations at Highways Supermarket are still carried out manually (Ashrafi, & Ashrafi, 2008). The operations that involve order placing, payments for the orders and the tracking of the paid orders are hectic and time-consuming.

In case there is any problem with a customer’s order record, it is a hard task to try to trace that particular record in the orders-registry. Moreover, dealing with the customers’ order problems is inefficient because it entails erasing mistakes with an error corrector or a rubber eraser. In addition, the probability of clerical errors is high as the process of allocating, tracking, updating and deleting records are performed by the staff.

Problem Statement

The current system of managing customers’ orders, scheduling the deliveries, and assigning tasks associated with deliveries to the staff is ineffective and inefficient. Currently, the process involves recording the data in huge files posing huge risks associated with clerical errors (Ashrafi, & Ashrafi, 2008). Moreover, the organization of the managing process is organized in a way that makes it hard to follow and track an order of the customer hence resulting in delays in delivery. Such a fact translates into inconveniences on the customer’s side.

Limitations of the Manual System:

· Processing Speed is quite slow since it depends on manual processing.

· There is no efficient method used for searching and retrieving a particular record of a particular customer.

· Storage of bulky files is a problem.

· Maintenance and updating of data are difficult.

· Order placement is hectic since a customer must come to the premise to place an order.

· Follow all the delivery recording in files is a tedious exercise.

Proposed Solution

In regard to the problem, the proposed mobile app and the web-based system will ensure that the customer can place an order for existing products from any location. The customers are able to place an order by using their cell phones. Moreover, the customers can pay for the ordered item through a mobile payment application. Once the orders are placed, the staff can review them and plan the delivery dates (Ashrafi, & Ashrafi, 2008). What is important, such a strategy provides clients with feedback indicating when to expect the products to be delivered. So, the system will reduce the time needed for order placements and delivery. Moreover, such a system will facilitate the work of the supermarket staff.

Project Justification

The operations of the Supermarket or the Hypermarket such as management of stock, orders, and deliveries of the customers, involve time-consuming tasks, which represent an important part of the management. Under manual management, such tasks as staffing, logistics, finances, and other functions are ineffective and time-consuming. Such operations as order placement, product entries, staff registration, delivery tracking, and the general order reports also involve a lot of time and staff (Ashrafi, & Ashrafi, 2008).

The proposed web-based system and the customer mobile application facilitate the work of the administrator. Moreover, the proposed strategies ensure that the staff of the Hypermarket work more effectively and all the tasks can be done efficiently. The system facilitates the work of the staff by moving the time-consuming operations online. Thus, the proposed strategies would improve the following operations: customer registration, staff registration, order placement, product entries, delivery planning and the generation of reports from time to time. Moreover, the system can help the staff and the Supermarket in general to gain information about the general product preferences of various customers that may improve the decision-making process (Ashrafi, & Ashrafi, 2008).

Scope

The proposed system will include the following vital processes: customer registration, staff registration, product entries, login, order placements, delivery planning, order reports, delivery reports, and consumer reports generation.

Project Objectives

The project has the following objectives:

a. Investigate the current system to identify the needs of the supermarket.

b. Automate the customer module.

c. Automate the staff registration module.

d. Automate the order placement module.

e. Automate the delivery planning and tracking module.

System Objectives

a. Register staff information.

b. Entries of new products/stocks.

c. Ordering of products by customers.

d. Tracking deliveries and planning.

e. Register a new customer.

Benefits of the Proposed System

How the proposed system is better than the existing manual system:

· User-Friendly System: a user can register through the mobile application or through the web-based system. The customer can log in in order to place an order. The system has a simple graphical interface to allow both the novice and the experienced users to use the system comfortably. The system allows for easy and less time-consuming modifications of the data filled by a user (Ashrafi, & Ashrafi, 2008).

Moreover, administrative work is facilitated. The storage, retrieval, and maintenance of the data in the database are much easier. Moreover, the automated system facilitates the search for any kind of information by the administrative user as various reports can be generated.

· Faster response: Filling the information form about states online takes much less time than filling it manually. In addition, the data maintenance can be performed through the click on a few buttons rather than through analyzing a huge number of files.

System Development Life Cycle

Introduction to SDLC

The traditional development methodology called Systems Development Lifecycle (SDLC) consists of a set of development activities that have a prescribed order (Ashrafi, & Ashrafi, 2008). Once the problem of the existing management process (for example, the order placement, customer registration, and delivery tracking) is recognized, the request for developing a new system is forwarded to get the approval. The recycling of the development activities may occur after the evaluation by the System if the System still requires modification or redevelopment. The term Development Cycle is used to acknowledge the importance of recycling in meeting information needs.

Figure 1 shows the SDLC phases:

Figure 1. Software Development Life Cycle Models.

The following 4 Software Development Life Cycle (SDLC) is used (Ashrafi, & Ashrafi, 2008):

· Prototyping Model

· Waterfall Model

· Incremental Model

· Evolutionary Model

According to the project requirements, the Waterfall Model will be used to develop the software.

The following model is used because it reinforces the notion of “Define before Design” and “Design before Code” proving the systematic approach.

Waterfall Model

The Waterfall Model is the most familiar model and consists of five phases represented below –

· Requirement Analysis and Specification

· Design

· Implementation and Unit Testing

· Operation and Maintenance

The phases always occur in the following order and sequence.

 

Figure 2. Waterfall Model.

A brief description of the various phases is the following:

1. Requirements analysis: The process of studying and analyzing the customer and user needs to derive the definition of the system requirements (Ashrafi, & Ashrafi, 2008).

2. Design: the process of developing a blue-print of a to-be system from the collected requirements.

3. Implementation: the process that entails the coding process of the system using a programming language.

4. Testing: the process that involves testing the system to ensure the successful performance of the tasks in the business environment.

5. Maintenance: a continuous phase that involves rectifying faults in the working system and implementing changes required in the working system (Ashrafi, & Ashrafi, 2008).

Requirements Elicitation Techniques

Interviews

Interviews involved visiting the Supermarket premises and talking to the management and staff about the operations of the firm and the types of tasks performed on a daily basis. The interview questions were prepared prior to the visit and were relevant to the operations of a supermarket environment. Customers were also interviewed with the purpose to collect requirements for the ordering procedure (Ashrafi, & Ashrafi, 2008).

Observation

Observation involved personally visiting the premise and watching the staff, management, and customers performing the daily tasks. In fact, the observation process helped to see how the customers cope with the product ordering activities.

Documentation Review

Documentation review involved acquiring written documents such as the ordering placement files, report books, staff registration records, delivery tracking, and processing documents, and reading them to obtain the functional requirements of the proposed system. Documentation review is needed to get data for the system and to understand the calculations involved.

Literature Review

Literature review involved reading a lot of literature about the development of similar systems and their operations. Moreover, it involved conducting research on the internet and visiting the library to gather information about similar systems in order to be able to understand their working system. The literature review provided insights into the various components of the system and the development process that facilitated the development process (Ashrafi, & Ashrafi, 2008).

User Requirements

Functional Requirements

The following are the requirements that capture the intended behavior or functionalities expected from the system. Such behavior is defined as the tasks, functions, services that the system is expected to deliver. The main functional requirements that will be expected from the system are presented below.

Outputs:

· List of all the orders placed by users.

· List of all the deliveries that are scheduled and staff handling.

· List of all the customers currently registered.

· List of all the staff members in the supermarket.

· Generation of the order and delivery reports.

· Generation of staff reports.

Inputs.

The system should:

a. Enable users to log in.

b. Offer order application and processing.

c. Allow registration of new staff.

d. Be able to facilitate the registration of new customers/clients.

e. Allow entries of new stock into the system.

Processing:

· Adding new user

· Adding new staff

· Adding new customers

· Order placement

· Order processing

· Delivery scheduling/planning

· Generation of reports.

Non-Functional Requirements

Security

a. Any user, who uses the system, should have a user name and password with some privileges.

b. Administrators should be able to view and modify all the information in the system.

Performance Requirements

a. The user-interface screen should respond within 7 seconds.

b. The systems must conform to the Microsoft Accessibility guidelines.

c. The system should be available all the time.

d. The system should be reliable all the time.

Usability Requirements

The usability requirements include the following;

· Reduced-order placement life cycle times: the time that it takes for the order of a given product to be placed and the delivery of the product to be scheduled. Since the process is automated now, the time that it takes for the order to be processed will decrease greatly.

· Efficiency and centralization: the system provides user-friendly and interactive interfaces any user can effectively use. Each customer should be able to check various products and their availability at any time through the use of cell phones. The customers can also place orders for preferred products through the use of the mobile web-based application (Ashrafi, & Ashrafi, 2008).

Functional and Behavioral Model of the Business System

Figure 3. User graphical interface storyboard.

Figure 4. Use case diagram.

Use Cases and Use Case Descriptions

Actors. The main actors in the use case are the following:

1. Customer

2. Supermarket staff

3. Administrator

Use the case description. Scenario 1: The customer wishes to make an order.

Preconditions:

· The Supermarket is operating by offering products to be sold out

· The customer is registered and ready to place an order for available products

The basic flow of events. The general flow of events is the following:

1. The customer registers personal details and then log into the system

2. Customer places order for existing products

3. Customer pays for the product through the valid application

4. Supermarket staff checks the placed order

5. Staff plans the delivery and assigns a staff member to deliver different orders

6. The client receives the ordered product

The alternative flow of events. If in step 3 the customer fails to pay for the placed order within the specified time, then

Scenario 2. Staff scheduling deliveries.

Precondition. Orders have already been assigned to the staff.

The basic flow of events.

1. Staff checks the deliveries assigned

2. Staff plans the delivery considering distance and urgency

3. Staff executes the plan

Scenario 3. The staff checks the orders.

Preconditions:

1. The customer has already placed an order for an item

2. Item is in stock

The basic flow of events:

1. Staff checks the existing orders

2. Staff assigns the orders to be delivered to the junior staff

3. Staff generates the delivery reports and sends to the other staff

The alternative flow of events. If the user fails to pay for the ordered item on time, the user case ends with the staff canceling the placed order

Figure 5. Communication diagram or sequence diagram.

Figure 6. Activity diagram of the system.

Design of the Business System/System Interfaces

Design User Interface Screens for all System Components

All the users must log in before exploiting the system. Different users have different access rights and privileges; they will be directed to different pages according to their access rights.

1. Login page screenshot

The login page is the first page that appears when the system is launched. The first page requires the user to provide the username and the password. Later, the system will check the validity of the provided credentials as well as the privileges of the concerned user. After the successful login, the user (in this case the supermarket staff) is directed to the main page.

Figure 7. Login page screenshot.

2. Main page screenshot

The main page is the main page that follows a successful login. The staff member can maneuver to other pages of the system easily from the main page. The main page contains all the links to crucial pages of the system such as the staff registration module, product entries section, planning of deliveries section, the information about placed orders, and the generated reports.

Figure 8. Main page screenshot.

3. Customer page screenshot

The customer page is the module that is used by the customer to register in order to access the system.

Figure 9. Customer’s page screenshot.

4. Staff page screenshot

Staff page is used by the Supermarket administration during the registration of a new staff member.

Figure 10. Staff page screenshot.

5. Products page screenshot

Products page is the module that is utilized either by the staff or by the administrator of the supermarket in order to describe the details about a new product.

Figure 11. Product page screenshot.

6. Orders page screenshot

Orders page is the module that is used by the customer to place an order for a given product. Once the user provided all the details, registration of the order will submit all the data about the placed order to the database of the system.

Figure 12. Orders page screenshot.

7. Deliveries page screenshot

Deliveries page is the module that is used by the staff or administrator of the supermarket to plan the deliveries of the placed orders.

Figure 13. Deliveries page screenshot.

8. Reports page screenshot

Reports page is the module that is used for the generation of all the reports that are necessary.

Figure 14. Reports page screenshot.

Relational Database

The database used to develop the proposed system will be deployed in a mysql environment. Mysql is a relational database that can run on different platforms. In fact, mysql is secure since the person is required to execute all the commands in a command-line environment (Ashrafi, & Ashrafi, 2008). The screenshot of the database, the related tables that will constitute the system and constraints are presented below. The structure of the table will be designed as shown below:

The breakdown of the tables is provided below:

B) Orders_table: the table that is used in capturing and storing all the information about the orders placed by the customers. Order ID is the PRIMARY KEY for the table.

C) Customers_table: the table that contains all the information about the registered customers. Customer ID acts as the PRIMARY KEY for the table.

D) Products_table: contains all the information about the products the supermarket has in stock. Productid, in this case, is the PRIMARY KEY for the table.

E) Deliveries_table: the table that contains all the scheduled deliveries of the orders. The delivery ID is the PRIMARY KEY, while staff ID and order ID are the FOREIGN KEYS from both staff_table and orders_table respectively.

F) Staff_table: contains information about the staff that is a part of the highway supermarket team. Staff ID is the PRIMARY KEY of the table.

G) Login_table: contains the login credentials for both the customers and the staff. The difference between the two classes of users is access privileges. The table is used in order to direct both the customers and the staff members to different pages.

Structural Model of the Business

Figure 15. Class diagram.

Figure 15. Object diagram.