ADDIS ABABA INSTITUTE OF

TECHNOLOGY
CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC
COMPUTING
DEPARTMENT OF SOFTWARE ENGINEERING

Min Letazez - An E-commerce platform

Team Members
Abdi Nuredin ATE/6459/07
Billion Shiferaw ATE/6424/07
Mesfen Yohannes ATE/6440/07
Sihul Tibeb ATE/6450/07

Advisor: Mr. Daniel Abebe

January 2020

1
 Addis Ababa Institute of Technology
Information Technology and Scientific Computing

Min Letazez - E-commerce platform

This Project documentation submitted in partial fulfillment of the requirements for the Degree
of Bachelor of Science in Software Engineering.

Project Advised by:

Mr. Daniel Abebe

Name and signature of Members of the examining board:

Name Title Signature Date

1. __________________ Advisor _____________ _____________

2. __________________ Chairperson _____________ _____________

3. __________________ Examiner _____________ _____________

4. __________________ Examiner _____________ _____________

5. __________________ Examiner _____________ _____________

January 2020

1
 Declaration of Originality

We declare that this project is our original work and has not been presented for a degree in any
other university.

Name Signature Date

1. Abdi Nuredin __________________ __________________

2. Billon Shiferaw __________________ __________________

3. Mesfin Yohannes __________________ __________________

4. Sihul Tibeb __________________ __________________

This project documentation has been submitted for examination with my approval as university
advisor:

Advisor Name _________________________

January 2020

2
 ACKNOWLEDGEMENT

//write the acknowledgment

3
ABSTRACT

4
 Table of Contents
List of Figures ix

List of Tables x

ACRONYMS xi

1. INTRODUCTION 1

1.1 Background 1

1.2 The Existing System 1

1.3 Statement of the Problem 1

1.4 Objective of the Project 2

1.4.1General Objective 2

1.4.2 Specific Objective 2

1.5 Proposed System 2

1.6 Feasibility Study 2

1.6.1 Economic Feasibility 2

1.6.1.2 Developmental cost 2

1.6.1.2 Operational Cost 2

1.6.2 Technical Feasibility 2

1.6.3 Schedule Feasibility 2

1.7 Scope 3

1.8 Methodology 3

1.8.1 Data Collection Method 3

1.8.2 System Analysis and Design Methodology 3

5
 1.8.3 Requirement Structuring Tools 3

1.8.4 Data Modeling Tool 3

1.8.5 Testing Procedure 3

1.9 Project Management plan 4

1.9.1. Time Management plan 4

1.9 .2 Quality Management Plan 4

1.9 .3. Communication Management Plan 5

1.10 Business model

2. LITRATURE REVIEW 6

2.1 Introduction 6

2.2 Reviewed System 6

2.3 Summary of the review 6

3. SYSTEM REQUIREMENT SPECIFICATION 7

3.1 Introduction 7

3.1 Purpose 7

3.2 General Description 7

3.2.1 Product Perspective 7

3.2.2 Product Functions 7

3.2.3 User Characteristics 7

3.2.4 General Constraints 7

3.2.5 Assumptions and Dependencies 8

3.3 External Interface Requirements 8

3.3.1 User Interfaces 8

6
 3.3.2 Hardware Interfaces 8

3.3.3 Software Interfaces 9

3.3.4 Communications Interfaces 10

3.4 Functional Requirements 10

3.4.1 <Functional Requirement or Feature #1> 10

3.4.2 <Functional Requirement or Feature #2> 10

3.5 Use Cases 10

3.5.1 Use Case #1 10

3.5.2 Use Case #2 10

3.6 Non-Functional Requirements 10

3.6.1 Performance 11

3.6.2 Reliability 11

3.6.3 Availability 11

3.6.4 Security 11

3.6.5 Maintainability 11

3.6.6 Portability 11

3.6.7 Usability 11

3.7 Inverse Requirements 11

3.8 Design Constraints 11

3.9 Logical Database Requirements 11

3.10 Other Requirements 11

3.11 Change Management Process 11

4. SYSTEM DESIGN SPECIFICATION 12

4.1 Introduction 1

7
 4.1.1 Purpose 1

4.1.2 General Overview 1

4.2 Development Methods & Contingencies 12

4.3 System Architecture 12

4.3.1 Subsystem decomposition 12

4.3.2 Hardware/software mapping 12

4.4 Object Model 13

4.4.1 Class Diagram 13

4.4.2 Sequence Diagram 14

4.4.3 State chart Diagram (optional element) 14

4.5 Detailed Design 15

5. SYSTEM TESTING 17

5.1 Introduction 17

5.2 Features to be tested/not to be tested 17

5.2.1 Features to be tested 17

5.2.2 Features not to be tested 17

5.3. Pass/Fail criteria 17

5.4. Approach/Strategy 17

5.5 Test cases with specifications 18

6. SYSTEM USER MANUAL 19

6.1 scope 19

6.2 Installation and configuration 19

6.3 How to Operate the system 19

7. CONCLUSION AND RECOMMENDATION 20

8
7.1 Conclusion 20

7.2 Recommendation 20

BIBLIOGRAPHY 21

APPENDIX 22

9
 List of Figures
//automatically generated list of figures

10
 List of Tables
//automatically generated list of figures

11
 ACRONYMS
This subsection should provide the definitions of all terms, acronyms, and abbreviations
required to properly interpret the document

12
INTRODUCTION
Background
The main aim of this project Online Ordering system is to provide fast delivery services

to end users as possible. Usually people have to go to stores, shops, or any market itself to

buy its products and they have to wait in queue for a long time to get the orders. While our

approach is a convenient, inexpensive delivery service, traditional methods of market

require the buyer and seller meet and transact each other, taking the time of the buyer

which could have been spent doing other important tasks. Buyers use their app to request

an order, and a delivery personnel will take the order and delivers to their destination.

By using our application anyone can take the role of a buyer, a seller or a delivery

personnel. A seller will advertise the product they wish to sell, a buyer will choose and order

the product and a delivery personnel will scroll across the orders and delivers the order they

choose.

Currently, there is no delivery oriented application in the market. All applications are

either related to advertisements, e-commerce, payment system or the like. But the main

focus of our service will be delivery of products buyers are interested in while delivery

people will take care of the delivery and sellers are allowed to advertise and sell their

products on our platform.

The organizations involved in our application are companies that sell products. Products
might range from industrial products to local restaurants. Products will be classified
according to their industry and offered to the buyers. The platform will seamlessly connect
buyers, sellers, and delivery personnel accordingly

1
 To make the transaction easier, safe and secure for all parties it will be better if the

application has a online payment system. We will have to integrate available external

payment methodologies into our application. E-commerce projects, companies having their

own websites for sales purposes can use our platform.

The Existing System

Currently, the conventional method of market transactions requires the buyer physically

approaching the seller, identifying the product and dealing with the seller and finally buying the

product and transporting it to their destination themselves. In this process there are many

efficiency solutions possible to make the transaction flexible, and less time consuming while

assuring trust and reducing cost as much as possible.

Firstly, the buyer and the seller need not meet as long as there is a method for identifying

and ordering the specific product to be sold. If the buyer trusts the system in delivering that

specific product the meeting between the buyer and seller is actually unnecessary time

consuming act.

Second, the other reason for the two parties to meet is actually so that the buyer deals

with the seller about the detailed specifications of the product to create trust between them

and for future customer relations. If the platform offers a solution to this problem then it will be

an additional reason for avoiding the need for the contact.

2
 Third, the transaction itself can be hard for expensive products as the buyer may need to

transport the cash to the location of the buyer, If we have a solution that would avoid this step

the transaction will be securely performed online.

Fourth, all the responsibilities of securely delivering the product to the destination will lie

on the buyer themselves if they don’t have a delivery personnel. So by providing a delivery

personnel and a system and securely transporting the product our approach will reduce the

risks the buyer has to take.

While delivery transportation systems already exist for some markets, they have their own

disadvantages and shortcomings. First, they are specific to the different markets they work on

and are tied to them. Our approach will be general and adaptive to almost all industrial

products. Even when using these systems, the buyer has to rely on phone calls and verbally

describing the product and destination and discussing the transportation fee to the delivery

personnel. In addition, you will have to blindly trust the delivery personnel.

3
 Statement of the Problem
E-commerce Systems followed by delivery personnel have existed in foreign countries

for more than a decade now. In Ethiopia, due to the financial regulatory restrictions these

companies haven’t been able to adapt to the local market nor are there local e-commerce

companies with the same business approach. Clearly due to ease of access if there were a

system capable of allowing the order, delivery and sales of products of varying type with the

same approach to the globally known e-commerce systems and adding local payment platforms

as option and a delivery system with that of like the modern day transportation methods

already in practice in the community(ex. Ride, Pick-Pick etc…) there will be a demand and an

eventually addressed need for the system in the target population.

The major problem in the existing system is efficiency. The current conventional market

is very time consuming and tedious. Due to this the customer will be affected as it takes

physical presence at the location of the sales and requires time to go through the items, choose

and buy the product and other transportation issues.

Another problem for specifically some types of products is the issue of security. Most

products need to be securely transported to the destination as they are prone to theft. In

addition to security the system will handle transportation of the product to be delivered. The

problem of transportation is quite apparent for some products as they might naturally need a

transportation vehicle specialized for those products.

4
 Some products might be relatively expensive and require the buyer to present a bulk

amount of money in cash to the location of sales. A buyer normally will need to physically go to

the location of the seller and choose the product himself or herself. In our case the buyer will

have to just scroll through the available options choose what they want and simply order saving

them time.

5
 Objective of the Project
General Objective

The objective of this project is making an online ordering and home delivery system applicable

for many types of products.

Specific Objective

The specific objectives of this project are:

- Making an easy online market application

- Enabling it to have an efficient transaction platform

- With a trusted delivery system

- And connecting various sellers to buyers and buyers to delivery personnel with their

needs

Proposed System
Our proposed system will be efficient in the following ways. First, each buyer will be

able to browse through available products, which will be presented with their details, and

specifications then after choosing product/s the user will buy the product.

Our solution provides efficient system of time management as it reduces the time

needed to go to the point of sales and the time needed to find the right product and most

6
importantly the time needed to transport the goods purchased all while the buyer doesn’t need

to go to the seller’s place.

We will connect and offer different vehicles for different products while the user will

have to only take care of the order and the payment through the method we provide. But with

our system all the security considerations will be handled in the application reducing the risk

the buyers have to take in any transaction.

7
 Feasibility Study

Economic Feasibility

Developmental cost
The basic costs of development for our system include computers and internet

connection as well as costs for communication purposes like printing paper and time spent

working on the project by the team.

Operational Cost
The operational cost of the system include the cost of the servers and storage to run the

application and other costs like backup and disaster recovery. In addition initially, the software

has the cost of setting up, configuring and testing so it can be used in production. Additionally,

there will be training costs for training personnel for the use of the application.

Technical Feasibility

The technical feasibility of the application is apparent because of the following reasons.

According to a study made by Ethio Telecom in 2017, the number of smart phone users in

