ttc metropass consolidation project - weeblybasantramachandran.weebly.com/uploads/1/8/2/0/... ·...

1 RFP - TTC METROPASS CONSOLIDATION PROJECT

TORONTO TRANSIT COMMISSION

Basant Ramachandran

[TTC METROPASS CONSOLIDATION PROJECT]

Materials and Procurement OfficeRFP ISSUE DATE : APRIL 01, 2014

Duncan Building, 2nd Floor, TTC's Hillcrest Complex 1138 Bathurst Street

Toronto, Ontario, M5R 3H2


Table of Contents

Table of Contents...........................................................................................................................21. Statement of Confidentiality...................................................................................................32. Abbreviations, Acronyms, and Definitions............................................................................33. Introduction..............................................................................................................................4

3.1 About Our Company........................................................................................................43.2 About this Request for Proposal......................................................................................53.3 Submitting Proposals.......................................................................................................53.4 Accepting Proposals.........................................................................................................63.5 Contracting Schedule.......................................................................................................7

4. Proposal Preparation Guidelines............................................................................................85. Project Overview....................................................................................................................106. Statement of Work.................................................................................................................10

6.1 Project Organization......................................................................................................116.2 Communication..............................................................................................................126.3 Dependencies and Constraints.......................................................................................126.4 Design, Development, and Implementation Methods....................................................136.5 Evaluation and Monitoring............................................................................................146.6 Change Management.....................................................................................................146.7 Product Acceptance.......................................................................................................156.8 Support and Maintenance..............................................................................................17

7. Vendor Requirements............................................................................................................178. Functional Use Case Requirements......................................................................................18

8.1 UC 1: Kiosk Recharge System......................................................................................188.2 UC 2: TTC Online Recharge System.............................................................................218.3 UC 3: TTC Passenger Registration System...................................................................248.4 UC 4: Validating Metropass at TTC Premises..............................................................278.5 Hardware upgrades........................................................................................................29

9. Deliverables............................................................................................................................3010. Cost and Schedule Estimates................................................................................................3111. Contracts and Licenses..........................................................................................................31

11.1 Purchase Agreement......................................................................................................3111.2 Licensing Agreements...................................................................................................3211.3 Intellectual Property Ownership....................................................................................3211.4 Vendor Warranties.........................................................................................................3211.5 Performance Bonds, Late-Delivery Penalties, and Early-Delivery Bonuses.................33

11.5.1 Performance Bonus....................................................................................................3311.5.2 Late Delivery penalties..............................................................................................3311.5.3 Financial Bonus.........................................................................................................33

11.6 Vendor-Supplied Training.............................................................................................3411.7 Non-Disclosure Agreements..........................................................................................34

12. Proposal Evaluation Criteria Matrix...................................................................................35References.....................................................................................................................................36


1. Statement of Confidentiality

This Request for Proposal (RFP) contains confidential and proprietary information that is the

property of Toronto Transit Commission, which is provided for the sole purpose of

permitting the recipient to respond to the RFP. The recipient agrees to maintain such

information in confidence and not to copy nor disclose this information to any person outside

the group directly responsible for responding to its contents. The contents of this document

may not be used for any purpose other than preparation of a response to this RFP. Should the

vendor not be chosen for the engagement described in this RFP, vendor must return all copies

of this RFP to Mr. Nichalowe Taylor at Materials and Procurement Office, Duncan

Building, 2nd Floor, TTC's Hillcrest Complex, 1138 Bathurst Street, Toronto, Ontario,

M5R3H2 immediately upon notification that the respective vendor was not selected.

2. Abbreviations, Acronyms, and Definitions

ACRONYM DEFINITION

TTC Toronto Transit Commission

RFP Request For Proposal

POC Proof of Concept

RFID Radio Frequency Identification

DB / DBMS Database / Database Management System

UI User Interface

MBA Master of Business Administration

PMP Project management Professional

MySQL Structured Query language


SDK Software Development Kit

ISTQB International Software Testing qualifications Board

CSTE Certified Software Tester

API Application Programming Interface

DLL Dynamic Link Library

WBS Work Breakdown Structure

CCB Change Control Board

OOD Object Oriented Design

SVN Subversion

SP Stored Procedure

SLA Service Level Agreement

SLO Service Level Objective

RTM Requirements Traceability Matrix

CMMI Capability Maturity Model Integration

EPC Gen 2 Electronic Product Code - Generation 2

3. Introduction

3.1 About Our Company

The Toronto Transit Commission (TTC) is a public transport agency that operates transit

buses, Streetcars, Subway trains and Rapid transit services in Toronto, Ontario, Canada. TTC

boasts to be the third largest transit system in North America with an average daily ridership

of more than 2.76 million passengers in 2012. It is estimated that the recent spur in the use of

counterfeit tokens and passes has cost TTC losses amounting anywhere northwards of $1

million per year. TTC currently issues close to 900000 of metro passes every month.


3.2 About this Request for Proposal

