JAR_User_Requirements_2016.pdf

FDOT RCI User Requ i rements De l ive rab le 6 : F ina l Use r Requ i rements

FLORIDA DEPARTMENT OF

TRANSPORTATION

OFFICE OF INFORMATION SYSTEMS

GEOSPATIAL ROADWAY DATA

STRATEGIC FRAMEWORK

ROADWAY CHARACTERISTICS INVENTORY (RCI)

DELIVERABLE #6: FINAL USER REQUIREMENTS DOCUMENT

JANUARY 29, 2016

www.ISF.com

Corporate Headquarters

5210 Belfort Rd., Suite 320

Jacksonville, FL 32256

(904) 724-2277 office

(904) 723-3561 fax

Tallahassee Office

3800 Esplanade Way., Suite 220

Tallahassee, FL 32311

(850) 671-1000 office

(850) 656-1300 fax

Austin Office

2243 Buena Vista Lane

Round Rock, TX 78665

(850) 671-1023 office

(850) 656-1300 fax

ISF Page i

TABLE OF CONTENTS

Revision History ....................................................................................................................... ii

Acronyms .................................................................................................................................. ii

Project Overview

FDOT’s Roadway Characteristics Inventory

Roadway and Technological Modernization

FDOT RCI Goals

User Requirements Overview

Analysis Methodology

Existing Documentation and RCI Reviews

Vision Interviews

Joint Application Requirement Workshops

Technical Documentation Reviews and Technical Interviews

User Requirements

Business Requirements

Functional Requirements

Non-Functional Requirements

FDOT RCI Interfaces

System-to-System Interfaces

Non System-to-System Interfaces

List of Appendices

Appendix A: JAR Session Handouts

Appendix B: JAR Session Meeting Summaries

Appendix C: JAR Session Evaluations

Appendix D: JAR Session STARfish Diagrams

Appendix E: Executive Vision Interview Summaries

Appendix F: Technical Meeting Summaries

Appendix G: Interface Questionnaires

Deliverable 6 Approvals

ISF Page i i

REVISION HISTORY

Final Version

Date Author(s) Revision Notes

1.0 12/10/2015 ISF Draft for first submission to FDOT

2.0 1/18/2016 ISF Formal submission to FDOT

3.0 1/29/2016 ISF Final submission to FDOT

ACRONYMS

Acronym Term

ArcGIS, GIS Arc Geographic Information System. “Arc” is the smallest unit of a vector datum, the units used to describe a map space.

AST Agency for State Technology

BMS Bridge Management System

BSSO Business Systems Support Office

CAR Crash Analysis Reporting

CLS Crash Locating System

CBT Computer Based Training

COTS Commercial Off-The-Shelf

EEDMS Enterprise Electronic Document Management System

ESRI Environmental Systems Research Institute

FAC Functional Application Coordinator

FAMS Federal Authorization Management System

FDOT Florida Department of Transportation

FHWA Federal Highway Administration

FM Financial Management System

FPS Financial Project Search

GIRD General Interest Roadway Data

GIS Geospatial Information System

HPMS Highway Performance Management System

ISF Information Systems of Florida, Inc.

JAR Joint Application Requirement

LRS Linear Referencing System

MAP 21 “Moving Ahead for Progress in the 21st Century”

MRP Maintenance Rating Program

ISF Page i i i

Acronym Term

OIS FDOT Office of Information Systems

PCM Project Cost Management

PCS Pavement Condition Survey

PITS Permit Information Tracking System

PM Project Manager

PMM Pavement Marking Management System

PSEE Project Suite Enterprise Edition

PSM Project Scheduling and Management

QA Quality Assurance

QC Quality Control

RCI Roadway Characteristics Inventory

RFQ Request for Quote

RITA Roadway Inventory Tracking Application

RWM Right of Way Management System

SHR Skid Hazard Reporting

SHS State Highway System

SLD Straight-line Diagrams

SME Subject Matter Expert

SOW Statement of Work

STARfish Submission Tracking And Role

TCI Traffic Chracteristics Inventory

TranStat Transportation Statistics Office

VLG Video Log

WPA Work Program

ISF Page 1

PROJECT OVERVIEW

The Florida Department of Transportation (FDOT) coordinates the planning and development of a safe, viable, and balanced state transportation system serving all regions of the state. To measure, capture, and report information about travel ways, FDOT utilizes the Roadway Characteristics Inventory (RCI) system.

FDOT’S ROADWAY CHARACTERISTICS INVENTORY

A variety of stakeholders use the RCI system. Many FDOT divisions and program areas depend on its data. External users include other State agencies, the general public, local governments, engineers, mapping companies, law enforcement agencies, the legal profession, universities, realtors, developers, theme park operators, the media, and emergency medical service providers, and the construction industry. The primary purpose of RCI data is to plan, design, and analyze Florida’s highway system. Other uses include Federal Highway Administration (FHWA) reporting, disbursement of funds, creating maintenance budgets, and developing straight-line diagrams, as well as input to crash analyses statewide.

The accuracy and timeliness of RCI data is important to the safety of millions of Floridians, as well as the success of the state’s roadway development, construction, and repair.

There are three primary FDOT procedures associated with RCI. Each procedure is associated with a primary Central Office stakeholder that ‘owns’ it and a specific dataset that the stakeholder also ‘owns.’

