Unt Dev Meth 100

University of North Texas ARS Development Methodologies
Remedys Action Request System :

UNTs Structured Development Methodologies for Remedy
Prepared By
Axton Grams
Version 1.00
Development Methodologies
For UNT Internal Use Only
Document Number: UNT-DEV_METH-001
Originated 06/03; Last Updated: 6/18/2003
Table of Contents
1
1.1
1.2
2
2.1
2.2
2.3
3
3.1
3.2
3.2.1
3.2.1.1
3.2.1.2
3.2.1.3
4
4.1
4.2
4.3
4.3.1
4.3.1.1
5
5.1
5.1.1
5.1.2
5.2
5.3
5.4
5.5
5.5.1
5.5.1.1
5.5.1.2
5.5.1.3
5.5.1.4
6
6.1
6.2
6.3
Versi on Control..................................................................................................................... 3
Purpose .................................................................................................................................3
Revision History......................................................................................................................3
Introduction .......................................................................................................................... 4
Purpose .................................................................................................................................4
Document Scope ....................................................................................................................4
Audience................................................................................................................................4
Development and Production Architecture ........................................................................... 5
Development and Production Configuration ..............................................................................5
Migrating Changes ..................................................................................................................5
Methods of Migration ..............................................................................................................5
Difference Reports..................................................................................................................5
Form Definition Migration ........................................................................................................5
Workflow Migration .................................................................................................................5
Functional Requirement Specifications................................................................................ 6
Inputs.....................................................................................................................................6
Outputs ..................................................................................................................................6
Sample Functional Requirement Statement ..............................................................................6
Phase 1 (version 5.x implementation).......................................................................................6
Shared Workflow Functional Requirements ..............................................................................6
Functional Requirement Test Scripts ................................................................................... 7
Test Script Requirements ........................................................................................................7
Licenses ................................................................................................................................7
Data.......................................................................................................................................7
Test Script Specifications ........................................................................................................7
Inputs.....................................................................................................................................8
Outputs ..................................................................................................................................8
Sample Test Script ............................................................................................................... 10
The system shall enable users to query all open Help Desk or Change requests by module. ..... 10
Questions and Requirements ................................................................................................ 10
Description........................................................................................................................... 10
Test Script 1-35-A: Query Change Requests .......................................................................... 11
Test Script 1-35-B: Query Help Desk Cases ........................................................................... 12
Functional Requirement Technical Documentation and Packaging Methods..................... 14
Specifications ....................................................................................................................... 14
Inputs................................................................................................................................... 14
Outputs ................................................................................................................................ 14
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-DEV_METH -1 00.doc
06-08-2003
Axton Grams
2 Introduction
This document is intended to define the methods used to facilitate the development, documentation, and
packaging of additional requirements to the Remedy RSM applications. This document is not intended to
define the actual requirements, but instead serves as an outline of the steps and methods used to follow
custom requirements from concept to production.
2.1 Purpose
The intended purpose of this document is to outline a method to achieve the following requirements as they
pertain to application development:
Control requirement scope creep

Avoid requirement overlay/duplication
Provide a method for generating a comprehensive list of requirements
Provide a method to validate functional requirements for the purpose of the following methods of
testing:
o Functional Requirement Validation Testing
o Regression Testing
o Parallel Testing
Provide a method to generate accurate technical documentation in regards to packaging
Provide a method to re-implement enhancements from prior to subsequent versions of Remedys
RSM applications
Several documents produced a direct result of the methodologies outlined in this document. These
documents include:
Functional Requirements Specification

Functional Requirements Test Scripts
Functional Requirements Technical Documentation
Doc #: UNT-FRS-xxx
Doc #: UNT-TEST-xxx
Doc #: UNT-FRS_TECH-xxx
This document will outline the definition and composition of each of the above mentioned documents.
2.2 Document Scope

This document does not address any specific functional requirements, but may include specific functional
requirements to serve as examples on the expected outcome and composition of the resulting documentation.
2.3 Audience
The paper is intended for UNTs Remedy Administrators, UNTs Remedy Developers, and all other interested
members of UNTs Remedy user community. The processes and methodologies outlined in this document
should be considered proprietary and confidential information to the University of North Texas.
3 Development and Production Architecture

3.1 Development and Production Configuration
3.2 Migrating Changes
3.2.1 Methods of Migration
3.2.1.1 Difference Reports
3.2.1.2 Form Definition Migration
3.2.1.3 Workflow Migration
4 Functional Requirement Specifications

