PM Artifact

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 37

[CLIENT]: Business Definition Document (BDD)

[CLIENT LOGO]

Portal for Airport Manager Effectiveness (SMWR


Reporting)
BUSINESS DEFINITION DOCUMENT

CLARITY #: PRJ0021749
Exec Sponsor (US) / ELT Sponsor (EMEA) Joe Ferraro, Andre Meesschaert
Business Owner/Project Manager Aaron Gleason
Portfolio Lead/Portfolio Delivery Manager Moiz Masavi
(EMEA)
Project Manager Jeanne Tansey
Document Author Lohitha Ravi
Peer Reviewer Moiz Masavi, Nishank Gandhi
Date Issued 10-May-2017

Version Control
Version Date Status <Draft or Author Comment / Changes from Prior Version
Final>
1.0 5/10/17 Final Lohitha Initial Version
Ravi
Final Lohitha Modified the document to exclude the
1.1 11/21/17
Ravi requirement of a mobile app for this project
Final Removed references to accessories reports as
Lohitha
1.2 12/19/17 it is out of scope of initial delivery of the
Ravi
SMWR application
Final Nishtha Added the requirement for VRS 03 and VRS
1.3 02/02/18
Sachan 04
Final Nishtha Updated Business owner
1.4 02/12/18
Sachan Added a new section - Appendix D
Template Version 1.1 Company Confidential
[CLIENT]: Business Definition Document (BDD)
Final Nishtha
1.5 02/16/18 Updated Appendix C and Appendix D
Sachan
Final Added Appendix E to include rules for VRS03
report
Nishtha
1.6 02/23/18 Updated Appendix B
Sachan
Updated the functional requirements FR01,
FR02, FR11, FR29

Template Version 1.1 Company Confidential


[CLIENT]: Business Definition Document (BDD)
Table of Contents

Reviewers & Approvers...........................................................................................................................................4


Sign Off.....................................................................................................................................................................5
Glossary of Terms........................................................................................................................................5
Supporting Documents................................................................................................................................5
Document Purpose..................................................................................................................................................6
1. Project Overview, Objectives and Impact......................................................................................................7
1.1. Overview..........................................................................................................................................7
1.2. Objectives & Benefits.......................................................................................................................7
1.3. Brand & Commercial Impact...........................................................................................................7
1.4. Business Scope.................................................................................................................................8
3. Business Processes.........................................................................................................................................9
3.1. ‘As Is’ User Roles..............................................................................................................................9
3.2. ‘As Is’ Business Processes................................................................................................................9
3.3. ‘To Be’ User Roles............................................................................................................................9
3.4. ‘To Be’ Business Process................................................................................................................11
4. Business Requirements.................................................................................................................................12
5. Functional Requirements..............................................................................................................................13
6. Non Functional Requirements......................................................................................................................23
6.1. Performance..................................................................................................................................23
6.2. Security..........................................................................................................................................23
6.3. Capacity.........................................................................................................................................24
6.4. Availability.....................................................................................................................................24
6.5. Reliability.......................................................................................................................................24
6.6. Compliance....................................................................................................................................24
7. C.R.A.I.D........................................................................................................................................................26
7.1. Constraints.....................................................................................................................................26
7.2. Risks...............................................................................................................................................26
7.3. Assumptions...................................................................................................................................26
7.4. Issues..............................................................................................................................................26
7.5. Dependencies.................................................................................................................................27
Appendix A.............................................................................................................................................................28
Appendix B.............................................................................................................................................................30
Appendix C.............................................................................................................................................................31
Appendix D.............................................................................................................................................................34
Appendix E.............................................................................................................................................................35

Template Version 1.1 Company Confidential


[CLIENT]: Business Definition Document (BDD)
Reviewers & Approvers

Functional Area Position RACI Approver

Business Business Sponsor: C


Ferraro, Joe
Meesschaert, Andre
Business Owner & Project Manager: A Y
Gleason, Aaron
IT Technical Leads: C
Gandhi, Nishank
Srivastava, Kritika
Kulkarni, Neela Neela.Kulkarni@[client].com Palacios,
Alfredo Alfredo.Palacios@[client].com
Renn, Kurt Kurt.Renn@[client].com
Dandapath, Debajyoti Debajyoti.Dandapath@[client].com
Chopade, Aniket Aniket.Chopade@[client].com
Project Manager: C Y
Tansey, Jeanne Jeanne.Tansey@[client].com
Architecture Directors: C
Schaaf, George George.Schaaf@[client].com;
Renier Pretorius Renier.Pretorius@[client]-europe.com
Solution Architect: C
ABCR-ITArchitecture@[client].com
Relationship Manager: I
Hans, John John.Hans@[client].com
Information Security:  I
abcrinfosec@[client].com
Test Manager: I
Wallace, Sharon Sharon.Wallace@[client].com
Business Analyst: C
Bailey, Simon Simon.Bailey@[client]-europe.com
Cox, Jim Jim.Cox@[client]-europe.com
Gupta, Vishal Vishal.Gupta@[client].com
Ramaiah, Suresh Suresh.Ramaiah@[client].com
Project Management Office: I
Project.Administration@[client].com
Information ABCR - Information Security: abcrinfosec@[client].com I
Security
Legal [CLIENT] Privacy: I
[CLIENT]privacy@[client].com

4
[CLIENT]: Business Definition Document (BDD)
Sign Off

Name Role Signature


Jeanne Tansey IT Project Manager
Aaron Gleason Business Owner

