Helps

DEBRETABOR UNIVERSITY
FACULITY OF TECHNOLOGY
DEPARTMENT OF COMPUTER SCIENCE
PROJECT DOCUMENTATION
ON
“Online shopping for Ethiopia Industry Inputs Development Enterprise (EIIDE) in
Debretabor Branch”
A DOCUMENT SUBMITTED TO THE FACULTY OF TECHNOLOGY DEPARTMENT

OF COMPUTER SCIENCE OF DEBRETABOR UNIVERSITY IN PARTIAL
FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF BSC IN
COMPUTER SCIENCE
BY:
1. MELKAMU ABERE 0055/07 All activity (Role)
2. ABEBA ALEMINEH 0195/07 All activity (Role)
3. BIZUAYEHU ANIMUT 2325/06 All activity (Role)
Advisors:
4. Mss. Adina N. (MSC) Main advisor
5. Mr. Gezahegn G. (BSC) Co advisor
January, 2018
ONLINE SHOPPING FOR EIIDE IN DEBRETABOR BRANCH 2018
Declaration
This is to declare the project entitled online shopping for EIIDE in Debretabor branch is an
work done by the project team members in partial fulfilment of the requirement for the
degree bachelor of science at computer science department faculty of technology in
Debretabor university all the analysis, design and system development is accomplished by
the project team (Name and Signature up to the number of the project group members)
……………………………… ………………………
Name signature
……………………………… ………………………
Name signature
……………………………… ………………………
Name signature
This is to certify that I have read this project and that in my opinion it is fully adequate, in
scope and quality, as a thesis for the degree of Bachelor of Science.
………………………………………… ………………….
Name of Main-advisor signature
This is to certify that I have read this project and that in my opinion it is fully adequate, in
scope and quality, as a thesis for the degree of Bachelor of Science.
………………………………………… ………………….
Name of Co-advisor signature
i|Page
Acknowledgement
First thanks to God because nothing could be possible without his free will and the
completion of this project proposal are supported by him. Secondly, our deepest thanks go to
main Advisors Miss. Adina and co- advisor Mr. Gezahegn for guiding and for his advice and
useful suggestion. Next we would like to acknowledge Debretabor University computer
science Department in order to developing this online shopping for EIIDE system in a good
manner. At the last special thanks to the manager of EIIDE in Debretabor branch for his great
respect and giving as all the necessary information about the organization.
ii | P a g e
Abstract
This project concern about online shopping for EIIDE has found one branch in Debretabor
town. Today the overall activities of EIIDE are under taken manually in this branch. There
repetitive and bulky activities while registering users, updating records periodically,
generating reports and difficult to integrate data from different individual records, unable to
interest different user request. Based on the above problem this project is to automate the
existing manual system and producing an automated (online) product distribution and
commercial system. This project works on User registration; It will generate report in easy
way online payment; The administrator updates periodical information; The customer order
Item online; The system allow to the customers, to search Item in a fast mechanism;
Customers should be able to post comments to the system about the items. The Programming
Language, Database and server that we have used a free and open source so we can find and
use them. To develop this web based technology we are using PHP language.
iii | P a g e
Acronyms and Abbreviations

 CD--------------------------------------Compact disk
 MS--------------------------------------Microsoft
 UML------------------------------------Unified Modeling Language
 NOV------------------------------------November
 DTU------------------------------------Debretabor University
 DVD------------------------------------Digital Versatile Disk
 EIIDE-----------------------------------Ethiopian Industrial Inputs Development Enterprise
 HTML----------------------------------Hypertext Mark Up Language
 Admin----------------------------------Administrator
 PHP-------------------------------------Hypertext Preprocessor
 BR--------------------------------------business rule
 WH-------------------------------------Warehouse
 RAM-----------------------------------Random Access Memory
 EDDC----------------------------------Ethiopian Domestic Distribution Corporation
 EWTIE --------------------------------Ethiopian Whole sailor Trade and Import Enterprise
 SWOT---------------------------------Strength, Weakness, Opportunity, Threat
iv | P a g e
Symbols
Generalization
Activation
v|Page
Contents
Declaration.............................................................................................................................................i
Acknowledgement................................................................................................................................ii
Abstract................................................................................................................................................iii
Acronyms and Abbreviations................................................................................................................iv
Symbols.................................................................................................................................................v
List of Table........................................................................................................................................viii
List of Figure.......................................................................................................................................viii
CHAPTER ONE.......................................................................................................................................1
1 INTRODUCTION.............................................................................................................................1
1.1. Background...........................................................................................................................1
1.2. Study of existing system........................................................................................................2
1.3. Statement of the problem.....................................................................................................2
1.4. Objectives of the project.......................................................................................................2
1.4.1. General objective..........................................................................................................2
1.4.2. Specific objectives.........................................................................................................2
1.5. Scope of the project..............................................................................................................3
1.6. Significance of the study.......................................................................................................3
1.7. Feasibility of the project........................................................................................................4
1.7.1. Economic feasibility.......................................................................................................4
1.7.2. Schedule feasibility........................................................................................................5
1.7.3. Technical feasibility.......................................................................................................6
1.7.4. Operational feasibility...................................................................................................6
1.8. Methodology.........................................................................................................................7
1.8.1. Data gathering techniques............................................................................................7
1.8.2. Design Methodology.....................................................................................................8
1.8.3. Implementation Methodology......................................................................................8
1.8.4. Testing Methodology.....................................................................................................9
CHAPTER TWO....................................................................................................................................10
2 REQUIREMENT ANALYSIS DESCRIPTION......................................................................................10
2.1. Overview of existing system.....................................................................................................10
2.1.1. Activities of Existing System..............................................................................................10
2.1.2. Problems of the current system........................................................................................11
2.1.3. SWOT analysis...................................................................................................................12
2.2. Overview of the new system....................................................................................................12
vi | P a g e
2.2.1. Functional Requirements............................................................................................13

