University of Gujrat

Department of Computer Science

ONLINE BOOKS RESELLING PORTAL

Session: BSCS 2017-2021

Project Advisor: Dr. Nauman Riaz Chaudhry

Submitted by
Warda Shabbir 17271519-003
Saman Ishtiaq 17271519-043
Maryam Tanveer 17271519-072
OBRP

STATEMENT OF SUBMISSION

This is certifying that “Warda Shabbir” Roll No. “17271519-003”, “Saman Ishtiaq”
Roll No. “17271519-043” and “Maryam Tanveer” Roll No “17271519-072” has
successfully completed the final year project named as “Online Books Reselling Portal”
at the Department of Computer Science, University of Gujrat, to fulfill the requirement of
the degree of BS Hons. in Computer Science.

Project Supervisor Project Management Office,

Faculty of Computing &IT Department of Computer Science.

Chairperson Computer Sciences.

ii
© Department of Computer Science University of Gujrat
 ACKNOWLEDGEMENT

We truly acknowledge the cooperation and support provided by HOD, Department of

Computer Science, University of Gujrat. He has been a constant source of guidance
throughout the course of this project. We would also like to thank Dr. Nauman Riaz
Chaudhry for his help and guidance throughout this project. We are also thankful to our
friends and families whose silent support led us to complete our project.

Date: July 14, 2021

 Abstract