Glossary of Terms
Term Meaning
ADD Architecture Definition Document
DMP Damager Manager Portal – US and Canada application
EDW Enterprise Data Warehouse
Maintenance Damage Manager System – EMEA
MDMS
application
Motor Vehicle Asset to uniquely identify [CLIENT]
MVA
vehicles
MSI Market Segment Indicator
PM Preventive Maintenance
RA Rental Agreement
SMWR Station Manager Weekly Report
TCU Telematics Control Unit
TDD Technical Definition Document
VAB Virginia Beach
VIN Vehicle Identification Number
Vehicle Reporting System – Mainframe based
VRS
application

Supporting Documents

Document Name Quick Link


PSR/Project Brief PSR
Supporting Documentation

5
[CLIENT]: Business Definition Document (BDD)
Document Purpose

This document is used to capture business, functional and non-functional requirements for the given
project as agreed with the Project Sponsors.

The target audience of the document are the Business Sponsor and Stakeholders as identified in Clarity.
The approved version of this document will be passed to the Technical teams. The Technical team will
prepare and share Technical Design for business stakeholders and IT systems teams review and
approval.

This is a mandatory document for all projects in accordance with [CLIENT] SDLC

6
[CLIENT]: Business Definition Document (BDD)
1. Project Overview, Objectives and Impact

1.1. Overview

The current Station Manager Weekly report consists of 13 plus different reports which the global
Operations team works as part of their daily work flow and for audit requirements. The report is time
consuming, manual, print/paper heavy and often the actions taken by Operations are reactive than
proactive as most of the reports are not real time and lag by several days. It requires extensive amount of
time to reconcile reports, thereby preventing Operational Managers from focusing on [CLIENT]’s associates
and the customer’s overall experience.

This project aims to build a live, globally supported portal that will consolidate multiple data points for
Contracts and Fleet and allow Operational Managers to access in real time key operational information
across all brands, research and take immediate action.

1.2. Objectives & Benefits


Objective # Description (including Benefits) Stakeholder Area
1. Develop a live fully responsive web portal Operation
solution that will be one stop shop for all key Managers
operational data points for Contracts and
Fleet. It will
- Minimize the amount of time spent
in researching and reconciling
present day Station Manager
Reports. Today, managers need to
pull in information from various
sources – 502, 203, 806, VRS, DMP,
Infopac etc. - in order to research
specific items on the report
- Provide a cleaner display of relevant
data for strategic management
- Identify operational exceptions in a
timely manner, with greater ease and
accessibility
- Improve response times to major
issues or policy violations
- Minimize printing costs
1.3. Brand & Commercial Impact
Corporate:
US* CA LAC ASIA AU/NZ EMEA Global
[CLIENT
BRAND 1]
[CLIENT
BRAND 2]
[CLIENT
7
[CLIENT]: Business Definition Document (BDD)
BRAND 3]
[CLIENT
☐ ☐ ☐ ☐ ☐ ☐ ☐
BRAND 4]
[CLIENT
☐ ☐ ☐ ☐ ☐ ☐ ☐
BRAND 5]
[CLIENT
☐ ☐ ☐ ☐ ☐ ☐
BRAND 6]
[CLIENT
☐ ☐ ☐ ☐ ☐ ☐ ☐
BRAND 7]

Licensee:
US* CA LAC APAC EMEA Sub Global
Licensees
[CLIENT
BRAND 1]
[CLIENT
BRAND 2]
[CLIENT
BRAND 3]
[CLIENT ☐
BRAND 4] ☐ ☐ ☐ ☐ ☐ ☐
[CLIENT ☐
BRAND 5] ☐ ☐ ☐ ☐ ☐ ☐
[CLIENT
☐ ☐ ☐ ☐ ☐ ☐
BRAND 6]
[CLIENT ☐
BRAND 7] ☐ ☐ ☐ ☐ ☐ ☐

* US includes Puerto Rico and Virgin Islands.

1.4. Business Scope

# In Scope Items Stakeholder Area


1. Develop an interactive, fully responsive, global application (web [CLIENT] IT, Operational
portal) that will consolidate multiple data points for contracts Managers
and fleet. Refer Appendix D for complete list of reports.
2. The application will automatically reconcile data from multiple [CLIENT] IT, Operational
sources; generate a list of exceptions accompanied by supporting Managers
details and make recommendations for actions to be taken by
the manager.
3. The application will maintain an audit trail of all actions taken by [CLIENT] IT, Operational
the manager on the port Managers
4. The application will generate alerts (text alert, email alert, [CLIENT] IT, Operational
dashboard alert on the portal) for major issues and policy Managers
violations.
# Out of Scope Items Stakeholder Area
8
[CLIENT]: Business Definition Document (BDD)
1. Accessories reports [CLIENT] IT, Operational
Managers
2. Contract Reports other than Payment Card Decline and [CLIENT] IT, Operational
Exceptions Managers

9
[CLIENT]: Business Definition Document (BDD)
3. Business Processes

3.1. ‘As Is’ User Roles

Process Role Role Description Process Description


Reconcile Station Operational Manager for an airport, Pull all reports, print them,
Manager Weekly Manager local market or supply chain research information from
Report location multiple sources and make
handwritten notes after
research is conducted.
Ensure Station [CLIENT] District Manager and above Ensure Station Manager
Manager Weekly Internal Weekly Report is reconciled
Report is reconciled Auditor regularly
regularly

3.2. ‘As Is’ Business Processes


 Currently, reconciliation of the Station Manager Weekly Report is a manual, resource intensive
process.
 The Station Manager pulls all reports from Wizard or Infopac. This is done manually or using
macros.
 The manager reviews the report and identifies items that will need to be researched.
