Unt FRS 108

University of North Texas ARS Functional Requirements Specifications
Remedys Action Request System :

(FRS) Functional Requirements Specifications Document
Prepared By
Axton Grams
Version 1.08
Functional Requirements Specifications

For UNT Internal Use Only
Document Number: UNT-FRS-108
Originated 06/03; Last Updated: 6/18/2003
Table of Contents
1
1.1
1.2
2
2.1
2.2
2.3
2.4
3
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
Versi on Control..................................................................................................................... 3
Purpose .................................................................................................................................3
Revision History......................................................................................................................3
Introduction .......................................................................................................................... 4
Purpose .................................................................................................................................4
Document Scope ....................................................................................................................4
Audience................................................................................................................................4
Document Composition ...........................................................................................................4
Phase 1 (version 5.x implementation)................................................................................... 5
Shared Workflow Functional Requirements ..............................................................................5
Help Desk Functional Requirements ...................................................................................... 13
Change Management Functional Requirements...................................................................... 21
Small Assets Functional Requirements .................................................................................. 28
CEATS / Asset Management Integration ................................................................................ 32
Change Management / Approval Server Integration Functional Requirements .......................... 33
LDAP People Integration and Dependant Integration Functional Requirements ........................ 35
Mid-Tier Common Functional Requirements ........................................................................... 36
Mid-Tier Approval Central Functional Requirements................................................................ 38
Mid-Tier ITSMHelpDesk Functional Requirements .................................................................. 39
Mid-Tier SLA Functional Requirements .................................................................................. 40
Mid-Tier Requester Relative Functional Requirements ............................................................ 41
ARS PERL Web Interface Common Functional Requirements ................................................. 42
WebCT ARS PERL Web Interface Functional Requirements ................................................... 43
Wiring Request ARS PERL Web Interface Functional Requirements........................................ 44
ResNet ARS PERL Web Interface Functional Requirements ................................................... 45
Document Management Sub-system Functional Requirements ............................................... 46

1 Version Control
1.1 Purpose
This section is made available so that different revisions of this document may be differentiated against one
another. Each time this document is made publicly available, an attempt to increase the version, and recap
the changes, date changed, and person making the changes will be recorded. Due to the lack of a sufficient
document control system, the revision data may contain inaccuracies.
1.2 Revision History

Version
Description of Changes
Document Name
Date
Changed by
1.00
1.03
1.06
1.07
1.08
Original Draft
Additional Requirements
Updates to requirements
UNT-FRS-100.doc
UNT-FRS-103.doc
UNT-FRS-106.doc
UNT-FRS-107.doc
UNT-FRS-108.doc
02-06-2003
08-06-2003
10-06-2003
13-06-2003
16-06-2003
Axton
Axton
Axton
Axton
Axton

Grams
Grams
Grams
Grams
Grams
2 Introduction
2.1 Purpose
This document is intended to define the proprietary functional requirements of UNTs Remedy Action Request
System. All the functional requirements outlined in this document are in addition to the out of the box
functional requirements. This document shall be used during subsequent implementations and upgrades to
the ITSM suite of applications and shall serve as a base point for testing in future version implementations.
2.2 Document Scope

This document is meant to serve as a functional statement of each proprietary process and accompanying
requirement. This document does not delve into technical detail about how each of these requirements shall
be met.
2.3 Audience
The paper is intended for UNTs Remedy Administrators, UNTs Remedy Developers, and all other interested
members of UNTs Remedy user community.
2.4 Document Composition

For each functional requirement, the following information will be provided:
-
Functional Requirement Number

o The FRS # shall follow the following general rules:
Each FRS# shall be prefixed with one of the following:
ALL
Shared workflow not specific to any module
HD
Specific to the Help Desk module
CM
Specific to the Change Management module
AM
Specific to the Small Assets module
LDAP People integration to external directory provider
WEB Specific to a particular web interface
Each of these prefixes shall be accompanied by two sets of number
First Number denotes implementation phase
Second number denotes increment of previous number and shall act as a
unique identifier for the FRS in conjunction with the prefix and phase number.
This number may also be accompanied by an alphanumeric character for
similar requirements or functional requirements which comprise of multiple
functional requirements.
o Examples:
ALL-01-0001
CM-01-0013
Functional Requirement Description
o The Description shall provide a detailed description of the functional requirement. This shall
not pertain to any set instructions on how to accomplish or demonstrate this requirement
using the Remedy ITSM applications, but instead shall act as a description of the desired
behavior.
Original Application Behavior
o If the FRS causes a deviation in the behavior of the out of the box application, the out of the
box functional behavior shall be document so that a contrast may be established and
recorded for future reference.

3 Phase 1 (version 5.x implementation)