Books can also be the most resourceful activity to learn various experiences and life skills
which can boost personality development of children. Reading is a skill which enhances
perception abilities of a person. Now a days, the main issue is that the people waste their
used books by throwing them in garbage or putting them in cupboard for couple of years,
unused or some people just give their books to ragman. On the other hand, few people are
unable to buy the firsthand books just due to lack of money. Few of them just quit their
studies due to expensive books. To provide such students a golden chance, we are going
to make a website, which helps the people to buy their old books in less price and other
people who are not able to buy firsthand, or expensive books can purchase the
secondhand books in less price and easily from the app without going to market. This will
help the people to save time and travelling cost as well. And it serves as an earning
source for people, who sells their old and used books.
TABLE OF CONTENTS
CHAPTER 1: PROJECT FEASIBILITY REPORT.....................................................1
1.1. INTRODUCTION..........................................................................................................2
1.2. PROJECT/PRODUCT FEASIBILITY REPORT...........................................................2
1.2.1. Technical Feasibility.....................................................................................................2
1.2.2. Operational Feasibility.................................................................................................3
1.2.3. Economic Feasibility....................................................................................................3
1.2.4. Schedule Feasibility......................................................................................................3
1.2.5. Specification Feasibility................................................................................................3
1.2.6. Information Feasibility.................................................................................................4
1.2.7. Motivational Feasibility................................................................................................4
1.2.8. Legal & Ethical Feasibility...........................................................................................4
1.3. PROJECT/PRODUCT SCOPE.......................................................................................4
1.4 PROJECT/PRODUCT COSTING...................................................................4
1.4.1. Project Cost Estimation By Function Point Analysis..............................................4
1.4.2. Project Cost Estimation By Using Cocomo’81 (Constructive Cost Model).............5
1.4.3. Activity Based Costing............................................................................................6
1.5. TASK DEPENDENCY TABLE.....................................................................................6
1.6. CPM-CRITICAL PATH METHOD...............................................................................7
1.7. GANTT CHART............................................................................................................7
1.8. INTRODUCTION TO TEAM MEMBER AND THEIR SKILL SET............................7
1.9. TASK AND MEMBER ASSIGNMENT TABLE..........................................................8
1.10. TOOLS AND TECHNOLOGY WITH REASONING...................................................9
1.11. VISION DOCUMENT...................................................................................................9
1.12. RISK LIST.....................................................................................................................9
1.13. PRODUCT FEATURES/ PRODUCT DECOMPOSITION...........................................9
CHAPTER 2: SOFTWARE REQUIREMENT SPECIFICATION (FOR OBJECT
ORIENTED APPROACH................................................................................................11
2.1. INTRODUCTION.............................................................................................................12
2.1.1. Systems Specifications................................................................................................13
2.1.2. Identifying External Entities.......................................................................................14
2.1.3. Context Level Data Flow Diagram.............................................................................14
2.1.4. Capture "Shall" Statements.........................................................................................14
2.1.5. Allocate Requirements................................................................................................14
2.1.6. Prioritize Requirements..............................................................................................14
2.2. ONLINE BOOKS RESELLING PORTAL (OBRP).........................................................14
2.2.1. Introduction................................................................................................................14
2.2.2 Existing Systems...........................................................................................................15
2.2.3 Scope Of The System....................................................................................................15
2.2.4. Summary Of Requirements: (Initial Requirements).....................................................15
2.2.5. Identify External Entities............................................................................................15
2.2.6. Capture "Shall" Statements.........................................................................................16
2.2.7 Allocate Requirements:................................................................................................17
 2.2.8. Prioritize Requirements:.............................................................................................18
2.2.9. Requirements Trace-Ability Matrix.............................................................................19
2.1.8. Interface Requirements...............................................................................................20
2.2.10. High Level Use Case Diagram..................................................................................21
2.2.11. Analysis Level Use Case Diagram............................................................................22
2.2.12. User Case Descriptions............................................................................................22
2.3 NON-FUNCTIONAL ATTRIBUTES................................................................................25
CHAPTER 3: SOFTWARE REQUIREMENT SPECIFICATION AND DESIGN
DOCUMENT (FOR OBJECT ORIENTED APPROACH)..............................................26
3.1. INTRODUCTION........................................................................................................27
3.2. DOMAIN MODEL.......................................................................................................27
3.3. SYSTEM SEQUENCE DIAGRAM.............................................................................28
3.4. SEQUENCE DIAGRAM:.............................................................................................29
3.5. COLLABORATION DIAGRAM:................................................................................29
3.5.1. Contents Of Collaboration Diagram.....................................................................30
3.5.2. Constructs Of Collaboration Diagram..................................................................30
3.6. DESIGN CLASS DIAGRAM:.....................................................................................31
3.7. STATE CHART DIAGRAM:.......................................................................................32
CHAPTER 4: USER INTERFACE DESIGN...............................................................35
4.1. INTRODUCTION........................................................................................................36
4.2. SITE MAPS..................................................................................................................36
4.3. STORY BOARD..........................................................................................................38
4.4. NAVIGATIONAL MAPS............................................................................................38
4.5. TRACEABILITY MATRIX.........................................................................................39
CHAPTER 5: SOFTWARE TESTING.........................................................................41
5.1 INTRODUCTION..............................................................................................................42
5.2 TEST PLAN.......................................................................................................................42
5.2.1. Test Plan Identifier.....................................................................................................43
5.2.2. Introduction................................................................................................................43
5.2.3. Test Items....................................................................................................................43
5.2.4. Features To Be Tested.................................................................................................44
5.2.5. Features Not To Be Tested..........................................................................................44
5.2.6. Approach....................................................................................................................44
5.2.7. Item Pass/Fail Criteria...............................................................................................44
5.2.8. Suspension Criteria And Resumption Requirements...................................................44
5.2.9. Test Deliverables........................................................................................................44
5.2.10. Testing Tasks............................................................................................................45
5.2.11. Environmental Needs................................................................................................45
5.2.12. Responsibilities.........................................................................................................45
5.2.14. Schedule....................................................................................................................46
5.2.15. Risks And Contingencies...........................................................................................46
5.2.16. Approvals..................................................................................................................46
5.3. TEST DESIGN SPECIFICATION...............................................................................46
5.3.1. Purpose.......................................................................................................................46
 5.3.2. Outline........................................................................................................................46
5.4. TEST PLAN IDENTIFIER...........................................................................................47
5.4.1. Introduction................................................................................................................47
5.4.2. Test Items....................................................................................................................47
5.4.3. Features To Be Tested................................................................................................48
5.4.5. Approach....................................................................................................................48
5.4.6. Item Pass/Fail Criteria...............................................................................................48
5.4.7. Suspension Criteria And Resumption Requirements...................................................48
5.4.8. Test Deliverables........................................................................................................48
5.4.9. Testing Tasks..............................................................................................................49
5.4.10. Environmental Needs................................................................................................49
5.4.11. Responsibilities.........................................................................................................49
5.4.12. Staffing And Training Needs.....................................................................................49
5.4.13. Schedule...................................................................................................................49
5.4.14. Risks And Contingencies...........................................................................................49
5.4.15. Approvals.................................................................................................................50
5.5. TEST PROCEDURE SPECIFICATION......................................................................50
5.5.1. Test Case Specification Identifier...............................................................................50
5.5.2. Test Items....................................................................................................................50
5.5.3. Input Specifications....................................................................................................50
5.5.4. Output Specifications..................................................................................................50
5.6. ENVIRONMENTAL NEEDS......................................................................................50
5.6.1. Hardware...................................................................................................................50
5.6.2. Software......................................................................................................................50
5.6.3. Other..........................................................................................................................51
5.6.4. Special Procedural Requirements...............................................................................51
5.6.5. Inter Case Dependencies............................................................................................51
5.6.6. Test Procedure Specification......................................................................................51
5.7. TEST LOG....................................................................................................................52
5.7.1. Purpose.......................................................................................................................52
5.8. TEST INCIDENT REPORT.........................................................................................54
5.8.1. Purpose.......................................................................................................................54
5.8.2. Outline........................................................................................................................54
5.9. TEST SUMMARY REPORT.......................................................................................55
5.9.1. Purpose.......................................................................................................................55
5.9.2. Outline........................................................................................................................55
CHAPTER 6: USER MANUAL.....................................................................................57
6.1 GENERAL INFORMATION.............................................................................................58
6.1.1 System Overview..........................................................................................................58
6.2 SYSTEM SUMMARY.......................................................................................................58
6.2.1 System Configuration..................................................................................................58
6.2.2 User Access Levels......................................................................................................58
6.2.3 Contingencies..............................................................................................................58
6.3 GETTING STARTED........................................................................................................58
 6.3.1 Usage Guide................................................................................................................58
6.3.2 Logging In...................................................................................................................58
6.4 USING THE SYSTEM.......................................................................................................59
6.4.1. Home Screen...............................................................................................................60
6.4.2 Chatbot........................................................................................................................62
6.4.3 Root User Dashboard..................................................................................................63
6.4.4 Admin Dashboard........................................................................................................64
6.4.5 User Dashboard..........................................................................................................64
6.4.6 Sell Page......................................................................................................................65
6.4.7 Products Page.............................................................................................................65
6.4.8 View Product Page......................................................................................................66
6.4.9 Cart.............................................................................................................................66
6.4.10 Checkout....................................................................................................................67
OBRP

Chapter 1: Project Feasibility Report

1
© Department of Computer Science University of Gujrat
OBRP

1.1. Introduction
Books can also be the most resourceful activity to learn various experiences and life skills
which can boost personality development of children. Reading is a skill which enhances
perception abilities of a person. Now a days, the main issue is that the people waste their
used books by throwing them in garbage or putting them in cupboard for couple of years,
unused or some people just give their books to ragman. On the other hand, few people are
unable to buy the firsthand books just due to lack of money. Few of them just quit their
studies due to expensive books. To provide such students a golden chance, we are going
to make a website, which helps the people to buy their old books in less price and other
people who are not able to buy firsthand, or expensive books can purchase the
secondhand books in less price and easily from the app without going to market. This will
help the people to save time and travelling cost as well. And it serves as an earning
source for people, who sells their old and used books.
This project is like an e-bookstore website where books can be bought from the comfort
of home through the Internet. An online bookstore is a virtual store on the Internet where
customers can browse the catalog and select books of interest. User can select many
books and those books stored in cart. At checkout time, the items in the shopping cart
will be presented as an order. At that time, more information will be needed to complete
the transaction. Usually, the customer will be asked to fill the basic details or select a
billing address, a shipping address, a shipping option, and payment information such as
credit card number. The system can be very well used by the user as well as book
shopkeepers to expand their customers.

1.2. Project/Product Feasibility Report

There are many types of feasibilities:
• Technical
• Operational
• Economic
• Schedule
• Specification
• Information
• Motivational
• Legal and Ethical

1.2.1. Technical Feasibility

In Technical point of view tools that are used to develop our project are available, so it is
possible to develop our “Online Books Reselling Portal” and our team members have
skills to develop such system. It is measure of the practicality of specific technical
solution and the availability of technical resources and expertise. The development of
books Reselling Portal is technical feasible because of the following reason:
 Online Secondhand Book Buying & Selling Portal components are easily available.

2
© Department of Computer Science University of Gujrat
  To check whether the module technically feasible or not we have to give the
following two question answer.
Q.1 Is the proposed system practical?
Ans. The proposed system is practical as we have all the resources available. Also
building up this module requires the minimum amount of hardware & software is easily
available. So, the proposed system is extremely efficient and practical.
Q.2 Do we currently possess the necessary technology?
Ans. Looking into the system requirement, we can see that we possess all the hardware
and software requirements. Also, the technology used is easily available and deployed
all around the world.

1.2.2. Operational Feasibility

In operational feasibility we discuss skill set of our members if we have capability to do
this project. The question arises in operational feasibility is that is problem is worth
solving or not?
This project is very helpful especially in Pakistan as well as the internationally. It
provides all the Social and professional Facilities at the same platform. It is required such
system that provide these services fully automatic responsive.

1.2.3. Economic Feasibility

Economically our Project depends on the amount a hardware available for the support.
The main types of cost one can require to build this project is in form maintenance and
assistive technology.
Development Cost: 50K
Maintenance and Assistive Cost: can be derived from the suggested hardware list.
Benefit Estimates: Benefit estimates enclose tangible benefits and intangible benefits.
Tangible Benefits: We provide our services for free and make our system easier to use.
Intangible Benefits: We try to provide best services to the users of our system and
provide correct and useful information and help.

1.2.4. Schedule Feasibility

Time is an important factor. Scheduling and Planning of Project is very important to
complete Project on Time. In this regard we divide the project into tasks with proper
dependencies and durations and make Critical Path Method and Gantt chart.

1.2.5. Specification Feasibility

Requirement Specification and Analysis is the main aspect of our Online Book Reselling
Portal. We must have proper requirements specification to make our project meaningful
and useful according to user requirements.
1.2.6. Information Feasibility
To complete our Project, we divide the Project into Tasks and tasks are assigned to each
member according to their skill set. We make our project reliable by using advanced
Social Website development technology.

1.2.7. Motivational Feasibility

Using this system is not only an assistance to those with all humanly abilities but also for
those who lack something in their body. If someone cannot type with hand, they can only
see on the screen to control a computer. This project is totally free to use for all of those
who want to have the best experience and enjoy the wonder we can Human Eye.

1.2.8. Legal & Ethical Feasibility

Legally and ethically, we have legal rights to use tools that are used to develop our
Projects. We Use Visual Studio code that Microsoft provided to us in our University
Website freely. We use JavaScript Runtime Environment like Node.js that are freely
available on their websites.
We use React JS, HTML, CSS on the frontend, which are open source and free to use.
We used Python and Natural Language Toolkit to build the datasets for bot, which are
open source and free to use.

1.3. Project/Product Scope

Online Second-hand Book Buying & Selling Portal is an online service that allows users
to list their old and new books to reuse/recycle them and make money while doing so.
It covers public and book readers. That can find any book available in good condition at a
good market price. It is intended to be a platform for book lovers to find quality books
and purchase them. Also helping students and public to recycle books and make money
doing so.

1.4. Project/Product Costing

1.4.1. Project Cost Estimation by Function Point Analysis
 Table 1.1
Total Function Points ≈ 464

1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost

Model) Our Project is between organic and embedded type, so we use Semi-detached
type to measure cost.
Basic COCOMO
Type Effort Schedule
Semi-Detached PM  3.0(KLOC) 1.12
*3.95 TD  2.5(PM )0.35
PM= person-month (effort)
KLOC= lines of code, in thousands
TD= number of months estimated for software development (duration)
𝑃𝑀 = 3.0(7.29)1.12 *3.95= 109.64
𝑇𝐷 = 2.5(109.64)0.35 = 12.93
People Required = 109.64 /12.93= 8.47