Information is pulled in from multiple sources (like 203/806, 502, Vehicle Trace, DMP, Zipcar
website etc.).
 The outcome of the research is maintained on spreadsheets or handwritten notes on printed
reports.
 Globally, Operations spends anywhere from 15-40 hours (varies by region/size of location) per
week printing, working and reconciling these reports manually.

3.3. ‘To Be’ User Roles

Process Role Process Description Impact of change Related


Functional
Requirement
Profile Settings Operational Update preferences and Users will assign FR06
Managers information on profile individuals to
who will use setting page different
the new workgroups
SMWR
application
(web portal)
Access Control New SMWR Validate access to the Users without the FR05, FR30

10
[CLIENT]: Business Definition Document (BDD)
Process Role Process Description Impact of change Related
Functional
Requirement
application application and reports necessary access
based on the logon will not be able
credentials and user role log in, view
reports or take
action on the
reports
Easy research New SMWR The application will pull in Users will not FR03, FR07,
application information for contract, have to log in to FR11, FR15,
and vehicle from multiple other FR17, FR18,
sources applications to FR22, FR23,
obtain vehicle, FR24, FR30
contract
information in
order to make
decisions
Make New SMWR The application will Users can take FR10, FR15,
recommendations application execute a pre-defined set actions based on FR30
of rules based on vehicle the
or contract parameters recommendation
and make made by the
recommendations application
Notifications New SMWR Alert operational This will help FR09, FR19
notification managers about issues or operational
process policy violations managers
manage their
staff and vehicles
more efficiently
Corrective action Operational Review reports on the This will help FR08, FR04,
Manager SMWR application and reconcile the FR30, FR13,
take necessary action (like SMWR reports FR17, FR18
email checklists, update
RA, update notes, perform
manual checks) based on
the recommendations
Audit review [CLIENT] Review audit reports Ensure timely FR14, FR25
Internal generated by the SMWR action is taken by
Auditor application Operational
managers to
reconcile SMWR
reports

11
[CLIENT]: Business Definition Document (BDD)
3.4. ‘To Be’ Business Process
 Operational Manager will log in to the new SMWR application to view reports for locations he /
she has access to.
 The application will pull in vehicle / contract data from multiple sources and display relevant
information on each of the reports. Color coding or indicators will be used to allow easy
identification of records that need to be researched by the manager.
 The application will perform automatic verification of business rules for vehicles / contracts and
make recommendations for actions to be performed by the manager – like email checklists,
update the RA, assign the record to another employee, enter processing notes etc.
 Audit trail will be maintained for all actions performed via the SMWR application so that an
internal auditor can review audit reports to ensure SMWR reports are reconciled regularly.
 Notifications/alerts will be generated for issues or policy violations. This will enable managers
take immediate action when needed.

12
[CLIENT]: Business Definition Document (BDD)
4. Business Requirements

Business Objective Stakeholder Detailed Description MoSCoW


Requirement # Area (identify Business Owners if required)
#
BR01 1 [CLIENT] IT Build a global, fully responsive SMWR M
application (web portal) that will house live
Station Manager reports for fleet / contracts
BR02 1 [CLIENT] IT The SMWR application should allow easy M
identification of vehicles / contracts that would
need to be researched
BR03 1 [CLIENT] IT Pull in vehicle / contract information from M
multiple sources and display on the SMWR
application in order make the research easy
BR04 1 [CLIENT] IT Perform automatic verification of business rules M
for vehicles / contracts, display the results on
the SMWR application and make
recommendations for user action based on the
results
BR05 1 [CLIENT] IT Provide the ability to view and enter notes on M
the SMWR application for vehicles / contracts
BR06 1 [CLIENT] IT Provide the ability to generate M
alerts/notifications for specific scenarios
BR07 1 [CLIENT] IT Provide the ability for an Internal Auditor to M
ensure that prompt action is taken for major
issues related to vehicles / contracts
BR08 1 [CLIENT] IT Provide the ability to pull up information on the M
SMWR application from multiple sources
BR09 1 [CLIENT] IT Define access privileges for every user role that M
would use the SMWR application
BR10 1 [CLIENT] IT Provide the ability to assign via the SMWR M
application a vehicle / contract record to an
employee in order to perform the necessary
research
BR11 1 [CLIENT] IT Provide a dashboard on the SMWR application M
that would display current status of key
performance indicators
BR12 1 [CLIENT] IT Provide the ability to update personal M
preferences on the SMWR application

13
[CLIENT]: Business Definition Document (BDD)
5. Functional Requirements
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
Fleet Report Requirements
FR01 BR01 Build a live fleet view that is a combination M Compare the
of the rules for the present day VRS 01, 21 result with that
and 29 screens. Provide indicators on the of the VRS
report to clearly identify vehicles that only screens
satisfy the criteria for the 21 report. Pilot
for one location.

Provide 2 types of views:


0+ view - All vehicles on hand at the
location
7+ view - All vehicles on hand at the
location and idle for 7 or more days
3+ view - All vehicles on hand at the
location and idle for 3 or more days
FR02 BR01 Display the following information on the M Verify all the
report data elements
1. MVA are populated
on the report
2. Make and Model
3. Vehicle Status
4. Inventory Date and Time
5. Location
6. Idle Days
7. [CLIENT] Idle Days (collapsible column)
8. MSI
9. Space and Readyline number
10. Risk Status
11. Fleet Owner
FR03 BR03 Following information about the vehicle M Verify all the
should be available for review upon data elements
clicking/selecting the MVA displayed on are populated
the report: on the report
1. License Plate Number
2. VIN Number
3. Vehicle Trace (includes movement
type, Location Mnemonic, Date, Time,
Miles, Movement Number, Brand and
Remarks)