Ethiopia is about 5 % of the total number of mobile subscribers which were believed to be 53

million; the number sums up to about 2.65 million people with an annual increase rate of 11%.

Although this number seems low for the entire population’s accessibility to internet and smart

8
phones; but, since most of these people are believed to live in urban areas and are continually

getting involved in modern technology, introducing such an application would be feasible.

In addition most businesses are on the verge of expanding their online presence for

accessibility and marketing initiatives. These companies will be able to sell their products on our

platform easily since it is basically end-user oriented order and delivery system.

Various forms of transportation services are already available in the streets. If these

transportation service-providing personnel will get a chance to make a valuable amount of

money by delivering a product using our platform it is apparent that they will eventually choose

to.

Schedule Feasibility

Within the provided Time-Management plan in the project management, plan section

below the application will be feasibly completed and put into production.

9
 Scope
The project will deliver the online ordering and delivery system with a payment method. It

will have a mobile application as well as a web application and so will heavily rely on internet

connection. Since there is less availability of internet connection and thus less amount of

people willing to use the system outside major cities and towns in Ethiopia and to allow easier

integration and connection between stakeholders, the system will be created to be functional

in the context of Addis Ababa.

Methodology
After Careful consideration of the specifics of the SDLC models the one that we have

found to be best suited to our circumstances is Scrum agile software development model.

Scrum is an agile way to manage a project, usually software development. Agile software

development with Scrum is often perceived as a methodology; but rather than viewing Scrum

as methodology, some think of it as a framework for managing a process. In Scrum, a team is

cross functional, meaning everyone is needed to take a feature from idea to implementation.

This will not only get each one of us involved in the project and technically contribute to it but

also is adaptive to small teams and distributes responsibilities evenly.

Another advantage of Scrum is that it is designed for teams of three to nine members,

who break their work into actions that can be completed within time boxed iterations, called

sprints, no longer than one month and most commonly two weeks, then track progress and re-

10
plan in 15-minute time-boxed stand-up meetings, called daily scrums. We will have these

meetings where the team discusses on each aspects of the current status of the system and

helps us come to a common understanding.

Unlike the traditional method of waterfall model where analysis, design, development

needs to be done for every phase of the project; in scrum every phase of the project has

multiple iterations. Analysis, Design, Development and deployment needs to be done in every

iteration with potential releases every 2-4 weeks. Scrum prefers having smaller teams, between

2 to 8 team members with high coordination and collaboration, which suits best to our case

too.

Most importantly, Scrum is adaptive to changes. The cost for a change is lower as the

scope is defined for smaller release timelines. It focuses on implementation of the most

valuable features first. Reduces the risk of having unusable/deprecated features built in the

application.

Finally, Scrum suits more for the fast-paced development environment or continuous

production industry where we will be flexibly tolerant to changes in deadlines making efficient

time management.

11
 In Scrum, requirements go in user stories. There is generally no single requirements

document at all, nor any overall project report similar to what you describe. A user story will

describe the requirement at the highest level with a single feature with a regularized format.

"As a $X I want to $Y so I can $Z". Since our solution is not bound to known specific set of

stakeholders that we need to question for preparing requirements that fit into this story, we

will oversee the currently existing system ourselves and prepare the user stories for

implementation, which will most likely be the product of our first sprint.

In addition to those functional requirements that will mostly be addressed in the user

stories, we have considered that we will have to provide a SLA(Service Level Agreement) to the

user that details the most pressing matters of the application like the non-functional

requirement of availability. Another most important design aspect of our system will be

security. The application will be having secure mobile payment methods and also users privacy

should be of paramount importance. Thirdly, the users are expected to rely on the application

to pursue their businesses and so the reliability of the system will have to be ensured. Other

things to consider are the extensibility of the system as more and more features are added,

efficiency of the application in performing time, and resource hungry processes, and the fault-

tolerance of the system in case of unexpected behaviors.

There are various implementation approaches to our solution. We have reviewed some

of those payment APIs methods offered and so we will be using third party APIs for payment

12
handling. We will have both mobile and web applications for our system. For the Mobile apps

we are planning to implement for both IOS and android devices using tools and frameworks like

Flutter. For the we app we will use javascript frameworks like view.js and other packages from

package managers which we will have to use for purposes of efficiency and reusability than

making a ground-up solution for each low level code we will have to write.

With regards to testing, we will have unit and integration tests to insure that all

components of the system are working as expected alone and together. In addition, since we

are using scrum methodology which will require us to iterate and develop the system in an agile

manner where continious changes are being applied to it, we will have regression tests to

insure that the system behaves as expected after major changes to it.

13
 Project Management plan
1.9.1. Time Management plan
Figure SEQ Figure \* ARABIC 1

ID Task Name Start Finish Duration Complete

1 Brainstorming Ideas Mar 23 Mar 31 1 week 100%

2 Presentation and Title Approval Apr 1 Apr 5 4 days 100%

3 Proposal Development Apr 7 Apr 12 1 week 100%

4 Requirement Elicitation Apr 13 Apr 21 1 week, 1 day 0%

5 Data Collection Apr 22 Apr 30 1 week 0%

6 Design May 1 May 14 2 weeks 0%

7 Implementation Oct 1 Oct 31 4 weeks 0%

8 Testing Nov 1 Nov 11 1 week, 4 days 0%

9 Finalizing Project Nov 11 Nov 15 4 days 0%

14
 Quality Management Plan

One of the potential risks associated to our projects quality is the technical risk. Due to

the incrementally changing requirements of the system our technical performance quality will

be at stake at times and that is why we should have set forth a regression testing plan as

defined above in the methodology section. Another potential risk would be schedule risks, since

we have a scrum based team oriented approach to tasks assignment and implementation if one

of some mutually required tasks are not done in the expected timeframe the integration of

those systems would have to be delayed which will have an effect on the entire schedule.

15
 Communication Management Plan

Figure 2
Type of Method / Frequency/ Information Participants
Communication Tool Schedule Responsibles

Internal Communication:

Project Meetings Personal Weekly and Project status, problems, Project Mg

meetings on event risks, changed Project Team
requirements

Sharing of project Shared When All project documentation Project Mgr(s)

data Project available and reports Project Team Members
Server

Milestone Personal Before Project status (progess) Project Mg

Meetings Physical milestones Sub-project Mgr
meetings

Final Project Personal Wrap-up Project Mg

Meeting meetings Project Team
Experiences

External Communication and Reporting:

Project Report Excel sheet Monthly Project status Project Manage

- progress Sub-Project Managers
- forecast
- risks

SteCo Meetings Personal Monthly Project Manager, SteCo

meetings

16
2 Literature Review
2.1 Introduction

By definition, ecommerce or electronic commerce, is the buying and selling of products

or services via the Internet. The history of ecommerce started 40 years ago and, to this day,
continues to grow with new technologies, innovations, and thousands of businesses entering
the online market each year. Online shopping was invented and pioneered in 1979 by Michael
Aldrich in the United Kingdom. He connected a modified domestic television via a telephone
line to a real-time multi-user transaction-processing computer. The system was marketed
beginning in 1980 and offered mainly business-to-business systems that were sold in the UK,
Ireland, and Spain. His history of ecommerce is closely intertwined with the history of the
internet. Online shopping only became possible when the internet was opened to the public in
1991. Amazon was one of the first ecommerce sites in the world to start selling products online
and thousands of businesses have followed since.

2.2 Reviewed System

Amazon is a Fortune 500 e-commerce company based in Seattle, Wash. It has the
distinction of being one of the first large companies to sell goods over the Internet. In 1994,  Jeff
Bezos founded Amazon. Amazon started out as an online bookstore and then quickly diversified
by adding other items, including DVDs, music, video games, electronics, and clothing. It has
Over 240 million Amazon customers worldwide. As of early 2019, Amazon had nearly
647,000 employees worldwide. It is known for its technical innovations and boasts that
its engineers handle complex challenges in large-scale computing. Software development
engineers, technical program managers, test engineers and user interface experts work in small
teams throughout the company to build an e-commerce platform that's used by customers,
sellers, merchants and external developers.

17
Drawbacks

Fulfillment by Amazon (FBA) is an e-commerce service in which third-party vendors store

their products in Amazon’s fulfillment centers and the e-commerce giant picks, sorts, packs,
ships, tracks and handles returns and refunds for these products. In addition to accounting
for a huge portion of Amazon’s revenue, FBA enables Amazon to offer other vendors’
products alongside its own.

FBA gives smaller vendors access to Amazon’s web-to-warehouse picking and sorting
system and other logistics services, freeing the vendor to focus more on other aspects of
their business. Amazon charges merchants for storage space and a fee for orders it fulfills.
Shipping costs and 24/7 customer service are included in vendor fees.

Cost

FBA is not free. The seller must pay to keep the service going. The initial setup costs are
inexpensive, the rates better than what the seller can negotiate, however, as the contract
progresses the seller might have to spend well. Now, this might be disadvantage for the
seller’s business depending upon the type, value, and volume of products you sell.

Control

The seller give up a lot of control of his inventory when he send it to Amazon. This is
because; Amazon ships and packs seller’s products the way they want.

Fungible Item

18
These are the items those are identical and can be replaced with each other. For example, if
on Amazon two different sellers (S1 and S2) offer the same item but have stored it in
different locations (L1 and L2); FBA will ship the item closet to the customer irrespective of
the seller the item was ordered from or if that seller has inventory at that location. So,
Amazon might ship a product from Location L2 (where inventory from Seller S2 is stored)
when a product is ordered from Seller S1 (while his inventory is stored at Location L2). For
the simple reason that the customer is closer to warehouse L2, Amazon will pick and ship
the item from there.

Since products can be of different quality, this can lead to negative reviews for a Seller;
because the customer might have selected a seller for a particular reason. In a few cases,
damaged or counterfeit items were shipped. Although the seller was not at fault, they had
to face rather harsh consequences.

Labeling

Amazon mandates its sellers to label every product (where fulfillment is done by Amazon)
with a unique product identifier that has its own barcode. Although a banal task, this would
take a considerable amount of time and money. You would have to buy labeling stickers,
bags & boxes and a barcode scanner just to pack and ship your items to Amazon. If the
labels are not visible or properly attached then Amazon might even return all items, making
it even more difficult to profit.

Competition, Branding and Costumer Loyalty

You have to face the fact that Amazon itself would be your prime competitor among the
plethora of other similar sellers like you. Moreover, there are not many branding options
available on Amazon; the only things you can control being the product photos and
description (if you are selling only via Amazon). Everything else is Amazon-branded and
customers rarely get to see the end vendor. Hence, their loyalty is associated with Amazon
and not your brand.

19
Lost Marketing Opportunities

Amazon does not let sellers capture buyer’s email addresses. This deprives you of
opportunities to promote your brand, up-sell and cross-sell products, launch new products,
and more through email campaigns.

Payments

Amazon settles payment with sellers once every 14 days; until that time, the money is held
in an escrow account to cover the cost of possible returns. This means that you will not be
paid for nearly two weeks, which can have an impact on your payment cycle.

Tax Compliance