Toronto Transit Commission is issuing this RFP for systems and software development

services for TTC Metropass Consolidation project. Your company is invited to respond to

this RFP. Toronto Transit Commission will compare the competitive advantages that your

proposal offers with those from the other responding companies. Proposals will be evaluated

in terms of satisfaction of the technical requirements set forth in this RFP, quality, delivery

schedule, price, project management, and risk management. Toronto Transit Commission

intends to identify a short list of qualified respondents and, ultimately, to select a vendor for

this project.

This RFP is not an offer to contract. Issuance of this RFP and the receipt of responses by

Toronto Transit Commission do not commit Toronto Transit Commission to award a contract

to any bidder.

3.3 Submitting Proposals

Please acknowledge receipt of this RFP and reply indicating whether your company intends

to submit a proposal by contacting Mr. Nichalowe Taylor via e-mail at [email protected] no

later than April 4, 2014. If your company does intend to submit a proposal, please provide

the name, mailing address, e-mail address, telephone number, and fax number from the

representative from your company who will serve as the single point of contact for all

communications regarding this RFP. If your company chooses not to submit a proposal,

please return all copies of this RFP immediately to Mr. Nichalowe Taylor at Materials and

Procurement Office, Duncan Building, 2nd Floor, TTC's Hillcrest Complex, 1138 Bathurst

Street, Toronto, Ontario, M5R3H2.

mailto:[email protected]


The costs of preparing a proposal are the sole responsibility of your company. All proposals

and supporting documentation submitted with the proposal become the property of Toronto

Transit Commission.

Proposals must be prepared according to the description in section 3, Proposal Preparation

Guidelines.

Submit questions regarding this RFP in writing to Mr. Nichalowe Taylor, [email protected]

Materials and Procurement Office, Duncan Building, 2nd Floor, TTC's Hillcrest Complex,

1138 Bathurst Street, Toronto, Ontario, M5R3H2, +1-416-393-4000. Toronto Transit

Commission will provide copies of all questions and their answers to all bidders who

received this RFP.

Submit your proposal in hard copy form to Mr. Nichalowe Taylor at Materials and

Procurement Office, Duncan Building, 2nd Floor, TTC’s Hillcrest Complex, 1138 Bathurst

Street, Toronto, Ontario, M5R3H2, +1-416-393-4000. All proposals must be received in the

required format by April 28, 2014. Proposals received after this time will be returned to the

vendor without being considered.

3.4 Accepting Proposals

Toronto Transit Commission will evaluate submitted proposals according to the criteria

summarized in section 12, Proposal Evaluation Criteria. Toronto Transit Commission may

accept or reject any proposal, whether or not it satisfies the requirements stated in this RFP.

Toronto Transit Commission reserves the right to negotiate further with bidding vendors.

Your response to this RFP constitutes an offer by you to do business with Toronto Transit

Commission on the terms stated in your response. Should your company be selected, Toronto

mailto:[email protected]


Transit Commission may incorporate any portions of your response into negotiated

agreements.

In the event that Toronto Transit Commission decides not to accept your proposal, you will

be so notified. Toronto Transit Commission reserves the right not to communicate the basis

upon which its decision was made.

3.5 Contracting Schedule

Milestone Date Due Deliverables Responsibility

Issue RFP to vendors April 1, 2014 RFP Toronto Transit Commission

Intent to bid or withdraw April 4, 2014 E-mail notification VendorDeadline for Submission of Questions

April 14, 2014 TTC Website notification

Vendor

Responses to Questions Posted to Internet

April 15, 2014 TTC Website notification

Toronto Transit Commission

Written proposals submitted April 28, 2014 Proposals in hardcopy VendorsSite visits or surveys May 12, 2014 none Toronto Transit

CommissionVendor selected May 19, 2014 Written notification Toronto Transit

CommissionNegotiations completed May 23, 2014 Final statement of

workToronto Transit Commission

System POC Rollout Sept 15, 2014 POC VendorContract executed and purchase order issued

Jan 1, 2015 Contract, purchase order

Toronto Transit Commission, vendor

4. Proposal Preparation Guidelines

The proposal shall not exceed 36 single-sided pages or 18 double-sided pages. This page

limitation does not include the cover sheet, abstract, table of contents, personnel, facilities,


equipment and resources, other considerations, schedule, other support, cost information, and

literature cited. Each page of the proposal must be numbered sequentially. Vendors are

encouraged to limit the overall size of the proposal, inclusive of appendices, attachments, etc.

Type density and size must be 10 to 12 points. If constant spacing is used, 15 cpi (characters

per inch) or fewer shall be used, whereas proportional spacing should provide an average of

no more than 15 cpi. There must be no more than six lines of text within a vertical inch.

Margins must be no less than ½ inch around, exclusive of headers and footers.

All vendors must follow the guidelines laid out below while preparing the proposal. Any

proposal found non-compliant will not be entertained.

Include a cover letter that specifies the legal name and address of the vendor, the

