WARN Functional Requirements

NIT (Notification Implementation Taskforce)
Functional Requirements for

W.A.R.N.
Version 1.0
Prepared By: Curtis Bray, Jaspreet Gill, John Dale, Valerie Lucus, Safa Hussain, Frank Wada, Elliot Lopez
Peter Brinkerhoff, Karen Williams Elizabeth Meyer, Deborah Luthi, and Laine Keneller
Date: January 22, 2008
Version
1.0
Description of Change
Notification Implementation Taskforce input
Author
Workgroup #3
Date
1/22/08
INTRODUCTION
The goal of this workgroup within the Notification Implementation Taskforce is to:
Recommend necessary notification information (fields) within the Online Directory
Develop methods to encourage staff/faculty/students to update information
Identify legal issues with disclaimers.
Note: WARN is consistently used throughout this document as the name of the notification system
although it is understood that moving forward the campus will select another name for branding
purposes.
1.1 Scope
This phase of the W.A.R.N. implementation will focus on emergency and urgent communications
being sent to notify students, staff, faculty and others that may have computing accounts on campus.
1.2
Assumptions and Constraints

This assumes that the public telephone network and campus network remains stable and messages
are sent and received.
This assumes that all staff and facility will receive a message regardless of their work location (for
example, Bodega Bay staff will be sent the same messages that everyone on campus receives and
visa versa).
W.A.R.N. Functional Requirements v1.0
Page 1 of 19
Some recipients may be outside the normal update cycle such as retired faculty, graduate students,
etc and their notification information could become out of date or they may continue receiving
messages after they leave campus.
SYSTEM DEFINED:
Currently the faculty and staff contact information for campus and the Med Center is contained in the
Online Directory. Student emergency contact information data will be stored in the Online Directory
making it the authoritative source for all emergency contact information.
IET will develop an interface based on these functional requirements that will collect emergency
contact information from students, staff and faculty and store it in the Online Directory database. This
information will be pushed into the W.A.R.N. system and refreshed nightly. The WARN Interface will
be known as WI in this document. Below is a diagram:
SIS web
Online
Directory
Student
Housing
WARN
Interface
(WI)
WARN
Mothra
METHODOLOGY
The functional requirements listed in this document were developed with input from students and staff
from the appropriate campus departments.
Page 2 of 19
FUNCTIONAL REQUIREMENTS
Requirement
ID
Requirement Definition
NIT - 1
The Online Directory must allow the UCD population (staff, faculty, med center, students
and affiliates) to update their own personal emergency notification information.
NIT - 2
The Online Directory must not require an approver to review personal emergency
notification information.
NIT - 3
For the mandatory screen in the Online Directory, WI system must accept two emergency
notification fields for each of the following devices: UCD provided cell phone, office phone,
and email.
NIT - 4
For the optional section in the Online Directory ,WI systems must accept a total of four
emergency notification device fields for personal cell phone, home phone number, alphapager numbers and personal email (limited to two per device type).
NIT 5
The Online Directory must require recipients to opt-out of personal emergency notification.
NIT 6
The Online Directory must accept multiple buildings (up to 3 locations).
NIT 7
The Online Directory must pull residence hall information from the Student Housing data
base.
NIT 8
The Banner SISWeb end-user workflow must not be interrupted by the opening of the
Online Directory window and the emergency contact information pages.
NIT 9
The Banner SISWeb end user must only be asked to log in and authenticate once when they
log into SIS web, the switch to the Online Directory must not disrupt the work session.
NIT 10
End-user must be able to opt-out of the personal emergency notification session at any time.
NIT 11
Banner SISWeb must prompt student to update emergency information only once a term.
NIT 12
Banner SISWeb must display contact information that is currently in the Online Directory
database. (Is this a requirement or an implementation detail?)
NIT 13
The WI system must search database records in the Online Directory to find current
emergency notification information.
NIT 14
The WI system must recognize people by (a) an attribute-based group such as everyone in a
building and in (b) a manually selected group such as an EOC member.
NIT 15
The WI system must recognize and separate recipients by pre-determined fields such as (a)
building location (dormitory location for students), (b) home department (on the primary
listing), and (c) status faculty, staff, students, med center.
NIT 16
The WI system must accept multiple attributes for one recipient.
NIT 17
The WI system must be able to pull all records into one contact list to notify everyone in the
Online Directory database.
NIT 18
The WI system must include contacts at the UCDHS.
NIT 19
User is directed to a descriptive web error page for instruction.
NIT 20
The WI system must retain and archive change history reports.
NIT - 21
The WI system must upload contact information nightly.
Page 3 of 19
Requirement
ID
Requirement Definition
NIT 22
The WI system must recognize dual roles and reconcile records (i.e. student/staff)
NIT- 23
The WI system must maintain an audit trail when a record is viewed but not updated to be
considered an opt-out.
NIT 24
The WARN system must allow access only to initiators and administrators that have
successfully logged into the application with a valid ID and password.
NIT 25
The WARN system must allow administrators and initiators to create call groups and not
allow individuals to designate themselves to a call group.
3.1 Out of Scope

