table of contentsfaculty.kutztown.edu/tan/csc354/datafiles/new/354/brow… · web viewthe director...

Software Requirements SpecificationVersion 2.4

Browser Team

Mamadou S Diallo

Tamara Jennings

Alexander Posipanko

Jordy Then

David Vera

Perrillen Zuniga

CSC 354

Dr. Tan

Software Requirements Specification November 11, 2018

Table of ContentsTable of Contents……….……….…….………….……….……….……….……….……….……….……….……….……….……….………. i

REVISION HISTORY……….……….…..….……….……….……….……….……….……….……….……….……….……….……………… ii

1.0 INTRODUCTION……….…………..….……….……….……….……….……….……….……….……….……….……….……………. 1

1.1 Purpose of Document……….……….……….……….……….……….……….……….……….……….……….……….……….. 1

1.2 High-Level Product Overview……….……….……….……….……….……….……….……….……….……….………………. 1

1.3 Explanatory Material: Acronyms & References……….……….……….……….……….……….……….………………. 2

2.0 PROJECT CONSIDERATIONS……….……….……….……….……….……….……….……….……….……….……….……………. 3

2.1 Identified Costs……….……….……….……….……….……….……….……….……….……….……….……….……….………… 3

2.2 Possible Tools……….……….……….……….……….……….……….……….……….……….……….……….……….…………... 3

2.3 Open Issues and Questions……….……….……….……….……….……….……….……….……….……….……….………… 4

2.4 Long-Term Plans for Future Releases and Features……….……….……….……….……….……….……….……….. 5

2.5 Standards and Regulatory Considerations……….……….……….……….……….……….……….……….……………. 5

3.0 PROJECT SCOPE……….……….……….……….……….……….……….……….……….……….……….……….……….…………… 6

3.1 Administrative Perspective……….……….……….……….……….……….……….……….……….……….……….………… 6

3.2 User Profile……….……….……….……….……….……….……….……….……….……….……….……….……….……………… 6

3.3 Director Perspective……….……….……….……….……….……….……….……….……….……….……….……….…………. 6

3.4 CNO Perspective……….……….……….……….……….……….……….……….……….……….……….……….……………….. 6

3.5 User Interface Map……….……….……….……….……….……….……….……….……….……….……….……….…………… 7

4.0 SYSTEM ARCHITECTURE DESIGN……….……….……….……….……….……….……….……….……….……….……….…… 8

5.0 FUNCTIONAL REQUIREMENTS……….……….……….……….……….……….……….……….……….……….……….……….. 9

5.1 Browser Version Functional Requirements……….……….……….……….……….……….……….……….…………… 9

5.2 Family Mobile Application Version Functional Requirements……….……….……….……….……….………… 20

5.3 CNA Mobile Application Version Functional Requirements……….……….……….……….……….……………. 22

5.4 Tablet Version Requirements……….……….……….……….……….……….……….……….……….……….……………. 24

5.5 Database and Hardware Functional Requirements……….……….……….……….……….……….……….………. 25

6.0 NONFUNCTIONAL REQUIREMENTS……….……….……….……….……….……….……….……….……….…..….……….. 28

7.0 USE CASE DIAGRAM……….……….……….……….……….……….……….……….……….……….……….……….……………. 30

8.0 USE CASE DESCRIPTIONS……….……….……….……….……….……….……….……….……….……….……….……………… 33

8.1 Account Management……….……….……….……….……….……….……….……….……….……….……….……………… 33

8.2 Task Management……….……….……….……….……….……….……….……….……….……….……….……….………….. 35

8.3 Help and Support……….……….……….……….……….……….……….……….……….……….……….……….……………. 38

8.4 Schedule Management……….……….……….……….……….……….……….……….……….……….……….……………. 39

ii


REVISION HISTORYThe up-to-date revision history is listed in Table 1. As changes to this document are made, the table will be edited to reflect them.

Version Date Description Editor1.0 10/22/2018 Created Document Tamara Jennings1.1 10/23/2018 Edited:

Section 1.0: IntroductionSection 1.1: Purpose of documentSection 1.2: High-Level Product OverviewSection 1.3: Explanatory Material

(Acronyms and References)

Mamadou Diallo

1.2 10/24/2018 Edited:Section 2.0: Project ConsiderationSection 2.1: Possible ToolsSection 2.2: Open Issues and Questions

Perrillen Zuniga

1.3 10/25/2018 Edited:Section 3.6: System Architecture DiagramSection 2.3: Open Issues and Questions

Jordy Then

Edited:Section 6.0: Use Case Diagrams

Alexander Posipanko

1.4 10/27/2018 Edited:Section 3.0: Project ScopeSection 3.1: Administrative PerspectiveSection 3.2: Director PerspectiveSection 3.3: CNO Perspective

Mamadou Diallo

Edited:Section 6.0: Use Case DiagramsSection 7.1: Account Management

Alexander Posipanko

Edited:Section 1.1: Purpose of DocumentSection 2.1: Identified CostsSection 2.3: Open Issues and Questions

Perrillen Zuniga

1.5 10/28/2018 Edited:Section 2.4: Long-Term Plans for Future Releases and FeaturesSection 2.5 Standards and Regulatory Considerations

David Vera

Edited:Section 4.0: Functional Requirements

Jordy Then

1.6 10/29/2018 Edited:Section 3.4 User ProfileSection 3.5 User Interface MapSection 4.0 Functional Requirements

David Vera

iii


Edited:Section 5.0 Nonfunctional Requirements

Mamadou Diallo

Edited:Section 4.0 Functional Requirements

Perrillen Zuniga

1.7 10/30/2018 Edited:Section 2.2 Possible ToolsSection 2.4 Long-Term Plans for Future Releases and FeaturesSection 3.4 User Profile

David Vera

Edited:Section 4.0 Functional Requirements

Tamara Jennings

Edited:Section 6.0 Use Case DiagramsSection 7.1 Account ManagementSection 7.2 Task ManagementSection 7.3 Survey ManagementSection 7.4 Schedule Management

Alexander Posipanko

Edited:Section 1.2 High Level Product OverviewSection 2.5 Standard and RegulatoryConsiderationsSection 3.1 Administrative PerspectiveSection 3.2 Director Perspective

Mamadou Diallo

Edited:Section 5.0 Non-Functional Requirements

Jordy Then

1.8 10/31/2018 Edited:Section 5.0 Non-Functional RequirementsSection 7.3 Survey ManagementSection 7.4 Schedule Management

