3.

1 Software Requirements Specification

3.1.1 Introduction This chapter illustrates the Requirement Specifications in

developing a Health Care Facility System. This section gives details all about the functional features of the software, along with the interface, design constraints and related considerations such as Database management. The Software Requirements Specification is intended for the users of the newly developed software for the Local Government Unit.

3.1.1.1 Goals and Objectives The underlying concepts are the goals and objectives of Health Care Facility System: a. Recording of Diseases occurred in municipals and Barangay. b. Allocation of vaccine and drugs request and re-order point of medicines and estimated life span of medicine. c. User-friendly, easy-to-use & web-enabled applications d. Guides citizens through a preliminary eligibility check for individual programs, and provides a recommendation whether to proceed with submitting an application. e. Enhancing the communication and establishing cooperation between the Barangay and the municipal.

3.1.1.2 Statement of Scope This part includes the description of the software functionality followed by detailed requirements. The first part is the login. A user should enter their username and password. The software will determine its privileges. Administrators are responsible for processing and accessing information from the other databases and systems.

Doctor/Assistant Administrator are responsible for processing and accessing information of staffs and patient. Employee/Staffs they are responsible for adding and updating patients information.

Health Care Facility System User Requirements Req. No. Priority Reference Description

Access Privileges R1 High User There shall be three levels of access: administrator, Doctor/Assistant Admin, and Employee/Staff. R2 High User Admin are permitted to add and edit all data. R3 R4 High Med User User Admin are allowed to view audit trails. All user privileges are allowed to view reports. R5 High User Only Administrators can view executive and confidential reports. R6 Med User Staff/employee can only add and update patients info and view limited reports. Security R7 High User Each user is required to login before accessing the services of HCFS. R8 R9 High High User User A password shall be given to each user If password is forgotten, a new

password will be given Reports

R10

High

User

Reports

are

administered

by

administrator/assistant admin only R11 High User Reports are generated from the

information returned by the database of the systems. User Interface R12 High User The system shall have a web-based platform that works with web browsers. R13 High User The system shall respond to all user requests within 25 seconds.

3.1.1.3 Software Context The Health Care Facility System considers the following concepts; the promulgation of national health standards, goals, priorities and indicators; development of special health programs and projects and advocacy for legislation on health policies and programs, it enables to help to secure people primary health, it accesses, analyzes and captures data from the database. With the help of Health Care Facility System, users are capable of making promotion, protection, preservation or restoration of the health of the people through the provision and delivery of health services and through the regulation and encouragement of providers of health goods and services that drive innovative decisions, asking questions and pursuing insights on their own or collaboratively, searching across all their data to get the big picture. 3.1.1.4 Major Constraints The Health Care Facility System is intended to help Local Government Units (LGU) on promoting, protection or restoration of the health of the people through the provision and delivery of the health services and through the regulation and encouragement of providers of health goods and services. As a part of the project it is capable of delivering a full range of reporting,

analysis to enable the decision

to quickly gain new insights and take

actions to drive better outcomes of performance with the flexibility of the Local Government Unit. 3.1.2 Usage Scenario 3.1.2.1 User Profiles The following designations describe the actors in the HCFS. Actor Administrator Description An administrator has the responsibility for adding and editing entities including all confidential and configuration materials. They have limitless access to the system. Assistant admin/Doctor Employee/Staff The assistant has the ability to add and edit only limited entities. The will have limited access to the system. An employee of the LGU will be assigned as an administrator and assistant. System The system refers to the computer hardware and software that controls the application. It accepts user input, displays user output, and interfaces to the Web Server through the Internet. Web Server The Web Server is a remote computer system that maintains the database and serves web pages to the system. Databases Outside databases which data the system needs to create reports.

3.1.2.2 Use-Cases The following use-cases are typical interactions between the external environment and the internal software system.

1. Login 2. Process Reports 3. Display Reports 4. View Reports 5. Check Patient 6. Enter Information 7. Requests Medicines 3.1.2.2.1 Use-Case Diagram The use-case diagram in Figure 1 shows actors that were described in section 3.1.2.1. In order to minimize the complexity of this diagram several connections were left out.

Figure 1: Local Citizens Portal Use-Case Diagram 3.1.2.2.2 Use-Case Descriptions Use-Case: Primary Actor: Goal in Context: Preconditions: Trigger: Scenario: Login Employee/Staff To gain access to the system The employee has a valid username and password An employee needs access to perform a job 1. The System prompts for username and password 2. Employee enters username and password 3. The system sends username to Web Server 4. Web Server return registered password of the username 5. System verifies the password and sets authorization 6. Employee is given access to the system Exceptions: Username and Password cannot be confirmed

