NYC Departments of Correction and Probation

Portal Implementation

Business Requirements

Tata Consultancy Services Limited

Draft

March 10, 2005

NYC Departments of Correction and Probation Portal Implementation

Revisions

Version / Primary Author(s) / Description of Version / Date Completed

Contents

Revisions

Contents

1Introduction

1.1Purpose

1.2Scope

1.3Supporting Material

1.4Definitions and Acronyms

1.5Business Interaction Model

1.6Overview

2Overall Description

2.1Product Perspective

2.2Product Features

2.3Actors, Rolls and Business Function

2.3.1Personas

2.4Operating Environment

2.5Design and Implementation Restraints

2.6Assumptions and Dependencies

3Functional Requirements

3.1 Functionality by Use Case

3.1.1Overview

3.1.2Use Case Reference

3.1.3Business Functionality

3.1.4Process Workflow

4External Interface Requirements

4.1 User Interfaces

4.2Hardware Interfaces

4.3Software Interfaces

4.4Communication Interfaces

5Nonfunctional Requirements

5.1Archival

5.2Auditability

5.3Authentication

5.4Authorization

5.5Availability

5.6Compatibility

5.7Configurability

5.8Data Integrity

5.9Extensibility

5.10Installability

5.11Integratability

5.12Leveragability/Reuse

5.13Licensing/Legal

5.14Localization

5.15Maintainability

5.16Multiple Environment Support

5.17Operability

5.18Performance

5.19Personalization

5.20Portability

5.21Privacy

5.22Reliability

5.23Robustness

5.24Scalability

5.25Security

5.26Upgradeability

5.27Usability/Achievability

Appendix A

Page 1

RCMS Probationer Reporting Kiosk – Business Requirements

1Introduction

1.1Purpose

The purpose of this Business Requirements Specification document is to identify and define the business and functional requirements for the NYC Departments of Correction and Probation portal implementation. This document is intended for use by Business Analysts, User Interface Developers, the System Architect and Software Developers.

This document incorporates by reference the following deliverables:

User Interface Design

It should also be used as a reference when creating the Software Architecture and Design Specification

1.2Scope

It is easy to reason that these agencies could spend years utilizing and implementing all of the functionality that portals provide. Therefore, the scope of this project will be limited to configuring and delivering the IBM Websphere Portal. Once users have been categorized, identified, and entered into employee directories the following portal functions will be implemented:

  • Document Management: A document management system will be implemented through the portal to manage the Department of Probation’s Executive Policies and Procedures (EPAP).
  • Intelligent Notification Service: A Use-of-Force/Incident Management notification system will be developed for the Department of Correction uses IBM’s Intelligent Notification Service.
  • People Search: The portal will be configured to allow the departments to search for employees, inmates and probationers.

1.3Supporting Material

  • DOP Request for Proposal for Task Order B
  • TCS Proposal for Task Order B
  • The Portal Implementation Project Charter

1.4Definitions and Acronyms

Term / Definition
EPAP / Executive Policies and Procedures
INS / Intelligent Notification Service
PO / Probation Officer
CO / Correction Officer
DC / Deputy Commisioner
AC / Assistance Commisioner
DD / Deputy Director

1.5Business Interaction Model

1.6 Overview

The portal will provide a means to integrate various DOP and DOC applications. It will provide a way for the Agency staff to publish/read content, look up details of Agency staff and subscribe to receive notifications to Jail Incidents.

The three objectives of this portal will be:

Incident Notification: Allow Agency staff to subscribe to various Jail Incidents. Whenever any of these “incidents” occur, they are logged onto a PC system in the facility. This is then emailed or paged out to the subscribed staff.

Content Publishing and Search: Allow MAPS team to publish EPAPS. This will also allow the MAP team to create draft versions of the EPAP for circulation and approval from the various responsible authorities. When these EPAPS are posted on the portal, the Agency staff will be able to read this by one of two ways: a) Searching for the EPAP by keyword OR b) Browsing through the relevant categories to find the EPAP.

Directory Search:Allow staff to search for a DOC/DOP employee by either name or Department. This directory will be kept updated on a daily basis. The records for a particular employee will show his/her details plus their position in the org structure.

2Overall Description

2.1Product Perspective

2.2Product Features

2.3Actors, Rolls and Business Function

2.3.1Personas

2.4 Operating Environment

2.5 Design and Implementation Restraints

2.6 Assumptions and Dependencies

3Functional Requirements

3.1Functionality by Use Case

3.1.1Overview

3.1.2Use Case Reference

3.1.3Business Functionality

  1. Goal
  2. Validation Steps to Achieve Goal
  3. Sub Steps

3.1.4Process Workflow

Page 1

RCMS Probationer Reporting Kiosk – Business Requirements

4External Interface Requirements

4.1User Interfaces

The portal will provide an interface for: a) Updating employee data b) Publish EPAPs. c) Search for content on the portal. d) Subscribe/unsubscribe to receive notifications.

4.2Hardware Interfaces

  • Client Machine - Processor Hardware – P4 1GHz, memory 256 MB, 17” monitor
  • Server Machine - Processor Hardware – Dual P4 2.4GHz, 2.5 GB RAM, 36 GB logical disk space.

4.3Software Interfaces

4.4Communication Interfaces

The RCMS Kiosk is an internet application that uses several communication protocols for its functionality:

  • HTTP
  • HTTPS
  • TCP/IP
  • JDBC

5Nonfunctional Requirements

5.1Archival

5.2Auditability :

The system will keep a count of the content accessed on the portal. It will store the following information: a) Which profile accessed the document b) What is the total number of times a document was accessed.

5.3Authentication:

All the content on the portal will be accessible only after the user logs in.

5.4Authorization

5.5Availability:

The portal will be available 24x7.

5.6Compatibility:

The portal will be compatible with IE 5 and above.

5.7Configurability

5.8Data Integrity

5.9Extensibility:

The portal should be flexible enough to allow adding more applications/portlets if required in the future.

5.10Installability

5.11Integratability

5.12Leveragability/Reuse

5.13Licensing/Legal:

The System shall be open source that adheres to the GNU General Public Licensed (GPL) . For more information on public licensing software please read the following:

5.14Localization:

The portal shall support multiple languages and shall have the capability to configure a new language. No special effort shall be made to support non-US measures, currencies calendar formats etc.

5.15Maintainability

5.16Multiple Environment Support

5.17Operability

5.18Performance

5.19Personalization

5.20Portability

5.21Privacy

5.22Reliability

5.23Robustness

5.24Scalability

5.25Security

5.26Upgradeability

5.27Usability/Achievability

Appendix A

Page 1