2.2.2. Non Functional Requirements.....................................................................................14
2.2.3. System Requirement...................................................................................................15
2.2.4. User requirements.......................................................................................................15
2.2.5. Business rules..............................................................................................................16
CHAPTER THREE..................................................................................................................................17
3 SYSTEM MODELING.....................................................................................................................17
3.1. Use case model........................................................................................................................17
3.1.1. Actor specification.............................................................................................................17
3.1.2 .Use Case Diagram..............................................................................................................18
3.2. Sequence diagram....................................................................................................................26
3.3. Class diagram......................................................................................................................33
3.4. Activity diagram..................................................................................................................34
Chapter Four: System Design..............................................................................................................40
4.1. Design goal...............................................................................................................................40
4.2. System decomposition.............................................................................................................40
4.3. System architecture............................................................................................................42
4.4. Deployment diagram...........................................................................................................43
4.5. Persistent Modeling/ Database Design...............................................................................44
4.6. Access control and security policy.......................................................................................45
4.7. User Interface Design..........................................................................................................46
Appendix A..........................................................................................................................................48
References..........................................................................................................................................49
vii | P a g e
List of Table
Table 1.1: Hardware Cost Estimation....................................................................................................5
Table 1.2: Software Cost Estimation.....................................................................................................5
Table 1.3: schedule...............................................................................................................................6
Table: 3.1: System use case description for register...........................................................................19
Table 3.2: System use case description for login.................................................................................20
Table 3.3: System use case description for order product..................................................................21
Table 3.4: System use case description for remove items..................................................................22
Table 3.5: System use case description for add new item...................................................................23
Table 3.6: System use case description for update product................................................................24
Table 3.7: System use case description for update employee............................................................25
Table 3.8: System use case description for Active/Deactivate employee...........................................26
Table 4.1: Access control of actors......................................................................................................46
List of Figure
Figure: 3.1: System use case diagram.................................................................................................18
Figure 3.2: Sequence diagram for login...............................................................................................27
Figure 3.3: Sequence diagram for registration....................................................................................28
Figure 3.4: Sequence diagram for add new product...........................................................................29
Figure 3.5: Sequence diagram for update product..............................................................................30
Figure 3.6: Sequence diagram for remove product.............................................................................31
Figure 3.7: Sequence diagram for order products...............................................................................32
Figure 3.8: System class diagram........................................................................................................33
Figure 3.9: Activity diagram for customer registration........................................................................34
Figure 3.10: Activity diagram for Create User Account.......................................................................35
Figure 3.11: Activity diagram for user’s login......................................................................................36
Figure 3.12: Activity diagram for add new item..................................................................................36
Figure 3.13: Activity diagram for update item.....................................................................................37
Figure 3.14: Activity diagram for delete item......................................................................................38
Figure 3.15: Activity diagram for order product..................................................................................39
Figure 4.1: system decomposition......................................................................................................41
Figure 4.2: subsystem decomposition.................................................................................................42
Figure 4.3: system architecture...........................................................................................................43
Figure 4.4: deployment diagram.........................................................................................................44
Figure 4.5: persistent modeling/database design...............................................................................45
Figure 4.6: login interface...................................................................................................................47
Figure 4.7: registration interface.........................................................................................................47
viii | P a g e
CHAPTER ONE
1 INTRODUCTION
Online Shopping center is the system that involves selling and buying process. This online
shopping for Ethiopian Industrial Inputs Development Enterprise is a web based system that
works by providing an opportunity for different customer in south Gondar by creating account
and sale products online. It also allows different users to buy different products from this branch
that are registered on this system. This system works online payment. On this system the users
can get different kinds of products based on their interest. The main purpose of this project is to
make each customers and workers activity in computerized way rather than manually which
because of its time consuming.
1.1. Background
Ethiopian Industrial Inputs Development Enterprise (EIIDE) one of the governmental
organization which is works importing product and distributing for customers in Ethiopia. This
organization is establish in 1935 E.C. by foreign person. In the first time, the name of this
organization was Ethiopian Domestic Distribution Corporation (EDDC), but after six years they
enhances their scope and they changes the name of this organization to Ethiopian Whole sailor
Trade and Import Enterprise (EWTIE), But now the time being the name of this organization is
changed to Ethiopian Industrial Inputs Development Enterprise (EIIDE). This organization has
around 82 branches in Ethiopia. One of the branch for this organization is found in Debretabor
city, this branch also gives different service in North Gondar zone, due to providing wide variety
of food, clothes and household products, so it is larger in size and has a wider selection. It is
difficult to manage the stock of companies shop i.e. to identify which products are available in
the stock and which are not available in the stock, these is doing by labor intensive and therefore
also quite expensive. The shopping process was slow, as the number of customers who could be
attended to at one time be limited by the number of staff employed in the store, so in order to
solve the problems we recommend to develop an automated Online Shopping for EIIDE.
1.2. Study of existing system
In the present system Debretabor branch of this organization sell their products and service
through various ways. This conventional technique may not achieve the intended goals, as their
reach is limited to little number of customers. In addition to consuming more energy and waste
1|Page
time to get products. The existing system is too much hard to implement. But it was found to be
inefficient in meeting the growing demands of population.
1.3. Statement of the problem
We have noticed the following problems in the existing system of the organization, wastage of
money, the time wasted in searching for products, customer may not be satisfied with the limited
number of products choices, It is difficult to search, update, delete and add products, customers
may not be satisfied with the options, Information not updated frequently, there is no advertisement
of product however in the new system products are promoted online with their types and prices, there is
no written items description and price, use more labor compared to new system which reduce human
labor, it is a time consuming process. Generally, the existing system is difficult to perform all activities.
1.4. Objectives of the project
1.4.1. General objective
The main objective is developing or creating a web based shopping area in order to purchase and
sale products online.
1.4.2. Specific objectives
 Identifying how the existing system works.
 Identify functional and non-functional requirements for the new system.
 Design a new system that can overcome the problem of the current system.
 Provide a system that reduces the manual work in the institution.
 Provide all transactions are available and easy for users.

 Provide the records of customers, item details, employees.