14
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
4. Last Vehicle Movement
a. If rental agreement, also SEC from
203/806 screen
b. Was the MVA modified?
c. Was last movement a minilease or
extended rental?
5. Miles / KM
6. PM Miles
7. Registration and Inspection Date
8. Title Status (is it active?)
9. MSI (conditions – turnback facilities
etc.)
10. Car Group
11. TCU Connected or Zipcar Device
12. Last Gate Exit Scan
13. Button to Request Connected Car Last
recording of Data within a Geo Fence
facility
Notes section - Notes from ERS, VAB,
Supply Chain, Manager’s Comments, etc.
FR04 BR08 Provide the ability to search by MVA, VIN M Verify the result
or license plate number with that of the
313 screen
FR05 BR09 User Roles M Log in for each
1. Country Manager / AVP type of user
role to verify
2. Regional Manager / Operational
the access
Director
privileges
3. District Manager / City Manager /
Front Line Manager / Airport Manager
4. Security Manager
5. Supply Chain
6. Finance
7. Auditor
8. Operations
9. VAB, Budapest
10. Reservation Center
11. L&D, SPM
12. WHQ, Bracknell management
15
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)

Types of Access
for user roles
1. Add notes to vehicle
2. Send emails
3. Fill in missing vehicle report and
4. Add access to employees
5. Give temporary full access to an
employee
6. Email missing vehicle report to Security
only by specific roles
FR06 BR12 Provide the ability to assign individuals to C Verify if all user
each work group like Supply Chain, Area roles are able to
Security, Fleet Distribution etc. Integrate make
with Workday for employee hierarchy assignments to
information. all applicable
work groups
FR07 BR02 MVA records on the report should be M Verify the last
marked with green, amber and red color revenue date
based on the following rules and inventory
date for all
No Dot vehicles on the
 No revenue in 71 hours report and
determine if
 No inventory in 71 hours
colour coding is
Green
correct
 Revenue within 71 hours  (under 3
days)
 Inventoried within 71 hours (under 3
days)
Yellow
 Inventory or not inventory (click on dot
to see)
 No revenue from 72-144 Hours (6
days)
Red
 7 days idle with no revenue
 Not inventoried in 7 days
FR08 BR05 Provide the ability to update notes for a M Enter notes for
vehicle and view notes entered by all a vehicle and

16
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
users. Notes should be retained for 60 verify it is
days. displayed
FR09 BR06 Provide the ability for a manager to M Add notes to a
receive an alert on the application every vehicle owned
time another user updates notes/missing by another
vehicle checklist for a vehicle owned by location, log in
the manager’s location as manager for
that location to
view the alert
FR10 BR03, BR04 Provide the ability to view, run and update M Verify the
(enter notes and status) a checklist for a results of the
missing vehicle. Wherever applicable, checklist with
automatically verify checklist items and vehicles that
make recommendations. Complete satisfy the
checklist is available in Appendix A. checklist
criteria
FR11 BR03, BR04 For a connected car, provide the ability to M Verify the
request last recording of data within a geo information of
fenced facility the connected
car
FR12 BR04 Provide the ability to email the filled out M Verify email
Missing Vehicle report to content and if it
1. Operation Manager, Supply Chain is received by
Manager, Security Manager (these the intended
would be defined by user in profile recipient
settings)
2. Audit Team
3. Finance Team
4. Any email address that is manually
entered
FR13 BR10 Provide the ability to assign an MVA S Verify that a
record to another employee/user for user is able to
research assign a record
to another user
FR14 BR07 Maintain a daily snap shot of the actions M Verify if audit
taken on all the MVAs included in the fleet trail is
report. maintained for
actions
performed on a
vehicle
FR15 BR06 Generate notifications. Method of delivery M Verify

17
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
and frequency to be determined by notifications are
business. A complete list of notifications is received for
in Appendix B. each condition
FR16 BR03 Changes to Inventory process: M Verify if
1. Inventory should be performed for inventory
every check-in and Readyline date/time is
transaction. Exclusions are auto void, updated after
[CLIENT BRAND 1] now, delayed check- each a check in
in and contract exchange. and ready line
transaction.
2. If a car is scanned by a hand held
Verify
device - Rover, MDMS app, Quintiq
indicators on
app - for a check-in or Readyline or
MDMS.
inventory transaction, indicate if the
MVA was manually entered
3. Build in MDMS and SMWR portal
indicators associated with the
inventory date  – source system
(Wizard/GUI/Pronto/Zelda or hand
held app), source transaction
(Readyline, check-in, inventory) and if
MVA was manually entered.
FR17 BR05, Build a real-time fleet overdue report M Verify the
BR08, BR07 similar to the VRS 03 report and display results of the
the below information report.
1. MVA
2. License Plate Enter notes for
3. Movement a vehicle and
4. Checkout date verify it is
5. Due date displayed with
6. Due Station the timestamp
7. Wiz St
8. Model Verify audit trail
9. MOP type is maintained
10. Con Ext for all actions
11. Owner taken
12. Processing Notes

Hyperlink should be available to view the


details of vehicle from the report
Following action can be taken from the
report
1. Update RA remarks
18
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
2. No-Charge / Void the rental

Maintain an audit trail of the actions taken