Alexander Posipanko

Edited:Table of ContentsSection 1.0 IntroductionSection 3:0 Project Scope

Tamara Jennings

2.0 11/8/18 Edited:Section 1.0: IntroductionSection 1.1: Purpose of documentSection 1.2: High-Level Product Overview

Mamadou Diallo

2.1 11/9/18 Edited:Section 4.0 Functional Requirements

Alexander Posipanko

2.2 11/10/18 Edited:Section 3.0 Project ScopeSection 4.0 Functional RequirementsSection 7.0 Use Case Diagrams

Alexander Posipanko

Edited:Section 2.1 Identified CostsSection 4.0 Functional Requirements

Perrillen Zuniga

2.3 11/11/2018 Edited: Alexander Posipanko

iv


Section numberingSection 4.0 Functional RequirementsSection 7.0 Use Case DiagramSection 8.1 Account ManagementSection 8.2 Task ManagementSection 8.3 Help and SupportSection 8.4 Schedule Management

Edited:Section 2.3 Open Issues and QuestionsSection 3.1 Administrative PerspectiveSection 3.2 User ProfileSection 3.3 Director PerspectiveSection 3.4 CNO Perspective

Perrillen Zuniga

Edited:Section 3.6 System Architecture DiagramSection 3.5 User Interface MapSection 4.0 Functional RequirementsSection 8.2 Task ManagementSection 8.3 Help and SupportSection 6.0 Non-Functional RequirementsSection 2.2 Possible Tools

Jordy Then

Edited:Section 2.4 Long-Term Plans for Future Releases and FeaturesSection 2.5 Standards and Regulatory ConsiderationsSection 3.2 User Profile

David Vera

Edited:Section 6.0 Nonfunctional RequirementSection 2.0 Project Considerations

Mamadou Diallo

Edited:Section 1.0 IntroductionSection 2.1 Identified CostsSection 2.2 Possible ToolsSection 5.0 Functional Requirements

Tamara Jennings

2.4 11/12/18 Edited:Section 6.0 Nonfunctional RequirementsSection 7.0 Use Case DiagramSection 8.1 Account Management

Alexander Posipanko

Edited:Section 3.5 User Interface MapSection 8.0 Use Case Descriptions

Tamara Jennings

Table 1: Revision History

v


vi


1.0 INTRODUCTIONA Software Requirements Specification (SRS) is a document that describes the nature of a project, software or application. It specifies the features of a system and how it is expected to behave. Software requirements specification establishes the basis for an agreement between the client and the LTC-TMS.

1.1 Purpose of DocumentThe purpose of this document is to provide information about the scope, functional and nonfunctional requirements, software and hardware requirements, use case diagrams and use case descriptions for the Long-Term Care-Task Management System.

Section 2.0 explains project consideration for creating a functioning system, including cost, tools, and issues that may affect the completion of the system.

Section 3.0 describes the scope of the project from the perspective of different users of the system.

Section 4.0 lists all functional requirements that cover all aspects of the system. They must be met those requirements before they are considered complete.

Section 5.0 looks at non-functional requirements, which are used to judge the system’s behavior.

Section 6.0 shows how certain actors (users of the system) interact with the system through use case diagrams.

Section 7.0 contains use case descriptions for the system.

1.2 High-Level Product OverviewThe purpose of this project is to create a functional long-term care management system that incorporates information from external sensors to measure relevant information, such as step count, heart rate, and room temperature. The LTC-TMS will be available to patients and their families to view patients’ information as well as tasks. It will also be available to CNAs, allowing them to add and make changes to a patient’s record. The system will also be used by the management personnel of the facility to keep track of staff information and facility schedules. Additionally, hardware will be installed in rooms as well as worn by patients to collect sensory information. This information will be transmitted wirelessly to a database so that facility staff can view them in the task management system on both a desktop browser and a mobile application.

1


1.3 Explanatory Material: Acronyms & ReferencesThe acronyms and terms listed in Table 2 are used throughout this document.

Acronym Full Name

Account User login information

AI Artificial Intelligence

Client A long-term care facility that uses the system

CNA Certified Nurse Assistant, a staff member that works directly with patients

CNO Chief Nursing Officer, a staff member in charge of CNAs and administration

CSS Cascading Style Sheets

Facility Long-term care location using the system

HTML Hypertext Markup Language

IDE Integrated Development Environment

KU Kutztown University of Pennsylvania

LTC-TMS Long Term Care-Task Management System

MCU Ming Chuan University of Taiwan

Patient A person receiving treatment at the Long-Term Care facility

Portfolio Container for information associated with a particular user

RFP Request for Proposal

RMP Risk Management Plan

SPP Software Project Plan

SRS Software Requirements Specification

SSL Secure Socket Layer

Table 2: Acronyms & References

2


2.0 PROJECT CONSIDERATIONSThis section provides details about what is needed to create a functioning system. It will contain the estimated costs of the tools used to build the system, issues that could arise during the project, a long-term plan for the LTC-TMS, and legal standards that must be considered.

2.1 Identified CostsTo complete this project, the project team must obtain several hardware and software resources.

Hardware components are the costliest resources at this time. The Computer Science and Information Technology Department at KU will generously loan some of the hardware including two Raspberry Pi 3B (version 1.2 2015) kits. Each kit contains a power cord, a case, a 16GB micro SD card, a heat sink, and a 150Mbps wireless 802.11b/n Nano USB adapter. The rest of the hardware and their quantities are listed in Table 3.

Item QuantityMicro:Bit: 83-17934 4Temperature & Humidity Sensor: DHT11

2

Heart Rate Sensor: 101020082 2Grove Shield for Micro-Bit 2Air Quality Sensor: SHARP GP2Y1014AU0F

2

Microchip MCP3008-I/P MCP3008 8-Channel 10-Bit A/D Converters

2

Rechargeable batteries 1 pack of 4T-GPIO expansion board with 40 pin connectors

2

Table 3: Hardware Quantities

In addition to hardware, software components are also crucial to the development of the system. The project team will be using Google’s Firebase as a database and web hosting solution. Google offers free services for up to 1GB of stored data, 50 000 reads/day, 20 000 writes/day, 20 000 deletes/day, and 1-GB/month of network egress. This project is not expected to reach these limits, so the free plan will suffice. Another consideration deals with publishing applications on Apple’s App Store. A license is required to publish, and this costs $99/year. However, Apple offers a fee waiver for educational institutions such as KU as long as the institution does not profit from the application. The project team is in the process of applying for this waiver.