name and contact information of the individual who is authorized to respond to

issues raised by Toronto Transit Commission, and the name and contact

information of the individual who is authorized to conduct negotiations and

execute a contract

Add an executive summary containing a brief description of the proposed project

development approach.

Briefly describe the corporate history and information, including financial details.

Qualifications, including previous TTCs for whom the vendor has done similar

work with contact information (for references), and cost, schedule, and quality

performance data (actual versus estimates) on previous projects.


CMMI maturity level of the Company, ISO 9000 registrations, other software

process qualifications, conformance to IEEE or other established standards.

High level plans and Processes to be used for requirements management,

configuration management, testing, and quality assurance.

A project plan that includes:

1. The major project milestones and deliverables from each.

2. The proposed team and the team members’ qualifications; evidence of

technical skills, technical staff, and available resources.

3. Proposed schedule and how it was derived, including contingency buffers

4. Assumptions the vendor made

5. Dependencies on external factors, third parties, or material suppliers.

6. An analysis of significant project risks.

7. The vendor’s proposed tradeoffs between functionality, quality, schedule, and

cost.

Estimated project costs and payment details, including software development,

hardware, system software, third-party components that must be licensed,

consumables, installation and checkout, maintenance and support, training,

documentation, travel expenses, and any other costs not specifically requested by

the TTC.

Payment milestones and the amount due at each

Any other terms and conditions that the Vendor wishes to impose on the contract

or project


How the vendor intends to satisfy the stated evaluation criteria

A vendor’s comment section, to include information the vendor feels is relevant

or useful for the project, but which is not required or requested elsewhere in the

RFP.

5. Project Overview

TTC Metropass Consolidation Project, is a strategic initiative towards cost cutting, managing

security, Curbing metropass counterfeiting, Increase revenues and maintaining a passenger

repository. The long term benefits of the project far outweighs the initial costs and helps TTC

connect with its passengers better giving it an edge.

6. Statement of Work

The scope of work for this project includes:

- Streamlining the existing passenger registration flow to capture passenger information for

all card types.

- Replacing the old ID cards and Issuing new ones to all passengers post registration.

- Developing new software for online recharge.

- Developing software for kiosk recharge

- Developing backend databases to store and retrieve passenger information.

- Acquiring, distribution and installation of RFID systems on all TTC asset entry points.

- Campaign to educate users on the new recharge systems

The Metropass consolidation system should have the following capabilities:

- Issue of RFID enabled secure pin TTC photo ID card to every passenger.


- Capturing and mapping all passenger information in DB for different types of card.

- Developing new software system to capture online recharge for registered passengers.

- Software up-gradation for existing kiosk machines to enable monthly card recharge.

- RFID hardware installation on all TTC assets.

- Expanding existing passenger database to accept all categories of card passengers.

- Creation of an online recharge portal.

- Expanding Kiosk functionality to accept credit cards.

- Integrating all kiosk machines with passenger DB for updates on card renewal, expiry

and validity.

- Introduction of Magnetic strip on the card.

- Disabling the kiosk vending ports.

- Capture government identification information as part of user registration.

6.1 Project Organization

TTC Contract Management Team

Role Team Member

Project Manager Mr. Gowrishankar Raju

Vendor’s Subcontract Manager Mr. Nichalowe Taylor

Subject Matter Experts (IT) Mr. Basant Ramachandran

Technical coordinator Mr. Peter Gordon

Verification Engineer Mrs. Diwei Dionne Wu

QA Engineer Ms. Cathy Morgan


6.2 Communication

Vendors shall direct all communications to the attention of the Subcontract Manager

cited on the TTC Contract Management Team of this solicitation. Communications

with other officials may compromise the competitiveness of this acquisition and result

in cancellation of the requirement.

Technical interactions between key members of the vendor and TTC staffs will take

place through any of the following modes of communication like face-to-face meetings,

teleconferences and commenting on documents through word processor revision

markup and inserted annotations (such as Microsoft Word comments).

During the design phase, the engineering staff from the vendor will operate from the

TTC’s Engineering division premises and collaborate with the TTC’s subject matter

experts and other system architects in face to face interactions. Any documentation

regarding the project needs to be digitally distributed to the project stakeholders in a

secured manner only. Any such travel costs must be accommodated in the monthly

billing invoice and claimed on a pro-rata basis. Note that the project manager will have

the final say on any disagreements on design or engineering matters and will be the sole

project decision maker.

6.3 Dependencies and Constraints

o Proposed passenger registration system should be built as an extension to the

existing Passenger Registration system on the technology used.

o Proposed passenger system should be able to use the existing DBMS.


o All Proposed systems should be compatible to the existing platforms and systems.

o The new consolidate cards should be able to use the current magnetic swipe

infrastructure.

o The hands free card readers should operate at 0.5m ranges while maintaining

sufficient levels of security.

o The reader should support reading battery less card that follow EPC Gen 2

standards.

o Vendor should abide strict green procurement methods.

