Online Book Shopping Application: Software Requirements Specification

This document presents a Software Requirements Specification (SRS) for an online book shopping application. It outlines the project's overview, including definitions, system objectives, stakeholders, and acceptance criteria. The report details the overall functionalities, user characteristics (administrator, customer, vendor), assumptions, and system context. It further elaborates on functional and non-functional requirements, software development life cycle, database requirements, and quality requirements. Use cases, including login and other functionalities, are described. The document also includes diagrams like use case diagrams, context diagrams, class diagrams, activity diagrams, and sequence diagrams, and concludes with references and sign-off sections. This SRS serves as a comprehensive guide for the development of the online book shopping application, ensuring clarity and consistency between the client and the development team.

Online Book Shopping Software Requirements Specification
Software Requirements Specification
Project name: Online Book Shopping
Application name:
Customer:
Version:0.0
Date:........
Status: Draft/final
Page 1 of 35

Online Book Shopping Software Requirements Specification
For more information Customer contact
Name: .......... Name: .........
Project Manager Project Sponsor
e-mail: e-mail:
Telephone: Telephone:........................
Revision History:
Version Date Author(s) Change Description
0.1 First draft.
Page 2 of 35

Online Book Shopping Software Requirements Specification
Table of Contents
Contents
1 Project overview...................................................................................................................................... 5
1.1 Definitions & Acronyms..................................................................................................................... 5
1.2 Referenced Documents from other sources or Notes.......................................................................5
1.3 Name of the Project.......................................................................................................................... 5
1.4 System Overview.............................................................................................................................. 5
1.5 System Objectives............................................................................................................................ 6
1.6 Support............................................................................................................................................. 6
1.7 Stakeholders..................................................................................................................................... 7
1.8 System Context................................................................................................................................ 7
1.9 Acceptance Criteria.......................................................................................................................... 7
1.10 Evaluating Success........................................................................................................................ 7
2 Overall Description of the Project............................................................................................................ 7
2.1 Overall Functionalities of the Product............................................................................................... 7
2.2 User Characteristics......................................................................................................................... 8
2.3 Assumptions and Dependencies...................................................................................................... 9
2.3 Viewpoint of the Product................................................................................................................... 9
2.4.1 Analysis of User Interfacing........................................................................................................ 9
2.4.2 System Constraints.................................................................................................................. 13
2.4.3 Operations................................................................................................................................ 14
2.5 User Base....................................................................................................................................... 14
2.6 General Design Constraints............................................................................................................ 14
2.7 Project Feasibility............................................................................................................................ 14
3 Requirements........................................................................................................................................ 15
3.1 Functional Requirements.......................................................................................................... 15
3.2 Non-functional Requirements................................................................................................... 22
3.3 Software Development Life Cycle................................................................................................... 22
3.3.1 Site Map............................................................................................................................... 25
3.4 Database Requirements................................................................................................................. 26
3.4.1 Entity-Relationship Diagram..................................................................................................... 26
3.8 Extra Quality Requirements...................................................................................................... 27
3.8.1 Requirement Verification Process............................................................................................ 27
3.8.2 Software Testing and Acceptance Criteria...............................................................................28
4 References........................................................................................................................................ 29
5 Appendixes....................................................................................................................................... 31
4.1 Appendix A – Use Case diagram.................................................................................................... 31
4.2 Appendix B - Context diagram........................................................................................................ 31
4.3 Appendix C - Class diagram........................................................................................................... 32
4.4 Appendix D – Activity Diagram....................................................................................................... 33
4.4 Appendix D - Sequence Diagram................................................................................................... 34
Page 3 of 35

Online Book Shopping Software Requirements Specification
5 Sign-off.................................................................................................................................................. 35
5.1 Client Sign-off................................................................................................................................. 35
5.2 Team Sign Off................................................................................................................................. 35
Page 4 of 35

