Hospital management system_software_requ

Sri Lanka Institute of Information Technology
HOSPITAL MANAGEMENT SYSTEM
Software Requirement Specification
Information Technology Project 2016
Project ID: ITP-16-MLB-WE-13
Submitted by:
1. IT15135230– (Amarathunga A. A. B. S)
2. IT15143082– (Abeywardhane J.S.D.M.D.S)
3. IT15143228– (Gunawardena D.C)
4. IT15130730– (De Silva E.M.W.N)
5. IT14069246– (Jayathilaka A.U)
6. IT15099846– (Palliyaguru S.T)
7. IT15096944– (Wanniarachchi T.N)
8. IT15025722– (Liyanage L.C)
Submitted to:
(Supervisor’s signature)
…………………………..
Ms. Yashodhya Wijesinghe
Date of submission

ii
Table of Contents
Table of Contents.......................................................................................................................... ii
Revision History........................................................................................................................... iii
1. Introduction..............................................................................................................................1
1.1 Purpose ........................................................................................................................................ 1
1.2 Document Conventions ............................................................................................................... 3
1.3 Intended Audience and Reading Suggestions ............................................................................. 3
1.4 Product Scope.............................................................................................................................. 3
1.5 References ................................................................................................................................... 6
2. Overall Description..................................................................................................................6
2.1 Product Perspective ..................................................................................................................... 6
2.2 Product Functions........................................................................................................................ 6
2.3 User Classes and Characteristics................................................................................................. 9
2.4 Operating Environment ............................................................................................................. 10
2.5 Design and Implementation Constraints ................................................................................... 10
2.6 Project Documentation.............................................................................................................. 11
2.7 User Documentation.................................................................................................................. 12
2.8 Assumptions and Dependencies................................................................................................ 12
3. External Interface Requirements .........................................................................................13
3.1 User Interfaces........................................................................................................................... 13
3.2 Hardware Interfaces .................................................................................................................. 23
3.3 Software Interfaces.................................................................................................................... 24
3.4 Communications Interfaces....................................................................................................... 24
4. System Features......................................................................................................................25
5. Other Nonfunctional Requirements.....................................................................................33
5.1 Performance Requirements ....................................................................................................... 33
5.2 Safety Requirements.................................................................................................................. 33
5.3 Security Requirements .............................................................................................................. 33
5.4 Software Quality Attributes ...................................................................................................... 33
5.5 Business Rules........................................................................................................................... 34
Revision History
Name Date Reason For Changes Version

ITP-16-MLB-WE-13 – Hospital Management System
1
1. Introduction
1.1 Purpose
If the SRS is written well it will serve the following purposes. SRS is the agreement document
between the client and the Software developer.
Feedback to the Customer-This software requirement specification assures the project
management stakeholders and client that the development team has really understood
the business requirements documentation properly. This also provides confidence that the team
will develop the functionality which has been detailed.
Breaking the Requirements Down-This document is documented in such a way that it breaks
the deliverables into smaller components which makes the participants in this project to
understand what is to be done clearly.
The information is organized in such a way that all the developers within the team will not only
understand the boundaries within which we need to work, but also what functionality needs to be
developed and in what order.
Understanding what order the functionality will be developed in means that we, the developers
will have the "big picture" view of the development. This gives us an opportunity to plan ahead
which saves both project time and cost.
Facilitating other Documentation-The SRS forms the basis for a load of other important
documents such as the Software Design Specification.
Product Validation-It basically helps in validating with the client that the product which is
being delivered, meets what they asked for.
Which means that the product we have output is Equal to the standards of the documentation in
the SRS which the client satisfied and agreed on.

2
Characteristics of a Software Requirement Specification
1.1.1 Accuracy
We will ensure the accuracy of the software and the data entered to the database
1.1.2 Clarity
This SRS will be clearly stating what the user wants in the software.
1.1.3 Completeness
The software requirement specification contains all the the requirements stated in the
business requirements documentation that the user specified.
1.1.4 Consistency
The document is consistent from beginning till the end. It helps the readers understand
the requirements well.
1.1.5 Prioritizations of Requirements
The requirements will be full filled according to the order of priority and preference.
1.1.6 Verifiability
At the end of the project, the user/client will be able to verify that all that all the agreed
deliverables have in fact been produced and meet the project management requirements
specified.
1.1.7 Modifiability
The SRS can be modified when the development team and user feel the need.
1.1.8 Traceability
Each requirement stated in the SRS is uniquely associated to a source such as a use case
or interaction document etc.