1.4.3. Activity Based Costing

Task Duration Cost
A. Database Development 7 Days Free
B. Website Frontend Development 15 Days Free
C. REST API: Users Module 10 Days Free
D. REST API: Products Module 8 Days Free
E. REST API: Orders Module 5 Days Free
F. Frontend Connection Users 5 Days Free
Module
G. Frontend Connection Products 5 Days Free
Module
H. Frontend Connection Orders 5 Days Free
Module
I. Natural Language Bot Dataset 10 Days Free
J. Interactive Support Bot Front End 7 Days Free
K. Interactive Support Bot Backend 10 Days Free
Table 1.2

1.5. Task Dependency

Table
Task Dependency Duration
A. Database Development None 7 Days
B. Website Frontend Development A 15 Days
C. REST API: Users Module A, B 10 Days
D. REST API: Products Module A, C 8 Days
E. REST API: Orders Module A, C, D 5 Days
F. Frontend Connection Users B, C 5 Days
Module
G. Frontend Connection Products B, D 5 Days
Module
H. Frontend Connection Orders B, E 5 Days
Module
I. Natural Language Bot Dataset A 10 Days
J. Interactive Support Bot Front I 7 Days
End
K. Interactive Support Bot J 10 Days
Backend
Table 1.3
1.6. CPM-Critical Path Method

Figure 1.1

1.7. Gantt Chart

Figure 1.2

1.8. Introduction to Team member and their skill set

Member Name Skill Set Tasks
 Warda Shabbir Backend Development Design and develop
database and Rest APIs
Saman Ishtiaq Database Connectivity Integrate and Map REST
APIs.
Maryam Tanveer Frontend Framework Design and develop all
high-end components
Table 1.4

1.9. Task and Member Assignment Table

Task Duration (days) Dependencies Members
T1 7 M1, M2, M3
T2 15 T1 M1, M2
T3 10 T1, T2 M1, M2, M3
T4 8 T1, T3 M1, M3
T5 5 T1, T3, T4 M2, M3
T6 5 T2, T3 M1, M2
T7 5 T2, T4 M2, M3
T8 5 T2, T5 M3
T9 10 T1 M1
T10 7 T9 M1, M2, M3
T11 10 T10 M1, M2, M3
Table 1.5

Allocation of People to Activities:

Task Members
T1 M1, M2, M3
T2 M1, M2
T3 M1, M2, M3
T4 M1, M3
T5 M2, M3
T6 M1, M2
T7 M2, M3
T8 M3
T9 M1, M2, M3
T10 M1, M2, M3
T11 M2, M3
Table 1.6
Staff Allocation:
OBRP

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10
Warda Shabbir
Saman Ishtiaq
Maryam Tanveer

1.10. Tools and Technology with Reasoning

• HTML5, CSS3, Bootstrap for Frontend Layouts and Design
• React JS as Frontend Framework
• Node.JS and Express.js For REST API Development
• MongoDB for No-SQL Database
• Visual Studio Code and Atom
• NPM (Node Package Manager)
Tools and technologies (optional):
• Python Flask Framework

1.11. Vision Document

Online books reselling portal provide the facility of buying the secondhand books. It
provides the complete facility of selling the secondhand. It also provides the facility of AI
chatbot. This portal will provide all the facilities with proper tracking and notification
alerts from your order submission to job done with feedback facility.

1.12. Risk List

• We are not facing any major risk regarding our reseller feature, but our main
concern remains for our AI Chatbot’s Dataset.
• English language has a wide range of conversational constructs that are
understandable and can be interpreted in a dataset, a different language might
put the system at risk.

1.13. Product Features/ Product Decomposition

Sr. Features

1 E-Commerce Feature
2 Order Management
3 Searching

9
© Department of Computer Science University of Gujrat
OBRP

4 Admin Overview
5 AI Chatbot for Support
Table 1.7