6.4 Design, Development, and Implementation Methods

Following are the technical methods, tools and environments currently in use in all

internal TTC projects. The vendor is expected to use the existing tools and tackles.

6.4.1 Technical Methods

o Project to follow agile methodology.

o Design diagrams, Architecture diagrams and any other project documentation

should follow the IEEE standards.

6.4.2 Development Tools & Environment

o Current systems are based on OOD methodologies and hence extendable.

o Design methodology - Object Oriented Design

o Software development Environment - Java JDK / Java NetBeans

o Version Control - Tortoise SVN

o Project / Defect Tracking – Quality Centre 10.0


o Backup & Recovery Procedure – Nightly backup done to the central servers

All documentation needs to be reviewed and approved by the Technical coordinator

from TTC.

6.5 Evaluation and Monitoring

TTC team will work with the vendor to track and measure progress throughout the

project, addressing the following points:

Weekly status reporting in Microsoft word format having the overall status from all

streams of the project to be submitted to the project manager.

Project manager will host a bi-weekly meeting on every second Friday with the

stakeholders from vendor side to discuss project proceedings, risks, statuses,

tracking of actual results against the plans and estimates.

Quality checkpoints and joint reviews of work products that will involve

representatives from both the TTC and the vendor.

Testing progress and defect statistics will be tracked using Quality Center made

available to key vendor staff.

Penalties will be levied by TTC on vendor on failure to produce an expected

deliverable on schedule. Details of the penalties will be detailed n the SLA

documents amounting to fines deductible from the monthly fee proceeds.

TTC will perform measurements after the project is completed based on the cost

and schedule performance compared with estimates and product quality.

6.6 Change Management

Any changes to the proposed and base lined requirements need to be approved through

a Change Control Board (CCB) chaired by the Project Manager. This includes changes


in scope, requirements and technology. Any such changes from the proposed scope will

be taken up with the CCB and on approval will be included in a later version if the

severity s low else if the severity of the change has a high impact on the primary

software delivery, the change needs to be incorporated in the current release though an

extension of date will be provided subject to realization and approval by the project

manager.

Root cause analysis will be conducted to understand the gap requiring the change to

occur and subsequently any penalty on the fee or number of days will be incorporated

to the vendor. Any change accounted for missing requirements or incorrect

requirements will mandate the analysis team to go over a CCB enquiry committee

chaired by Project manager.

6.7 Product Acceptance

TTC will evaluate both interim and final deliverables for acceptability, including both

executables and non-executables.

User acceptance testing will be performed after every major release which would be

every 3-4 weeks. Following the agile methodology, a scrum release is expected after

every week adding to the logically functional bigger releases. The issues found in user

acceptance testing will be recorded in Quality center and available to every project

stakeholder.

Following are the detailed vendor acceptance criteria based on the quantitative quality

targets, such as performance goals, estimated residual defect densities, or defect

removal effectiveness.


Functional Testing Evaluation of the testing of product functionality to determine whether the testing is adequate for ensuring quality and fitness for use in the product’s intended operating environment.

- Achieved 100% test coverage.- Zero high/medium severity defects in open status.

Defect Data Evaluation of product defect information. Verification of correct product operation for top-priority features.

- Achieved 98% DRR (Defect Removal Ratio)Install Testing Verification of correct product install and uninstall in target

environment. - Documentation available for installation procedure

and automated as much as possible.Vendor Documentation

Contracted user manual and maintenance documentation must be provided in either hard copy or online format.

- Product user documentation evaluated for accuracy and consistency with product operation.

End to End Compatibility Testing

Evaluation of the product to perform its required functions while sharing the same environment with other systems or components. This includes binary sharing, data sharing, hardware and operating system environments, and backward compatibility.

- Successful End to End testing run mimicking the operational world scenario.

- All High/Medium severity integration issues are fixed.Continuous Operation

Evaluation of the product’s operation over a period of time to detect time-dependent defects such as memory leaks, race conditions, and other factors that reduce reliability.

- All issues – both major and minor are addressed during the 3 months of soak time.

Performance Measurement

Evaluation of the key performance attributes of the product to determine whether performance goals are met.

- Key Performance Indicators — quantifiable measures used to determine efficiency and effectiveness of the service

- Service Level Agreement — formal negotiated agreement which defines parameters and responsibilities for the delivery of a service

- Vendor Incidents — any occurrence that disrupts the company’s operation.

- Vendor Billing — accuracy and timeliness of billing.


- Vendor Quality — overall vendor experience.- Vendor responsiveness — responsiveness to general

questions and follow-up- Training quality- Knowledge – knowledge of the vendor's core functions.- Vendor innovation – knowledge and adaptability of

vendor’s services

6.8 Support and Maintenance

Vendor is expected to provide a mandatory 3 months of extended product support post

the turnkey implementation day.

- The support functions will include ironing out any known issues major or

minor. Documentation and troubleshooting tips needs to be recorded.

