Practical no: - 02

Aim: - SRS For online bookstore

Table of Contents: -
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Product Scope
1.5 References

2. Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies

3. External Interface Requirements

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

4. Other Non-functional Requirements

4.1 Performance Requirements
4.2 Safety Requirements
4.3 Security Requirements
4.4 Software Quality Attributes
4.5 Business Rules

9|
 Page
1. Introduction
Purpose
This Software Requirement Specification is meant for an Online Bookstore. The Online
Bookstore is meant as a way for customers to browse books on the website and buy them
from home without the need to travel to a book shop. Defining the functions and
specifications of the Online Bookstore is the primary purpose of this SRS. The SRS illustrates
in clear terms, the system’s primary uses.

Document Conventions
This SRS is written in Arial font with size 11 in italics, and Times font with size 14 for bullet
points. The priorities for higher level requirements are inherited in detailed requirements.

Intended Audience and Reading Suggestions

This System Requirement Specification is meant for the Project makers, Project overseers,
The Website Administrators, Customers, and the Suppliers. The SRS is written in the
standard IEEE
format. The readers should read the whole SRS sequentially to gain a proper understanding
of the project.

Product Scope
The software system being produced is called Online Bookstore. It is being produced for a
customer interested in selling books via the Internet. This system is designed to “provide
automation support” for the process of placing books for sale on the Internet and facilitating
the actual sale. This system is largely cross-platform and is available to anyone using the
internet. The system will be run on a central server with each user having a remote user
interface through a web browser to interact with it. The Online Bookstore will allow any user
to create an account to become a customer. The customer, through the process of account
creation, will have the option to become a member of the site. The system will allow
customers to browse, search, select, and add books to a shopping cart. Then, provided they
have books in their shopping cart, check out books in shopping cart and decrement the stock
that the inventory the system maintains. The Online Bookstore also allows a manager to
manage the inventory with full create, retrieve, update and delete (CRUD) functionality with
regards to books in the system.

10 | P a g e
 References http://www.cse.msu.edu/~chengb/RE-491/Papers/SRS-BECS-2007.pdf

An SRS of an example of online bookstore on a small scale of a university campus.

https://docplayer.net/25969140-Srs-for-bsu-online-bookstore.html

2. Overall Description
Product Perspective
This product is an entirely new product. It is not a component of a larger system. The online
bookstore website supports a number of functions for both the consumer and store's
management. The website is available to anyone using the internet and as such must work
correctly in all browsers (Google Chrome, Internet Explorer, Mozilla Firefox, Microsoft Edge,
Safari, etc). There are no hardware or software requirements beyond these including, but
not limited to, memory or specific software packages that need to be utilized nor software
packages that need not be utilized. The Online Bookstore system will interact with a
credit/debit 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.

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 keeps 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.

 Allow customers and managers to log in and out of the system.

11 | P a g e
 • 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.

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.

Operating Environment
The system will work on any hardware device having an internet connectivity and browsers
to browse the website. The browsers should be up to date to run various features of the
website. The system will not run-on OS below Windows XP. The system will also not run-on
browsers not supporting JAVA plugins.

Design and Implementation 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
12 | P a g e
 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.

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.

Apportioning of requirements
As stated by the customer, security is not a concern of this project. As such, it is beyond the
scope of this system to encrypt personal user data, encrypt credit card information, prevent
unauthorized login attempts, or any other concern of this nature. Additionally, the system is
not responsible for the following:
• Verifying that credit card information is valid.
• Verifying the email address provided by a user.
• Storing additional information about a book beyond simply the title, name of author, and price.
• Allowing users to edit their account details (username, password, mailing address, etc).
• Allowing customers to order multiple copies of a book in a single order.
• Providing individual product pages (one page for every item in the inventory).
• Allowing the manager to update login credentials or other information about the manager.

13 | P a g e
 3. External Interface Requirements
System Interfaces
The system will interface with the following two systems:
1. A credit/debit card processing system: The system will access the credit/debit card
processing system via its web services API.
2. The Bookstore Inventory database: The system will interact with the inventory

database via an ODBC connection. User Interfaces

The system will provide the ability for everyone to access the Online Bookstore via the
Internet. There will be two different user interfaces that will accompany this website: one for
the buyers and one for administrator.
• Buyers will be allowed to search database without having to login, however, they
must login in order to perform any other transaction. This other transaction will include
purchasing textbooks, or viewing and changing their online account.
• Administrator will have to login to perform any functions. Administrator will be able
to add/delete books to be displayed to the users, and change the information on any books
as required. He/she will also be able to look into the inventory database to check the
availability of books and their quantity-in-stock.

Hardware Interfaces
There are no special hardware interface requirements. Software
Interfaces
There are no special software interface requirements.