on all the MVAs included in this report
A complete list of rules is in Appendix E.
FR18 BR03, Build an Open Movement Report similar to M Verify the
BR03, the VRS 04 report which will be updated results of the
BR05, once a day with the below information report.
BR08, BR07 a. MVA
b. License Plate Enter notes for
c. Checkout Station a vehicle and
d. Checkout date time verify it is
e. Check-in station displayed with
f. Check-in date time the timestamp
g. Movement
h. Miles Verify audit trail
i. Processing Notes (real time) is maintained
for all actions
Processing Notes has to be reflected real- taken
time in the report
Hyperlink should be available to view the
details of vehicle from the report
Following action can be taken from the
report
a. Update RA remarks
b. No-Charge / Void the rental

Maintain an audit trail of the actions taken


on all the MVAs included in this report

A complete list of rules is in Appendix E.


Payment Card Decline Report Requirements
FR19 BR01 Build a daily payment card decline view M Verify the
that is similar to the present day KVC card content of this
decline report in Infopac. Provide the report matches
ability to pull up the report by checkout with the KVC
date, location and brand. report
FR20 BR01 Display the following information on the M Verify all data
report for all payment card declines elements on
1. Rental Agreement Number the report
2. Payment Card Type (CM, CX etc.) and
Last 4 Digits of Card
19
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
3. Payment Card Expiry Date
4. Agent ID
5. Employee Name (Included in Workday
feed)
6. Requested Amount
7. Authorized Amount
8. Declined Transaction Date / Time
9. Authorization Code
10. Terminal ID
11. Transaction
12. Reason
13. Status
14. Action Taken
15. Processing Notes
FR21 BR03 Following information about the contract M Verify all data
should be available for review upon elements on
clicking/selecting the RA number displayed the report
on the report:
1. Rental Agreement Number
2. Reservation Number
3. Booking Source, Date and Time
4. Quoted Rate Detail
5. AWD Display
6. Customer Name
7. Customer Contact Phone Number
8. MVA Number
9. Agent ID
10. Payment Card Number (Masked) and
Expiry Date
11. Check-in Date and Station
12. Security Information on Rental
13. Previous RA display for reopen rentals
FR22 BR02, Decline transactions that meet the M Verify that all
BR03, BR04 following criteria do not require user declined
review and should be marked as “System transactions
Closed” : that satisfy the
criteria are

20
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
1. If manual authorization is checked marked as
against merchant services. System Closed
2. If RA has only one entry on the report
and Requested Amount matches the
Authorized Amount
3. If the difference in amount Request
Amount and Authorized Amount
matches the difference in T&M
(excluding upsell) from the first
attempt
4. If FAN is the first attempt with
subsequent attempt by preferred
agent and Authorization Amount for
both RA entries is the same
5. If first card attempted is Debit card
with no CID and second card presented
and authorized is credit card and
authorization amount difference is
equal to additional authorization
amount required for debit card
6. If difference between authorization
obtained and authorization needed is
less than + or – 10
FR23 BR02, Decline transactions that do not meet the M Verify that all
BR03, BR04 criteria for a “system closed” situation declined
should be marked open for user review. transactions
Provide the ability to enter processing that satisfy the
notes against the transaction, changing criteria are
status to in progress or closed (after marked for
appropriate action has been taken offline). review
1. If required amount is not the same as
authorized amount, mark RA entry as
"Possible Phishing"
2. If there are multiple declines on a card
for different Agent IDs and an hour or
more between attempts, mark all
entries as "Possible Customer
Phishing"
3. If there are multiple declined entries
for a debit card, mark all entries as
"Improper Debit Card Use"
21
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
FR24 BR07 Maintain a periodic audit trail for M Verify audit trail
contracts that were actioned by a user. is maintained
Auditors should be able view these for all actions
reports. taken on a
declined
transaction
FR25 BR04 Provide the ability to upload policy C Verify user is
documentation and to send it to an agent able to email
in the event of a policy violation. Maintain uploaded policy
a record of repeated defaulters. documentation.
Exception Report Requirements
FR26 BR01 Build a daily Exception Report that is M Verify the
similar to the present day WRSCEX report. content of this
report matches
with WRS
screen
FR27 BR01 Include 203 adjustments of the previous M Verify that all
day in the Exception report 203
adjustments for
the location
selected appear
on the report
FR28 BR02, Make recommendation based on contract M Verify the
BR03, BR04 parameters. A complete list of application
recommendations is in Appendix C. displays correct
recommendatio
n for the
exceptions that
satisfy the rule
criteria
Common Requirements for all Reports
FR29 BR08, BR09 Provide the ability to extract reports for M Verify report
for the correct
1. A single location/brand a user has
location and
access to
brands is
2. All locations/brands a user has access displayed
to
3. A combination of locations/brands a
user has access.
Note: A location can be a rental station,
district, fleet owner, region or division
Detailed Reports will not be provided for

22
[CLIENT]: Business Definition Document (BDD)
Functional Business Detailed Description MoSCoW Criteria For
Requirement Requireme Evaluation (or
# nt(s) Acceptance
Covered Criteria)
Hierarchy locations. Instead Summary
information can be provided for Hierarchy
locations.
FR30 BR07 Provide the ability for Internal Auditor to M Verify weekly
view weekly a snapshot of all reports and snapshot of all
manager activity on reports for the last 6 reports are
months. available for the
last 6 months

23
[CLIENT]: Business Definition Document (BDD)
6. Non Functional Requirements
6.1. Performance
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR01 Retrieval of basic Response time for retrieval M Response time
information of basic information for should be as
fleet, contracts deemed
appropriate by
business

NFR02 Recommendations and Response time for M Response time


Checklists recommendations and should be as
checklist tasks for all SMWR deemed
reports appropriate by
business

NFR03 Front end processing Front end processing on M Portal front end
EMEA VDI terminals should not have
high CPU usage