Amazon has many warehouses. More often than not, sellers are not notified as to where
their product is stored. With many states in the US having different policies towards items
stored, sellers are unsure about the sales tax compliance.

Using third-party fulfillment centers limits your control over inventory, although it is your
item to sell. In addition, you will not completely know the details of the transaction.

Alibaba Group was established in 1999 by 18 people led by Jack Ma, a former English
teacher from Hangzhou, China. From the outset, the company’s founders shared a belief
that the Internet would level the playing field by enabling small enterprises to leverage
innovation and technology to grow and compete more effectively in the domestic and
global economies. Since launching its first website, helping small Chinese exporters,
manufacturers and entrepreneurs to sell internationally, Alibaba Group has grown into a
global leader in online and mobile commerce. Today the company and its related
20
companies operate leading wholesale and retail online marketplaces as well as businesses
in cloud computing, digital media and entertainment, innovation initiatives and others.

Drawbacks
Regulatory Problems

Investors will not own shares directly in Alibaba due to Chinese laws forbidding foreigners
from owning Chinese Internet companies. Instead, they will invest in a Cayman Islands
holding company, known as Alibaba Group Holding, which has contractual rights to profits
from the Chinese businesses.

Government interference
Accounting oversight may not be easy. The US entity established by Congress to oversee
public company audits, known as the Public Company Accounting Oversight Board, cannot
conduct inspections without approval of the Chinese government.
eBay is an American multinational e-commerce corporation based in San Jose,
California that facilitates consumer to consumer and business to business sales through its
website. eBay was founded by Pierre Omidyar in the autumn of 1995, and became a
notable success story of the dot-com bubble. eBay is a multibillion-dollar business with
operations in about 30 countries, as of 2011. The company manages the eBay website,
an online auction and shopping website in which people and businesses buy and sell a wide
variety of goods and services worldwide. The website is free to use for buyers, but sellers
are charged fees for listing items after a limited number of free listings, and again when
those items are sold. eBay previously offered online money transfers as part of its services
(via PayPal which was a wholly owned subsidiary of eBay from 2002 to 2015)

Costs and Fees

The eBay fee scale varies depending on the type of item you list, selling price and whether
or not you have an eBay store. Sellers pay both an insertion fee and a final value fee. EBay
also offers upgrades to listings, such as a bold listing, a larger gallery for photos, subtitles
and a themed layout for the listing, which cost extra. These fees add up over time, taking
away from the profit. Sellers also invest time in answering questions and managing the
21
listings. When selling low-priced items that can result in low profits when you factor in the
amount of time spent on the listing. Estimating the fees before listing helps determine if
selling the item will be profitable.

Fraud and Scams

EBay has policies in place to control how the website is used, but both buyers and sellers do
face the risk of scams and fraud. Sellers might intentionally misrepresent items for sale.
Bidders might skip out on paying or try to return an item after receiving it. Both buyers and
sellers are encouraged to resolve problems directly with one another. If the other party
doesn't respond, the eBay Resolution Center is an option. The user chooses the specifics of
the issue and provides information to get help with a resolution.

Poor Customer Service

Anyone can sell on eBay, which means buyers can't be sure what type of customer service
they'll receive. The seller might be slow to respond to questions. Shipment of the item may
not be prompt, or the seller may fail to properly package the item for shipping. Reading a
seller's reviews before bidding on an auction item gives the buyer a sense of the customer
service provided by a seller. Generally, a seller with lots of transactions and mostly positive
feedback is a better option than new seller or one with several major red flags in feedback.

Difficult Customers

From the seller's end, dealing with customers is sometimes a disadvantage of eBay. Some
customers might complain about the smallest thing or be very demanding. Buyers have the
option of leaving negative feedback for sellers, which can hurt credibility. Sellers can protect
themselves by listing items accurately and explaining policies upfront. EBay requires sellers
to establish a return policy. The policy could simply be that there are no returns and items
are sold as-is. Providing top-notch customer services and providing information upfront can
eliminate some difficult customers.

22
Expensive. Fees are some of the highest (and most complicated) around and can cut into
your profits

Less flexibility. eBay policies dictate and require you to take only certain kinds of payments,
limit what keywords you can use, put only certain text in your listings and prevent you from
cross marketing to other platforms

2.3 Summary of the review

Min Letazez is an online ordering and delivery System that is expected to be working in
web as well as smartphones and intended to connect and communicate buyers and sellers
and even delivery personnel on the network through our System creating an online market
community in Addis Ababa.

The major problem in the existing system is efficiency. The current conventional market is
very time consuming and tedious. Due to this the customer will be affected as it takes
physical presence at the location of the sales and requires time to go through the items,
choose and buy the product and other transportation issues.

Another problem for specifically some types of products is the issue of security. Most
products need to be securely transported to the destination, as they are prone to theft. In
addition to security, the system will handle transportation of the product to be delivered.
The problem of transportation is quite apparent for some products as they might naturally
need a transportation vehicle specialized for those products.

Some products might be relatively expensive and require the buyer to present a bulk
amount of money in cash to the location of sales. A buyer normally will need to physically
go to the location of the seller and choose the product himself or herself. In our case the
buyer will have to just scroll through the available options choose what they want and
simply order saving them time.

23
3. System Requirements Specification
Introduction
By definition, ecommerce or electronic commerce, is the buying and selling of products
or services via the Internet. The history of ecommerce started 40 years ago and, to this day,
continues to grow with new technologies, innovations, and thousands of businesses
entering the online market each year. Online shopping was invented and pioneered in 1979
by Michael Aldrich in the United Kingdom. He connected a modified domestic television via
a telephone line to a real-time multi-user transaction-processing computer. The system was
marketed beginning in 1980 and offered mainly business-to-business systems that were
sold in the UK, Ireland, and Spain. His history of ecommerce is closely intertwined with the
history of the internet. Online shopping only became possible when the internet was
opened to the public in 1991. Amazon was one of the first ecommerce sites in the world to
start selling products online and thousands of businesses have followed since.

Types of E-Commerce Models

Electronic commerce can be classified into four main categories. The basis for this
simple classification is the parties that are involved in the transactions. So the four basic
electronic commerce models are as follows,

● Business to Business

24
 This is Business to Business transactions. Here the companies are doing business with
each other. The final consumer is not involved. So the online transactions only involve the
manufacturers, wholesalers, retailers etc.

● Business to Consumer

Business to Consumer. Here the company will sell their goods and/or services directly to
the consumer. The consumer can browse their websites and look at products, pictures, read
reviews. Then they place their order and the company ships the goods directly to them.
Popular examples are Amazon, Flipkart, Jabong etc.

● Consumer to Consumer

Consumer to consumer, where the consumers are in direct contact with each other. No
company is involved. It helps people sell their personal goods and assets directly to an
interested party. Usually, goods traded are cars, bikes, electronics etc. OLX, Quikr etc follow
this model.

● Consumer to Business

This is the reverse of B2C, it is a consumer to business. So the consumer provides a good
or some service to the company. Say for example an IT freelancer who demos and sells his
software to a company. This would be a C2B transaction.

25
The conventional method of market transactions requires the buyer physically approaching
the seller, identifying the product and dealing with the seller and finally buying the product
and transporting it to their destination themselves. In this process there are many efficient
solutions possible to make the transaction flexible, and less time consuming while assuring
trust and reducing cost as much as possible. The user doesn’t need to transport themselves
to the sellers locale, the user doesn’t need to be there to check the item themselves as they
will find the detailed specifications of the product on our System, the user can perform all
transactions online through our System, the user will get a trusted delivery personnel
through our System that can deliver them their products with security.

Purpose
The purpose of this document is to provide a full description of what our system's
requirements are; depicting what the reader should expect and create a general
understanding between the different stakeholders involved in this project. This document
provides a basis of what our system is expected to be when it is fully implemented that can
be used for checking up if all the requirements have been attained. It describes “ Min
Letazez” (An online ordering and delivery System) which is an E-commerce application
followed by a delivery system.

The developers, our supervisor (Advisor), use this document and all the stakeholders
involved in making a decision about the System or that might affect the System. While the
first part of this document is a generalization of the System, the second part is intended to
give a general non-technical description of the system to any interested stakeholders and
the third part is a detailed requirement specification intended to be used by the designers
and developers of the system. In a nutshell, this document is intended to guide designers in
making the system, while providing all the required information and description of the
functionalities for any interested party.

26
 General Description
Product Perspective

Amazon is a Fortune 500 e-commerce company based in Seattle, Wash. It has the
distinction of being one of the first large companies to sell goods over the Internet. In
1994, Jeff Bezos founded Amazon. Amazon started out as an online bookstore and then
quickly diversified by adding other items, including DVDs, music, video games, electronics,
and clothing. It has Over 240 million Amazon customers worldwide. As of early 2019,
Amazon had nearly 647,000 employees worldwide. It is known for its technical innovations
and boasts that its engineers handle complex challenges in large-scale computing. Software
development engineers, technical program managers, test engineers and user interface
experts work in small teams throughout the company to build an e-commerce platform that
is used by customers, sellers, merchants and external developers.

Drawbacks

Fulfillment by Amazon (FBA) is an e-commerce service in which third-party vendors store

their products in Amazon’s fulfillment centers and the e-commerce giant picks, sorts, packs,
ships, tracks and handles returns and refunds for these products. In addition to accounting
for a huge portion of Amazon’s revenue, FBA enables Amazon to offer other vendors’
products alongside its own.

FBA gives smaller vendors access to Amazon’s web-to-warehouse picking and sorting
system and other logistics services, freeing the vendor to focus more on other aspects of
their business. Amazon charges merchants for storage space and a fee for orders it fulfills.
Shipping costs and 24/7 customer service are included in vendor fees.

Cost

27
FBA is not free. The seller must pay to keep the service going. The initial setup costs are
inexpensive, the rates better than what the seller can negotiate, however, as the contract
progresses the seller might have to spend well. Now, this might be disadvantage for the
seller’s business depending upon the type, value, and volume of products you sell.

Control

The seller give up a lot of control of his inventory when he send it to Amazon. This is
because; Amazon ships and packs seller’s products the way they want.

Fungible Item

These are the items those are identical and can be replaced with each other. For example, if
on Amazon two different sellers (S1 and S2) offer the same item but have stored it in
different locations (L1 and L2); FBA will ship the item closet to the customer irrespective of
the seller the item was ordered from or if that seller has inventory at that location. So,
Amazon might ship a product from Location L2 (where inventory from Seller S2 is stored)
when a product is ordered from Seller S1 (while his inventory is stored at Location L2). For
the simple reason that the customer is closer to warehouse L2, Amazon will pick and ship
the item from there.

Since products can be of different quality, this can lead to negative reviews for a Seller;
because the customer might have selected a seller for a particular reason. In a few cases,
damaged or counterfeit items were shipped. Although the seller was not at fault, they had
to face rather harsh consequences.

Labeling

Amazon mandates its sellers to label every product (where fulfillment is done by Amazon)
with a unique product identifier that has its own barcode. Although a banal task, this would
take a considerable amount of time and money. You would have to buy labeling stickers,
bags & boxes and a barcode scanner just to pack and ship your items to Amazon. If the
labels are not visible or properly attached then Amazon might even return all items, making
it even more difficult to profit.

