A

Project Report
On

Online Shopping System

by
Rajesh Pansare
Yogita Patil
Jyotsna Rane
(ME Sem I)

1
 Content

Sr. No. Title Page No.

Abstract 3
1 Introduction

2 Project Background 4
3 System Analysis 5
3.1 Requirement Specification
3.2 Software and Hardware Requirements
3.3 Process Model
3.4 Data Model
4 System implementation 12
5 Critical evaluation 16
6 Conclusion 18
7 References 19

2
Online Shopping System
ABSTRACT
Our project is to develop an on-line shopping system for Metro Credit Union
(MCU). MCU provides many services and benefits to its members. Currently,
during the sales promotion to MCU members, MCU staffs manually handle the
purchasing information with the use of basic office software, such as Microsoft
Office Word and Excel. It may results in having mistakes easily and the process is
very inconvenient. As a result, MCU needs an online shopping system at their
MCU Intranet.

We develop an online shopping system based on the requirements of users. The

MCU Online Shopping System should have following key features:
(1) To provide the user friendly online shopping cart function to members, to
replace hardcopy ordering form;
(2) To store inventory & sales information in database to reduce the human
mistakes, increase accuracy and enhance the flexibility of information processing;
(3) To provide an efficient inventory system, this can help the MCU staffs to
gain enough information to update the inventory.
(4) To be able to print invoices to members and print a set of summary
reports for MCU’s internal usage.
(5) To design the system that is easy to maintain and upgrade.

3
 1. INTRODUCTION

Online shopping becomes increasing popular nowadays. It brings many advantages

to both the sellers and the buyers. In our project, we developed an online shopping
system. In this system, we introduce our stakeholder and describe the existing
problem, the user requirements, the project scope and the project schedule. Next,
we present our solution including the system analysis, the deviation between the
final and initial design, the functions of our online shopping system and the testing
plan. Finally, we evaluate our work in different aspects, present the area for further
improvement and conclude our work.

2. PROJECT BACKGROUND

In this section, we briefly introduce our stakeholder and describe the existing
problem, the project scope and the system specification.

2.1 Our Stakeholder

Metro Credit Union (MCU) is a co-operative, nonprofit association for the purpose
of creating a source of credit available to its members who are the employees of
MTR Corporation. MCU always strive continuously to look for improvement in all
related business, so that its members can benefit from its services and obtain the
best value for money.

2.2 Existing Problem

MCU always organizes sales exhibition at discounted price to members. Due to

the insufficient venue and lack of manpower to manipulate the sales exhibition,
MCU would like to develop an on-line shopping platform, so that members
could enjoy the service via MTR intranet web server instead of on-site. In
addition, MCU can easily estimate the sales volume and be able to negotiate a
better discount from vendor. This is a saving time and saving money
unprecedented service to its members.

4
2.3 Scope of Project

MCU requires an online shopping system with a database keeping the inventory
and the invoicing information, and the system has to be migrated to the MTR
Intranet web server. The online shopping system needs to have three key features:
(1) Only accessible by MCU members;
(2) User friendly for computer illegitimate; and
(3)Easy to maintain by system administrators.

2.4 Potential Users of Our System

There are two groups of users in our system; they are MCU members and system
administrators. They have different authorities in our system which is shown as
follows:
• Members – They are MCU members. They can view the detailed product
information & their shopping history. Besides, they are able to create, view,
modify & cancel their shopping orders.
• Administrators – They are authorized MCU staffs to control the system.
They are assigned with different level of authority to maintain the information of
inventory, invoicing, members & administrators. Besides, they can make
conditional refunds and print out transaction invoices. In addition, administrators
can execute summary reports and be responsible to maintain database.

3. SYSTEM ANALYSIS

In this section, we present the requirement specification, software and hardware

requirements for both system developers and system users, process model and data
model.

3.1 Requirement Specification

In the following, we describe the functional requirements and non-functional
requirements of our system.

3.1.1 Functional Requirements

Functional requirements define the functions that are requested by our stakeholder.
Different functions are needed by different system users. There are three types of
MCU members: Ordinary, Associate and Suspended. An ordinary member is a
general member. An associate member is a VIP member. A suspended member is a

5
member having limited rights to be served by MCU. Once a member login the
system, it can identify the type of the member. Besides, different administrators
have different levels of authority to maintain the system information. The system
can identify the authority of an administrator after he login.
• Functional Requirements for Members
 Login
 Shopping cart
 Receive invoice
 View shopping history
 Search information of product
 Change of password

• Functional Requirements for Administrators

 Login
 Update information of product
 Update information of member
 Update information of administrator
 Update invoice and transaction
 Print Invoice
 Print Report
 Change of password