The Functional Requirements Specifications document highlights the Functional Requirements Specifications
(FRS) for the University of North Texas. The Functional Requirements Specifications document is not
intended to detail the technical specification for each of the proposed solutions, but to present in a validated
format the high-level requirements submitted by the various groups and users of the Remedy IT Service
Management applications.
4.1 Inputs
Current production 4.x Help Desk applications functionalities implemented in the past. These requirements
were typically not documented in any formal documentation. The requirements must be extrapolated from the
application based on code changes from the vanilla application.
4.2 Outputs
Project phase based list of deliverables/requirements

Functional Requirement Specification Number
Functional Requirement Specification Description
Vanilla Application Behavior
4.3 Sample Functional Requirement Statement

4.3.1 Phase 1 (version 5.x implementation)
4.3.1.1 Shared Workflow Functional Requirements
FRS #
Description
ALL-01-0001
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.
ALL-01-0002
Original Application
Behavior
New Feature
New Feature
5 Functional Requirement Test Scripts

The purpose of the Test Scripts document is to provide a description of each of the Functional Requirements
Specifications (FRS #) based on the Functional Requirements Specifications (FRS) document. For each of
the requirements, the Test Scripts document will provide a description of what the requirement entails; a
series of steps guiding users through the necessary operations to verify the desired functionality; and, how
the test script proves each of the requirements.
5.1 Test Script Requirements

5.1.1 Licenses
The Remedy server used for testing must be licensed with:
Server License
Fixed or Floating User Licenses
HelpDesk-Fixed or HelpDesk-Floating Licenses
SLA Fixed Licenses
5.1.2 Data
The Remedy server that is used for testing must have the following data loaded. The data set does not need
to mirror production or be a complete data set, but should include sufficient data for testing.
Categorizations
Locations
Groups
Support Groups
Special Permission Groups
People
Assets from CEATS
User Ids and Passwords for access
5.2 Test Script Specifications

Typically, multiple test scripts will be generated per FRS because the complexity of the requirement can not
be fully demonstrated using a single test script. The test scripts generated for each FRS should address all
possible facets of the requirement. For example, take the case of FRS# HD-01-0002, which states:
The Remedy Help Desk ticketing form shall be modified to show the following additional information about
the requester:
UNT ID
Role
Email
Customer (see FRS# ALL-01-0029)
Accounting Code
In order to validate FRS# HD-01-0002, a separate test script will need to be generated for each of the
following conditions:
1.
2.
3.
When a person designates the requester using the UNT ID field, ensure all the additional fields
are populated.
When a person designates the requester using the Login Name field, ensure all the additional
fields are populated.
When a person designates the requester using the Search People dialog, ensure all the
additional fields are populated.
4.
5.
When a person creates a people profile for the requester, ensure all the additional fields are
populated.
When a person designates the requester using the Name field, ensure all the additional fields are
populated.
Several critical elements must be present when developing test scripts. These include:
Audience (Typically includes: End Users, Support Staff, ARS Administrators)

Originating Functional Requirement Specification Number
Test ID
Test Script Step ID
Expected Result
The Test ID should follow this format:
<Phase>-<APP>-<TestScriptID>
99-AAAAA-9999
Each step in the Test Script should follow this format:
<Phase>-<APP>-<TestScriptID>-<StepID>
99-AAAA-9999-999
5.3 Inputs
Functional Requirement Specification Number

Functional Requirement Specification Description
5.4 Outputs
FRS #
Test ID #
Role
Functional Requirement Specification Number, as it relates to the Functional

Requirement Specification (FRS) document
Test step based on FRS #
The role of the user performing the test. For the purpose of test scripts, user
roles are broken down into the following categories:
Role
Description
Administrator
This Role includes the application administrator. Test scripts belonging in this role will usually
pertain to application configuration tasks, and not to support specific tasks. Users performing
these tasks must belong to the APP-Administrator and/or Administrator group(s), and are
generally not accessible by general support staff.
This Role includes tests to be performed by people that will be designated as managers who
have cleared the FERPA data accessibility requirements. These tasks will usually include
approvals, service level agreements, and various other managerial tasks. Users performing
these tasks must generally belong to the APP- Management group and APP-FERPA group.
This Role includes tests to be performed by people that will be designated as managers who
have not cleared the FERPA data accessibility requirements. These tasks will usually include
approvals, service level agreements, and various other managerial tasks. Users performing
these tasks must generally belong to the APP- Management group.
The Role includes tests to be performed by people that use the application on a daily basis to
perform work related tasks, manage problem/change requests, and create new requests who
have cleared the FERPA data accessibility requirements. Users performing these tasks must
generally be in the APP-Support group and APP-FERPA group.
The Role includes tests to be performed by people that use the application on a daily basis to
perform work related tasks, manage problem/change requests, and create new requests who
have not cleared the FERPA data accessibility requirements. Users performing these tasks must
generally be in the APP-Support group.
This Role includes tests to be performed by any user, whether via the web and/or the native
client.
FERPA Cleared Management
Not FERPA Cleared Management
FERPA Cleared Support Staff
Not FERPA Cleared Support Staff
Public
Description
Short description of what the test step performs
Action
Expected Result
Response Time
Detailed instructions of how to perform the task described in the description

column.
The expected result when following the instructions in the action column.
The application response time during the step. To be completed by
individual performing the test script.
5.5 Sample Test Script

5.5.1 The system shall enable users to query all open Help Desk or Change requests by module.
FRS #
Requirement Description
ALL-23
<< The system shall enable users to query all open Help Desk or Change requests by module. >>
5.5.1.1 Questions and Requirements

5.5.1.1.1
Tester Signoff
Tester:
Signature/Initials:
5.5.1.1.2
Title:
Date:
Prerequisites
User PC has network access

User PC has the Remedy Client Software installed on PC
User ID in Remedy
User ID has AR User Fixed or AR User Floating license
User ID has Help Desk Fixed or Help Desk Floating license
5.5.1.1.3
PC Information
Testing PC: Model/Processor/Memory/OS

PC Type Used in Test: Desktop or Laptop: (circle one)
Make:
Model:
Processor:
Memory:
Hard Drive Size:
OS Make/Version:
REMEDY Version:
WEB or Client: (circle one)
Client Version:
Browser Type:
Browser Version:
Java Make:
Java Version:
5.5.1.2 Description
This can be accomplished by opening the main form for the module desired in search mode, then performing a Query by Example (QBE) or Advanced
query from that particular form
10
5.5.1.3 Test Script 1-35-A: Query Change Requests

FRS #
Test/Step ID #
Role(s)
Description
ALL-23
ALL-23-A
ALL-23-A -001
Support
Login to Remedy User
1. Login to the Remedy
Remedy User is opened
with a valid account.
User tool.
with no forms open.
Open the Support
1. Click File-> Open
The Remedy Support
Console.
2. Click on the Find tab
Console is displayed in
3. Type Remedy Support in the Remedy User tool
the Search what
keywords? Text field
4. Double-click the row
where the name is
Remedy Support
Open the search
1. Click the Search for
The Main Change form is
Change Request form
Request button
opened in Search mode
(CHG:Change).
2. When prompted with
the Search dialog box,
click the Change
Request button
a. If you are not
prompted with a dialog
to select Change
Request or Help Desk
Case, then you need
to set up your
Personal Preferences.
This can be
accomplished
following the steps
provided below
i. Click on the Utilities> Personal
Preferences menu
ii. When the Setup
Personal
Preferences dialog is
presented, verify that
ALL-23-A -002
ALL-23-A -003
11
Action
Expected Result
Actual Result
Response
Time
ALL-23-A -004
Query the Change

Requests
the New Request

Action is set to Open
Selection Dialog;
and the Search for
Request Action is
set to Open
Selection Dialog
iii. After the values
have been verified,
click the Save button
iv. Click the Close
button after the
Personal
Preferences have
been saved
1. Enter the query
parameters using QBE
or the Advanced search
bar
2. Click Search
The query selects against

all Change requests, and
only returns the records
that match the query
parameters
Action
Expected Result
5.5.1.4 Test Script 1-35-B: Query Help Desk Cases

FRS #
Test/Step ID #
Role(s)
Description
ALL-23
ALL-23-B
ALL-23-B -001
Support
Login to Remedy User
1. Login to the Remedy
Remedy User is opened
with a valid account.
User tool.
with no forms open.
Open the Support
1. Click File-> Open
The Remedy Support
Console.
2. Click on the Find tab
Console is displayed in
3. Type Remedy Support
the Remedy User tool
in the Search what
keywords? Text field
4. Double-click the row
where the name is
Remedy Support
Open the search Help
1. Click the Search for
The Help Desk form is
Desk Cases form
Request button
opened in Search mode
(HPD:HelpDesk).
2. When prompted with
the Search dialog box,
click the Help Desk
button
ALL-23-B -002
ALL-23-B -003
12
Actual Result
Response
Time
ALL-23-B -004
Query the Help Desk

Cases
13
If you are not prompted

with a dialog to select
Change Request or Help
Desk Case, then you need
to set up your Personal
Preferences. This can be
accomplished following the
steps provided below
i. Click on the Utilities->
Personal
Preferences menu
ii. When the Setup
Personal Preferences
dialog is presented,
verify that the New
Request Action is set
to Open Selection
Dialog; and the Search
for Request Action is
set to Open Selection
Dialog
iii. After the values have
been verified, click the
Save button
iv. Click the Close button
after the Personal
Preferences have
been saved
1. Enter the query
parameters using QBE
or the Advanced search
bar
2. Click Search
The query selects against

all Help Desk Cases, and
only returns the records
that match the query
parameters
6 Functional Requirement Technical Documentation and

Packaging Methods
Generate packing list per each functional requirement.
6.1 Specifications
Ensure that these packages can be migrated into the vanilla RSM application without intefering with
oob workflow.
Ensure that this package can interoperate with other packages without introducing inteference.
Ensure that this package contains all the contents required to operate independantly of all other
packages.
All of the above requirements should be met with the expectation that each may be loaded to the
vanilla application without being dependant on any other packages, and interoperate with all other
packages. Each of these packages may then be easily retrofitted in the future for subsequent
releases of the RSM application. Also, each and packages shall be versioned according to the RSM
application to which they apply.
6.2 Inputs
Functional requirement specification.

Accompanying test scripts.
Working version of FRS on test server.
6.3 Outputs
Packing List
DEF file of the following:
o Forms, which only include the fields that were created and/or modified for this particular
functional requirement.
o Active Links which pertain to this package. All new active links shall be prefixed with a plus
sign (+), and all modified active links shall be prefixed with an asterisk (*).
o Filters which pertain to this package. All new filters shall be prefixed with a plus sign (+), and
all modified filters shall be prefixed with an asterisk (*).
o Menus which pertain to this package. All new menus shall be prefixed with a plus sign (+),
and all modified menus shall be prefixed with an asterisk (*).
o Escalations which pertain to this package. All new escalations shall be prefixed with a plus
sign (+), and all modified escalations shall be prefixed with an asterisk (*).
o Active Link Guides which pertain to this package. All new active link guides shall be
prefixed with a plus sign (+), and all modified active link guides shall be prefixed with an
asterisk (*).
o Filter Guides which pertain to this package. All new filter guides shall be prefixed with a plus
sign (+), and all modified filter guides shall be prefixed with an asterisk (*).
o Applications which pertain to this package. All new application shall be prefixed with a plus
sign (+), and all modified applications shall be prefixed with an asterisk (*).
o Web Services which pertain to this package. All new web services shall be prefixed with a
plus sign (+), and all modified web services shall be prefixed with an asterisk (*).
ARX Data files for the following:
o All new permission groups which are required for this particular functional requirement
o All configuration records which are required for this particular functional requirement
For example:
Menu Value entries
SHRCFG:ConfigTmpIndex entries
SQL script to disable modified workflow objects.
o When workflow is modified, its name shall be captured and included in the packing list. A
comprehensive list of the modified workflow shall be used to generate a SQL script which will
14
disable the original workflow, so that when the modified workflow is migrated to a server, the
two will not conflict.
15

Unt Dev Meth 100

Загружено:

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

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

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

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

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

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

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

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

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

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

Unt Dev Meth 100

Загружено:

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

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

University of North Texas ARS Development Methodologies

Remedys Action Request System :

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

University of North Texas ARS Development Methodologies

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

University of North Texas ARS Development Methodologies

1.2 Revision History

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

University of North Texas ARS Development Methodologies

Control requirement scope creep

Functional Requirements Specification

2.2 Document Scope

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

University of North Texas ARS Development Methodologies

3 Development and Production Architecture

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

University of North Texas ARS Development Methodologies

4 Functional Requirement Specifications

Project phase based list of deliverables/requirements

4.3 Sample Functional Requirement Statement

The Remedy Support console shall allow the ability to search

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

University of North Texas ARS Development Methodologies

5 Functional Requirement Test Scripts

5.1 Test Script Requirements

5.2 Test Script Specifications

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

University of North Texas ARS Development Methodologies

Audience (Typically includes: End Users, Support Staff, ARS Administrators)

The Test ID should follow this format:

Each step in the Test Script should follow this format:

Functional Requirement Specification Number

Functional Requirement Specification Number, as it relates to the Functional

FERPA Cleared Management

Not FERPA Cleared Management

FERPA Cleared Support Staff

Not FERPA Cleared Support Staff

Short description of what the test step performs

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

University of North Texas ARS Development Methodologies

Detailed instructions of how to perform the task described in the description

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

University of North Texas ARS Development Methodologies

5.5 Sample Test Script

5.5.1.1 Questions and Requirements

User PC has network access

Testing PC: Model/Processor/Memory/OS

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

University of North Texas ARS Development Methodologies

5.5.1.3 Test Script 1-35-A: Query Change Requests

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

University of North Texas ARS Development Methodologies

Query the Change

the New Request

The query selects against

5.5.1.4 Test Script 1-35-B: Query Help Desk Cases

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

University of North Texas ARS Development Methodologies

Query the Help Desk

If you are not prompted

The query selects against

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

University of North Texas ARS Development Methodologies

6 Functional Requirement Technical Documentation and