table 1 provides the revision history to the srs...

Software Requirements SpecificationVersion 2.4

Hardware and Database Team

Nicolas Altamirano

Justin Frye

Nolan Perugini

Matt Sauchelli

Lucas Strickland

Tyler Whittaker

CSC 354

Dr. Tan

Software Requirements Specification November 12, 2018

TABLE OF CONTENTSREVISION HISTORY…………………………………………………………………………………………………………………………………… i

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

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

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

1.3 Acronyms & Extrapolations…………………………………………………………………………………………………………….1

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

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

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

2.3 Open Issues and Questions….…………………………………………………………………………………………………………3

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

2.5 Standards and Regulatory Considerations…………………………………………………………………………………….. 4

3.0 PROJECT SCOPE………………………………………………………………………………………………………………………………….5

3.1 Director Perspective……………………………………………………………………………………………………………………… 5

3.2 CNO Perspective…………………………………………………………………………………………………………………………….6

3.3 CNA Perspective……………………………………………………………………………………………………………………………. 6

3.4 Family/Patient Perspective…………………………………………………………………………………………………………….7

4.0 User Interface Map……………………………………………………………………………………………………………………………8

4.1 Browser Version…………………………………………………………………………………………………………………………….8

4.2 Mobile App Version……………………………………………………………………………………………………………………….9

4.3 Tablet App Version………………………………………………………………………………………………………………………10

5.0 SYSTEM ATCHITECTURE DIAGRAM..…………………………………………………………………………………………………11

6.0 FUNCTIONAL REQUIREMENTS………………………………………………………………………………………………………….13

6.1 Hardware/Database Team Functional Requirements……………………………………………………………………13

6.2 Browser Team Functional Requirements………………………………………………………………………………………17

6.3 App Team Functional Requirements……………………………………………………………………………………………. 35

7.0 NON-FUNCTIONAL REQUIREMENTS………………………………………………………………………………………………… 37

7.1 Database Perspective………………………………………………………………………………………………………………….. 37

7.2 Hardware Perspective…………………………………………………………………………………………………………………. 27

8.0 USE CASE DIAGRAMS……………………………………………………………………………………………………………………….40

8.1 Notations Used……………………………………………………………………………………………………………….403


8.2 Use Case Diagram Example…………………………………………………………………………………………….40

8.3 Database Use Case Diagram……………………………………………………………………………………………40

8.4 Hardware Use Case Diagram…………………………………………………………………………………………..42

9.0 USE CASE DESCRIPTIONS………………………………………………………………………………………………………………….43

9.1 Database Use Case Description - Add a Data Field………………………………………………………………………..43

9.2 Database Use Case Description - Create a Firebase Instance…………………………………………………………44

9.3 Hardware Use Case Description - Check Heart Rate………………………………………………………………………47

9.4 Hardware Use Case Description - Hardware Security…………………………………………………………………….48

9.5 Hardware Use Case Description - Build Device……………………………………………………………………………...50

4


REVISION HISTORY

Table 1 provides the revision history to the SRS document. As changes are made, the table will reflect the version, date, description, and editor(s).

Version Date Description Editor

1.0 10/23/18 Added to sections:

6.0 FUNCTIONAL REQUIREMENTS

7.0 NON-FUNCTIONAL REQUIREMENTS

Justin Frye

Added to section:

9.0 USE CASE DESCRIPTIONS

Matt Sauchelli


1.3 Acronyms & Extrapolations

3.1 Director Perspective

3.2 CNO Perspective

3.3 CNA Perspective

3.4 Family/Patient Perspective

4.0 User Interface Map

5.0 System Architecture Diagram

Tyler Whittaker


2.5 Standards & Regulatory Considerations

Justin Frye

Added to sections:

2.0 Project Considerations

2.1 Identified Costs

2.2 Possible Tools

2.3 Open Issues and Questions

2.4 Long-Term Plans for Future Releases and Features

Nicolas Altamirano

5



Added to sections:




Tyler Whittaker

Added to sections:



Lucas Strickland



Justin Frye

Added to sections:

9.1 Database Use Case Description

9.2 Hardware Use Case Description

Lucas Strickland

Added to sections:



Nolan Perugini




Lucas Strickland

Added to section:

3.0 Project Scope

Tyler Whittaker

6



Added to sections:



7.1 Database Perspective