3.1.2 Non-functional Requirements

Non-functional requirements define the operational requirements and project
schedule that are requested by our stakeholder.

 Operational Requirements
 The system can be viewed by Microsoft Internet Explorer.
 The system can be executed on the MTR’s Intranet. The MTR Intranet web
server runs on the Windows server platform which supports Internet
Information Server (IIS).
 We can only use Microsoft Access to develop the database.

 Project Schedule
 The development of system is completed by the end of June 2011.
 The mitigation testing and final user acceptance testing is scheduled at the
end of July 2011.
 The system can be launched at the end of August 2011.6

6
3.2 Software and Hardware Requirements
In the following, we describe the software and hardware requirements for
system developers and system users.

3.2.1 Software and Hardware Requirements for Developers

During our system development, we have to design both static and dynamic
website interfaces, create website functions and a database system, edit photos and
pictures, and print out reports, so its has a set of software and hardware
requirements.

• Software Requirements
 Operating System – Windows XP with Service Pack 3 (CHT)
 Microsoft Visual Studio 2005
 Adobe® Creative Suite® 3 Design Premium (Photoshop CS3 , Flash CS3,
Illustrator CS3, Acrobat)
 Microsoft Office Access 2003
• Hardware Requirements
 CPU – Intel Core 2 Duo E7300
 RAM – 2 GB
 Hard disk – 120 GB

3.2.2 Software and Hardware Requirements for Web Server

in Production
The following is the requirements for web server which is compatible with
the current MTR Intranet web server.

• Software Requirements
 Microsoft Visual Studio 2005
 Adobe Acrobat
 Microsoft Office Access 2003

• Hardware Requirements
 CPU – Opteron / Xeon Server CPU(Opteron 2356/Xeon5300)
 RAM – 4 GB
 Hard disk – 30GB(for RAID 5)
 Operating System – Windows Server 2003 Standard
 LAN – at least 100Mbps

7
3.2.3 Software and Hardware Requirements for System
Users in Production
The following is the requirements for the system users including members and
administrators.

• Software Requirements
 Web browser - Microsoft Internet Explorer 6 or above.

• Hardware Requirements
 CPU – Intel Pentium 4
 RAM – 1.5 GB
 Hard disk – 30GB
 Operating System – Windows XP with Service Pack 3.

3.3 Process Model

In this section, we briefly describe the two Data Flow Diagrams (DFD) of our
system, and they are Data Flow Diagram (Context Level) and Data Flow Diagram
(Level 0)

3.3.1 Data Flow Diagram (Context Level)

In the Data Flow Diagram (Context Level) shown in Fig. 1, it has two
external users and one process. The two external users are Member (MCU
member) and Staff (Administrator) and the process is the online shopping system.
We combine some data flows together grouped by similar characteristic function in
the context level.

8
3.3.2 Data Flow Diagram (Level 0)
In the Data Flow Diagram (Level 0) shown in Fig. 2, it shows our system
has five major functions, four data storages and a number of data flows. It includes
all the functions for MCU members and administrators. The five major functions
are described briefly as follows:
• Process 1: Login the System – Both members and administrators have to use their
user IDs and passwords to login the system. Once they enter their IDs and
passwords, the system will verify the correctness of data by searching the relevant
data source for comparison.

• Process 2: Complete the Transaction Record – When a member wants to

purchase a product in the online shopping system, the system provides some
product information such as the quantity of each product, the payment methods and

9
the pickup locations. When the member selects the products he wants to purchase,
the system displays the transaction information and asks the member for
confirmation. Finally, the confirmed transaction information is stored into the
invoice data source.

• Process 3: Browse the System Information – Both members and administrators

can browse the system information. Besides, the system provides the searching
function by using keywords to increase the efficiency. Depending on their assigned
authorities, they can browse the information of products, invoice records, members
and administrators.

10
• Process 4: Maintain the System Information – Depending on their assigned
authorities, members and administrators can update the system information, such
as the information of product, invoice, members, administrators and their
passwords. Once an update occurs, the relevant data source will be updated.

• Process 5: Print the Documents – An administrator with the authority right can
print out some reports for internal usage, such as the inventory report.

3.4 Data Model

There are thirteen entities in our final Entity Relationship Diagram (ERD) as
shown in Fig. 3. The brief descriptions of all the entities are shown as follows:
• Member – Member
• Admin – Administrator
• Cart – Shopping cart of a member
• Cart Item – An item in the shopping cart of a member
• ProType_Pay – Product type and payment method of a product
• Pro_Loc – Pickup location of a product

