Kaustubh Phatak
Contents
------------
1. Introduction.
1.6 References
2 General Description.
4 System features
4.1 Modules
5.4.1 Portability
5.4.2 Reliability
5.4.3 Testability
6 Other requirements
1. INTRODUCTION
1.1 Purpose
Hospital and Clinic Administrators: Hospital and Clinic Administrator will be using
this software for overall management.
Doctors: Doctors will be using this to keep track of their patients, appointments,
their consultation fees, and other details
Administrators:
Operators:
Operators interact with the system through the overlying GUI. They must
have comprehensive knowledge of the system, its behavior and also should be
able to troubleshoot possible errors encountered.
Doctors:
User Constraints
Each user must keep the password private and that they must be
greater than 7 characters.
The documentation and tutorials for the software will be provided after the
product is fully developed and tested
Assumptions
The doctor enters details about the patients he is looking after, also
consultations provided, etc. As and when medicines and other equipments are
purchased their details are inputted into the database.
Login Screen: The users log in and access the system depending on
privileges given.
Admin screen: Add and remove system users / change rights, password,
perform backup and restore operations, change configurations, etc.
Report preparing utility: Settings for preparing the reports such as medical
reports, bills, etc
Main Server: server is located in the hospital premises which hosts the database
using MySQL
Clients: each dept is provided with client systems, which run the app and connect
to the database server using internal LAN
4 SYSTEM FEATURES
4.1 Modules:
Patient Records
This module consists of Registration, OPD and IPD panels. This module provides
all the information about the patient as per the user access level.
• Doctors have access to the patient’s medical records. They can view the results of tests
conducted and medical history. They can also append medical details of the patient as
per their diagnosis.
• Lab technicians attach reports of the various tests conducted in the hospital.
• Computer operators can add/edit other relevant patient information. They also perform
registration and other formalities.
This module allows tracking of the inventory and finances. All purchases made
by hospital such as medicines, bio-medical equipments and other relevant items are
recorded by this module. It allows bookkeeping, generates Income and Expenditure
Account, Balance Sheet and other accounting reports. It generates various Inventory
reports, allows the hospital staff to view total stock available. Based upon the reports
hospital can decide which medicines are sold faster so that they can keep adequate
stock of it.
Billing Module
This module generates bills of patients as per the information about the various
services offered. The services include the bed, tests, consultation, medicines, etc. The
module automatically generates bills according to the services used by the patient.
Pharmacy Module
The Pharmacy Dept will basically use this module. This module keeps tracks of
sales of medicines. This module will be linked to Accounting and Inventory module so
that the net stock of medicines is always available.
The important aspect of Sanjivani is that it must offer complete control management and
all information at the click of a button. Response time of server may not be greater than
1 min. Number of terminals is not restricted by the application but the operating system
or N/w may impose some restrictions, in any case only one login per terminal and only
one login per user name is allowed
It keeps backup of all data files in separate directory, tape drives, etc
1. Access to the system will only be granted to the operators after authentication
2. Each user will be provided with a user name, password (minimum 8 characters) and
access level. The user can access only those modules and features as permitted by the
administrator.
3. Administrator(s) will have access to entire system
5.4 Software quality attributes
The product is open source so its source code will be available for everyone to
see. It will be free for further modifications and improvements.
5.4.1 Portability
5.4.2 Reliability
5.4.3 Testability
The requirement of this SRS will be verified through the exercising of test
cases as described by the requirement. Each requirement of this SRS will be
tested by thoroughly running the system with all forms of input. System should be
closely monitored during and after user testing to ensure that any fault is quickly
fixed
5.6 Installation
6 OTHER REQUIREMENTS
Not applicable
7 ENTITY RELATIONSHIP DIAGRAM