3.1 Shared Workflow Functional Requirements
FRS #
ALL-01-0001
ALL-01-0002
ALL-01-0003
ALL-01-0004
ALL-01-0005
ALL-01-0006
ALL-01-0107
ALL-01-0108
ALL-01-0109
Description
The Remedy Support console shall allow the ability to search for requests based on
Case/Change/Task ID.
The Remedy Support console shall allow the ability to search for requests based on the
requester.
When creating or modifying bulletin entries, the user shall have the ability to set a
desired expiration date, upon which the bulletin entry shall be removed from visibility.
Bulletin entries shall be removed within (+) 15 minutes of expiration time.
Bulletin entries removed due to expiration time shall not be deleted from the
system (see FRS# ALL-01-0004).
No entries shall be deleted from any form, except where systematic pruning, archiving, or
system processes are contingent.
Special Considerations for Bulletin Boards (see FRS# ALL-01-0003)
Special Considerations for Menu Values (see FRS# ALL-01-0018)
Bulletin entries shall have the ability to be sent as a notification CC Netman.

Bulletin entries shall have the ability to include an attachment. This attachment shall be
included in any notifications triggered from the bulletin.
The quick ticketing forms (Remedy Requester New Request and Remedy Support
New Request) shall require the selection of the requesters role when submitting a
request.
New Request) shall allow the entry of a single UNT property decal, at which point:
The asset record will be related to the accompanying ticket using the association
form
The requester shall be listed as a contact of type 'User' for the asset entered into
the UNT property decal field.
All ticketing forms (CHG:Change, CHG:Task, HPD:HelpDesk, Remedy Requester New
Request, Remedy Support New Request) shall include a protected field for which
sensitive information may be submitted.
Only the requester and UNT internal support individuals who have met the
FERPA requirements (see FRS# ) shall have permission to read/update the data
in the sensitive information field.


New Feature
New Feature
New Feature
New Requirement. This is not enforced in

the out of the box application
New Feature
This feature was added to the HD 5.5
vanilla application.
New Feature
New Feature
New Feature
ALL-01-0110
ALL-01-0111
ALL-01-0112
ALL-01-0015
ALL-01-0216
New Request) shall allow the submission of 1 or more attachment(s) for problem (HD)
requests. (see FRS# HD-01-0001)
New Request) shall be modified to show the following additional information regarding
the requester:
Role
Customer
Capacity
Email
Accounting Code
Withheld Info
New Request) shall allow the requester and/or support individual the ability to specify the
group to which to assign the request.
This functionality shall only be available on 'Remedy Requester New Request
when a non-student role has been selected.
Support users with licenses (Read/Floating/Fixed) shall have the ability to set a
password local to Remedy. All of the following conditions must be met:
An interface to perform password updates shall be accessible from a given
users Personal Preferences.
Users shall only have permission to update their own (implies ownership of the
logged in account) password. This permission shall be enforced using the
following methods:
o Workflow performing the update(AL Pushes, to avoid AL error
messages, and make visible filter error message)
o Row level permissions on the User form
o Column level permissions on the User form
Logging of password values (encrypted/unencrypted) shall not be recorded in
any log files (server-side/client-side).
Access to the ARS system during outages (expected/unexpected) of the AREA
LDAP services (Authentication) must be available if a local password is defined.
For security reasons, form level access to the User form must be restricted to
members of the Administrator group only.
The password change interface shall verify the password entered by prompting
for the value twice, and performing a comparison.
Access to personal information (People Entries) shall be restricted to:
Support personnel who have completed the FERPA training (see FRS# ALL-010042)
The owner/submitter of the particular entry

New Feature
New Feature
New Feature
This feature exists out of the box, but is

not accessible to end users. This feature
needs to be designed so that users do
have access to this feature.
New Feature
Individuals defined as support personnel who have not passed the FERPA training (see
FRS# ALL-01-0042) shall have restricted access to personal profiles:
a limited subset of personal information for other individuals
Full access to their own personal information entry.
ALL-01-0018
This feature shall apply to each of the out of the box views (Support and Management)
on the people form.
A module shall be designed that will allow:
Dynamic menu updates to production menus during operational hours, peak or
off-peak.
Propagate updates to menu values with minimal overhead.
May be utilized anywhere within Remedy where a single-tiered menu is required.
Menu values may not be deleted, but rather must be moved to a non-active
status. (see FRS# ALL-01-0004)
The ordering of the values in the menu selection may be defined.
Comments may be stored with a particular menu.
Menu, menu value additions/modifications may only be performed by the system
administrator.
FRSs dependant on FRS# ALL-01-0018:
ALL-01-0033
HD-01-0014
HD-01-0019
HD-01-0020
HD-01-0021
HD-01-0024
HD-01-0026
HD-01-0030
HD-01-0031
HD-01-0032
HD-01-0033
HD-01-0034
CM-01-0019a
CM-01-0019b
CM-01-0020a
CM-01-0020b
CM-01-0021
CM-01-0026a
CM-01-0026b
CM-01-0024

New Feature. This is similar in concept to

a drop-down field in design, except that
the values may be updated without
updating the form definition from the
Remedy Administrator tool.
ALL-01-0024
ALL-01-0029
ALL-01-0030
ALL-01-0031
ALL-01-0032
People Searching capabilities within Remedy shall include the following fields to query
people profiles:
Last Name
UNT ID
Full Name
Description
Phone
Department
EUID
For each role (see FRS# ALL-01-0030) relating to an individual, a preformatted
customer value shall be generated that outlines the following:
Description (see FRS# ALL-01-0031)
Organization (Region/Site/Department)
Office
Email
Default Customer Support Group
For every person in the system, one of more roles shall be systematically generated for
each of the following:
Student Enrollment Status
Faculty Job Entry
Staff Job Entry
For each role (see FRS# ALL-01-0030) relating to an individual, a preformatted
description value shall be generated that outlines the following:
Role Type (Student or Faculty/Staff)
Job Title/Year-Major
The people profile form shall be updated to include the following additional data
elements, to support UNTs employee and student data dictionaries:
Default Role
College
SSN
Faculty?
Modified Service?
Retiree?
Staff?
Role
Room Number
Customer
Description
NDS -Network ID

This feature is met to some degree in the

out of the box application. The search
dialogs need to be updated to include:
Description
UNT ID
Phone
New Feature
New Feature
New Feature
New Feature
Student?
ContinuingStudent?
LastTermEnrolled
Class
Minor
Degree
Major
Picture
Building
Withheld Info
Additional Requirements:
The Config People form shall be updated to reflect these new values
The workflow associated with the Config People form shall be updated to
handle these operations:
Display
All search methods
Save (Create)
Save (Modify)
Delete
The Office field shall be formatted using the values entered into the Building and
Room Number fields on People and Configure People
Stipulations:
Portions of this requirement can not be implemented until the following FRS(s)
are met. The portions of this requirement that must be skipped until the following
FRS(s) are complete include the following:
o Active Links on SHR:People for:
Save (Update)
Save (Create)
Display (All methods)
The following FRS(s) shall be implemented to fulfill the stipulations listed above for FRS
ALL-01-003.
ALL-01-0216
ALL-01-0042
FRS(s) dependant on FRS ALL-01-0032:
ALL-01-0107
ALL-01-0111
ALL-01-0033
ALL-01-0216 (see above)

ALL-01-0024
ALL-01-0029
ALL-01-0030
ALL-01-0031
The categorization form shall contain control data pertaining to the following request
specific tabs:
EIS, see FRS(s)

o HD-01-0003
o CM-01-0003a
o CM-01-0003b
Wiring Requests, see FRS(s)

o CM-01-0004a
o CM-01-0004b
Additional requirements:
The control data shall only be configurable by an ARS user with Administrator
privelages.
This data will be stored using a custom Yes/No menu (see FRS# ALL-01-0037),
which utilizes the custom menu module (see FRS# ALL-01-0018).
The following tabs are available for the specified application. This should be
enforced through the control fields visibilty from the categorization configuration
form.
o Help Desk Cases:
EIS Tab
o Change Requests:
EIS Tab
Wiring Request Ta b
o Change Tasks:
EIS Tab
Wiring Request Tab
FRS ALL-01-0033 is dependant on FRS(s):
ALL-01-0018
ALL-01-0037
FRS(s) dependant on FRS# ALL-01-0033:
HD-01-0003
CM-01-0003a
10
ALL-01-0034
ALL-01-0035
ALL-01-0036
ALL-01-0037
ALL-01-0038
CM-01-0003b
CM-01-0004a
CM-01-0004b
All required fields within Remedy shall meet the following requirements:
Suffixed with an asterisk (*) at the end of the field label
Provide the field label using a bold font
All fields where a return key-press performs a lookup shall meet the following
requirements:
Suffixed with a plus sign (+) at the end of the field label.
The Remedy Management Console shall provide the ability to view the following
additional request types:
Campus-wide outages
Campus-wide resolved outages
Open requests for my site (shall be based on default role)
For a selected requester
Assigned to an Individual
A custom Yes/No menu menu shall be created for system-wide use. This menu shall
utilize the custom menu module (see FRS# ALL-01-0018).
Dependant on FRS(s):
ALL-01-0018
An auto-assignment module shall be developed to meet the following requirements:
The auto-assignment module shall be self-contained (exist independent of the
ITSM modules).
The auto-assignment module shall process assignement requests for all three
ITSM request types (Help Desk, Change Requests, Change Tasks).
FRS(s) dependant on ALL-01-0038
HD-01-0026
HD-01-0027
CM-01-0026a
CM-01-0026b
CM-01-0027a
CM-01-0027b
ALL-01-0039
FRS ALL-01-0038 is dependant of FRS(s):

ALL-01-0039
ALL-01-0040
Remedy shall provide the ability to specify a default primary support group for every
support individual.

11
Required for section 508 disability

compliance.
Required for section 508 disability
compliance.
ALL-01-0040
The interface to specify the default support group for an individual shall be
accessible from the Configuration Manager
An individuals default support group will be the first group to which the individual
is granted membership.
FRS(s) dependant on FRS ALL-01-0039:

ALL-01-0038
ALL-01-0040
Filters on the ticketing forms (CHG:Change, CHG:Task, HPD:HelpDesk,
SHR:Assignment-Execute (see FRS# ALL-01-0038)) performing an assignment to an
individual (Assignment record of type Individual Skills), the Assigned to Group field
shall be populated with the individuals primary support group (see FRS# ALL-01-0039).
FRS ALL-01-0040 is dependant on FRS(s):
ALL-01-0039
ALL-01-0041
ALL-01-0042
The following FRS(s) are dependant on FRS ALL-01-0040:

ALL-01-0038
Customer definition for distributed areas
A permission group name APP-FERPA shall be created for the following purposes:
Restrict access to data protected under the FERPA act of 1974 to applicable
individuals
APP-Support and APP-Management shall not be dependant on APP-FERPA
membership
APP-Administrator and Administrator group membership shall imply APPFERPA group membership
People shall be added to the APP-FERPA permission group pending completion of the
WebCT FERPA training and testing.

12
3.2 Help Desk Functional Requirements

FRS #
HD-01-0001
HD-01-0002
HD-01-0003
Description
The Help Desk application ticketing form shall allow the ability to store up to 4
attachments with a size limit of 1MB each
The Remedy Help Desk ticketing form shall be modified to show the following additional
information about the requester:
UNT ID
Role (see FRS# ALL-01-0030)
Email
Customer (see FRS# ALL-01-0029)
Accounting Code
Capacity
The Help Desk application ticketing form shall contain a specific tab for EIS requests
which require specific information. This feature shall be governed (visible/hidden) based
on the categorization selection (see FRS# ALL-01-0033).

New Feature
New Feature
New Feature. This functionality shall be

driven by the SHR:Categorization form.
The EIS tab on the Help Desk form shall contain the following fields:
Dependant on FRSs:
FRS# ALL-01-0030
HD-01-0013
HD-01-0014
HD-01-0017
Related FRSs:
CM-01-0003a
CM-01-0003b
The Help Desk application ticketing form shall utilize a form external to the ticketing
forms to collect the following audit information:
Assigned to Individual / Duration
Assigned to Group / Duration
Status / Duration
Categorization / Duration
The audit information (see FRS# HD-01-0013) shall be presented using a method that
that meets the following requirements:
Provides information in a readable format in the windows and web clients
Allows for the selection of the type of audit information to view (Table fields using
external qualifications or multiple table fields using change fields visibility
actions)
Summaries for the Help Desk application ticketing form shall utilize a two-tiered menu

13
New Feature
Status / Duration data is collected in the
Status History field, but this method is
insufficient for this requirement.
New Feature. The summary menu out of
FRS #
HD-01-0019
Description
design
The Pending menus on the Help Desk application ticketing form shall utilize the Menu
Values Feature (see FRS ALL-01-0018)
HD-01-0020
The Source menus on the Help Desk application ticketing form shall utilize the Menu
Values Feature (see FRS ALL-01-0018)
HD-01-0024
The Source field shall be pre-populated by workflow with the source (if interface is
identifiable, see below). These sources are determined to be identifiable and shall be
pre-populated based on the these interfaces:
ARS PERL web interfaces: These interfaces shall be differentiated using
separate source values for each ARS PERL web interface. For example, Wiring
Request PERL interface, WebCT PERL interface, etc.
Mid-Tier web interfaces: These interfaces shall be differentiated using separation
source values for each ARS PERL web interface. For example, Remedy
Requester, Remedy Support, Remedy Management, etc.
Email
Phone
Walk-In
Voicemail
The Urgency menus on the Help Desk ticketing form shall utilize the Menu Values
Feature (see FRS ALL-01-0018), and shall display the following values:
Phone
Requester
Email
Web
NMP
Walk-In
Voicemail
On-Site Request
Palm
WebCT
Eagle
HD-01-0021

14

the box is only single tiered
The Pending menu exists on each of the
ticketing forms, but the out of the box
application utilizes a drop-down list field
type, which requires an update of the form
definition in order to update the menu
values.
The Source menu exists on each of the
values.
This requirement is met to some degree
with the out of the box application. UNTs
interfaces have expanded drastically to
include many more interfaces from which
requests can originate. This information
needs to be captured.
The Urgency (Request Urgency) menu

exists on each of the ticketing forms, but
the out of the box application utilizes a
drop-down list field type, which requires
an update of the form definition in order to
update the menu values.
FRS #
HD-01-0022
HD-01-0023
HD-01-0025
HD-01-0026
Description
RemMail
ResNet
Wiring
Web Relative - Requester
The Help Desk ticketing form shall display a flag/indicator if the requester of the case is
designated as having their personal information withheld under the FERPA act.
The Help Desk ticketing form shall have a drill-down menu available for the three-tiered
categorization menu structure.
The Help Desk ticketing form shall allow the following control of auto-generated
notifications:
Notify Assignee (Yes/No)
Notify Requester (Yes/No)
Notify Assignee Group (Yes/No)
A menu shall be available on Help Desk ticketing form that allows the support person
creating the request the ability to assign the request to one of the following:
To Me
To My Support Group
By Default
New Feature
New Feature
New Feature. By default, the option to
suppress notifications is not available.
New Feature
FRS HD-01-0026 is dependant on FRS(s)

ALL-01-0038
HD-01-0027
HD-01-0028
HD-01-0500
FRS(s) dependant on FRS HD-01-0026

HD-01-0027
The Help Desk ticketing form shall allow the ability to pre-assign a request prior to
submission under each of the following conditions:
Item selection
Classification selection (see FRS# HD-01-0023)
Summary selection
Assignment Process selection (see FRS# HD-01-0026)
FRS HD-01-0027 is dependant on FRS(s)
ALL-01-0038
HD-01-0023
HD-01-0026
The Help Desk ticketing form shall show the assigned group or individuals phone
number.
Notification Enhancement: All outbound emails generated from Help Desk requests to be
sent to an individual assignee shall utilize UWIPs Rem-Mail as the mail transport.

15
New Feature. The out of the box

application performs a ticket assignment
only after submission of the request.
New Feature
Enhancement. Email notifications are
typically distributed using the bundled
FRS #
HD-01-0501
HD-01-0502
HD-01-0503
Description
Except under these conditions:
An email address is not specified in the assignees profile
The default notification method specified in the assignees profile is not set to
Email
The Assignee Notifications enhancement flag (see FRS# HD-01-0025) is
specified as No
Notification Enhancement: All outbound emails generated from Help Desk requests to be
sent to an individual assignee without an email address specified shall utilize Remedys
Notifier/Alert as the method of notification. Except under these conditions:
Notifier
Assignee Notifications (see FRS# HD-01-0025) is specified as No
Email Page notifications updated, see the following FRS#s:
HD-01-0503
HD-01-0504
HD-01-0505
HD-01-0506
For email pages triggered by case assignment, make the following modifications:

Remedy Email Engine. The Assignee
Notifications enhancement is not available
out of the box.
Enhancement. The Assignee

out of the box.
Updated Functionality from the out of the

box application.

box application.
New Subject:
New Body:
Old Subject:
Old Body:
HD-01-0507
SHRH:HPD-PageEmailAssignee
For email pages triggered by denied reassignment, make the following modifications:

box application.
New Subject:
New Body:
Old Subject:
Old Body:
HD-01-0504
SHRH:HPD-PageEmailDenyReasign
For email pages triggered by group reassignment to an assignee, make the following
modifications:
New Subject:
New Body:

16

box application.
FRS #
Description
Old Subject:
Old Body:
HD-01-0505
SHRH:HPD-PageEmailGpToAsignee
For email pages triggered by successful reassignment, make the following modifications:

box application.
New Subject:
New Body:
Old Subject:
Old Body:
HD-01-0506
SHRH:HPD-PageEmailDenyReasign
For assignee email pages triggered by a reopened case, make the following
modifications:

box application.
New Subject:
New Body:
Old Subject:
Old Body:
HD-01-0801
SHRH:HPD-PageEmailReopen
All tickets shall be archived, such that each of the following requirements have been met:
HD-01-0801
HD-01-0802
HD-01-0803
HD-01-0804
HD-01-0805
HD-01-0806
HD-01-0807
When archiving requests, the ability to report on all closed cases shall be possible.
HD-01-0802
When archiving requests, the ability to report on all closed cases shall be possible.
HD-01-0803
When archiving requests, the ability to report on all open cases shall be possible.
HD-01-0800

17
New Feature. No archiving capabilities

are present in the out of the box
application.

application.
application.
FRS #
Description
HD-01-0804
When archiving requests, the ability to report on all open and closed requests for the 30
days shall be possible.
HD-01-0805
After archiving requests, the archived requests shall be removed from the active ticketing
form.
HD-01-0806
When archiving requests, a separate form shall be used to store the archived requests.
HD-01-0807
When archiving requests, the requests shall be archived to the extent that they may be
restored to the active form in the future. Such that after archiving requests, the archived
requests shall have the ability to be manually moved back to the active ticketing form and
reopened.
Cases may not be closed when the category is set to a value of Unknown. Please see
the categorization whitepaper (document number UNT-CAT-xxx.doc) for the reasoning
behind this requirement.
The Priority of a request shall be set based on the value of the requests Urgency.
The Priority shall be set to Urgent for the following Urgency values:
The Priority shall be set to High for the following Urgency values:
The Priority shall be set to Medium for the following Urgency values:
The Priority shall be set to Low for the following Urgency values:
All notifications originating from a Help Desk case intended for the requester of the case
shall utilize UWIPs Rem-Mail mail transport; except under the following conditions:
The requester does not have an email address specified in their profile
Email
The Assignee Notifications enhancement flag (see FRS# HD-01-0025) is
specified as No
See Filter HPD:REM-SuccessSubmitUpdHPD. Needs further definition
See Filter HPD:REM-SuccessSubmitUpdHPD01. Needs further definition
See Filter HPD:REM-SuccessSubmitUpdHPD01a. Needs further definition
See Filter HPD:REM-SuccessSubmitUpdHPD01b. Needs further definition
See Filter HPD:REM-SuccessSubmitUpdHPD02. Needs further definition
Help Desk cases shall be locked at a row level to grant permissions to particular group(s)
HD-01-0029
HD-01-0030
HD-01-0031
HD-01-0032
HD-01-0033
HD-01-0034
HD-01-0507
HD-01-0508
HD-01-0509
HD-01-0510
HD-01-0511
HD-01-0512
HD-01-0035

18

application.
application.
application.
application.
application.
FRS #
HD-01-0036
HD-01-0037
HD-01-0038
HD-01-0039
HD-01-0040
HD-01-0041
HD-01-0042
HD-01-0043
HD-01-0044
HD-01-0045
HD-01-0046
HD-01-0047
HD-01-0048
HD-01-0049
Description
based on rules defined using the following conditions:
Categorization
Location
The Solutions portion of the application shall provide the ability to perform full-text
searches
The following table fields shall perform the desired action on double-click or a row in the
table field:
Requesters Open Cases
Assets Used by Requester
Potential Duplicates
Current Duplicate Cases
Related Items
Potential Incidents
Current Incidents
The Find cases for this customer (see FRS# HD-01-0040) button shall become visible
when a requester is specified while the Help Desk ticketing form is in Search mode.
A button shall be available to perform a query for a particular requesters cases. This
button shall be labeled Find cases for this customer.
The Help Desk ticketing form shall restrict access to sensitive information (as defined by
the FERPA act) to individuals on a field level basis without generating any errors.
A button shall be available that will close the current case.
When a help desk cases is set to a Status of Pending Requester Information or Pending
Requester Availability, a notification shall be sent to the requester, and the individual
placing the request in a pending status shall be notified with a pop-up message
When a request is displayed that is not closed or resolved,
The Resolve Case button shall be set to hidden (see FRS# HD-01-0042)
The Assignment Process field shall be set to hidden (see FRS# HD-01-0026)
The Submit Resolved button shall be set to hidden (see FRS# HD-01-0045)
A button shall be available that will submit a case as resolved.
When creating a request, the support staff shall have the ability to lookup the requester
based on phone number with a carriage return on the Phone field.
When creating a request, the support staff shall have the ability to lookup the requester
based on UNT ID with a carriage return on the UNT ID field.
After submitting a Help Desk case, the case submitted shall be presented in a modify
view.
The Remedy administrator shall have the ability to configure pop-up questions for certain
request types based on the requests classification. This pop-up shall be triggered by
one of the following:

19
FRS #
HD-01-0050
HD-01-0051
HD-01-0052
HD-01-0053
Description
Classification selection
Item selection
Summary menu selection
Set Arrival Time??? See Active Links
+HPD:HPD-SetArrivalTime0a-2b
A pop-up dialog shall be presented to the user if the click on the VIP button. The
message shall state:
"This individual has been flagged as a high priority customer. Please promptly address
this person's requests."
A pop-up dialog shall be presented to the user if the click on the Withheld Info button
(see FRS# HD-01-0022). The message shall state:
"Per UNT Policy Number 18.1.9, stating: The University of North Texas is required to
follow the Family Educational Rights and Privacy Act of 1974 (FERPA). See
http://www.unt.edu/planning/UNT_Policy/volume3/18_1_9.html for further information
about FERPA.
The Help Desk application shall provide the ability to email a selected solution to the
requester from the solutions tab of the help desk ticketing form by the press of a button.

20
3.3 Change Management Functional Requirements

FRS #
CM-01-0003a
Description
The Change Management application main ticketing form shall contain a specific tab for
EIS requests which require specific information. This feature shall be governed
(visible/hidden) based on the categorization selection (see FRS# ALL-01-0033).
The EIS tab on the main change ticketing form shall contain the following fields:
Dependant on FRS (s):

ALL-01-0030
Related FRS (s):
HD-01-0003
CM-01-0003b
CM-01-0004a
CM-01-0004b
CM-01-0003b
The Change Management application sub-task ticketing form shall contain a specific tab
for EIS requests which require specific information. This feature shall be governed
The EIS tab on the main change ticketing form shall contain the following fields:
Dependant on FRS (s):

ALL-01-0030
Related FRS (s):
HD-01-0003
CM-01-0003a
CM-01-0004a
CM-01-0004b
CM-01-0004a
The Change Management application main ticketing form shall contain a specific tab for
wiring requests which require specific information. This feature shall be governed
The Wiring Requests tab on the main change ticketing form shall contain the following

21
FRS #
Description
fields:
Building
Number of Drops
Service Order No
Department For
Billing Account
ALL-01-0030
Related FRS(s):
HD-01-0003
CM-01-0003a
CM-01-0003b
CM-01-0004b
CM-01-0004b
The Change Management application sub-task ticketing form shall contain a specific tab
for wiring requests which require specific information. This feature shall be governed
The Wiring Requests tab on the main change ticketing form shall contain the following
fields:
Service Order No
Requested Completion Date+
Billing Account
Building
Department For
Number of Drops
Trip Charge
Move/Install: JK/Wire IN PLACE
Move/Install: JK/Wire REQUIRED
Minor Work: MODIFED
ALL-01-0030
Related FRS(s):
HD-01-0003
CM-01-0003a

22
FRS #
CM-01-0013
CM-01-0017
Description
CM-01-0003b
CM-01-0004a
The Main Change Request ticketing form shall utilize a form external to the ticketing
forms to collect the following audit information:
Assigned to Individual / Duration
Assigned to Group / Duration
Status / Duration
Categorization / Duration
Summaries for the Main Change Ticketing form shall utilize a two-tiered menu design
CM-01-0019a
The Pending menus on the Main Change ticketing form shall utilize the Menu Values
Feature (see FRS ALL-01-0018)
CM-01-0019b
The Pending menus on the Change sub-task ticketing form shall utilize the Menu Values
Feature (see FRS ALL-01-0018)
CM-01-0020a
The Source menus on Main Change ticketing form shall utilize the Menu Values Feature
(see FRS ALL-01-0018)
CM-01-0020b
The Source menus on the Change sub-task form shall utilize the Menu Values Feature
(see FRS ALL-01-0018)
CM-01-0021
The Urgency menus on the Main Change ticketing form shall utilize the Menu Values
Feature (see FRS ALL-01-0018), and shall display the following values:
Phone
Requester
Email

23
New Feature
Status / Duration data is collected in the
Status History field, but this method is
insufficient for this requirement.
New Feature. The summary menu out of

the box is only single tiered
values.
values.
values.
values.
The Urgency (Request Urgency) menu
exists on each of the ticketing forms, but
the out of the box application utilizes a
drop-down list field type, which requires
an update of the form definition in order to
update the menu values.
FRS #
CM-01-0022a
CM-01-0022b
CM-01-0023a
CM-01-0023b
CM-01-0025a
CM-01-0025b
CM-01-0026a
Description
Web
NMP
Walk-In
Voicemail
On-Site Request
Palm
WebCT
Eagle
RemMail
ResNet
Wiring
Web Relative - Requester
The Main Change ticketing form shall display a flag/indicator if the requester of the case
is designated as having their personal information withheld under the FERPA act.
The Change sub-task form shall display a flag/indicator if the requester of the case is
designated as having their personal information withheld under the FERPA act.
The Main Change ticketing form shall have a drill-down menu available for the threetiered categorization menu structure.
The Change sub-task ticketing form shall have a drill-down menu available for the threetiered categorization menu structure.
The Main Change ticketing form shall allow the following control of auto-generated
notifications:
The Change sub-task ticketing form shall allow the following control of auto-generated
notifications:
A menu shall be available on Main Change ticketing form that allows the support person
creating the request the ability to assign the request to one of the following:
To Me
To My Support Group
By Default
FRS CM -01-0026a is dependant on FRS(s)
ALL-01-0038

24
New Feature
New Feature
New Feature
New Feature

New Feature
FRS #
CM-01-0026b
Description
FRS(s) dependant on FRS CM -01-0026a
CM-01-0027a
A menu shall be available on Change sub-task ticketing form that allows the support
person creating the request the ability to assign the request to one of the following:
To Me
To My Support Group
By Default
New Feature
FRS CM -01-0026b is dependant on FRS(s)

ALL-01-0038
CM-01-0027a
CM-01-0027b
CM-01-0028a
CM-01-0028b
FRS(s) dependant on FRS CM -01-0026b

CM-01-0027b
The Main Change ticketing form shall allow the ability to pre-assign a request prior to
Item menu selection
Classification menu selection (see FRS# CM-01-0023a)
Summary menu selection
Assignment Process menu selection (see FRS# CM-01-0026a)
ALL-01-0038
CM-01-0023a
HD-01-0026a
The Change sub-task ticketing form shall allow the ability to pre-assign a request prior to
Item selection
Classification selection (see FRS# CM-01-0023b)
Summary selection
Assignment Process selection (see FRS# CM-01-0026b)
ALL-01-0038
CM-01-0023b
HD-01-0026b
The Main Change ticketing form shall show the assigned group or individuals phone
number.
The Change sub-task ticketing form shall show the assigned group or individuals phone
number.

25


New Feature
New Feature
FRS #
CM-01-0024
CM-01-0500
CM-01-0501
CM-01-0001
CM-01-0230
Description
The Source field shall be pre-populated by Remedy with the source (if interface is
identifiable, see below). These sources are determined to be pre-populated based on
the source of the request:
ARS PERL web interfaces: These interfaces shall be differentiated using
separate source values for each ARS PERL web interface. For example, Wiring
Request PERL interface, WebCT PERL interface, etc.
Mid-Tier web interfaces: These interfaces shall be differentiated using separation
source values for each ARS PERL web interface. For example, Remedy
Requester, Remedy Support, Remedy Management, etc.
Email
Phone
Walk-In
Voicemail
Notification Enhancement: All outbound emails generated from the Main Change form to
be sent to an individual assignee shall utilize UWIPs Rem-Mail as the mail transport.
Except under these conditions:
An email address is not specified in the assignees profile
Email
The Assignee Notifications enhancement flag (see FRS# CM -01-0025a) is
specified as No
Notification Enhancement: All outbound emails generated from Change Tasks to be sent
to an individual assignee without an email address specified shall utilize Remedys
Notifier/Alert as the method of notification. Except under these conditions:
Notifier
Assignee Notifications (see FRS# CM-01-0025b) is specified as No
When using a predefined task to generate tasks, the following information needs to be
pre-populated:
600100501 Sequence
600040052 Urgency
When creating multiple sub-tasks for a change request, the tasks should have the ability
to be ordered.
This sequencing shall be enforced by one of the following methods, as defined in the
parent change request:
None
Warning
Error

26

This requirement is met to some degree
with the out of the box application. UNTs
interfaces have expanded drastically to
include many more interfaces from which
requests can originate. This information
needs to be captured.
Enhancement. Email notifications are

typically distributed using the bundled
Remedy Email Engine. The Assignee
out of the box.
Enhancement. The Assignee

out of the box.
FRS #
Description
Task ordering requirements:

Multiple tasks may exist at the same sequence
Single tasks may exist at a particular sequence
All tasks may exist at different levels of the task sequence
All tasks may exist at the same level of the task sequence
If a task has prior tasks, according to the sequence, which are not closed; then work may
not begin until the prior tasks are closed.
The task order may not be changed after the task has been moved to a scheduled
status.
CM-01-0250
CM-01-0251
Should the parent change request require approval, the tasks may not be re-ordered
after the approval process has completed.
Assignee notifications (group and individual) triggered from the sub-task form shall not
be delivered until the tasks status has been set to Scheduled.
When relating main change requests, they shall have the ability to be ordered.

27
This is the behavior of the vanilla

application
3.4 Small Assets Functional Requirements

FRS #
AM-01-0001
AM-01-0002
AM-01-0003
AM-01-0004
AM-01-0005
Description
The Small Assets module shall provide the ability to associate one or more server related
services information to a particular asset.
The related services information (see FRS# AM -01-0001) shall provide the means to
collect the following data:
Services Type
o FTP Server
o HTTP Server
o Database Server
o Etc.
Parent Asset ID
Status
o Planned
o In Production
o Testing
o Down
o Decommissioned
Product Name
Service Name
Date of Last Upgrade
Port
Service Pack
Version Sub-Number
Configuration Basic Number
Patch/Build Number
Notes
The server related services information (see FRS# AM -01-0001) shall collect audit
information on the following data:
Date of last Upgrade
Port
Status
Service Type
Patch/Build Number
Service Pack
The Small Assets module shall provide the ability to associate one or more related
network information records to a particular asset.
The network related information (see FRS# AM -01-0004) shall provide the means to

28
FRS #
AM-01-0006
Description
collect the following data:
Parent Asset ID
IP Address
Host Name
Status
o New
o Assigned to System
o Assigned to DHCP Pool
o Reserved
o Available
o Unavailable
o Delete from System
Domain
Subnet Mask
DNS Server
Default Gateway
Protocol
Network Card
IPX Address
MAC Address
Driver
IO Port
Printer Queue
NLM
Service
Notes
The network related information (see FRS# AM -01-0004) shall provide an audit of the
following data:
IP Address
Host Name
Status
o New
o Assigned to System
o Assigned to DHCP Pool
o Reserved
o Available
o Unavailable
o Delete from System
Domain

29
FRS #
AM-01-0007
AM-01-0008
AM-01-0009
AM-01-0010
Description
Subnet Mask
DNS Server
Default Gateway
Protocol
MAC Address
Driver
The Small Assets module shall provide the ability to associate one or more groups to a
particular asset as a contact.
The Small Assets module shall provide the ability to associate one or more individuals to
a particular asset as a contact.
The Small Assets module main form shall be modified to store this additional data:
600030003 Account Number
600030376 Acquisition Cost
600020019 Building
600060003 Class Code Description
600030378 Detail Description
600030377 Inventory Detail #
600030379 Model #
600030002 Purchase Account
600002034 Room Number
600030375 Software Version
600030007 State Class Code
600030022 SystemOS
The Small Assets Component form shall be modified to store this additional data:
600030003 Account Number
600030376 Acquisition Cost
600020019 Building
600060003 Class Code Description
600030378 Detail Description
600030377 Inventory Detail #
600030379 Model #
600030002 Purchase Account
600002034 Room Number
600030375 Software Version
600030007 State Class Code

30

31
3.5 CEATS / Asset Management Integration

FRS #
CTS-01-0001
Description

32
3.6 Change Management / Approval Server Integration Functional Requirements

FRS #
AP-01-0001
AP-01-0002
AP-01-0003
AP-01-0004
AP-01-0005
AP-01-0006
AP-01-0007
AP-01-0008
AP-01-0009
AP-01-0010
AP-01-0011
AP-01-0012
Description
The Change Management application shall require the Submitter to designate an
Approver prior to initiating the approval process
The Change Management application shall not permit the Submitter of a Change request
to also be its Approver
The Change Management application shall enable the Requester to modify an existing
Change request prior to approval
The Change Management application shall prevent a Requester from modifying an
existing Change request after it has been approved.
When a user modifies a Change request after it has been approved, the CM application
shall restart the request's approval process.
The Change Management application shall generate notifications to Approvers:
a. The system shall email notifications to Approvers when a request's approval process
has been activated;
b. The system shall generate reminder emails to those Approvers who have not yet
submitted their approvals/rejections two (2) days prior to the implementation date of a
Change request or task, and every day thereafter until approved.
The Change Management application shall enable users to specify different change
Approvers according to business rules to ensure that appropriate individuals approve the
changes:
a. Users shall be able to designate Approvers by group;
b. Users shall be able to designate Approvers by change type.
The Change Management application shall provide the ability to require that certain
Change requests be approved by multiple groups.
The Change Management application shall include different workflow and approval paths
based on the following three criteria:
a. The values entered in the CTI fields;
b. The value entered in the SAP 'Type of Change' field;
c. Whether SCR or TPR was specified;
d. Whether Non-GMP or GMP was specified.
The Change Management application shall require a 'statement of approval' among the
approval tasks. Approvers will view and approve message:
'I have reviewed this system Change request and the supporting documentation and am
approving the change and verifying that the documentation is adequate'.
The system shall allow the Administrator to grant primary or secondary Change approval
privileges to specific users.
The system shall allow the Administrator to manually change an Approver, enabling
flexibility to expedite emergency Change requests.

33
FRS #
AP-01-0013
AP-01-0014
AP-01-0015
Description
The Change Management application shall allow the Administrator to modify an existing
Change request after it has been approved.
The Change Management application shall require that changes to regulated systems be
approved by Quality Assurance
The Change Management application shall provide ability to require review by
designated individuals prior to the Change request being discussed at the Change
Management Review Board meeting

34
3.7 LDAP People Integration and Dependant Integration Functional Requirements

FRS #
LDAP -01-0013
Description
Department Account Integration

35
3.8 Mid-Tier Common Functional Requirements

FRS #
MT-01-0001
MT-01-0002
MT-01-0003
MT-01-0004
MT-01-0005
MT-01-0006
Description
All Mid-Tier accessible web pages shall be Section 508 compliant. The applications
where accessibility shall be required include, but are not limited to:
Approval Central
ITSM Help Desk
Service Level Agreements
All Mid-Tier views shall be retained, such that each of the following conditions are true:
Form Titles locations shall be retained from the vanilla application
Form Title Bar shall have the same vertical sizing as the vanilla applications
Form Navigation bar item locations shall be retained from the vanilla application
All Mid-Tier views shall have the same field layout as their windows counterpart.
All Mid-Tier Applications shall provide a custom login page which meets the following
requirements:
Display UNT Logos
Display UNT Computer use policies
Display ARS navigation URLs
Display CITC footer
Links for EUIDs
o What's my EUID (pending LDAP implementation)
o Forgot my Password (pending LDAP implementation)
o Request an Account (pending LDAP implementation)
URL for web browser compatibility
All Mid-Tier Application shall provide a custom logout page, which meets the following
requirements:
Display UNT Logos
Display ARS navigation URLs
Display CITC footer
URL for web browser compatibility
Remedy shall use custom background images. The custom images shall retain the
same vertical and horizontal sizing as the vanilla application, but shall present the UNT
logos instead of the Remedy corporation logos.
Vanilla

application image files:

RemedyBackground.jpeg
RemedyBackground.gif
RemedyBackgroundNav.gif
RemedyBackgroundNav.jpeg
36

These interfaces are section 508
compliant in the vanilla application. All
modifications and additions must follow all
508 compliance standards.
FRS #
MT-01-0007
Description

37
3.9 Mid-Tier Approval Central Functional Requirements

FRS #
MT_AP -01-0001
Description

38
3.10 Mid-Tier ITSMHelpDesk Functional Requirements

FRS #
MT_ITMS-01-0001
Description
The ITSMHelpDesk application consoles shall provide access to the "Approval
Central" Mid-Tier application for all roles (requester, support, management)

39
3.11 Mid-Tier SLA Functional Requirements

FRS #
MT_SLA-01-0001
Description

40
3.12 Mid-Tier Requester Relative Functional Requirements

FRS #
MT_RR-01-0001
Description

41
3.13 ARS PERL Web Interface Common Functional Requirements

FRS #
PERL-01-0013
Description

42
3.14 WebCT ARS PERL Web Interface Functional Requirements

FRS #
WebCT_PERL-01-0013

Description
43
3.15 Wiring Request ARS PERL Web Interface Functional Requirements

FRS #
WR_PERL-01-0013

Description
44
3.16 ResNet ARS PERL Web Interface Functional Requirements

FRS #
RN_PERL-01-0013
Description

45
3.17 Document Management Sub-system Functional Requirements

FRS #
DOC-01-0013
Description

46

Unt FRS 108

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Unt FRS 108

Uploaded by

Copyright:

Available Formats

University of North Texas ARS Functional Requirements Specifications

Remedys Action Request System :

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

University of North Texas ARS Functional Requirements Specifications

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

University of North Texas ARS Functional Requirements Specifications

1.2 Revision History

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

University of North Texas ARS Functional Requirements Specifications

2.2 Document Scope

2.4 Document Composition

Functional Requirement Number

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

University of North Texas ARS Functional Requirements Specifications

3 Phase 1 (version 5.x implementation)

Bulletin entries shall have the ability to be sent as a notification CC Netman.

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

Original Application Behavior

New Requirement. This is not enforced in

University of North Texas ARS Functional Requirements Specifications

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

This feature exists out of the box, but is

University of North Texas ARS Functional Requirements Specifications

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

New Feature. This is similar in concept to

University of North Texas ARS Functional Requirements Specifications

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

This feature is met to some degree in the

University of North Texas ARS Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

University of North Texas ARS Functional Requirements Specifications

ALL-01-0216 (see above)

EIS, see FRS(s)

Wiring Requests, see FRS(s)

Originated 06/03; Last Updated: 6/18/2003

University of North Texas ARS Functional Requirements Specifications

FRS ALL-01-0038 is dependant of FRS(s):

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

Required for section 508 disability

University of North Texas ARS Functional Requirements Specifications

FRS(s) dependant on FRS ALL-01-0039:

The following FRS(s) are dependant on FRS ALL-01-0040:

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

University of North Texas ARS Functional Requirements Specifications

3.2 Help Desk Functional Requirements

Original Application Behavior

New Feature. This functionality shall be

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003

New Feature. The summary menu out of

University of North Texas ARS Functional Requirements Specifications

Functional Requirements Specifications

Originated 06/03; Last Updated: 6/18/2003