Detailed Requirements

batterycopperInternet and Web Development

Nov 12, 2013 (3 years and 8 months ago)

82 views

Detailed Requirements

Requirements broken down into sub
-
projects with detailed estimates and implementation plans.

The Emergency Contact project requirements can be divided into 4 general categories:

1.

Emergency Online Directory Interface


2.

Banner Workflow Integration


3.

WARN Update Process


4.

WARN Command Interface


Each of these categories address specific requirements from the NIT_Functional_Requirements document.

Emergency Online Directory Interface

These requirements address the needs of the inter
face that will be created to collect emergency contact
information from campus affiliates.

Creation of the Interface
-

NIT 1
-
6, 18, 19, & 22

NIT
-

1:

The Online Directory must allow the UCD population (staff, faculty, med center, students and
affiliates) t
o 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:

Online Directory and WI systems must accept two emergency notificatio
n fields for each of the
following devices: UCD provided cell phone, office phone, and email.

Online Directory and WI systems must accept a total of four emergency notification device fields for
personal cell phone, home phone number, alpha
-
pager numbers
and personal email (limited to two per
device type).

NIT
-

4:

The Online Directory must require recipients to opt
-
out of personal emergency notification.

NIT
-

5:

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

NIT
-

6:

The Online

Directory must pull residence hall information from the Student Housing data base.

NIT
-

18:

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

NIT
-

19:

The WI system must retain and archive change history reports.

NIT
-

22:

The WI system
must maintain an audit trail when a record is viewed but not updated to be
considered an "opt
-
out."

Requirements

Requirement
#

Requirement Description

NIT
-
1.1

The application must be secured via campus single sign
-
on.

NIT
-
1.2

The personal emergency infor
mation must be stored separately from normal business
contact information and be private, not visible via any public directory or in LDAP.

NIT
-
1.3

The personal emergency information must not require approvals.

NIT
-
1.4

The personal emergency information m
ust be updateable by both staff/faculty and
students.

NIT
-
1.5

Users must be allowed to "opt
-
out" of providing personal emergency contact information.
This should be facilitated via a checkbox or radio buttons on the primary interface screen
and stored on
the back end.

NIT
-
1.6

The application must keep track of user views of the personal contact form. Every time a
user visits the form (whether they make changes or not) a timestamp must be maintained
on the back
-
end for audit purposes.

NIT
-
1.7

The applicat
ion must provide useful error messages to end users upon an application error.

NIT
-
1.8

The personal emergency form must be accessible from the main campus people search
pages via a link like "Update My Emergency Contact Information".

NIT
-
1.9

The personal

emergency form must be accessible from the existing online directory
application via a link like "Update My Emergency Contact Information".

NIT
-
1.10

The personal emergency form must have some mention/tie
-
in with the existing online
directory application
such as a link like "View my Business Contact Information".

NIT
-
1.11

The text in the existing online directory application on the listing edit screen that mentions
future collection of personal contact info must be updated to link to the emergency system

NIT
-
1.12

The interface must accept a maximum of 4 devices. Users must be able to select which
devices to include but will be limited to a max of: 2 cell phones, 2 office phones, 2 email
addresses, and 2 pagers.

NIT
-
1.13

Users must be able to select a max

of 3 building locations. A 4th building location will not
be editable by users but will display residence hall building for students if they are in a
residence hall (see NIT
-
1.15).

NIT
-
1.14

The interface must provide a drop
-
down of valid buildings for us
ers to select from.

NIT
-
1.15

The interface must display for students the residence hall they are currently in. This will
not be a modifiable field and will come directly from Student Housing.

NIT
-
1.16

Interface will dynamically ensure user is not enterin
g more than the max number of a
specific type of contact device.

NIT
-
1.17

Interface must validate contact info entered by user. This includes both validation for
proper formatting of device data (i.e. phone number and email format) and validation
against
harmful injection attacks.

NIT
-
1.18

The system must maintain a record of all modified data as well as information about who
made the changes and when. (This will occur exactly the same way as the existing online
directory.)

NIT
-
1.19

The system must provi
de helpful confirmation pages after form submission.

NIT
-
1.20

The interface must allow/require users to select a pager provider from a pre
-
populated
select box when they choose to add a pager.

