SOFTWARE REQUIREMENTS SPECIFICATION

FOR

PHARMACY STORE MANAGEMENT

(PSM)

VERSION 1.0 APPROVED

PREPARED BY MANSI VARSHNEY, RIYA MUDGAL, KM PALAK

& YASH KUMAR

KIET GROUP OF INSTITUTIONS

26TH OCTOBER, 2021

 S. Due Completion Faculty
Program
No. Date Date Signature
Prepare an SRS document in line with the IEEE 15-09-2021
1 recommended standards for the specified Case 18-09-2021
Study. (Functional Requirements)
Prepare an SRS document in line with the IEEE 22-09-2021
2 recommended standards for the specified Case 25-09-2021
Study. (Non-Functional Requirements.
Draw the use case diagram and specify the role of 29-09-2021
3 each of the actors for the specified Case Study. 06-10-2021

09-10-2021
4 Prepare state the precondition, post condition and function
20-10-2021
of each use case for the specified Case Study.

5 Draw the activity diagram for the specified Case 23-10-2021

Study. 27-10-2021

6 Identify the classes. Classify them as weak and strong 30-10-2021

classes and draw the class diagram for the specified Case
Study.
10-11-2021 13-
7 Draw the sequence diagram for any two scenarios. 11-2021

Draw the collaboration diagram for the specified 17-11-2021

8 Case Study.
20-11-2021
9 Draw the state chart diagram for the specified Case Study. 24-11-2021

27-11-2021
10 Draw the component diagram for the specified Case Study. 01-12-2021

04-12-2021
11 Draw the deployment diagram for the specified Case 08-12-2021
Study.
11-12-2021
12 Design a test suite for the specified Case Study.
15-12-2021

TABLE OF CONTENTS
1. Introduction 4

1.1 Purpose 4

1.2 Document Conventions 4

1.3 Intended Audience and Reading Suggestions 4

1.4 Product Scope 4

1.5 References 5

2. Overall Description 5

2.1 Product Perspective 5

2.2 Product Functions 5

2.3 User Classes and Characteristics 5

2.4 Operating Environment 5

2.5 Design and Implementation Constraints 5

2.6 User Documentation 5

2.7 Assumptions and Dependencies 5

3. External Interface Requirements 6

3.1 User Interfaces 6

3.2 Hardware Interfaces 6

3.3 Software Interfaces 6

3.4 Communications Interfaces 6

4. System Features 6

4.1 Login/Signup Page 6

4.2 View Course 7

4.3 View User Profile 8

4.4 Logout Page 8

5. Other Nonfunctional Requirements 8

 5.1 Performance Requirements 8

5.2 SafetyRequirements
9
5.3 Software Quality Attributes 9

5.4 Business Rules 9

6. Other Requirements 9

1. INTRODUCTION

1 .1 Purpose

This document is meant to set forth the features and requirements of Pharmacy Store
Management Platform in a clear and concise way, so as to serve as a guide to the developers
on one hand and a software validation document for the perspective client on the other. This
Pharmacy Store Management Platform will enable customers and dealers to browse through
the available medicines and enable you to track all the products of the medical shop.

1 .2 Document Conventions

a) PSM: Pharmacy Store Management

b) SRS: System Requirement Specifications
c) GUI: Graphical User Interface UC: Use Case
e) Approx.: Approximately

1 .3 Intended Audience and Reading Suggestions

The intended audience of this SRS:

Developers: Project developers can go through this document and understand the requirements
presented by the client for the development of the product and start to work on it accordingly.
If the developer wants to change, modify or add new requirements/features into the existing
system, he/she must first consult this document, update the requirements in an appropriate
manner and pass the information correctly to the other phases of the development process.

Marketinq Staff: Marketing staff can read this SRS to develop accurate and effective pitches.
Users: Users, mainly students, can refer this document to get a better idea of the functioning
of the PSM and determine whether the requirements listed here have been satisfactorily
implemented.

Testers: Testers are required to go through the requirements very carefully to design test
cases and test the end product to ensure that the requirements presented by the client have
been implemented and the software is working efficiently.

1.4 Product Scope

As this is generic software it can be used by a wide variety of outlets (Retailers) to automate
the process of manually maintaining the records related to the subject of maintaining the
stock and cash flows.
This project is basically updating the manual chemist inventory System to Automated
inventory system, so that organization can manage their record in efficient and organized form.

1.5 References

IEEE Software Requirement Specification standard format

2. OVERALL DESCRIPTION

2.1 Product Perspective

PMS is a new project which is not associated to any other already Pharmacy websites in any
way.

2.2 Product Functions

PMS enables users to perform following functions:

1. Register
2. Login
3. Browse through the website and search for medical requirements It
will enable admins to perform:
1. Keep records of users
2. Keep records of Inventory
3. Add/delete/update data
 2.3 User Classes and Characteristics

2.4 Operating Environment

Web browser: Any web browser

Operating system: Windows 7 and above, iosl 2 and above, android 6.0 and above
Internet speed: minimum speed of 2mbps
PMS is free to browse and can be accessed by anyone

2.5 Design and Implementation Constraints

The user must have individual ID for creating an account

PMS shall be developed using HTML5/CSS on Visual Studio Code and MongoDB
for database.

2.6 User Documentation

