UITSGenesys data integration

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, CT06269-2209

File Name: Document3

Overview

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.

TABLE OF CONTENTS

1General

1.1Project Description

1.1.1Background

1.1.2Purpose

1.1.3Assumptions and Constraints

1.1.4Interfaces to External Systems

1.2Points of Contact

1.3Document References

2FUNCTIONAL REQUIREMENTS

2.1Data Requirements

2.2Functional Process Requirements

3OPERATIONAL REQUIREMENTS

3.1Security

3.2Audit Trail

3.3Data Currency

3.4Reliability

3.5Recoverability

3.6System Availability

3.7Performance

3.8Capacity

3.9Data Retention

4REQUIREMENTS TRACEABILITY MATRIX

5Glossary

1General

1.1Project Description

1.1.1Background

FAMIS Application hosted in Santa Claraneeds 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.2Purpose

To update Requestor and Employee data in FAMIS from Genesys data feed by developing corresponding loader modules.

1.1.3Assumptions 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.4Interfaces to External Systems

  • Interface with Genesys system

1.2Points of Contact

  • 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

1.3Document References

-Service Request 4176

2FUNCTIONAL 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.

2.1Data Requirements

-Input Genesys text file with following fields

  • Employee NetID
  • Employee Name
  • Email
  • Phone
  • U-Box
  • Department Number

-Output requestor table with following fields

  • Employee NetID
  • Employee Name
  • Email
  • Phone
  • U-Box
  • Department Number

-Output employee table with following fields

  • Employee NetID
  • Employee Name
  • Email
  • Phone
  • U-Box

2.2Functional 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/updaterecords inthe 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

Fig. 1: Level 0 DFD ofGenesys integration solution

3OPERATIONAL REQUIREMENTS

Operational requirements describe the non-business characteristics of an application.

3.1Security

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:

  • Ability to update the employee/requestors on a large scale using the solution is available only to FAMIS Team

3.2Audit Trail

  • Employee table: enter date, enter user

3.3Data 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?”

Data currency depends on the loading frequency.

3.4Reliability

Reliability is the probability that the system will be able to process work correctly and completely without being aborted.

  • Accuracy needs as high as possible (need of error checking function)

3.5Recoverability

Recoverability is the ability to restore function and data in the event of a failure.

  • 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
  • FAMIS Proper (databases, forms)
  • Network

3.6System 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.7Performance

  • Able to finish updating requestor/employee data daily, given the newly changed or created record data, conditional on the network and FAMIS system availability.

3.8Capacity

The system stores data for approximately 2700 employee records in the main campus as well as regional campus, and 5300 requestorrecords regardless their active status and employment type.

3.9Data Retention

The most up-to-date records are kept within the system.

4REQUIREMENTS 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.

Requirement Description / Ref. / Need / Status / Verification Method
The system is able to find out new requestor records and insert them / REQ-001 / 001 / Proposed / Test Plan
The system is able to find out new employee recordsand insert them / 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 / REQ-004 / 002,
004 / Proposed / Test Plan
The system is able to find out employee records of ones who left and deactivate them / REQ-005 / 006 / Proposed / Test Plan
Never delete employees as FAMIS Requestors or FSM Employees / REQ-006 / 007 / Proposed / Test Plan
If custom email accounts are used for particular FAMIS Requestors so that more then one person can receive notifications, these should not be over-written by Genysis data / 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 / Statement of Need / Business Area / Source of Need / Business Priority / Status
001 / Automate a repeatable process to load new UCONN employees as FAMIS Requestors / Facilities Operations / Facilities Operations / High / Proposed
002 / Automate a repeatable process to load new UCONN employees as FSM Employees / Facilities Operations / Facilities Operations / High / Proposed
003 / Automate a repeatable process to update changes UCONN employees in FAMIS Requestors
-Name (First, Last, Middle)
-Department
-Phone
-Email / Facilities Operations / Facilities Operations / High / Proposed
004 / Automate a repeatable process to update changes UCONN employees in FSM Employees
-Name (First, Last, Middle)
-Department
-Phone
-Email / Facilities Operations / Facilities Operations / High / Proposed
005 / Automate a repeatable process to inactivate UCONN employees as FAMIS Requestors when they leave the university / Facilities Operations / Facilities Operations / High / Proposed
006 / Automate a repeatable process to inactivate UCONN employees as FSM Employees when they leave the university / Facilities Operations / Facilities Operations / High / Proposed
007 / Never delete employees as FAMIS Requestors or FSM Employees / Facilities Operations / Facilities Operations / High / Proposed
008 / If custom email accounts are used for particular FAMIS Requestors so that more then one person can receive notifications, these should not be over-written by Genysis data / Facilities Operations / Facilities Operations / High / Proposed
009 / Reports should be available to show adds, updates and inactivation of FAMIS Requestors / Facilities Operations / Facilities Operations / Medium / Proposed
010 / Reports should be available to show adds, updates and inactivation of FSM Employees / Facilities Operations / Facilities Operations / Medium / Proposed

5Glossary

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 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 ManagerFunctional Lead

______

Date Date

RevisioN History

Version / Date / Summary of Changes / Author / Revision Marks
(Yes/No)
1.0 / January 14, 2014 / Initial revision. / Cuong Do

Functional Requirements DocumentPage 1 of 11January 14, 2014