SRS DOCUMENTATION

FOR ONLINE BOOK

STORE
TABLE OF CONTENTS

1 INTRODUCTION
1.1 Purpose
1.2 Product Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 References

2 OVERALL DDESCRIPTION
2.1 Product Perspective
2.2 Product Functions
2.3 User classes and characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies

3 EXTERNAL INTERFACE REQUIREMENTS

3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communication Interfaces

4 SYSTEM FEATURES
4.1 Authentication
4.2 Outpass Details
4.3 Use case Diagram
4.4 Class Diagram

5 NON- FUNCTIONAL REQUIRENTS

5.1.1 Performance
5.1.2 Reliability
5.1.3 Availability
5.1.4 Security
5.1.5 Maintainability
5.1.6 Portability
5.2 Design Constraints
5.3 Logical Database Requirements
5.4 Other Requirements

6 ANALYSIS MODEL
6.1 Sequence Diagram
6.2 Dataflow Diagram
1.Introduction

1.1. Purpose
The purpose of this Software Requirements Specifications (SRS) is to fully document
the specifications and requirements for the Online Bookstore. The audience of this SRS will
be the clients who want the software to be built and the technical professionals developing
the software.

1.2. Product Scope

The objective of this project is to create and implement a website for the bookstore.
The website will be used primarily by the students. The website will allow users to create and
maintain individual secured accounts, search the Bookstore database for textbooks, and make
secured online credit card purchases. Users will also be able to contact site administrators.
The website makes purchasing textbooks quicker, easier, and more convenient.

1.3. Definitions, Acronyms, and Abbreviations

This document uses the following definitions, acronyms, and abbreviations:
 SRS- Software Requirement Specification
 OBS-Online Book Store
 Customer-A person who is purchasing the book
 Administrator/Admin- User having all the privileges to operate OBS
 Staff- Staff of the university operating URS and coordinating the
admissions

1.4. References
The following material was used in creating this document:
• IEEE Std 830-1998, IEEE Recommended Practice for Software
Requirements Specifications.

2. Overall Description

2.1. Product Perspective

This product is an entirely new product. It is not a component of a larger system. The
BSU online bookstore system will interact with a credit card processing system in order to
process purchases from the website. The system will also interact with the Bookstore’s
Inventory database, which records the quantity of books available for sale in the inventory.

2.2. Product Functions

The Online Bookstore will provide a number of functions, each is listed below.
• Maintain data associated with the inventory (a collection of books).
• A book has a title, author and price.
• The inventory also keep track of the stock/quantity of each book.
• Maintain records for many customers.
• A customer can be either a member or non-member.
•A customer has a username (unique across all users), password (no restrictions),
email address (no restrictions), and postal address (unverified).
• Anyone may sign up for a customer account.

• Allow any customer to become a member.

• Show a listing of available books.

• Books are to be displayed in ascending alphabetical order by title.
• Each book will list the following from left to right.
• Title.
• Author.
• Price.
• Allow customers and managers to log in and out of the system.

• Shopping cart.
• Anyone is able to add one or more books to the shopping cart.

• Checkout.
• Checkout is only available to logged-in customers. A user that is not logged in as a
customer is given a chance to log in.
• Collect a 16-digit credit card number from the customer.
• Log/record the transaction.

• Allow manager to specify a stop-order for a book.

• Each book has its own stop-order status – either on or off. Details of its use are involved in
the following feature.
• Notify manager when books need to be reordered.
• When the quantity a book falls below a threshold, the manager is notified that the
book needs to be reordered.
• One exception is if the manager has already specified a stop-order for this book.
• Every book must either have stop-order enabled or disabled.

• Allow manager to update stock quantities.

• Allow manager to change any book's price.
• Allow manager to view transaction logs

2.3 User Classes and Characteristics

The typical Online Bookstore user is simply anyone that has access to the Internet and
a web browser. It is assumed that the user is familiar enough with a computer to operate the
browser, keyboard and mouse and is capable of browsing to, from and within simple
websites.

2.4 General Constraints

Security is not a concern for this system. The database may store passwords in plain
text and there doesn't need to be a password recovery feature nor lockout after numerous
invalid login attempts. As such, the system may not work correctly in cases when security is a
concern. These cases include those listed above in addition to lack of an encrypted
connection when sending credit card information and forcing users to use “strong”
passwords. A strong password is a password that meets a number of conditions that are set in
place so that user's passwords cannot be easily guessed by an attacker. Generally, these rules
include ensuring that the password contains a sufficient number of characters and contains
not only lowercase letters but also capitals, numbers, and in some cases, symbols.

2.5 Assumptions and Dependencies

Since the Online Bookstore is only accessible through the internet, it is assumed that
the end user has a connection to the internet. It is also assumed that the user has a web
browser able to display the website.
Client:
We have assumed that all of the computer systems are in proper working condition
and that the user is capable of operating these system's basic functions including but not
limited to being able to power on the system, login and open browsers, and navigate the
browser to the address of the website.
Provider:
We have assumed that the Online Bookstore will be running on a properly working
web server and database system with an Internet connection that allows this system to
perform all communications with clients.
Assumptions:
• The manager account’s username and password maybe hard coded.
• The manager cannot be a customer.
• Any user cannot edit their account information

3. External Interface Requirements

3.1. User Interfaces:

The system will provide the ability for students and faculty to access the BSU Online
Bookstore via the Internet. There will be three different user interfaces that will accompany
this website: one for the students, the faculty, and the administrators.
• Students will be allowed to search database without having to login, however,
they must login in order to perform any other transaction. These other transaction will include
reserving and purchasing textbooks, or viewing and changing their online account.
 • The Faculty must be required to login at all times in order to perform any