7.2 Hardware Perspective

Justin Frye



Justin Frye

Added to sections:


Matthew Sauchelli


2.0 Project Considerations

2.1 Identified Costs

2.2 Possible Tools

2.3 Open Issues and Questions


2.5 Standards and Regulatory Considerations

Nicolas Altamirano


9.1 Database Use Cases Description


Lucas Strickland


3.0 Project Scope


3.2 CNO Perspective

Tyler Whittaker

7



3.3 CNA Perspective



4.1 Browser Version

4.2 Mobile App Version

4.3 App Version for Tablet

Added to sections:

1.1 Purpose of Document

1.2 High Level Product Overview


Nolan Perugini

Added to sections:


6.1 Hardware/Database Team Functional Requirements

6.2 Browser Team Functional Requirements

6.3 App Team Functional Requirements

Justin Frye








Justin Frye

8




2.4 11/12/18 Added to Sections:

3.0 Project Scope


3.2 CNO Perspective

3.3 CNA Perspective



4.1 Browser Version

4.2 Mobile App Version

4.3 App Version for Tablet

Tyler Whittaker

Added to sections:


2.5 Standards and regulatory considerations



Matt Sauchell

Added to section:


Nicolas Altamirano

Added to sections: Lucas Strickland

9





8.0 USE CASE DESCRIPTION

9. 1 Database Use Case Description - Add a data field

9.2 Database Use Case Description - Create a Firebase Instance

9.3 Hardware Use Case Description - Check Heart Rate

9.4 Hardware Use Case Description - Hardware Security

9.5 Hardware Use Case Description - Build Device

Added to sections:








Justin Frye

Table 1: Revision History

10


1.0 INTRODUCTION

1.1 Purpose of DocumentThis document is the Software Requirements Specification for the Long-Term Care Task Management System. This document is written by and pertains to the hardware, database, and project management team. The purpose of this document is to list all project considerations, define the project scope, enumerate all functional and nonfunctional requirements, and create use case diagrams with proper descriptions. The project considerations section identifies all potential expenses, problems, ongoing questions, and tools. The project scope section lists all functions that the Long-Term Care Task Management System must provide. The section also lists the different roles and actions that each user may take. The User Interface Map section displays the different processing paths that each version of the Long-Term Care Task Management System will follow during use. The System Architecture Diagram section is a visual representation of the flow of information inside the Long-Term Care Task Management System from a hardware perspective. Sections six and seven list all of the functional and nonfunctional requirements. Functional requirements are given a category, requirement ID, description, and priority level. Nonfunctional requirements are given a purpose and a metric used to quantity each requirement. Section eight displays all of the use case diagrams relevant to the hardware perspective of the system. Section nine is comprised of detailed use case descriptions for the database and hardware.

1.2 High Level Product OverviewThe Long-Term Care Task Management System is a product that will provide an electronic system for healthcare facilities to document and manage their patients, facility, and staff. The system will provide applications that are available through a web browser, tablet, and phone. These applications allow staff to document patient information as well as manage their work schedule and store notes relevant to their many tasks on a daily basis. The system provides a hierarchical management interface which allows a Supervisor to delegate and oversee tasks that are given to the Chief Nursing Officer or Certified Nursing Assistant. The Chief Nursing Officer may also oversee and delegate tasks for the Certified Nursing Assistant. The system will gather patient metrics such as heart rate through a wearable device as well as track conditions such as air quality through static hardware located in each patient's room. A database will store all of the information related to the Long-Term Care Task Management System.

1.3 Acronyms & ExtrapolationsListed below in Table 1 are all of the acronyms used in the Software Requirements Specification. All acronyms and definitions may be used interchangeably throughout the document.

11


Acronym Definition

KU Kutztown University of Pennsylvania

MCU Ming Chuan University

SRS Software Requirements Specification

ID Identifier

IT Information Technology

AI Artificial Intelligence

LTC-TMS Long-Term Care Task Management System

CNO Chief Nursing Officer

CNA Certified Nursing Assistant

App Application

HIPPA Health Insurance Portability and Accountability Act

FR Functional Requirement

DB Database

HW Hardware

PDF Portable Document Format

PM Project Management

SPP Software Project Plan

12


PDF Portable Document Format

Table 1: Acronyms & Extrapolations

13


2.0 PROJECT CONSIDERATIONS