Listed below are the procedures and primary stakeholders:

General Interest Roadway Data (GIRD) - Transportation Statistics Office

Transportation Data Collection, Storage, and Reporting - Maintenance Office

RCI Traffic Engineering and Operations Data - Traffic Engineering and Operations Office

The Department’s Central and District Offices coordinate on RCI data collection, verification, entry, quality assurance, quality control, storage, and management.

ROADWAY AND TECHNOLOGICAL MODERNIZATION

FDOT currently faces challenges associated with RCI’s data structure and the need for new and expanded functionality. Since the system originated, technology has become available that could establish a database model with more flexibility and scalability. An RCI solution must accommodate ever-modernizing roadways, intermodals, and changes to the Department’s business processes, regulatory systems, and technologies. FDOT has also identified the items below:

Business processes surrounding the current RCI and the way the data is being collected, stored and presented should be examined

New state statutes, federal regulations, and mandates have driven changes in business processes, other systems, or interfaces and require additional data to be captured

The use of RCI information has expanded beyond its original intent

The system must accommodate information relative to other travel modes such as aviation, rail, port, and freight

ISF Page 2

Limitations exist in the current data structure and software that have been carried over from older technologies, which impede or limit functionality

The system must be flexible in order to accommodate additional travel way information

(currently known as features and characteristics) of various formats to be added easily by the users without requiring changes to application code

The system must also be capable of handling multiple data types (such as images, videos, very large text, etc.)

The solution must be compatible with the Department’s existing linear referencing system (LRS)

RCI data needs to be more readily and easily available to various audiences

New or improved technologies are available that can provide solutions (laptops, tablets, etc.)

GIS capabilities

FDOT RCI GOALS

FDOT commissioned ISF to work with RCI’s primary stakeholders in defining the user and data requirements for a new solution. The ‘new RCI’ will contain the roadway and rail data in the existing system, as well as new roadway information and data related to intermodals: aviation, ports, freight, and additional rail. The project team conducted Joint Application Requirements (JAR) sessions, work sessions in which groups of RCI users discussed their processes and the related data, interviewed FDOT Subject

Matter Experts (SMEs) and executives, and researched industry standards, best practices, and available technologies. These activities produced analysis used as input to draft user and data requirements. The

ISF project team conducted several requirements sessions with FDOT and incorporated the resulting feedback to final requirements documentation.

FDOT outlines the following goals for this project:

Involve the appropriate stakeholders in the analysis of their current business processes; explore possible reengineering of those business processes, and ultimately gather the requirements for solutions to meet the business needs

Produce a User Requirements document and a Data Requirements document that accurately, completely, and unambiguously reflect those business and functional requirements

Use the user and data requirements produced by this project for the following:

To evaluate existing commercial off the shelf (COTS) products to possibly meet a portion or all of the RCI requirements, and/or as input to design specifications and development of a custom solution(s)

ISF Page 3

USER REQUIREMENTS OVERVIEW

Deliverable 6 provides user requirements defining a technical solution that encompasses the existing RCI system, as well as the addition of intermodal data and more robust geospatial mapping functionality. They describe the how the resulting system will function to support Department business while meeting FDOT

OIS technical standards. The list below identifies three sets of user requirements as defined by the project

RFQ.

Business Requirements - High-level goal or objective to be met by the solution.

Functional Requirements - Describe in detail the operations, behaviors, capabilities that are required in the solution to meet the business requirements.

Nonfunctional Requirements - Criteria that can be used to judge the operations of the system and not its behaviors or functions; do not directly relate to the functionality or behavior of the solution.

Deliverable 6 dedicates a section to each type of user requirement, which begins with a brief introduction to the requirement set and its methodology. Associated findings and recommendations use nontechnical terms and avoid industry jargon that could limit accessibility of the content to a specific business group or groups. The methodology section describes how the ISF team elicited and understood business and data needs.

ISF Page 4

ANALYSIS METHODOLOGY

The ISF team employed a number of techniques in the analysis of the proposed system and development of user requirements.

EXISTING DOCUMENTATION AND RCI REVIEWS

To begin the project, the ISF team reviewed existing documentation to include the following items:

FDOT General Interest Roadway Data (GIRD) Procedure, Topic No: 525-020-310T

FDOT Maintenance RCI Transportation Data Collection, Storage, and Reporting Procedure #850-

000-001

FDOT Traffic Engineering and Operations RCI Data Collection Procedure #750-000-001

RCI Features and Characteristics Handbook

RCI Planning Data Handbook

RCI User Manual

RCI Maintenance Handbook (Central Office)

RCI Traffic Operations Features

In addition to reviewing existing FDOT support materials, further discovery efforts supported development of the requirements. The ISF team reviewed the requirements developed in 2004 and the

RCI data dictionary. Discovery efforts also included research and review of USDOT practices and guidelines, recent trends in transportation data, and standard practices in intermodal data. The FDOT

RCI Functional Application Coordinator (FAC) demonstrated areas of the existing application for ISF staff to enhance the project team’s familiarity with the current user interface and workflow. Reviews of the interface continued periodically during the JAR sessions to enhance discussions.

V ISION INTERVIEWS