NIT
-
1.21

The existing "Proxy" function of the online director
y will NOT be supported in the
Emergency Notification interface. (Administrators (ITX) should be able to troubleshoot
problems via a combination of tests using their personal account and the aid of back
-
end
investigation by developers.)

Notes

The interfac
e will differ slightly for staff/faculty and students.

Use Cases

Use Case #1

1.

User is updating business contact information and sees link to update personal emergency contact
info.

2.

User clicks link to view/update personal emergency contact info

3.

User is re
directed to personal emergency info form.

4.

User updates info and clicks save.

Screenshot Mock
-
ups





Implementation

The new screens should be developed using the Java Spring framework. They should reference newly
created database APIs.

New Database tab
les may also be required to maintain "last
-
viewed" history and opt
-
out information.

Every page load needs to call an API procedure to record last view date for the logged in user.

Resources



1 Java developer



1 database programmer

Estimate



18 days (Mira)



16 days (Alex)


Banner Workflow Integration

These requirements address the needs of the Banner SisWeb system to provide students a way to easily
update their emergency contact information during course registration.

Banner Integration
-

NIT 7
-
11

NIT
-

7:

The Banner end
-
user workflow must not be interrupted by the opening of the Online Directory
window and the pages.

NIT
-

8:

The Banner end user must only be asked to log in and authenticate once when they log into SIS
web, the switch to the Online Director
y must not disrupt the work session.

NIT
-

9:

End
-
user must be able to opt
-
out of the personal emergency notification session at any time.

NIT
-

10:

Banner must prompt student to update emergency information only once a term.

NIT
-

11:

Banner must display
contact information that is currently in the Online Directory database. (Is
this a requirement or an implementation detail?)

Requirements

Requirement
#

Requirement Description

NIT
-
4.1

The personal emergency form must integrate with the Banner registration

workflow with
minimal if any disruption.

NIT
-
4.2

Students must not be required to log in a second time, authentication must be integrated
with existing SisWeb authentication. (this should already be done since sisweb uses
distauth.)

NIT
-
4.3

Look and fee
l of emergency form must integrate with sisweb as much as possible.

NIT
-
4.4

Students must receive instructions on the emergency form that explains why they are
there and what they need to do.

NIT
-
4.5

The emergency form must have save/close buttons that w
ork with the banner workflow.
This could mean that they close the existing window or redirect back to sisweb.

NIT
-
4.6

Student must be able to opt
-
out of emergency notification rather than be required to enter
contact info.

NIT
-
4.7

Sisweb must be able to
query the emergency notification system to determine if the logged
in user has viewed/updated information for the current term. This info will be used to
determine if the user should be presented with the emergency form.

Notes

Most of this work will be mi
nimal on the emergency notification end. The primary pieces are the need to
have last view/update date available for sisweb. This may be done by either a database link and direct
queries, or a webservice.

Use Cases

Use Case #1:

1.

Student logs into sisweb for

registration, follows normal reg workflow.

2.

Sisweb queries emergency system to determine last time student viewed emergency data.

3.

Sisweb determines student has not viewed emergency data this term and provides student with
links to take them to the emerge
ncy forms.

4.

Student clicks links, new window opens with emergency form. (Behind scenes, emergency system
records user view of data.)

5.

student reviews data makes changes and saves.

6.

window closes and student continues with sisweb workflow.

Screenshot Mock
-
ups

Implementation

The emergency app will need to be able to accept a URL parameter (or detect the requesting page) that
makes it behave differently for sisweb integration.

When sisweb opens the new window for the emergency form, the emergency form will n
eed to be able to
get the student back to sisweb. It is conceivable that the student could ignore the new window and continue
with registration. The student then may come back to the open window after they have exited theior sisweb
session. The emergency a
pplication will need to be able to handle this situation gracefully.

Resources



1 Java developer



1 database programmer

Estimate



7 days (Mira)



5 days (Alex)


WARN Update Process

These requirements address the needs of the process that transfers contact
information from the Online
Directory into the WARN Command system.

Loading Contact Info
-

NIT 12, 15
-
17, 20 & 21

NIT
-

12:

The WI system must search database records in the Online Directory to find current emergency
notification information.

NIT
-

15:

The