Section 2.0 outlines information outside of the project in terms of costs, tools, concerns, and future/standards. Additional information regarding certain fundamental functions can be found in the SPP.

2.1 Identified CostsCost are being structured to only have the needed products and future progress will be with this guideline in mind. As of this moment, Firebase has been picked as the database/Host. Hardware will be the largest expense based on acquiring micro:bit and Raspberry Pi with all needed accessories such as groove shield and other sensors.

2.2 Possible ToolsTools will be clearly stated, whether in terms of Firebase (Real-Time Database) modifications or hardware structure. Firebase Cloud server will be used for the duration of the project. Communication/file sharing tools used are google based services such as google hangouts/drive. For overall class communication slack is used. Lucidchart was used for creation of all diagram. GitHub will be used for storing all code and will be shared for the entire class.

2.3 Open Issues and QuestionsOpen concerns that will continue throughout the duration of the project are in terms of scalability and structure of data processing. How much storage in Firebase will be required to store patient data? How much processing power is required and how long will client information be held in the database? what limits are set of the patient of what they can and can't see? Will those Restrictions be the same for the family as well? Will the KU team be able to duplicate the computing environment of MCU? Will the KU team be able to maintain and improve the LTC-T system handled over by MCU?

2.4 Long-Term Plans for Future Releases and FeaturesThe project is initially going to be a prototype and hopefully will have the necessary functionality for it to be considered a success once the following steps are implemented.

● Micro: Bit/Raspberry Pi through radio frequency, allows the ability to collect data from the patient.

● Micro:Bit/Raspberry Pi should be able to send information over radio frequency to Firebase.

● LTC-TMS retrieves patient data from firebase for creation of patient’s profile.● LTC-TMS will have mobile and browser support.

14


● LTC-TMS allows patient and family to view relevant Health information on patient.● Incorporate speech-to-text functionality● Generate reports for analysis

2.5 Standards and Regulatory ConsiderationsThe DB/HW/ team will work within the policies and procedures of the law regarding data of patient information; specifically, the HIPPA Act of 1996. However, if a client is acquired, such legal compliances will be followed to the fullest extent to ensure the security and confidentiality of patient information. If any of the standards or regulatory considerations are breached, the DB/HW/team will be responsible for informing the project leader and higher management taking the necessary steps to reach a timely solution.

15


3.0 PROJECT SCOPE

LTC-TMS is designed to reduce the paperwork, digitize data, improve efficiency, communication, and production for the long-term care staff. The family is able to check the patient's status more efficiently and conveniently. The implementation of LTC-TMS will allow the hardware to automatically send data rather than manually keying in the data manually.

Listed below are the function for LTC-TMS:

● Available for more devices and browsers (Android, IOS, Chrome)● Provide bi-languages (English, Chinese)● Provide CNO personal Memo● Provide CNO and Director monitoring(Status Record)● Provide staff and patient portfolio● Provide two Android and IOS mobile app● Provide one Android tablet app● Provide Family and CNA monitoring (Status Record)● Provide CNA input status record● Provide center schedule and announcement● Provide CNA working schedule and working hours● Provide App(Mobile) users feedback platform● Provide auto-measurement through sensors

3.1 Director PerspectiveBrowser Version for Computer:The director is given the highest authority in the LTC-TMS but is not allowed to access the CNO’s account. Listed below is the following functions that can be performed by the director:

●View daily status record● View vital status record● View AI status record● View feedback● Create accounts (Both browser and app users)● Create and Edit portfolio● Create and Edit announcement● Create and Edit event● Create and Edit task Instruction● Create and Edit memo● Assign task instruction

16


● Upload and Delete working schedule● Upload and Delete working hour

3.2 CNO PerspectiveBrowser Version for Computer:The CNO is able to perform and use the following functions:

● View portfolio● View daily status record● View vital status record● View AI status record● View feedback● Create and Edit announcement● Create and Edit event● Create and Edit task instruction● Create memo● Assign task instruction● Upload and Delete working schedule● Upload and Delete working hour

3.3 CNA PerspectiveMobile App Version:The CNA receives information from database, and view and send information byutilizing the following functions:

● View task instruction● View CNA portfolio● View announcement● View center schedule● View working hour data● View working schedule● View notifications● Input feedback

Tablet Version:The CNA receives information from database, and view and send information byutilizing the following services:

● View AI status record

17


● Input daily status record● Input vital status record

3.4 Family/Patient PerspectiveApp Version for Mobile:In order for the LTC-TMS to be HIPPA compliant every patient needs to sign a waiver giving the family access to legally view the patient's medical record. Only then will the family be able to see the medical record data.

The family and patient are able to:

● View daily status record● View vital status record● View AI status record● View task instruction● View patient portfolio● View announcement● View center schedule● View notifications● Input feedback

18


4.0 User Interface MapLTC-TMS has two versions, the browser version for desktop computers, and the mobile app version.

4.1 Browser Version:The following Figure 1 below is a user interface map of the web page design for the browser version of LTC-TMS. Once the application is launched in the web browser a login page will appear and prompt the user to login.

19


Figure 1: Web Design for Browser Version

4.2 Mobile App Version:The following Figure 2 below is a user interface map of the web page design for the Mobile app version of LTC-TMS. Once the application is launched the user will come to a welcome page and will be prompted to login in. If the credentials are not valid the user will be brought back to the login page. The application is meant for two user the CNA and family. Once the CNA is logged in they will have access to the schedule page, reports, notifications, logout, the hamburger menu which gives them access to the following pages: working hour page, working schedule page, task instruction page, and portfolio page. Once the family is logged in they will be able to access the schedule page, reports, notification page, logout, the hamburger menu page which gives them access to the following pages: portfolio page, daily status record, task instruction page, AI status record, vital status record page.

20


Figure 2: Web Design for Mobile App Version

4.3 Tablet App Version:

The following Figure 3 below is a user interface map of the web page design for the tablet app version of LTC-TMS for the CNA. The Tablet is a read-only version and will bring the CNA to a homepage. From there they can choose a patient to view their daily status record which includes: basic care, dietary condition, sanitation behavior(defecation and freshen up), and special care. They also have a vital status record page and an AI status record page.

21


Figure 3: Web Design for Mobile App Version

22


5.0 System Architecture DiagramThe hardware will consist of a raspberry pi, a micro bit, and a few sensors to monitor vitals and air quality. Then the system will need a server and a database to send and receive requests. A tablet, mobile device and desktop computer will be used for the end user to view the LTC-TMS. The browser version is for the director and the CNO and is used on desktop computers. The app version for the mobile devices is going to be used by the CNA and family members. The app version for the tablet is going to be used by the CNA.

The raspberry pi and one of the micro:bits are going to act as a receiver of the patient’s data and will be then sent over WIFI to the database. The raspberry pi will also have two sensors connected to it to measure the temperature and humidity, and the air quality. The temperature and humidity, and the air quality sensor is wired directly to the raspberry pi which will then send the data to the database using WIFI. The other micro:Bit and heart rate sensor are going to be worn by the patient and will send the data using radio frequency. The micro:bit being worn by the patient will also be sending the number of steps the patient has made and the current position. Once the database has received the data it will then provide all of the data to the end users on the tablet, mobile device, and desktop computer to view.

The end users will navigate the web application which will interact with the server and database. The hardware will be sending its data to the database over WIFI.

The diagram below (Figure 4) shows how the hardware will connect to the database, server, and the end user devices.

23


Figure 4: SYSTEM ARCHITECTURE DIAGRAM for LTC-TMS

24



Functional Requirements include all aspects of the LTC-TMS project that must be implemented to fulfill the client’s needs for the system. Since the team handles all aspects of the hardware and database, the functional requirements will be geared towards those two aspects of the LTC-TMS project.

The following subsections will cover all functional requirements for the LTC-TMS project with one sub-section/table for each team. Each table has five columns: Category (DB or HW), Requirement ID (unique identifier), Requirement (name), Description (brief explanation of requirement), and Priority. Priority will range from [1-3], 1 being what the client deems to be essential to the system, 2 being good to have features, and 3 being features that would be nice to have and will be implemented if time permits.

6.1 Hardware/Database Team Functional RequirementsTable 2 provides each of the functional requirements of the LTC-TMS system in the areas of database and hardware. The functional requirements will each have a category name, requirement ID (unique), requirement (name), description, and priority (1-3).

Category Requirement ID

Requirement Description Priority

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

25




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

26




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

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

27




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

The hardware device will be capable of sending patient vitals (data) over Wi-Fi connection to the

1

28




database.

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