- Trainings to be imparted to all respective TTC staff.

- Any pending activity needs to be completed.

- transfer of skills and knowledge to TTC staff

- Delivery of new releases of commercial components and future enhancements.

- Tweak the performance issues to find the optimal balance.

7. Vendor Requirements

The chart below describes the vendor staffing requirements.

Vendor Team Required Core skills Required Education

Years of Experience

Required Certifications

Management Project management MBA More than 12 years

PMP

Development Java SDK, MySQL, NetBeans

Software Engineering

More than 5 years Sun Java certification.

Quality Functional testing, MySQL

Software Engineering

More than 5 years ISTQB / CSTE

RFID Engineers RFID techniques Electronics More than 7 years -


Engineering

Records retention policy of the vendor should match the TTC’s corporate retention

policy. An attrition rate higher than TTC might be subject to verification and the

vendor should sign a contract on the attrition policy to reduce the project derailment

risk due to vendor staff attrition.

All development and testing has to be done strictly using legally acquired licensed

versions of software tools.

TTC staff will have the right to inspect the development premises and facilities, and

to conduct project and technical reviews at the vendor’s site without notice.

8. Functional Use Case Requirements

Following are the software / system use case requirements, TTC plans to outsource to the

vendor. All the use cases listed below qualify as mandatory requirements without which the

system will be incomplete. The use cases have been included from the software requirements

specification.

8.1 UC 1: Kiosk Recharge System

Use Case Name: Kiosk Recharge System

Brief Description: The purpose of the use case is to show the interactions between the kiosk

recharge machine and the TTC passenger where she/he tries to recharge the metropass.

Trigger: TTC passenger needs to recharge metropass.

Level: Sea Level


Precondition:

1. The TTC passenger can access the Kiosk recharge system.

2. The Kiosk machine should be up and running.

Post condition:

On Success:

o The passenger recharged the metropass.

On Failure:

o The passenger cannot recharge the metropass.

Flow of Events

Basic Flow

1 The passenger inserts the metropass in the card reader of the kiosk machine.

2 The Kiosk machine directs the passenger to select a language - English/French.

3 The passenger selects the desired language.

4 The kiosk machine prompts the passenger to select the type of pass required [BR1]

5 The passenger confirms the selection / order.

6 The kiosk system calculates the total order amount by validating [BR2]

7 The Kiosk system prompts the passenger to remove the metropass and then re-insert

the debit / credit card .


8 The passenger inserts the debit/credit card [BR3].

9 The Kiosk system prompts the passenger to enter the pin for debit/credit card.

10 The passenger enters the 4 digit pin no [BR4]. (Alternative Flow 1)

11 The third party system process the payment and once the kiosk system gets the

confirmation number from the third party system it request the passenger to remove

the debit/credit card and then insert the metropass again .

12 The passenger removes the credit/debit card and then inserts the metropass.

13 The Kiosk system deposits the monthly pass in to the metropass and then the Kiosk

system asks the passenger to remove the metropass.

14 The use case ends.

Business Rules

BR1: The passenger must select any one of the pass types shown in the Kiosk System.

BR2: The total order amount is the sum of the cost of the pass selected plus the

appropriate taxes.

BR3: Kiosk system accepts only debit or credit card payment.

BR4: The 4 digit pin no must be numbers only.

Alternate flows

Alternate flow 1: The passenger enters the 4 digit pin number incorrectly from step 10

1) The kiosk system prompts an error message (Incorrect pin number).


2) The kiosk system asks the passenger to re-enter the correct pin number.

3) The passenger submits the correct pin number.

4) The kiosk system continues to process the payment.

5) Alternate flow resumes at step 11 of basic flow.

8.2 UC 2: TTC Online Recharge System

Use Case Name: TTC Online Recharge System

Brief Description: The purpose of the use case is to show the interactions between the TTC

online recharge system (system) and the passenger where she/he tries to recharge the metropass.

Trigger: TTC passenger needs to recharge metropass and proceeds to TTC website.

Level: Sea Level

Precondition:

The TTC passenger can access the TTC Online Recharge System

Post condition:

On Success:

o The passenger recharged the metropass.

On Failure:

o The passenger cannot recharge the metropass.

Flow of Events

Basic Flow

1 The passenger browses TTC website and navigates to Online Recharge System

(system).


2 The passenger selects the type of pass required.

3 The system calculates the total order amount by validating. [BR1]

4 The passenger chooses to checkout.

5 The system prompts the passenger to enter the unique passenger ID number present

on the metropass for identification. [BR2] (Alternate Flow 1)

6 The system validates the passenger and proceeds to checkout and payment.

7 The system prompts the passenger to enter credit /debit card number, expiry date and

CVV number.

8 The passenger confirms and continues with payment.

9 The system prompts the passenger for the credit /debit card number and expiry date.

10 The customer provides the credit/debit card number and expiry date and requests the

system to continue.

11 The system applies BR3 and sends the credit/debit card number, expiry date and the