ISF conducted vision interviews with six key FDOT leadership resources, as they were available throughout the project timeline. Their input acted as a guide for prioritizing functionality and data in the model for the new technical solution. A common success factor that was identified throughout each of the vision interviews was the importance of making sure that all RCI stakeholders had an opportunity to provide input feel like their input was heard by decision makers. To ensure this objective was met, ISF held numerous JAR sessions, requirement review sessions and individual meetings which included stakeholders across all of the districts and headquarters.

JOINT APPLICATION REQUIREMENT WORKSHOPS

In order to develop the business and functional requirements, ISF facilitated 28 JAR sessions, which addressed each stakeholder group identified by FDOT. The objective of the JAR sessions was to address current and future state processes while identifying existing datasets and data ‘candidates’ for the new system. As the JAR sessions progressed, ISF conducted additional, follow-up review sessions with the

ISF Page 5 functional application coordinators and subject matter experts to ensure the documentation meets FDOT expectations and receive feedback for the Deliverable products.

JAR SESSION OBJECTIVES

The ISF project team engaged JAR participants in multiple activities designed to elicit business, functional, and non-functional requirements. The following list identifies JAR session objectives.

Validate as-is business processes and identify those most dependent on RCI

Validate the existing technical environment and OIS standards, including pending changes that may impact the new system

Discuss potential solutions for common business issues and identify how the to-be model could incorporate them

Identify data and functionality requests to form the to-be system requirements

JAR SESSION APPROACH

The ISF team achieved these objectives by engaging in a variety of JAR session activities. Participants completed customized context diagrams or ‘STARfish’ (Submission Tracking and Role) diagrams that ISF staff designed to identify key processes and work products generated by RCI stakeholders. The diagramming tool is an efficient methodology that allowed the ISF project team to understand the processes, interactions, and work products that are dependent on or associated with the existing system.

These varied widely based on FDOT division, role, and location. Appendix C contains copies of the diagrams collected during each JAR session. Participants also engaged in brainstorming activities to elicit new data and functional requirements. District JAR participants demonstrated District-specific technical solutions developed by various District division staff. These include a robust District 1 traffic signal inventory, and Districts 4 and 6 extensive geospatial system interfaces.

ISF focused the development of the user requirements to support needed user activities, provide user process and data flexibility, and to identify those requirements associated with the purchase of a COTS product or for an RFQ for the design and development of a new RCI. ISF staff addressed these objectives by engaging in an iterative process for each work session. The ISF project team developed written meeting summaries after each session and submitted them weekly. The team reviewed and analyzed each summary, verifying requirements development and validating the resulting documentation. It was also important to review the initial scope draft prioritization of the requirements throughout the JAR sessions timeline by conducting follow-up sessions with FDOT stakeholders and reviewing FDOT documentation internally.

ISF Page 6

JAR SESSION SCHEDULE

The tables below identify dates, times, topics, and participants for each Central and District Office JAR session. Changes to the original timeline are noted.

Centra l Off ice JAR Sessions

The following table identifies dates, times, topics, and participants for each FDOT Central Office JAR session.

Central Office JAR Sessions

Date Time Topic FDOT Invitees

9/14/15

8:30 AM -

5:00 PM

RCI Data Collectors - Current State

Office of Maintenance

Office of Planning

Traffic & Engineering Operations

Work Program and Budget

Systems Planning

Safety Office

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Right Of Way Office

Transit Office

OIS Enterprise Geospatial System

9/17/15 8:30 AM -

5:00 PM

RCI Data Consumers - Current State

Traffic Engineering and Operations - Operations Division

Safety Office

9/21/15 8:30 AM -

5:00 PM

RCI Data Consumers - Current State

Finance and Administration - Work Program and Budget

9/22/15 8:30 AM -

5:00 PM

RCI Data Consumers - Current State

Intermodal Systems Development

Environmental Management

Performance Management

Planning Office

Public Transportation Offices

9/24/15 8:30 AM -

5:00 PM

RCI Data Collectors - Future State

Office of Maintenance

Office of Planning

Traffic & Engineering Operations

Work Program and Budget

Systems Planning

Safety Office

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Right Of Way Office

ISF Page 7

Central Office JAR Sessions

Date Time Topic FDOT Invitees

Transit Office

OIS Enterprise Geospatial System

9/28/15 8:30 AM -

5:00 PM

RCI Data Consumers - Future State

Traffic Engineering and Operations - Operations Division

Safety Office

9/30/15 8:30 AM -

5:00 PM

RCI Data Consumers - Future State

Finance and Administration - Work Program and Budget

9/29/15 8:30 AM -

5:00 PM

RCI Data Consumers - Future State

Finance and Administration; Cancelled-to be rescheduled by program

10/5/15 8:30 AM -

11:30 AM

RCI & RHCI

Data Collectors & Consumers

Current & Future State

Rail and Motor Carrier Operations

10/5/15 12:30 PM

- 5:00 PM

Data Collectors & Consumers

Current & Future State

Freight Logistics and Passenger Operations

10/7/15 8:30 AM -

11:30 AM

Data Collectors & Consumers

Current & Future State

Aviation and Spaceports

10/7/15 12:30 PM

- 5:00 PM

Data Collectors & Consumers

Current & Future State

Seaports and Waterways; rescheduled for 10/16/15 at program request

10/16/15 9:00 AM -

11:00 AM

Data Collectors & Consumers

Current & Future State

Seaports and Waterways

10/16/15 1:00 PM -