This Taskforce recognizes that any notification system has practical limitations. This phase of the
implementation will concentrate on developing and maintaining a contact list for current students,
staff, med center and faculty. A subsequent phase of the roll-out may include secondary concerned
groups such as parents / guardians, and employee spouses.
3.1.1
The following groups of people will not be added to the WARN contact list:
Visitors
Affiliates not listed in directory
Contractors working on campus without a computing account
Employees that are not issued a computer or phone
3.1.2
The ability for a department to use the system for notification within the department or campuswide will not be addressed in this initial phase of the implementation.
3.1.3
The ability to monitor equipment on campus will not be included in this phase of the
implementation.
3.2 User Requirements Use Cases

Description: The Warn system can be activated by a designated Initiator. This use case describes the
notification process for an Initiator to send an emergency notification to recipients.
Normal Flow of events:
1. Contact specific group (MSOs, EOC, O&M building contacts, etc.)
a. Online Directory contact info is updated by recipient.
b. WI system uploads current contact information each night (M F).
c. During an emergency event, an Initiator selects message to be sent.
d. Initiator selects group of recipients that message will be sent to.
e. WARN system searches the database for selected contact information.
f. WARN system sends messages across multiple platforms to multiple devices.
g. WARN notification successfully received.
2. Contact all Occupants of a Specific Building
Page 4 of 19
3.

Notify All
Post conditions: A high percentage of students, faculty, and staff are contacted via phone, voice
mail, text mail, or email.
Alternate flow of events:
1. The initiator cancels the notifications.
2. The initiator uses the WARN system to send urgent information email (i.e. campus
situation update).
4
OTHER REQUIREMENTS
4.1 Interface Requirements

The WARN system is a web based application.
4.1.1
Hardware
The WARN system is hosted and maintained off-site by the vendor.

4.1.2
Software
The WI application must interface directly with the Online Directory database to select the data from
campus systems and format information for input into the WARN system.
4.1.3
Communications Interfaces
The system is available through the campus network.

4.2 Operational Requirements
This system has been identified as a critical function and the system must be available 24x7x365.
4.2.1
Security and Privacy
A. The following are consequences of breaches of security in the subject applications:

1. Loss or corruption of data.
Page 5 of 19
2. Social Security numbers are not stored in the Online Directory; however, the Online Directory
database has access to sensitive data stored in Mothra.
3. Disclosure of privileged/privacy information about individuals relative to the Online Directory
specifically:
Name
Address
Phone Number
4. Corruption of software or introduction of viruses.

B. The following type of security is required:
1. Physical security at the data center where the Online Directory servers are housed.
2. Access to WARN by user role is limited only approved employees established as
administrators and initiators will have access.
4.2.2
Reliability
A. The damage that can result from failure of this system:

1. Loss of opportunity to notify UCD population of emergency / urgent situation.
2. Delay in notification to campus of emergency / urgent situation.
4.2.3
Recoverability
A. In the event the WARN system is unavailable to initiators because of a system failure, the
Emergency Manager (or designee) would require an emergency bulk email and broadcast voice
mail be sent as substitute notification.
B. In the event the Online Directory database is corrupted, the database must be capable of being
restored to its original condition.
C. If the processing site (hardware, data, and onsite backup) is destroyed, WARN is responsible for
emergency restoration procedures and timelines. In the case of a disaster, the EOC would resort to
other notification systems that are in place while the system is restored.
4.2.4
System Availability
WARN must be available 24x7x365 (regularly scheduled maintenance).