The wearable sensors will be worn in a location that would not be in the way of the patient’s day to day life.

3

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

3

29




sent to Family and CNA

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 2: Hardware/Database Team Functional Requirements

6.2 Browser Team Functional RequirementsTable 3 provides each of the functional requirements of the LTC-TMS system in the area of browser functionalities. The functional requirements will each have a category name, requirement ID (unique), requirement (name), description, and priority (1-3).

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

30



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 EditAnnouncement

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

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

1

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

1

31



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

32



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 to view vital status record.

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

1

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

33



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 has to 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

34



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 to edit an event's date

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

1

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 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 file(s).

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

1

35



39 Director must be able to delete uploaded 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 file(s).

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

1

Create and Edit Task

41 CNO 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 task.

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

1

36



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

37



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.

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.


55 Director must be able to embed video(s) into a task.

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

2

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

38



59 Director must be able to edit a task.

When a task’s information needs to be changed, Director should be able to change a 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 a 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

39



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

40



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 detailed steps when creating a task.


2

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

41



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 tasks

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 to log in with the provided account.

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

1

42



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

43



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.

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

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

44



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

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

Director should be able to use the

1

45



system on Internet Explorer browser

system on the browser of their choice including Internet Explorer.

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

112 Director must be able to use the system on Edge browser

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

1

113 CNO must be able to use the system on Edge browser

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

1

Table 3: Browser Team Functional Requirements

6.3 App Team Functional RequirementsTable 4 provides each of the functional requirements of the LTC-TMS system in the areas of mobile app functionalities. The functional requirements will each have a category name, requirement ID (unique), requirement (name), description, and priority (1-3).


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

46



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

3Family 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

6Family 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

7Family 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 9Family 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

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

11Family 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 Family are able to speak into the 1

47



information using their voice.

device to input data in fields when tapping the microphone icon.

Table 4: App Team Functional Requirements

48



Non-functional Requirements include all system behaviors of the LTC-TMS project, which will be fulfilled by the HW/DB/ team. Non-Functional requirements are typically referred to as “quality goals” as they judge the overall system properties rather than specific functions (functional requirements). The two following subsections will discuss the non-functional requirements from the database (5.1) and hardware (5.2) perspective in the LTC-TMS project.

7.1 Database PerspectiveTable 5 provides detail on the non-functional requirements from the DB perspective of the LTC-TMS project. The table has three columns, which are Requirement (name), Purpose (reason for requirement), and How the Requirement Will be Measured (description/detail regarding the requirement).

Requirement Purpose How the Requirement Will be Measured

Consistent availability of data from Firebase.

Information should not only be stored in the database but should also be available to users of the LTC-TMS system.

Database querying will be used to test the system from a more back-end approach. Queries should produce results in less than three seconds. Also, other testing including looking up patient profiles/information will be conducted to ensure data is available on the front-end via the mobile apps (Android and iOS).

Maintainability of data within Firebase.

This refers to ensuring the database remains current, clean, and efficient.

Database administration tasks such as limiting redundancies (modifying JSON relationships), checking for integrity when data is sent to the firebase (ensure data is correct). Security will also be fulfilled by channeling

49



the hardware (radio channel) to ensure only the LTC-TMS’s project team is sending data to the database, as well as the build-in security that Firebase includes as a Google product.

Scalability of the Firebase instance to allow for storage expandability.

The database will initially have limited storage and should be seamlessly expandable if need-be at any point during the LTC-TMS project.

Firebase offers scalability by allowing a database instance to begin at a level of storage (starting at free version) and upgrading storage space at any time, without any issues.

Table 5: Database Perspective

7.2 Hardware PerspectiveTable 6 provides detail on the non-functional requirements from the HW perspective of the LTC-TMS project. The table has three columns, which are Requirement (name), Purpose (reason for requirement), and How the Requirement Will be Measured (description/detail regarding the requirement).


Availability of hardware for the CNA to treat the patient and record vitals.

The hardware should be charged and ready for the CNA to record patient vitals.

The CNA will be trained to properly use the hardware device on the patient and putting the hardware on charge after use. Also, the device will be tested before the beginning of each day by the CNA to determine if it is functional/available.

50



Performance of the hardware in terms of limiting lag/latency with recording vitals from the patient, as well as pushing data out to Firebase for storage.