10
© Department of Computer Science University of Gujrat
Chapter 2: Software Requirement Specification (For Object
Oriented Approach
2.1. Introduction
Requirements engineering process provides the appropriate mechanism for understanding
what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable
solution, specifying the solution unambiguously, validating the specification and
managing the requirements as they are transformed into an operational system. The task
of capturing, structuring, and accurately representing the user’s requirements so that they
can be correctly embodied in systems which meet those requirements (i.e., are of good
quality).
• Requirement’s elicitation
• Requirement’s analysis and negotiation
• Requirement’s specification
• System modeling
• Requirement’s validation
• Requirements management

Figure 2.1

Here, requirements specification is to be discussed. Requirement’s specification would

lead to the following four steps:
• Identify external interfaces.
 • Development of context diagram
• Capture “shall statements.
• Allocate requirements.
• Prioritize requirements.
• Development of requirements traceability matrix

2.1.1. Systems Specifications

The following are the clauses that must be included while describing the system
specifications.

2.1.1.1 Introduction
Books can also be the most resourceful activity to learn various experiences and life skills
which can boost personality development of children. Now a days, the main issue is that
the people waste their used books by throwing them in garbage or putting them in
cupboard for couple of years, unused or some people just give their books to ragman. On
the other hand, few people are unable to buy the firsthand books just due to lack of
money. Few of them just quit their studies due to expensive books. To provide such
students a golden chance, we are going to make a website, which helps the people to buy
their old books in less price and other people who are not able to buy firsthand, or
expensive books can purchase the secondhand books in less price and easily from the app
without going to market. This will help the people to save time and travelling cost as
well. And it serves as an earning source for people, who sells their old and used books.

2.1.1.2 Online Books Reselling Portal

Online Books Reselling Portal is like an e-bookstore website where books can be bought
from the comfort of home through the Internet. An online bookstore is a virtual store on
the Internet where customers can browse the catalog and select books of interest. User
can select many books and those books stored in cart. At checkout time, the items in the
shopping cart will be presented as an order. At that time, more information will be needed
to complete the transaction. Usually, the customer will be asked to fill the basic details or
select a billing address, a shipping address, a shipping option, and payment information
such as credit card number. The system can be very well used by the user as well as book
shopkeepers to expand their customers.

2.1.1.3 Organizational Chart

This Organizational chart will be very much supportive to get a better overview of the
organization’s areas and their different departments.

2.1.1.4 Scope of the System

System covers several stakeholders including book collectors, students, teachers,
librarians and more. System is intended to cover public with similar interests, and market
to draw new users to be part of the platform.
2.1.1.5 Summary of Requirements: (Initial Requirements)
In this e-bookstore, hire an admin or control authority to manage this website. This can be
helpful for students.

2.1.2. Identifying External Entities

In our project of online books reselling portal, the Identification of External Entities is
done in two phases: Over Specify Entities from Abstract and Perform Refinement.

2.1.3. Context Level Data Flow Diagram

Data flow diagram of online books reselling portal contains only process, representing
the entire system.

2.1.4. Capture "shall" Statements

According to the functional requirements this project will fulfill the ‘Shall’ statements.

2.1.5. Allocate Requirements

In use case diagram of this project, we describe the whole working of online books
reselling portal. We allocate the requirements related to this website in the use cases.

2.1.6. Prioritize Requirements

We have priorities the logins, buying, searching, and editing books. This will help
achieve tasks easily.

2.2. Online Books Reselling Portal (OBRP)

2.2.1. Introduction
Books can also be the most resourceful activity to learn various experiences and life skills
which can boost personality development of children. Reading is a skill which enhances
perception abilities of a person. Now a days, the main issue is that the people waste their
used books by throwing them in garbage or putting them in cupboard for couple of years,
unused or some people just give their books to ragman. On the other hand, few people are
unable to buy the firsthand books just due to lack of money. Few of them just quit their
studies due to expensive books. To provide such students a golden chance, we are going
to make a website, which helps people to buy their old books in less price and other
people who are not able to buy firsthand, or expensive books can purchase the
secondhand books in less price and easily from the app without going to market. This will
help the people to save time and travelling cost as well and it serves as an earning source
for people, who sells their old and used books.
This project is like an e-bookstore website where books can be bought from the comfort
of home through the Internet. An online bookstore is a virtual store on the Internet where
customers can browse the catalog and select books of interest. User can select many
books
and those books stored in cart. At checkout time, the items in the shopping cart will be
presented as an order. At that time, more information will be needed to complete the
transaction. Usually, the customer will be asked to fill the basic details or select a billing
address, a shipping address, a shipping option, and payment information such as credit
card number. The system can be very well used by the user as well as book shopkeepers
to expand their customers.
2.2.2 Existing Systems
There are several e-commerce stores, and classified sites that are already working with
buying and selling. Our system is intended to be a mainstream platform for people to
recycle books and earn while doing it.
2.2.3 Scope of the System
System covers several stakeholders including book collectors, students, teachers,
librarians and more. System is intended to cover public with similar interests, and market
to draw new users to be part of the platform. Similar system has already created a wide
range of usage for such technologies. So, our system intends to provide a different
dynamic.

2.2.4. Summary of Requirements: (Initial Requirements)

• User Management
• Product Management
• Order Management
• Historical Reports
• Admin Dashboard
• AI Chatbot for Support

2.2.5. Identify External Entities

The Identification of External Entities is done in two phases.
a. Over Specify Entities from Abstract:
• User
• REST API Client
• REST Server
b. Perform Refinement:
After over specifying the entities, you must refine them based on your business logic. For
example, in this example we found the following entities more related to our business logic.
• Site Visitors
Context Level Diagram

Figure 2.2

2.2.6. Capture "shall" Statements:

Identifier Initial Requirements
1 User shall be able to use the application through a web
browser.
 2 The system shall allow user to view as a visitor.
3 User shall be able to register to the system as a user by using
email.
4 The system shall ask user to sign in to access user dashboard.
5 The system shall allow user to add products to the database.
6 The system shall allow users to search for books.
7 The system shall allow users to add books to local storage
carto place an order.
8 The system shall allow users to place an order.
9 The system shall allow users to check order history.
10 The system shall allow users to check for the order made for
their listed product.
11 The system shall allow users to track the status of their order.
12 The system shall allow users to change order status.
13 The system shall allow admin to view products.
14 The system shall have a section for admin to view orders.
15 The system shall allow admin to filter orders based on status,
date, and price.
Table 2.1

2.2.7 Allocate Requirements:

Identifier Initial Requirements Use Case Name
1.0 User shall be able to login to the system using UC_Auth
email and password.
2.0 The system shall have a section for users to UC_ProductsManagement
add new products, delete existing products,
edit existing products.
3.0 System shall allow users to search for books UC_Search
based on ISBN, Title, Price, Categories.
4.0 The system shall allow users to add products UC_Shop
to cart and submit an order to buy.
5.0 The system shall allow users to check for UC_Orders Managment
incoming orders for the products that they
listed. User shall be able to change status of
the order, view information for customer to
communicate.
 6.0 The system must have a protected area for UC_Admin
admin users to manage products, categories,
orders and handle the system’s settings.
7.0 The system shall have a chatbot for users to UC_SupportBot
interact with so they can contact support to
learn more about using the system.
Table 2.2

2.2.8. Prioritize Requirements:

Identifier Initial Requirements Priority User Use Case Name
Case
ID
1.0 User shall be able to login High UC_1 UC_Auth
to the system using email
and password.
2.0 The system shall have a High UC_2 UC_ProductsManagement
section for users to add
new products, delete
existing products, edit
existing products.
3.0 System shall allow users High UC_3 UC_Search
to search for books based
on ISBN, Title, Price,
Categories.
4.0 The system shall allow High UC_4 UC_Shop
users to add products to
cart and submit an order
to buy.
5.0 The system shall allow High UC_5 UC_Orders Managment
users to check for
incoming orders for the
products that they listed.
User shall be able to
change status of the order,
view information for
customer to communicate.
6.0 The system must have a High UC_6 UC_Admin
protected area for admin
users to manage products,
categories, orders and
handle the system’s
settings.
7.0 The system shall have a Medium UC_7 UC_SupportBot
chatbot for users to
interact with so they can
 contact support to learn
more about using the
system.
Table 2.3

2.2.9. Requirements Trace-ability Matrix:

Identifier Initial Build Use Case Name Category
Requirements
1.0 User shall be able to B1 UC_Auth Business
login to the system
using email and
password.
2.0 The system shall B1 UC_ProductsManagement Business
have a section for
users to add new
products, delete
existing products,
edit existing
products.
3.0 System shall allow B1 UC_Search Business
users to search for
books based on
ISBN, Title, Price,
Categories.
4.0 The system shall B1 UC_Shop Business
allow users to add
products to cart and
submit an order to
buy.
5.0 The system shall B1 UC_Orders Managment Business
allow users to check
for incoming orders
for the products that
they listed. User
shall be able to
change status of the
order, view
information for
customer to
communicate.
6.0 The system must B1 UC_Admin Business
have a protected
area for admin users
to manage products,
categories, orders
 and handle the
system’s settings.
7.0 The system shall B1 UC_SupportBot Business
have a chatbot for
users to interact
with so they can
contact support to
learn more about
using the system.
Table 2.4

2.1.8. Interface Requirements

User Interfaces
Standard users will use the web browser to use the system. You can simply browser it.
Hardware Interfaces
No high-level external hardware components are required by the system. The system
works on standard keyboard and mouse inputs.
Communications Interfaces
The web component/website is based on HTTPS.
2.2.10. High Level Use Case Diagram

Figure 2.3
2.2.11. Analysis Level Use Case Diagram

Figure 2.4

2.2.12. User Case Descriptions

ID 1
Name Authentication
Description This module lets user sign in and sign up using their personal
information.
Pre-Condition Idle condition in front of the laptop.
Post-Condition You are signed in to use the application
Dependency None
Scenario 1. User sees the sign in screen.
2. If user has already registered, user enters email and
password.
3. User clicks sign in.
4. If user is new, user presses sign up.
5. User enters personal details.
6. User clicks sign up.
7. User is registered and can now use the system.
Table 2.5
ID 2
Name Product Management
Description User has a module in the system where they can list all their books
for sale.
Pre-Condition User is signed in
Post-Condition Users can add, edit, delete, and view their products.
Dependency UC_Auth
Scenario 1. User presses user icon in top right corner.
2. User approaches the dashboard.
3. User clicks the products tab.
4. User creates a new product.
1. User can delete products.
2. User can edit products and update product info.
Table 2.6

ID 3
Name Search
Description User can search for any products using ISBN
Pre-Condition User is viewing the system in his web browser.
Post-Condition Users can search for books of their choice.
Dependency None
Scenario 1. User enters a search query into the search bar.
2. User can see search suggestions.
3. User clicks on the search suggestion of their choice to view
more details.
Table 2.7

ID 4
Name Shop
Description User has a shop module to look through all products by applying
filters of their choice.
Pre-Condition User is viewing the shop page
Post-Condition User has a shortlist of books of their choice.
Dependency None
Scenario 1. User clicks shop from the menu.
2. User can view all books.
3. User selects parameters from the right filter box.
4. User changes parameter to shortlist their selection.
Table 2.8

ID 5
Name Orders Management
Description User can use the e-commerce features of the system to record order
for their books.
Pre-Condition User is sign in
Post-Condition User places an order
Dependency UC_Auth
Scenario 1. User uses the “add to cart” option to select books to buy.
2. User can view the cart by selecting the option in top right
menu.
3. User finalizes an order and clicks checkout.
4. User order is recorded and now the user can view the status
of the order in their dashboard.
5. User can also check the orders they received if they are a
seller and have listed products.
6. User can change status of the order based on the status of
the ordered products in his inventory.
Table 2.9
ID 6
Name Administration
Description This section is exclusive for only admins of the system.
Pre-Condition User is signed in and has admin privileges.
Post-Condition User can view the admin section and can perform all the functions
listed.
Dependency UC_Auth
Scenario 1. User signs in
2. User can view the admin feature in his dashboard.
3. User can manage products.
 User can edit products.
 User can delete products.
 User can view details of all the products listed by all
users.
4. Use can manage other users.
5. User can view all orders.
6. User can list categories for the system.

Table 2.10

ID 7
Name Support Bot
Description User has an interactive bot that helps them through using the
system.
Pre-Condition User is viewing the application in the system.
Post-Condition User can ask, select action and make queries through the bot.
Dependency None
Table 2.11

2.3 Non-Functional
Attributes
 Performance The front-page load time must be no more than 5 seconds for users
that access the website using browser.
 Availability The system shall not be unavailable more than 1 hour per 1000 hours
of operation.
 Security The website shall identify all its users before allowing them to use its
capabilities.
 Maintainability The program must be designed in a way that new addition can be
done without changing the already developed structure.
 Portability Website must be access able by users from multiple operating
systems including Microsoft Windows, macOS, and Android.
 Reliability The system defect rate shall be less than 1 failure per 1000 hours of
operation.
Chapter 3: Software Requirement Specification and Design
Document (For Object Oriented Approach)
3.1. Introduction
Third deliverable is all about the software design. In the previous deliverable, analysis of
the system is completed. So, we understand the current situation of the problem domain.
Now we are ready to strive for a solution for the problem domain by using object-
oriented approach. Following artifacts must be included in the 3rd deliverable.
1. Domain Model
2. System Sequence Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. Design Class Diagram
6. State Chart Diagram
Now we discuss these artifacts one by one as follows:

3.2. Domain Model

Domain models represent the set of requirements that are common to systems within a
product line. There may be many domains, or areas of expertise, represented in a single
product line and a single domain may span multiple product lines. The requirements
represented in a domain model include:
• Definition of scope for the domain
• Information or objects
• Features or use cases, including factors that lead to variation.
• Operational/behavioral characteristics
A product line definition will describe the domains necessary to build systems in the
product line. A domain model is a business object model that focuses on "product,
deliverables, or events that are important to the business domain." A domain model is an
"incomplete" business model, in that it omits individual worker responsibilities. The point
of domain modeling is to provide "the big picture" of the interrelationships among
business entities in a complex organization. The domain model typically shows the major
business entities, and the relationships among the entities. A model that typically does not
include the responsibilities people carry is often referred to as a domain model. It also
provides a high-level description of the data that each entity provides. Domain modeling
plays a central role in understanding the current environment and planning for the future.
In domain model analysis of Online Secondhand Book Buying & Selling Portal, we
found the following entities and behavior.
 Figure 3.1

3.3. System Sequence Diagram

The UML system sequence diagram (SSD) illustrates events sequentially input from an
external source to the system. The SSD will define the system events and operations. A
characteristic of a sequence diagram is that time passes from top to bottom: the
interaction starts near the top of the diagram and ends at the bottom. System sequence
diagrams are a timeline drawing of an expanded use case. Events are related by time with
the top events occurring first. System events are the important items. Sequence diagrams
have certain benefits:
 You can easily see how tasks are distributed between components.
 You can identify patterns of interaction that make it difficult to update the
software.
In our project, we have drawn sequence diagram using functionality provided by our app.
This diagram shows how actors interact with the system. System Sequence Diagram of
“Online Secondhand Book Buying & Selling Portal” has following main actors named.
1. User
2. Visitor
3. Seller
4. Admin
5. REST API Service

3.4. Sequence Diagram:

Figure 3.2

3.5. Collaboration Diagram:

A collaboration diagram describes a pattern of interaction among objects; it shows the objects
participating in the interaction by their links to each other and the messages that they send to each
other. Collaboration diagrams are used to show how objects interact to perform the behavior of a
particular use case, or a part of a use case. Along with sequence diagrams, collaborations are used
by designers to define and clarify the roles of the objects that perform a particular flow of events
of a use case. They are the primary source of information used to determining class
responsibilities and interfaces. Unlike a sequence diagram, a collaboration diagram shows the
relationships among the objects. Sequence diagrams and collaboration diagrams express similar
information but show
it in different ways. Collaboration diagrams show the relationships among objects and are better
for understanding all the effects on a given object and for procedural design. Because of the
format of the collaboration diagram, they tend to better suit for analysis activities. Specifically,
they tend to be better suited to depicting simpler interactions of smaller numbers of
objects. As the number of objects and messages grows, the diagram SE- UOG - Project
Management Office Version: 1.0 Final Project Deliverable Guide Date: July 5,2021 ©
Department of Software Engineering becomes increasingly hard to read. In addition, it is
difficult to show additional descriptive information such as timing, decision points, or
other unstructured information that can be easily added to the notes in a sequence
diagram.
3.5.1. Contents of Collaboration Diagrams:
You can have objects and actor instances in collaboration diagrams, together with
links and messages describing how they are related and how they interact. The
diagram describes what takes place in the participating objects, in terms of how the
objects communicate by sending messages to one another. You can make a
collaboration diagram for each variant of a use case's flow of events.
3.5.2. Constructs of Collaboration Diagram:
Objects: An object is represented by an object symbol showing the name of the
object and its class underlined, separated by a colon: object name: class name You
can use objects in collaboration diagrams in the following ways: An object's class can
be unspecified. Normally you create a collaboration diagram with objects first and
specify their classes later. The objects can be unnamed, but you should name them if
you want to discriminate different objects of the same class. An object's class can
itself be represented in a collaboration diagram if it actively participates in the
collaboration.
Actors: Normally an actor instance occurs in the collaboration diagram, as the
invoker of the interaction. If you have several actor instances in the same diagram, try
keeping them in the periphery of the diagram.
Links: Links are defined as follows: A link is a relationship among objects across
which messages can be sent. In collaboration diagrams, a link is shown as a solid line
between two objects. An object interacts with, or navigates to, other objects through
its links to these objects. A link can be an instance of an association, or it can be
anonymous, meaning that its association is unspecified. Message flows are attached to
links.
Messages: CS- UOG - Project Management Office Version: 1.0 Final Project
Deliverable Guide Date: July 5,2021 © Department of Computer Science. A message
is a communication between objects that conveys information with the expectation
that activity will ensue. In collaboration diagrams, a message is shown as a labeled
arrow placed near a link. This means that the link is used to transport, or otherwise
implement the delivery of the message to the target object. The arrow points along the
link in the direction of the target object (the one that receives the message). The arrow
is labeled with the name of the message, and its parameters. The arrow may also be
labeled with
 a sequence number to show the sequence of the message in the overall interaction.
Sequence numbers are often used in collaboration diagrams, because they are the only
way of describing the relative sequencing of messages. A message can be unassigned,
meaning that its name is a temporary string that describes the overall meaning of the
message. You can later assign the message by specifying the operation of the
message's destination object. The specified operation will then replace the name of
the message.

3.6. Design Class Diagram:

 Figure 3.3

3.7. State Chart Diagram:

For some operations, the behavior of the operation depends upon the state the receiver
object is in. A state machine is a tool for describing the states the object can assume and
the events that cause the object to move from one state to another. State machines are
most useful for describing active classes. The use of state machines is particularly
important for defining the behavior. Each state transition event can be associated with an
operation. Depending on the object's state, the operation may have a different behavior;
the transition events describe how this occurs. The method description for the associated
operation should be updated with the state specific information, indicating, for each
relevant state, what the operation should do. States are often represented using attributes;
the state chart diagrams serve as input into the attribute identification step.

User Sign Up

User Login

Buyer Place Order

 Seller Product Management

Admin/Seller Order Management

Admin User Management

Figure 3.4
Chapter 4: User Interface Design
4.1. Introduction
Page elements should be visualized on paper before building them in the computer. Just
as you draw a site map to plan the site, use cartoons and storyboards to begin blocking
out the site’s appearance and navigational scheme.
 Site maps
 Storyboards
 Navigational maps
 Traceability Matrix

4.2. Site Maps

A site map's main benefit is to give user an overview of the site's areas in a single glance
by dedicating an entire page to a visualization of the information architecture. If designed
well, this overview can include several levels of hierarchy, and yet not be so big that
users lose their ability to grasp the map.
Figure 4.1
4.3. Story Board
A storyboard is a sequence of single images, each of which represents a distinct event or
narrative. It is also a visual representation of the script illustrating the interaction between
the citizen and the machine. It can also be imagined as a film in visual-outline form.
By using the local machine access the terminal or command prompt, run the server than
citizen will be able to navigate the website.

Figure 4.2

4.4. Navigational Maps

The next step is of navigational maps. In these maps, the storyboards are used as an input.
The different display buttons or action buttons show the navigation from one screen to
the other. In other words when one action button is pressed it would lead to other screens.
This path and navigation would be shown.
 Figure 4.3

4.5. Traceability Matrix

Following columns are involved in the trace-ability matrix.
Features:
 Orders
 Notifications
 Chatbot
 Feedback
Use Case:
 Users
 Admin
Chapter 5: Software Testing
5.1 Introduction
This deliverable is based on the IEEE standard of software testing i.e., IEEE
SOFTWARE TEST DOCUMENTATION Std 829-1998. This standard describes a set of
basic test documents that are associated with the dynamic aspects of software testing (i.e.,
the execution of procedures and code). The standard defines the purpose, outline, and
content of each basic document. While the documents described in the standard focus on
dynamic testing, several of them may be applicable to other testing activities (e.g., the
test plan and test incident report may be used for design and code reviews). This standard
may be applied to commercial, scientific, or military software that runs on any digital
computer. Applicability is not restricted by the size, complexity, or criticality of the
software. However, the standard does not specify any class of software to which it must
be applied. The standard addresses the documentation of both initial development testing
and the testing of subsequent software releases. For a software release, it may be applied
to all phases of testing from module testing through citizen acceptance. However, since
all the basic test documents may not be useful in each test phase, the documents to be
used in a phase are not specified. Each organization using the standard will need to
specify the classes of software to which it applies, and the specific documents required
for a test phase. The standard does not call for specific testing methodologies,
approaches, techniques, facilities, or tools, and does not specify the documentation of
their use. Additional test documentation may be required (e.g., code inspection checklists
and reports). The standard also does not imply or impose specific methodologies for
documentation control, configuration management, or quality assurance. Additional
documentation (e.g., a quality assurance plan) may be needed depending on the
methodologies used.
This chapter is the test plan of the mentioned project, Following are standard artifacts,
which must be included in this deliverable:
1. Test Plan
2. Test Design Specification
3. Test Case Specification
4. Test Procedure Specification
5. Test Item Transmittal Report
6. Test Log
7. Test Incident Report
8. Test Summary Report

5.2 Test Plan

Purpose
To prescribe the scope, approach, resources, and schedule of the testing activities. To
identify the items being tested, the features to be tested, the testing tasks to be
Outline
A test plan shall have the following structure:
• Test plan identifier
 • Introduction
• Test items
• Features to be tested
• Features not to be tested
• Approach
• Item pass/fail criteria
• Suspension criteria and resumption requirements
• Test deliverables
• Testing tasks
• Environmental needs
• Responsibilities
• Staffing and training needs
• Schedule
• Risks and contingencies
• Approvals
The sections shall be ordered in the specified sequence. Additional sections may be
included immediately prior to Approvals. If some or all the content of a section is in
another document, then a reference to that material may be listed in place of the
corresponding content. The referenced material must be attached to the test plan or
available to citizens of the plan. Details on the content of each section are contained in
the following sub-clauses
5.2.1. Test plan identifier

Specify the unique identifier assigned to this test plan

5.2.2. Introduction
Summarize the software items and software features to be tested. The need for each item
and its history may be included. References to the following documents, when they exist,
are required in the highest-level test plan:
Project authorization.
Project plan.
Quality assurance plan.
Configuration management plan.
Relevant policies.
Relevant standards.
In multilevel test plans, each lower-level plan must reference the next higher-level plan

5.2.3. Test items

Identify the test items including their version/revision level. Also specify characteristics
of their transmittal media that impact hardware requirements or indicate the need for
logical or physical transformations before testing can begin (e.g., programs must be
transferred from tape to disk). Supply references to the following test item documentation
if it exists:
 a) Requirement’s specification