Online Directory maintenance (yet to be determined)
WI maintenance (yet to be determined)
4.2.5
General Performance
The expected rate of activity on WARN is relatively low except for in the event of a campus
emergency then the volume will be extreme and may continue for extended periods of time. This
system will only be used for emergency or urgent notifications and to update throughout the duration
of the event.
Page 6 of 19
The WARN system will be tested on a regular basis.

4.2.6
Data Retention
The system shall retain application information for 5 years.

4.2.7
Error Handling
User is directed to a descriptive web error page for instruction.

4.2.8 Validation Rules
The UCD employee will be validated as a system administrator or initiator.
Page 7 of 19
Appendix A Staff and Faculty Screen Shot
Page 8 of 19
Appendix A Student Screen Shot
To be delivered.
Page 9 of 19
Appendix B Student Experience

Sample Methodology to Obtain WARN information for UC Davis Students
DRAFT 01/18/08
Objective:
Develop a methodology utilizing the student user interface, SISWEB, to collect WARN (used only for
purposes of identifying the notification system) contact information (cell phone and alternate email
address) that can be viewed and updated to the WARN system. Students will receive a prompt each
quarter to update or verify their WARN information through the SISWEB process.
Project Requirements:
1) Modify existing SISWEB pages
a. Registration Menu page (see Figure 1)
1. No new links are needed.
2. Add a trigger to prompt students to update/verify WARN when they select:
a. Select Term
b. Register for Classes (incl. Adding & Dropping)
c. Look-up Classes to Add
d. Add/Drop using a PTA or PTD number
e. Check Appointment Times
3. After a student has completed the WARN page, they should be directed to the place
they originally selected (e.g., if a student clicked on Look-up Classes to Add, they
should be directed to that page)
4. Once a student has updated/verified their WARN information for that term, the
triggers should no longer be active until the next term.
5.Valid term codes for the trigger are
- fall quarter (10)
- fall semester (09)
- winter quarter (01)
- spring quarter (03)
- spring semester (02)
- summer terms (05, 06, 07, 08) will not trigger if valid spring quarter information
exists. If no spring information, then student should be prompted once for summer term
codes 05, 06, 07, or 08. Term 04 is a spring continuation term for limited classes so no
trigger is needed.
b. Personal Information page (Figure 4a)
1. Add a new link to the page that indicates:
View WARN Participation (Activate/Update/Decline)
Students can update/verify their WARN information at anytime through SISWeb
Personal Pages, but the terms available for selection must be restricted based on the
available terms viewable in SISWeb (Figure 4b).
2. Once students update/view WARN information through the Personal Information
page, they should be returned to the main Personal Information page.
2) Add new SISWEB pages
Page 10 of 19
a. Add WARN Information from Registration processes

(see Figure 2) [If student has no WARN information]
1. When Activate or Decline WARN button is clicked, two actions must occur.
a) a new web window will appear with White Page information and the
student will have the opportunity to add or decline participation. The white
page window must remain active, even if a student chooses to return to the
SISWeb window to complete their tasks. This will allow the student to
complete their WARN information.
b) the SISWeb page will then continue to the site that the student originally
intended to go to as indicated in 1.a.3 in the project requirements section.
b. Update WARN Information from Registration processes
(see Figure 3) [If student has WARN information]
1. When Information Correct. Use this information and continue with my
SISWeb activity is selected, two actions must occur:
a) The action will trigger the White Page information to indicate the student
has verified their information for this term. No pop-up window is
required.
b) The SISWeb page will then continue to the site that the student originally
2. When the Update or Decline WARN information button is selected, two
actions must occur.
a) a new web window will appear with pre-existing White Page information
about the student who will have the opportunity to change or decline
participation. The white page window must remain active, even if a
student chooses to return to the SISWeb window to complete their tasks.
This will allow the student to complete their WARN information.
b) the SISWeb page will then continue to the site that the student originally
c. Add WARN Information from Personal Information section
(see Figure 5) [If student has no WARN information]
1. When Activate or Decline WARN button is clicked, two actions must occur.
a) a new web window will appear with White Page information and the
student will have the opportunity to add or decline participation. The white
page window must remain active, even if a student chooses to return to the
SISWeb window to complete their tasks. This will allow the student to
complete their WARN information.
b) the SISWeb page will then return the student to the home Personal
Information page.
d. Update WARN Information from Personal Information section
(see Figure 6) [If student has WARN information]
1. When Information Correct. Use this information and continue with my
SISWeb activity is selected, two actions must occur:
a) The action will trigger the White Page information to indicate the student
has verified their information for this term. No pop-up window is
required.
Information page.
2. When the Update or Decline WARN information button is selected, two
actions must occur.
Page 11 of 19
a) a new web window will appear with pre-existing White Page information
about the student who will have the opportunity to change or decline
participation. The white page window must remain active, even if a
student chooses to return to the SISWeb window to complete their tasks.
This will allow the student to complete their WARN information.
Information page.
3) Add a link/reminder in MyUCDavis in the Appointment Time window that they should check
their WARN information. Once students update/verify WARN information, the link/reminder
should be removed. (see Figure 7)
Page 12 of 19
Figure 1: Main SISWEB Registration Menu
Page 13 of 19
Figure 2: Update WARN Information via Registration Menu Trigger
Activate or Decline Personal Aggie Alert Information