1.5. Scope of the project
Scope
 The system will able to manage user account.
 The system will perform online payment.
 The system will give receipt verification after customer bought a product.
 The System will calculate vat from customer or buyer.
 The system will back up the database files.
 The system will give notification for appropriate transaction.
 The system will generate report.
2|Page
 The system will advertise new products.

 The system will provide all transactions are available and easy for users.
Limitation
 It will not work without internet connection
 Transportation system is not consider in this system.
 The system will not consider suppliers.
1.6. Significance of the study
 The system will provide security for customers.
 Customer will get products anytime and anywhere.
 The shop keeper will manage their store easily.
 This branches will sales their products easily for customer.
 It will fulfill what customer needs.
 It will decrease the load and number of employees.
 It will describe details information of the items.
 It will provide service for 24 hour.
 It will attract the customer and it is safety way of data storage and retrieval.
1.7. Feasibility of the project

The main objective of the feasibility study of this project is to test the Technical, Operational and
Economical feasibility for adding new modules and debugging old running system. Feasibility
study enables us to:-
 Determine whether or not the project can be developed in terms of resources,
 Evaluates and identifies the newly developed system.
Therefore, the feasibility analysis of proposed system involves the following:-
1.7.1. Economic feasibility
Here we analyze the system by comparing the benefit and cost of this proposed system with the
existing system. So, the benefits and cost that are obtained for the users and organization by
using this proposed system can be categorized as.
Tangible benefits are:
 Reduce the cost of wasted papers.
 No cost wasted to search for products.
3|Page
 Reduce cost that is paid to the advertise body as commission.

Intangible benefits:
 The customers and users will be satisfied.
 The employers will also be satisfied.
 No time wasted to search for products.
 No time wasted by the customer to search for products.
One time cost:
 The cost for the designers and programmers.
 The cost of materials like software and hardware required.
 The cost of domain name to run the website.
Recurring (permanent) cost:
 The payment or salary of the web administrator and employee.
 The cost to maintain the website.
Table 1.1: Hardware Cost Estimation
S.no Material Amount Price per unit Total price
1 A4 size paper 2 Desta 130 Birr 260Birr
2 Pen(lexis) 4 5 Birr 20 Birr
3 Flash disk 2 120 Birr 240Birr
4. Note book 2 20 Birr 40 Birr
5 CD 3 15 Birr 45 Birr
6 Computer 1 12,500 Birr 12,500 Birr
Total 13,105.00 Birr
Table 1.2: Software Cost Estimation
No Material Price per unit
1 Microsoft office 2007 Free
2 wamp server Free
4 Notepad++,Notepad Free
5 Php Free
6 Edraw max Free
4|Page
1.7.2. Schedule feasibility

Enables this project to meet organizational deadlines, this project will be completed in six
months. We scheduled our project into two parts in terms of time. Depend on this schedule this
project is definitely feasible.
Table 1.3: schedule
ACTIVITY TIME
NOV DECEMBER JANUARY FEBRUARY - MAY JUNE

PROJECT
PROPOSAL
REQUIREMENTS
ANALYSIS
DESIGN
IMPLEMENTATIO
N AND CODING
TESTING &
PROJECT DEFENSE
1.7.3. Technical feasibility

Technical feasibility can be defined in two ways:
 Do we have skilled man power to develop the project?
 Do we have enough technology?
The proposed system is technically feasible as the resources (equipment’s) that are needed for
the proposed system are easily available and uses easy method as well as user friendly
programming languages for developing and also it is easy to run once after the system is
developed. The Programming Language, Database and server that we have used are a free and
open source so we can find and use them; this also makes the proposed system technically
feasible.
1.7.4. Operational feasibility
The proposed system can be used effectively after it has been developed. Users will not have any
difficulty with the new system to produce the expected benefits. System will be developed based
5|Page
on the policies of the organization and it doesn’t require much training for users. And the new
system will not place any new demands on users nor requires any operating changes. The new
system was considered to be operational feasible.
 User-friendly
 Security
 Portability
 Maintainability
1.8. Methodology
1.8.1. Data gathering techniques
There are different types of data collection methods. From these methods we use the following in
order to prepare our project work.
Interview: - the project team asks the most important method that helps us to get most critical
information about the general view of the Shops is by interviewing owner of the team gets
responses from the manager and employees of the organization and they also told us that, the
current system is used manual system that means all activates performed by agenda. So that the
system is complex, more time consuming and redundant activity. Some interview questions
are:-
 When did the organization established?
 What kind of system the organization used? Web based system or manual?
 How many employees are in the organization?
 What kind of service the organization give to customer?
 What type of product the organizations have?
 What is the problem of the current system?