total amount to the credit card company in order to check the customer’s situation and

funds.

12 The credit/debit card company checks the customer situation and funds. (Alternate

Flow2).

13 The credit/debit card company processes the payment and generates a related

authorization number.


14 The credit/debit card company sends the authorization number to the system.

15 The system generates and indicates an order confirmation number to the passenger.

16 The online recharge system confirms the recharge validity period.

17 The use case ends.

Business Rules:

1) BR1: The total order amount is the sum of the cost of the pass selected plus the

appropriate taxes.

2) BR2: The unique 12 digit identification code at the back of the Metropass must be

numbers only.

3) BR3: The online TTC recharge system accepts only debit or credit card payment.

Alternate Flows

Alternate flow 1: The passenger enters the unique Identification number incorrectly.

1) The system prompts an error message for incorrect ID and asks the passenger to enter

the ID again.

2) The system validates the new ID keyed in.

3) On failed validations, alternate flow 1 resumes at step 1 of alternate flow 1.

4) On successful validation, alternate flow 1 resumes at step 6 of basic flow.

Alternate Flow 2: The passenger has insufficient funds.


1. From step 12, the third party payment system checks the card validity and authenticates

payment instructions by checking fund availability.

2. The payment system notifies insufficient fund status to the Online Recharge system.

3. The online recharge system notifies the passenger on fund status and prompts him/her for

an alternate credit / debit card information.

4. The passenger provides alternate credit/debit card information.

5. The third party payment system successfully authenticates the payment.

6. The use case resumes at step 13 of the basic flow.

8.3 UC 3: TTC Passenger Registration System

Use Case Name: TTC Passenger Registration System

Brief Description: The purpose of this use case is to show the interaction between the TTC

Clerk, TTC Passenger Registration System (system) and the TTC passenger. The TTC passenger

provides personal information by filling a form and submitting to the clerk who enters the

information in the Passenger registration system. On successful registration, the clerk issues a

generic rechargeable photo Identification metropass card.

Trigger: TTC passenger has a need for a metropass.

Level: Kite level

Precondition:

1. The TTC passenger walks into any of the TTC registration office.

2. The Passenger pays $10 for registration and gets the registration form.


3. The passenger approaches the clerk with a completed form.

4. The passenger has all supporting government issued documents to prove his identity.

Post condition:

On Success:

o The passenger gets the metropass identification card issued.

On Failure:

o The passenger did not get the metropass identification card issued.

Flow of Events

Basic Flow

1. The TTC clerk verifies the information in the form against the supporting identification

such as Passenger name, Government ID number, Date of birth, Address, Telephone,

Supporting identification documents, Type of pass and signature with date. [BR1] [BR2]

(Alternate F1ow 1)

2. The clerk enters the verified passenger information into the new passenger registration

system capturing all the information.

3. The Clerk captures a photograph of the passenger from a camera integrated to the

passenger registration system. [BR3]

4. The clerk prints a fresh metropass identification card with unique identification number,

photograph and passenger information.


5. The passenger verifies the printed information provided in the card. (Alternate Flow 2)

6. Use case ends

Business Rules

BR1:All the details must be filled in upper case letters only

BR2: The piece of government ID must have a photo of the passenger in it e.g.: driving

license and ID like sin no or health card will not be accepted.

BR3: The photo must be taken in white background only and passenger should not be

wearing any Item that covers their face while taking photo.

Alternate Flow

Alternate flow 1: Passenger fills information incorrectly on the form

1. From Step 1, The staff notifies the passenger to fill out the missing or incorrect

information

2. The passenger fills out the missing or incorrect information and submits back.

3. The clerk verifies information again.

4. Alternate flow resumes at step 2 of basic flow.

Alternate flow 2: Passenger information appears incorrectly in the metropass

1. From step 5, the passenger notifies the clerk about the discrepancy in information

printed.


2. The clerk updates the correction and issues a new Metropass and retains the old

card.


8.4 UC 4: Validating Metropass at TTC Premises

Use Case Name: Validating metropass at TTC premises

Brief Description: The purpose of the use case is to show the flow of events that occurs when a

passenger enters the TTC premises

Trigger: Passenger needs to enter TTC premises

Level: Kite level

Precondition:

1. The TTC passenger holds a valid metropass in person.

2. The RFID installation is made on the entry points like Subway station turnstiles,

Bus/Streetcar entry and is working fine.

Post condition:

On Success:

o The passenger can enter the premises

On Failure:

o The passenger cannot enter the premises

Flow of events

Basic flow


1. Passenger approaches the RFID mounted entry point (Bus doorway / Subway station

turnstile). [BR1]

2. The RFID system verifies the hands free metropass in its close vicinity. (Alternate Flow

1) (Alternate Flow 2) (Alternate Flow 3)

3. RFID system generates a standard confirmation beep and lets the passenger through.

4. Use case ends.

Business Rules:

BR1: All entry points have a 1 meter long gangway leading to a turnstile and at any point only

