UNT-FRS-108

University of North Texas ARS Functional Requirements Specifications

Functional Requirements Specifications 1 Originated 06/03; Last Updated: 6/18/2003 For UNT Internal Use Only Document Number: UNT-FRS-108

Remedy’s Action Request System: (FRS) Functional Requirements Specifications Document

Prepared By

Axton Grams

Version 1.08



Table of Contents 1 Version Control.....................................................................................................................3 1.1 Purpose .................................................................................................................................3 1.2 Revision History......................................................................................................................3

2 Introduction ..........................................................................................................................4 2.1 Purpose .................................................................................................................................4 2.2 Document Scope ....................................................................................................................4 2.3 Audience................................................................................................................................4 2.4 Document Composition ...........................................................................................................4

3 Phase 1 (version 5.x implementation)...................................................................................5 3.1 Shared Workflow Functional Requirements ..............................................................................5 3.2 Help Desk Functional Requirements ......................................................................................13 3.3 Change Management Functional Requirements......................................................................21 3.4 Small Assets Functional Requirements ..................................................................................28 3.5 CEATS / Asset Management Integration ................................................................................32 3.6 Change Management / Approval Server Integration Functional Requirements ..........................33 3.7 LDAP People Integration and Dependant Integration Functional Requirements ........................35 3.8 Mid-Tier Common Functional Requirements ...........................................................................36 3.9 Mid-Tier Approval Central Functional Requirements................................................................38 3.10 Mid-Tier ITSMHelpDesk Functional Requirements ..................................................................39 3.11 Mid-Tier SLA Functional Requirements ..................................................................................40 3.12 Mid-Tier Requester Relative Functional Requirements ............................................................41 3.13 ARS PERL Web Interface Common Functional Requirements .................................................42 3.14 WebCT ARS PERL Web Interface Functional Requirements ...................................................43 3.15 Wiring Request ARS PERL Web Interface Functional Requirements........................................44 3.16 ResNet ARS PERL Web Interface Functional Requirements ...................................................45 3.17 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 Original Draft UNT-FRS-100.doc 02-06-2003 Axton Grams 1.03 Additional Requirements UNT-FRS-103.doc 08-06-2003 Axton Grams 1.06 Additional Requirements UNT-FRS-106.doc 10-06-2003 Axton Grams 1.07 Additional Requirements UNT-FRS-107.doc 13-06-2003 Axton Grams 1.08 Updates to requirements UNT-FRS-108.doc 16-06-2003 Axton Grams



2 Introduction

2.1 Purpose This document is intended to define the proprietary functional requirements of UNT’s 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 UNT’s Remedy Administrators, UNT’s Remedy Developers, and all other interested members of UNT’s 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 # Description Original Application Behavior ALL-01-0001 The Remedy Support console shall allow the ability to search for requests based on

Case/Change/Task ID. New Feature

ALL-01-0002 The Remedy Support console shall allow the ability to search for requests based on the requester.

New Feature

ALL-01-0003 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).

New Feature

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) •

New Requirement. This is not enforced in the out of the box application

ALL-01-0005 Bulletin entries shall have the ability to be sent as a notification CC Netman. New Feature ALL-01-0006 Bulletin entries shall have the ability to include an attachment. This attachment shall be

included in any notifications triggered from the bulletin. This feature was added to the HD 5.5 vanilla application.

ALL-01-0107 The quick ticketing forms (Remedy Requester – New Request and Remedy Support – New Request) shall require the selection of the requester’s role when submitting a request.

New Feature