28
Competition, Branding and Costumer Loyalty

You have to face the fact that Amazon itself would be your prime competitor among the
plethora of other similar sellers like you. Moreover, there are not many branding options
available on Amazon; the only things you can control being the product photos and
description (if you are selling only via Amazon). Everything else is Amazon-branded and
customers rarely get to see the end vendor. Hence, their loyalty is associated with Amazon
and not your brand.

Lost Marketing Opportunities

Amazon does not let sellers capture buyer’s email addresses. This deprives you of
opportunities to promote your brand, up-sell and cross-sell products, launch new products,
and more through email campaigns.

Payments

Amazon settles payment with sellers once every 14 days; until that time, the money is held
in an escrow account to cover the cost of possible returns. This means that you will not be
paid for nearly two weeks, which can have an impact on your payment cycle.

Tax Compliance

29
Amazon has many warehouses. More often than not, sellers are not notified as to where
their product is stored. With many states in the US having different policies towards items
stored, sellers are unsure about the sales tax compliance.

Using third-party fulfillment centers limits your control over inventory, although it is your
item to sell. In addition, you will not completely know the details of the transaction.

Alibaba Group was established in 1999 by 18 people led by Jack Ma, a former English
teacher from Hangzhou, China. From the outset, the company’s founders shared a belief
that the Internet would level the playing field by enabling small enterprises to leverage
innovation and technology to grow and compete more effectively in the domestic and
global economies. Since launching its first website, helping small Chinese exporters,
manufacturers and entrepreneurs to sell internationally, Alibaba Group has grown into a
global leader in online and mobile commerce. Today the company and its related
companies operate leading wholesale and retail online marketplaces as well as businesses
in cloud computing, digital media and entertainment, innovation initiatives and others.

Drawbacks
Regulatory Problems

Investors will not own shares directly in Alibaba due to Chinese laws forbidding foreigners
from owning Chinese Internet companies. Instead, they will invest in a Cayman Islands
holding company, known as Alibaba Group Holding, which has contractual rights to profits
from the Chinese businesses.

Government interference
Accounting oversight may not be easy. The US entity established by Congress to oversee
public company audits, known as the Public Company Accounting Oversight Board, cannot
conduct inspections without approval of the Chinese government.
eBay is an American multinational e-commerce corporation based in San Jose,
California that facilitates consumer to consumer and business-to-business sales through its
website. eBay was founded by Pierre Omidyar in the autumn of 1995, and became a
notable success story of the dot-com bubble. eBay is a multibillion-dollar business with
operations in about 30 countries, as of 2011. The company manages the eBay website,

30
an online auction and shopping website in which people and businesses buy and sell a wide
variety of goods and services worldwide. The website is free to use for buyers, but sellers
are charged fees for listing items after a limited number of free listings, and again when
those items are sold. eBay previously offered online money transfers as part of its services
(via PayPal which was a wholly owned subsidiary of eBay from 2002 to 2015)

Costs and Fees

The eBay fee scale varies depending on the type of item you list, selling price and whether
or not you have an eBay store. Sellers pay both an insertion fee and a final value fee. EBay
also offers upgrades to listings, such as a bold listing, a larger gallery for photos, subtitles
and a themed layout for the listing, which cost extra. These fees add up over time, taking
away from the profit. Sellers also invest time in answering questions and managing the
listings. When selling low-priced items, that can result in low profits when you factor in the
amount of time spent on the listing. Estimating the fees before listing helps determine if
selling the item will be profitable.

Fraud and Scams

EBay has policies in place to control how the website is used, but both buyers and sellers do
face the risk of scams and fraud. Sellers might intentionally misrepresent items for sale.
Bidders might skip out on paying or try to return an item after receiving it. Both buyers and
sellers are encouraged to resolve problems directly with one another. If the other party
doesn't respond, the eBay Resolution Center is an option. The user chooses the specifics of
the issue and provides information to get help with a resolution.

Poor Customer Service

Anyone can sell on eBay, which means buyers can't be sure what type of customer service
they'll receive. The seller might be slow to respond to questions. Shipment of the item may
not be prompt, or the seller may fail to properly package the item for shipping. Reading a
seller's reviews before bidding on an auction item gives the buyer a sense of the customer

31
service provided by a seller. Generally, a seller with lots of transactions and mostly positive
feedback is a better option than new seller or one with several major red flags in feedback.

Difficult Customers

From the seller's end, dealing with customers is sometimes a disadvantage of eBay. Some
customers might complain about the smallest thing or be very demanding. Buyers have the
option of leaving negative feedback for sellers, which can hurt credibility. Sellers can protect
themselves by listing items accurately and explaining policies upfront. EBay requires sellers
to establish a return policy. The policy could simply be that there are no returns and items
are sold as-is. Providing top-notch customer services and providing information upfront can
eliminate some difficult customers.

Expensive. Fees are some of the highest (and most complicated) around and can cut into
your profits

Less flexibility. eBay policies dictate and require you to take only certain kinds of payments,
limit what keywords you can use, put only certain text in your listings and prevent you from
cross marketing to other platforms

Min Letazez is an online ordering and delivery System that is expected to be working in web
as well as smartphones and intended to connect and communicate buyers and sellers and
even delivery personnel on the network through our System creating an online market
community in Addis Ababa.

The major problem in the existing system is efficiency. The current conventional market is
very time consuming and tedious. Due to this the customer will be affected as it takes
physical presence at the location of the sales and requires time to go through the items,
choose and buy the product and other transportation issues.

32
Another problem for specifically some types of products is the issue of security. Most
products need to be securely transported to the destination as they are prone to theft. In
addition to security the system will handle transportation of the product to be delivered.
The problem of transportation is quite apparent for some products as they might naturally
need a transportation vehicle specialized for those products.

Some products might be relatively expensive and require the buyer to present a bulk
amount of money in cash to the location of sales. A buyer normally will need to physically
go to the location of the seller and choose the product themselves. In our case the buyer
will have to just scroll through the available options choose what they want and simply
order saving them time.

Product Functions
Min Letazez is an online marketplace which processes business to consumer to delivery
sales and communication and creates an online market community for Addis. The basic
functionalities of Min Letazez can be summarized as follows.

The System will allow users to directly buy goods from a seller over the internet using a
web browser or a smart phone application. Buyers can find the product that interests them
by viewing and searching among the list vendors on the System and once they do they can
check the details of that product and buy it online.

The System will allow photos or images of the good or product to be sold to be visible
for the user with a list of the details of the specification, features and prices for that
specific product. Using the System users will be able to search all the available variations of
the same product with regards to price, provider, or any other specifications. The users can
also follow and get notified of the vendor they are interested in about products they offer.

Just like a conventional store offers a physical cart for the consumers to accumulate
multiple items in it the same goes with our online shopping cart system that will allow
users to accumulate multiple items and to adjust quantities. The user can finally checkout
where they will get a payment and delivery information.

33
 In our System we will integrate a payment system that will(hopefully) allow purchases
through any of the major banks in Addis. Using this external integrated payment system, a
user will be able to cash out and pay and purchase the products they selected or put on cart
and order delivery. All the transaction is expected to be performed online including the
delivery and service charge in addition to the product/s’ price.

The other basic functionality of the system is allowing the sellers to to keep a list of their
products in the online store provided by our System and to advertise, specify and sell it to
the buyers. Sellers will control their own shops and will sell their products to the consumers
using our system as a channel.

Once the user has completed a purchase and hence ordered a delivery the system will
provide the means of delivery to the buyer based on the type of product they bought. For
physical products, the product is transported to a buyer designated address if they require
so or taken to their current location as they prefer. The System’s delivery personnel will be
contacted with all the details necessary to perform the delivery and the item will be
delivered to the user as such.

For digital products like software, books and the like the user will be able to download
the item once they complete the transaction online. The user will be able to access these
products after sales only and no delivery will be needed naturally for such kinds of products.

The other basic and important functionality of the System will the ability of a user to
track the orders using their phone at any time. Users will be able to know the current
location of the vehicle transporting their order and will be able to trace the order. Until the
delivery personnel picks up the purchased item, the item will be assumed to be staying at
the seller’s locale, and after the delivery personnel transacts it the person will be traced
through the device they use to access the System till the reach the user.

User Characteristics
While the System is expected to be used by anyone in the city there might be certain
expectations of the user’s background. The users of Min Letazez are expected to have the
following basic knowledge to successfully and correctly utilize the System:
- Basic understanding and use of computers
- Internet Access and the use of applications
- Search
- Web browsing or usage of Smartphones
- Basic social networking experience (signing in and out, managing profile, messages
etc…)
- Should have a banking information

34
Assumptions and Dependencies
The System that this document describes is an e-commerce System that will allow
internet transactions for users with an external payment interface. The external payment
system that we utilize is Yenepay, an online payment platform.

35
Specific Requirements
External Interface Requirements
User Interfaces

The user interfaces of such an e-commerce System are sometimes overwhelming for
users to use. Therefore, while we expect our system to have a user interface that is simple
and understandable the information that it has to offer must be placed in the same
interface where it is needed meaning a bit of organization is an important aspect. To this
end, we will have a user interface requirement as follows.

Each functionality will have a separate user interface that serves its own purpose and the
user will be able to get all the information needed for that specific functional requirement
in the same interface. This will allow users to focus on one specific aspect or functionality of
the system while getting all information required in the same.

In addition, all interfaces must have a clear navigation menu that allows users to transfer
from one function to another easily. The users of the system will expect all the information
of their usage to be recorded and shown to them while keeping it private and secure. As
such a user can, at any point, pause a particular task and resume whenever and wherever
they can and from whichever device they like to resume from.

The first screen the user will be looking at is always the welcome page which will allow the
user to login or register. Once the user logs in the page will go to the user’s homepage
which will include a list of recommendations, a search function and a set of navigation items
to the different functional areas of the system. The user can view the details of the items
including the specifications add those items to cart and checkout and get redirected to

36
payment handler page. The user can also rate products, give a review and rate specific
vendors based on the products they offer. The user can also be able to contact those
vendors and delivery personnel assigned to them. The system will have a separate interface
where the user will track the specific products they have ordered as they are being travelled
to the user by a delivery personnel. The user can ask for refunds based on reasonable
circumstances which will be defined below.

Since the application will be designed to be used from a web browser or from smart-
phones, by using the accessibility features of a browser it is assumed that the user with
disability will be able to easily use the System and such considerations shall be taken while
designing the product.

37
UI 1: Home Page (Signed In)

38
UI 2: Homepage (mobile)

UI 3: Checkout

39
40
UI 4: Track Order

41
UI 5: Search

Hardware Interfaces

The System supports any device with a web browser and an internet connection. The
users can access it from their device of they have a working internet connection on a device
that has one of the common web browsers; Mozilla firefox, chrome, opera, safari and the
like. In addition the system will be able to be accessed from a smartphone via the
applications for that device. All interactions between hardware such as tracking of one
through the other (i.e. for order tracking purposes) shall be conducted through the
respective operating system capabilities of the devices involved and not the hardware
themselves.