6.2. Security
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR04 Access to SMWR The application should only M Users without the
application be available to users who necessary access
are logged into [CLIENT] should not be able
network with valid to log in.
credentials.
NFR05 Access to SMWR reports The application should M Users should not be
display reports only for able to view
locations and brands the reports their sign-
user’s sign-on has access to on does not have
access to
NFR06 Customer sensitive data Payment card information M Users should be
must never be displayed or able to view only
stored in clear text the last 4 digits of
the payment card
number
NFR07 Inactive user Lock portal when user is M Lock the portal if
inactive user is inactive for
more than 15
minutes
NFR08 Access to web services Web service will be secured M Only authorized
using client authentication applications will

24
[CLIENT]: Business Definition Document (BDD)
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
methods with valid have access to the
credentials. web service

6.3. Capacity
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR09 Data Retention Retention for report data M Data will be
and audit trail retained for 6
months only

6.4. Availability
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR10 Hours of operation The SMWR application and M Available 24/7
supporting databases
available 24 hours a day / 7
days a week with the
exception of planned down
time as agreed with the
business owner

6.5. Reliability
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR11 Disaster recovery Disaster recovery team M SMWR application
(PM: Peter Bonacasa) should be include
in Disaster
Recovery

6.6. Compliance
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
NFR12 Sox Compliancy SMWR application will meet M Project should pass
☒ Is this project in requirements set out by health check and
scope for SOx? SOX Security requirements. SOx audit

NFR13 PCI Compliancy Not Applicable, SMWR


☐Does project require application will only display

25
[CLIENT]: Business Definition Document (BDD)
NFR Subject Description MoSCoW Acceptance Criteria
# (identify Business Owners if
required)
storage, display, last 4 digits of the payment
transmission or card (credit or debit card)
processing of credit card
data?
NFR14 PII Compliancy Yes M SMWR application
☒ Does project require will display name,
storage, contact information
display, transmission or for renters and
processing of PII data? operational
managers which
can be viewed only
by authorized users

26
[CLIENT]: Business Definition Document (BDD)
7. C.R.A.I.D

7.1. Constraints
# Constraint Stakeholder Area
Change in business requirements or project scope will impact the cost
1 Business
and timeline.
Completion and signoff on the BDD, ADD and TDD before portal
2 Business, IT
development commences.

7.2. Risks
# Risk Stakeholder Area
1 Delay in availability of infrastructure and licenses needed for the IT Architecture, IT
SMWR portal will result in schedule and cost overrun Project Manager,
Business
2 Non-availability of key IT resources will result in schedule slippage. IT

7.3. Assumptions
# Assumption Stakeholder Area
1 Any change in the scope of engagement after the sign-off would be IT, Business
treated as a Change Request and addressed through the Change
Management Process.
2 SMWR portal for EMEA will be web based, no install required on IT, Business
rental station equipment
3 Following requirements have been excluded from estimation and will IT, Business
not be delivered as they are either not feasible or not recommended
1. FR05 – Provide ability to add access to employees and give
temporary full access to an employee
2. FR10 – Fleet report recommendations for possible mini
lease/extended rental, possible auto void reopen, possible
incomplete rental match and manual rental agreement not
entered
3. FR21FR22 - Check manual authorization against merchant services
4. FR24FR25 – Maintain a record of repeated defaulters for payment
card decline report
4 FR18- Open vehicle movement report will be a daily feed instead of IT, Business
real time but the processing notes entered will be real time.

7.4. Issues
# Assumption Stakeholder Area
1 No issues reported at this time

27
[CLIENT]: Business Definition Document (BDD)
7.5. Dependencies
# Dependency Stakeholder Area
1 Resource availability from all participating teams IT, Business
2 Timely completion of TDD and ADD IT
3 Prioritization of project requirements Business
4 Signoff on user acceptance testing before production deployment IT, Business
5 Timely availability of infrastructure and licenses IT Architecture
6 Delivery of Wizard GUI for EMEA Corporate Locations project to scale IT, Business
up performance of rental station VDI in EMEA
7 Appropriate communication and training before portal rollout Business – L&D

28
[CLIENT]: Business Definition Document (BDD)
Appendix A

Fleet Checklist and Recommendations


1. Display current status and last inventory location of the vehicle. Look for activity since the inventory
was entered in Wizard.
2. Perform a vehicle trace to check for discrepancies in the movement record
3. Contact the last renter to determine status of rental (was vehicle returned, breakdown, tow etc.). (Pull
up 203/806 screen (with SEC) and allow to see Phone number and customer’s email within portal)
4. Verify movements and ping in Zipcar system https://members.zipcar.com/en-CA/register/
5. Confirm no vehicle exchange was completed
i. [CLIENT BRAND 1] ____ [CLIENT BRAND 2] ____ [CLIENT BRAND 3]_______
6. Check for partial contracts (is the 404IR / incomplete rental report worked daily).
i. [CLIENT BRAND 1] ____ [CLIENT BRAND 2] ____ [CLIENT BRAND 3]_______
7. Check ERS / breakdown log / open two tickets, email ERS Help and maintain email chain
8. Check with MDMS
9. Contact the last inventory location. (Wizard- Show location and phone number 405 screen | Manual
process to call)
10. Verify title is still on file with VAB/check with Fleet for turnback status. (DMP portal https://bpm.
[CLIENT].com/iDMPortal/iDMPortal.html)
11. Provide the ability to locate missing vehicle from the Damager Manager Portal and indicate the
following possibilities
a. ERS issue (If ERS issue, provide ability to email ERS Help Desk)
b. ERO open
c. Accident
d. Impounds
12. Vehicle Trace
a. If a movement is open in the trace before the last movement was closed, make a
recommendation that it is a possible hidden movement and provide the ability to open hidden
movement NRT, close RA, Void RA or No charge RA.
b. Indicate if an MVA was modified via 203 modify or 206 vehicle exchange
13. If the registration date has expired, provide the ability to send the vehicle information to Registration
Renewal. The email should include the address of the manager (which would be updated through
profile settings page)
14. Possible Mini Lease/Extended Rental not re-open
a. Check if last movement is a Mini Lease or Extended Rental or last open movement is the same
customers name as last closed movement which was a Mini Lease or Extended rental
b. If /FOR SRT(Y or B)MINI screen shows that end date was greater than current day
c. Make recommendation that it is possible Mini Lease or Extended needs to be opened
15. Possible Auto void reopen
a. On trace previous RA was auto voided
b. Car on hand
c. scanned by 408 at Gate Exit not attached to a RA for any brand
d. Connected Car has broken the GEO Fence and have last reading
e. Show 203 screen of last customer
f. Indicate as recommendation do you want to re-open. Have portal reopen create new RA when
click yes