11
• Invoice – An invoice which a member may have more than one invoices after he
checks out his shopping cart, e.g, he chooses different pickup locations for
different products in one shopping cart.
• Location – Detailed information of a pickup location
• Payment – Detailed information of a payment method
• Product – Detailed information of a product
• ProType – Detailed information of a product type
• ProType_Loc – Product type and pickup location of a product
• Pro_Hist – History of the inventory record of a product

3.5 Deviation between Final Design and Initial Design

There are a number of differences between the final design and initial design
of our system, and we describe them in this section.
Firstly, we deleted two functions:
(1) member registration;
(2) messaging function.

Since the MCU member registration process is already done in an existing

system in MTR’s Intranet, it is not necessary for us to provide this function in our
system. Besides, a system administrator does not log into our system all the time,
members sending messages to administrators through the messaging function in
our system cannot receive the instant reply from administrators. As a result, it is
better to display the contact information of MCU administrative staffs in our
system, and asks members to contact the staffs directly. Therefore, the
corresponding data flows in DFD and related entities in ERD are deleted.
Secondly, we designed a few reports to meet the needs of our stakeholder as
follows.
• Inventory report for all locations
• Inventory report for selected location(s)
• Outstanding order list report for all locations
• Outstanding order list report for selected location(s)
• Outstanding invoice report for all invoice statuses
• Outstanding invoice report for selected invoice status (es), such as ordered,
waiting for pickup
Thirdly, after understanding the sales operations of MCU, we modify our
ERD diagrams to suit their needs. For example, it allows members to buy a few
quantity of the same product in one shopping cart, but they can pick up the
products at different locations. As a result, it is possible that more than one
invoices printing out for one shopping cart.

12
 Fourthly, after several demonstration sessions, we revised the interfaces of
both members and administrators based on the comments from our stakeholder.

4. SYSTEM IMPLMENTATON
In this section, we present our online shopping system in terms of the
functions for members, the functions for administrators and the system printouts.
Besides, user guides for members and administrators are also prepared for our
stakeholder, but we do not present them in this paper because of limited space.

4.1 Functions for Members

Members use their member IDs and passwords to login our system. Once a
member logs into the system, it identifies the type of the member, which is
Ordinary, Associate or Suspended. The authorities are granted to the member
based on the type of the member. After that, a main menu displays all the functions
for members in our system as shown in Fig. 4.

We briefly describe the five main functions provided to members as

follows:
1. Going shopping – The system provides a searching function on goods based on
the product types and brand names, and shows the inventory state to members.
Members can make purchase orders on different products using the online
shopping cart.

2. Shopping history – Members can check their shopping history, ordering history
and existing invoices, and cancel their orders any time.

3. Change password – It allows the members to change their passwords by

themselves.

13
4. Contact us –
Member can get the contact information of the system administrators.

Product Code:9823
Brand:Nokia
Model:XU-3256
Facilities:3.2 Mpix Camera,FM.,
4 GB Memory.
Price:Rs 10500/-

5. Logout
To purchase products in our online shopping system, a member can select
the Going shopping function in the main menu.
When the member double-click the name of a product type, all the products
of the type are displayed, for example, all the products of mobile phone type are
Displayed. When the member selects one product, he can view the detailed
description of the product. At this page, he can input the purchase quantity and
select the pickup location and time, then press the “Add to Cart” button. After that,
the member can view his selected items in his shopping cart. Once the member
decides to order the selected items, he checks out, views the information of the
invoice and selects the payment method. Besides, the member can cancel his order
at his view order page.

4.2 Functions for Administrators

Administrators use their administrator IDs and passwords to login our
system. Once an administrator logs into the system, it identifies the authorities for
the administrator to maintain the information of products, invoices, members and
administrative staffs, and to print vary types of reports. After an administrator logs

14
into our online shopping system, a main menu displays all the functions for
administrators in our system.
We briefly describe the seven main functions provided to administrators as
follows:
• Member setting – Administrators can view, modify and delete the personal
information and passwords of members if necessary. Administrators can search the
information of members by using member ID or member type.

• Staff setting – Administrators can view, modify and delete the personal
information and passwords of administrators if necessary.

• Product setting – Administrators can view, modify and delete the information of
products, such as the prices, pickup locations of products, inventory and ordered
quantities.

• Invoice setting – Administrators can choose to view the invoice list of ordered
but not paid, paid orders, finished pickup orders or disqualified orders. Besides,
at the interface showing the details of an invoice. Administrators can modify the
invoice, such as completing a transaction and disqualifying a transaction. They can
print out the invoice if necessary.

• Print report – Administrators can print out reports for internal usages, such as
inventory report.