2.2 Possible ToolsListed below are the possible tools used for developing the LTC-TMS.

Type of Tool Tool How it will be usedDatabase Firebase Realtime

DatabaseIt will hold data and information of the system. It will store data such as daily vital status and tasks, along with fetching the stored data.

Web Hosting Firebase Hosting It will host the browser version of the LTC-TMS.

3


Type of Tool Tool How it will be usedText Editor Notepad++ It is an IDE that will be used to develop the browser version

of the LTC-TMS because it supports JavaScript and many other programming languages. It is available only on Windows machines.

Sublime It is an IDE that will be used to develop the browser version of the LTC-TMS because it supports JavaScript and many other programming languages. It is available on a handful of operating systems including MacOS.

File Sharing Google Drive It is a cloud-based storage service. It allows team members to work simultaneously on the same document. It has been used to write various documents including SRS, SPP, RMP, RFP, etc.

Version Control GitHub It will be used for code sharing. Members of the project team will be able to work on the code simultaneously. It also shows a revision history and allows individuals to work on their own repository.

Communication Slack It will be used for communication between teams and individuals. It is good for quick communication.

Google Hangouts It will be used for video calls with MCU. It will also be used when team members are unable to physically attend team meetings

Single Board Computer

Raspberry Pi 3B It is the computer responsible for sending data to the database via WIFI.

Sensors Temperature & Humidity Sensor: DHT11

It is the sensor responsible for measuring the temperature and humidity of a room in the facility.

Air Quality Sensor: SHARP GP2Y1014AU0F

It is the sensor responsible for measuring the air quality of a room in the facility

Heart Rate Sensor: 101020082

It is the sensor responsible for measuring the heart rate of a patient

Embedded System Micro:Bit: 83-17934 It is a real-time operating system that is will be used to collect information from the sensors and transmit it to the single board computer to be sent to the database.

Table 4: Tools and Their Roles in LTC-TMS

2.3 Open Issues and QuestionsThe most important issue that users of LTC-TMS deal with is data security. Patients’ information is confidential and should be available to be viewed by the family and facility staff only if permission is granted by the patient. The public should not be able to view patient’s data and there will be security measures in place to prevent data breaches, such as a secure login with a password. Other possible issues that will be encountered by the users of LTC-TMS will be the traditional difference in the work field. Facilities may be reluctant to change from using paperwork to execute their duties to a digital system. The transition from physical paperwork to digital devices might affect their work efficiency due to unfamiliarity with the system. Another possible issue is dealing with the means of managing inaccurate data. Other than obvious outlier data that are easily detectable as inaccurate, there is no

4


certainty that the data received from the sensors will display accurate data all the time. Also, there are issues and concerns as to whether this system will compete with other robust patient and staff management software currently deployed in caregiving institutions. LTC-TMS might not consist all the necessary functions that a facility would need at the moment. This might raise questions as to the effectiveness and practicality of the functions that LTC-TMS will provide.

2.4 Long-Term Plans for Future Releases and FeaturesThe browser version of the LTC-TMS is intended to support the management of the long-term care facility with its daily tasks and activities. If the basic requirements for the system are met, the project team will look to implement the following improvements:

● Provide for a variety of languages (ex. French, Spanish, etc.)● Real-time browser updates● Integration with other mainstream sensors such as smart watches● User page personalization

2.5 Standards and Regulatory ConsiderationsThe Web browser team will make sure that they are operating within the boundaries of the law. Additionally, malpractice that may risk confidential files being publicized must also be considered. The theft of personal data could result in lawsuits and/or fines from law enforcement. The LTC-TMS must abide by the Health Insurance Portability and Accountability Act of 1996. This act addresses the use and disclosure of individuals’ health information. Misusing the system will result in a review of the situation, and the project team will be required to improve upon it so that the likelihood of further misuse is minimized.

5


3.0 PROJECT SCOPEThe LTC-TMS will consist of software and hardware components. The software components are the web application and mobile applications. The browser application will be available to the Director and CNO of a facility employing LTC-TMS. The browser version will let the Director and CNO manage staff and patient portfolios, create announcements, create and view tasks, monitor patient status records, and add schedules. The mobile application version will be available to CNAs and patients and their family. The mobile application version and the tablet version allow CNAs to monitor patient tasks, input patient data, and view facility schedules and announcements. The mobile version will also allow patients and families to view patient information and the facility schedule. The sensors will be used to collect data regarding air quality, humidity and temperature of rooms in the facility and the heart rate of the patient.

3.1 Administrative PerspectiveThe administrator of the LTC-TMS will have access to create and edit Director's portfolios. They will also have access to manage updates to the applications as they arrive from the development team.

3.2 User ProfileThe Director and the CNO are the intended users of the browser version of LTC-TMS. The main purpose of the browser version of the LTC-TMS is to input patient information to be displayed to the users on the app version of the system. The Director and CNO will have similar functions regarding the use of the LTC-TMS browser version, but the major difference is the director’s clearance to create and edit portfolios.

3.3 Director PerspectiveThe director will be the only one who can create and edit portfolios for each staff member and the patient at the facility. In addition, the director will be allowed to create and edit announcements and tasks. The director will also be able to upload staff and facility schedules. The director must have basic computer skills such as typing, uploading files, using a web browser and understanding the LTC-TMS browser version capability.

3.4 CNO PerspectiveThe CNO will not be able to create or edit any portfolio and is not allowed to access Director’s account, but they will be able to view portfolios, create and edit announcements, and assign task instructions. The CNO will also have the ability to upload staff and facility schedules. The CNO must have the basic knowledge of computer skills such as typing, uploading files, using a web browser and understanding capabilities of the LTC-TMS browser version.

6


3.5 User Interface MapThe user interface map of the LTC-TMS browser version is shown in Figure 1. The box represents the web pages while the arrows illustrate the menu path throughout the application. The starting page is the home page and CNO/CNA can then log into their account in the Login web-page. Once logged in, CNO/CNA are directed to their profile page where they can choose from 7 different web-pages.

Figure 1: User Interface map

7