Use-Case: Primary Actor: Goal in Context: Preconditions: Trigger: Scenario:

Process Reports Databases, Systems, Administrator To process reports from the databases User should have valid privileges to process and view reports Users want to view reports 1. Administrator logs onto the system 2. Administrator accesses the reports 3. System sends request to the databases 4. Databases returns data 5. System processes it to report 6. Administrator views report

Exceptions:

The database cant fetch data

Use-Case: Primary Actor: Goal in Context: Preconditions: Trigger: Scenario:

Display Report Administrator To set state and properties for displaying reports Valid privileges to set report To do the responsibility of the administrator 1. Administrator logs onto the system 2. Administrator accesses reports 3. Administrator sets properties for displaying of report

Exceptions:

No fetched data

Use-Case: Primary Actor: Goal in Context: Preconditions: Trigger: Scenario:

View Reports Employee, Staff, Web Server, System To view the reports Particular reports are set to certain users Users need/want to view reports 1. User logs into the system 2. User accesses reports 3. Systems determine privileges and sends request to web server 4. Web server return data to system 5. System checks if user have access 6. User views the report

Exceptions:

System checked that user should have no access

Use-Case: Primary Actor:

Enter Patients Info Users, Web Server, System

Goal in Context: Preconditions: Trigger: Scenario:

To store Patient info Certain properties are only accessible to certain users User wants to add Patient Info 1. User logs into system 2. Users add patient info 3. User saves patient info 4. System sends request to store data to web server 5. Web server allows 6. User views data and update

Exceptions:

No data send and returned

3.1.4 Functional Model Description

3.1.2.3 Special usage considerations

The Request of supply feature allows you to send message for other employee that is capable of restocking of supply based from his/her job position. The Request, specified on the HCFS statement, is proportionately distributed to all supply based on the percent of resources that must maintain. If the supply stock reached to zero therefore it cannot be seen on option on any forms that is connected. The Adding of Account to those employees is based on their job position to acquire such account type. Ex: If the employee info inserted position is health worker therefore the account type that he/she can adapt is for limited for the health worker controls only.

3.1.2.4 Activity Diagrams

Figure 3.1.2.4.1: Login Activity Diagram

Figure 1 shows the step process on logging in to system. Each account type has access for some controls of the system.

Figure 3.1.2.4.2: Data Activity Diagram Figure 1 shows the step process on entering data into the system. Each account type has access for some controls of the system.

Figure 3.1.2.4.3: Update Data Activity Diagram Figure 1 shows the step process on updating data into the system. Each account type has access for some controls of the system.

Figure 3.1.2.4.4: Transaction Activity Diagram Figure 1 shows the step process on creating transaction into the system. Each account type has access for some controls of the system.

Figure 3.1.2.4.5: Process Report Activity Diagram Figure 1 shows the step process on viewing of report from the system. Each account type has access for some controls of the system.

3.1.3 Data Model Description

3.1.3.1 Data Objects Account Data Object id employee_id username password type A unique number assigned to an account Reference ID from employee object A name to login to the system Password to login to the system Classification healthworker of user, whether admin, doctor, or

Employee Data Object id fname mname lname gender age status position address Facility A unique number assigned to a employee First name Middle name Last name gender age Status such as Single, Married and etc. Job Position Local Address Reference ID from Facility to locate those healthcare buildings

Patient Data Object id fname mname lname gender age status address type Facility A unique number assigned to a patient First name Middle name Last name gender age Status such as Single, Married and etc. Local Address Specifies the ID for the program of what patient has joined. Reference ID from Facility to locate those healthcare buildings

illness Data Object id name description A unique number assigned to an illness Name of illness Details of illness

Program Data Object id title description A unique number assigned to an program Title of a program Details of a program

Request Data Object id account_id A unique number assigned to an request Reference ID from account to specify whom employee has a request title message Title of request Message created for the request

Supply Data Object id name description type quantity Facility A unique number assigned to an supply Name of supply Details of supply Type of supply Quantity/stock of supply Reference ID from Facility to locate those healthcare buildings

Patient Record Data Object id account_id patient_id illness_id supply_id Date A unique number assigned to an patient record Reference ID from account Reference ID from patient Reference ID from illness Reference ID from supply Date of patient record that has been made

Facility Data Object id name location A unique number assigned to an patient record Name of facility location of healthcare building

