<Enter team name here>

<Enter project name here>

Feasibility Report
Version <1.0>
12/22/2020

© 2020 <Enter team name here> <Drive:\Directory\Filename.ext>

Feasibility Report

Document Control
Approval
The Guidance Team and the Customer shall approve this document.

Document Change Control

Initial Release:
Current Release:
Indicator of Last Page in Document:
Date of Last Review:
Date of Next Review:
Target Date for Next Update:

Distribution List
This following list of people shall receive a copy of this document every time a new version of this document
becomes available:
Guidance Team Members:
Mrs. Wafa Al-Tarawneh
Customer:
Software Team Members: <<Your Names Here>>

Change Summary
The following table details changes made between versions of this document

Version Date Modifier Description

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 2
Feasibility Report

Table of Contents

DOCUMENT CONTROL II
APPROVAL II
DOCUMENT CHANGE CONTROL II
DISTRIBUTION LIST II
CHANGE SUMMARY II

1. INTRODUCTION 3
1.1. PURPOSE OF THE FEASIBILITY REPORT 3
1.2. JUSTIFICATION FOR THE PROPOSED SYSTEM 3
1.3. REQUIREMENTS DEFINITION 3
1.4. USE CASES (FIRST LEVEL ABSTRACTION) 3
1.4.1. Actors 3
1.4.2. Use Case Descriptions 3
2. CONSIDERATIONS 3
2.1. ONTOLOGY TOOLS 3
2.1.1. Protégé 3
2.1.2. WebODE 3
2.2. DATABASE SYSTEMS 3
2.2.1. Oracle 3
2.2.2. MySql 3
2.3. INFERENCE ENGINES 3
2.3.1. Flogic 3
2.3.2. Jess 3
2.3.3. CLIPS 3
2.4. PLATFORMS AND LANGUAGE 3
2.4.1. C++ 3
2.4.2. Prolog 3
2.4.3. Lisp 3
2.4.4. Net 3
3. SOLUTIONS 3
3.1. SOLUTION 1 3
3.1.1. Description 3
3.1.2. Requirements 3
3.1.3. Resources Needed 3
3.1.4. Limitations 3
3.2. SOLUTION 2 3
3.2.1. Description 3
3.2.2. Requirements 3
3.2.3. Resources Needed 3
3.2.4. Limitations 3
4. COMPARISON OF SOLUTIONS 3
5. CONCLUSIONS 3

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 3
Feasibility Report

6. REFERENCES 3

1.

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 4
Feasibility Report

2. Introduction
<< BEFORE YOU BEGIN:
This outline is structured in sections. To display section breaks, headers and footers, from the View menu, point
to Page Layout. To add information to a chapter, insert the information before a section break to ensure it flows
onto the next page properly. Information inserted after a section break disrupts the header and footer layout
scheme and results in incorrect pagination. For more information about section breaks, consult Microsoft
Word’s online help. >>

1.1. Purpose of the Feasibility Report

The purpose of this system is to automate the process of day to day activities of the hospital such as admission
of new patient, discharge of patient and finally compute the bill.

1.2. Justification for the Proposed System

   The proposed software product in the Hospital Patient Management System (HPMS). The system will be
used to allocate beds to patients on a priority basis, and to assign doctors to patients in designated wards as
need arises. Doctors will also use the system to keep track of the patients assigned to them Nurses who are in
direct contact with the patients will use the system to keep track of available beds, the patients in the
different wards, and the type of medication required for each patient.

1.3. Requirements Definition

- 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

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

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

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

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 5
Feasibility Report

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

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

1.4. Use Cases (first level abstraction)

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 6
Feasibility Report

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 The operator should login with user account
account
Main flow of events 1. User selects “add patient entry “
Patient entry form displayed

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 7
Feasibility Report

3. User enter data to required fields

4. “Successfully record added” message 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 Add Patient diagnosis history

Description This function add patient’s diagnosis details to the
system.
Actors Data entry operator
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
Actors Data entry operator
Pre-conditions User should login to the system
Main flow of events 1) user selects “Ambulance ” in vehicle
2) system prompts to enter vehicle details
3) user enters vehicle details
4) user select add entry
5) system display “successfully record
added” message and generates
vehicle ID

Name Schedule counselling doctors

Description This function mange’s counsellors charging details
Actors Accountant
Pre-conditions User sound login to the system

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 8
Feasibility Report

Main flow of events 1) user selects cancelling doctor form in employee

module
2) system prompts doctor’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

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 user selects search button in ambulance management

form
user enters vehicle id
system displays the availability and vehicle details
extensions 3) a) if search type is available lists display available
vehicle list

Name Calculate bill

Description This function calculate total charge for the patient
Actors Receptionist, cashier
Pre-conditions THz patient must register to the system

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 9
Feasibility Report

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.

1.1.1. Actor

Front-desk staff(receptionist):
they all have general reception and secretarial duties. Every staff has some basic computer training. They are
responsible for patient’s check-in or notification of appropriate people.

Administrators: 
They all have post-secondary education relating to general business administration practices. Every
administrator has basic computer training. they are responsible for all the scheduling and updating day/night
employee shifts. Administration in the wards are responsible for assigning doctors and nurses to patients. 

Doctors:
All doctors have a medical degree. Some have further specialized training and are computer literate. Doctors
will use the HPMS to check their patient’s lists.

1.1.2. Use Case Descriptions

receptionists’ details of a patient and add record to the patient file and generate a patient registration number

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 10
Feasibility Report

3. Considerations
1.5. Ontology Tools
1.1.3. Protect

1.1.4. WebODE

1.6. Database Systems

1.1.5. Oracle

1.1.6. MySql

A query language for RDBMS based on. Non –procedure approach to retrieve record
from RDBMS.
SQL was proposed by IBM and got its standardization by ANSI and adopted by different corporation with bit
modification.

SELECT [*|ALL] FROM <TABLE> [WHERE <CONDITION”] <ORDER BY [<FIELD>]

1.7. Inference Engines

1.1.7. Flogic

1.1.8. Jess

1.1.9. CLIPS

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 11
Feasibility Report

1.8. Platforms and Language

1.1.10. html

1.1.11. PHP

1.1.12. CSS

1.1.13. javascript

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 12
Feasibility Report

4. Solutions
1.9. Solution 1

1.1.14. Description
This system (HMS) provides online storage/ updating and retrieval facility. This system promises very less or no
paper work and also provides help to Doctor and operational staff. In this system everything is stored
electronically so very less amount of paper work is required and information can be retrieved very easily
without searching here and there into registers

1.1.15. Requirements

1.1.16. Resources Needed

<< Include software, hardware, experience, training >>

1.1.17. Limitations
Lack of security of data.
Time consuming.
Consumes large volume of paper work .
Manual work
No direct role for the higher officials

1.10. Solution 2
1.1.18. Description

1.1.19. Requirements

1.1.20. Resources Needed

<< Include software, hardware, experience, training >>

1.1.21. Limitations

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 13
Feasibility Report

5. Comparison of Solutions
<< This section should discuss how each option measures up against any constraints set forth in the statement of
requirements and how each compares with the others.
Include the following:
• Specific hardware and software requirements
• Time constraints
• Ease of use
• Staffing levels and training required
• User preference
• Security issues
A matrix that compares features is required. >>

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 14
Feasibility Report

6. Conclusions
<< Summary and recommendations >>

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 15
Feasibility Report

7. References
<< All information in the above text that comes from outside sources should be cited. All references that are
cited should be enumerated below. >>

Feasibility Report <Enter team name here> Date Page

12/22/2020 10:55 PM 16