WI system must accept multiple attributes for one recipient.

NIT
-

16:

The WI system must be able to pull all records into one contact list to notify everyone in the
Online Directory database.

NIT
-

1:

The WI system must include contacts at the UCDHS.

NIT

-

20:

The WI system must upload contact information nightly.

NIT
-

21:

The WI system must recognize dual roles and reconcile records (i.e. student/staff)

Requirements

Requirement
#

Requirement Description

NIT
-
5.1

Contact information must be pulled from e
xisting online directory.

NIT
-
5.2

Additional contact information must be pulled from the new personal emergency
application.

NIT
-
5.3

Multiple contact attributes must be accepted per person.

NIT
-
5.4

The system must include faculty, staff, and students as

well as individuals at UCDHS.

NIT
-
5.5

The system must be able to create one contact list of all individuals at both campus and
UCDHS.

NIT
-
5.6

Contact information must be pulled from existing online directory.

NIT
-
5.7

The system must be able to reconcil
e individuals who hold multiple roles, (i.e. student
and staff).

NIT
-
5.8

Contact information must be uploaded to WARN nightly.

NIT
-
5.9

The nightly upload needs to detect/record upload errors and report them to
administrators/developers.

NIT
-
5.10

For eve
ry cell phone uploaded to WARN, a SMS will also be loaded with the same cell
number.

Notes

Use Cases

Use Case #1:

1.

User has contact information in online directory and personal emergency contact application.

2.

During nightly cron job, WI joins the data from

the two sources creating one record containing all
contact info.

3.

this data is uploaded to WARN.

4.

WARN now has contact info for the individual.

Screenshot Mock
-
ups

None. No user interface will exist for this task.

Implementation

One view will be created
to hold all campus/med center individuals. This view may utilize other views
specific to the data upload.

Resources



1 database/application programmer

Estimate



14 days (Alex)

Loading Groups
-

NIT 13 & 14

NIT
-

13:

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
-

14:

The WI system must recognize and separate recipients by pre
-
determined fields such as (a)
building location, (b) home department

(on the primary listing), and (c) status
-

faculty, staff, students,
med center.

Requirements

Requirement
#

Requirement Description

NIT
-
6.1

The system must be able to upload grouping information with the person record. This
information includes but is no
t limited to user type (staff, faculty, student), building
location, committee membership, etc.

NIT6.2

Individuals must be able to put into groups manually rather than via the automated load of
individuals.

Notes

Use Cases

Use Case #1:

1.

user becomes staff

and drops student role.

2.

during nightly load of people, the WI system determines the individuals role has changed and
removes the student affiliation and adds the staff affiliation before loading data to WARN.

3.

data is loaded into WARN and WARN now has st
aff group membership for the individual.

Screenshot Mock
-
ups

None. This does not have a user interface.

Implementation

Resources



1 database programmer

Estimate



5 days (Alex)


WARN Command Interface

These are some specific requirements of the WARN Comma
nd interface as it relates to administrative needs.

Administrator Abilities
-

NIT 23 & 24

NIT
-

23:

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

-

24:

The WARN system must allow administrators and initiators to create call groups and not allow
individuals to designate themselves to a call group.

Requirements

Requirement
#

Requirement Description

NIT
-
7.1

WARN Command must only be accessible by adm
inistrators who have permission to send
emergency notifications and who have a valid username/password

NIT
-
7.2

Administrators must be able to create groups and add individuals to the groups without
the individuals permission or involvement in the process
.

Notes

Use Cases

Use Case #1:

1.

Administrator is alerted that Donald Duck is having a quack attack on the quad.

2.

Administrator logs into WARN Command with valid username/password.

3.

Administrator creates a message intended for all campus individuals informi
ng them to avoid the
quad.

4.

Administrator sends notification.

5.

End users receive notifications via various contact methods.

6.

Disaster is averted.

Screenshot Mock
-
ups

Implementation

Resources



None

Estimate



0 days (this is complete)






Children


Hide Children

|
View in hierarchy

|
Add Child Page


Banner Workflow Integration

(IET Middleware Team)


Emergency Online Directory Interface

(IET Middleware Team)


WARN Command Interface

(IET Middleware Team)


WARN Update Process

(IET Middleware Team)