The hardware should be efficient when recording vitals so that the CNA can provides smooth care to the patient, rather than adding unnecessary time to a patient’s appointment due to poor hardware performance.

The hardware will be tested at least once per week to track its performance rates with the time it takes to measure vitals and send to the database. If the HW/DB team begins to see a downwards trend in the performance, the hardware lead will further investigate to determine if it is a code or hardware issue. Timing multiple scenarios of recording vitals and pushing data to DB will be used in determining time consistency to measure performance.

Usability of the hardware for the CNA to properly care for the patient when recording vitals.

The hardware should not be complicated for the CNA to use when caring for the patient. Training on the hardware’s use should be the only knowledge needed to properly record patient vitals.

The HW/DB team will have test users to determine how easy the product is to record vitals, there should be limited to no technical experience needed by the CNA outside of recording vitals. Test user feedback will be used in measuring usability.

Table 6: Hardware Perspective

51


8.0 USE CASE DIAGRAMSUse case diagrams are a graphical representation of a set of use cases. The diagram shows how actors outside of the system boundary interact with the system. The lines of association show how actors interact with use cases and the relationships between them.

8.1 Notations UsedThe actor figure is representative of anyone outside the system that interacts with the system. The system boundary is the box that separates actors from use cases. Actors may only interact with the system through use cases. The line of association shows a relationship between an actor and a use case. Use cases are written inside ovals within the system boundary.

8.2 Use Case Diagram ExampleThis diagram explains the layout of use case diagrams in this document.

Figure 5: Use Case Diagram Example

52


8.3 Database Use Case DiagramThis diagram shows the role of the technologist in establishing and maintaining the database.

Figure 6: Database Use Cases

53


8.4 Hardware Use Case DiagramThis diagram shows the role of the technologist in assembling and maintaining the hardware of the LTC-TMS.

Figure 7: Hardware Use Cases

54



These use case descriptions explain the details behind how functional requirements should be implemented. The following subsections organize the use case descriptions based on their category. This team is primarily responsible for the hardware and database components of the system.

9.1 Database Use Case Description - Add a Data FieldTable 7 goes through a use case description for a database admin creating a new data field to properly store a new type of incoming data. This table goes through a fully developed use case description in which the scenario, actors, pre/postconditions and other aspects of the use case are described. This use case involves a database administrator as the main actor in this scenario as they are the only ones who are directly involved in the database. In this scenario, a new data field is going to be added to the database. The triggering event is that the system now requires a new type of data to be stored within it.

Use Case Name: Add a Data Field

Scenario: Add a new data field to the database.

ID: 4

Triggering Event: A new type of data from the system is needed to be stored.

Brief Description: A Database Admin will create and organize data fields where data will be stored.

Actors: Database Admin

Stakeholders: Database Admin, CNO, CNA, Director, Patient, Family

Preconditions: 1. The database and the proper data fields must have already been created to add onto it.

2. The database must have enough space for the incoming data.

55



Postconditions: 1. Data is checked for validation as it’s placed in the new database field.

2. The new database field is checked that it is properly exporting the data inside it as needed.

Flow of Activities:

Actor System

1. The Database Admin logs into the database on Firebase.

1.1 Firebase retrieves the database upon logging in.

2. The admin searches for where the new data field will be placed into the database.

2.1 Firebase searches the existing database for the location the user is looking for.

3. The admin selects the firebase development option to add the code needed to receive the new type of data.

3.1 Firebase opens its development area upon selection.

3.2 Firebase takes in the user’s code and adds the new field onto the existing database in the chosen spot.

4. The admin checks that the new database field is working correctly.

4.1 The LTC-TMS will send data to the database and into the new field.

4.2 The code will be processed and place into its correct location by firebase.

56



Exception Condition: 1. The database does not take in data due to incorrect code.

2. The data is placed into the wrong area of the database due to an incorrect database schema or improper coding.

3. The database rejects the data because it was the wrong type of data inserted.

Table 7: Add a Data Field

9.2 Database Use Case Description - Create a Firebase Instance Table 8 goes through a fully covered use case description for a database admin creating a new database instance to properly store incoming data from the LTM-TMS. This table goes through a fully developed use case description in which the scenario, actors, pre/postconditions and other aspects of the use case are described. This use case involves a database administrator as the main actor in this scenario as they are the only ones who are directly involved in the database. In this scenario, a new instance of a firebase database is going created. The triggering event is that the system requires a database to store all the data for its applications.