Online Book Shopping Software Requirements Specification
1 Project overview
The design overview of the proposed project is provided in this segment.
.
1.1 Definitions & Acronyms
To make easy understanding of this SRS document for both development team
members and client or end user, they can refer this section. It consists of technical short form
term throughout this document.
Terms Meaning
Admin Administrator
Client End user of the proposed system
DFD Data Flow Diagram
SDD Software Design Document
SPMP Software Project Management Plan Document
SRS Software Requirements Specification
PM Project Manager
1.2 Referenced Documents from other sources or Notes
Serial Number of the Document/
Taken From/ URL of the source
Description about the Reference/Name of the source
1.3 Name of the Project
Online Book Shopping
1.4 System Overview
The SRS document (Software Requirements Specification) is intended to report and portray the
understanding between the client and the software engineer with respect to the detail of the product
item asked. Its main role is to give an unmistakable and enlightening "proclamation of client
necessities" that can be utilized as a source of perspective in advance improvement of the product
framework. This record is broken into various segments used to sensibly isolate the product
prerequisites into effortlessly referenced sections.
Page 5 of 35

Online Book Shopping Software Requirements Specification
This Software Requirements Specification (SRS Document) expects to depict the Attributes,
External Interfaces, functionality and Design Constraints forced on Implementation and execution of
the programming framework depicted all through whatever remains of the record. All through the
depiction of the product framework, the dialect and phrasing utilized ought to unambiguous and
predictable all through the report.
1.5 System Objectives
Fundamental objective is to make the SRS document for online book shopping and it empower
the database segment for this record.
 This task is additionally gone for determining the product prerequisites to be created and it can
be connected to support the book shopping.
 It additionally used to make the particular prerequisites or model to characterizing the product
necessity record for book shopping and this undertaking is does not recognize the a particular strategy
and classification or device for setting up the product prerequisite archive.
 This document is additionally dealt with the book buy and deals as to accelerating and
rearranging the way toward obtaining, choice and requesting the books for clients and in addition
dealing with a client database and item database for book shop proprietors.
 The product framework is being created for a client inspired by offering books by means of the
Internet. This framework is intended to provide automatic support for the way toward putting books
available and to be purchased on the Internet and encouraging the real deal.
 This framework is to a great extent cross-stage and is accessible to everybody.
 The framework will be keep running on a local server with every client having a remote UI
through a web program to interface with it.
1.6 Support
To maintain the application, Administrator should support this application. They play
main role in organizing the database of user’s credentials and monitor the process of shopping
from ordering to delivering with updated database [1].
1.7 Stakeholders
Clients: Customers are assuming principle part in this application and who purchases the items from
this site. Merchants additionally utilizing this application to offer their item. This application centres on
creating improved shopping site for clients [2].
Administrator: The individual who keeps up the private records of clients and sellers
Page 6 of 35

Online Book Shopping Software Requirements Specification
Super Administrator: The individual who can do endorsements for merchants and overseeing
Administrators.
Product Development Team: The improvement group builds up the application in highlights centred
and settling the issues when it meets any issue of working.
1.8 System Context
The proposed framework will take a report at web server. With the goal that this shopping
application can keep running on any program and work by client to purchase book items [3].
1.9 Acceptance Criteria
Subsequent to completing the unit testing, framework testing and client acknowledgment
testing, this undertaking will be acknowledged in view of the Severity 1 and Severity 2. These are given
underneath.
Severity 1: The issue will be settled by distinguishing the issue. In the event that it proceeds in excess of
one functionalities or on the off chance that it intrudes on the buying and instalment process, the group
will refactor the code without influencing the noteworthy capacities.
Severity 2: If the issue influences the client's task, the group will do further and move this venture into
the nearby out period of undertaking [4].
1.10 Evaluating Success
The achievement will be assessed in light of following criteria:
1. The task passes the criteria in client acknowledgment testing
2. Client's Feedback about their shopping background
2 Overall Description of the Project
2.1 Overall Functionalities of the Product
This application lets in sellers to establishment online book shops, clients to peruse through
the stores, and the overseer to endorse and dismiss demands for seal punishing new book shops and
keep up arrangements of keep classifications. Likewise the designer is planning a web purchasing site
page to control the different books in shop and furthermore help customers to buy them on-line
without venturing to every part of the store physical [5]. The web based shopping framework will utilize
the web as the main technique for elevating items to its clients.
Display tests
Page 7 of 35