Communications Interfaces
There are no special communication interface requirements.

4. Other Non-functional Requirements Performance

Requirements
The performance requirements are as follows: - 

System login/logout shall take less than 5 seconds.

• The system should run properly on all browsers.

• The system should be light and run smoothly.

Safety Requirements
The safety requirements are as follows: -

14 | P a g e
 • The password should not be visible while typing.

• The system should use a secure connection to connect with the credit/debit card
processing system.

Security Requirements
The security requirements are as follows: -

• The user (buyers and administrator) requires a username and password to login into the
system.

• The buyers cannot buy books without logging in.

• The order will not be confirmed until payment process is completed.

Software Quality Attributes

• Reliability The average time of failure for the system is 30 days. In the event that the server
crashes, the system will take a week to be running again.

• Availability The Online Bookstore will be available 24x7, with the exception of being down
for maintenance no more than 3 hours a week. If the system crashes, it should be back up
within a week.

• Security Users will be able to 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.

• Maintainability Any updates or defect fixes shall be able to be made on server-side

computers only, without any patches required by the user. Business Rules
The business rules are as follows:

• The administrator cannot be a customer.

• The administrator cannot access the buyers’ personal information.

• The administrator will receive notifications from the credit/debit card processing system to
process the order and confirm payment of order is received.

Practical no.: - 03
Aim: - Draft a project plan using OpenProj.
OpenProj is an open-source project management software application. OpenProject offers powerful
collaboration features and meets highest requirements in data privacy and security. It offers an
appealing and intuitive user interface. Also, the majority of features are fully accessible. OpenProj
operates on multiple platforms including Windows, Mac, Linux and Unix.
Due to continuous development and enhancements, OpenProject has an enormous potential, which
outdrives common project management software. OpenProject is licensed under the terms of the
GNU General Public License version 3. OpenProject's plugins also support a variety of functionalities,
15 | P a g e
such as meeting management, Scrum methodologies, time and cost reporting, etc... OpenProject
also includes companies and organisations to participate and consider their requirements and ideas
to improve the software, e.g., in terms of data privacy, security, usability and accessability.
OpenProject provides a place to collaborate, exchange ideas, best practices and new requirements
for companies as well as individuals.
The open-source software, OpenProj, is provided free of charge to companies of all sizes. Consumers
may download the application as many times as needed for all team members throughout their
enterprise. No restrictions exist with OpenProj. Each of these tools help managers allocate time,
resources and budget expenses. Project management tools are designed to help team members
effectively manage time and budget resources.

Features:
The current version includes:

• Earned Value costing

• Gantt chart  PERT graph
• Resource Breakdown Structure (RBS) chart
• Task usage reports
• Work Breakdown Structure (WBS) chart.
• Sharing with team members is easy
• Define Standard and Overtime rates or Cost per use for resources
• Put resources in groups
• Define Resources with type Work or Material

Steps of Installing OpenProj

Step 1: Download the installation file of OpenProj from
http://sourceforge.net/project/openproj/files.
Step 2: Double click the installation file to install OpenProj.
Step 3: After the installation, double click the shortcut of OpenProj.exe on the desktop to execute
it.

Practical no.: -04

Aim: - Track the progress of a project using OpenProj.
Gantt: Gantt chart in which a series of horizontal lines shows the amount of
work done or production completed in certain periods of time in relation to the
amount planned for those periods. Gantt charts illustrate the start and finish
dates of the terminal elements and summary elements of a project.

16 | P a g e
Network: An arrangement of intersecting horizontal and vertical lines. interact
with others to exchange information and develop professional or social
contacts

Resources: A stock or supply of money, materials, staff, and other assets that
can be drawn on by a person or organization in order to function effectively.

17 | P a g e
Report: An account given of a particular matter, especially in the form of an
official document, after thorough investigation or consideration by an
appointed person or team.

Task usage: The task usage view displays useful information about all the tasks
in a project. Through this view you can see how much time and money any task
will take. Once you have assigned an hourly rate to the different resources in
your project you can get an estimate to how much the project is going to take.

18 | P a g e
Resources usage: one of the most important aspects of your role is to monitor
the assignments for each of your resources so that you can effectively balance
their workloads. Some resources might be overallocated, and others might be
under allocated. You can review how efficiently your resources are being used
in your project, and whether you need to make any adjustments

19 | P a g e
 Practical no.: -05
Aim: - Activity diagram, Sequence diagram and Class diagram for online bookstore
using Rational Rose.
Activity Diagram:
Activity diagram models the logic from workflow to use cases to methods. It borrows most of the
notations from the flowchart but has added the concept of concurrency to support many modern
applications. The arrow traces the flow from beginning to end through decision and loops, while
identifying each logic steps in the process. Activity diagrams are typically used for business process
modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the
detailed logic of a business rule.