b) Design specification
c) Citizen’s guide
d) Operations guide
e) Installation guide
Reference any incident reports relating to the test items. Items that are to be specifically
excluded from testing may be identified
5.2.4. Features to be tested.
Identify all software features and combinations of software features to be tested. Identify
the test design specification associated with each feature and each combination of
features.
5.2.5. Features not to be tested.
Identify all features and significant combinations of features that will not be tested and
the reasons
5.2.6. Approach
Describe the overall approach to testing. For each major group of features or feature
combinations, specify the approach that will ensure that these feature groups are
adequately tested. Specify the major activities, techniques, and tools that are used to test
the designated groups of features. The approach should be described in sufficient detail to
permit identification of the major testing tasks and estimation of the time required to do
each one. Specify the minimum degree of comprehensiveness desired. Identify the
techniques that will be used to judge the comprehensiveness of the testing effort (e.g.,
determining which statements have been executed at least once). Specify any additional
completion criteria (e.g., error frequency). The techniques to be used to trace
requirements should be specified. Identify significant constraints on testing such as test
item availability, testing resource availability, and deadlines.
5.2.7. Item pass/fail criteria.
Specify the criteria to be used to determine whether each test item has passed or failed
testing.

All major functionality of the Application should work as intended, the pass percentage
of test cases should be more than 95%, and there should not be any critical bugs.