29
[CLIENT]: Business Definition Document (BDD)
16. Possible Incomplete Rental Match
a. Look at IRs on the 404 screen for same amount of days car was idle from last revenue movement
at location. Show key indicators on rental agreement
Date and time out
Car group reserved
Day of week
b. Match 408 scans to an MVA showing it left lot with NO rental agreement attached
c. Connected Car has broken the GEO Fence and have last reading with mileage not matching
17. Connected Car Data recommends car maybe on a Rental Agreement, MFC, Licensee rental one way not
on Wizard, etc.
a. Received connected car data at midnight from data warehouse showing off lot, no movement
and mileage discrepancy from 01/29 report
18. Manual Rental Agreement not entered is recommended as possible scenario for a missing vehicle(s)
a. Verify RA range is loaded in Wizard on /FOR P613
b. When that range has a missing number or range to highlight that to
c. Take into account any RA ranges that were removed from the /FOR WZTRALOG screen
d. State Date and time of ranges and between ranges to find a correlation on time used.
19. If a location is using shuttling solutions the movements within these systems need to be visible within
SMWR.

30
[CLIENT]: Business Definition Document (BDD)
Appendix B

Fleet Notification Scenarios

1. If a location has not performed inventory by 11.59 pm local time


Notify: RM / CM / DM

2. If NRT is overdue by 24 hours


Notify: City manager, district manager and employee who the NRT is assigned to

3. If NRT is overdue by 24 hours and system identifies an inventory


Notify: Location manager to close the NRT

4. If an NRT is created to a vendor (oil change, service, body shop, detail)


Notify: Location manager after the vehicle is overdue

5. If RA is open for 60+ days


Notify: Loss prevention team

6. IF vehicle was considered a Red Dot  (7 days idle with no revenue | Not inventoried in 7 days) OR
Missing from Control in Wizard and is inventoried at another location OR shows up on a revenue
movement to
Notify: Location managers where vehicle was reported originally as a Missing From Control OR was
listed on a particular location’s idle report. 
Delivery Method: Portal inbox or email

31
[CLIENT]: Business Definition Document (BDD)
Appendix C

Exception Report Logic

1. No Charge
a. IF Reason Code = "SY/" THEN match new RA number after "SY/" to 203
IF name of cancelled RA matches name of active 203 RA THEN Leave off report
ELSE Prompt message for "Manager Review"

b. IF Reason Code = "PE" THEN check to see if cancelled RA Preferred Renter


IF Preferred Rental THEN display remarks for Manager Review
ELSE Prompt message "Manager Review: Non-Preferred Renter"

c. IF Reason Code = "RC" THEN Display remarks AND check 502-screen to see if rental honored
IF Rental honoured THEN Display new RA
ELSE Prompt message for "Manager Review"

d. IF Reason Code = "MB" THEN link MVA(s) to ERO System to match any RO made for MVA after C/I
date; display link to applicable RO(s). *NICE TO HAVE REQUIREMENT*

2. Voids
a. IF Voided-RA's reservation is re-honored THEN Display remarks
IF Rental honoured THEN Display new RA
ELSE Prompt message for "Manager Review"

3. Walk-up / No Show
a. Need the ability to check across [CLIENT BRAND 1], [CLIENT BRAND 2] & [CLIENT BRAND 3].
Need to have system match names better; too many obvious “non-deviations” making it to the
report.
IF WIZARD finds a match THEN
IF LOR of 203 = LOR of 502THEN
IF ILC Field of 203 = ILC of 502 THEN
IF Car Class of 203 = EQP of 502 THEN Populate RA on the report along
with RMK Field
ELSE Do not populate RA onto the report

4. Manual Rates
a. IF Reason Code = “RD” THEN match T&M of 203 against T&M of 502
IF 203 = 502 THEN Do not populate on the report
ELSE Prompt “Manual Rate Not Matching Reservation Rate”

b. IF Reason Code = “UP” THEN match T&M of 203 against T&M of 502
IF 203 > 502 THEN Prompt “Verify Upsell With Signature Copy”
*NICE TO HAVE REQUIREMENT: A link that is clickable to print/view signature copy*
ELSE Prompt “Invalid Reason Code/Manager Review Needed”

32
[CLIENT]: Business Definition Document (BDD)
c. IF Reason Code = “MC” THEN match the “HRY/DLY/WKY” of 203 against “HRY/DLY/WKY” of 502
IF 203 = 502 THEN
IF MLG of 502 > 0 THEN Do not populate of the report
ELSE Prompt “Invalid Reason Code/Manager Review Needed”
ELSE Prompt “No Mileage Cap/Manager Review Needed