ALL-01-0108 The quick ticketing forms (Remedy Requester – New Request and Remedy Support – 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.

New Feature

ALL-01-0109 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



ALL-01-0110 The quick ticketing forms (Remedy Requester – New Request and Remedy Support – New Request) shall allow the submission of 1 or more attachment(s) for problem (HD) requests. (see FRS# HD-01-0001)

New Feature

ALL-01-0111 The quick ticketing forms (Remedy Requester – New Request and Remedy Support – New Request) shall be modified to show the following additional information regarding the requester:

- Role - Customer - Capacity - Email - Accounting Code - Withheld Info

New Feature

ALL-01-0112 The quick ticketing forms (Remedy Requester – New Request and Remedy Support – 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.

New Feature

ALL-01-0015 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 user’s 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.

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.

ALL-01-0216 Access to personal information (People Entries) shall be restricted to: • Support personnel who have completed the FERPA training (see FRS# ALL-01-

0042) • The owner/submitter of the particular entry

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.

This feature shall apply to each of the out of the box views (Support and Management) on the people form.

ALL-01-0018 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 People Searching capabilities within Remedy shall include the following fields to query people profiles:

• Last Name • UNT ID • Full Name • Description • Phone • Department • EUID

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

ALL-01-0029 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

New Feature

ALL-01-0030 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

New Feature

ALL-01-0031 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

New Feature

ALL-01-0032 The people profile form shall be updated to include the following additional data elements, to support UNT’s employee and student data dictionaries:

• Default Role • College • SSN • Faculty? • Modified Service? • Retiree? • Staff? • Role • Room Number • Customer • Description • NDS-Network ID

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-0216 (see above) • ALL-01-0024 • ALL-01-0029 • ALL-01-0030 • ALL-01-0031

ALL-01-0033 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



• CM-01-0003b • CM-01-0004a • CM-01-0004b

ALL-01-0034 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

Required for section 508 disability compliance.

ALL-01-0035 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.

Required for section 508 disability compliance.

ALL-01-0036 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

ALL-01-0037 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

ALL-01-0038 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

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

• ALL-01-0039 • ALL-01-0040

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



• The interface to specify the default support group for an individual shall be accessible from the “Configuration Manager”

• An individual’s 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

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 individual’s primary support group (see FRS# ALL-01-0039). FRS ALL-01-0040 is dependant on FRS(s):

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

• ALL-01-0038

ALL-01-0041 Customer definition for distributed areas ALL-01-0042 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 APP-FERPA group membership

People shall be added to the APP-FERPA permission group pending completion of the WebCT FERPA training and testing.



3.2 Help Desk Functional Requirements FRS # Description Original Application Behavior HD-01-0001 The Help Desk application ticketing form shall allow the ability to store up to 4

attachments with a size limit of 1MB each New Feature

HD-01-0002 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

New Feature

HD-01-0003 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). The EIS tab on the Help Desk form shall contain the following fields:

• Dependant on FRSs:

• FRS# ALL-01-0030 Related FRSs:

• CM-01-0003a • CM-01-0003b

New Feature. This functionality shall be driven by the SHR:Categorization form.

HD-01-0013 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

New Feature Status / Duration data is collected in the Status History field, but this method is insufficient for this requirement.

HD-01-0014 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)

HD-01-0017 Summaries for the Help Desk application ticketing form shall utilize a two-tiered menu New Feature. The summary menu out of



FRS # Description Original Application Behavior design the box is only single tiered

HD-01-0019 The Pending menus on the Help Desk application ticketing form shall utilize the Menu Values Feature (see FRS ALL-01-0018)

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.

HD-01-0020 The Source menus on the Help Desk application ticketing form shall utilize the Menu Values Feature (see FRS ALL-01-0018)

The Source 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.

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

This requirement is met to some degree with the out of the box application. UNT’s interfaces have expanded drastically to include many more interfaces from which requests can originate. This information needs to be captured.

HD-01-0021 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

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 # Description Original Application Behavior • RemMail • ResNet • Wiring • Web Relative - Requester

HD-01-0022 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.

New Feature

HD-01-0023 The Help Desk ticketing form shall have a drill-down menu available for the three-tiered categorization menu structure.

New Feature

HD-01-0025 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)

New Feature. By default, the option to suppress notifications is not available.

HD-01-0026 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

FRS HD-01-0026 is dependant on FRS(s)

• ALL-01-0038 FRS(s) dependant on FRS HD-01-0026

• HD-01-0027

New Feature

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

New Feature. The out of the box application performs a ticket assignment only after submission of the request.

HD-01-0028 The Help Desk ticketing form shall show the assigned group or individual’s phone number.

New Feature

HD-01-0500 Notification Enhancement: All outbound emails generated from Help Desk requests to be sent to an individual assignee shall utilize UWIP’s Rem-Mail as the mail transport.

Enhancement. Email notifications are typically distributed using the bundled



FRS # Description Original Application Behavior Except under these conditions:

• An email address is not specified in the assignee’s profile • The default notification method specified in the assignee’s profile is not set to

“Email” • The Assignee Notifications enhancement flag (see FRS# HD-01-0025) is

specified as “No”

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

HD-01-0501 Notification Enhancement: All outbound emails generated from Help Desk requests to be sent to an individual assignee without an email address specified shall utilize Remedy’s Notifier/Alert as the method of notification. Except under these conditions:

• The default notification method specified in the assignee’s profile is not set to “Notifier”

• Assignee Notifications (see FRS# HD-01-0025) is specified as “No”

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

HD-01-0502 Email Page notifications updated, see the following FRS#s: • HD-01-0503 • HD-01-0504 • HD-01-0505 • HD-01-0506

Updated Functionality from the out of the box application.

HD-01-0503 For email pages triggered by case assignment, make the following modifications: New Subject: New Body: Old Subject: Old Body: SHRH:HPD-PageEmailAssignee


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


HD-01-0504 For email pages triggered by group reassignment to an assignee, make the following modifications: New Subject: New Body:




FRS # Description Original Application Behavior Old Subject: Old Body: SHRH:HPD-PageEmailGpToAsignee

HD-01-0505 For email pages triggered by successful reassignment, make the following modifications: New Subject: New Body: Old Subject: Old Body: SHRH:HPD-PageEmailDenyReasign


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


HD-01-0800 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

New Feature. No archiving capabilities are present in the out of the box application.

HD-01-0801 When archiving requests, the ability to report on all closed cases shall be possible. New Feature. No archiving capabilities are present in the out of the box application.

HD-01-0802 When archiving requests, the ability to report on all closed cases shall be possible. New Feature. No archiving capabilities are present in the out of the box application.

HD-01-0803 When archiving requests, the ability to report on all open cases shall be possible. New Feature. No archiving capabilities are present in the out of the box



FRS # Description Original Application Behavior application.

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. New Feature. No archiving capabilities are present in the out of the box application.

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.


HD-01-0029 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.

HD-01-0030 The Priority of a request shall be set based on the value of the requests Urgency. HD-01-0031 The Priority shall be set to Urgent for the following Urgency values:

•

HD-01-0032 The Priority shall be set to High for the following Urgency values: •

HD-01-0033 The Priority shall be set to Medium for the following Urgency values: •

HD-01-0034 The Priority shall be set to Low for the following Urgency values: •

HD-01-0507 All notifications originating from a Help Desk case intended for the requester of the case shall utilize UWIP’s Rem-Mail mail transport; except under the following conditions:

• The requester does not have an email address specified in their profile • The default notification method specified in the assignee’s profile is not set to

“Email” • The Assignee Notifications enhancement flag (see FRS# HD-01-0025) is


HD-01-0508 See Filter HPD:REM-SuccessSubmitUpdHPD. Needs further definition HD-01-0509 See Filter HPD:REM-SuccessSubmitUpdHPD01. Needs further definition HD-01-0510 See Filter HPD:REM-SuccessSubmitUpdHPD01a. Needs further definition HD-01-0511 See Filter HPD:REM-SuccessSubmitUpdHPD01b. Needs further definition HD-01-0512 See Filter HPD:REM-SuccessSubmitUpdHPD02. Needs further definition HD-01-0035 Help Desk cases shall be locked at a row level to grant permissions to particular group(s)



FRS # Description Original Application Behavior based on rules defined using the following conditions:

• Categorization • Location

HD-01-0036 HD-01-0037 The Solutions portion of the application shall provide the ability to perform full-text

searches

HD-01-0038 The following table fields shall perform the desired action on double-click or a row in the table field:

• Requester’s Open Cases • Assets Used by Requester • Potential Duplicates • Current Duplicate Cases • Related Items • Potential Incidents • Current Incidents

HD-01-0039 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.

HD-01-0040 A button shall be available to perform a query for a particular requester’s cases. This button shall be labeled “Find cases for this customer”.

HD-01-0041 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.

HD-01-0042 A button shall be available that will close the current case. HD-01-0043 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

HD-01-0044 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)

HD-01-0045 A button shall be available that will submit a case as resolved. HD-01-0046 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.

HD-01-0047 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.

HD-01-0048 After submitting a Help Desk case, the case submitted shall be presented in a modify view.

HD-01-0049 The Remedy administrator shall have the ability to configure pop-up questions for certain request types based on the request’s classification. This pop-up shall be triggered by one of the following:



FRS # Description Original Application Behavior • Classification selection • Item selection • Summary menu selection

HD-01-0050 Set Arrival Time??? See Active Links +HPD:HPD-SetArrivalTime0a-2b

HD-01-0051 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."

HD-01-0052 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.”

HD-01-0053 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.



3.3 Change Management Functional Requirements FRS # Description Original Application Behavior CM-01-0003a 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 (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-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 (visible/hidden) based on the categorization selection (see FRS# ALL-01-0033). The Wiring Requests tab on the main change ticketing form shall contain the following



FRS # Description Original Application Behavior fields:

• Building • Number of Drops • Service Order No • Department For • Billing Account

Dependant on FRS(s):

• 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 (visible/hidden) based on the categorization selection (see FRS# ALL-01-0033). 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

Dependant on FRS(s):

• ALL-01-0030 Related FRS(s):

• HD-01-0003 • CM-01-0003a



FRS # Description Original Application Behavior • CM-01-0003b • CM-01-0004a

CM-01-0013 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

New Feature Status / Duration data is collected in the Status History field, but this method is insufficient for this requirement.

CM-01-0017 Summaries for the Main Change Ticketing form shall utilize a two-tiered menu design New Feature. The summary menu out of the box is only single tiered

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

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 # Description Original Application Behavior • Web • NMP • Walk-In • Voicemail • On-Site Request • Palm • WebCT • Eagle • RemMail • ResNet • Wiring • Web Relative - Requester

CM-01-0022a 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.

New Feature

CM-01-0022b 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.

New Feature

CM-01-0023a The Main Change ticketing form shall have a drill-down menu available for the three-tiered categorization menu structure.

New Feature

CM-01-0023b The Change sub-task ticketing form shall have a drill-down menu available for the three-tiered categorization menu structure.

New Feature

CM-01-0025a The Main Change ticketing form shall allow the following control of auto-generated notifications:



CM-01-0025b The Change sub-task ticketing form shall allow the following control of auto-generated notifications:



CM-01-0026a 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

New Feature



FRS # Description Original Application Behavior FRS(s) dependant on FRS CM-01-0026a

• CM-01-0027a CM-01-0026b 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 FRS CM-01-0026b is dependant on FRS(s)

• ALL-01-0038 FRS(s) dependant on FRS CM-01-0026b

• CM-01-0027b

New Feature

CM-01-0027a The Main Change ticketing form shall allow the ability to pre-assign a request prior to submission under each of the following conditions:

• 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


CM-01-0027b The Change sub-task 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# CM-01-0023b) • Summary selection • Assignment Process selection (see FRS# CM-01-0026b)


• ALL-01-0038 • CM-01-0023b • HD-01-0026b


CM-01-0028a The Main Change ticketing form shall show the assigned group or individual’s phone number.

New Feature

CM-01-0028b The Change sub-task ticketing form shall show the assigned group or individual’s phone number.

New Feature



FRS # Description Original Application Behavior CM-01-0024 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

This requirement is met to some degree with the out of the box application. UNT’s interfaces have expanded drastically to include many more interfaces from which requests can originate. This information needs to be captured.

CM-01-0500 Notification Enhancement: All outbound emails generated from the Main Change form to be sent to an individual assignee shall utilize UWIP’s Rem-Mail as the mail transport. Except under these conditions:

• An email address is not specified in the assignee’s profile • The default notification method specified in the assignee’s profile is not set to

“Email” • The Assignee Notifications enhancement flag (see FRS# CM -01-0025a) is


Enhancement. Email notifications are typically distributed using the bundled Remedy Email Engine. The Assignee Notifications enhancement is not available out of the box.

CM-01-0501 Notification Enhancement: All outbound emails generated from Change Tasks to be sent to an individual assignee without an email address specified shall utilize Remedy’s Notifier/Alert as the method of notification. Except under these conditions:

• The default notification method specified in the assignee’s profile is not set to “Notifier”

• Assignee Notifications (see FRS# CM-01-0025b) is specified as “No”

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

CM-01-0001 When using a predefined task to generate tasks, the following information needs to be pre-populated: 600100501 Sequence 600040052 Urgency

CM-01-0230 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



FRS # Description Original Application Behavior 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. Should the parent change request require approval, the tasks may not be re-ordered after the approval process has completed.

CM-01-0250 Assignee notifications (group and individual) triggered from the sub-task form shall not be delivered until the task’s status has been set to Scheduled.

This is the behavior of the vanilla application

CM-01-0251 When relating main change requests, they shall have the ability to be ordered.



3.4 Small Assets Functional Requirements FRS # Description Original Application Behavior AM-01-0001 The Small Assets module shall provide the ability to associate one or more server related

services information to a particular asset.

AM-01-0002 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

AM-01-0003 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

AM-01-0004 The Small Assets module shall provide the ability to associate one or more related network information records to a particular asset.

AM-01-0005 The network related information (see FRS# AM -01-0004) shall provide the means to



FRS # Description Original Application Behavior 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

AM-01-0006 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



FRS # Description Original Application Behavior • Subnet Mask • DNS Server • Default Gateway • Protocol • MAC Address • Driver

AM-01-0007 The Small Assets module shall provide the ability to associate one or more groups to a particular asset as a contact.

AM-01-0008 The Small Assets module shall provide the ability to associate one or more individuals to a particular asset as a contact.

AM-01-0009 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

AM-01-0010 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



3.5 CEATS / Asset Management Integration FRS # Description Original Application Behavior CTS-01-0001



3.6 Change Management / Approval Server Integration Functional Requirements FRS # Description Original Application Behavior AP-01-0001 The Change Management application shall require the Submitter to designate an

Approver prior to initiating the approval process

AP-01-0002 The Change Management application shall not permit the Submitter of a Change request to also be its Approver

AP-01-0003 The Change Management application shall enable the Requester to modify an existing Change request prior to approval

AP-01-0004 The Change Management application shall prevent a Requester from modifying an existing Change request after it has been approved.

AP-01-0005 When a user modifies a Change request after it has been approved, the CM application shall restart the request's approval process.

AP-01-0006 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.

AP-01-0007 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.

AP-01-0008 The Change Management application shall provide the ability to require that certain Change requests be approved by multiple groups.

AP-01-0009 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.

AP-01-0010 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'.

AP-01-0011 The system shall allow the Administrator to grant primary or secondary Change approval privileges to specific users.

AP-01-0012 The system shall allow the Administrator to manually change an Approver, enabling flexibility to expedite emergency Change requests.



FRS # Description Original Application Behavior AP-01-0013 The Change Management application shall allow the Administrator to modify an existing

Change request after it has been approved.

AP-01-0014 The Change Management application shall require that changes to regulated systems be approved by Quality Assurance

AP-01-0015 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



3.7 LDAP People Integration and Dependant Integration Functional Requirements FRS # Description Original Application Behavior LDAP-01-0013 Department Account Integration



3.8 Mid-Tier Common Functional Requirements FRS # Description Original Application Behavior MT-01-0001 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

These interfaces are section 508 compliant in the vanilla application. All modifications and additions must follow all 508 compliance standards.

MT-01-0002 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

MT-01-0003 All Mid-Tier views shall have the same field layout as their windows counterpart. MT-01-0004 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

MT-01-0005 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

MT-01-0006 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



FRS # Description Original Application Behavior MT-01-0007



3.9 Mid-Tier Approval Central Functional Requirements FRS # Description Original Application Behavior MT_AP-01-0001



3.10 Mid-Tier ITSMHelpDesk Functional Requirements FRS # Description Original Application Behavior MT_ITMS-01-0001 The ITSMHelpDesk application consoles shall provide access to the "Approval

Central" Mid-Tier application for all roles (requester, support, management)



3.11 Mid-Tier SLA Functional Requirements FRS # Description Original Application Behavior MT_SLA-01-0001



3.12 Mid-Tier Requester Relative Functional Requirements FRS # Description Original Application Behavior MT_RR-01-0001



3.13 ARS PERL Web Interface Common Functional Requirements FRS # Description Original Application Behavior PERL-01-0013



3.14 WebCT ARS PERL Web Interface Functional Requirements FRS # Description Original Application Behavior WebCT_PERL-01-0013



3.15 Wiring Request ARS PERL Web Interface Functional Requirements FRS # Description Original Application Behavior WR_PERL-01-0013



3.16 ResNet ARS PERL Web Interface Functional Requirements FRS # Description Original Application Behavior RN_PERL-01-0013



3.17 Document Management Sub-system Functional Requirements FRS # Description Original Application Behavior DOC-01-0013

UNT-FRS-108

Documents

Transcript of UNT-FRS-108