BEFORE CONTINUING WITH YOUR SISWEB SESSION FOR THIS TERM, please consider submitting the
following information. This will be used solely for the purposes of contacting you in the event of a
campus emergency. By providing your cell phone and alternate email address, UC Davis will send a
message (text and voice mail to cell phone; text only to the alternate email address) to you if Aggie
Alert is activated. This contact information will only be used for emergency purposes. Please visit
ucdavis.edu/xxxxx for more information about this emergency notification service.
To ensure that information for the Aggie Alert system is up to date, students will be asked to update
their personal Aggie Alert information prior to the start of registration for each upcoming quarter.
FALL
2008
may
update
their information at anytime through _______________
pages???).
NOTE: (white
this should
self
TermStudents
To Update:
WARN Status: NOT ACTIVE
populate with term that the

student is trying to enroll
Please click on the button below to activate or decline participation with WARN.
Note: A new pop-up window will appear.
Activate or Decline AGGIE ALERT
Action: once the student clicks on the button Add or Decline WARN two actions will occur. 1) a new web window will
appear and the student will have the opportunity to add or decline participation. 2) the SISWeb page will then continue to
the site that the student originally intended to go to as indicated in 1.a.3 in the project requirements section.
Page 14 of 19
Figure 3: Update WARN Information via Registration Menu Trigger
Update Personal Aggie Alert Information