3
1.2 Document Conventions
The document is prepared using Microsoft Word 2010 and has used the font type 'Times
New Roman'. The fixed font size that has been used to type this document is 12pt with 1.5 line
spacing. It has used the bold property to set the headings of the document. All pages except the
cover page are numbered, the numbers appear on the lower right hand corner of the page. Every
image and data table are numbered and referred to the in the main text
Use case scenario is written according to Alistair Cockburn’s template. Standard IEEE
template is the template used to organize the appearance of the document and its flow.
1.3 Intended Audience and Reading Suggestions
The intended audience of this document would be the client and specific employees like
Manager and Receptionist, consultants and System Operators of the St Joseph Hospital, and
project team, supervisor with the objective to refer and analyze the information. The SRS
document can be used in any case regarding the requirements of the project and the solutions
that have been taken. The document would final provide a clear idea about the system that is
building.
1.4 Product Scope
Currently Wennapuwa St Joseph hospital is using a manual system to handle the hospital
process. When patients arrive they make an appointment at the reception to consult a Doctor.
These are being recorded in a file. Then again the patients diagnosed symptoms related disease
details, ward details and other necessary details are being recorded and those files are being
stored in special locations. Calculation of bills and inventory are done manually.
As the current system is a file based one, management of the hospital has to put much
effort on securing the files. They can be easily damaged by fire, insects and natural disasters.
Also could be misplaced by losing data and information.
Limited storage space of the files is another issue that they currently face when the
management is manually done.
There occurs an issue with the organization of data information and schedules and running
the process methodically which leads to the manual system malfunctioning.

4
If we want to check a previous record of a patient or other detail. Management will be in a
great problem. It’s a tough and time taking process to search for a record in a file.
Keeping files takes much time and waste much precious man hours.
The tendency of making mistakes is high when functioning manually. It is hard to relay on
the accuracy of calculations done manually too. It is more obvious for problems to arise.
We plan to overcome the above mentioned problems through a standalone application, to
manage the major functions of the Hospital System.
The hospital management system we are going to implement will be covering all basic processes
done in the hospital. It would handle Employee and Salary management, Patient and “Zumba
exercise” management, Theatre and ward Management, Laboratory management, Transport
Management, Pharmacy Management, OPD management and emergency management.
In OPD unit, with the OPD and Consultation Management system, the manual doctors
channeling details entering process has automated. So the staff does not need to spend time on
writing appointment records and updating them in files. And the number issuing process
becomes easier and efficient. And keeping the track of patients and medical prescription details
allow them to review the details whenever needed.
Implementing the Employee & Salary Management system we record Attendance,
shifting of employees, their holidays and consulting doctors’ schedules. And the system
performs calculations of EPF/ETP and OT hours, Shares of consulting doctors and do the payroll
part. This is more efficient and more reliable and accurate as the system avoids incorrect data
inputs whenever they are occurred.
The proposed system for Mini-theatre & Ward Management records details of surgeons,
in- patients who are assigned for Wards, different ward details and surgery details. The
pharmaceuticals used within the theatre are managed as well. Food menus for the patients
according to their diseases based on wards is systemized too. All are digitalized in a systematic
way. So the details of surgeons, patients and surgeries are well organized and can be easily
accessed whenever needed. Surgery reports, Ward progress reports, In-ward patient progress
details are generated and history can be tracked too.
The Vehicle & Transport Management system handles all the data on ambulance
transport. It manages the time slots of ambulances, driver’s and employee details of transport
section and provides bill generating facility. And reliable time slot management provides the

