Dispensary Management Software SRS

StuDocu is not sponsored or endorsed by any college or university
SRS Dispensary Management
Software Engineering (Thapar Institute of Engineering and Technology)
StuDocu is not sponsored or endorsed by any college or university
SRS Dispensary Management
Software Engineering (Thapar Institute of Engineering and Technology)
Downloaded by Stay Tuned (kkon2383@gmail.com)
lOMoARcPSD|11267987

A CASE STUDY (IEEE Format)
Software Requirements Specification Document
Version 1.0
Dispensary WebApp
lOMoARcPSD|11267987

TABLE OF CONTENTS
Chapter No. Topic Page No.
1. Introduction 3
1.1 Purpose of this Document 3
1.2 Scope of the Development Project 3
1.3 Definitions, abbreviations and acronyms 5
1.4 References 7
1.5 Overview 7
2. Overall Description 8
2.1 Product Perspective 8
2.2 Product functions 11
2.3 User Characteristics 12
2.4 General Constraints, Assumptions and Dependencies 13
2.5 Apportioning of the requirements 14
3. Specific Requirements 15
3.1 External Interface Requirements 15
3.2 Detailed Description of Functional Requirements 15
3.2.1 Functional Requirements for Student Welcome Screen 16
3.2.2 Functional Requirements for Staff Welcome Screen 16
3.3
3.2.3 Functional Requirements for Student cum Staff W
elcome Screen
Performance requirements
17
17
3.4 Logical database requirements 18
3.5 Quality attributes 19
3.6 Other requirements 19
4. Change History 19
5. Document Approvers 20
lOMoARcPSD|11267987

1. Introduction
1.1Purpose of this Document
The purpose of this SRS document is to provide a detailed overview of our software
product, i.e., DISPENSARY WEB-APP. It will explain the purpose and various features
of the app, what the app will do and the constraints under which it must operate. This
document is intended for both the end users and the developers of the web app.
1.2Scope of Development Project
The proposed software product is a Dispensary web app. The system will be used to get the
information from the patients and then storing that data for future usage.
The current system in use is a paper-based system. It is too slow and cannot provide updated
lists of patients within a reasonable timeframe.
The intentions of the system are to reduce overtime pay and increase the number of patients that
can be treated accurately. Requirements statements in this document are both functional and
non-functional.
Initially we plan to implement these functionalities for one Hostel only, with an intended
audience of around 500 people (of which 10 are Dispensary members including Doctor,
Nurses, Pharmacist and remaining are students) as part of the Pilot Phase. Once the Pilot
Phase is successful then we plan to implement it in other Hostels all across the institute
and eventually we plan to include various new features relevant for the software.
The scope of this system is not just limited to the university campus only as the same
software can be used in other campuses as well among the students and faculties. This
system can also be implemented in various other sectors where online medical facilities
can be provided in which a person sitting at his/her house can comfortably consult doctors
and get the required treatment and prescriptions for the same. This scenario is prevalent in
many industries today, and can bring a revolution around the world.
1.3Definitions, abbreviations and acronyms
Definitions
lOMoARcPSD|11267987

Table 1 gives an explanation of the most commonly used terms in this SRS document.
Table 1: Definitions for most commonly used terms
S.No. Term Definition
1 Login Window This component performs the function of user authentication. It
checks the user details from the database and signs in the user.
2 BMI It stands for body mass index.
Body Mass Index is a simple calculation using a person’s height
and weight. The formula is BMI = kg/m2 where kg is a person’s
weight in kilograms and m2 is their height in metres squared.
3 Web App A web application (or web app) is application software that runs on
a web server, unlike computer-based software programs that are run
locally on the operating system (OS) of the device. Web
applications are accessed by the user through a web browser with
an active network connection. These applications are programmed
using a client–server modeled structure—the user ("client") is
provided services through an off-site server that is hosted by a third-
party.
4 Pilot Phase The pilot project is an initial small-scale implementation that is
used to prove the viability of a project idea. The pilot project
enables an organisation to manage the risk of a new idea and
identify any deficiencies before substantial resources are
committed.
5 Database
A database is a collection of information that is organized so that it
can be easily accessed, managed and updated. Computer databases
typically contain aggregations of data records or files, containing
information about sales transactions or interactions with specific
customers.
Abbreviations
Table 2 gives the full form of most commonly used mnemonics in this SRS
document.
Table 2: Full form for most commonly used mnemonics
S.No. Mnemonic Full Form
1 BMI Body Mass Index
2 GPS Global Positioning System
3 SRS Software Requirement Specification
1.4References
[1]. Google Sign-in Authentication Link:
lOMoARcPSD|11267987

