Draft ETS functional req v2

Document Sample
Draft ETS functional req v2 Powered By Docstoc


The purpose of this tracking program is to consolidate and uniformly manage both planned and unplanned
events impacting roadway conditions, such as construction, special events, weather-related traveler
advisories, etc. It will enable CommuterLink partners and other authorized personnel to enter and record
event information, both making knowledge of the event available to all impacted agencies for scheduling
purposes, and to the public for current condition status.

The information tracked by ETS shall be available for viewing by privileged users and the public, via
both the ETS software interface and/or the online Commuterlink Website.


The ETS will be designed to accept input information on events from a variety of sources, including
ATMS partnering agencies, remote or local agencies, other states, dial-in data (TAT), legacy systems,
etc., in addition to a manual ETS user-interface. It will provide users the ability to access the program
remotely through use of the Internet, where information can be entered and viewed both graphically and

The ETS will also integrate with the existing ATMS subsystems to provide response plan and traveler
information data types. This will include the ability to display event queries on the ATMS network map,
the ability to generate response plans for events listed within the ETS, and the ability to post graphical
representations of scheduled events to the Commuterlink Website map. The ETS will also be expandable
in functionality, to allow external agencies to interface with the program and populate their own database
systems with event data in real time.

ETS User Interface

The ETS will consist of two distinct user interfaces, each with a specific purpose.

          1. Input. Users may record an event manually, or it may be populated within the ETS
             automatically from one of several external systems with which the program may interface.

          2. Output. Users may query event lists and view this information via the ETS software GUI
             (i.e., online or via the ATMS network, depending on the source connection) or they may view
             the compiled information regarding current and planned events as a layer on the
             Commuterlink Website map.

Event Tracking System                                                                     02/25/12

The ETS is envisioned as a method for uniformly tracking planned and unplanned events which impact
the traffic network within the region. It will allow input for event creation from a variety of sources,
including users, legacy systems and ATMS subsystems, and will provide output information in several
forms using both the Internet and the ATMS traveler information subsystems.

The following represent the functional requirement specifications for this subsystem:


1.       Extensibility

     1.1. The ETS shall support an expandable number of GUIs.

     1.2. The ETS shall support (1) to (many) event records.

     1.3. ETS GUI’s shall support expansion in the number of data fields represented within the GUI’s and
          contained within the database.

     1.4. The ETS shall support an expandable number of data interfaces with input/output client

     1.5. The ETS shall be platform independent in operation.

2.       Help File

     2.1. A context sensitive help file shall be accessible to both online and networked ETS users.

3.       Standards

     3.1. The ETS shall conform to all applicable, desired communication and database standards (i.e.,
           NTCIP, center-to-center communication, National ITS Architecture, etc.).

4.       Redundant Control

     4.1. To the extent feasible, mouse and keyboard control shall be interchangeable in operating the
           program functionality.

5.       Activity Log

     5.1. The ETS shall log all user-initiated and system-initiated operations which create a new record or
           modify an existing record. The items to be logged for each operation include (but are not
           limited to) the following:

       5.1.1.    Time and Date Stamp

       5.1.2.    User identification (if user-initiated)

Event Tracking System                              1 of 6                                    02/25/12
Functional Requirement Specifications
       5.1.3.    List of events which were changed/created

       5.1.4.    Changes made to each event

       5.1.5.    Comments (if user initiated)

6.       Past Events/Archive Data

     6.1. Past event records shall be removed from the program database of current and future events, and
            archived separately as follows:

       6.1.1. Past event records shall be accessible to users via the ETS program, with full ETS
         functionality available, for a period of (1) year past their closure.

       6.1.2.    Past event records older than (1) year shall be transferred to a tertiary storage medium.

7.       User Accessibility

     7.1. Authorized users may access the ETS via the Internet or ATMS Intranet network to create or
          modify event records.

     7.2. Public users (i.e., those without a username/password) shall be required to access the program via
          the Internet.

     7.3. User access and system input privileges shall be fully configurable, based on individual user-
          identities, the access method (internet vs. intranet), and user-role as defined by the system
          administrator (see Section 20 – User Administration/Authority).

     7.4. Users may access both ETS read and write functionality directly from the ATMS Network map
          (i.e., left & right mouse click functionality).


The following define the data-elements and event-record attributes which should be present for ETS event