5
facility of checking the availability of the ambulances whenever required, and decide about a
possible time they can fulfill a request.
The current process of “Zumba” exercise details managing does not support for any
individual progress analyzing. The Exercise “Zumba” Management provides a detailed progress
report of each individual and allows the management or their customer to take decisions on
exercise plans.
The system developing for Emergency Treatment & Equipment Management automate
the current processes of patient registering and propose a better way to keep records of
equipment and medicines related to the emergency treatment unit in a computer based file
system. The proposed system provides a simple interface to gather quick information of the
patient and record them. So that in a case of special request by an external party, details of the
patient history can be accessed and viewed.
The Pharmacy Stock Management system is responsible for proper management of drug
stocks, pop ups the notifications of expiry dates of stock items. This system allow the client to
keep track of medicine stocks , notify the personals when the stock is running out of items and
help the manager to reduce stock levels and eliminate stock waste.
The Lab Management System records sample collection details, keep track of lab
resources and participate in lab reports conclusion generating. This increases the accuracy of
report generating process and save a lot of time in manual handling of report details and improve
the efficiency and the productivity of the organization.
Our goal is to make a client satisfied system by full filling the client requirements and
improving the current manual system with client needs which are not even particularly
mentioned but what we have suggested by analyzing and got approved by the client to improve
the standard of the system and of the management of the hospital to its utmost.
The scope of the SRS is basically for everyone involved to understand and have an idea
about how and what is going to happen in the system. Using ER, User Case diagrams and GUI’s
which are in a form where everyone can understand. How the interfaces finally appear. To have
an idea about the new employees that the client might have to get employed when the system is
implemented.

6
1.5 References
[2]Lauesen, S, (2003), Task Descriptions as Functional Requirements, IEEE Computer Society,
Available:http://www.itu.dk/~slauesen/Papers/IEEEtasks.pdf
2. Overall Description
2.1 Product Perspective
St. Joseph’s Medical Centre follows manual procedures to keep track of its day to day
activities. When scenarios such as patient information handling, employee handling, stock
handling, financial analysis and report generation is taken into consideration there exists many
issues with regard to efficiency, security, accuracy and reliability. Due to improperly managed
details medical center faces quite a lot of difficulties in accessing past data as well as managing
present data. The manual file systems which are being used at present require storage facilities
which is also another overhead.
The fully functional automated hospital management system which will be developed
through this project will eliminate the disadvantages caused by the manual system by improving
the reliability, efficiency and performance. The usage of a database to store patient, employee,
stock details etc. will accommodate easy access, retrieval, search and manipulation of data. The
access limitations provided through access privilege levels will enhance the security of the
system. The system will facilitate concurrent access and convenient management of activities of
the medical center.
2.2 Product Functions
OPD and Consultation Management
 Recording patient details
 Issuing numbers according to doctor channeled
 Updating the record with medical prescription
 Printing bill of doctor charges
Employee and Salary Management System
 Attendance and schedule of employees

7
 Holiday approvals
 Schedule of consulting doctors
 EPF/ETP and OT calculation
 Shares of consulting doctors
 Shares of doctors who has sent patient for lab test and ECG
Mini Theatre and Ward Management
 Details of surgeon
 Surgery success/failure details
 Complications of the patient, patient history and other details
 Bill calculation and reports
Vehicle and Transport Management
 Ambulances management
 Vehicle deployment handling
 Time management
 Drivers and employee details
 Billing calculations
Exercise ‘Zumba’ and Patient Management
 Patient management
 Weight loss and height increase
 Abdominal circumference
 Progress report
 Package details
Emergency Treatment and Equipment Management
 Emergency patient Details
 Issue ECG reports
 Billing calculations
 Lab equipment stock management
Pharmacy Stock Management
 Drug stock management

8
 Expiry notification
 Billing calculation
 Searching
Lab Management
 Record sample collection details
 Lab resources management
 Lab report conclusion generation
 Bill calculation
 Lab equipment stock management
2.3
Figure 2.2 1

9
2.3 User Classes and Characteristics
● Admin
Admin has the full access to the system which means he is able to manage any
activity with regard to the system. He is the highest privileged user who can access to the
system.
Key functions
✓ Manage employees, patients and equipment
✓ Allocate resources
✓ Administer the charges
✓ Generate reports
✓ Manage ambulances
✓ Manage doctors
✓ Manage salaries
● Employee
Interacts with the systems most often to supply service to customers
Key functions
✓ Keep track of patient details
✓ Keep tract of test details
✓ Make ambulance reservations
✓ Keep track of progress of patients
✓ Maintain bill details
✓ Manage inventory

10
2.4 Operating Environment
Software requirements
● Windows 7 or above operating system
● JRE 1.8
● MySQL server
Hardware Requirements
● Core i5 processor
● 4GB Ram
● 20GB of hard disk space in terminal machines
● 1TB hard disk space in Server Machine
2.5 Design and Implementation Constraints
● System is wirelessly networked with an encryption
● System is only accessible within the hospital premises only.
● Database is password protected.
● Should use less RAM and processing power.
● Each user should have individual ID and password.
● Only administrator can access the whole system.