https://www.npmjs.com/package/react-google-login
[2]. BMI Calculator Component’s formula
Link: https://www.diabetes.ca/managing-my-diabetes/tools---resources/body-
mass-index-(bmi)-calculator
[3]. Calories tracker formula
Link: https://www.myprotein.co.in/blog/nutrition/how-to-calculate-a-calorie-
deficit-easy-steps/
[4]. React bootstrap for styling the components
Link : https://react-bootstrap.github.io/
[5]. W3Schools for references in react
Link: https://www.w3schools.com/REACT/DEFAULT.ASP
[6]. Javapoint for references in our project
Link : https://www.javatpoint.com/reactjs-tutorial
[7]. Wikipedia for general theory references
Link: https://www.wikipedia.org/
1.5Overview
The remaining sections of this document provide a general description, including
characteristics of the users of this project, the product's hardware, and the functional and
data requirements of the product. General description of the project is discussed in section
2 of this document. Section 2 gives the functional requirements, data requirements and
constraints and assumptions made while designing the multi-utility system. It also gives
the user viewpoint of product use. Section 3 gives the specific requirements of the product.
Section 3.0 also discusses the external interface requirements and gives detailed description
of functional requirements.
2. Overall Description
2.1 Product Perspective
As the user will open the web-app, he/she will be directed to a login window where the
software will authenticate the user credentials from the existing database after which the
user will see six different options available in our web app as you can see from the below
block diagram. After selecting the option as per requirement the user will be further
lOMoARcPSD|11267987

redirected to a new tab where he/she can perform the required task.
The above mechanism can be explained in a better manner with the help of the following
figure (Figure 1).
Figure 1: Block Diagram of our app representing its various functions.
Here the block diagram of our product has been depicted in the form of flow chart representing
its various features:
1. Login
2. Sign up
3. Slot Booking
4. BMI calculator
5. Medicine Delivery
lOMoARcPSD|11267987

6. Calorie Tracker
7. Emergency
2.2 Product Functions
The product should be able to perform the following operations:
1. It must be able to authenticate the user by matching the email id and the password code
against the values stored in the database.
2. It must be able to check the patient’s history or track record if he/she is already
registered with the software by referring to the database for the same.
3. It must be able to calculate the BMI of an individual by taking the required inputs from
the user.
4. It must be able to provide slot-booking facilities to the patients so that they can fix their
appointments with the respective doctors.
5. It must be able to provide a calorie tracking feature to the user so that the user can know
about his/her maintenance calories just by entering data such as height,weight,age etc.
6. It must provide a medicine delivery feature to the user so that the user can order
required medicines online without any hassle.
7. It must provide an emergency feature to the user so that in such a situation, the user can
quickly call an ambulance or any doctor and prevent any unfortunate incident.
2.3 User Characteristics
This software has 2 kinds of access modes ie. it gives access to two kinds of users.
1. Administrator:
The personnel and College administrator will have administrator access to add, delete,
and modify information stored in the database. The administrator can monitor the
details of registered members and update the database accordingly.
2. Authorized User :-
● Doctor
Doctors can view their appointments with their patients and add/upload prescriptions on
their end, advice patients and diagnose them accordingly in the slots allotted to them.
● Student/Faculty
lOMoARcPSD|11267987

They can view their history record with the doctors, book/edit their scheduled
appointments, order various medicines online, and have access to various other features
like BMI calculator, Calorie tracker and Emergency contacts.
2.4 General Constraints, Assumptions and Dependencies
➔ Talking about General Constraints, anyone who wants to access the software must have
himself/herself registered with the app. After doing so he/she will be able to guide through
our portal easily and experience the features provided.
➔ As one can see, each user will have a different educational background and expertise
level in using the system. Our goal is to develop software that should be easy to use for
all types of users. Thus while designing the software one can assume that each user
type has the following characteristics:
❖ The user is computer-literate and has little or no difficulty in using the software to
access its various functionalities.
❖ In order to use the smart card it is not required that a user be aware of the internal
working of a smart card but he/she is expected to know what happens when the card
is swiped against the reader.
➔ In order to find the exact location of the patient, he/she must have access to phone
GPS/Google Maps, so that it becomes easy for the ambulance to reach the patient timely
without any delay.
2.5 Apportioning of requirements
We plan to implement our Dispensary web app in the following three phases in a well
informed manner:
i. Pilot Phase: Initially we plan to implement our software for one Hostel only,
with an intended audience of around 500 people (of which 10 are Dispensary
members including Doctor, Nurses, Pharmacist and remaining are students) as
part of the Pilot Phase. Once the Pilot Phase is successful then we plan to
implement it in other Hostels all across the institute and eventually we plan to
include various new features relevant for the software.
lOMoARcPSD|11267987

ii. Institute wide deployment: Following the successful completion of the pilot
phase, we plan to implement our software in other Hostels all across the institute
and eventually we plan to include various new features relevant for the
upgradation of software.
iii. Extension of our web app to other campuses as well: In future this system
will not only be limited to our university campus only as the same software can
be deployed in other campuses as well among the students and faculties. This
system can also be implemented in various other sectors where online medical
facilities can be provided in which a person sitting at his/her house can
comfortably consult doctors and get the required treatment and prescriptions for
the same. This scenario is prevalent in many industries today, and can bring a
revolution around the world.
iv. Here the same functionalities will be implemented in each phase; the only
difference will be that the software implementation will be carried out on a very
large scale.
3. Specific Requirements
3.1 External Interface Requirements :
The following list presents the external interface requirements:
· In this product, usage of graphics is kept minimum with just a simple and easy to use
keypad for taking input.
· The product does not require usage of sound or animation.
· Sound is not an essential feature but it can be considered for future variants of the
system.
· This product is compatible with operating systems like Windows, Mac OS, Linux ,
Android and IoS.
· The device must have a screen which is atleast 5 inches large, for the user to view the
lOMoARcPSD|11267987

web-app comfortably and to ensure that it looks the way it is supposed to.
3.2 Detailed Description of Functional Requirements :
Table 3 shows a template that I’ll be using to describe functional requirements for users: student,
faculty , doctor as one can easily deduce the functional requirements for other user types with
this template.
Table 3: Template for describing functional requirements
Purpose A description of the functional requirements and its reasons
Inputs What are the inputs; in what form will they arrive; from what
sources can the inputs come; what are the legal domains of each
input.
Processing Describes the outcome rather than the implementation; includes any
validity checks on the data, exact timing of operation (if needed),
how to handle unexpected or abnormal situations
Outputs The form, shape, destination and volume of output; output timing;
range of parameters in the output; unit of measure of the output;
process by which output is stored or destroyed; process for handling
error message produced as output.
3.2.1 User Sign-Up Screen
Purpose This screen will allow a patient/doctor to register themselves on the app
so that the app knows who’s using it.
Inputs The user would need to select the type of user they are i.e.whether they’ll
be using the app as a doctor or a patient. Next, they’ll be needed to type in
details about themselves and also set up an email address and password
for future authentication.
Processing The details provided by the user will be stored in the central database for
lOMoARcPSD|11267987