5.2.8. Suspension criteria and resumption requirements

Specify the criteria used to suspend all or a portion of the testing activity on the test items
associated with this plan. Specify the testing activities that must be repeated when testing
is resumed
5.2.9. Test deliverables
The following document have:
a. Test plan.
 b. Test design specifications.
c. Test case specifications.
d. Test procedure specifications.
e. Test item transmittal reports.
f. Test logs.
g. Test incident reports.
h. Test summary reports.

5.2.10. Testing tasks

Identify the set of tasks necessary to prepare for and perform testing. Identify all inter
task dependencies and any special skills required.
5.2.11. Environmental needs
Specify both the necessary and desired properties of the test environment. This
specification should contain the physical characteristics of the facilities including the
hardware, the communications and system software, the mode of usage and any other
software or supplies needed to support the test. Also specify the level of security that
must be provided for the test facilities, system software, and proprietary components such
as software, data, and hardware. Identify special test tools needed.
Identify any other testing needs. Identify the source for all needs that are not currently
available to the test group.
5.2.12. Responsibilities
Identify the groups responsible for managing, designing, preparing, executing,
witnessing, checking, and resolving. In addition, identify the groups responsible for
providing the test items identified and the environmental needs identified. These groups
may include the developers, testers, operations staff, citizen representatives, technical
support staff, data administration staff, and quality support staff.