Online Book Shopping Software Requirements Specification
The web architecture in imperative in this application. It ought to be more alluring and
intuitive one for clients. The outline and show highlights will be tried [6].
Record information
Putting away the data about clients and sellers is something critical in this venture, for
example, their qualification data, requested item data et cetera.
Reviews
Dissecting the web logs and occasion logs is important to think about how the client carry on
towards this site as opposed to others. It enhances the element of the framework [7].
Organization area
Dealing with the whole book shopping process, approving client's validation data, manage
merchants are basic zones of organization.
Download Data
In the organization territory, they can download the data about client's enrolment and
instalment detail. It is required for the proposed framework.
2.2 User Characteristics
The proposed framework comprises of three kinds of clients that are demonstrated as follows.
1. Administrator:
The administrator keeps up all back end work, for example, recording information and keeping the
record as a refreshed. He keeps up the two clients and merchants.
2. Customer:
The purchasers are the essential clients of this application. The guests are the auxiliary clients of this
application.
3. Vendor:
The Vendors book their shop to offer their items through site. He will settle the offer
and rebates on items
2.3 Assumptions and Dependencies
The presumptions are noted below.
• The proprietor and administrator can't be a client.
• The administrator accounts username and secret key might be hard coded.
• There is no requirement for anybody to have the capacity to arrange in excess of a one
duplicate of a book in a solitary exchange.
Page 8 of 35

Online Book Shopping Software Requirements Specification
• Any client can't alter their record data.
2.3 Viewpoint of the Product
2.4.1 Analysis of User Interfacing
2.4.1.1 Use Cases
A use case addresses a unit of accommodation gave by the structure. The vital clarification
behind the use case graph is to help change clusters picture the profitable necessities of a framework,
including the relationship of "performing experts" (individuals who will collaborate with the structure)
to basic approach, and moreover the relationship among various utilize cases. Utilize case outlines
everything considered show social events of use cases — either all use cases for the entire framework,
or a breakout of a specific party of use cases with related accommodation (e.g., all security affiliation
related use cases). To display a use case on plot, pull in an oval the point of convergence of the outline
and put the name of the use case in the purpose of joining of, or underneath, the oval. To draw an on-
screen character (showing a framework client) on a usage case graph, we pull in a stick individual to the
opposite side or right of the blueprint (and just in the event that we're thinking about, a few people
draw prettier stick individuals than others).
The reason behind this chart is to demonstrate how request will cooperate with online book
shopping and guide out the basic handiness of the framework. The going with is a synopsis of the parts
that you will find in the chart on the going with page too what is joined into the usage case plans that
take after.
Actors
Appeared in the chart as stick figures with a name underneath. They address parts that will be
plainly teaming up with the framework.
Extends
Lines that interface the performing specialists with the varying Use Cases.
Collaboration
These demonstrate that there is some sort of direct participation between the performing
skilled worker and that particular esteem.
Use Cases
Oval shapes that have their names in the centre. These address arrange helpfulness inside the
system that must be executed.
Includes
Page 9 of 35

Online Book Shopping Software Requirements Specification
Contaca ted lines named "<<include>>" that accomplice two utilize cases and have a shock
pointing towards one. This surmises the use case without the jar approaches the handiness of the use
case with the shock.
Touched lines named "<<include>>" that partner two use cases and have a jolt pointing towards one.
This infers the use case without the jolt approaches the handiness of the usage case with the jolt.
Use Case Template
Depicts the basic handiness and features of every use case and the can be found in the pages
following the use case chart.
The System Boundary
The broad rectangle that contains the Use Cases. Everything inside the rectangle is the thing
that the system is responsible for executing
Cross Ref
A field in the usage case arranges that states which one of the main necessities that particular
use case satisfies.
Type
A field in the usage case arrange that states paying little heed to whether the use case is clearly
connected with by an on-screen character (Primary) or not (Secondary) and furthermore paying little
respect to whether it is central to having a working structure.
Use Cases
A field in the use case designs that state which other use cases must be executed before that
particular use case.
Use Case 1: Login to the Application
Actors: Administrator or Manager,
Description: Initiated when a customer attempts an action that is constrained. The customer is then
incited to enter in their username and mystery word remembering the ultimate objective to proceed.
Excludes: None
Includes: None
Use Case 2: Logout of the Application
Actors: Manager or Administrator, Client or Customer and System
Primary and fundamental Description: The customer or director will have the decision to logout and if
that customer is sit out of gear for a given measure of time then that customer should be logged out by
the structure thus.
Excludes: None
Page 10 of 35