Observation: - this method is also used to collect data, done by direct seeing the working
environment. The project team observed physically by going to in Debretabor branch of this
organization. Also observed that there is no any computerized system in the Shop and also
information about the Shop and the service that the Shop provides were not available easily.
The team also observes that ordering is only by face to face.
6|Page
1.8.2. Design Methodology

In this project, we are going to utilize the object oriented development approach for system
modeling by the following reasons:
 Simplicity of implementation.
 Reusability of code.
 Efficiency of modeling the real world.
 Ease of adopting changes at any level.
 A tool we will use during system analysis and design.
1.8.3. Implementation Methodology
Hardware tools
 Processor:- AMD E1-1200 APU with Radeon(tm) HD Graphics 1.40GHz
 Printer: to print out a document into hardcopy.
 RAM :- 4GB
 Flash 8 GB, CD and DVD.
 Stationary materials like pen and paper.
Software tools
 Operating system: 64 bit operating system, x64-based processor, window 8
 Edrawmax: to draw UML diagram.
 Microsoft word & power point 2013 to write and prepare the documentation and to present
our project.
 PHP: used to implement server side sub system: front end.
 NOTPAD++: used to write and edit codes.
 WampSever: used to run server side application virtually.
 MySQL-server: back end.
1.8.4. Testing Methodology
 Unit Testing: The unit testing is performed to test the validity of the individual units of the
online shopping for EIIDE modules. These modules are login module, registration module,
add new product module, user order modules.
 Integrity (action) Testing: When all the developed modules is completed and integrated the
test phase will be conducted. In this phase the interface between the modules are tested. This
7|Page
phase basically verifies whether inter module exchange of information and events are as per
required system behavior i.e. if user users are login it should displays admin page for admin,
warehouse page for store keeper and if user wants to order the product, the should be login.
 System Testing: The system testing phase incorporates the performance stress testing so as
to meet the product criteria with respect to the desired bench marks. This is necessary test for
highly data intensive product. Here there are two testing methods:
 Alpha testing: Alpha testing in this testing method, the system will tested by giving the
correct input it will tested by the developers' site, when the developer check all form i.e.
login form registration form order form, it performs appropriate transaction.
 Beta testing: Beta testing comes after alpha testing and can be considered as a form of
external user acceptance testing. Versions of the software, known as beta versions, are
released to a limited audience outside of the programming team. When the customer uses this
system it will perform correct action e.g. when they login and register, it should display
meaning full message.
8|Page
CHAPTER TWO
2 REQUIREMENT ANALYSIS DESCRIPTION
2.1. Overview of existing system
The current system of Ethiopian Industrial Inputs Development (EIIDE) are not provide goods
and services Online and has not provide online banking system to make payment, to purchase
items. They simply selling and purchasing items to their customers face to face and only generate
the day to day income of the shop. The activity of the retailer is selling the items dealing within a
customer. The warehouse employee checks items if there are below the minimum stock balance,
and then he sends detail of a new or additional stock item to be purchased. The customer order to
one of the supplier and buys the specified stock items. The warehouse receives the new items
based on purchasing lists and receipts. The manager receives the receipt of the system of the new
item and set the normal price. The price is based on the original purchase price from the
suppliers, the cost of transport and storage and desired profit margin for that product. Managers
monitors all those and adjust product prices accordingly, and sends the copy of the new item’s
price list to the warehouse employee. The warehouse employee has the responsibility to put price
on each item and inform the customers about a new product. Finally customers can easily take
goods what they want from display/shelf and they make payment to the warehouse employees.
When customer purchases goods for cash, details of the sales are recorded using cash register,
and the customer is provided with a receipt giving the details of the sales and payments.
2.1.1. Activities of Existing System
Shop manager comes with the following activities:-
 Plan in the Shop
 Organize the sellers
 Control on a daily basis activities
 Make decision
 Control the bill
 Generate report
The Warehouse Employee comes with the following activities
 Activate in the customer service
 Keep materials properly
9|Page
 Obtain customer order

 Check availability
 Show items for the customer
 Tells the price of the item
 Give the items to the customers
 Receive pay from customer
 Submitted total payment to the seller
Customers come with the following activities:-
 Ask information
 Order item as they want
 Asking price of the item
 Take items from the seller
 Pay the cost of item
2.1.2. Problems of the current system
The system works manually and the data handling and processing system creates problem on
summarization, updating, getting the item types and integration of data for easily and fast
implementation of the activity. The current system is very time consuming. This system is more
prone to errors and sometimes the approach to various problems is:
 The system couldn’t generate needed report.
 The system is very time consuming.
 It is difficult to know how many the items are remaining in the store.
 It is difficult to know how many items are sales in time duration.
 Wastage of resource example paper, human resource, time.
 It is difficult to count the items or goods that are present in the store.
 Customers don’t know the cost of each item.
2.1.3. SWOT analysis
Weakness
The existing system has a weakness like:
 It takes time to calculate price of each items and serve many customer at the same time.
 It is also time consuming in identifying the individual prices of each goods.
10 | P a g e
Strength
The current system has many employees and one manager, the employee works cooperatively
with each other with good approach. Although strength of the existing system stated below.
Those are:
 The way of attracting the customer towards the market with good approach.
 Most people’s chose on this shop in case of they get good product with a good cost and with
a best performance so the customers are delighted.
Opportunities:
 Increase job opportunity for employees
Threats:
 The manual data may lose and decay by natural factors.