3:00 PM

Data Collectors & Consumers

Current & Future State

FDOT OIS Enterprise Geospatial System;

scheduled on 10/7

ISF Page 8

Dist r ic t Off ice JAR Sessions

The following table identifies dates, times, topics, and participants for each FDOT District Office JAR session.

District Office JAR Sessions

Date Time District / Topics FDOT Invitees

10/12/15 &

10/13/15

8:30 AM -

5:00 PM

District 2 – Lake City

RCI Data Collectors and Consumers

Current and Future States

RCI Data Collectors and Consumers

Offices of Maintenance

Office of Planning

Systems Planning

Traffic & Engineering Operations

Systems Planning

Work Program and Budget

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Transit

OIS Enterprise Geospatial System

10/14/15 &

10/15/15

8:30 AM -

5:00 PM

District 3 – Chipley

Current and Future States

RCI Data Collectors and Consumers

Offices of Maintenance

Office of Planning

Systems Planning

Traffic & Engineering Operations

Systems Planning

Work Program and Budget

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Transit

OIS Enterprise Geospatial System

10/19/15 &

10/20/15

8:30 AM -

5:00 PM

District 7 – Tampa

Current and Future States

RCI Data Collectors and Consumers

Offices of Maintenance

Office of Planning

Systems Planning

Traffic & Engineering Operations

Systems Planning

Work Program and Budget

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Transit

OIS Enterprise Geospatial System

ISF Page 9

District Office JAR Sessions

Date Time District / Topics FDOT Invitees

10/21/15 &

10/22/15

8:30 AM -

5:00 PM

District 1 – Bartow

Current and Future States

RCI Data Collectors and Consumers

Offices of Maintenance

Office of Planning

Systems Planning

Traffic & Engineering Operations

Systems Planning

Work Program and Budget

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Transit

OIS Enterprise Geospatial System

10/26/15 &

10/27/15

8:30 AM -

5:00 PM

District 4 – Ft.

Lauderdale

Current and Future States

RCI Data Collectors and Consumers

Offices of Maintenance

Office of Planning

Systems Planning

Traffic & Engineering Operations

Systems Planning

Work Program and Budget

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Transit

OIS Enterprise Geospatial System

10/28/15 &

10/29/15

8:30 AM -

5:00 PM

District 6 – Miami

Current and Future States

RCI Data Collectors and Consumers

Offices of Maintenance

Office of Planning

Systems Planning

Traffic & Engineering Operations

Systems Planning

Work Program and Budget

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Transit

OIS Enterprise Geospatial System

11/2/15 &

11/3/15

Canceled at District request

8:30 AM -

5:00 PM

Turnpike - Ocoee

Current and Future States

Turnpike Enterprise

RCI Data Collectors and Consumers

Offices of Maintenance

Office of Planning

Systems Planning

ISF Page 10

District Office JAR Sessions

Date Time District / Topics FDOT Invitees

Traffic & Engineering Operations

Systems Planning

Work Program and Budget

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Transit

OIS Enterprise Geospatial System

11/4/15 &

11/5/15

Reschedule d for 11/3/15 &

11/4/15 subsequent to Turnpike reschedule

8:30 AM -

5:00 PM

District 5 – Deland

Current and Future States

RCI Data Collectors and Consumers

Offices of Maintenance

Office of Planning

Systems Planning

Traffic & Engineering Operations

Systems Planning

Work Program and Budget

Freight Logistics and Passenger Operations

Rail and Motor Carrier Operations

Intermodal Systems Development

Transit

OIS Enterprise Geospatial System

TECHNICAL DOCUMENTATION REVIEWS AND TECHNICAL INTERVIEWS

To support the development of the non-functional requirements, the ISF team reviewed current FDOT technical documentation to include the following:

Data and Database Standards:

http://www.dot.state.fl.us/OIS/docs/standards/Data_Database_Standards.docx

FDOT Development Environment:

http://www.dot.state.fl.us/OIS/docs/standards/FDOTDevelopmentEnvironment09012015.docx

Web Application Standards:

http://www.dot.state.fl.us/standards/WebStandards.pdf

In addition to reviewing FDOT OIS technical documentation, the ISF team met with various technical groups within the Department to further document the non-functional requirements for the new system.

Technical meeting summaries associated with each technical session are included as part of Appendix E:

Technical Meeting Summaries.

http://www.dot.state.fl.us/OIS/docs/standards/Data_Database_Standards.docx http://www.dot.state.fl.us/OIS/docs/standards/FDOTDevelopmentEnvironment09012015.docx http://www.dot.state.fl.us/standards/WebStandards.pdf

ISF Page 11

USER REQUIREMENTS

This section presents an overview of the user requirements identified for the to-be roadway and intermodal transportation characteristics solution. The Analysis Methodology section reviews the activities used to elicit the requirements. As previously mentioned, according to the RCI RFQ conditions, the ISF project team divided the user requirements into the following groups:

Business Requirements – A high-level goal or objective to be met by the solution.

Functional Requirements – Describe in detail the operations, behaviors, capabilities that are required in the solution to meet the business requirements.

Non-functional Requirements – Do not directly relate to the functionality or behavior of the solution.

The RFQ identifies each of the following areas as those that the user requirements should address. These areas are discussed further in the business requirements section:

Technical or Environmental Restrictions

Operating System