d. IF Reason Code = "MA" THEN Link ID given for Rate Default to Agent ID who entered the Manual
Rate AND WIZARD verify ID number a Manager
IF all matches THEN Do Not Populate of the Report
ELSE Prompt “Manual Rate Not Approved By Manager/Need Review”
*NICE TO HAVE REQUIREMENT*
In meantime, Reason Code “MA” should follow same logic as “RD” Reason Code

5. Connected Cars
a. IF FLO =/= “G8” THEN
IF TCU DEVIC GAS OUT < TCU DEVIC GAS IN THEN Connected Car adjustment; Do not
populate on report
ELSE Display the RA on the report with the amount of fuel adjusted from the F/O field
along with anything in remarks field

6. Adjustment over #100


a. IF F/O field + ADJ field => 100 THEN
IF ADJ = Hourly Rate THEN
IF STA field =/= ILC field THEN
IF Amount Due = Quoted Rate from 502-screen THEN Do not populate on
report to be reconciled
ELSE Prompt “One-way Adjustment Made/MGR Verification” and display
RMK field
ELSE Prompt “Over $100 Adjustment/MRG Verification” and display RMK field
ELSE IF ADJ = Daily Rate THEN
IF STA field =/= ILC field THEN
IF Amount Due = Quoted Rate from 502-screen THEN Do not populate on report
to be reconciled
ELSE Prompt “One-way Adjustment Made/MGR Verification” and display RMK
field
ELSE Prompt “Over $100 Adjustment/MRG Verification” and display RMK field
ELSE Prompt “Over $100 Adjustment/MRG Verification” and display RMK field

7. Adjustment matching CSI


a. IF ADJ > 0 THEN
IF ADJ = UPSL AMT THEN Prompt “Adjustment Matching Upsell” and display RMK field
ELSE IF WPP field =/= “NNNN” THEN Need to scrape for which products are indicated
with a “Y” or “P”, multiply the product’s price(s) individually and in all combinations by
the LOR to determine if any of the products match the ADJ field
IF ADJ = Any of the products THEN “Adjustment Matching Coverage(s)” and display which
coverage(s) are matching the adjustment and display RMK field

33
[CLIENT]: Business Definition Document (BDD)
ELSE IF ADJ = ACC sold THEN Prompt “Adjustment Matching Counter Product” and display
RMK field
ELSE IF ADJ = BFL field THEN Prompt “Adjustment Matching Fuel Proceeds” and display
RMK field
END IF

b. IF F/O > 0 THEN


IF ADJ = UPSL AMT THEN Prompt “Adjustment Matching Upsell” and display RMK field
ELSE IF WPP field =/= “NNNN” THEN Need to scrape for which products are indicated
with a “Y” or “P”, multiply the product’s price(s) individually and in all combinations by
the LOR to determine if any of the products match the ADJ field
IF ADJ = Any of the products THEN “Adjustment Matching Coverage(s)” and
display which coverage(s) are matching the adjustment and display RMK field
ELSE IF ADJ = ACC sold THEN Prompt “Adjustment Matching Counter Product” and
display RMK field
ELSE IF ADJ = BFL field THEN Prompt “Adjustment Matching Fuel Proceeds” and display
RMK field
END IF

8. Adjustment matching coupon


a. IF ADJ > 0 THEN
IF CPN field has a value in it
IF CPN field value = CPN field value on 502 screen THEN Do not populate on
report to be reconciled
ELSE Prompt “No Coupon found in RES” and display RMK field.

9. Fuel adjustment
a. *Run Connected Car Logic to Filter Those Out First*
IF F/O field has value in it
IF F/O = “D0/G “
IF Value after “D0/G “ = BFL field THEN Prompt “Improper Fuel Adjustment” and
display RMK field
ELSE Prompt “Verify Fuel Adjustment” and display RMK field
ELSE Prompt “On Road Expense Adjustment Made” display value of the adjustment and
display RMK field

34
[CLIENT]: Business Definition Document (BDD)
Appendix D

Proposed Phase Report


01 – Inactive Vehicle
29 – Shared Fleet Inactive Vehicle Report
03 – Overdue Report
MVP Phase 1 04 – Local Open Movement Report
(Detailed requirements included as part
21 – Unaccounted Vehicle Report
of BDD)
Credit Card Decline (KVC705)
Debit Card Decline with Agent Override (KVC709)
WRS reports - WRSCEX and WRSCEXD
Garmin Unaccounted
Tablet Unaccounted
P406 Coupon Tapes
Surprise Cash Audit (406)
Future Phase Partial Rental Agreement P404 Report
Zipcar Toggle Cards#
Minilease SRTMINI Report
Manual Rental Agreement Log copy
Voided Manual Rental Agreement Report
17 - Missing Miles
Out of Scope
Mini-lease files reviewed

35
[CLIENT]: Business Definition Document (BDD)
Appendix E

Rules for VRS03 Overdue Vehicle Report

The following rules will apply for generating the VRS03 Overdue Vehicle report

1) A vehicle will appear on this report when it’s more than three (3) days overdue on non-cash rentals and one
(1) day overdue on Cash rentals.

2) Any missing or sold vehicles should be excluded from this report

3) Any vehicle which has rental that has been checked out for more than 45 days.

4) Include the overdue previous movement of a vehicle only if the current vehicle is NRT and is closed.

Sample VRS03 report

36
[CLIENT]: Business Definition Document (BDD)
VRS04 Open movement report

Sample VRS04 report

37

You might also like