Online Book Shopping Software Requirements Specification
Includes: None
Use Cases: User almost certainly completed the Log In use case.
2.4.1.2 Context Diagrams
The Context Diagram displays the structure under thought as a particular surprising state process and
after that exhibits the relationship that the framework has with other outer segments (structures, true
blue get-togethers, outside information stores, and so on. Another name for a Context Diagram is a
Context-Level Data-Flow Diagram or a Level-0 Data Flow Diagram. Since a Context Diagram is a
particular contrast in Data-Flow Diagram, seeing to some degree about Data-Flow Diagrams can be
beneficial.
A Data-Flow Diagram (DFD) is a graphical impression of the development of information
through a data framework. DFDs are one of the three central parts of the oversaw structures
examination and structure framework (SSADM). A DFD is process driven and plots 4 focal parts [23].
• Procedures (circle)
• Outside Entities (square shape)
• Information Stores (two level, parallel lines or a piece of the time and circle)
• Information Flows (twisted or straight line with sharpened stone displaying stream course)
Each DFD may indicate distinctive philosophy with information spilling into and out of each
framework. In the event that there is a need to exhibit more detail inside a specific structure, the
framework is disintegrated into various all the more little methods in a lower level DFD. In like way, the
Content Diagram or Context-Level DFD is implied a "Level-0 DFD" while the running with level of decay
is named a "Level-1 DFD", the running with is named a "Level-2 DFD", and so on. Setting Diagrams and
Data-Flow Diagrams were made for structures examination and plan. Regardless, almost as other
examination contraptions they have been utilized for different purposes. For instance, they can in like
way be utilized to get and offer the affiliations and stream of information between business diagrams.
Thusly, they ought not to be obliged to structures examination [22].
2.4.1.3 Class Diagrams
The explanation behind this graph is to demonstrate how challenges inside the structure will
speak in light of each other keeping the ultimate objective to achieve the helpfulness required by the
Use Case plot. The accompanying is an once-over of what you will discover in the diagram itself and
what's more the class depictions that take after.
Use Cases: None
Use Case: Logout
Actors: Manager or Administrator, Customer, Application System
Page 11 of 35

Online Book Shopping Software Requirements Specification
Description: The client or director will have the choice to logout and if that client is latent for a given
measure of time then that client ought to be logged out by the framework naturally.
Use Cases: User more likely than not finished the Log In utilize case.
2.4.1.4 Activity Diagram
Activity diagrams display the procedural development of control among no beneath class
contraptions even as managing an Activity. Advance diagrams can be used to uncover more noteworthy
substantive blend venture strategy at the considerable unit level, or to show low-level internal
greatness works out [21]. To the degree I can advise, advance diagrams are best used to demonstrate
additional fundamental blend lodging, as an example, how the association is at remaining getting
nearby business, or how it should need to work together. That is by means of feelings of change
diagrams are "less exact" in appearance, segregated from design structures, and venture confined
individuals have a tendency to appreciate them the majority of the all the more suddenly [20].
The Activity characterize's documentation set takes after that used as to some recognition a
country plot diagram. Like a country chart diagram, the other arrange begins with a strong float related
with the basic side interest. The advance is appeared by methods for drawing a rectangular shape with
balanced edges, encasing the leisure activity's name. Brandishing occasions might be connected with
one of a kind wearing exercises through trade follows, or to inclination shows that interface undeniable
games checked by methods for conditions of the decision factor. Activities that end the exhibited
system are related with an end factor (moreover as in a kingdom chart plot). Practically, the physical
amusements might be assembled into swim ways that are connected to display the demand that truly
performs out the movement.
2.4.1.5 Sequence Diagram
Arrangement charts exhibit a point by point stream for a specific use case or even basically part
of a specific use case. They are generally undeniable; they exhibit the calls between the assorted
challenges in their sequence and can show up, at an unmistakable level, particular calls to different
things [19].
A sequence diagram has estimations: The vertical estimation acclaimed the course of
development of messages/procures the time plan that they show up; the even estimation
demonstrates the request examples to which the messages are sent.
A sequence graph is incredibly simple to pull in. Over the most quickened reason for our
diagram, perceive the class occurrences (things) with the guide of putting each class event internal a
case (see observe four). Inside the compartment, put the wonderfulness case call and class name
detached by a space/colon/space " : ". In the event that a class occasion builds up an association on
Page 12 of 35