Use Case Name: Create a Firebase Instance

Scenario: Creating a new instance of a Firebase database.

ID: 1

Triggering Event: A new database on Firebase is needed to start storing the incoming data from the system applications.

Brief Description: A Database Admin will create a new instance of a Firebase database in order to properly store data for the LTC-TMS.

Actors: Database Admin


Preconditions: 1. The Database Admin must already have an account with

57



Google.2. The Database Admin must have already agreed to Google’s

terms of service to use their Firebase service.3. The Database Admin must have selected which version of

Firebase(paid or free) to use.

Postconditions: 1. JSON documentation is read and Firebase creates the new Database.

2. Data is checked for validation as it’s placed in the new database.

3. The new database is checked that it is properly exporting the data inside it as needed.

4. The new database is checked that it was properly formed to take in any and all data from the system .

Flow of Activities:

Actor System

1.1 The Database Admin creates a Google account.

1.2 The Database Admin verifies their information with Google to gain full access to their services.

1.1 Google creates a user account for the Database Admin.

1.2 Google verifies the user’s information and given them access to their services.

2.1 The Database Admin goes to the Firebase website and clicks on the “GO TO CONSOLE” link.

2.1 Google opens the user’s Firebase console page and displays any current projects they may have.

58



2.2. The Database Admin goes clicks on “Add project.”

2.2 Google creates a new Firebase project for the user.

3.1 The Database Admin selects the Real-Time Database option.

3.2 The Database Admin types in the data fields of the desired database which consist of key and value pair.

3.1 Firebase prepares a new database to be store on Google’s servers.

3.2 Firebase generate code to link the new database to the LTC-TMS.

3.2 Firebase creates the format of the database based on the data fields typed in by the user.

4.1 The Database Admin properly adds the connection code generated by Firebase into the LTC-TMS as needed.

4.2 The Database Admin checks that the new database is working correctly.

4.1 The LTC-TMS will send data to the database and into the new field.

4.2 The code will be processed and place into its correct location by firebase.

Exception Condition: 1. The database does not take in data due to incorrect code.

2. The data is placed into the wrong area of the database due to an incorrect database schema or improper coding.

3. The database rejects the data because it was the wrong type of data inserted.

4. The database has gone over the limit Google has provided for it

59



and stops collecting data.

Table 8: Create a Firebase Instance

9.3 Hardware Use Case Description - Check Heart RateTable 9 describes the use case for a CNA using the hardware on a patient at the facility. This table goes through a fully developed use case description in which the scenario, actors, pre/postconditions and other aspects of the use case are described. This use case involves a CNA as the main actor. In this scenario, the hardware is going to be placed on a patient’s arm to measure their heart rate. The triggering event is that the medical facility wants to keep a patient's heart rate monitored.

Use Case Name: Check Heart Rate

Scenario: CNA keeps record of a patient’s heart rate

ID: 9

Triggering Event: The medical facility wants to keep records of a certain patient’s heart rate throughout the day.

Brief Description: The CNA will attach the hardware to the patient’s arm in order to monitor heart rate and step count.

Actors: CNA, Patient


Preconditions: 1. The hardware must have been already assembled and in working order.

2. There must be a patient willing to have the device on their arm for an extended period of time.

Postconditions: 1. The patient’s heart rate will be stored in the database.

60



2. The patient’s heart rate will be viewable from that patient’s portfolio afterwards.

Flow of Activities:

Actor System

1.1 A CNA decides to measure a patient’s heart rate throughout the day.

1.2 The CNA will select the patient’s room number.

1.3 The CNA will select the patient within that room.

1.1 The system will have stored a portfolio for the patient to link any data collected to that patient.

1.2 The system will display the patients within the selected room number.

1.3 The system will direct the CNA to the status selection page.

2.1 The CNA will select the vital status page from the status selection page.

2.1 The system will redirect the CNA to the vital status page.

3.1 The CNA will select to have the chosen patient’s heart rate as monitored.

3.2 The CNA will select confirm on the alert box.

3.1 The system will alert the CNA with a selection of confirmation on submission.

3.2 The system then updates the selection into the database and directs CNA back to status selection page.

4.1 The CNA will attach the 4.1 The hardware will connect

61



hardware device onto the patient’s arm.