4.0 SYSTEM ARCHITECTURE DIAGRAMFigure 2 displays the system architecture that depicts the operating environment of the LTC-TMS. Firstly, the hardware consists of Raspberry Pi, Micro:Bit, heartbeat rate sensor, and temperature and humidity sensor. Then a database is used to hold all the data gathered from the sensors, along with other data like account information and user tasks. A server will gather requests from the end users and send back responses. Lastly, the front end-task assistant provides information from the database to the end users. The front end-task assistant will be the homepage where the family of the patients can view the patient’s daily vital status and activities. Also, the back end-task manager is an interface for the Director and CNO to edit the patients’ information as well as provide facility staff the ability to edit and add tasks to their profiles.

Figure 2: System Architecture of LTC-TMS

8


5.0 FUNCTIONAL REQUIREMENTSThe tables below demonstrate the functional requirements for LTC-TMS. Each requirement is assigned an ID and a detailed description. The requirements are also classified into related categories and assigned a priority. Priority designates the importance of the requirement to the project with 1 indicates a requirement that the application needs to have. Priority 2 denotes a requirement that is good to have. Priority 3 denotes a requirement that is not important, but it is nice to have.

5.1 Browser Version Functional RequirementsThe functional requirements for the browser version of LTC-TMS are listed in Table 5.

Category Requirement ID

Requirement Description Priority

Create and Edit Portfolio

1 Director must be able to create a portfolio.

When a new staff/patient joins the Facility, Director should be able to create Portfolio.

1

2 Director must be able to edit existing portfolio.

When a patient/staff changes their information, Director should be able to edit the Portfolio.

1

3 Director must be able to view an existing portfolio.

Director should be able to review the staff/patient Portfolio.

2

4 Director must be able to embed picture(s) into the portfolio.

Given that a new staff/patient joins the care center, Director must upload the person’s picture.

1

5 CNO must be able to view an existing portfolio.

CNO should be able to review existing staff/patient Portfolio.

2

6 Director must be able to remove an existing portfolio.

When a staff/patient quits the facility, Director should be able to remove an existing portfolio.

1

Create and Edit Announcement

7 Director must be able to create an Announcement.

When Director wants to deliver news, they must be able to create a new Announcement

1

8 CNO must be able to create an Announcement.

When CNO wants to deliver news, they must be able to create a new Announcement

1

9 Director must be able to edit existing

Given there is an error in the published announcement,

1

9




Announcement. Director must be able to edit an Announcement.

10 CNO must be able to edit existing Announcement.

Given there is an error in the published announcement,CNO must be able to edit an Announcement.

1

11 Director must be able to delete existing Announcement.

Given there is an unwantedAnnouncement, Director must be able to delete an Announcement.

1

12 CNO must be able to delete existing Announcement.

Given there is an unwantedAnnouncement, CNO must be able to delete an Announcement.

1

Create and Edit Memo

13 Director must be able to create a Memo

If Director needs a personal reminder, they must be able to create a memo.

1

14 CNO must be able to create a Memo

If CNO needs a personal reminder, they must be able to create a memo.

1

15 Director must be able to edit a Memo.

Given that a memo must be changed, Director must be able to edit memos.

1

16 CNO must be able to edit a Memo.

Given that a memo must be changed, CNO must be able to edit memos.

1

17 Director must be able to delete a Memo.

Deleting Memo allows Director to delete unwanted Memo.

1

18 CNO must be able to delete a Memo.

Deleting Memo allows CNO to delete unwanted Memo.

1

View Status Record

19 Director must be able to view the daily status record.

After CNA submitted a patient’s daily status record of the day, Director must be able to view it.

1

20 CNO must be able to view the daily status record.

After CNA submitted a patient’s daily status record of the day, CNO must be able to view it.

1

21 Director must be able After CNA submitted a patient’s 1

10




to view vital status record.

vital status record of the day, Director must be able to view it.

22 CNO must be able to view vital status record.

After CNA submitted a patient’s vital status record of the day, CNO must be able to view it.

1

23 Director must be able to view AI status record.

After CNA have submitted patients AI status record of the day, Director must be able to view it.

1

24 CNO must be able to view AI status record.

After CNA have submitted patients AI status record of the day, CNO must be able to view it.

1

25 Director must be able to select a group of patients filtered by room numbers

When Director has to input status records, Director must be able to find every patient's name listed according to the room number.

2

26 CNO must be able to select a group of patients filtered by room numbers

When CNO must input status records, CNO must be able to find every patient's name listed according to the room number.

2

Create and Edit Event

27 Director must be able to create an event.

When there is a new event for the facility, Director must be able to create a new event.

1

28 CNO must be able to create an event.

When there is a new event for the facility, CNO must be able to create a new event.

1

29 CNO must be able to edit an event.

When an event is inaccurate, Director must be able to edit an event

1

30 CNO must be able to edit an event.

When an event is inaccurate, CNO must be able to edit an event

1

31 Director must be able to key in event's date

After an event is created, Director must be able to set event's date

1

32 CNO must be able to key in event’s date

After an event is created, CNO must be able to set event's date

1

33 Director must be able When there is an error in the date 1

11




to edit an event's date

of an event, Director must be able to edit the event's date.

34 CNO must be able to edit an event’s date.

When there is an error in the date of an event, CNO must be able to edit the event's date.

1

35 Director must be able to delete event.

When an event is expired or invalid, Director must be able to delete an existing event.

1

36 CNO must be able to delete event.

When an event is expired or invalid, CNO must be able to delete an existing event.

1

Upload Work Schedule and Working Hour

37 Director must be able to upload schedule file(s).

Given that a work schedule file is to be uploaded, Director must be able to upload the file.

1

38 CNO must be able to upload schedule file(s).

Given that a work schedule file is to be uploaded, CNO must be able to upload the file.

1

39 Director must be able to delete uploaded schedule file(s).

After file expired/out of date, Directors are allowed to remove the file from the website.

1

40 CNO must be able to delete uploaded schedule file(s).

After file expired/out of date, CNO are allowed to remove the file from the website.

1

Create and Edit Task

41 Director must be able to create a new task.

When a lesson or command needed to be delivered, Director must be able to create new task instruction.

1

42 CNO must be able to create a new task.

When a lesson or command needed to be delivered, CNO must be able to create new task instruction.

1

43 Director must be able to add main steps to a task.

After a task has been created, Director must be able to add the main step to a certain task when needed.

1

44 CNO must be able to add main steps to a

After a task has been created, CNO must be able to add the main step

1

12




task. to a certain task when needed.

45 Director must be able to add detail steps to a task.

After the main step has been created, Director must be able to add a detail step to each main step correspondingly.

1