42
Software Interfaces

Yenepay platform will be used for payment within the system including purchases. This
will be the only software interface with an external system.

Communications Interfaces

The system will use the internet and is dependent on it for conducting the transactions
internally, and providing a communication across users of it reliably. The system thus will
directly interact with the internet and will use the standard protocols to communicate with
the server and through the server to each party involved.

Functional Requirements
3.2.1. Register

3.2.1.1 Introduction The System will require the users to register to use the application
properly. In order to use the application and buy products the user
needs to provide basic information and hold an account on the System
which can then be used to sign in from a different device at anytime. It
is assumed that most users have a mobile phone number and so one
can get authenticated by using their mobile phone number. Optionally
we will use Email addresses, but this is optional because some users
might not already have an email address. For sellers and delivery
personnel, while they will have and need a username and password

43
 they will have to get these credentials from the administrator after
they have applied for it and have been legally verified. The delivery
personnel and the sellers are going to be validated and registered by
the administrator.

3.2.1.2 Inputs The inputs of the registration process will vary from user to user. For
buyers the following inputs are required from the user upon
registration.

● Full Legal Name

● Mobile Number
● Email Address(optional)
● Payment information
● Username
● Password

For sellers and delivery personals the following inputs are required
from the user upon registration.

● Company Legal Name,

● Location (Address),
● Phone Number (Mobile number),
● Email(optional),
● Payment Information,
● Username(assigned),
● Password (assigned, can be changed later)

3.2.1.3 Processing The system will verify the phone number and/or the email address of
the user, check if the password is valid and whether or not the
username is already taken. The system will also verify the payment
information provided by the user. So, at this step the processing is
basically validation of the user’s inputs

3.2.1.4 Outputs The system will save the user information and create a profile for the
user. The user will be able to sign in from a different device at anytime

44
 by providing the username and password credentials.

3.2.1.5 Error Handling If any of the users provided information appears to be invalid, wrong or
taken (in the case of a username) the system will respond as required
respectively as follows. For usernames the system will respond that the
username is taken and that the user shall attempt with another
username, at this stage the system could also provide suggestions to
the username for this user based on their legal name provided, the
same is true for mobile numbers. For passwords the system shall
specifically tell the users what kind of passwords are allowed and which
aren’t. For the financial information the user’s information will be
crosschecked with the respective payment transaction handler and
handled by itself, the system will receive the error information from
the API and will respond to the user the appropriate error message. For
the optional Email address, the system will send and ask verification for
the user but this step might not be mandatory as stated above and if
there’s no verification the system shall mark the email address
unverified and save. If one of the required fields are not provided the
system shall respond the appropriate message asking the user to fill in
the queries.

3.2.2 Sign In and sign Out

3.2.2.1 Introduction As per the username and password provided during registration a

45
 registered user shall be able to sign in providing the correct credentials
on any device.

The user can sign out of the System at any time from any device
they have signed in.

3.2.2.2 Inputs ● The user is supposed to be signed in.

● username and password given at time of registration.

3.2.2.3 Processing ● The system will check if the username exists and check the
password is correct, and sign in the user and log that the user
has signed in at that specific time and with the appropriate
device or IP information in the user’s activity data.
● The system will sign out the user.
3.2.2.4 Outputs ● The user will be signed in and redirected to their respective
home page according to their role (seller, buyer, or delivery
personnel).
● The user will be signed out.
3.2.2.5 Error Handling If any provided information is wrong the system shall respond
accordingly.

3.2.3 View Products

3.2.3.1 Introduction The system shall provide the users a list of products by
recommendation, by the industry, by the name of the vendor who
provides the product, by popularity of the product (most sold product)
based on reviews given to the product by users. Based on the criteria
the user chooses the list of products will be visible for buyers who use
the system.

3.2.3.2 Inputs The system will read the sellers’ available product data and the current

46
 users purchase data, the industry it belongs to, the vendor who
provided it, its popularity and reviews given to the product and provide
the appropriate preview of products in the home page of that specific
user.

3.2.3.3 Processing The system will stand idle as the user scrolls around the products and
chooses the items. As the user chooses the item the user shall be
redirected to the detailed information of that specific product and a
transaction and order pane.

3.2.3.4 Outputs The user shall be able to see a list of items recommended for them
respectively in their homepage.

3.2.3.5 Error Handling The system shall respond to the user the error.

3.2.4 View Product Details

3.2.4.1 Introduction The system shall show the user the product detail that the user is
interested in including the specification and price.

3.2.4.2 Inputs Product ID that the user chooses (clicked on), and user information will
be passed from the previous page to the current product details page.

3.2.4.3 Processing The system will stand idle as the user scrolls around the product’s
information and specification and reads. The system will redirect the
user to the “cart” if the user chooses to add the item to cart or
redirects the user to the payment page if the user chooses to buy the
product right away. (except for sellers interested in just checking the

47
 market and thus won’t be able to add to cart or buy using a seller
account).

3.2.4.4 Outputs The system reads the product ID and displays the detail information of
the product for the user.

3.2.4.5 Error Handling If any provided information is wrong the system shall respond
accordingly.

3.2.5 Manage Profile

3.2.5.1 Introduction The user shall be able to view, edit their profile in the System anytime
they want after registration.

3.2.5.2 Inputs username and password,

3.2.5.3 Processing The system will redirect the user to their respective profile and views
all their information providing a method of editing it.

3.2.5.4 Outputs The user edits their profile.

3.2.5.5 Error Handling If the user edits their confirmed phone number or email address the
system shall ask the user to reconfirm the new email address or phone
number.

48
 3.2.6 Recent Transactions

3.2.6.1 Introduction The user shall be able to view, request refund, navigate through and/or
review products pertaining to their recent transactions. As such the
user will have a recent transactions log to be visible to them when
needed.

3.2.6.2 Inputs A list of the recent transactions (not more than 50 transactions)

3.2.6.3 Processing The system will redirect the user to their recent transactions list and
stands idle transferring to the appropriate function if the user wants to
review a product, request refund and the like.

3.2.6.4 Outputs The user will be able to visit a list of their recent transactions.

3.2.6.5 Error Handling The system shall respond to the user the error.

3.2.7 Order

3.2.7.1 Introduction The user shall be able to order items that he wants to buy, visit the
pending orders they have placed and are waiting to receive from the

49
 delivery personnel.

3.2.7.2 Inputs A list of the pending orders,

3.2.7.3 Processing The system will stand idle as the user reads the information about their
pending order and transfers them to the appropriate function when if
they want to view the delivery personnel information, track their order,
or get a purchase information and the like.

3.2.7.4 Outputs The user gets a list of their pending orders.

3.2.7.5 Error Handling The system shall respond to the user the error.

3.2.8 My Reviews

3.2.8.1 Introduction The user shall be able to edit the reviews to any product or vendor they
have made in the past in the System anytime they want after
registration. As such a list of the user’s reviews on various products do
far will be visible to them when ever they deem it needed.

3.2.8.2 Inputs A list of the user’s reviews

3.2.8.3 Processing The system will stand idle as the user visits their reviews and provides a
method of editing it.

3.2.8.4 Outputs The user gets a list of their reviews and edits them when needed.

3.2.8.5 Error Handling The system shall respond to the user the error.

50
 3.2.9 Manage Cart

3.2.9.1 Introduction The user shall be able to view and manage their cart at any time. The
user can add any product to cart, increase amounts, check the price of
items in the cart remove from cart or empty the cart or checkout when
needed. The user can also check the price of current content of the cart
in total. The user could add a product to cart where all the selected
products will be put and ordered altogether when the user checks out.

3.2.9.2 Inputs Cart content information

3.2.9.3 Processing The system will redirect the user to their respective cart and views all
their information and stands idle and transfers them to the respective
function available when they deem necessary.

3.2.9.4 Outputs The user checks their cart.

3.2.9.5 Error Handling The system shall respond to the user the error.

3.2.4 Shop

3.2.1.1 Introduction The seller’s workspace will be organized as a virtual shop where they
will place their products, post their specifications, tag the amounts
available, keep a sales inventory, maintain customer’s data, edit their
profile, and access the reviews on them and their products.

51
3.2.1.2 Inputs username and password

3.2.1.3 Processing The system will redirect the seller to their respective profile and views
all their information.

3.2.1.4 Outputs The seller views their profile.

3.2.1.5 Error Handling The system shall respond to the user the error.

3.2.4 Report

3.2.1.1 Introduction Introduction

● The seller will be able to have a list of their customers who have
visited and bought their products.
● The seller shall be able to find a list of reviews made on them
and/or their products by their customers.
● The administrator shall get an information related to all the list
of users in the system, and all their public data, and their usage
and a visualization of the system’s usage and locations of those
usages.
● The seller will be able to get daily, weekly, monthly and annual
sales reports about his products
3.2.1.2 Inputs ● Inventory data
● Customers’ data on a vendor
● Reviews on the current seller
● Sales data
● User data, Transactions, Location data
3.2.1.3 Processing ● The system will redirect the seller to their respective
inventory data.
● The system generates daily, weekly, monthly and annual
sales reports
3.2.1.4 Outputs ● The seller views their inventory.
● The seller views reviews on and comments about them.
● The seller views their customers’ data.
● The seller views their sales reports.

52
3.2.1.5 Error Handling The system shall respond to the user the error.

3.2.4 Manage product

3.2.1.1 Introduction ● The seller shall be able to add a new product to their inventory.
● The seller shall be able to remove a product from their
inventory.
● The seller shall be provided with information pertaining to a
single type of product they offer, its popularity, how many
times it has been checked, its reviews and sales report on that
single type of product they offer.
● The sellers need to upload and update the information of their
products on the System. As such once registered the users can
edit or upload product information.
3.2.1.2 Inputs ● Inventory data
● Inventory data, product data, reviews, and sales data

3.2.1.3 Processing ● The system will request details and add a new product to
the inventory of the seller.
● The system will provide the user a report about the product
they offer.
● The system checks if the product is already available.
3.2.1.4 Outputs ● The seller adds a new product.
● The seller gets a report about a product they offer.
● The system updates the product information
3.2.1.5 Error Handling The system shall respond to the user the error.

3.2.4 Pending Delivery

3.2.1.1 Introduction The delivery personnel shall be able to view, and read information
about a pending order they have been assigned.

3.2.1.2 Inputs Purchase Data related to the delivery they have been assigned

53
3.2.1.3 Processing The system will provide the delivery the information about the pending
delivery like, the pick and drop locations and the seller and buyer
information.

3.2.1.4 Outputs The delivery personnel will get information related to the order they
are about to handle.

3.2.1.5 Error Handling The system shall respond to the user the error.

3.2.4 Sales

3.2.1.1 Introduction ● The buyers shall be able to request refund requests to the seller
in the system.
● The seller shall be able to view refund request from buyers.
3.2.1.2 Inputs Refund requests from customers.

3.2.1.3 Processing The system shall provide the administrator all the available refund
requests.