2.2. Overview of the new system
The proposed system is concern about the online shopping for EIIDE in order to provide an
alternative solution for the manual shopping system. This includes adding, deleting and updating
items on the cart as well as advertising the product and generates a report. The first activity is
based on adding the items to the shopping cart along with the rate which are present in the shop
and the name of the items which the shop will agree to sell. This authority is given to the
warehouse employee. Any modifications to be done in the item name and rate can be done by the
warehouse employee. He also has the right to delete any item. The other activity done in the new
system is managing employees, view order, accept feedbacks, update profile and view reports.
This activity can be done by warehouse employee and manager, but managing an employee is
only done by administrator and manager. Most of warehouse employee and manager activities
are done by administrator. A customer first has to register and login to the site. After he/she login
to the site, they can see all the products and their wants since the products are listed on a
shopping cart with their details such as their costs, and then they can add the product or an item
and their wants to his/her carts and calculating the cost of product from the bill. Then the
warehouse employee view the customer’s order of product and calculate the cost of products
send the bill to the customer, Finally the organization send the ordered products for the
customers using their services.
11 | P a g e
2.2.1. Functional Requirements

Functional requirements should include functions performed by specific screens, outlines of
work flows performed by the system, and other business requirements the system must meet.
The functional requirements in this system are listed below.
Manager
 System will allow to manages employees (active/deactivate, create, update).
 System will allow to accept feedbacks.
 System will allow to view order.
 System will allow to view report.
 System will allow to login/ logout into site.
Administrator
 System will allow to manage employee account (add, active/deactivate, update).
 System will allow to update profile.
 System will allow to approve the customer account.
 System will allow to recover database.
 System will allow to create coupon.

Customer
 System will allow to register.
 System will allow to manage cart (View item, Add to cart, remove cart, order item).
 System will allow to perform payment and vat.
 System will allow to send feedback.
 System will allow to recover account.
 System will allow to view notification.
Warehouse employee
 System will allow to manage product (add, update, delete).
 System will allow to view customer order.
 System will allow to update profile.
 System will allow to view notification.
12 | P a g e
 System will allow to login/logout to site.

2.2.2. Non Functional Requirements
Non-functional requirement is a requirement that specifies criteria that can be used to judge the
Operation of a system, rather than specific behaviors this requirement does not directly affect
the performance of the proposed system but, they concerned with security, performance,
usability, maintainability, reliability, efficiency, portability (across operating systems)
testability, understandability etc. The non-functional requirements of the system are presented
below: -
 User Interface: - user friendly interface with easy navigational scheme.
 Error handling Mechanism:- handles invalid inputs and display user error in
meaningful messages due to users are order item, login into the system, registration.
 Security issue: - provides security tasks when users are registering by using md5 encryption
of user password. This is used to prevent any unauthorized and any authorized user can
access their account using their password and user name.
 Maintainability: -When the website fails, it can be maintained easily. What does it mean to
say the web has failed? Over time the number of people using the system will dramatically
grow and customer demands will grow and change. So this website can easily be rebuilt to fit
the evolving customer demands and the newly arriving changes. So it can be easily
maintained and can grow to a better version.
 Availability: -The system will be available for 24 hours to users with internet connection.
 Backup and Recovery: As world is not clear from disaster situation our system data is
placed in different server. So database files are backed up every hours. And also when the
user are forgotten their password, they can recover by using their email.
2.2.3. System Requirement
Hardware requirement
 Client computer (laptop).
 Server computer with Uniform server WampSever installed.
 Flash 8GB
Software requirement
 Web browser (Mozilla Firefox, Google chrome).
13 | P a g e
 Wamp server.
 Microsoft word 2013
 Macromedia Dream Weaver.
 Edrawmax(trial version)
2.2.4. User requirements
The main purpose of requirements document is to serve as an agreement between the developers
and the users on what the application would do. Users are individuals that use the system or
software in its environment. User requirements are their verified needs for that system or
software. The following are user requirements:-
 Anyone may sign up for a customer account if he/she is not a member before.
 The user must fill required information correctly for all forms.
 The user must confirm user name, email and password are acceptable.
2.2.5. Business rules
Business rules describe the operations, definitions and constraints that apply to an organization.
Business rules can apply to people, processes, corporate behavior and computing systems in an
organization, and are put in place to help the organization achieve its goals.
BR1: The user has to login to do his/her business operation on the system.
BR2: It is not allowed to see all reports unless he/she is the manager.
BR3: It is not allowed to add, update, and delete items unless he/she is the Warehouse employee.
BR4: It is not allowed to add and delete users unless he/she is the Administrator.
BR5: The customer must have logged in before order items.
BR6: The customer cannot purchase unless enough money in their bank account.
BR7: Admin or warehouse employees must have logged in to view order.
BR8: Admin must have deactivate employees to prevent illegal access.
14 | P a g e
CHAPTER THREE
3 SYSTEM MODELING
3.1. Use case model
A use case is a sequence of transactions performed by a system that yields an outwardly visible,
measurable result of value for a particular actor. A use case typically represents a major piece of
functionality that is complete from beginning to end. An actor represents whatever (Customer,
admin, manager, WH employee) interacts with the system. The actor is not part of the system
itself and represents anyone or anything that must interact with the system.
3.1.1. Actor specification
 Customer: - someone who buys product.
 Administrator: - a special user of the system who can setup access right for other users.
 Warehouse Employee: a user of the system who is responsible for managing the catalog of
the products. Performs login and view order item.
 Manager: who is manages the organization.
15 | P a g e
3.1.2 .Use Case Diagram
Figure: 3.1: System use case diagram
16 | P a g e
Table: 3.1: System use case description for register