46 CNO must be able to add detail steps to a task.

After the main step has been created, CNO must be able to add a detail step to each main step correspondingly.

1

47 Director must be able to remove task.

Given that a task is no longer needed, Directors should be able to remove task instruction

1

48 CNO must be able to remove task.

Given that a task is no longer needed, CNO should be able to remove task instruction

1

49 Director must be able to remove the main steps from a task.

When a main step is not needed, Director should be able to delete that main step.

1

50 CNO must be able to remove the main steps from a task.

When a main step is not needed, CNO should be able to delete that main step.

1

51 Director must be able to remove detailed steps from a task.

When a detailed step should be removed, Director must be able to delete a detail step.

1

52 CNO must be able to remove detailed steps from a task.

When a detailed step should be removed, CNO must be able to delete a detail step.

2

53 Director must be able to embed image(s) into a task.

If an image can help explain a step, Director must be able to upload an image.

2

54 CNO must be able to embed image(s) into a task.

If an image can help explain a step, CNO must be able to upload an image.

2

55 Director must be able to embed video(s)

Given that the steps for a given task require a demonstration, Director

2

13




into a task. should be able to upload a video.

56 CNO must be able to embed video(s) into a task.

Given that the steps for a given task require a demonstration, CNO should be able to upload a video.

2

57 Director must be able to access a task from the database.

When Director wishes to edit a task, Director must be able to retrieve the task data from the database.

1

58 CNO must be able to access task from the database.

When CNO wishes to edit a task, CNO must be able to retrieve the task data from the database.

1

59 Director must be able to edit a task.

When a task’s information needs to be changed, Director should be able to change task information.

1

60 CNO must be able to edit a task.

When a task’s information needs to be changed, CNO should be able to change task information.

1

61 Director must be able to save unfinished tasks as draft.

Saving tasks before completion would give flexibility to Director to work on a task at different times

2

62 CNO must be able to save unfinished tasks as draft.

Saving tasks before completion would give flexibility to CNO to work on a task at different times

2

63 Director must be able to save completed tasks to the Task Library

Once a task is completed, it must be saved to the Task Library.

1

64 CNO must be able to save completed tasks to the Task Library.

Once a task is completed, it must be saved to the Task Library.

65 Director must be able to create a new keyword for a task.

Keywords allow tasks to be found without knowing their full name

2

66 CNO must be able to create a new keyword for a task.

Keywords allow tasks to be found without knowing their full name

2

14




67 Director must be able to choose an existing keyword for a task.

Preset keywords allow tasks to be found without knowing their full name using common keywords.

2

68 CNO must be able to choose an existing keyword for a task.

Preset keywords allow tasks to be found without knowing their full name using common keywords.

2

69 Director/CNO must be able to edit the main steps of a task.

Given that the main steps of a task need to be changed, Director must be able modify the main steps.

1

70 Director/CNO must be able to edit the main steps of a task.

Given that the main steps of a task need to be changed, CNO must be able modify the main steps.

1

71 Director should be able to reorder the main steps when creating a task.

The Director can switch step positions instead of deleting and rewriting the step.

2

72 CNO should be able to reorder the main steps when creating a task.

CNO can switch step positions instead of deleting and rewriting the step.

2

73 Director should be able to reorder the main steps when editing a task.


2

74 CNO should be able to reorder the main steps when editing a task.

CNO can switch step positions instead of deleting and rewriting the step.

2

75 Director must be able to edit detailed steps.

When the detailed steps must be changed, Director must be able to edit the detailed step.

2

76 CNO must be able to edit detailed steps.

When the detailed steps must be changed, CNO must be able to edit the detailed step.

2

77 Director should be able to reorder

The Director can switch step positions instead of deleting and

2

15




detailed steps when creating a task.

rewriting the step.

78 CNO should be able to reorder detailed steps when creating a task.

The CNO can switch step positions instead of deleting and rewriting the step.

2

79 Director should be able to reorder detailed steps when editing a task.


2

80 CNO should be able to reorder detailed steps when editing a task.

The CNO can switch step positions instead of deleting and rewriting the step.

2

Assign Tasks 81 Director must be able to distribute a task to specific groups or individuals.

Director wishes to send a task to a specific group of users/individuals.

1

82 CNO must be able to distribute a task to specific groups or individuals.

CNO wishes to send a task to a specific group of users/individuals.

1

83 Director must be able to cancel assigned task(s).

In the event a task is no longer applicable to its assignee(s), the Director should be able to un-assign the task.

2

84 CNO must be able to cancel assigned tasks

In the event a task is no longer applicable to its assignee(s), the CNO should be able to un-assign the task.

2

View Task Library

85 Director must be able to view Task Library.

After a task is created, Director should be able to view it in the task library.

1

86 CNO must be able to view Task Library.

After a task is created, CNO should be able to view it in the task library.

1

Login 87 Director must be able Director with an account must be 1

16




to log in with the provided account.

able to login to the browser version of LTC-TMS.

88 CNO must be able to log in with the provided account.

CNO with an account must be able to login to the browser version of LTC-TMS.

1

Logout 89 Director must be able to logout of their session.

Director must be able to logout from the browser version of LTC-TMS.

1

90 CNO must be able to logout of their session.

CNO must be able to logout from the browser version of LTC-TMS.

1

Query Function 91 Director is able to search for information using keywords.

Director is able to search for information by inserting keyword on the query function

3

92 CNO is able to search for information using keywords.

CNO is able to search for information by inserting keyword on the query function

3

Voice Input 93 Director is able to dictate information to be translated to text.

Director’s speech will be translated to text.

3

94 CNO is able to dictate information to be translated to text.

CNO’s speech will be translated to text.

3

Voice Output 95 Director is able to listen to the information when the sound icon is clicked.

Director is able to listen to a voice version of the information the sound icon is clicked.

2

96 CNO is able to listen to the information when the sound icon is clicked.

CNO is able to listen to a voice version of the information the sound icon is clicked.

2

Show QR Code 97 User is able to scan QR code from the home page.

User is able to scan QR code from the home page to go to the app version of LTC-TMS in both English and Chinese version.

2

17




View Help and Support

98 Director is able to view the help and support page.

Director is able to view the help and support page when they want to view comments and suggestions from users.

2

99 CNO is able to view the help and support page.

CNO is able to view the help and support page when they want to view comments and suggestions from users.

2

100 Director is able to submit feedback on the system.

Director is able to add comments and suggestions for the system.