one passenger can access the gangway.

Alternate Flows:

Alternate Flow 1: RFID system validates metropass authenticity and validity.

1. RFID system reads the unique 12 digit identification number from the metropass.

2. RFID system verifies the ID number against the passenger database system.

3. Passenger DB system confirms a match in ID number and the metropass validity

status.

4. RFID system interprets the data from Database.


Alternate Flow 2: [Subway Station]: Passenger does not carry metropass or has an invalid

metropass.


1. The RFID system recognises the passenger but verifies the metropass as invalid.

2. The turnstile entry fails to get activated.

3. The passenger takes a side gangway leading to the ticket booth.

4. Alternate flow resumes at step of basic flow.

Alternate Flow 3: [Buses / Streetcars]: Passenger does not carry metropass or has an

invalid metropass.

1. The RFID system recognises the passenger but verifies the metropass as invalid.

2. The TTC staff is not alerted with a valid beep.

3. The passenger cashes the travel.

4. Alternate flow resumes at step of basic flow.

8.5 Hardware upgrades

ID Requirement

R 8.5.1Installation of RFID readers on entrances to all TTC assets like transit bus,

Streetcar and Subway stations.

R 8.5.2Databases and servers to support the customer information and recharge

information from kiosks.

R 8.5.3Design and manufacture the metropass cum pass with following capabilities -

RFID, Magnetic stripe and Secure pin.

Note: Cards equipped with RFID are used to identify people. The hands-free card readers’ offer

read ranges of multiple meters (long-range identification) and offers the highest level of


convenience while maintaining sufficient levels of security. This reader supports reading battery

less UHF cards that follow the EPC Gen 2 standard.

9. Deliverables

Following are the interim and final deliverables to be produced for the project including both

technical and project management deliverables.

Vendor-written requirements specifications.

Documentation on Design descriptions and Database definitions.

Data Dictionary.

User interface prototypes and UI models.

Source code for API’s, DLLs, and executables.

Test plans, Test cases, Test Procedures, and Reports.

Vendor’s software development plan and any revisions made to it.

WBS (Work breakdown structure).

User documentation.

Metrics on status, schedule, and cost reports.

Change request reports and metrics (CCB)

Defect tracking reports and metrics

Performance metrics

Support and Training documents

SP (Stored procedures) and scripts

Installation scripts, Procedures, Operating manuals.

RTM (Requirements traceability matrix).


All the deliverables should be placed in the company intranet under the specific project folder

repository. The project folder repository should also have a backup available which is updated on

a nightly basis. All the versions of the documentation should be available and ordered as per the

company IT folder and file naming conventions.

10. Cost and Schedule Estimates

The table below lists the cost and schedule estimates from TTC.

Delivery Milestone Due Date Estimated Cost range ($)

POC for the RFID implementation Sept 15, 2014 2000 - 3000

Installation of RFID hardware across all

TTC assets. Oct 10, 2014 2000000 – 2500000

Software Development (Online & Kiosk)

phase Aug 15, 2014 768000 – 825000

Software Testing Phase Oct 15, 2014 350000 – 400000

End to End Integration testing Oct 27, 2014 7000– 8000

Pilot Implementation Testing with 50k

user registrations and RFID across all

Subway station Nov 17, 2014 50000 – 75000

Go Live Jan 1, 2015 –

Maintenance & Support Apr 1, 2015 10000 – 15000

Material, Software Licenses etc - 15000 - 20000

The vendor must justify any cost or schedule estimates that are significantly outside the range

presented.


11. Contracts and Licenses

11.1 Purchase Agreement

The project being a turnkey project, the vendor will purchase all the RFID materials

including card readers, initial cards, software licenses, hardware – Application and

database servers, database storage, Passenger information uplink servers in all TTC assets

etc.

All the materials purchased needs to get the approval from the Project Manager. TTC will

not be liable to handle materials or warehousing requirements.

TTC will not be liable for Material handling and logistics. The RFID installation on

movable TTC assets like Buses and streetcars has to be done overnight from the TTC

garages.

11.2 Licensing Agreements

Licenses might be necessary for packages or reused components that will be integrated into the

developed product.

All Software and Hardware licenses needs to be purchased by the Vendor though the approvals

for them need to be provided by the Project Manager.

11.3 Intellectual Property Ownership

Ownership of the intellectual property along with the information within will remain the

exclusive property of TTC.

11.4 Vendor Warranties


The Vendor must warranty all products, work and services provided for a period of three years after

the go live date. The contractor must turn over all equipment and software warranties to TTC.

The Vendor shall propose a warranty for all its offerings including but not limited to RFID

installations, quality of software / hardware and any third party acquisitions and describe the services

and support available for each of them.

11.5 Performance Bonus, Late-Delivery Penalties, and Early-Delivery Bonuses

This project is subject to a bonus and penalty agreement, to help properly identify and target

TTC’s business priorities, reach specific deadlines, budget, or deliverable and quality objectives