4.2 The CNA will make sure the device is on and connected.

to the main computer and then connect to the server via Wi-Fi.

4.2 The hardware will periodically send the patient’s heart rate to be stored in the database.

Exception Condition: 1. The hardware loses connection to the database.2. The patient takes off the hardware.3. The hardware loses power and turns off.

Table 9: Check Heart Rate

9.4 Hardware Use Case Description - Hardware SecurityTable 10 describes the use case for a CNA or CNO keeping track of the hardware in the facility, so it is not stolen. This table goes through a fully developed use case description in which the scenario, actors, pre/postconditions and other aspects of the use case are described. This use case involves a CNA or CNO as the main actor. In this scenario, the hardware is going to be placed on a patient’s arm but must be taken off and checked that it has been returned before the patient leaves. The triggering event is that the medical facility wants to protect their hardware from being stolen either on purpose or by accident.

Use Case Name: Hardware Security

Scenario: Checking that the hardware is returned before the patient using it leaves.

ID: 14

Triggering Event: A patient using the hardware is checking out.

Brief Description: The actor will keep track of which patient is using the hardware and will remove the hardware from the patient’s arm before they

62



leave the facility.

Actors: CNA, CNO

Stakeholders: CNO, CNA, Director

Preconditions: 1. The hardware must already be assembled. 2. The hardware must be in use by a patient.

Postconditions: 1. The hardware is cleaned after patient use.2. The hardware is stored appropriately in its correct location

when not in use.

Flow of Activities:

Actor System

1.1 The actor keeps track of which patient is using the hardware at any moment by checking the LTC-TMS app.

1.1 The LTC-TMS is keeping track of who is using the hardware by which patient’s profile is being populated with real-time data.

2.1 The actor takes the hardware off the patient as part of the checking out process.

2.1 The hardware is removed from the patient’s arm.

3.1 The actor opens the LTC-TMS app.

3.2 The actor goes to the vital status page and deselects the

3.1 The LTC-TMS displays the main menu.

3.2 The system opens the vital status page when selected.

63



current patient.

3.3 The system stops recording the data from the hardware when the patient is deselected.

4.1 The actor sanitizes the used hardware.

4.2 The actor places the hardware in a secured location to charge.

4.1 The hardware charges as it is stored.

Exception Condition: 1. A patient leaves without checking out. 2. Someone breaks into the facility and steals the hardware. 3. A patient discards the hardware before checking out.

Table 10: Hardware Security

9.5 Hardware Use Case Description - Build DeviceTable 11 goes through the use case description for an IT worker assembling the hardware. This table goes through a fully developed use case description in which the scenario, actors, pre/postconditions and other aspects of the use case are described. This use case involves an IT worker as the main actor. In this scenario, the hardware is going to be assembled to be incorporated into the LTC-TMS. The triggering event is that the hardware needs to be assembled for the system to record a patient's vitals.

Use Case Name: Build Device

Scenario: The hardware must be assembled together correctly and coded properly to work.

ID: 6

64



Triggering Event: The LTC-TMS must have a device that measures a patient's vitals to be fully implemented.

Brief Description: The hardware parts are collected and must be put together and programmed to work.

Actors: IT Worker

Stakeholders: Database Admin, CNO, CNA, Director, Patient, Family, IT Worker

Preconditions: 1. The parts for the device must have been collected. 2. The hardware team must know how to put the device

together.

Postconditions: 1. The device will be working and reading vitals correctly. 2. The device will connect to other parts of the

system(database/LTC-TMS) correctly.

Flow of Activities:

Actor System

1.1 The actor will research the parts needed for the device.

1.2 The actor will collect the parts by buying them or by some other means.

1.1 The system will not collect any data from the device until assembled and coded.

2.1 The actor will research how to assemble the parts correctly.

2.1 The device has been assembled but will not work until programmed to.

65



2.2 The actor will properly assemble the device.

3.1 The actor will program the device to run correctly and connect to the rest of the system.

3.1 The device will now run and is able to connect to other parts of the system.

3.2 The device is now ready to stream real-time data into the LTC-TMS.

Exception Condition: 1. The device is not assembled correctly.2. Certain parts of the device are unavailable. 3. There is no information on how to assemble the device. 4. Some of the parts are damaged and no longer work.

Table 11: Build Device

66

table 1 provides the revision history to the srs...

Documents