Testing Module Performed By

Test planning Maryam Tanveer
Test Specification Maryam Tanveer
Test Case Development Saman Ishtiaq
Test writing Warda Shabbir
Test Execution Saman Ishtiaq
Table 5.1

5.2.13. Staffing and training needs

Specify test-staffing needs by skill level. Identify training options for providing necessary
skills.
5.2.14. Schedule
Include test milestones identified in the software project schedule as well as all item
transmittal events.
Define any additional test milestones needed. Estimate the time required to do each
testing task Specify the schedule for each testing task and test milestone. For each testing
resource (i.e., facilities, tools, and staff), specify its periods of use.
5.2.15. Risks and contingencies
Identify the high-risk assumptions of the test plan. Specify contingency plans for each
(e.g., delayed delivery of test items might require increased night shift scheduling to meet
the delivery date).
5.2.16. Approvals

Specify the names and titles of all persons who must approve this plan. Provide space for
the signatures and dates.

5.3. Test Design Specification

5.3.1. Purpose
To prescribe the scope, approach, resources, and schedule of the testing activities. To
identify the items being tested, the features to be tested, the testing tasks to be performed,
the personnel responsible for each task, and the risks associated with this plan
5.3.2. Outline
A test plan shall have the following structure:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.
The sections shall be ordered in the specified sequence. Additional sections may be
included immediately prior to Approvals. If some or all the content of a section is in
another document, then a reference to that material may be listed in place of the
corresponding content. The referenced material must be attached to the test plan or
available to citizens of the plan. Details on the content of each section are contained in
the following sub- clauses.

5.4. Test plan identifier

Specify the unique identifier assigned to this test plan.
5.4.1. Introduction
Summarize the software items and software features to be tested. The need for each item
and its history may be included. References to the following documents, when they exist,
are required in the highest-level test plan:
a) Project authorization
b) Project plan
c) Quality assurance plan
d) Configuration management plan
e) Relevant policies
f) Relevant standards
In multilevel test plans, each lower-level plan must reference the next higher-level plan.

5.4.2. Test items

Identify the test items including their version/revision level. Also specify characteristics
of their transmittal media that impact hardware requirements or indicate the need for
logical or physical transformations before testing can begin (e.g., programs must be
transferred from tape to disk). Supply references to the following test item documentation
if it exists:
a) Requirement’s specification
b) Design specification
c) Citizen guide
d) Operations guide
e) Installation guide

Reference any incident reports relating to the test items. Items that are to be specifically
excluded from testing may be identified.
5.4.3. Features to be tested
Identify all software features and combinations of software features to be tested. Identify
the test design specification associated with each feature and each combination of
features.

5.4.4. Features not to be tested

Identify all features and significant combinations of features that will not be tested and
the reasons.

5.4.5. Approach
Describe the overall approach to testing. For each major group of features or feature
combinations, specify the approach that will ensure that these feature groups are
adequately tested. Specify the major activities, techniques, and tools that are used to test
the designated groups of features. The approach should be described in sufficient detail to
permit identification of the major testing tasks and estimation of the time required to do
each one. Specify the minimum degree of comprehensiveness desired. Identify the
techniques that will be used to judge the comprehensiveness of the testing effort (e.g.,
determining which statements have been executed at least once). Specify any additional
completion criteria (e.g., error frequency). The techniques to be used to trace
requirements should be specified. Identify significant constraints on testing such as test
item availability, testing resource availability, and deadlines.

5.4.6. Item pass/fail criteria

Specify the criteria to be used to determine whether each test item has passed or failed
testing.

5.4.7. Suspension criteria and resumption requirements

Specify the criteria used to suspend all or a portion of the testing activity on the test items
associated with this plan. Specify the testing activities that must be repeated when testing
is resumed.

5.4.8. Test deliverables

Identify the deliverable documents. The following documents should be included:
a) Test plan
b) Test design specifications
c) Test case specifications
d) Test procedure specifications
e) Test item transmittal reports
f) Test logs
g) Test incident reports
 h) Test summary reports
Test input data and test output data should be identified as deliverables. Test tools (e.g.,
module drivers and stubs) may also be included.

5.4.9. Testing tasks

Identify the set of tasks necessary to prepare for and perform testing. Identify all inter
task dependencies and any special skills required.

5.4.10. Environmental needs

Specify both the necessary and desired properties of the test environment. This
specification should contain the physical characteristics of the facilities including the
hardware, the communications and system software, the mode of usage (e.g., stand-
alone), and any other software or supplies needed to support the test. Also specify the
level of security that must be provided for the test facilities, system software, and
proprietary components such as software, data, and hardware. Identify special test tools
needed. Identify any other testing needs (e.g., publications or office space). Identify the
source for all needs that are not currently available to the test group.

5.4.11. Responsibilities
Identify the groups responsible for managing, designing, preparing, executing,
witnessing, checking, and resolving. In addition, identify the groups responsible for
providing the test items identified and the environmental needs identified. These groups
may include the developers, testers, operations staff, citizen representatives, technical
support staff, data administration staff, and quality support staff.

5.4.12. Staffing and training needs

Specify test-staffing needs by skill level. Identify training options for providing
necessary skills.

5.4.13. Schedule
Include test milestones identified in the software project schedule as well as all item
transmittal events. Define any additional test milestones needed. Estimate the time
required to do each testing task. Specify the schedule for each testing task and test
milestone. For each testing resource (i.e., facilities, tools, and staff), specify its periods of
use.

5.4.14. Risks and contingencies