Database Restrictions

Software Languages

Regulatory laws, policies or procedures that must be met or dictate aspects of the solution

Software System attributes/design constraints

Reliability

Availability

Security

Maintainability

Portability

Standards

The User Requirements also identifies the following subjects as those that the user requirements could address:

Interfaces

Security

Confidentiality

Performance

Conversion

Constraints and Limitations

As the discovery process progressed as outlined in the Analysis Methodology, the ISF team developed a collection of business, functional (behavior, inputs, and outputs) and non-functional (overall qualities or attributes) requirements to define the to-be system. The remainder of the deliverable groups the requirements according to the RFQ conditions and dedicates a section to each group.

ISF Page 12

BUSINESS REQUIREMENTS

Business requirements relate to business objectives, vision, and goals. They identify a specific need that resources must address in order to achieve objectives. They also provide the scope of the business need or problem that a project needs to address. The business requirements table contains the following information for each requirement:

Requirement ID - Unique ID assigned to each requirement in the format ‘##-###;’ the first element of the ID, ‘BR’ represents a business requirement; the second represents a three-digit sequential number (e.g., ‘001,’ ‘002,’ etc.).

Business Category - Description of the overall business group or section.

Business Requirement - Description of the requirement.

Supporting Requirements – Examples of functional and/or non-functional requirements which meet the needs of the expressed business requirement. Note that this is not an exhaustive list, but a sampling of some of the functional requirements that address the high-level business requirement.

ID Category Business Requirement Supporting

Requirements

BR-001 Application-wide The new system will include the functionality of the current system with the additional flexibility to measure, capture, and report new information.

Throughout

BR-002 Application-wide The system will perform checks and data validations to help prevent errors from being introduced into the system.

The system will also have the flexibility to allow some data fields to be "required" and others to be "optional," based upon the Department's needs. The new system will not have the data constraints of the existing system (for example, users will no longer be limited to 8 characters when entering certain data elements).

FR-003 through

FR-005; FR-

008 through

FR-010

BR-003 Junctions, Premises, and

Travelways

The new system will measure, capture, and report information about travelways, junctions, and premises, as defined in the "Entity Descriptions" table. Data stored in the system will describe the travelways, junctions, and premises, including their physical, administrative, maintenance, and operational properties. Examples include roadway name(s), width, number of lanes in each direction, surface description, median width/composition, lighting, traffic signals, etc. Users will be able to link data in the system to multiple travelways, junctions, and premises without duplication. The system must be capable of accommodating information relative to other travel

FR-106, FR-116

through FR-117;

FR-142 through

FR-148; FR-188

through FR-196

ISF Page 13

ID Category Business Requirement Supporting

Requirements modes (including but not limited to Aviation, Rail, Port, and Freight). The system must be able to accommodate additional travelway information of various formats to be added easily by the users without requiring changes to application code.

BR-004 Inventory Item The information collected in the existing system is currently known as features and characteristics. These will be replaced with inventory items (physical items such as sign panels, light fixtures, crosswalks, etc.) and attributes

(number, size, height, color, etc.).

FR-082 through

FR-105

BR-005 Interfaces The system should also support existing and desired interfaces to other systems in the Department. These interfaces are thoroughly described in the "Interfaces" table.

FR-078 through

FR-081

BR-006 File Attribute The system must be capable of handling multiple data types (such as images, videos, very large text, etc.) and allow for the import and export of multiple file types.

FR-044 through

FR-050

BR-007 Security The system will use the Department's authentication method for system sign-on. The system will assign users, roles, and permissions to govern what information users can see and what tasks they can perform. The system will also allow authorized users to make changes, additions, and deletions to users, roles, and permissions. In addition, the system will have a public-facing view available over the

Department's website. (See the "Entity Descriptions" table for a definition of users, roles, and permissions.)

FR-011; FR-022;

FR-169 through

FR-183

BR-008 Workflow

Notifications

The system will accommodate workflows and notifications to allow users to assign tasks, submit items for review, prioritize tasks, determine data that needs to be updated, etc. Authorized users should be able to customize workflows and notifications as needed.

FR-014; FR-197

through FR-206

BR-009 Application-wide The system will maintain a history of changes, including the user and the date made. The system will have the ability to roll back changes. The system will also have the ability to archive data according to Department requirements. Data will not be deleted from the system except by authorized users.

FR-006 through

FR-007; FR-017

through FR-021;

FR-023; FR-027

BR-010 Application-wide The system will allow data to have a “working” status to allow users to “save” works in progress and share works in progress with others. Working data will not be viewable except to authorized users until it is formally submitted

FR-012 through

FR-016

ISF Page 14

ID Category Business Requirement Supporting

Requirements and approved. Not all changes will have to be approved;

some users will have the ability to upload data immediately.

BR-011 Application-wide The system will provide help to the user in a variety of formats. This may include but is not limited to context sensitive help, access to training videos, access to user manuals and other documentation, etc.

FR-026; FR-028

BR-012 Geospatial and

Linear

Referencing

System

The system must be compatible with the Department’s linear referencing system (LRS) and GIS. For any location data, the system should be able to calculate location information in both GIS and LRS formats. The GIS component of the system will allow users to view and manipulate system data in a GIS format. Any changes finalized in the GIS component will be reflected throughout the system (including the LRS location information) and vice versa.