3

101 CNO is able to submit feedback on the system.

CNO is able to add comments and suggestions for the system.

3

Language 102 Director should be able to choose the language in which they want to view the system.

Director would be able to select the language they prefer which would increase usability

3

103 CNO should be able to choose the language in which they want to view the system.

CNO would be able to select the language they prefer which would increase usability

3

Browser Support

104 Director must be able to use the system on Chrome browser.

Director should be able to use the system on the browser of their choice including Chrome

1

105 CNO must be able to use the system on Chrome browser.

CNO should be able to use the system on the browser of their choice including Chrome

1

106 Director must be able to use the system on Firefox browser.

Director should be able to use the system on the browser of their choice including Firefox.

1

107 CNO must be able to use the system on Firefox browser.

CNO should be able to use the system on the browser of their choice including Firefox.

1

18




108 Director must be able to use the system on Safari browser

Director should be able to use the system on the browser of their choice including Safari.

1

109 CNO must be able to use the system on Safari browser

CNO should be able to use the system on the browser of their choice including Safari.

1

110 Director must be able to use the system on Internet Explorer browser

Director should be able to use the system on the browser of their choice including Internet Explorer.

1

111 CNO must be able to use the system on Internet Explorer browser

CNO should be able to use the system on the browser of their choice including Internet Explorer.

1

Table 5: Browser Version Functional Requirements

19


5.2 Family Mobile Application Version Functional RequirementsThe functional requirements for the mobile application version of LTC-TMS with a family member as the intended user are listed in Table 6.



User Login 1 Family must be able to login to the system.

Family will be provided with default login info, which can be changed to enable secure login.

1

Tasks Instruction Viewing

2 Family must be able to select the instruction type.

All task instructions are created from the browser page and this enables Family to select the instruction type.

1

3 Family must be able to view the page of tasks instruction list.

System will list task instructions on the page.

1

4 Family must be able to view task instructions.

A task instruction is composed with text, video and a PDF file.

1

Daily Status Record Viewing

5 Family must be able to view Daily Status Record page

Users are able to select “Daily Status Record” at hamburger menu page.

1

6 Family must be able to access a Status Record page by date.

In the page, users need to select a date in order to let the app to show the status record data for the selected date.

1

7 Family must be able to view status record with a selected date.

After selecting a date, the status record data will be shown to family.

1

Announcement Board Viewing

8 Family must be able to enter home page and view the announcement board.

App will retrieve announcement board information from the LTC-TMS database that is generated in the browser version.

1

Portfolio Viewing

9 Family must be able to enter and view portfolio page.

App will retrieve portfolio information from the database that is created using the LTC-TMS browser. Family can only view the portfolio for their family member.

1

20




Feedback Sending

10 Family must be able to send feedback.

Family is able to submit the feedback to the database which is also forwarded to CNO/Director.

1

11 Family ID must be captured along with the feedback sent back.

Each feedback is entitled to a user, for CNO/Director to locate and reply the user.

1

Voice Output 12 Family is able to listen to the information when they click on the sound icon as voice.

Family are able to listen to a voice version of the information when click on the sound icon.

2

Voice Input 13 Family is able to input information using their voice.

Family are able to speak into the device to input data in fields when tapping the microphone icon.

1

Table 6: Family Mobile Application Version Requirements – Family User

21


5.3 CNA Mobile Application Version Functional RequirementsThe functional requirements for the mobile application version of LTC-TMS with a CNA as the intended user are listed in Table 7.

Category Requirement ID Requirement Description Priority

User Login 1 A CNA must be able to login to the system.

CNA will be provided with default login info, which can be changed to enable secure login.

1

Tasks Instruction Viewing

2 A CNA must be able to select the instruction type.

All task instructions are created from the browser page and this enables a CNA to select the instruction type.

1

3 A CNA must be able to view the page of tasks instruction list.

System will list task instructions on the page. 1

4 A CNA must be able to view task instructions.

A task instruction is composed with text, video and a PDF file. 1

Daily Status Record Viewing

5 A CNA must be able to view Daily Status Record page

Users are able to select “Daily Status Record” at hamburger menu page. 1

6 A CNA must be able to access a Status Record page by date.

In the page, users need to select a date in order to let the app to show the status record data for the selected date.

1

7A CNA must be able to view status record with a selected date.

After selecting a date, the status record data will be shown to family. 1

Announcement Board Viewing 8

A CNA must be able to enter home page and view the announcement board.

App will retrieve announcement board information from the LTC-TMS database that is generated in the browser version.

1

Portfolio Viewing 9 A CNA must be able to enter and view portfolio page.

App will retrieve portfolio information from the database that is created using the LTC-TMS browser.

1

Center Schedule Viewing

10A CNA must be able to view all the center schedules for the month.

Home page will show a sample table that include events for 5 days (past 2 days/today/next 2 days)

1

11A CNA must be able to view all the center schedules for the month.

If a CNA clicks on the Center schedule on home page, the app opens the calendar for the current month. Users can switch to different months for the center schedule.

1

Working Schedule Viewing 12

A CNA must be able to view working schedule for the month.

CNA can select the work schedule in menu page, which opens the working schedule page. The CNA is able to switch months and view data.

1

Working hour data Viewing

13 A CNA must be able to view the number of hours they work for

CNA can select work schedule in menu page, the app will direct to working

1

22



the month. hour page, and also allow CNA to switch months and view data.

Feedback Sending

14 A CNA must be able to send feedback.

CNA is able to submit the feedback to the database, which is also forwarded to CNO/Director.

1

15A CNA’s ID must be captured along with the feedback sent back.

Each feedback is entitled to a user, for CNO/Director to locate and reply the user.

1

Voice Output 16A CNA is able to listen to the information when they click on the sound icon as voice.

CNA is able to listen to a voice version of the information when click on the sound icon.

2

Voice Input 17 A CNA is able to input information using their voice.

CNA are able to speak into the device to input data in fields when tapping the microphone icon.

1

Table 7: Family Mobile Application Version Requirements – CNA User

23


5.4 Tablet Version RequirementsThe functional requirements for the tablet version of LTC-TMS with a CNA as the intended user are listed in Table 8.


Patient from a room selection 1 A CNA must be able to select a

patient from the room.

When the CNA initiate the tablet version, he/she needs to select a patient from a room in order to update the selected patient’s status.

1

Daily Status Updating

2 A CNA must be able to input data.