of the project.

11.5.1 Performance Bonus

Letter of credit.

Escrow funds

Bonus cheque worth 2% of vendor’s monthly fee.

These items help protect the TTC against vendor nonperformance.

11.5.2 Late Delivery penalties

Following are the cost penalties that the TTC will apply for missed milestones or late

delivery of the contracted product.

5% penalty on software development fee for each month that vendor-tested code is

late;

5% penalty on software testing fee if DRR (Defect Removal Ratio) < 98% after

System / UAT test.


11.5.3 Financial Bonus

Following are the financial bonuses that TTC will pay if the vendor delivers a product

of acceptable quality and functionality ahead of schedule or if the vendor delivers a

product with exceptionally few defects.

An equity stake

5% bonus in software development fee, if vendor-tested code is available 1 month

before the contracted date.

10% bonus if the number of defects discovered in system test is less than 1%

11.6 Vendor-Supplied Training

Following table lists the expected training by topic, the total number of hours and the total

number of TTC staff gaining the knowhow. The vendor should ensure that the following training

has been completed before the signoff without which the project funds will not be released for

full and final settlement.

Training Topic Number of HoursMinimum Number of staff

trained.Hands-on training on Software Usage. 3500 350

Storage, Backup and Maintenance of DB 400 20

RFID Reader Installation on TTC Assets. 700 70

RFID System Troubleshooting 300 30

Technical Support & Maintenance 1000 100

11.7 Non-Disclosure Agreements


All stakeholders from the vendor side needs to abide by and execute a mandatory non-disclosure

agreement concerning the confidentiality of Software solutions implemented, Project

Documentation or any such knowledge gained through the project proceedings.

12. Proposal Evaluation Criteria Matrix

Following are the criteria TTC will use to evaluate vendor proposals.

CriteriaMinimum

RequirementRating

Vendor references for comparable RFID projects.

5 projects 10 points

Technical capability: Design, Implementation and Delivery of mega turnkey Passenger systems.

10 projects 15 points

Competitive total cost. - 20 points

Ability of proposed system to meet the stated requirements.

- 15 points

Vendor warranty, training, support and maintenance offerings.

3 months 15 points

CMMI Level 4 and above. 10 points

Any Value add – ROI measurements, Additional performance SLA’s or SLO’s.

- 5 points

RFP response document completeness 10 points


References

Korostoff, K.(2010).The RFP: Finding Great Research Partners. Market Research Book - Research Rockstar LLC. http://www.greenbook.org/marketing-research/rfp-finding-great-research-partners-hm19#Chapter6

Business Analyst | business-analyst-templates-description | Templates. (n.d.). Retrieved from http://www.batimes.com/templates/business-analyst-templates-description.html?SID=888

TTC Current Tenders. (n.d.). Retrieved from http://www.ttc.ca/TTC_Business/Materials_and_procurement/Current_Tenders.jsp

Statement of Work Template. (n.d.). Retrieved from http://www.projectmanagementdocs.com/project-documents/statement-of-work.html

Evaluating Candidate COTS Packages - adapted from Software Requirements, 3rd Edition | seilevel.com. (n.d.). Retrieved from http://requirements.seilevel.com/blog/2014/02/evaluating-candidate-cots-packages-adapted-from-software-requirements-3rd-edition.html

RFP Announcement: The National Myelodysplastic Syndromes (MDS) Natural History Study - Data Coordinating Center and Central Laboratory/Biorepository | DoResearch. (n.d.). Retrieved from https://doresearch.stanford.edu/funding/opportunity/rfp-announcement-national-myelodysplastic-syndromes-mds-natural-history-study

Toronto Transit Commission - Wikipedia, the free encyclopedia. (n.d.). Retrieved April 2, 2014, from http://en.wikipedia.org/wiki/Toronto_Transit_Commission

https://doresearch.stanford.edu/funding/opportunity/rfp-announcement-national-myelodysplastic-syndromes-mds-natural-history-study

https://doresearch.stanford.edu/funding/opportunity/rfp-announcement-national-myelodysplastic-syndromes-mds-natural-history-study

http://requirements.seilevel.com/blog/2014/02/evaluating-candidate-cots-packages-adapted-from-software-requirements-3rd-edition.html

http://requirements.seilevel.com/blog/2014/02/evaluating-candidate-cots-packages-adapted-from-software-requirements-3rd-edition.html

http://www.projectmanagementdocs.com/project-documents/statement-of-work.html

http://www.ttc.ca/TTC_Business/Materials_and_procurement/Current_Tenders.jsp

http://www.batimes.com/templates/business-analyst-templates-description.html?SID=888

http://www.greenbook.org/marketing-research/rfp-finding-great-research-partners-hm19#Chapter6

http://www.greenbook.org/marketing-research/rfp-finding-great-research-partners-hm19#Chapter6

ttc metropass consolidation project - weeblybasantramachandran.weebly.com/uploads/1/8/2/0/... ·...

Documents