UITS
PROJECT/SUB-PROJECT TITLE>
<
Functional Requirements Document
Genesys data integration project
FAMIS Team
Prepared for
University Information Technology Services
Babbidge Library, Storrs CT
369 Fairfield Rd, Unit 2209
Storrs, CT 06269-2209
File Name: Document3
Overview
Functional Requirements Document
Page 1 of 11
January 14, 2014
UITS
PROJECT/SUB-PROJECT TITLE>
<
The functional requirements document (FRD) is a formal statement of an application’s
functional requirements. It serves the same purpose as a contract. The developers agree to
provide the capabilities specified. The client agrees to find the product satisfactory if it provides
the capabilities specified in the FRD.
Quality is meeting requirements. For that reason, the FRD is the central document in system
development. It is used for the following:



Designing and developing the application system.
Evaluating the product in all subsequent phases of the life cycle.
Determining the success of the project.
The FRD has the following characteristics:



It demonstrates that the application provides value to the University in terms of the
business objectives and business processes in the 5-year plan.
It contains a complete set of requirements for the application. It leaves no room for
anyone to assume anything not stated in the FRD.
It is solution independent. The ERD is a statement of what the application is to do—
not of how it works. The FRD does not commit the developers to a design. For that
reason, any reference to the use of a specific technology is entirely inappropriate in
an FRD.
A requirement is a condition that the application must meet for the customer to find the
application satisfactory. A requirement has the following characteristics:






It provides a benefit to the organization.
It describes the capabilities the application must provide in business terms.
It does not describe how the application provides that capability.
It does not describe such design considerations as computer hardware, operating
system, and database design.
It is stated in unambiguous words. Its meaning is clear and understandable.
It is verifiable.
Functional Requirements Document
Page 2 of 11
January 14, 2014
UITS
PROJECT/SUB-PROJECT TITLE>
<
TABLE OF CONTENTS
1 General ............................................................................................................................................... 4
1.1 Project Description ............................................................................................................................... 4
1.1.1 Background ...................................................................................................................................................... 4
1.1.2 Purpose .............................................................................................................................................................. 4
1.1.3 Assumptions and Constraints ................................................................................................................... 4
1.1.4 Interfaces to External Systems ................................................................................................................. 4
1.2 Points of Contact .................................................................................................................................... 4
1.3 Document References .......................................................................................................................... 4
2 FUNCTIONAL REQUIREMENTS ................................................................................................... 4
2.1
2.2
Data Requirements ............................................................................................................................... 5
Functional Process Requirements ................................................................................................... 5
3 OPERATIONAL REQUIREMENTS ................................................................................................ 6
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Security ...................................................................................................................................................... 6
Audit Trail ................................................................................................................................................ 6
Data Currency ......................................................................................................................................... 6
Reliability ................................................................................................................................................. 7
Recoverability ......................................................................................................................................... 7
System Availability ................................................................................................................................ 7
Performance ............................................................................................................................................ 7
Capacity ..................................................................................................................................................... 7
Data Retention ........................................................................................................................................ 7
4 REQUIREMENTS TRACEABILITY MATRIX .............................................................................. 7
5 Glossary ............................................................................................................................................. 9
Functional Requirements Document
Page 3 of 11
January 14, 2014
UITS
1
1.1
PROJECT/SUB-PROJECT TITLE>
<
GENERAL
Project Description
1.1.1 Background
FAMIS Application hosted in Santa Clara needs up-to-date employee and requestor data
in its databases to automate the data entry, and facilitate processes that need updated
employee and requestor data (e.g Self Service). The updated employee and requestor data
is provided by Genesys system in the format of text files.
1.1.2 Purpose
To update Requestor and Employee data in FAMIS from Genesys data feed by
developing corresponding loader modules.
1.1.3 Assumptions and Constraints
Assumptions are future situations, beyond the control of the project, whose outcomes
influence the success of a project. Assumptions are:


Availability of resources
Availability of a hardware/software platform
Constraints are conditions outside the control of the project that limit the design
alternatives. Constraints are:


Government regulations (Occupational Safety and Health Administration)
University of Connecticut policies and procedures
1.1.4 Interfaces to External Systems

1.2
Points of Contact




1.3
Interface with Genesys system
Project Manager: Lara Bordick
Development project leader: Cuong Do
User contacts: Jessica Alson, Anthony Weston, Michael Jednak
Agency employee whose signature constitutes acceptance of the FRD
Document References
- Service Request 4176
2
FUNCTIONAL REQUIREMENTS
The functional requirements describe the core functionality of the application.
The solution will provide updated employee and requestor data in FAMIS Proper, an
implementing mechanism, and provide necessary reports.
Functional Requirements Document
Page 4 of 11
January 14, 2014
UITS
2.1
PROJECT/SUB-PROJECT TITLE>
<
Data Requirements
- Input Genesys text file with following fields
o Employee NetID
o Employee Name
o Email
o Phone
o U-Box
o Department Number
- Output requestor table with following fields
o Employee NetID
o Employee Name
o Email
o Phone
o U-Box
o Department Number
- Output employee table with following fields
o Employee NetID
o Employee Name
o Email
o Phone
o U-Box
2.2
Functional Process Requirements
Process requirements describe what the application must do. Process requirements relate
the entities and attributes from the data requirements to the users’ needs.
The solution/application will:
- read employee information from Genesys feed
- insert/update records in the requestor table in Santa Clara FAMIS database
- insert/update records in the employee table in Santa Clara FAMIS database
- provide necessary reports
Process requirements may be expressed using data flow diagrams, text, or any technique
that provides the following information about the processes performed by the application:






Context
Detailed view of the processes
Data (attributes) input to and output from processes
Logic used inside the processes to manipulate data
Accesses to stored data
Processes decomposed into finer levels of detail
Functional Requirements Document
Page 5 of 11
January 14, 2014
UITS
PROJECT/SUB-PROJECT TITLE>
<
0.B
FAMIS Team
Control
Loader
0.C
Employee Information
(Text Files)
Genesys
System
Employee Information
0.A
Facilities
Reports
FAMIS
Fig. 1: Level 0 DFD of Genesys integration solution
3
OPERATIONAL REQUIREMENTS
Operational requirements describe the non-business characteristics of an application.
3.1
Security
The security Section describes the need to control access to the data. This includes
controlling who may view and alter application data.
The consequences of erasure or contamination of employee data:
 Incorrect requestor/employee information provided to FO technicians
 Incorrect or missing requestor/employee information provided to general users
Types of security required:

3.2
Ability to update the employee/requestors on a large scale using the solution is
available only to FAMIS Team
Audit Trail
o Employee table: enter date, enter user
3.3
Data Currency
Data currency is a measure of how recent data are. This section answers the question,
“When the application responds to a request for data how current must those data be?”
Functional Requirements Document
Page 6 of 11
January 14, 2014
UITS
PROJECT/SUB-PROJECT TITLE>
<
Data currency depends on the loading frequency.
3.4
Reliability
Reliability is the probability that the system will be able to process work correctly and
completely without being aborted.

3.5
Accuracy needs as high as possible (need of error checking function)
Recoverability
Recoverability is the ability to restore function and data in the event of a failure.


3.6
If the computer that runs the loader application (hardware, and software) is destroyed,
the application is able to be restored within 48 hours conditional on the availability of
hardware/software.
Also depends on the availability of
o FAMIS Proper (databases, forms)
o Network
System Availability
System availability is the time when the application must be available for use. Required
system availability is used in determining when maintenance may be performed.
The usage of the loader application is made available to FAMIS team only. The system
availability is the function of the production database system, network availability, and
software environment & hardware (Java, Visual Basic, workstation, etc).
3.7
Performance