3.2.1.4 Outputs The admin gets a list of refund requests.

The seller gets a list of refund requests on his products.

3.2.1.5 Error Handling The system shall respond to the user the error.

3.2.5 Buy Product

54
3.2.1.1 Introduction The user will select a product and see its details and finally get
interested to buy it. At this stage the user has two options. Either the
user can directly buy and order this product only or the user can add
this product to cart where all the selected products will be put and
ordered altogether when the user wants.

3.2.1.2 Inputs Product ID, or the list of product IDs the user has ordered or added to
cart respectively are the main inputs.

3.2.1.3 Processing Once the user has ordered the product/s the user will be redirected to
the payment page where the user will check price, check details and
buy.

3.2.1.4 Outputs The user will order a product or products using the System, and this
will be logged to the user activities.

3.2.1.5 Error Handling If the user’s balance is low, or if the user’s payment information had
issues the system will respond the appropriate message to the user by
reading the message from the payment handler and responding to the
user in specific description why it has failed and what can be done to
fix the issue.

3.2.6 Assign Delivery

3.2.1.1 Introduction Once a user has bought a product and ordered delivery, the system
shall take care of the delivery in a way that is flexible, and accessible to
the user as follows.

3.2.1.2 Inputs User information, like current location, name and phone number.

List of products, and their respective shops and prices

3.2.1.3 Processing The system checks the availability of the closet delivery personnel in

55
 the area and assigns them the order.

3.2.1.4 Outputs The delivery personnel will get the user and product information. The
user’s order will be handled by the delivery personnel and the user will
be notified of who is going to deliver their product.

3.2.1.5 Error Handling If no delivery personnel is available in the area the user will be told of
the problem and asked if they are willing to wait or to pay more for an
instant delivery. The price of the delivery of the product will be directly
proportional with the availability of delivery personnel.

3.2.7 Register Sellers and Delivery Personnel

3.2.1.1 Introduction

3.2.1.2 Inputs Inputs from registration

3.2.1.3 Processing The system will verify the phone number and/or the email address of
the user, check if the password is valid and whether or not the
username is already taken. The system will also verify the payment
information provided by the user. So at this step the processing is
basically validation of the user’s inputs

3.2.1.4 Outputs The stakeholder will be registered according to their role.

3.2.1.5 Error Handling If this user already exists the system will respond the appropriate
message to the admin.

56
 3.2.8 Order Tracking

3.2.1.1 Introduction Once a user has purchased and ordered a product the user will be able
to view the current location of the product. When the delivery
personnel take the item from the store, the user will be notified and
the tracking will start until the product reaches the users location.

3.2.1.2 Inputs Delivery personnel’s status, Product ID, user ID, delivery personnel’s ID,
seller’s ID, transaction ID

3.2.1.3 Processing The system will wait for the product to be taken by the delivery
personnel and will track the movements of the delivery personnel until
the product is taken from the store, and from there the system notifies
the user and tracks back the product to the location of the user until a
confirmation has been made by the user.

3.2.1.4 Outputs The current location and status of the ordered product will be
displayed to the user.

3.2.1.5 Error Handling The user will be given a contact detail of the seller, delivery personnel
in case of delays or emergencies. The user will also be able to request
refund if the item isn’t delivered due to the system’s error or
emergencies as stated above.

3.2.9 Manage Activities

3.2.1.1 Introduction The user activities shall be held privately but visible to the user
themselves when needed. This will help the user find information of a
previously purchased product, help the system to make
recommendations for the user, help the user get a review for

57
 purchased products, or help the seller in customer relations. Sellers will
be allowed to check the history of who has bought them in the same
manner a buyer checks where they have bought from.

3.2.1.2 Inputs Purchase orders, Current Cart contents

3.2.1.3 Processing The system will record each transactions the user has made in the user
activities log. In addition, the user activity log will contain the contents
of the “cart” for the current user at any time. The system will read
these data and display to the user when needed

3.2.1.4 Outputs The user gets a detailed description the transactions and interest they
have had so far.

3.2.1.5 Error Handling The system shall respond to the user the error.

3.2.10 Review Product

3.2.1.1 Introduction The users shall be able to rate any product and write a review on it
once they have purchased it.

3.2.1.2 Inputs The rating (Stars or levels), the comment, the user info, the user
activity, the product to be rated

3.2.1.3 Processing The system checks if the user has purchased the item and registers the
review for the product.

3.2.1.4 Outputs The product gets a review.

3.2.1.5 Error Handling The system shall respond to the user the error.

58
 3.2.11 Search

3.2.1.1 Introduction The system contains various products and the user gets the
recommended products list, and a category but since the user might
want to buy a new product the search capability is added.

3.2.1.2 Inputs The user inputs the search query.

3.2.1.3 Processing The system queries the database for any matching result.

3.2.1.4 Outputs The user gets a list of the matching results

3.2.1.5 Error Handling If no entries match the user’s query the system responds the
appropriate error message to the user.

59
Use Cases
Use case Diagram

Use Case #1

Use case Name UC01: Registration

Goal Registering the user/buyer

60
 Primary Actors Buyer

Preconditions Buyer should be on the register screen

Main Success Scenario S1. The user inputs the required information

S2. The user hits the register button

S3. The system will verify and validate the user

S4. The system will respond the success

S5. The system redirects the user to home screen

Extensions S2a. The required fields are empty

S5a1. The system will display the error message.

S3a. The user’s input information wasn’t valid

S3a1. The system will display the error message.

Use Case #2

Use case Name UC02: Buying a product/s

Goal Buying a product/s the user seletced

Primary Actors Buyer

Preconditions Buyer should be registered and logged in

61
Main Success Scenario S1. The user selects the product/s

S2. The user hits the buy button

S3. The system will redirect the user to

payment page

S4. The system shows the details of the order

S5. The user confirms the transaction

Extensions S5a. The user doesn’t have the required

balance.

S5a1. The system will display the user that

the balance is insufficient.

S5a2. The system will get the user back to

the detail screen.

Use Case #3

Use case Name UC03: Search a product or vendor

Goal check a desired product or vendor on the

System

Primary Actors Buyer or seller

Preconditions Buyer or seller are at the homepage or anypage

on the System

62
Main Success Scenario S1. The user enters the name of the product

S2. The user hits the search button

S3. The system will search the product

S4. The system shows a list of results S5. The

user scrolls around and chooses the product or
vendor they want

Use Case #4

Use case Name UC04: Add Product to cart

Goal Adding a product to the cart

Primary Actors Buyer

Preconditions Buyer should be registered and logged in

Main Success Scenario S1. The user selects the product/s

S2. The user presses “add to cart” button

S3. The system adds the product to cart

Extensions S2a. The product is already in cart

S2a1. The system will add the amount of that

product in cart to the amount the user just
added.

S5a2. The system will notify the user of the

addition and the presence of older addition of

63
 the product in cart.

Use Case #5

Use case Name UC05: Edit My profile

Goal Editing a user’s profile

Primary Actors Buyer

Preconditions Buyer should be registered and logged in

Main Success Scenario S1. The user selects “my profile”

S2. The user hits the edit button

S3. The system will redirect the user to edit

page

S4. The user edits their profile

S5. The user hits the save button

Extensions S5a. The user has entered a wrong

username/password or payment information.

S5a1. The system will display the error and

ask the user to review their edit.

S5a2. The system will get the user back to

the edit screen.

Use Case #6

Use case Name UC06: Track an Order

64
Goal Tracking a placed order

Primary Actors Buyer

Preconditions Buyer should be registered and logged in and

has a pending order

Main Success Scenario S1. The user selects “My Actiities “

S2. The user selects “Pending orders”

S3. The system will redirect the user to pending

orders page

S4. The user selects the order the want to track

S5. The system tracks and views the current

location of the order.

Use Case #7

Use case Name UC07: Review a product

Goal Reviewing a product

Primary Actors Buyer

Preconditions Buyer should be registered and logged in

65
Main Success Scenario S1. The user selects the product/s

S2. The user hits the review button

S3. The system will redirect the user to review

page

S5. The user reviews the product

Extensions S3a. The user already has reviewed the

product.

S5a1. The system will allow the user edit the

review.

S5a2. The user will edit the review.

Use Case #8

Use case Name UC08: Empty cart

Goal Empty the Cart of the user

Primary Actors Buyer

Preconditions Buyer should be registered and logged in

Main Success Scenario S1. The user selects the “cart”

S2. The user hits the empty button

S3. The system will empty the cart

3.3.2 Use Case #9

66
Use case Name UC09: Remove Item from cart

Goal To remove an item from the cart

Primary Actors Buyer

Preconditions Buyer should be registered and logged in

Main Success Scenario S1. The user selects the “cart”

S2. The user selects the item

S3. The user hits “remove item”

S4. The system requests how much amounts to

be removed.

S5. The user enters amount and hits remove.

S6. The system removes the item from cart

Use Case #10

Use case Name UC10: Checkout

Goal Checkout a cart

Primary Actors Buyer

Preconditions Buyer should be registered and logged in and

cart of the buyer should not be empty

Main Success Scenario S1. The user selects the “cart“

S2. The user hits the checkout button

S3. The system will redirect the user to

67
 checkout page.

S4. The user reads the information and

confirms checkout.

S4. The system redirects the user to the

payments page.

Non-Functional Requirements
Performance

The System is expected to be used with a huge number of people at a scale that would increase
gradually. As such the expected scale for the System’s usage will be at least 10% of the
population of the city. With this scale the data that has to be kept on device and the data that
has to be fetched for each usage has to be defined in designing to accommodate such usage. In
addition, the number of simultaneous usages at this scale will have to be smooth and work with
ease since when the System is released. As much as possible, as it is to be defined in the design,
much information will be kept both in device and on databases, and synchronized on a regular
basis to avoid traffic during usage. In a nutshell, a user shall not have to wait for the major
functions excluding transactions (since they will be routed through third-party APIs) for more
than a minute in peak hour usage time.

Reliability

The System will be required to be reliable in such a way that any user shall be able to use it
anytime needed as long as they have a working internet connection and and a compatible
device.

Availability

68
The system should be available 24 hours a day and 7 days a week. Since it is the usual
commerce tool for the users and it must be available since it is there to replace the day-to-day
tedious user market experiences.

Security

The system will make use of payment transaction methodologies and order tracking capacities
to the user and will also log user usages of the System in its database for recommendation of a
better product. As such the security and privacy of the system and its user specific information
and transactions is of paramount importance. A user’s information, transaction history, and
payment information shall be kept completely private and secure.

To make the transaction easier, safe and secure for all parties it will be better if the application
has an online payment system. We will have to integrate available external payment
methodologies into our application. E-commerce projects, companies having their own
websites for sales purposes can use our System.

Maintainability

As to be defined in the design document, the implementation of the program must be done in a
way that would allow the maintenance of the system without any problem and a sum-total of
the systems information is going to be kept in a manual designed for such purposes.

Portability

The system is expected to be accessed and used form anywhere anytime where there is an
internet connection and compatible device as listed above.

69
 Inverse Requirements