2.7 Assumptions and Dependencies

Database used for PMS is MongoDB

Operation of the PMS depends on the number of concurrent users
Each user must have a User ID and password
There must be an internet connection
There should only be one account per email address

3. EXTERNAL INTERFACE REQUIREMENTS

3.1 User Interfaces

Login Screen: This feature is inbuilt in the software for the verification of authenticated user
over the unregistered ones.
Administrator Account: This enables the user to perform the admin level activities like
adding, removing and updating data.
User Account: This enables the user to view Inventory and view profile.
3.2 Hardware Interfaces

3.3 Software Interfaces

PMS is a multi-user environment, it uses HTML/CSS for the web pages and MongoDB as
the backend application tool.

3.4 Communications Interfaces

User can communicate with the admin via email provided on the website and hence uses
simple mail transfer protocol (SMTP).

4. SYSTEM FEATURES

4.1 Login/Signup Page

4.1.1 Description and Priority

Provides the user with a page to login or register for the PMS
Priority = 10
4.1.2 Stimulus/Response Sequences
Stimulus: User clicks on Login Link.
Response: Login Page is displayed
Stimulus: User Enters Username and Password
Response: Username and Password are validated from MongoDB
Database.
Stimulus: User Clicks on Login Button
Response: Home Page is displayed if Username and Password is
correct else Error Message is displayed and the user is asked to
enter username and password again.
Stimulus: User clicks on register Link.
Response: Register(signup) page is displayed
Stimulus: User enters his/her details and clicks on register button
Response: User's data gets saved; account is created and home page is
displayed

4.1.3 Functional Requirements

 REQ-I: The user should be able to view and click on login link
REQ-2: The user should be able to enter and validate the username and
Password.
REQ-3: There should be only one account per email else and error pop-up
should appear.

4.2 View Inventory

4.2.1 Description and Priority

Provides the user with a page to view different medicines with an option to
search medicine in inventory
Priority = 9

4.2.2 Stimulus/Response Sequences

Stimulus: User clicks on Medicines.
Response: Medicines Page is displayed
Stimulus: User clicks on particular page
Response: page and its description are displayed.

4.2.3 Functional Requirements

REQ-I : The user should be able to view and click on links.
REQ-2: The user should be able to update and delete for a particular product.
REQ-3: The user should be able to view product details by clicking on a
particular product.
REQ-I : The user should be able to view and answer the questions.

4.3 View User Profile

4.3.1 Description and Priority

Provides the user with a page to view his/her profile
Priority = 9

4.3.2 Stimulus/Response Sequences

Stimulus: User clicks on Settings -> User Profile
Response: User profile is displayed with user details.
4.3.3 Functional Requirements
REQ-1: The user should be able to click and view his/her profile.
 REQ-2: The user should be able to see the list of current and old inventory
items.

4.4 Logout Page

4.4.1 Description and Priority

Provides the user with a logout option.

Priority = 10

4.4.2 Stimulus/Response Sequences

Stimulus: User clicks on Logout link
Response: User is logged out and index page is displayed.
4.4.3 Functional Requirements
REQ-I : The user should be able to logout from the system.

5. OTHER NONFUNCTIONAL REQUIREMENTS

5.1 Performance Requirements

PE-I : Responses to activities should not take very long time onto the screen (approx.
2-5s, depending upon user's internet speed).

PE-2: The system should display confirmation message to the user very quickly after
the user submits information to the system (depending upon user's internet
speed).
PE-3: PMS should work fine even with a number of users using concurrently.

5.2 Safety Requirements

SR-1: Consistency: Checking the fact that all clients must be attached to one server, so
there is an appropriate control of the information.
SR-2: Users' data should be kept confidential.

5.3 Software Quality Attributes

SQA-I : PMS should be available to the users all the time.

SQA-2: The code should be neat and it should contain all the necessary comments for
the ease of maintenance.
 5.4 Business Rules

6. OTHER REQUIREMENTS
All the requirements have been specified.

Appendix A: Glossary

Appendix B: Analysis Models Appendix C: To Be Determined

List
USE CASE DIAGRAM
THE PRECONDITION, POST CONDITION AND FUNCTION OF LOGIN USE CASE
FOR PHARMACY STORE MANAGEMENT.

Case 1:- Test if user is able to login successfully.

Preconditions

- User must be registered already.

Input test data

-Correct username, Correct password.

Postconditions

- User must successfully login to the web page.

Case 2:- Test if unregistered users is not able to login to the site.

Input test data

- Incorrect username , lncorrect password.

Postconditions

- Proper error must be displayed and prompt to enter login again.

Case 3:- Test with valid username and empty password such that login must get failed.
Preconditions

-User must be registered already.

Input test data

- Valid username and empty password.

 Postconditions

- Proper error must be displayed and prompt to enter login again.

Case 4:- Test with empty username and empty password and check if login fails.
Postconditions

- Proper error must be displayed and prompt to enter login again.

Case 5:- Check of the password is masked on the screen i.e., password must be in
bullets or asterisks.

Input test data

-Some password(can be a registered/unregistered).

Postconditions

-The password field should display the characters in asterisks or bullets such that the
password is not visible on the screen.
ACTIVITY DIAGRAM

Open web
Applicatio
n

Registrati
on
SEQUENCE DIAGRAM