• Change password – It allows the administrators to change their passwords by

themselves.

• Logout

4.3 Printouts
In this section, we describe the printouts of our online shopping system, they
are invoices and summary reports.
4.3.1 Invoices
In our online shopping system, the administrator can print out a selected
invoice. Before printing, the print preview of the invoice. The administrator can
enter some remarks for internal reference.

4.3.2 Reports
For internal usage, the administrator can print out some reports, such as
outstanding inventory report, outstanding invoice report and inventory report.
15
After clicking “Report Preview” button, the print preview of the report is
displayed.

4.4 Testing Plan

We executed a series of tests to ensure the correctness of our system. In, it
describes different types of testing during system development, they are unit
testing, integration testing, system testing, user acceptance testing. For our system,
we also have migration testing. In the following, we briefly describe all the testing
in our system.

4.4.1 Unit Testing

Unit Testing focuses on one unit – a program or a module that performs a
specific function that can be tested.The purpose of a unit test is to ensure that the
module or program performs its function as defined in the program specification.
For example, we tested the login function for the unit test, so we entered the user
ID and password to test until the program not displaying any error message.
4.4.2 Integration Testing
Integration Testing assesses whether a set of modules or programs that must
work together do so without error. They ensure that the interfaces and linkages
between different parts of the system work properly. For example, after we tested
the login function and the shopping function separately without error, we tested
these two functions together until we completed the transaction without error.

4.4.3 System Testing

System Testing is to ensure that all modules and program work together
without error. System testing is similar to integration testing but is much broader
on scope. For example, we tested all functions together in our system until the
process was completed without error.

4.4.4 User Acceptance Testing

User Acceptance testing is done primarily by the user with support from the
project team. The goal is to confirm that the system meets the business needs that
prompted the system to be developed, and is acceptable to the users.
For example, we had 4 demonstrations to our stakeholder, which are held at
26th February, 16th April, 5th May and 14th May 2009. In the demonstrations, our
stakeholder revised the user requirements and our system functions. After that, we
deleted some useless functions such as member registration function and
messaging function, and we also defined which reports are needed by our
stakeholder.

16
4.4.5 Migration Testing
The system is expected to be migrated into MTR’s Intranet by the end of
July 2009. Before the migration testing, we checked out the system environment of
the MTR’s Intranet and the MTR web server (Windows 2003 Server supports
Internet Information Services, IIS function). We confirmed with our stakeholder
that a set of current members’ data in Microsoft Excel format will be transferred to
our database. For example, in the migration testing, we test the performance of our
system, check the compatibility of our system with the MTR’s Intranet and debug
the system if necessary. MCU’s staffs can do the final user acceptance testing and
check out whether the system performance matches their expectations.

5. CRITICAL EVALUATION
In this section, we evaluate our performance in this project in different
aspects, and summarize what we have learnt in this project.

5.1 Problems Faced in our Team

At the early stage of this project, some members were quite passive in team
work, so the completions of tasks were delayed. We solved this problem by
increasing the frequency of project meetings and redistributing the tasks and work
load from time to time if necessary. The next problem is only one member in our
team had experience in VB.NET programming. It results in the time for system
development greatly increased comparing with our initial project schedule plan.
After a series of demonstrations to our stakeholder, we got our stakeholder’s
agreement to delay the project schedule.

5.2 Gain of our Team

Through the discussions of project, we gain more experience in
communication skills in a team and help us to communicate with other people
more efficiently in other projects in the future. We also learn how to endure
other member’s weaknesses and train our patience. Besides, we understand that the
skilled members shoulder other member’s responsibilities in a group project.
Moreover, we learn how to distribute work among members through proper
communication.
In this project, we demonstrated and presented our system to our supervisor
and stakeholder for several times, it enhances our presentation skills. It increases
our courage during presentation and enhances our answering skills to audiences’
questions. Besides, we gain the experience on writing regular and formal reports.

17
6. CONCLUSION
In this project, we developed an online shopping system for our stakeholder,
Metro Credit Union (MCU), and the system is expected to be launched in the near
future. In the system development, we applied the skills that we have learnt in the
past years and gained a lot of experiences. For further improvement of our system,
we suggest to add some animations in our system in order to make our system to
be more attractive. Besides, we can further enhance our system’s functions in order
to match the development of MCU.

18
7. REFERENCES
1. MTR Corporation. http://www.mtr.com.hk/
2. Dennis A., Wixom B. H. and Roth R. M. 2006. Systems Analysis and
Design, Third Edition. ISBN: 978-0-471-72257-1. Wiley.
3. Software Engineering By Pressman.

19