3.8
Able to finish updating requestor/employee data daily, given the newly changed or
created record data, conditional on the network and FAMIS system availability.
Capacity
The system stores data for approximately 2700 employee records in the main campus as
well as regional campus, and 5300 requestor records regardless their active status and
employment type.
3.9
Data Retention
The most up-to-date records are kept within the system.
4
REQUIREMENTS TRACEABILITY MATRIX
The requirements traceability matrix (RTM) provides a method for tracking the functional
requirements and their implementation through the development process. Each requirement
is included in the matrix along with its associated section number. As the project progresses,
the RIM is updated to reflect each requirement’s status. When the product is ready for
system testing, the matrix lists each requirement, what product component addresses it, and
what test verify that it is correctly implemented.
Functional Requirements Document
Page 7 of 11
January 14, 2014
UITS
PROJECT/SUB-PROJECT TITLE>
<
Requirement Description
The system is able to find out new requestor
records and insert them
The system is able to find out new employee
records and insert them
Ref.
Need
Status
Verification
Method
REQ-001
001
Proposed
Test Plan
REQ-002
002
Proposed
Test Plan
The system is able to find out changed requestor
records and update them
REQ-003
001,
003
Proposed
Test Plan
The system is able to find out changed employee
records and update them
The system is able to find out employee records of
ones who left and deactivate them
REQ-004
002,
004
Proposed
Test Plan
REQ-005
006
Proposed
Test Plan
Never delete employees as FAMIS Requestors or
FSM Employees
If custom email accounts are used for particular
FAMIS Requestors so that more then one person
can receive notifications, these should not be overwritten by Genysis data
REQ-006
007
Proposed
Test Plan
REQ-007
008
Proposed
Test Plan
Reports should be available to show adds, updates
and inactivation of FAMIS Requestors
REQ-008
009
Proposed
Test Plan
Reports should be available to show adds, updates
and inactivation of FSM Employees
REQ-009
010
Proposed
Test Plan
ID
001
002
003
004
Statement of Need
Automate a repeatable process to
load new UCONN employees as
FAMIS Requestors
Automate a repeatable process to
load new UCONN employees as FSM
Employees
Automate a repeatable process to
update changes UCONN employees in
FAMIS Requestors
-Name (First, Last, Middle)
-Department
-Phone
-Email
Automate a repeatable process to
update changes UCONN employees in
FSM Employees
Functional Requirements Document
Business
Area
Source of
Need
Facilities
Operations
Facilities
Operations
High
Proposed
Facilities
Operations
Facilities
Operations
High
Proposed
Facilities
Operations
Facilities
Operations
High
Proposed
Facilities
Operations
Facilities
Operations
High
Proposed
Page 8 of 11
Business
Priority
Status
January 14, 2014
UITS
PROJECT/SUB-PROJECT TITLE>
<
-Name (First, Last, Middle)
-Department
-Phone
-Email
Automate a repeatable process to
inactivate UCONN employees as
005
FAMIS Requestors when they leave
the university
Automate a repeatable process to
inactivate UCONN employees as FSM
006
Employees when they leave the
university
007 Never delete employees as FAMIS
Requestors or FSM Employees
If custom email accounts are used for
particular FAMIS Requestors so that
008 more then one person can receive
notifications, these should not be
over-written by Genysis data
Reports should be available to show
009 adds, updates and inactivation of
FAMIS Requestors
Reports should be available to show
010 adds, updates and inactivation of FSM
Employees
5
Facilities
Operations
Facilities
Operations
High
Proposed
Facilities
Operations
Facilities
Operations
High
Proposed
Facilities
Operations
Facilities
Operations
High
Proposed
Facilities
Operations
Facilities
Operations
High
Proposed
Facilities
Operations
Facilities
Operations
Medium
Proposed
Facilities
Operations
Facilities
Operations
Medium
Proposed
GLOSSARY
FUNCTIONAL REQUIREMENTS DOCUMENT SIGN OFF
To:
From:
Preparer/Contact: _________________________ Phone: _______________________
Project Name: FAMIS Genesys data integration
The functional requirements for the project named above have been captured and documented
within these pages as complete per the business client’s team and the technical team. All
sections of the document have been completed to the best of the teams ability and knowledge to
Functional Requirements Document
Page 9 of 11
January 14, 2014
UITS
PROJECT/SUB-PROJECT TITLE>
<
solve the domain problem described in this document beginning on page 4.
Any further requirements uncovered for this project will be evaluated for importance to the
successful delivery of this project. If it is deemed the project will not be successful without the
inclusion of the new requirements, the requirements will be added to this document and
management will be notified at once. Other requirements will follow the change control process.
SIGNATURES
___________________
Project Manager
_____________________
Functional Lead
___________________
Date
_____________________
Date
Functional Requirements Document
Page 10 of 11
January 14, 2014
UITS
PROJECT/SUB-PROJECT TITLE>
<
REVISION HISTORY
Version
Date
Summary of Changes
Author
1.0
January 14, 2014
Initial revision.
Cuong Do
Functional Requirements Document
Page 11 of 11
Revision Marks
(Yes/No)
January 14, 2014