11
2.6 Project Documentation
Software Life Cycle Phase Documentation Intended Activities
Requirement Gathering,
Analysis and Specification
● Project charter
● Project proposal
● Software Requirement and
Specification (SRS) which
includes
✓ Entity relational diagram
✓ Data flow diagrams
✓ Use case diagrams
✓ Use case scenarios
Includes the customer expected
software features, constraints,
interfaces and other attributes.
Moreover the objectives and the
benefits gained through the
system are clearly specified
Software Design ● Software Design
Description(SDD)
Describes the logical basis of
design decisions taken and how
it will pave way in acquiring the
requirements of the customer
through the software
Implementation ● Technical Documentation Contains information regarding
the implementations of the
system using the programming
concepts
Software Testing ● Software Test
Documentation(STD)
Includes information degrading
testing procedures to validate and
verify the software results. Main
types of testing techniques are
unit testing, integration testing,
system testing and acceptance
testing
Maintenance ● User Documentation Includes manuals for the end
users according to their position
of access levels

12
2.7 User Documentation
As a part of the system itself a user documentation is provided to the customers which
gives an overview of the system. It will include the full description about the product and
complete orderly followed steps to install the software. The users will get the opportunity to use
the system without having any trouble. The user manual will include the email addresses to
contact us in need. Tasks are listed alphabetically or logically grouped often using cross
referenced indexes which helps the users to know exactly what sort of information they are
looking for.
2.8 Assumptions and Dependencies
● Each user must have a valid user id and password
● Server must be running for the system to function
● Users must log in to the system to access any record.
● Only the Administrator can delete records.

13
3. External Interface Requirements
3.1 User Interfaces

14

15

16

17

18

19

20

21

22

23
3.2 Hardware Interfaces
 Laptop/Desktop PC
o core i5 processor
o 4GB RAM
o 500GB HDD
Purpose of this pc is to give information when Patients ask information about doctors,
medicine available lab tests etc. To perform such Action it need very efficient computer
otherwise due to that reason patients have to wait for a long time to get what they ask for.
 Display Unit (LED/LCD Monitor/TV)
This unit is for display the channel number when the patients come
to see their consultants. It will avoid chaos. And also display
Hospital welcome screen, video, information etc.
 Laser Printer (B/W)
Simply this device is for printing bills and view reports.
 Wi-Fi router
Wi-Fi router is used to for internetwork operations inside of a
hospital and simply data transmission from pc’s to sever.
Figure 3.2 1
Figure 3.2 2
Figure 3.2 3
Figure 3.2 4

24
3.3 Software Interfaces
Developing end
 JDK 1.8 - Java is fast, secure, and reliable. From laptops to
datacenters, game consoles to scientific
supercomputers, cell phones to the Internet,
 Netbeans 8.1 - IDE for Java developing.
 MySQL server - Database connectivity and management
 Adobe Photoshop cs4 - Logo and other designing such as User interfaces
Client End
 OS – Windows 7/8/8.1- Very user friendly and common OS
 JRE 1.8 - JAVA Runtime Environment for run Java
Application and System
 MySQL server - Database connectivity
3.4 Communications Interfaces
 NIC (Network Interface Card) - It is a computer hardware component that allows a computer to
connect to a network. NICs may be used for both wired and wireless connections.
 CAT 5 network cable- for high signal integrity
 TCP/IP protocol- Internet service provider to access and share information over the
Internet
 Ethernet Communications Interface- Ethernet is a frame-based computer network
technology for local area networks (LANs)
 Ubiquitous, easy to set up and easy to use. Low cost and high data transmission rates.

25
4. System Features
USE CASE Diagram