Use case name Register
Participating actor Customer
Description New Customer of the site is registered here.
Precondition The Customer must be new user
Flow of events Basic Action:

First: should be activate homepage
1. The customer click on registration button
2. The system displays a registration form
3. The customer enters all required inputs
4. The customer clicks on summit button.
5. The system validates the data entered
6. The system displays successfully registered message and login
page.
7. The use case end
Alternate Course A: Invalid data entered.
A.5. The system displays error massage
A.6. The system asks to re-enter valid data
A.7. The use case end
Alternate Course B: If the customer already registered
B.6. The system displays already registered message
B.7. The system displays login page
B.8. The use case end
Post condition The customer is registered.
Table 3.2: System use case description for login

Use case name Login
17 | P a g e
Participating Actor Customer, Administrator, Ware house employee, manager

Description Only the registered users will login, it may be the customer,
Administrator, Ware house employee or manager.
Precondition The user have to be already register
1. The user clicks on login button
2. The system displays a login form
3. The user enters user name and password
4. The user clicks on summit button.
6. The system displays successfully logged in message.
7. The use case end
A.8. The use case resume to step 4
Alternate Course B: If the user is not having an account
B.6. The system display your user name and password is incorrect
B.7. The use case resume to step 3
Alternate Course C: If the user forgot password
C.6. The system display your user name and password is incorrect
C.7. The user must have to click on forgot password button
C.8. The system asks to fill username and email address
C.9. The customer clicks on Change button
C.10. The system sends the password to his/her email account
C.11. The use case end
Post condition A user is logged into the system
Table 3.3: System use case description for order product

Use case name Order product
18 | P a g e
Description The Customer Orders the products what he wants to buy and it includes
login before order.
Precondition The customer must add an items before ordering
Flow of action Basic Action:

1. The customer clicks on products button and Shopping cart button
2. The system displays product list form
3. The customer click on Order button
4. The system displays a login form
5. The customer enters user name and password
7. The system return message and display on cart page
8. The customer add an items to cart
9. The customer click on summit button
10. The system send data to the controller
11. The system execute save to order table
12. The system display successfully ordered products.
Alternate Course A: If the customer not added products.
A.8. The system display your cart is empty massage
A.9. The system ask to add items
A.10. The customer click on product button
A.11. The system display product list page
A.12. The customer added an item to his/her cart
A.14. The use case end
Post condition The customer get the product
Table 3.4: System use case description for remove items
Use case name Remove items from cart
19 | P a g e

Description The customer removes the product from the cart
Precondition The customer added a product to the cart.

1. The customer clicks on cart button
2. The system display customer cart with items information.
3. The customer selects item to remove from the cart.
4. The customer clicks on the Remove item link.
5. The system asks the user for the confirmation.
6. The customer confirms the removal
7. The system removes the item from the customer cart.
8. The system displays the products is removed successfully
9. The use case end.
Alternate Course A: If The user not confirms to remove the item
A6. The use case go to step 2
Post condition The products is successfully removed
20 | P a g e
Table 3.5: System use case description for add new item
Use case name Add new product
Participating actor Warehouse employee

Description The Warehouse employee creates the product category list
Precondition The Warehouse employee must be logged in
Flow of event Basic Action:

1. The warehouse employee clicks on add new product button.
2. The system displays add new product form
3. The warehouse employee fills all required inputs
4. The warehouse employee clicks on add button.
5. The system validates the data entered and send.
6. If valid the system displays successfully added message.
7. The use case end
Alternate Course B: If the product already available.
B.9. The system displays the product already available message
B.10. The system displays add new product page
B.11. The use case end
Post condition The category list of the product is created.
21 | P a g e
Table 3.6: System use case description for update product

Use case name Update product
Participation actor Warehouse employee
Description The Warehouse employee updates the product category list
Precondition The Warehouse employee must be logged in
Flow of event Basic Action:
1.The warehouse employee enter product code in the search form
2. The warehouse employee clicks on search button.
3. The system displays searched product.
4. The warehouse employee click on Edit button
5. The system display product information
6. The warehouse employee update the product information
7. The warehouse employee clicks on update link button
8. The system validate the data entry
9. The system display successfully updated message
10. The use case end
Post condition The category of the product is updated.
Table 3.7: System use case description for update employee

Use case name update employee
22 | P a g e
Participating actor Administrator, manager

Description The Administrator or manger wants to update user
Precondition The Administrator is logged in
Flow of control Basic Course of Action:
1. The Admin or manger clicks on update Employee button.
2. The system displays Employee page
3. The Admin and manger fill employee name in the search form
4. The Administrator or manger clicks on search button.
5. The system displays searched employee.
6. The Administrator or manger clicks on update link button
7. The system asks for confirmation
8. The administrator or manger confirms the deletion.
9. The system display successfully updated account.
Alternate Course A: If the administrator or manger enters in correct
Employee Name
A.5. The system displays there is no employee with this name message
A.6. The system asks to re input the employee information.
Alternate Course B: If the employee does not exist
B.5. The system display the employee is doesn’t exist
B.6. The system resume at step 2
Alternate Course C: If the admin or manger confirms not to update
C.7. The system resume at step 7
Post condition The employee is updated
23 | P a g e
Table 3.8: System use case description for Active/Deactivate employee

Use case name Deactivate /active employee
Participating actor Manager

Description The Manager wants to Deactivate /active employee
Precondition The Manager is logged in
Flow of control Basic Course of Action:
1. The system displays Employee page
2.The manager clicks Deactivate /active button
3. The Manager select on Deactivate or active button
4. The system Deactivate or active employee account.
Alternate Course A: If the employee does not exist
A.1. The system display the employee is doesn’t exist
A.2. The system resume at step 2
Post condition The employee is Deactivate /active employee account
3.2. Sequence diagram