FR-051 through

FR-077; FR-108

through FR-109

BR-013 Reports The system will provide the Department with standardized reports for the Legislature, Federal government, etc. The system will also allow users to create custom reports.

FR-118 through

FR-141

BR-014 Search The system will provide robust searching capabilities, allowing users to filter search criteria in both tabular and geospatial formats. The search functionality will also allow the user to save and share search criteria, and export and save search results.

FR-149 through

FR-168

BR-015 Operating System The system will operate on the latest version of Microsoft

Windows Server or a to-be-determined cloud server.

NF-001; NF-

BR-016 Database

Restrictions

The system will store data on the latest version of

Microsoft SQL or a to-be-determined cloud provider. The system must be compatible with the existing GIS framework.

NF-003; NF-

004; NF-005;

NF-021

BR-017 Software

Languages

The system will provide applications programming interfaces compatible with FDOT standards.

NF-006

BR-018 Reliability System must be tested to confirm compliance against all functional requirements and have no outstanding defects.

The system will ensure data integrity including no duplication of data, valid date and time fields, and restrictions upon who can submit and publish data. The system will check entered data against existing business rules.

NF-011; NF-012;

NF-013; NF-

014; NF-026;

FR-004; FR-

005; FR-006;

FR-007; FR-

009; FR-010;

FR-014; FR-016;

FR-018; FR-

ISF Page 15

ID Category Business Requirement Supporting

Requirements

020; FR-038;

FR-041; FR-

085; FR-088

BR-019 Availability System will be protected from loss of information system capabilities should natural disasters, human actions, and/or equipment failures occur during normal use.

NF-013; NF-

014; NF-015;

NF-016

BR-020 Maintainability System should have capacity to support extensive growth in data and user base.

NF-013; NF-

014; NF-015;

NF-016

BR-021 Portability System will be able to easily be transferred from its current environment to another, if necessary.

NF-023; NF-

BR-022 Standards The system should be built, maintained, and operated according to FDOT security and development standards.

NF-017; NF-

027; NF-028

BR-023 Confidentiality System should support Department processes and procedures for ensuring information cannot be accessed and compromised.

FR-011; FR-022;

FR-169 through

FR-183

BR-024 Performance System will be highly responsive when loading pages, returning values, and running reports.

NF-018; NF-

019; NF-020

BR-025 Conversion System will allow accurate conversion of data from the legacy system. The system will be able to convert Linear

Referencing System coordinates to geospatial coordinates and convert coordinates from WGS-1984, Albers, and Web

Mercator.

FR-005; FR-

052; FR-076;

NF-023

BR-026 Constraints /

Limitations

System data must be compatible with the existing FDOT

GIS framework with the ability to allow users to zoom in and out of the basemap between 5m and 400km. Batch jobs will be performed after hours when feasible.

NF-005; NF-

021; FR-070;

FR-071

ISF Page 16

FUNCTIONAL REQUIREMENTS

The functional requirements for the to-be model are contained in the following table. As previously, stated, functional requirements are those requirements that describe the behavior, inputs, and outputs of a system. The bulleted list below identifies the column headings for the functional requirements table.

Requirement ID - Unique ID assigned to each requirement in the format ‘#####;’ the first element of the ID, ‘FR’ represents a functional requirement; the second represents a three-digit sequential number (e.g., ‘001,’ ‘002,’ etc.).

Functional Category - Description of the overall group or class of system functionality.

Functional Requirement - Description of the requirement.

Priority - Precedence of the requirement as expressed by project stakeholders at ‘Must Have,’ ‘Should Have,’ and ‘Wish List’.

Grouping - Recommended ordering for requirement delivery.

Requirement

ID

Functional

Category Functional Requirement Priority Grouping

FR-001 Application-Wide The system will provide permissions for each entity that allows users to create, update, and delete entities. As an example, the system will provide permissions that allow creating, updating, and deleting an inventory item type.

Must Have 2

FR-002 Application-Wide The system will allow authorized users to create, update, and delete entities.

Must Have 2

FR-003 Application-Wide When creating and updating an entity, the system will require users to provide values for all required data elements and allow entry of optional data elements. Required data is only required when submitting final data and is not required for working data changes.

Must Have 2

FR-004 Application-Wide When creating and updating an entity, the system will prevent creating duplicates.

Must Have 2

FR-005 Application-Wide Required date fields will be valid date fields to include month, day, and year. Date fields shall be in the following format: MM/DD/YYYY. Optional date fields may be NULL.

Must Have 2

ISF Page 17

Requirement

ID

Functional

Category Functional Requirement Priority Grouping

FR-006 Application-Wide When creating an entity, the system will automatically populate the Create Date and Create User attributes. The system will prevent users from editing these attributes.

Must Have 3

FR-007 Application-Wide When updating an entity, the system will populate the Last Update Datetime and Last Update User attributes. The system will prevent users from editing these attributes.

Must Have 3

FR-008 Application-Wide The system will identify all required fields with a visual indicator for identification by the user. Typical identification methods consist of an '*'.

Must Have 3

FR-009 Application-Wide The system will prevent saving data which does not pass validation checks and will inform the user of the reason for the validation failure.

Must Have 3

FR-010 Application-Wide The system will ensure that "Date From" fields will occur earlier in time to "Date To" fields.

Must Have 3