26
USE CASE Scenarios
Name Add patient Entry
Description This function get details of a patient and add
record to the patient file and generate a patient
registration number
Actors Data entry operator, receptionist
Pre-conditions The operator should login with user account
Main flow of events 1. User sele ts add patie t e try at ho e
page
2. Patient entry form displayed
3. User enter data to required fields
4. User sele ts Add entry utto
5. Successfully record added essage
displayed.
6. System generates a patient Id and
display.
extensions 3) A) if necessary fields left by user prompt user
to enter all required fields.
Post conditions Patient record added to patient file.
Name Issue clinic numbers
Description This function assign a number to a patient for the
relevant channeling.
Actors Receptionist
Pre-conditions Patient must register to the system
Main flow of events 1. User sele ts ge erate a u er at OPD
module.
2. System prompts to select the clinic type.
3. If OPD, generates next available number
to available doctor and display number
4. User confirm number and print card.
extensions 3) a) if channeling a counselor, system prompts
the counselling field and doctor
3) b) user enter counselling field and doctor
3) C system generates next available number for
required counsellor.
Post conditions Patient channeling record should updated with
patient details.

27
Name Add prescription entry
Description This function records patients prescription details
Actors Data entry operator
Pre-conditions Doctor’s prescription chit must be issued.
Main flow of events 1. User sele ts Pres riptio for from
patient module
2. “yste pro pts to e ter patie t s
registration number
3. User enter system registration number
4. Prescription form displayed with relevant
patient details.
5. User a igates to tests field and selects
prescribed test details
6. User navigates to vaccine field and
select prescribed vaccine details
7. User navigates to edi i e field and
enter medicine details.
8. User enter re-consolation date.
9. User selects Add button and add
prescription details.
10. User selects pri t and print the
prescription details.
Name Calculate bill
Description This function calculate total charge for the patient
Actors Receptionist, cashier
Pre-conditions THz patient must register to the system
Main flow of events 1. User selects patient receipt card
2. System prompts patient registration
number
3. User enter registration number
4. System prompts date and time , which
the total charge required for
5. User enter the date and time
6. Receipt form displayed with patient
details, lab tests details, X-ray details,
ECG details etc. and total fee in number
and in word.
7. User select print receipt.
8. The patient receipt is printed
Post conditions The payment details should updated in payments
file.

28
Name Mark attendance
Description this function records employees attendance details
Pre-conditions User should login with the user account.
Manually recorded attendance details records
should be available
Main flow of events 1. E ployee attendance for selected by
user in employee management module
2. User enter date
3. User enter the employee ID that did not
attend particular date.
4. User selects update.
5. System prompts to add another record
6. User a s ers o
7. The form will be closed
extensions 6) a) if user answered ‘ yes’ , repeated 3) 4) until
user selects ‘ no’
Name Add Patient diagnosis history
Description This function add patient’s diagnosis details to
the system.
Pre-conditions Patient must register to the system
Main flow of events 1. User selects patient diagnosis card
2. System prompt patient Id
3. User enter patient Id
4. System display patient details in the form
5. User enter diagnosis details and date
6. User selects Add diagnosis record.
Post conditions The diagnosis record should added to the
diagnosis file.
Name Manage ambulance
Description This function manage all ambulance details
Pre-conditions User should login to the system
Main flow of events 1) user sele ts A ula e i ehi le
2) system prompts to enter vehicle details
3) user enters vehicle details
4) user select add entry
5) syste display su essfully re ord
added essage a d ge erates
vehicle ID

29
Name Generate salary
Description This function generates employee salary for given
period of time
Actors Accountant
Pre-conditions User should login with user account
Main flow of events 1. User sele ts Ge erate salary for i
employee management module
2. System prompts employee Id and time
period
3. User enter required data
4. User selects generates salary.
5. The total salary calculated by the system
and displayed
6. User select print pay slip
7. System print the salary pay slip
extensions 3) a) User enters allowance details if any.
Post conditions The payments file should updated with
salary payment record
Name Schedule counselling doctors
Description This function mange’s counsellors charging details
Actors Accountant
Pre-conditions User sound login to the system
Main flow of events 1) user selects cancelling doctor form in
employee module
2) system prompts do tor s Id
3) user enters id
4) system display councilor doctor details
5) user selects get visit hours and generated
sari details
6) user select generate counsellor charge
7) system calculates total counselor change to
be paired and display
extensions 5 ) a) system generates total visit hours
5 ) b) 1 ) system prompts time period and field (lab
tests, ECG, all) to generate shares
5) B) 2) user select period and field.
5 )b) 3) system generates total share amount