The CNA needs to be able to fill in data to the fields, and select appropriate checkboxes provided on the tablet version.

1

3A CNA must be able to identify themselves before submitting the data to the database.

Each batch of data submitted to the database is identified with the CNA in charge.

1

4A CNA must be able to receive the confirmation of the data entered.

Before the data is stored in the database, the CNA receives a pop-up dialog box to ensure the accuracy of the data.

1

Vital Status Updating

5A CNA must be able to update vital status hence the privilege to input data.

The CNA needs to be able to fill in data to the fields provided on the tablet version.

1

6A CNA must be able to identify themselves before submitting the data to the database.

Each batch of data submitted to the database is identified with the CNA in charge.

1

7A CNA must be able to receive the confirmation of the data entered.

Before the data is stored in the database, the CNA receives a pop-up dialog box to ensure the accuracy of the data.

1

AI Status Viewing 8A CNA is able to view the patient’s automated recorded status.

There are sensors placed in the center as well as on the patient’s wearables, the CNA are able to view the collected data of the patient which is organized and displayed on the tablet version.

1

Voice Input 9 A CNA is able to input information using their voice.

A CNA is able to speak into the device to input data in fields when tapping the microphone icon.

1

Table 8: Tablet Version Requirements – CNA User

24


5.5 Database and Hardware Functional RequirementsThe functional requirements for the database and hardware used in LTC-TMS are listed in Table 9.



Database 1 Create a new instance of Firebase.

Although KU and MCU are both using Firebase for the project, KU will have their own instance of Firebase to have their own independent data for testing and processing.

1

Database 2 Implement the database’s structure in JSON format, which consists of key and value pairs.

The same JSON structure will be utilized as MCU for transparency of the LTC-TMS project.

1

Database 3 Bridge communication with the LTC-TMS system.

The database administrators will permit communication to the LTC-TMS system so that data is accessible to the browser website and mobile applications.

1

Database 4 Add a data field to the database.

The database consists of JSON documents that are turned into JSON objects by Firebase. These objects take in and properly store incoming data from an application. These JSON documents organize the data into key and value pairs (data fields). If a new type of data is needed to be stored in the system then a new data field will be added into the database via the proper JSON document.

2

Database 5 Remove a data field from the database.

The database consists of JSON documents that are turned into JSON objects by Firebase. These objects take in and properly store incoming data from an application. These JSON documents organize the data into key and value pairs (data fields). If part of an application is discontinued and the data it was sending to the database is no longer needed then the data field will be deleted via JSON document.

2

25




Reporting 6 Generate report from LTC-TMS system.

Generate a daily, weekly, and/or monthly report. The report may include text or bar charts. The report will be in PDF format.

2

Reporting 7 Send report via email in PDF format.

Send the report via email from the LTC-TMS system.

2

Reporting 8 Store reports in the database.

Store report history inside of database. 2

Hardware 9 Build the wearable device for patient to record their vitals.

Constructing the wearable technology for the patient will be fulfilled using the hardware components purchased.

1

Hardware 10 Assemble the raspberry pi with a case for each room.

Each room will have a raspberry pi that will receive the data from the wearable device the patient has and send it to the database.

1

Hardware 11 Maintain the hardware.

This will involve ensuring the battery is charged and wearable is functioning for the CNA to use with the patient.

1

Hardware 12 Log data from the sensors.

When sensors are being used, the DB/HW team will be responsible for ensuring the proper data is being captured (e.g. heart rate sensor recording heart rate, not another vital).

1

Hardware 13 Send data to the DB over WIFI.

The hardware device will be capable of sending patient vitals (data) over Wifi connection to the database.

1

Hardware 14 Sensor will send data to Micro:Bit via radio frequency.

Patient vital data will be sent over radio frequency from the sensors to the Micro:Bit

1

Hardware 15 Ensure that Micro:Bit and sensor use the same radio frequency.

Each sensor will be channeled to the same radio frequency as the Micro:Bit.

1

Hardware 16 Ensure the patient does not inadvertently break

The wearable sensors will be worn in a location that would not be in the way of the patients day to day life

3

26




the device.

Hardware 17 Ensure the security of the hardware device.

The CNA and CNO will monitor the device throughout the day, ensuring it does not leave the room.

2

Notifications 18 Family and CNA must be able to receive notifications via the mobile app.

If CNO/Director makes any changes or post then the system will generate a notification in the browser version. Then the app will retrieve notification and sent to Family and CNA

3

Notifications 19 Alerts and Notifications displays on mobile notifications bar must be seen viewable by the Family/CNA.

While the alert/ notification is displayed on the notification bar the system generates a notification within the system.

3

Table 9: Database/Hardware Requirements

27


6.0 NONFUNCTIONAL REQUIREMENTSNonfunctional requirements can be described as how a program must behave. They are not feature requirements that must implemented in the system. For example, attributes such as real-time Response, reliability, and usability are not a "feature" of the system but are required characteristics.

Requirement Purpose How the requirement will be measured

Real-time Response

The browser version must respond to user input as quickly as possible. This will involve setting up the database, server, and web app in a way that allows for speed and efficiency.

Servers and databases have tools and options to enable faster service of data. By using these tools, the system can fine tune it to get the real-time requirements to a reasonable level.

Reliability Since the browser version in theory will be used by seniors who are having issues remembering how to do simple tasks, it is important that the application has a high reliability with minimum downtime.

Reliability can be measured under times of heavy traffic. Tests will also be done to see how efficient the LTC-TMS is responding to queries. The Browser team will execute multiple performance tests using high number of users, for example, 500 users will be assigned a task concurrently during the afternoon. The result will determine the reliability of the browser version of the application.

Usability The requirements are often expressed in learning time or similar metrics. Determine the training that users will have with computers, mobile devices, and web apps to ensure use comes naturally or with minimal time-consuming training.

Since the number of senior citizen users will outnumber the amount of supervisors (Director, CNO, CNA), the system will be required to be nearly self-explanatory to account for the difference in technology levels between supervisors and senior citizens. Measuring this will be quantitative statements regarding the feedback made by a sample base of the user’s demographics. It can also be measured through a series of experiments regarding how quickly someone can perform tasks within the website.

28


For example, novice users are expected to perform a number of tasks within 8 minutes while experienced users are expected to perform a number of tasks within 4 minutes. The results will determine the usability aspect of the system.

Table 10: Nonfunctional Requirements

29