Identify the high-risk assumptions of the test plan. Specify contingency plans for each.
5.4.15. Approvals
Specify the names and titles of all persons who must approve this plan. Provide space for
the signatures and dates.

5.5. Test procedure specification

5.5.1. Test case specification identifier
Specify the unique identifier assigned to this test case specification.

5.5.2. Test items

Identify and briefly describe the items and features to be exercised by this test case. For
each item, consider supplying references to the following test item documentation:
 Connection Successful with database
 Data Searched Successfully
 Empty field error handling
 Data Retrieved from database
 Data displayed correctly

5.5.3. Input specifications

Specify each input required to execute the test case. Some of the inputs will be specified
by value (with tolerances where appropriate), while others, such as constant tables or
transaction files, will be specified by name. Identify all appropriate databases, files,
terminal messages, memory resident areas, and values passed by the operating system.
Specify all required relationships between inputs (e.g., timing).

5.5.4. Output specifications

Specify all the outputs and features (e.g., response time) required of the test items.
Provide the exact value (with tolerances where appropriate) for each required output or
feature.

5.6. Environmental needs

5.6.1. Hardware
Specify the characteristics and configurations of the hardware required to execute this test
case.

5.6.2. Software
Specify the system and application software required to execute this test case. This may
include system software such as operating systems, compilers, simulators, and test tools.
In addition, the test item may interact with application software.
5.6.3. Other
Specify any other requirements such as unique facility needs or specially trained personnel.

5.6.4. Special procedural requirements

Describe any special constraints on the test procedures that execute this test case. These
constraints may involve special set up, operator intervention, output determination
procedures, and special wrap up.

5.6.5. Inter case dependencies

List the identifiers of test cases that must be executed prior to this test case. Summarize
the nature of the dependencies.

5.6.6. Test procedure specification

5.6.6.1. Purpose
To specify the steps for executing a set of test cases or, more generally, the steps used to
analyze a software item to evaluate a set of features.

5.6.6.2. Outline
Following are the contents of test procedure.
Specification:
a) Test procedure specification identifier
b) Purpose

5.6.7. Test procedure specification identifier

The identifier for the test procedure specification is “OBRP”.
5.6.8. Purpose
To define a test procedure specified by a test design specification
5.6.9. Test item transmittal report
5.6.9.1. Purpose

Test items identification being transmitted for testing which includes the person
responsible for each item, its physical location, and its status.

5.6.9.2. Outline
A test item transmittal report shall have the following structure:
a) Transmittal report identifier
 b) Transmitted items
c) Location
d) Status

5.7. Test log

5.7.1. Purpose
To provide a sequential record of relevant details about the execution of tests.
5.7.2. Outline
A test log shall have the following structure:
a) Test log identifier
b) Description

Test log - 1

Test log identifier T-1

Description Authentication and User Features

Activity and Event entries Date: 05-06-2021

Performed by: Warda Shabbir

Activity: Successful sign in, registration,

and system access.

 Shop Features
 Order Placement
 Order Status Tracking

Table 5.2

Test Log - 2

Test log identifier T-2

 Description Buyer Features

Activity and Event entries Date:05-06-2020

Performed by: Saman Ishtiaq

Activity:

 Product Management
 Order Management
 Profile Management

Table 5.3

Test Log - 3

Test log identifier T-3

Description Admin Features

Activity and Event entries Date: 08-06-2021

Author: Warda Shabbir

Activity:

 Product Management
 Order Management
 Profile Management
 Users Management

Table 5.4

Test Log - Z
 Test log identifier T-Z

Description Overall Systems Check

Activity and Event entries Date: 10-06-2021

Author: Maryam Tanveer

Activity:

 Product Management
 Order Management
 User Management
 Order Status Tracking
 Order Sales Tracking

Table 5.5

5.8. Test incident report

5.8.1. Purpose
To document any event that occurs during the testing process that requires investigation.

5.8.2. Outline
A test incident report shall have the following structure:
a) Test incident report identifier
b) Summary
c) Incident description
d) Impact

The sections shall be ordered in the specified sequence. Additional sections may be
included at the end. If some or all the content of a section is in another document, then a
reference to that material may be listed in place of the corresponding content. The
referenced material must be attached to the test incident report or available to citizens of
the incident report. Details on the content of each section are contained in the following
sub clauses.
5.9. Test summary report
5.9.1. Purpose
To summarize the results of the designated testing activities and to provide evaluations
based on these results.

5.9.2. Outline
A test summary report shall have the following structure:
a) Test summary report identifier
b) Summary
c) Variances
d) Comprehensive assessment
e) Summary of results
f) Evaluation
g) Summary of activities
h) Approvals

The sections shall be ordered in the specified sequence. Additional sections may be
included just prior to Approvals. If some or all the content of a section is in another
document, then a reference to that material may be listed in place of the corresponding
content. The referenced material must be attached to the test summary report or available
to citizens of the summary report. Details on the content of each section are contained in
the following sub clauses

Test Scenario ID Calibration Test case ID Calibration

Test case User Dashboard Test priority High

description
Shop Features

Pre-Requisite Logged In Post -Requisite NA

Table 5.6
Sr. Action Inputs Expected Actual Test Test Test
No output
output Tool Result comments

1 User Logged User can View Bro Pass Saman Ishtiaq

Dashboard In User place System wser
order. Logged 30/5/2021
Shop in 02:55 PM]:
Features Can
browse Successful
system
logged in

Table 5.7
Chapter 6: User Manual
6.1 General information
“OBRP” is basically a web-based application that enables user to sell and buy
secondhand books. It allows user to update, delete his/her books. It allows user the
facility of order management. It allows user to track his/her order. The user can view the
status of the order.
6.1.1 System Overview
OBRP is basically developed to help the students who cannot buy expensive books. The
students can also earn by selling their old books. First, they must sign up to uploads
books and their description, price etc. the user can track their orders and submit their
feedback.

6.2 System summary

The developed website supports any Internet browser.

6.2.1 System Configuration

The admin will access the website through any Internet browser.
6.2.2 User Access Levels
The user can access the website any time after “Signing Up” first and then “Sign in” later.
6.2.3 Contingencies
In case of loss of data connection, the submitted order will not be submitted successfully
if the user is already signed in.

6.3 Getting started

Open the website through any internet browser.

6.3.1 Usage Guide

To use the website, make sure your data connection/Wi-Fi is on.

6.3.2 Logging In
Create account on the website by using email and password and then clicking “Sign up”
button. After signup, website will take user to sign in/login screen of website. User can
now login by providing email and password that was used while signing up.
 Figure 6.1

Figure 6.2

6.4 Using the System

The first screen that comes after logging in is home screen. It displays the featured books,
chatbot, cart etc.
6.4.1. Home Screen
By default, the first screen that will be displayed is home screen. Screen contains different
modules including search bar, cart, order status books, chatbot.
Figure 6.3
6.4.2 Chatbot
If a user still wants to ask something. He can communicate our chatbot or call us. This
chatbot will guide to sell your old books, finding a book and helps to purchase a book.

Figure 6.4
 Figure 6.5

6.4.3 Root user Dashboard

Figure 6.6
6.4.4 Admin Dashboard
Admin can sell and purchase books

Figure 6.7

6.4.5 User Dashboard

User can only purchase books.

Figure 6.8
6.4.6 Sell page

Figure 6.9

6.4.7 Products Page

Figure 6.10
6.4.8 View Product Page

Figure 6.11

6.4.9 Cart

Figure 6.12
6.4.10 Checkout

Figure 6.13