transaction. Once logged in the faculty member will be able to update required textbook
information per the course(s) they instruct, and make any changes to their personal online
account.
• Administrators will be required to login at all times. However, they will
have limit access via the web-interface only being able to pull predefined reports. The
administrators will have to logon to a host machine inside the BSU Online Bookstore
network in order to build reports and ensure backups are running.

3.2. Hardware Interfaces:

There are no special hardware interface requirements.

3.3. Software Interfaces:

There are no special software interface requirements.

3.4. Communication Interfaces:

There are no special communication interfaces requirements.

4. System Features

4.1 Authentication
1. The system shall allow a registered user to log-in to their account.
2. The system shall require a username and password from the user.
3. The system will verify the username and password, and the user will be
considered “logged-in”.

4.2 Use case Diagram

A UML use case diagram is the principal form of system/software specifications for
an undeveloped computer program. Use cases specify the expected behaviour (what), and not
the exact method of making it happen (how). Use cases once specified can be denoted by
both textual and visual representation (i.e. use case diagram). A key concept of use case
modelling is that it helps us design a system from the end user's perspective. It is an effective
technique for communicating system behaviour in the user's terms by specifying all
externally visible system behaviour.
4.3 Class Diagram
The class diagram is a static diagram. It represents the static view of an application.
The class diagram is not only used for visualizing, describing, and documenting different
aspects of a system but also for constructing executable code of the software application. The
class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. Since they're the only UML diagrams that can be translated directly
to object-oriented languages, class diagrams are frequently utilised in the designing of object-
oriented systems. The class diagram shows a collection of classes, interfaces, associations,
collaborations, and constraints.
4.4 Activity Diagram
Another essential diagram in UML for describing the dynamic features of the system
is the activity diagram. It is essentially a flowchart that represents the transition from one
activity to another. The action can be defined as a system operation. The control flow is
directed from one activity to the next. This flow might be linear, branching, or parallel in
nature.
4.5 State Chart Diagram
A state-chart diagram depicts the various modes of an element in a system. The stages
are unique to a system component or item. A state machine is depicted by a Statechart
diagram. A state machine is a device that specifies distinct states of an item and controls
these states through explicit or implicit event
4.6 Collaboration diagram
The collaboration diagram is used to show the relationship between the objects in a
system. Both the sequence and the collaboration diagrams represent the same information but
differently. Instead of showing the flow of messages, it depicts the architecture of the object
residing in the system as it is based on object-oriented programming. The collaboration
diagram, which is also known as a communication diagram, is used to portray the object's
architecture in the system.
4.7 Component Diagram
The component diagram below shows the structural relations between components in
an online Books shop system. The connected components by lines represent relationships
within the systems. In the diagram, it can be seen that there are components namely product,
book, customer, and account. It shows how the user component connects to the other
components while using the system. Everything from the account details to product booking
to payment flow can be seen in the component diagram. Users can view all the books, search
books by name, filter books by categories, and buy or download books after login into the
application.
4.8 Deployment Diagram

5. Non- Functional Requirements

5.1.1 Performance
The performance requirements are as follows:
• System login/logout shall take less than 5 seconds.
• Searches shall return results within 10 seconds.
• Orders shall be processed within 10 seconds.
• System shall support 10,000 simultaneous users.

5.1.2 Reliability
The down for maintenance no more than one hour a week. If the system
crashes, it should be back up within one hour.

5.1.3 Availability
The BSU Online Bookstore shall be available to users 24 hours a day, 7 days a week,
with the exception of being access only their own personal information and not that of other
users. Purchases will be handled through a secure server to ensure the protection of user’s
credit card and personal information.

5.1.4 Security
Users will be able to average time to failure shall be 30 days. In the event that a
server does crash, a backup server will be up and running within the hour.
5.1.5 Maintainability
Any updates or defect fixes shall be able to be made on server-side computers only
without any patches required by the user.

5.1.6 Portability
Nothing required.

5.2 Design constraints

The Online Bookstore shall conform to the following design constraints:
• Able to support PC, Mac platforms.
• System logs out user after a ten minute inactivity period.
• System supports all web browsers (i.e. graphical, non-graphical).

5.3 Logical Database Requirements

The database is normalized up to third level. The failures of system during any
database access or any other operations can be handled by rollback to its previous state.

5.4 Other Requirements

Register: Allows Account Registration
Login: Allows Account Login
Search: Allows user to search
Add to Shopping Cart: Allows users to add books to shopping cart
Delete from Shopping Cart: Allows users to delete books from shopping cart
Checkout: Allows user to checkout
Contact Us: Allows users to contact XYZ bookstore employees
Update Account Information: Allows users to update account information
Shipping Status: Allows users to view shipping status
Account Purchase History: Allows users to view account purchase history
Logout: Allows users account to logout
Help: Allows users to get help by showing FAQs

6. Analysis model
6.1 Sequence Diagram
The sequence diagram represents the flow of messages in the system and is also
termed an event diagram. It helps in envisioning several dynamic scenarios. It portrays the
communication between any two lifelines as a time-ordered sequence of events, such that
these lifelines took part at the run time. In UML, the lifeline is represented by a vertical bar,
whereas the message flow is represented by a vertical dotted line that extends across the
bottom of the page. It incorporates the iterations as well as branching.

6.2 Data Flow Diagram

The data flow diagram is a graphical representation of the flow of data in an
information system. It is capable of depicting incoming data flow, outgoing data flow and
stored data. The DFD does not mention anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts a flow of
control in program modules. DFDs depict the flow of data in the system at various levels.
DFD does not contain any control or branch elements.