To see the interaction between objects, the sequence diagram is describe for each identified use
cases. In Figure below, once the user has activated the registration module by interacting with
the boundary object “New Registration Button” button, the control object named “Registration
Control” manages the activities involved in “Register customer” use case. First the “Registration
Control” creates registration form which will be filled by the customer and submitted. The
registration control sends the record to a persistent storage. The sequence diagrams for “Login”,
“customer registration”, “View product “and “order product” use cases are shown in figures
below respectively.
24 | P a g e
Figure 3.2: Sequence diagram for login
25 | P a g e
Figure 3.3: Sequence diagram for registration
26 | P a g e
Figure 3.4: Sequence diagram for add new product
27 | P a g e
Figure 3.5: Sequence diagram for update product
28 | P a g e
Figure 3.6: Sequence diagram for remove product
29 | P a g e
Figure 3.7: Sequence diagram for order products
30 | P a g e
3.3. Class diagram

It shows the static features of the actors and do not represent any particular processing. It is an
abstraction of the real environment class of seller, patron (user) and Administrator. The UML class
diagram for this system can depict all these things quite easily as follow:
Users
Account -fname
-account_ID -lname
-accounttype 1 Have 1 -password
-username -phone
-password -sex
-age
+login () -account_ID
+logout ()
Generalize
Customer Employee
- cus_ID
- State -emp_ID
- City -account _type
- Kebele
- Housenum
- Accountnum
+ Addtocart ()
Generalize
+ Viewcart ()
+ Order ()
+ register ()
M
Order Administrator
Manager
Warehouse
Employee M 1 + Report () +create ()
+Vieworder () 1 1 + delete ()
Manage + create ()
+vieworder ()
M +
1
Manage
M 1
View
Product M
Report
- pro_ID
M - pro_name - rep_ID
- pro_code - cus_ID
- - cus_fname
-pro_desc -
pro
- _image M cus
- pro _lname
_name
- pro_quantity
price - pro_code
+ add () - pro_quantity
+ Update () - Orderdate
+ delete ()
+ Report ()
Register
Figure 3.8: System class diagram
31 | P a g e
3.4. Activity diagram
Homepage
Register
Valid
Successfully
Fill form Summit System validate
Registered
Invalid
Figure 3.9: Activity diagram for customer registration
32 | P a g e
Valid
Enter username Check username and password Manage user
And password
Invalid
Employee
Registration
Successfully Register Fill form

Created
No
Yes
Check validity
Figure 3.10: Activity diagram for Create User Account
33 | P a g e
Enter username and

Password
Check username and

Password
No
Yes
Successfully logged in User page display
Figure 3.11: Activity diagram for user’s login
34 | P a g e
Login
Manage
Product
Add new
Not exist
Check an item
Exist
Added
Add to cart
Successfully
Figure 3.12: Activity diagram for add new item
35 | P a g e
Login
Manage
Product
Update
Product
Enter Product id
Not exist
Exist Updated
Check whether product exist Fill required input Update
Successfully
Figure 3.13: Activity diagram for update item
36 | P a g e
Login
Manage
Product
Delete
Items
No
Enter Product id Require confirmation
Yes
Not exist
Exist Deleted
Check whether product exist Delete
Successfully
Figure 3.14: Activity diagram for delete item
37 | P a g e
Login
Enter username and

Password
Invalid
System Validate
Valid
User page
No
View product
Order
Not exist
Yes
Check weather
Exist Confirmation Print
Item exist or not
Add to cart receipt
Figure 3.15: Activity diagram for order product
38 | P a g e
Chapter Four: System Design

4.1. Design goal
The goal of the system design is to manage complexity by dividing the system in to manageable
pieces. Some of the goals are listed below.
 Security: The system should be secured from unauthorized user.
 Modifiability: The system should be modifiability to modify different services depending on
the need of the institute.
 Efficiency: The system must do what it is supposed to do efficiently without the problem.
 User friendly interface: Users can easily input and retrieve their profile and history. This
means that the system must accommodate a clearly understandable user interface.
 End User Criteria: - The system have their own helping system when it use the system or
user manual.
4.2. System decomposition

To reduce the complexity of the solution domain, we decompose a system into simpler parts of
online shopping for EIIDE.
 Admin site
 Customer site
 Manager site
 Warehouse employee site
39 | P a g e
Figure 4.1: system decomposition

Subsystem decompositions help reduce the complexity of the system. The subsystems can be
considered as packages holding related classes/objects. These subsystems are further
decomposed into other subsystems. The major subsystems are manage employee, manage
product, view report, view order, add to cart, remove from cart and order item.
 Admin: manage employee

 Customer: manage cart, view product
 Manager: manage employee
 Warehouse: manages product, view order
40 | P a g e
Figure 4.2: subsystem decomposition
4.3. System architecture

The newly proposed software architecture of this system consists of three users interface
(presentation, business and Back-office) with their accessibility.
Presentation interface - The presentation interface is an agent to communicate client with
application server. And it is responsible for transfer request of the client (end user) to application
server and also transfers response to the client.
Business interface - The business interface contains the application server. The application
server implements the actual business rule and organizational units. It will interact with Back-
41 | P a g e
office interface if user request need database access or if user needs to store or retrieve data
to/from database.
Back-office interface - The back-office interface provides some basic services to the business
tier, such as a database system and an authentication or acknowledge and directory service.
Figure 4.3: system architecture
4.4. Deployment diagram