20 | P a g e
Sequence Diagrams:
Sequence diagram is one kind of interaction diagrams, which shows an interaction among a set of
objects and their relationships. The purpose of the Sequence diagram is to document the sequence
of messages among objects in a time-based view. The scope of a typical sequence diagram includes
all the message interactions for a single use case.

21 | P a g e
Class Diagram
Class diagram, one of the most commonly used diagrams in object-oriented system, models the
static design view for a system. The static view mainly supports the functional requirements of a
system – the services the system should provide to the end users. We will see from our practical
experience that lots of fun comes out when modeling out system with class diagrams. A class
diagram shows a set of classes, interfaces, and collaborations and their relationships.

22 | P a g e
 Practical no.: - 06
Aim: - To perform unit testing and integration testing.
Unit testing:
Unit testing is a software testing method by which individual units of source code, sets of one or
more computer program modules together with associated control data, usage procedures, and
operating procedures, are tested to determine whether they are fit for use. Intuitively, one can view
a unit as the smallest testable part of an application. In procedural programming, a unit could be an
entire module, but it is more commonly an individual function or procedure. In object-oriented
programming, a unit is often an entire interface, such as a class, but could be an individual method.
Unit tests are short code fragments created by programmers or occasionally by white box testers
during the development process. It is also known as component testing.

Test cases
Test cases help us discover information. Different types of tests are more effective for different
classes of information. Test cases can be "good" in a variety of ways. No test case will be good in all
of them.

The test cases will have a generic format as below.

USER:

• Registration

• Login

• Add To Cart

• Edit Cart

ADMIN:

• Create and Delete book from Category

• Create and Delete a Category

• Manage Orders

• Manage Members

23 | P a g e
User

24 | P a g e
Admin

25 | P a g e
Test Conditions for the fields in the Login screen
Admin Name-enter admin name

Username –Numeric and special type of characters are not allowed.

Test Prerequisite: The user should have access to Admin Login screen form screen.

Negative Test Case

Project Name- Online bookstore

Integration testing:
26 | P a g e
Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase in
software testing in which individual software modules are combined and tested as a group. It occurs
after unit testing and before validation testing. Integration testing takes as its input modules that
have been unit tested, groups them in larger aggregates, applies tests defined in an integration test
plan to those aggregates, and delivers as its output the integrated system ready for system testing.
Integration testing tests integration or interfaces between components, interactions to different
parts of the system such as an operating system, file system and hardware or interfaces between
systems. The purpose of this level of testing is to expose faults in the interaction between integrated
units. Test drivers and test stubs are used to assist in Integration Testing.

Practical no.: - 07
Aim: - To perform various white box and black box testing techniques.
Black box testing:
Black-box testing is a method of software testing that examines the functionality of an application
without peering into its internal structures or workings. This method of test can be applied to
virtually every level of software testing: unit, integration, system and acceptance. Test cases are built
around specifications and requirements, i.e., what the application is supposed to do. The test
designer selects both valid and invalid inputs and determines the correct output without any
knowledge of the test object's internal structure. Black box testing treats the system as a “blackbox”,
so it doesn’t explicitly use Knowledge of the internal structure or code. Also known as functional
testing, behavioral testing.

27 | P a g e
This method attempts to find errors in the following categories:

• Incorrect or missing functions.

• Interface errors.
• Errors in data structures or external database access.
• Behavior or performance errors.
• Initialization and termination errors.

Black box testing techniques:

Following are some techniques that can be used for designing black box tests.

• Equivalence partitioning
• Boundary Value Analysis
• Cause Effect Graphing

Login page

When the admin name and the password is correct then admi services are opened.
White box testing:
White-box testing is a method of testing software that tests internal structures or workings
of an application, as opposed to its functionality (i.e., black-box testing). In white-box testing
an internal perspective of the system, as well as programming skills, are used to design test
28 | P a g e
 cases. The tester chooses inputs to exercise paths through the code and determine the
appropriate outputs. White box testing is a testing technique, that examines the program
structure and derives test data from the program logic/code. Also known as clear box
testing, glass box testing, transparent box testing, and structural testing

In this the test cases are generated on the logic of each module by drawing flow graphs of
that module and logical decisions are tested on all the cases.
It has been uses to generate the test cases in the following cases:
• Guarantee that all independent paths have been executed.
• Execute all logical decisions on their true and false sides.
• Execute all loops at their boundaries and within their operational bounds.
• Execute internal data structures to ensure their validity.

White box testing techniques:

 Basis path testing
• Structured testing
• Fault based testing
• Logic based testing

29 | P a g e
30 | P a g e