8.       Event Record Characteristics

     8.1. Event records, whether manually or automatically generated within the ETS, shall provide
          adequate data elements to define the following information (example data entries shown in

       8.1.1.    Unique ETS Event ID / tracking number

       8.1.2.    Other ID (i.e., agency work order or tracking number, permit number, etc.)

       8.1.3.    Event location (i.e., street names, georeferenced coordinates, mileposts)

       8.1.4. Type of event (i.e., special, construction, maintenance, emergency closure, weather event,

Event Tracking System                            2 of 6                                        02/25/12
Functional Requirement Specifications
        8.1.5. Event duration (i.e., scheduled and actual start/end dates and times, estimates from the
          Incident/Construction Management system)

        8.1.6. Responsible or Managing Party (i.e., agency or group responsible, contact name, contact

        8.1.7.   Traffic Impact (i.e., number of lanes, lane numbers, ramps closed, etc.)

        8.1.8. Purpose/Justification (Reason) for Event (i.e., heavy snow, holiday parade, waterline
          repair, etc.)

        8.1.9.   Status (i.e., current/open, past/closed, delayed, road conditions, etc.)


The following define the required data-input functionality associated with either new or modified records.

9.       Creation of Records

      9.1. New event records may be created within the ETS in one of three ways:

        9.1.1.   Manual user-entry of data via the ETS user-interface.

        9.1.2. Automated entry of data via an Application Programming Interface (API) with an external
          system or application.

        9.1.3.   Placement of an event-type Icon at the appropriate location on a map.

10.      Scheduler

      10.1.         The ETS shall provide a graphical scheduling feature, enabling users to point-&-click
          within a calendar or equivalent timeline representation to define an event.

      10.2.       The scheduler shall support (1) to (many) events, scheduled up to (12) months in
          advance of the current time, on a rolling horizon basis.

      10.3.         The scheduler shall be capable of interfacing with other existing or future scheduling
          applications for other ATMS subsystems.

11.      External Systems

      11.1.         The ETS shall be capable of reading from and writing to external application databases
          using appropriate API’s. API developments shall be published to enable agencies to integrate
          such database systems with the ETS if desired. Examples of such systems which may be
          integrated in the future include (but are not limited to) the following:

        11.1.1. UDOT subsystems (Maintenance, Construction, & Permit Departments, Ports of
         Entry/Commercial Vehicle Operations, others)

        11.1.2. Commuterlink ATMS subsystems (Website,                     Traveler     Advisory   Telephone,
         Incident/Construction Management System, others)

Event Tracking System                             3 of 6                                       02/25/12
Functional Requirement Specifications
        11.1.3. Local Agency subsystems (Salt Lake City, Salt Lake County, UTA, University of Utah,

        11.1.4. Other State DOT’s (Wyoming, Nevada, Colorado, Idaho, Arizona)

        11.1.5. USDOT subsystems (FHWA, FTA, others)

      11.2.       Events within the ETS may be used to generate response plans within the ATMS
          Response Plan Management System.

12.       Input Verification

      12.1.          The ETS shall logically verify input data received via telephone or manual user-entry
          (i.e., verify input is within acceptable ranges, at acceptable locations, is non-repeating, etc.).

      12.2.         Operators shall be alerted when input errors are detected by the program, and the input
          shall be automatically cancelled.


The following define the required functionality for users viewing or extracting event record data.

13.       Data Display

      13.1.        The ETS shall refresh the data within active intranet program sessions at intervals
          configurable by the system administrator. Online users shall update their active sessions by using
          the ‘Refresh’ or ‘Reload’ button on their browser.

      13.2.       Users may view data and query results via the ETS program GUI’s. Groups of records
          may be displayed in any of the following formats:

        13.2.1. Map display (as a data layer on the ATMS network map and/or Commuterlink website
         map, as defined in the functional requirements documents for these two systems dated April

        13.2.2. Graphical Calendar (as a series of timelines or discrete events within a calendar or
         equivalent timescale representation)

        13.2.3. Textual/Tabular Listing (as a listing of sorted event records)

14.       Queries

      14.1.        Users may query the ETS event database based on one or more of the following data

        14.1.1. Time (date and time range)

        14.1.2. Location (milepost range, street name range)

        14.1.3. Event Type

Event Tracking System                           4 of 6                                      02/25/12
Functional Requirement Specifications
      14.2.         Users may request that notification of new or modified event records be sent to them
          automatically by the application, based on user-defined data thresholds (i.e., users may request
          notification of all event records with active dates between June and August 2000).

      14.3.        ETS queries may be scheduled by users to run automatically and email query files to the
          requesting user.

15.       Active Events

      15.1. The ETS shall automatically create and update, at configurable intervals, a query set of
            currently active events.

      15.2. The current event listing views shall have the same functionality as defined for other event
            query sets in (Section 13) of this document.

16.       Icons

      16.1. Data layer display of event records on the ATMS Network Map or the Commuterlink Website
            map shall utilize unique icons for different event types (as defined in the ATMS Network Map
            functional requirements dated April 2000).

17.       Find/Search Function

      17.1. A ‘Find’ or ‘Search’ functionality shall be provided within the ETS, allowing users to query for
            unique records based on specific alpha-numeric text strings.

        17.1.1. The Find/Search function shall be capable of searching for partial text-string information
         (i.e., exact matches are not required).

18.       Data Export

      18.1.          Users may print query or record data directly from the application.

      18.2.        Users may save ETS queries and record data, for (1) to (many) event records, in a
          delimited-text file format for import into other spreadsheet or database programs.


The following requirements pertain to global operational issues at the System Administrator level.

19.       Security

      19.1.      Access to privileged read/write functionality within the program shall require, at a
          minimum, entry of a username and password.

      19.2.        Users shall be required to enter their username/password information only once per user

Event Tracking System                             5 of 6                                    02/25/12
Functional Requirement Specifications
20.       User/Administration Authority

      20.1.        The ETS shall support (n) user roles, with (1) to (many) user identities associated with
          each role.

      20.2. All user identities shall assume the rights and privileges of the role they are associated with.

      20.3. User rights and privileges when operating the program shall be configurable by the system

Event Tracking System                             6 of 6                                        02/25/12
Functional Requirement Specifications

Shared By: