Professional Documents
Culture Documents
SRS Cse320
SRS Cse320
1|Page
TABLE OF CONTENTS
PAGE
TOPIC NO.
1.INTRODUCTION
1.1 PURPOSE
1.2 SCOPE
1.3 FEASIBILITY STUDY
1.4 DEFINITIONS, ACRONYMS AND 3-4
ABBREVIATIONS
1.5 DOCUMENTATION CONVENTION
1.6 REFERENCES
1.7 OVERVIEW
2.GENERAL DESCRIPTIONS
2.1 PRODUCT PERSPECTIVE
2.2 PRODUCT FUNCTIONS
2.3 USER CHARACTERISTICS
2.4 GENERAL CONSTRAINTS 4-6
2.5DESIGN AND IMPLEMENTATION
CONSTRAINTS
2.6 ASSUMPTIONS AND DEPENDENCIES
3. SPECIFIC REQUIREMENTS
3.1 FUNCTIONAL REQUIREMENTS
3.2 NON-FUNCTIONAL REQUIREMENTS
3.3 USER INTERFACE
3.4 HARDWARE INTERFACE
3.5 SOFTWARE INTERFACE 6-10
3.6 COMMUNICATION INTERFACE
3.7 SOFTWARE SYSTEM ATTRIBUTES
3.8 PERFORMANCE REQUIREMENTS
3.9 APPLICATION USER INTERFACE
(API)
4.OVERALL DESIGN
4.1 DATA FLOW DIAGRAM 10-14
4.2 USE CASE DIAGRAM
5. MANUAL TEST CASES 15
6. APPENDIX 16
2|Page
1.INTRODUCTION
1.1 PURPOSE
The purpose of this document is to provide a correct and
complete description of the requirements for the software of PRACTO. The requirements will
be shown in the written description to explain various concepts and different types of
functionalities with relevant information. A patient, his/her representatives or affiliates,
searching for Practitioners through the Website.
1.2 SCOPE
The software of PRACTO is responsible for making people take better healthcare
decisions and health-related issues. This also helps people in finding better
suggestions regarding health from the best doctors. Every day many people suffer
from many health problems or better healthcare.
With this software PRACTO, people start finding help from the best doctors which
can be managed by a single healthcare account for the entire family. It also secures
all the sensitive information regarding healthcare data to make better healthcare
decisions.
This software is looking to simplify healthcare access and help you to make
healthcare decisions. With search, we help you to find and decide on the right
healthcare providers across doctors, hospitals, diagnostics and wellness and fitness
centres.
Every day billions of people struggle for better healthcare. We are on a mission to
help mankind to live healthier and longer.
1.3 FEASIBILITY STUDY
The overall scope of the feasibility study was to provide
sufficient information to allow a decision to be made as to whether the PRACTO software
should proceed and if so, its relative priority in the context of other existing online healthcare
systems. The feasibility study phase of this project had undergone various steps as described:
Identify the origin of the information at different levels.
Identify the expectation of the user from the computerized system.
Analyze the drawback of the existing system (manual system).
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
JAVA -> Platform independent
GUI -> Graphical User Interface
SQL -> Structure query language
API -> Application User Interface
1.5 DOCUMENTATION CONVENTION
Font: Times New Roman 12
1.6 REFERENCES
Geeks for geeks
About practo.com
https://relevant.software/blog/software-requirements-specification-srs- document/
3|Page
1.7 OVERVIEW
The rest of this SRS document contains all the requirements for PRACTO
presented in several ways and organized in different sections.
Section 2 consists of general information that is not too in detail and is
provided as a background for the following sections. It contains the description of the other
components of the software that which it will interact. It also lists some of the product
functions, constraints, and assumptions about the software. Section 2 is important for the
customers as it contains a lot of information regarding the functionalities of the software.
Section 3 contains more details about the requirements with many others
which illustrate the functional requirements of the software PRACTO. In this a brief
information about interfaces such as user, software, hardware and also the communication
interfaces. This section is more useful for developers and testers.
2.GENERAL DESCRIPTIONS
Any user should have a valid user id and password to get access to the
services of the software.
Authentication in the form of OTP is just before staff is logging in to the
software, as a mark for securing the information of the users.
The user cannot get access unless and until he is registered with valid user
information.
The users cannot get access to the doctor’s account.
5|Page
If the password isn’t valid, prompt “Password must be 8-16 letters long and
must contain at least one uppercase and number”
Validate the if User has either chosen Doctor a or Customer
If either isn’t chosen, prompt “Choose User category”
All the data entered will be correct and up to date. This software package is
developed using java and GUI as a front end. Microsoft SQL server 2005 is used as the back
end which is supported by Windows 7.
3. SPECIFIC REQUIREMENTS
Doctor Search:
This helps the users in viewing the profiles of the doctors who are on the
PRACTO network. This allows users in fetching the complete profiles of the doctors in a single
request. This service returns multiple results of the profiles of doctors for convenient search
for users.
Search:
This service allows the user to search for a particular client, the availability
of the PRACTO services at their current location. The users also can search for the doctors who
work in their locality and can search for doctors by name, and specialization. Besides the
doctor’s information, the users can also search for the nearest clinics, gyms, spa, salons, and
also healthcare centers.
Consult:
This allows the users to ask the queries to the doctor without going to th
client then the query is answered by some of the doctors and also some of the assured
anonymous users. The best solution can be picked from the multiple solutions.
Log in/Register:
6|Page
Firstly, the user should be registered in the PRACTO valid information the
registration process is done the user can log in software with a valid user id and password for
authentication purposes. Once the user is logged in he/she can access the services of PRACTO.
Contact Us:
In this, the user can contact the doctor through EMAIL, phone call, SMS
etc. The user should provide the correct information for getting the solution for their queries.
Availability
The system should be available at all times, meaning the user can access
it using a web browser, only restricted by the downtime of the server on which the system runs.
In case of a hardware failure or database corruption, a replacement page will be shown. Also
in case of a hardware failure or database corruption, backups of the database should be retrieved
from the server and saved by the administrator.
Security
The system uses SSL (secured socket layer) in all transactions that include
confidential customer information.
The system must automatically log out all customers after a period of
inactivity.
The system should not leave any cookies on the customer’s computer
containing the user’s password.
The system’s back-end servers shall only be accessible to authenticated
administrators.
Reliability
The system provides storage of all databases on redundant computers
with automatic switchover.
The reliability of the overall program depends on the reliability of the
separate components. The main pillar of the reliability of the system is
the backup of the database which is continuously maintained and
updated to reflect the most recent changes.
Maintainability
7|Page
A commercial database is used for maintaining the database and the
application server takes care of the site. In case of a failure, a re-initialization of the program
will be done. Also, the software design is being done with modularity in mind so that
maintainability can be done
Availability
The system should be available at all times, meaning the user can access it
using a web browser, only restricted to the downtime of the server on which the system runs.
Portability
o The end user part should be fully portable and any system using any web
browser should be able to use the features of the system including any
hardware platform.
o The system shall run on pc, laptops, mobile phones and tablets.
Performance
The product shall take an initial load time depending on the media from w ch
the product is run.
There should be no delay from the system in processing the information
required by the user.
It must be able to perform in adverse conditions like high/low temperatures
etc.
High data transfer rate.
Supportability
Supportability refers to the degree by which the characteristics, design and
functions of products or services meet the standards of a particular system or organization.
Usability
The product should be easily used by all types of customers,i.e, naïve as well
as casual users without any difficulty.
The interface should be user-friendly so that the user and system interaction
is smooth and efficient.
Scalability
The software should have the ability to increase or decrease performance and
cost in response to changes in application and system processing demands.
The system should be able to increase its capacity and functionalities based
on its demands demand.
Recoverability
The software should be easily able to recover from crashes,
hardware failures and other similar problems.
It is tested by the forced failure of the software in a variety of ways
to verify that recovery is properly performed.
8|Page
Manageability
The software and its component should have the ability to get
easily maintained and monitored to keep the system performing, secure and
running smoothly.
9|Page
Doctor Details Provides access to profiles of doctors
Practice Details Provides access to the profile of practices of doctors
Search Allows you to query practices and doctors within a city with a wide range
of filters
Search Meta Data Provides the valid set of values needed while using Search.
This includes a list of cities, locations in a city and specialization supported in a
city.
4.OVERALL DESIGN
P.T.O
10 | P a g e
11 | P a g e
12 | P a g e
13 | P a g e
4.2 USE CASE DIAGRAM
14 | P a g e
5. MANUAL TEST CASES
15 | P a g e
6. APPENDIX
The rest of this SRS document contains all the requirements for
PRACTO presented in several ways and organized in different sections. Section 2 consists of general
information that is not too detailed and is provided as a background for the following sections. It contains a
description of the other components of the software that which it will interact It also lists some of the product
functions, constraints, and assumptions about the software. Section 2 is important for the customers as it
contains a lot of information regarding the functionalities of the software. Section 3 contains more details about
the requirements with many others which illustrate the functional requirements of the software PRACTO. In
this a brief information about interfaces such as user, software, hardware and also the communication
interfaces. This section is more useful for the developers and testers
16 | P a g e