FR-011 Application-Wide Unauthenticated users will have access to all system capabilities which are not identified as requiring authorization (i.e. "authorized users"). This will constitute the set of capabilities available to the general public.

Must Have 3

FR-012 Application-Wide When creating and updating entities, authorized users will be able to save the data in a working status without submitting it. This working data is displayed as current data for the user performing the edit, but is identified as working data. This data is available for further editing by that user but is not visible to other users.

Must Have 3

FR-013 Application-Wide Working data can be rolled back and deleted within the system. This is a permanent deletion and is not visible in a historical view.

Must Have 3

FR-014 Application-Wide When creating, updating, and deleting entities, authorized users will be able to submit the data changes for review by others. This Submitted data is identified as such for that user as well as for reviewing users. These data changes are not visible to other users. Entities are defined in the "Entity Definitions" table.

Must Have 3

FR-015 Application-Wide When creating, updating, and deleting entities, authorized users will be able to publish the data changes immediately without going through an approval process. This data changes are "live" and immediately visible to all authorized users. Only users with this authorization will be able to publish data changes directly. Published data has a status of approved.

Must Have 3

ISF Page 18

Requirement

ID

Functional

Category Functional Requirement Priority Grouping

FR-016 Application-Wide Authorized users will be able to review and approve data submitted by others. The Submitted data will be available in a view that provides both the old values and the new values for all items that were changed to facilitate the review. Approved data is "live" and immediately visible to all authorized users. When submitted data is approved, the user who submitted the data is notified.

Must Have 3

FR-017 Application-Wide When updating an entity, the system will create a new version of the entity and move the previous version to a historical view. History is tracked for all entities except Code Tables. Code tables and code table entries can be inactivated but not be deleted.

Must Have 4

FR-018 Application-Wide When data is deleted from the system, the system will populate the Last Update Datetime and Last Update User attributes and will maintain the data in the system for audit and historical access purposes. The data will no longer be available for use by end users when accessing current data.

(Per FR-019 this data will still be available in a historical view.) This data is also available for purging by authorized users.

Must Have 4

FR-019 Application-Wide The system shall allow accessing a snapshot of data at a particular date in the past by specifying an "As Of" date. If this date is specified, data should be filtered to exclude all additions, updates, and deletions performed after the "As Of" date.

Must Have 4

FR-020 Application-Wide In order to provide consistency, the system will ensure that all associated inventory items and attributes are deleted when a roadway is deleted, unless those items are associated with other entities. For example, for an inventory item associated with two travelways, if one travelway is deleted, the inventory item will not be deleted because it is associated with another travelway.

Must Have 5

FR-021 Application-Wide When deleting an entity, the system will populate the Last Update Datetime and Last Update User attributes. The system will prevent users from editing these attributes. The system will also differentiate deleted data from other data when viewing in either textual or geospatial search results.

Must Have

FR-022 Application-Wide A hyperlink to access the login page for the system will be accessible from the OIT Enterprise Applications web page for users authenticated via the FDOT OIT security system.

Must Have 1

ISF Page 19

Requirement

ID

Functional

Category Functional Requirement Priority Grouping

FR-023 Application-Wide The system will provide a "Revert to History" capability which allows the authorized user to select a historical version of an entity and update the entity to match the historical version. When this is performed, the current version is moved to history and a new version is created with the same data as the historical version. The Last Update User and Last Update Datetime corresponds to the user who performed the "Revert to History".

Nice to Have 4

FR-024 Application-Wide The system will provide sending an email via a "mail to" hyperlink to the FDOT Planning, Maintenance, or Traffic Operations offices. Clicking the hyperlink opens a window in the user's default mail client to create a new email message.

Nice to Have 5

FR-025 Application-Wide The system will use a logical tab ordering of fields from left to right and top to bottom.

Should Have 3

FR-026 Application-Wide The system should provide feedback for user actions including error messages, alerts, progress notification for long-running processes, and progress notification for multi-step processes.

Must Have 3

FR-027 Application-Wide The system will allow for users with the appropriate permissions to complete a manual purging of data from the system. When data is purged, it is no longer in the system, but the user will have an option to save the purged data outside the system as well as restore the purged data. Note that the actual purge policy in terms of frequency is a policy rather than a functional requirement.

Should Have 4

FR-028 Application-Wide The system will provide context-sensitive help. The help should provide an explanation for the purpose of intended usage of the screen from which it was invoked. Additionally, the help should provide a description and intended usage for each UI element on the screen.

Must Have 5

FR-212 Application-Wide The system will display all time values in the Eastern Standard Time (EST) time zone.

Must Have 2

FR-214 Application-Wide They system will allow all data to be viewed by all users, except where specifically restricted.

Should Have 1

FR-230 Application-Wide The system will allow authorized users to suspend the system. When the system is suspended, only the users with suspend permission can make updates. The system is read-only for all other users.

Must Have 4

FR-231 Application-Wide Authorized users will be able to reject data submitted by others when performing a review. When submitted data is rejected, the status of the data is changed to working and the user who submitted the data is notified

ISF Page 20

Requirement

ID

Functional

Category Functional Requirement Priority Grouping

FR-241 Application-Wide The system will notify users when a system error occurs or an action they initiated could not be completed due to a system limitation or constraint

Must Have 3