The application will not do the following functions:

An external payment handler will be integrated to the application but the application will not
perform the payment within itself.
A delivery management and an order-tracking algorithm will be implemented but the delivery
will be handled by external human entities and not technical hardware system.
Various products and services will be advertised and sold through the application but the
application gets this information from their respective sales companies or vendors and not
manually put in by the administrator.
This is a customer to sales company e-commerce System and not a user to user sales System so
will only offer transactions between users and the sales companies.
The System doesn’t have its own banking system or information and will use external third
party user information for transaction.

Design Constraints
The system and specifically the transaction interface of the system is to be designed in
accordance with other third party software and APIs to be used with integration and must be
compatible to all. This means all the inputs to, and outputs from other systems are compatible
with the output of the system and input into the interface of the system.

Logical Database Requirements

The user information like: name, address, payment information, and usage logs will be
kept inside a database. In addition, transaction logs, and product reviews, are also types of
dynamic and important information that has to be kept on database. In addition, the main data
the database has to keep is the list of products and their specifications, vendors and their
profile, delivery personnel and their profile all have to be kept in database and fetched and
used when needed accordingly. There are various data that are frequently used and expected
to be redundantly stored on users devices to decrease traffic and increase performance of the
system in general and these will be defined in the design document of the application.

70
 ER diagram

Change Management Process

The information kept in this documentation is a first draft expected to be revised after
consulting with the advisor. The documentation and all its contents are prone to change when
if the advisor requires it for the first phase of this draft. In addition, as the design document
gets developed and various design decisions gets addressed this documentation and its
contents particularly those relating to the design of the system and those that have been seen
as a starting point for the design process will be prone to reasonable change and will be

71
changes by specifying reasons as such. Finally, if any requirements are redundant or if any
regulatory procedure requires the change of those requirements, a modification of functional
requirements in this document will be expected while the functional requirements are
expected to be still addressed or their inputs or outputs or even their underlying process have
to be modified. In addition, any more requirements can be further added due to legal, business
logic related or design requirements are assessed to be needed. All additions shall be provided
to and approved by the advisor to create a next draft or a final document of this SRS document.

5 System Design Specification

5.1Introduction
5.1 Purpose
The purpose of System Design document is to translate the business requirements and business
processes into a technical design that will be used to develop the application.

5.2 General Overview

The Ordering and delivery system will be designed using the MVC architecture. The system will
have a set of interfaces (or clients) namely; the web client and the mobile clients. Users shall be
able to access and use the system from web or mobile, and so it will have different clients for
those. The users shall not be concerned with the internal representation of the information in
the system when they use the system in any of these platforms. In the same manner, the client
applications just interact with the controller of the system which holds the basic modules for
the fundamental functionalities defined in the requirements. The controller is responsible for
handling the user requests and actions by querying the model and modifying it if necessary. All
updates to the model will pass through the controller and not directly from the view.

72
The following is the basic context diagram for the system. The system in the middle handles all
the other operations including delivery management, order tracking and report generation. At
the very basic level our system stands in between the buyer and the seller as they perform the
transactions. Users registration data and details will be held and kept in the system and
selectively the important ones will be used as the user makes orders. In a similar manner the
system will hold information pertaining to the seller’s shop an d inventory and edits and
updates the information as required. Administrators get usage reports while sellers and users
get sales reports. Each transaction will be performed through the integrated external payment
systems.

73
 5.3 Development Methods & Contingencies
The design and implementation follows the object oriented approach as the system is designed
into a set of modules which contain a group of classes.

The specific implementations of the system will include the following:

● The front end of the web client of the system will be developed using the Vue.js
framework (JavaScript language)

74
 ● The backend of the web client will be developed using the Laravel PHP framework

● The Android and the IOS clients will be developed using the Flutter mobile application
development framework

● MySQL will be used to design the data storage

6 System Architecture
6.1 Subsystem decomposition
UML Component Diagram

Level 1 Component Diagram

Level 2 Component Diagram

75
Level 3 Component Diagram

6.2 Hardware/software mapping

UML Deployment diagram

76
7. Object Model
7.1 Class Diagram

77
78
7.2 Sequence Diagram
Registration Sequence Diagram

79
Checkout Sequence Diagram

80
Search Sequence Diagram

81
82
Track Order Sequence Diagram

83
Buying a product sequence diagram

84
Add product to cart sequence diagram

85
Edit profile sequence diagram

86
Review product sequence diagram

87
Empty cart sequence diagram

88
Remove from cart sequence diagram

89
7.3 State Chart Diagram

State chart Diagram 1: Registration

State chart diagram 2: Tracking order

90
91
8. Detailed Design
.

Table: 1 Administrator class

Administrator

registerAgent(user, type) : bool

generateUsageReport() : string

modifyAccount(userid, user) : bool

approveRefund(transaction) : bool

Table: 2 Operation description for Administrator class

Operation Visibility Return Argument Pre-Condition Post Condition
type

RegisterAgent Protected Boolean User user, The agent’s The agent’s

personal personal
Int Type,
information information
shouldn’t exist should exist

generateUsageReport Protected String (none) The usage The usage

information should information will
exist be generated

modifyAccount Protected Boolean Userid, The account The account

information should information
User
exist should be
modified

92
approveRefund Protected Boolean Transaction The transaction The refund
transaction information should request should be
exist approved

Table 3: Agent Class

Agent

-legalName : string

-address : string

+getlegalName() : string

+getAddress() : address

Table: 4 Attributes description for Agent class

Attribute Type Visibility Invariant

legalName: String Private Name <> NULL and must contain first, middle and last name
and shouldn’t contain special characters and integers.

Address String Private Address <>NULL and it must be between 12 to 20 characters

Table: 5 Attributes description for Agent class

Operation Visibility Return Argument Pre-Condition Post Condition

93
 type

getLegalName Protected String (none) The Agent has a The user gets the
legal name legal name of the
agent

getAddress Protected Address (none) The Agent has an The user gets the
address address of the
agent

Table 6: Buyer Class

Buyer

+addToCart(product, amount) : bool

+removeFromCart(product, amount = 0) : bool

+emptyCart() : bool

+checkout() : string

+createReview(on, rating, comment) : bool

+editReview(on, rating, comment) : bool

+confirmDelivery(transactionId)

94
 Table: 7 Attributes description for Buyer class

Operation Visibility Return Argument Pre-Condition Post Condition

type

addToCart Protected Boolean Product, The product or The product

amount the current should be added
amount wasn’t to cart
in the cart

removeFromCart Protected Boolean Product, The product or The product

amount = 0 the current should be
amount was in removed from
the cart cart or reduced by
the specified
amount

emptyCart Protected Boolean (none) The cart should The cart contents
have contents should be deleted

checkout Protected String (none) The cart should The cart contents
have contents should be cleared

createReview Protected Boolean Int id, The review isn’t The review is
available created
Double rating,

String comment

editReview Protected Boolean Int id, The review is The review is

available edited
Double rating,

95
 String comment

Table 8: Cart Class

Cart

-itemsList : List

-totalPrice : float

+add(product, amount) : bool

+remove(product, amount = 0) : bool

+empty() : bool

+getDetails() : string

+getPrice() : float

+getContents() : List

Table: 9 Attributes description for Cart class

Attribute Type Visibility Invariant

ItemsList: List Private Should contain a list of “Product” typed products

totalPrice Float Private <> NULL, could be 0 when content is empty

96
 Table: 10 Operations description for Cart class

Operation Visibility Return Argument Pre-Condition Post Condition

type

Add Protected Boolean Product The product or the The product

product, Int current amount should be added
amount wasn’t in the cart to cart

Remove Protected Boolean Product The product or the The product

product, Int current amount was should be
amount = 0 in the cart removed from
cart

Empty Protected Boolean (none) The cart should The cart contents
have contents should be deleted

getDetails Protected String (none) The cart details The cart details
should exist will be returned

getPrice Protected Float (none) The price should The cart price will
exist be returned

getContents Protected List (none) The content list The cart contents
should exist will be returned

Table 11: DeliveryPerson Class

DeliveryPerson

-status : bool

97
-drivingLicenseNumber : String

-plateNumber : string

-vehicleModel : string

- vehicleType : string

+switchStatus90 : bool

+confirmPick(transactionId) : bool

Table: 12 Attributes description for DeliveryPerson class

Attribute Type Visibility Invariant

Status Boolean Private True or false.

DrivingLicenseNumbe String Private <> NULL

r

PlateNumber String Private <> NULL

VehicleModel String Private <> NULL

VehicleType String Private <> NULL

98
 Table: 13 Operation description for DeliveryPerson class

Operation Visibility Return Argument Pre-Condition Post Condition

type

switchStatus Protected Boolean (none) The status is either The status gets
true/available or updated
false/unavailable.

confirmPick Protected Boolean Transaction The order hasn’t The order gets
transactionI been picked yet picked
d

Table 14: Inventory Class

Inventory

-productList : List

+add(product, amount) : bool

+remove(product, amount = 0) : bool

+updateProduct(product, amount) : bool

Table: 15 Attributes description for Inventory class

99
Attribute Type Visibility Invariant

ProductList List Private Should contain a list of “Product” typed products

Table: 16 Operations description for Inventory class

Operation Visibility Return Argument Pre-Condition Post Condition

type

add Protected Boolean Product The product or the The product

product, Int current amount should be added
amount wasn’t in the to cart
Inventory

remove Protected Boolean Product The product or the The product

product, Int current amount was should be
amount = 0 in the cart removed from
cart

update Protected Boolean Product The product or the The product

product, Int current amount was should be
amount in the cart updated

Table 17: Order Class

Order

-orderId : integer

100
-orderedBy: string

+track() : void

+getOrderId() : integer

+getOrderedBy(): string

Table: 18 Attributes description for Order class

Attribute Type Visibility Invariant

orderId Integer Private <> NULL

orderedBy String Private Name <> NULL and must contain first, middle and last
name and shouldn’t contain special characters and
integers.

Table: 19 Operations description for Order class

Operation Visibility Return Argument Pre-Condition Post Condition

type

track Protected Void (none) The order is being The order should
delivered be tracked

getOrderId Protected Integer (none) The ordered should The order Id will
exist be returned

101
getOrderedBy Protected Float (none) The orderedby The ordered by
should exist will be returned

Table: 20 Product Class

Product

-productId : integer

-productName: string

-vendorName: string

+getProductId() : integer

+getProductName(): string

+getVendorName(): string

Table: 21 Attribute description for Product Class

Attribute Type Visibility Invariant

productId Integer Private <> NULL

productName String Private Name <> NULL and must contain first, middle and last
name and shouldn’t contain special characters and
integers.

vendorName string Private Name <> NULL and must contain first, middle and last

102
 name and shouldn’t contain special characters and
integers.

Table: 22 Operations description for Product Class

Operation Visibility Return Argument Pre-Condition Post Condition

type

getProductId Protected Void (none) The productid The product id

should exist will be returned

getProductName Protected String (none) The productName The product name

should exist will be returned

getVendorName Protected String (none) The VendorName The vendor name