3.1.3.2 Relationships 1. Relationship FK_S_ACCOUNT_TYPE_S_EMPLOYEE between S_EMPLOYEE and S_ACCOUNT_TYPE 2. Relationship 3. Relationship 4. Relationship 5. Relationship 6. Relationship 7. Relationship 8. Relationship FK_T_PATIENT_RECORD_S_ACCOUNT_TYPE FK_T_REQUEST_S_ACCOUNT_TYPE FK_T_PATIENT_RECORD_S_SUPPLY FK_T_PATIENT_RECORD_S_ILLNESS FK_T_PATIENT_RECORD_S_PATIENT FK_S_PATIENT_S_PROGRAM FK_S_EMPLOYEE_S_FACILITY between between between between between between S_ACCOUNT_TYPE and T_PATIENT_RECORD S_ACCOUNT_TYPE and T_REQUEST S_SUPPLY and T_PATIENT_RECORD S_ILLNESS and T_PATIENT_RECORD S_PATIENT and T_PATIENT_RECORD S_PROGRAM and S_PATIENT between S_FACILITY and S_EMPLOYEE 9. Relationship FK_SUPPLY_S_FACILITY between S_FACILITY and S_SUPPLY 10. Relationship FK_S_PATIENT_S_FACILITY between S_FACILITY and S_PATIENT

3.1.3.3 Complete Data Model

Figure 3.1.3.3.1: HCFS system Relationship diagram

3.1.4 Functional Model Description 3.1.4.1 Class Diagrams The associations between the different classes are shown in Figure 3.1.3.3.1. The access functions to get and set private data attributes have been removed for clarity.

3.1.4.2 Software Interface Description The Health Care Facility System formed to assist the urban/rural areas that require medical attention and provide a health programs that the government is offering and implementation of such appropriations made by law. The Health Care Facility System will provide essential health care services and requests medicines for the use of the people in the community. Through their full participation and at a free-cost that the community can afford to have a practical means of receiving any form of health care services for expanding populations in poor areas. The essential features of a Health Care Facility System include a customizable interface and the ability to pull real-time data from the database.

Other features of the Executive Dashboard include: a. The easy to navigate and pinpoint the exact reports needed from a dropdown menu or expanding tree; The list reports is viewable by a specific user or group of users. b. Security that gives administrators complete control over the appropriate content for each user. c. Search function based on key words and phrases lets users easily and quickly locate the information they need. 3.1.4.2.1 External Machine Interfaces The software will be capable of printing reports on a local or network printer. 3.1.4.2.2 External System Interfaces The HCFS system will communicate with a Web Server on the internet through a high speed network connection such as DSL or cable.

3.1.4.2.3 Human Interface The web pages shall permit complete navigation using the keyboard alone, in addition to using mouse and keyboard combinations. 3.1.4.3 Reports 3.1.4.3.1 Inventory of Reports 3.1.4.3.2 Layout of Reports 3.1.4.3.3 Data Dictionary of Reports

3.1.5 Behavioral Model Description 3.1.5.1 Description for Software Behavior 3.1.5.1.1 Events User Class Events Add a user Update user details Update user status Assign Type

Employee Class Events Add an Employee Update Employee Assign Employee to user Manage Articles Manage Reports

Facility Class Events Add an Facility Update Facility Assign Supply and Employee Manage Supply Manage Reports

Request Class Events Add an Request Update Request Assign Employee to Request Manage Request

3.1.5.1.2 States User States Assigning Active Inactive On Line Off Line Employee or citizen are being assigned to a user User is active User is inactive The user has logged into the system The user has logged out from the system

Employee States Hired Terminated Add new employee Employee is no longer employed

Request/Complaint Data Object Pending Reviewing Solved Not yet been viewed by authority Message is being reviewed Message has been solved

3.1.5.2 State chart Diagram

Figure 12: HCFS overall state-chart diagram Figure 12 shows the overall state-chart diagram of the HCFS in which we can view different states and process.

3.1.6 Restriction, Limitations, and Constraints The system shall integrate within the Internet and with the existing systems and databases. All HTML code shall be conventional to the HTML 5.0 standard. All server side code shall be written in JAVA. MSSQL server will be the database server of the system. The browsers that are recommended for accessing the system are Google Chrome, Mozilla Firefox, and other superior browsers in the updated version of each.

3.1.7 Validation Criteria 3.1.7.1 Classes of tests Validation testing will be conducted to ensure no free-error environment. Access testing will be implemented to make certain that privileges are not being abused. 3.1.7.2 Expected Software Response The software should display appropriate error and success message to users. The software will not delete any data; it will be archived for future references. 3.1.7.3 Performance Bounds The system shall support simultaneous users. The system shall also provide access to the database with a latency within 20 seconds.