www.ucdavis.edu/xxxxxxx for more information about this emergency notification system.
their personal Aggie Alert information once prior to the start of registration for each quarter.
FALL
2008
may
update
their information at anytime through _______________
pages???).
NOTE: (white
this should
self
TermStudents
To Update:

student is trying to enroll.
WARN Status: ACTIVE

Cell Phone Number:
530-999-1234
Alternate Email Address:

warn_me_now@warn.com
How WARN with notify you:

Cell Phone Text Message (standard rates will apply)
= ok to notify
x Cell Phone Voice Message
X = will not be notified Email to Alternate Email Address
If the WARN information above is correct and no changes needed, click on the button below:
Information Correct. Use this
information and continue with SISWeb
activity.
NOTE: this button should send a

message to white pages that the
student confirmed this information.
If you would like to change information or decline participating in WARN, click on the button
below:
Change/Update or Decline
AGGIE ALERT Information
Page 15 of 19
Figure 4a: Modified Personal Information Menu
View Aggie Alert Participation (Activate/Update/Decline)
The View WARN Participation (Activate/Update/Decline) link is new.

Link should first go to the Term Select function (normally found on Registration Menu.) this will allow the
user to select the term to which to make the changes to.
Figure 4b: Term Select
There will be two webpages that the link can go to depending on whether there is existing WARN
information. If there is no information, go to web site found on Figure 5. If the most recent previous term
information exists, go to web site found on Figure 6.
Page 16 of 19
Figure 5: WARN Information via Personal Information (not active)
Personal Aggie Alert Information

This will be used solely for the purposes of contacting you in the event of a campus emergency. By
providing your cell phone and alternate email address, UC Davis will send a message (text and voice
mail to cell phone; text only to the alternate email address) to you if Aggie Alert is activated. This
contact information will only be used for emergency purposes. Please visit ucdavis.edu/xxxxx for
more information about this emergency notification system.
their personal Aggie Alert information once prior to the start of registration for each quarter.
Students may update their information at anytime through _______________ (white pages???).
FALL 2008
Term To Update:
NOTE: based on what they selected on

the Term selection webpage
WARN Status: NOT ACTIVE
Please click on the button below to activate or decline participation with WARN.
Activate or Decline AGGIE ALERT
Page 17 of 19
Figure 6: WARN Information via Personal Information (active)
Personal Aggie Alert Information

ucdavis.edu/xxxxx for more information about this emergency notification system.
their personal Aggie Alert information prior to the start of registration for each upcoming quarter.
Students may update their information at anytime through _______________ (white pages???).
Term To Update:FALL 2008

WARN Status: ACTIVE
Cell Phone Number:
530-999-1234
NOTE: this should self

student is trying to enroll.
Alternate Email Address:

warn_me_now@warn.com
How WARN with notify you:

Cell Phone Text Message (standard rates will apply)
= ok to notify
x Cell Phone Voice Message
X = will not be notified Email to Alternate Email Address
If the WARN information above is correct and no changes needed, click on the button below:
Information Correct. Use this
information for the identified term.
NOTE: this button should send a

message to white pages that the
student confirmed this information.
If you would like to change information or decline participating in WARN, click on the button
below:
Change/Update or Decline
AGGIE ALERT Information
Page 18 of 19
Figure 7: MyUCDavis Appointment Window Reminder to Update WARN Information
Or update your WARN Information
The message provides a reminder to update WARN information.
Page 19 of 19

WARN Functional Requirements

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

WARN Functional Requirements

Загружено:

Авторское право:

Доступные форматы

NIT (Notification Implementation Taskforce)

Functional Requirements for

Assumptions and Constraints

W.A.R.N. Functional Requirements v1.0

W.A.R.N. Functional Requirements v1.0

The Online Directory must accept multiple buildings (up to 3 locations).

The WI system must accept multiple attributes for one recipient.

The WI system must include contacts at the UCDHS.

User is directed to a descriptive web error page for instruction.

The WI system must retain and archive change history reports.

The WI system must upload contact information nightly.

W.A.R.N. Functional Requirements v1.0

3.1 Out of Scope

3.2 User Requirements Use Cases

W.A.R.N. Functional Requirements v1.0

c. During an emergency event, an Initiator selects message to be sent.

4.1 Interface Requirements

The WARN system is hosted and maintained off-site by the vendor.

The system is available through the campus network.

Security and Privacy

A. The following are consequences of breaches of security in the subject applications:

W.A.R.N. Functional Requirements v1.0

4. Corruption of software or introduction of viruses.

A. The damage that can result from failure of this system:

WARN must be available 24x7x365 (regularly scheduled maintenance).

W.A.R.N. Functional Requirements v1.0

The WARN system will be tested on a regular basis.

The system shall retain application information for 5 years.

User is directed to a descriptive web error page for instruction.

W.A.R.N. Functional Requirements v1.0

Appendix A Staff and Faculty Screen Shot

W.A.R.N. Functional Requirements v1.0

Appendix A Student Screen Shot

W.A.R.N. Functional Requirements v1.0

Appendix B Student Experience

W.A.R.N. Functional Requirements v1.0

a. Add WARN Information from Registration processes

W.A.R.N. Functional Requirements v1.0

W.A.R.N. Functional Requirements v1.0

Figure 1: Main SISWEB Registration Menu

W.A.R.N. Functional Requirements v1.0

Figure 2: Update WARN Information via Registration Menu Trigger

Activate or Decline Personal Aggie Alert Information

WARN Status: NOT ACTIVE

populate with term that the

W.A.R.N. Functional Requirements v1.0

Figure 3: Update WARN Information via Registration Menu Trigger

Update Personal Aggie Alert Information

populate with term that the

WARN Status: ACTIVE

Alternate Email Address:

How WARN with notify you:

NOTE: this button should send a

W.A.R.N. Functional Requirements v1.0

Figure 4a: Modified Personal Information Menu

View Aggie Alert Participation (Activate/Update/Decline)

The View WARN Participation (Activate/Update/Decline) link is new.

W.A.R.N. Functional Requirements v1.0

Figure 5: WARN Information via Personal Information (not active)

Personal Aggie Alert Information

NOTE: based on what they selected on

WARN Status: NOT ACTIVE

W.A.R.N. Functional Requirements v1.0

Figure 6: WARN Information via Personal Information (active)