should exist will be returned

Table 23: Review Class

Review

-reviewBy: string

-reviewOn: string

-rating: float

-comment: string

+getReviwer():string

+getReviewed():string

103
+getRating():string

+getComment():string

Table 24: Attribute description Review Class

Attribute Type Visibility Invariant

reviewBy String Private Name <> NULL and must contain first, middle and last
name and shouldn’t contain special characters and
integers.

reviewOn String Private Name <> NULL and must contain first, middle and last
name and shouldn’t contain special characters and
integers.

rating Float Private <> NULL

Comment String Private Optional, Could be null

Table 25: Operation description Review Class

Operation Visibility Return Argument Pre-Condition Post Condition

type

getReviewer Protected String (none) The reviewer should The reviewer

exist name will be
returned

getReviewed Protected String (none) The reviewed The reviewed

should exist name will be

104
 returned

getRating Protected Float (none) The rating should The rating will be
exist returned

getComment Protected String (none) The comment The comment will

should exist be returned

Table 26: Transaction Class

Transaction

-transactionId: integer

-productList: string

-price: string

+getTransactionId(): integer

+getProductList(): List

+getPrice(): float

+requestRefund(): bool

Table 27: Attribute description for Transaction Class

Attribute Type Visibility Invariant

transactionId integer Private <> NULL

105
productList String Private Should contain a list of “Product” typed products.

price Float Private Could be 0 but <> NULL

Table 28: Operation description for Transaction Class

Operation Visibility Return Argument Pre-Condition Post Condition

type

getTransactionId Protected Integer (none) The transactionid The transactionId

should exist will be returned

getProductList Protected List (none) The productlist The productList

should exist will be returned

getPrice Protected Float (none) The price should The price will be
exist returned

requestRefund Protected Bool (none) The transaction is The transaction is

faulty deleted

Table 29: Shop Class

Shop

-shopName: string

106
-ownerName: string

-reviews: Review

-inventory: Inventory

+getShopName():string

+getReviews():review

+getInventory():Inventory

+setShopName(name): bool

Table 30: Attribute description for Shop Class

Attribute Type Visibility Invariant

shopName String Private Name <> NULL

ownerName String Private Should contain a list of “Product” typed products.

reviews Review Private Not NULL

inventory Inventor Private Not NULL

y

Table 31: Operation description for Shop Class

107
Operation Visibility Return Argument Pre-Condition Post Condition
type

getShopName Protected String (none) The shop name The shop name
exists will be returned

getReviews Protected Review (none) The reviews exist The reviews will
be returned

getInventory Protected Float (none) The Inventory exists The inventory will
be returned

setShopName Protected Boolean String The shop could or The shop name
Name shouldn’t have a will be set or
name modified

Table 32: User Class

User

-userName: string

-password: Review

-id:string

-phoneNumber: string

+getUsername():string

+getid():string

+getPhoneNunber():string

108
 Table 33: Attribute description for User Class

Attribute Type Visibility Invariant

userName String Public Name <> NULL and must contain first, middle and last name
and shouldn’t contain special characters and integers.

password Review Public Should be 8 characters long and include letters and numbers
and shouldn’t be the same as the username

Id string Public ID <> NULL

phoneNumber String Private PhoneNumber <> NULL must be 10 digits and must start by
+251/09

Table 34: Operation description for User Class

Operation Visibility Return Argument Pre-Condition Post Condition

type

getUserName Protected String (none) The user name The shop name
exists will be returned

getId Protected string (none) The id exists The reviews will

be returned

getPhoneNumber Protected String (none) The phone number The inventory will
exists be returned

109
 Table 35: Seller Class
Seller

-shop: Shop

-review: Review

+getShop():shop

+getReviews():review

Table 36: Attribute description for Seller Class

Attribute Type Visibility Invariant

shop Shop Public Shop <> NULL

Review Review Public Review can be null

Table 37: Operation description for Seller Class

Operation Visibility Return Argument Pre-Condition Post Condition

type

getShop Protected Shop (none) The shop should be The shop will be
created returned

110
getReviews Protected Review (none) The reviews shall The reviews will
exisi be returned

111
 Chapter 5: Testing
5.1 Introduction
Software testing is an organizational process within software development in which business-
critical software is verified for correctness, quality, and performance. Software testing is used to
ensure that expected business systems and product features behave correctly as expected.
Software testing may either be a manual or an automated process.

● Manual software testing is led by a team or individual who will manually operate a
software product and ensure it behaves as expected.
● Automated software testing is composed of many different tools, which have varying
capabilities, ranging from isolated code correctness checks to simulating a full human-
driven manual testing experience.
Software testing will save an organization time and money by reducing software development
and maintenance costs. Software testing builds stability guarantees into the development of
new features. Testing ensures that a feature is working as expected and users are not
encountering bugs.

Development time on new features is reduced by specifying a set of test cases that the new
feature must match to be considered complete and deliverable. This gives developers a fixed
target to work towards enabling more accurate timeline estimates and lowering the
introduction of new bugs. Once these test cases are in place the overall maintenance costs are
lowered. The tests can be run against an already delivered feature to ensure that it still behaves
as expected.

112
 5.2 Features to be tested/not to be tested
5.2.1 Features to be tested

Features being Difficult Testing Scenarios

tested y

Signin Low New users get signed in 

Signup Medium User creates an account 

Manage product Medium Seller performs all CRUD operations on a

product

Review Product Medium User reviews a product 

Assign Delivery Medium Delivery Personnel will be assigned to an order.

Change Password Medium Users change their account password

View status(Delivery) Medium Delivery monitors all activity in the status board.

Generate Report Medium Report will be generated

 

 5.2.2 Features not to be tested

5.3. Pass/Fail criteria

The pass-fail criteria are based upon the following measures.
Invalid input: Incorrect data format or an empty input could make an input invalid.
Failure Notice: A message has to be generated to the user indicating the wrong entry that
he/she has made in the fields.

113
 Valid input: A valid input would be entering the data into the data entry fields in a correct
format.
Pass criteria: The standards would be returning a confirmation or a valid result.
 

5.4. Approach/Strategy
The testes taken on the project are taking the consideration of the functional and nonfunctional
requirements that are listed on the SRS document. From the listed functional and non-
functional requirements on the SRS document, eight functional requirements have been tested
and no defects have been found. From the five nonfunctional requirements three have been
tasted. And no defects have been found on them.

5.5 Test cases with specifications

Table 1: Test case specification for Login

Name: Login for web portal

Purpose: to verify that only authorized users gain access to the required page

Test Data= Email(Invalid, Valid, Empty)

               Password(Invalid, Valid, Empty)

Input Expected result Data Actual output Pass/

fail

Empty “Invalid account Any valid password “Invalid account Fail

email information!” and information!”
Valid Empty email
password

Invalid “Invalid account Any valid password “Invalid account Fail

email information!” and information!”
valid any Invalid email
password

Invalid “Invalid account Any Invalid email “Invalid account Fail

email information!” and empty information!”  
empty password  
password

114
 Valid email “Invalid account Any valid email and “Invalid account Fail
Invalid information!” Any invalid information!”
password Password

Empty “Invalid account Empty email and “Invalid account Fail

email information!” Empty Password information!”
Empty
Password

Valid email The user is redirected Any Valid email and The user is redirected Pass
Valid to home page valid Password to home page
Password

 
Table 2: Test case specification for registering new user
Name: Signup/Register new user

Purpose: To register new user

Test Data = fullname(invalid data, valid, empty)

                   Email(invalid data, valid, empty,)
                   phonenumber(invalid data, valid, empty,)
                   password(invalid data, valid, empty,)
                   confirmpassword(invalid data, valid, empty,)

Input Expected result Data Actual output Pass/

fail

Empty Full name “Please fill out this “” “Please fill out this fail
field” field”

115
 Previously “the email is already already “User already fail
registered email being used registered email exists”

Empty Phone “please put ““ “please put fail

number something here” something here”

Valid passowrd “no errors will be password no errors displayed  pass

displayed”

Empty password “please put ““ “please put fail

something here” something here”

non-confirming “passwords donot password “passwords donot pass

passwrds  match” match”

 
 
Table 3: Test case specification for managing product
Name: Manage Product

Purpose: Perform CRUD on a product

Test data
                  image(invalid data, valid, empty,)
                  name(invalid data, valid, empty,)
                 price(invalid data, valid, empty,)
                 discount(invalid data, valid, empty,)
                  brand(invalid data, valid, empty,)
                  model(invalid data, valid, empty,)
                  color(invalid data, valid, empty,)
                  category(invalid data, valid, empty,)
                  Characteriststics(invalid data, valid, empty,)
                  options(invalid , valid, empty)
                  notes (invalid , valid, empty)
                  info(invalid , valid, empty)

116
Input Expected result Data Actual output Pass/
fail

Empty Image “Please fill out this “” “Please fill out this fail
field” field”

Previously “the username is already “Student already fail

registered already being used registered exists”
product name student

Empty price “please put something ““ “please put fail

here” something here”

Valid image “no errors will be first name no errors displayed pass
displayed when moving when moving to
to next field” next field

Empty price “please put something ““ “please put fail

here” something here”

Valid name “no errors will be Mothers name no errors displayed pass
displayed”

Empty name “please put name ““ “please put name fail

here” here”

117
6.0 User Manual
6.1 scope
This user manual is to help maintain, update and use this new Ecommerce website easily and
quickly.We have listed detailed screenshots, explanations and instructions on how to manage
the application. 
The manual covers the following topics.
·             Installation
·             Configuration
·             How to operate the system
·             How to execute admin functions

6.2 Installation and configuration

Pre-requirement for installation:
·             A web server
·             Laravel should be installed
·             Environment settings should be configured

6.3 How to Operate the system

6.3.1. How to start the system
The application can be accessed from: 

1.  What a regular user sees, also known as “The Front End”: 

 http://minletazez.test 

1. The Admin panel, where you can change your website or add new products:

http://minletazez.test/admin (Requires an admin account username and password.)

118
6.3.2. How to create user account
To create a user account:

1. Visit the homepage

2. At the top right corner of the page hover over (or click on, depending on your device)
the red avatar icon

119
3. Click on Signup
4. Fill in the required
fields and hit

signup/register

120
121
 5. You will be redirected to logged-in-user-homepage if your input is correct otherwise
correct the inputs and retry.

6.3.3. How to execute admin functions

To enter the admin panel:

1. Login with an admin account

2. Find the browser’s “url view” field (at the top on most devices and browsers) where the
path to http://

3. Enter http://minletazez.test/admin and hit enter

122
 4. You will be redirected to the admin dashboard and see the following page where you
will be able to perform the admin functions by choosing one of the list items on the left
navigation pane.

6.3.4. Order an item

1. Navigate to homepage or product view of any category (as shown respectively below) 

123
2. Add the item or items you are interested in to cart

3. At the bottom left corner of the page press/click on the cart icon 

124
4. Review the list of added items and hit the checkout button at the top right side of the
page once you are satisfied with the inputs and price(you can decrease amounts or
empty the cart completely and start this sequence again)

125