30
Name Search ambulance
Description This function displays the availability of a vehicle
Actors Receptionist
Pre-conditions User log in to the system
The ambulance management form should available
Main flow of events 1) user selects search button in ambulance
management form
2) system proms to select search
type(search by vehicle, search available
list)
3) user selects type(search by vehicle)
4) user enters vehicle id
5) system displays the availability and
vehicle details
extensions 3) a) if search type is available lists display available
vehicle list
Name Deploy vehicle
Description This function handles the vehicle deployment
process
Actors Receptionist
Main flow of events 1) user selects ambulance in vehicle module
2) user sele ts deploy ehi le
3) system prompts vehicle id
4) user enters vehicle id
5) system checks for availability of the vehicle
and display details
6) system prompts hiring clients details
7) user enters client details
8) user selects calculates cost
9) system generates cost and display
10) user sele ts Deploy ehi le
extensions 5 ) a) 1) if vehicle is not available system prompts
distance to the vehicle
5 ) a) 2) a) user enters distance or selects “generate
distance”
5) A) 2) b) if user selects generate distance system
prompts the available location, user enters the
location, system generates the distends t the location.
5 ) a) 3) system generates assumed time period for
the vehicle to be available at hospital and display
10 ) a) if required print the pay slip
Post conditions Vehicle file should updated to deploy details

31
Name Register client –Sumba exercise
Description This function registers the clients for rumba
exercise classes
Actors Receptionist
Main flow of events 1) user selects rumba exercise
management form
2) system prompts to add client details
3) user add client details
4) system prompts to select package
5) user selected package
6) user selects generates costs system
prompts to select period(daily,
monthly)
7) user selected period
8) system generates and display fee
9) user confirm details and selects Add
client
10) system view successfully record
added message and generate Id
Name View Progress- rumba exercise
Description This function generates progress reports for
rumba exercise courses of individual clients
Actors Manager
Pre-conditions User should login o the system
The rumba exercise module should available
Main flow of events 1) user selects view progress
2) system prompts client id
3) user enters id
4) system prompts time period
5) user enters time period
6) System prompts to select report type
(chart, detailed info...)
7) user enters report type
8) system generates reports and view
extensions 8 ) a) if required print the reports

32
Name Generate lab report
Description This function generates the report of a particular
test and print the report
Actors Lab assistance
Pre-conditions User should login
Relevant lab test results should be available
Main flow of events 1) user selects lab report form from lab
tests module
2) system prompts patient id
3) user enter patient id
4) system display patient details
5) system prompts to selects lab test
category
6) user selects category by navigating to
relevant tab and enter test results
7) user selects add lab test record
8) system display successfully added
message
9) user selects print report
10) system prints the report
extensions

33
ER Diagram
5.

34
Other Nonfunctional Requirements
5.1 Performance Requirements
 Response time-The system will give responses within 1 second after checking the patient
information and other information.
 Capacity-The system must support 1000 people at a time
 User interface- User interface screen will response within 5 seconds.
 Conformity –The system must conform to the Microsoft accessibility
5.2 Safety Requirements
If there is extensive damage to a wide portion of the database due to catastrophic failure,
such as a disk crash, the recovery method restores a past copy of the database that was backed up
to archival storage and reconstructs a more current state by reapplying or redoing the operations
of committed transactions from the backed up log, up to the time of failure.
5.3 Security Requirements
All the administrative and data entry operators have unique logins so system can
understand who is login in to system right now no intruders allowed except system
administrative nobody cannot change record and valuable data.
5.4 Software Quality Attributes
 AVAILABILITY: The system shall be available all the time.
 CORRECTNESS: A bug free software which fulfill the correct need/requirements of the
client.
 MAINTAINABILITY: The ability to maintain ,modify information and update fix
problems of the system
 USABILITY: software can be used again and again without distortion.
 ACCESSIBILITY: Administrator and many other users can access the system but the
access level is controlled for each user according to their work scope.

35
 ACCURACY: The reliability on the information/output. Can depend/be sure of the
outcome.
 STABILITY: The system outcome/output won’t change time to time. Same output will
be given always for a given input.
5.5 Business Rules
 Want take the responsibility of failures due to hardware malfunctioning.
 Warranty period of maintaining the software would be one year.
 Additional payments will be analysed and charged for further maintenance
 If any error occur due to a user’s improper use. Warranty will not be allocated to it.
 No money back returns for the software.
 Trust bond placement should be done before designing and coding. An advance or an
Agreement.

Hospital management system_software_requ

More Related Content

What's hot (20)

Similar to Hospital management system_software_requ (20)

Recently uploaded (20)

Hospital management system_software_requ