7.0 USE CASE DIAGRAMUse case diagrams show how certain actors (users of the system) interact with the system. Use cases, the things that the users of the system are able to do, are shown in ellipses. The actors, or users of the system, are represented with a stick figure and its relationship with the use cases are shown with lines connecting the use cases with the actors.

Figure 3 – UML Use Case Diagram Format

30


Figure 4 – CNO Perspective Use Case Diagram

31


Figure 5 – Director Perspective Use Case Diagram

32


8.0 USE CASE DESCRIPTIONSThis section contains use cases descriptions for the project’s functional requirements. These descriptions will detail how a user interacts with the browser version of the LTC-TMS and the expected results. The use case descriptions also consider how the functional requirement will be implemented and executed from a backend perspective. The following use case descriptions are given in this section:

1. Create CNA Portfolio2. Create a Task – CNO 3. Assign a Task – CNO 4. View Feedback on the System – Director 5. Upload Working Schedule – CNO

8.1 Account ManagementThe use case for creating a staff portfolio is described in Table 11.

Use case name: Create CNA Portfolio

Functional Requirement: 1

Scenario: The director wishes to create a portfolio for a CNA in the system.

Brief Description: A new staff member has been hired and needs a portfolio in the system to be able to perform their duties.

Actors: Director

Stakeholders: Director, CNA

Preconditions: 1. The director has an existing account and the CNA to be added to the system does not have an existing portfolio.

2. The director is on the portfolio page of the site.

Postconditions: 1. The CNA being added to the system has a portfolio associated with them.

Flow of Activities:

Actor System

1. Select portfolio on the navigation bar.

2.1 Select staff option.

2.2 Click the add button to create the new portfolio.

1.1 Backend system serves the portfolio page from the database.

2.1 System displays page.

2.2 System displays a new portfolio page for the staff.

33


3. Enter information and click upload button when finished.

3.1 System sends data to the database.

Exceptions: ● CNA already has a portfolio

Related Use Cases: Edit Portfolio, Delete Portfolio

Table 11: Use Case Description - Create a Staff Portfolio

34


8.2 Task ManagementThe use case for creating a task is described in Table 12.

Use case name: Create a Task – CNO


Scenario: The CNO needs to deliver a lesson or command to one or more patients

Brief Description: CNO creates a new task and the system stores the task into its database.

Actors: CNO

Stakeholders: CNO, Patient

Preconditions: 1. CNO must be logged in

Postconditions: 1. The task is stored in the database.2. The task can be viewed in the library page.

Flow of Activities:

Actor System

1. CNO selects the Task Editor section of the navigation bar.

2. CNO clicks the review box.

3. CNO selects “add new task”.

4. CNO enters task information and clicks submit button.

1.1 System displays task editor page.

2.1 System displays drop-down menu, including option to add new task.

3.1 System displays new empty editable task page.

4.1 System sends request to database and inserts new task to the database.

Exceptions: ● Data loss while adding new tasks due to poor connection from the database to the user, causing tasks to not be saved.

Related Use Cases: Edit Task – CNO, Delete Task – CNO, Create Task – Director, Edit Task – Director, Delete Task – Director

Table 12: Use Case Description - Create a Task

35


The use case for assigning a task is described in Table 13.

Use case name: Assign a Task – CNO


Scenario: CNO wishes to assign a task to a group of users.

Brief Description: An existing task is assigned to a specific group of users.

Actors: CNO

Stakeholders: CNO, Patients

Preconditions: 1. Task to be assigned exists in the database2. User group the task is to be assigned to exists in the database

Postconditions: 1. Task is assigned to a specific group of users.

Flow of Activities:

Actor System

1. CNO selects the Task Editor section of the navigation bar.

2. CNO clicks the review box.

3. CNO clicks option to assign task

4. CNO selects the task to assign and clicks.

5. CNO selects the group to which the task will be assigned.

1.1 System displays task editor home page.

2.1 System displays drop-down menu, including option to edit existing tasks.

3.1 System displays list of tasks.

4.1 System retrieves information about the chosen task from the database.

4.2 System displays the task in the task editor.

4.3 System displays list of users groups which the task can be assigned to.

5.1 System stores the task association in the database.

Exceptions: ● The group that the task is being assigned to doesn’t exist.

36


Related Use Cases: Assign Task – Director, Cancel Assigned Task – CNO, Cancel Assigned Task – Director

Table 13: Use Case Description - Assign a Task

37


8.3 Help and SupportThe use case for viewing feedback on the system is described in Table 14.

Use case name: View Feedback on the System – Director


Scenario: Director wishes to view feedback from family of a patient.

Brief Description: Director views feedback from family of a patient.

Actors: Director

Stakeholders: Director, family member

Preconditions: 1. Director is logged on

Postconditions: 1. Feedback is stored on the system’s database.

Flow of Activities:

Actor System

1. Director selects the Center Schedule section of the navigation bar.

2. Director clicks “view feedback” button.

1.1 System displays help and support page, including a button to view feedback.

2.1 System retrieves feedback responses from the database

2.2 System displays page containing feedback.

Exceptions: ● Connection prevents content from being successfully loaded and displayed.

Related Use Cases: View Feedback on the System – CNO

Table 14: Use Case Description - Review Feedback on the System

38


8.4 Schedule ManagementThe use case for uploading a working schedule is described in Table 15.

Use case name: Upload Working Schedule – CNO


Scenario: CNO wishes to upload a working schedule for the facility staff.

Brief Description: A working schedule is uploaded to the system’s database by the CNO.

Actors: CNO

Stakeholders: CNO, CNA

Preconditions: 1. CNO is logged in2. Schedule file is acceptable size and format

Postconditions: 1. Schedule is added to the database

Flow of Activities:

Actor System

1. CNO selects Center Schedule in the navigation bar.

2. CNO selects a user from the page

3.1 CNO uploads new schedule image/document.

3.2 CNO Presses upload button

1. System displays center schedule page.

2.1 System retrieves schedule items associated with the user from the database

2.2 System shows button to upload new schedule item.

3.1 System displays active “upload” button.

3.2 System send new schedule document to the database.

Exceptions: ● Connection causes upload to fail.

Related Use Cases: Delete Working Schedule – CNO, Upload Working Schedule – Director, Delete Working Schedule – Director

Table 15: Use Case Description – Upload Working Schedule

39

table of contentsfaculty.kutztown.edu/tan/csc354/datafiles/new/354/brow… · web viewthe director...

Documents