Deployment modeling on this project is used to show the hardware of the system, the software
that is installed in the hardware and also the middleware that is used to connect the separate
machines to one and other. In most cases. This system Deployment modeling is also used for
how to communicate and access data from the database server.
42 | P a g e
Figure 4.4: deployment diagram

4.5. Persistent Modeling/ Database Design
Persistent data management deals with how the persistent data i.e. file, database, etc. are stored
and managed and to outlives a single execution of the system. Database design is the process of
producing a detailed data model of a database. This data model contains all the needed logical
and physical design choices and physical storage parameters needed to generate a design in a
data definition language, which can then be used to create a database.
43 | P a g e
Figure 4.5: persistent modeling/database design

4.6. Access control and security policy
Unauthenticated users are not allowed to edit any information that is displayed in each page and
also information that is stored in the web database. In addition to the one specified above, DB-
Administrator are obliged to come up with some account information (for example, their
username and password) to get a required service from the EIIDE. The shop would have
provision mechanism for those who have forgotten their password. One way to showing who can
access what is by using an access control matrix. Many levels of security protect sensitive
documents and files from unauthorized viewers. Each user has a security access level and each
document has a sensitivity level. Depending upon the access level of the user, they would see
only the list of documents that is appropriate for their security access level. Generally, all users
have their own user names and passwords to control security access levels and document
sensitivity level.
44 | P a g e
Table 4.1: Access control of actors

Actor Manage Manage Mange Accept View View Manage Manage
employee Customer product feedback report order user cart
account account
Admin  
Manger    
WH   
employee
customer  
4.7. User Interface Design
User Interface Design is contain home page, products page, login form, registration form, and
shopping cart page. Home Page is a page that users interact with the system primarily. It contains
Home, Products, Register, Login, about us and Contact us. The following interface is example of
user login interface
Figure 4.6: login interface

Registration page is used to register new Customer and can login in this page. The customers of
the system have to fill all those data to register if does not fill all the box alert massage to
customer and cannot register.
45 | P a g e
Figure 4.7: registration interface
46 | P a g e
Appendix A
Appendix for Interview questions
 When did the organization established?
 What kind of system the organization used? Web based system or manual?
 Who is the owner of the organization?
 How many employees are in the organization?
 What kind of service the organization give to customer?
 What type of product the organizations have?
 Have you give receipt to customer?
 Have you any computerized system?
 Do you have an items list with their descriptions and price?
 What is the problem of the current system?
 Who is generate a report?
47 | P a g e
References
[1] http://en.wikibooks.org/wiki/Systems_Analysis_and_Design/Introduction
[2] http://www.amazon.com
[3] Ambler, Scott (2001) The Object primer: The application Developers Guide to Object
Oriented and the UML.2nd rev. Ed England: The Cambridge University Press.
[4] Bruegge, Bernd (2000) Object oriented Software Engineering Conquering Complex and
Changing System. Upper Saddle River: Prentice Hall.
48 | P a g e

Helps

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Helps

Uploaded by

Copyright:

Available Formats

DEBRETABOR UNIVERSITY

A DOCUMENT SUBMITTED TO THE FACULTY OF TECHNOLOGY DEPARTMENT

Acronyms and Abbreviations

2.2.1. Functional Requirements............................................................................................13

 Provide all transactions are available and easy for users.

 The system will advertise new products.

 It will decrease the load and number of employees.

 It will describe details information of the items.

 It will provide service for 24 hour.

1.7. Feasibility of the project

 Reduce cost that is paid to the advertise body as commission.

1.7.2. Schedule feasibility

Table 1.3: schedule

NOV DECEMBER JANUARY FEBRUARY - MAY JUNE

1.7.3. Technical feasibility

1.8.2. Design Methodology

 Obtain customer order

2.2.1. Functional Requirements

 System will allow to recover database.

 System will allow to create coupon.

 System will allow to login/ logout into site.

 System will allow to login/logout to site.

3.1.2 .Use Case Diagram

Figure: 3.1: System use case diagram

Table: 3.1: System use case description for register

Participating actor Customer

Description New Customer of the site is registered here.

Precondition The Customer must be new user

Flow of events Basic Action:

Table 3.2: System use case description for login

Participating Actor Customer, Administrator, Ware house employee, manager

Table 3.3: System use case description for order product

Participating actor Customer

Flow of action Basic Action:

Participating actor Customer

Precondition The customer added a product to the cart.

Flow of events Basic Action:

Participating actor Warehouse employee

Precondition The Warehouse employee must be logged in

Flow of event Basic Action:

Table 3.6: System use case description for update product

Table 3.7: System use case description for update employee

Participating actor Administrator, manager

Table 3.8: System use case description for Active/Deactivate employee

Participating actor Manager

3.2. Sequence diagram

Figure 3.2: Sequence diagram for login

Figure 3.3: Sequence diagram for registration

Figure 3.4: Sequence diagram for add new product

Figure 3.5: Sequence diagram for update product

Figure 3.6: Sequence diagram for remove product

Figure 3.7: Sequence diagram for order products

3.3. Class diagram

Figure 3.8: System class diagram

3.4. Activity diagram

Figure 3.9: Activity diagram for customer registration

Successfully Register Fill form

Figure 3.10: Activity diagram for Create User Account

Enter username and

Check username and

Successfully logged in User page display

Figure 3.11: Activity diagram for user’s login

Figure 3.12: Activity diagram for add new item

Figure 3.13: Activity diagram for update item