You are on page 1of 16

SOFTWARES REQUIREMENT SPECIFICATIONS

AND DESIGN DOCUMENT OF PRACTO.COM

NAME : ABHI PANCHAMI


REGISTRATION NUMBER : 12113731

1|Page
TABLE OF CONTENTS

PAGE
TOPIC NO.

1.INTRODUCTION
1.1 PURPOSE
1.2 SCOPE 3-4
1.3 FEASIBILITY STUDY
1.4 DEFINITIONS, ACRONYMS AND
ABBREVIATIONS
1.5 DOCUMENTATION CONVENTION
1.6 REFERENCES
1.7 OVERVIEW
2.GENERAL DESCRIPTIONS
2.1 PRODUCT PERSPECTIVE
2.2 PRODUCT FUNCTIONS 4-6
2.3 USER CHARACTERISTICS
2.4 GENERAL CONSTRAINTS
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 6-10
3.4 HARDWARE INTERFACE
3.5 SOFTWARE INTERFACE
3.6COMMUNICATION 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
1.INTRODUCTION
2|Page
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/

1.7 OVERVIEW
3|Page
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

The described in this document is software for getting help


for healthcare within seconds. The resources and services are the major part of this software
which comprises several components that are useful for the people as well as doctors for
accessing the availability of several services provided by the software PRACTO. These
services are helpful for the users for getting correct information about the availability of
services like healthcare issues, doctors’ information, gym, salon and also the availability of
these services in your current location.

2.2 PRODUCT PERSPECTIVE


The software PRACTO will help the users in viewing the
details of the nearest clinics. The location issue shows the exact location of the clinics so that
the user can reach them without any panic. The user can solve their health-related issues by
questioning the doctors and getting the best solution.

2.2 PRODUCT FUNCTIONS


The main purpose of this project is to reduce the manual
work of both the general users and the doctors.
• This software is capable of managing multiple queries from the users and
also providing multiple solutions for those queries so that the users can pick one of the best
solutions.
• The main focusing point of this software is to offer its world-class patient
relationship management platform to the subscribers.
• This platform provides an efficient telephone, SMS, and Web-based
appointment booking system.
• Patient communication for follow-up and alerts to improve patient satisfaction.

2.3 USER CHARACTERISTICS


Educational level:

4|Page
The best knowledge on the development of the website is required as it
is important to build the best website for the customer the programmer should know the
programming language mentioned in the SRS so that it would be better in designing.
Experience:
An experienced person is required for the development of the website
so it was necessary was developing powerful projects and the experienced person can
develop the website professionally.
Technical Expertise:
it means knowledge to a very high level about some technology for
example computer knowledge that a technical expert has, in the same way, the website
developer in the case of online doctor practo.com

We have 2 levels of users :


 User module: In the user module, users will check the availability of
doctors, book their appointment, solve their queries, and search for their healthcare solutions.
 Book appointments with doctors
 Doctors module: This module consists of the following sub modules
 The daily schedule of the doctors.
 Checking the appointments of particular patients.
 For sharing the medical details with the staff.
 This also helps as a wonderful tool for their daily practice.

2.4 GENERAL CONSTRAINTS

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.

2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS


Login:
 Validate if an account with that email address exists
 Validate the account’s password
 If the email is blank, prompt the message “Please provide email”
 If a password is blank, prompt the message “Please provide the password”
 If either doesn’t match the data, prompt “email/password is incorrect”
Signup:
 Validate if the email is available
 Validate that the password isn’t blank
 If the password is blank, prompt the message “Please provide the password”
 Validate if the password entered is valid according to the criteria
 If the password isn’t valid, prompt “Password must be 8-16 letters long and
must contain at least one uppercase and number”

5|Page
 Validate the if User has either chosen Doctor a or Customer
 If either isn’t chosen, prompt “Choose User category”

Validate for Disabled Account:


 Validate that the account is not disabled
 If the account is disabled, the error message, "Account has been disabled as of
<expiration date>"

2.6 ASSUMPTIONS AND DEPENDENCIES

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

3.1 FUNCTIONAL 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:
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.

6|Page
Find and Book:
In this, the user/patient can find the doctor’s advice or can book an
appointment for the checkup or the treatment. PRACTO for Doctors: In this, the doctors can
log in and check their patient information, and answer the queries of the patients. Through
this module, the doctors can perform their daily activities, remainders, and discuss with their
staff.

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.

3.2 NON-FUNCTIONAL REQUIREMENTS

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

7|Page
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.
Manageability

8|Page
 The software and its component should have the ability to get
easily maintained and monitored to keep the system performing, secure and
running smoothly.

3.3 USER INTERFACE


The software provides a good graphical interface for the user. Any
authorized user can access the functionalities of the software such as searching for the
availability of PRACTO services, doctors’ profiles, nearest gyms, spas, and also healthcare
clinics and find solutions for their queries.

3.4 HARDWARE INTERFACE


Operating system: The software PRACTO is a user friendly, so it can be
run on any platform such as windows, IOS
Hard disk: As we need to store the information of the users without getting
the data lost some memory is needed for storing this information in the form of a hard disk
i.e., ranges from 10GB – 1TB
3.5 SOFTWARE INTERFACE
Graphical User Interface (GUI): It is an interface between the user and a
system that involves the use of mouse events to select options from menus, make choices
with
button actions, the art program by clicking the icons, etc.
JAVA: It’s a platform-independent language.

3.6 COMMUNICATION INTERFACE

Graphical User Interface (GUI): It is an interface between the user and


a system that involves the use of mouse events to select options from menus, make choices with
button actions, start the program by clicking the icons, etc. JAVA: It’s a platform-independent
language.

3.7 SOFTWARE SYSTEM ATTRIBUTES


It is an interface between the user and a system that involves the use of
a mouse-events to select options from menus, make choices with button actions, start program by
clicking the icons, etc.

3.8 PERFORMANCE REQUIREMENTS


The capability of the computer depends on the performance of the
software. The software can take any number of inputs provided the database size is larger enough.
This would depend on the available memory space.

3.9 APPLICATION USER INTERFACE (API)


The following requests are supported by the API:

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

4.1 DATA FLOW DIAGRAM


 ZERO-LEVEL DATA FLOW DIAGRAM: The zero-level DFD explains the
doctor appointment system in doctor practo.com and how it is interlinked with different types of
management as shown in the first figure.
 FIRST LEVEL DATA FLOW DIAGRAM: The first level DFD explains how
different types of management connects with the doctor appointment system and generates different
types of report as shown in the second figure.
 SECOND LEVEL DATA FLOW DIAGRAM: The second level DFD
explains the role of admin in the online doctor practo how he can access all the things in doctor practo
and how he can manage details of patients and other things like reports management etc. As shown in
the third figure.

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

Use case diagram for practo.com

5. MANUAL TEST CASES


14 | P a g e
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

You might also like