FR-243 Application-Wide The system will automatically check the spelling of words entered by a user based on dictionary entries maintained by authorized users. In situations where spelling errors are detected, the system will provide a visual indication of the error

Nice to Have 5

FR-029 Attribute Type The system will allow authorized users to view all inventory item and attribute data listed for a travelway, junction, and premises.

Must Have 2

FR-030 Attribute Type The system will allow authorized users to delete attribute types only when there are no occurrences of that attribute associated with a travelway, premises, or junction. The deleted data will be available in a historical view and will be a candidate for purging.

Must Have 4

FR-031 Attribute Type The system will allow authorized users to provide instructional text and/or instructional videos that provides additional information about an attribute type, its measurements, and how to collect data for the attribute type.

Must Have 5

FR-032 Code Table The system will allow authorized users to create, read, and update a code table by providing a name, code table entries, and code descriptions as well as a begin effective date and an end effective date for code table entries.

Must Have 2

FR-033 Code Table The system will provide a selection of allowed values based on code attribute type. The selection must include the code value, code description, or both as specified in the Code Table Attribute Type. Also, only effective code values are available for selection.

Must Have 3

FR-034 Code Table The system will automatically select the default code value if one has been specified in the Code Table Attribute Type.

Must Have 3

FR-228 Code Table Attribute

A code table attribute is associated with one and only one code table attribute type.

Must Have 3

FR-035 Code Table Attribute Type

The system will allow authorized users to establish a code table attribute type by specifying a code table. Multiple code table attribute types can use a single code table.

Must Have 2

FR-036 Code Table Attribute Type

The system will provide an option to either display the code, the description, or both when entering code table attributes.

ISF Page 21

Requirement

ID

Functional

Category Functional Requirement Priority Grouping

FR-037 Code Table Attribute Type

The system will allow users to specify a default value for a code attribute type.

Must Have 2

FR-038 Date Attribute The system will ensure that dates entered are between the minimum and maximums specified for the Date Attribute Type.

Must Have 3

FR-039 Date Attribute The system will provide a notification to users associated with roles when a reminder duration has passed. This notification will include the inventory item and associated entities (travelways/premises/junctions).

As an example, an inspection date may have a 3-year requirement. In this situation, the corresponding users should be notified when the inspection took place 3 years ago.

Must Have 3

FR-040 Date Attribute The system will provide a calendar view of upcoming reminder dates for a given role. For a description of the notification, see FR-039.

Should Have 3

FR-225 Date Attribute A date attribute is associated with one and only one date attribute type. Must Have 3

FR-041 Date Attribute Type

The system will allow users to identify maximum and minimum dates with date attribute types associated with the inventory item type.

Must Have 2

FR-042 Date Attribute Type

The system will allow capturing time values when entering date values. Must Have 2

FR-043 Date Attribute Type

The system will allow users to specify a Reminder Duration for a date attribute type as well as a list of roles to be reminded when the duration has passed. Specifying a reminder duration is optional.

Must Have 2

FR-044 File Attribute The system will allow uploading a file and associate the file with an inventory item. As an example, a user could upload a photo of a guardrail when creating a guardrail inventory item at a specified location. Allowed file extensions are provided in the "Data Dictionary."

Must Have 3

FR-045 File Attribute The system will allow uploading a new version of a file that is already associated with an inventory item. The previous version is available in a historical view.

Must Have 3

FR-046 File Attribute The system will allow viewing and printing files when accessing attributes associated with an inventory item.

Must Have 3

FR-047 File Attribute The system will allow downloading files when accessing attributes associated with an inventory item.

Must Have 3

FR-048 File Attribute The system will allow authorized users to delete files associated with an inventory item. Deleted files are available in a historical view and are candidates for purging.

ISF Page 22

Requirement

ID

Functional

Category Functional Requirement Priority Grouping

FR-229 File Attribute A file attribute is associated with one and only one file attribute type. Must Have 3

FR-049 File Attribute Type

The system will allow users to define the file type based on the attribute type established. As an example, a file type of Photo will require jpg, png, or bmp file formats.

Must Have 2

FR-050 File Attribute Type

The system will allow authorized users (such as administrators) to define the maximum file size allowed for upload to the system.

Must Have 2

FR-051 Geospatial The system will select and display a basemap when accessing a geospatial view.

Must Have 1

FR-052 Geospatial The system will convert geospatial coordinates to Linear Referencing System coordinates by determining the milepoint closest to the geospatial coordinates.

Must Have 2

FR-053 Geospatial The system will allow the user to pan to user-selected locations within the map when accessing a geospatial view.

Must Have 2

FR-054 Geospatial The system will allow the user to add or remove additional layers when accessing a geospatial view. Layers are derived from inventory items. As an example, adding a "Stop Sign" layer would display the location of Stop Sign inventory items within the system.

Must Have 2

FR-055 Geospatial The system will allow the user to display multiple layers of map data simultaneously when accessing a geospatial view. In situations where items overlap, the system will allow differentiating the overlapping items by thickness or offset based on user selection.

Must Have 2

FR-056 Geospatial The system will allow an authorized user to restrict layers available for viewing based on associated user permissions when accessing a geospatial view.

Must Have 2

FR-057 Geospatial When a travelway, premises, or junction is selected in a geospatial view, the system will provide type and name of the selected item and allow initiating a search with that item's uniquely identifying criteria automatically populated.