future use, after verification of their email IDs.
Outputs Once the verification of the email address entered by the user is
completed successfully, the user will be redirected to their respective
dashboard screen i.e. patient’s or doctor’s dashboard screen.
3.2.2 User Login Screen
Purpose This screen is to identify the user who will be using the app and check
whether they are a doctor or a patient.
Inputs The users would be required to type in their registered email address
along with their password and then click the ‘sign in’ button.
Processing A request will be made to the server to verify the credentials entered by
the user based on the values stored in the database, and accordingly the
server will respond to the request by sending back some information. Till
the time the server responds to the request, the ‘sign in’ button will be
disabled and a circular loading animation will be shown to the user.
Outputs If the details entered by the user couldn’t be verified by the server, a
message will be shown to the user to convey this and they would be
expected to try again. Though, if the details are correct, the server would
respond with information specifying the type of user i.e. doctor or patient,
and accordingly the user would be redirected to the patient dashboard/
doctor dashboard screen.
3.2.3 Slot / Appointment Booking Screen
Purpose This screen is used to facilitate the process of booking an appointment for
a patient, with their doctor of choice.
lOMoARcPSD|11267987

Inputs The patient would be able to select the time slot for consultation that suits
them the most, subject to the availability of the doctor at that time.
Processing A request would be made to the server to change the availability status of
the doctor at the selected time, in the database. A meeting will be
scheduled on the application for the patient and the doctor.
Outputs A pop would appear on the patient’s screen to indicate booking
confirmation and they will be redirected to the patient’s dashboard. A
mail will be sent to both the parties, containing the details of the
scheduled meet. No other patient would be able to book an appointment
with the same doctor at the same time since the doctor wouldn’t be
available at that time as stored by the database.
3.2.4 BMI Calculator
Purpose This is the screen where the patient will be able to see his /her body mass
index.
Inputs The patient has to enter his / her details which includes gender , weight
(in kilograms) and height ( in centimeters) .
Processing A BMI calculator would be opened which would ask all the basic details
necessary for calculation.
Outputs The patient would be able to see his / her BMI index and can observe
whether he /she is underweight / overweight or has normal weight.
lOMoARcPSD|11267987

3.2.5 Calorie Tracker
Purpose This screen is used to estimate the number of calories a person needs to
consume each day.
Inputs The patient has to enter his / her details which includes age, gender ,
weight (in kilograms) , height ( in centimeters) and number of times
he/she exercises in a particular week.
Processing A calorie calculator would be opened which would ask all the basic
details necessary for calculation.
Outputs The patient would be able to see the amount of calories needed for a day
to remain physically fit.
3.2.6 Medicine Delivery
Purpose This screen would redirect the patient to an online pharmacy platform of
his /her own choice.
Inputs The patient is required to click on his/her preferable e-pharmacy
platform.
Processing The patient is redirected to the clicked online platform.
lOMoARcPSD|11267987

Outputs The patient would be able to select the medicine of his/her choice where
he/she can do payment as well.
3.2.7 Emergency:
Purpose This screen is used to provide 24x7 help to the patient .
Inputs The patient has to select what kind of emergency help he/she needs at that
time.
Processing The patient can see the location of nearby hospitals with their phone
numbers and is provided with the phone number of the ambulance and
nearby doctors.
Outputs The patient is provided immediate help.
3.3 Performance Requirements
● The login info verification would be done in a few seconds.
● The loading of the interface screen shall not take much time.
● The software will support simultaneous user access only if there are multiple PC’s or
other devices.
lOMoARcPSD|11267987

3.4 Logical Database Requirements
Figure 3 shows the E-R diagram for the entire system.
Figure 3: E-R Diagram for the Dispensary WebApp(including access control and
attendance monitoring)
3.5 Quality Attributes
lOMoARcPSD|11267987

The product is targeted towards a wide variety of users such as students, faculty members,
doctors etc. The product must load quickly and work well on a variety of terminals. It must
also tolerate a wide variety of input possibilities from a user, such as incorrect responses
or unforeseen keystrokes.
3.6 Other Requirements
None at this time.
4. Change History
5. Document Approvers
SRS for Dispensary WebApp is approved by:
Name:Dr. Harkiran Kaur
Designation:
Date:
Version 1.0–Initial Release
2021
lOMoARcPSD|11267987

Dispensary Management Software SRS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Dispensary Management Software SRS

Similar to Dispensary Management Software SRS (20)

Recently uploaded

Recently uploaded (20)

Dispensary Management Software SRS