Customer Care Functional

Document
Version 1.0
CDAC -Noida

DATE 13/03/2019
CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

AUTHORS

Name Role Department

DOCUMENT HISTORY
Date Version Document Revision Description Document Author

APPROVALS
Approval Approved
Approver Role Approver
Date Version

pg. 2
 CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

Table of Contents

1. Introduction................................................................................................................................. 4
1.1 Purpose of the document..................................................................................................... 4
1.2 Project Scope ....................................................................................................................... 4
1.3 Scope of the document ........................................................................................................ 4
1.4 Related documents .............................................................................................................. 4
1.5 Terms/Acronyms and Definitions .........................................Error! Bookmark not defined.
1.6 Risks and Assumptions ...................................................................................................... 4
2. System/ Solution Overview .......................................................................................................... 5
2.1 Context Diagram/ Interface Diagram/ Data Flow Diagram, Application Screen Flow,
Sitemap, Process Flow ................................................................................................................. 5
2.2 System Actors ..................................................................................................................... 5
2.3 Dependencies and Change Impacts....................................................................................... 6
3. Functional Specifications ............................................................................................................. 6
3.1 <Title> .......................................................................................Error! Bookmark not defined.
4. System Configurations ....................................................................Error! Bookmark not defined.
5. Other System Requirements/ Non-Functional Requirements .........Error! Bookmark not defined.
6. Reporting Requirements .................................................................Error! Bookmark not defined.
7. Integration Requirements ...............................................................Error! Bookmark not defined.
7.1 Exception Handling/ Error Reporting.......................................Error! Bookmark not defined.
8. Data Migration/ Conversion Requirements ....................................Error! Bookmark not defined.
8.1 Data Conversion Strategy ........................................................Error! Bookmark not defined.
8.2 Data Conversion Preparation ..................................................Error! Bookmark not defined.
8.3 Data Conversion Specifications ...............................................Error! Bookmark not defined.
9. References ......................................................................................Error! Bookmark not defined.
10. Open Issues.................................................................................Error! Bookmark not defined.
Appendix ................................................................................................Error! Bookmark not defined.

pg. 3
 CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

1. Introduction
This document contains the information regarding customer care module. The document is
meant to define the functional behaviour of ‘Sweekaar Customer Care System’.

1.1 Purpose of the document

The purpose of the document is to provide a working behaviour of “Customer Care System
for AFCVT”. Based on this document software working functionality of the system would be
developed.

1.2 Project Scope

Scope of this document is limited to

I. Give detailed work flow of the module architecture and a description of how
request coming from terminal is handled by the Customer Care module and
response is send back to terminal.
II. In it also mention how Customer Care module interacting with Terminal using a
diagram.

1.3 Scope of the document

Scope of this document is limited to

I. Give detailed work flow of the module architecture and a description of how
request coming from terminal is handled by the Customer Care module and
response is send back to terminal.
II. In it also mention how Customer Care module interacting with Terminal using a
diagram.

1.4 References
1. DMRC meeting’s input regarding to customer care.
2. System Requirement Specification version 1.0.

1.5 Assumptions and Constraints

I. The terminal can be changed as per further scope of add-on features or third-
party software integration.
II. The different state/mode of the device can be changed as per user flexibility and
comfort without overriding fundamental operation.
III. The input interface and the visual interface can be modified as per further inputs.

pg. 4
 CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

2. System/ Solution Overview

The information contained in this section applies to SWEEKAAR Customer Care System Version 1.0.
Customer Care System is a single, unified Swing platform that offers the ability to handle the issue
related to the traveller in day today life, it is able to directly solve their issue and took appropriate
action according to their related issue.

2.1 Process Flow Diagram of Customer Care System

pg. 5
 CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

2.2 System Actors

2.2.1 User Roles and Responsibilities / Authority Requirements

Frequency Security/Access,
User/Role Example Additional Notes
of Use Features Used
Operator Person who Frequent Username and password
operate User are providing for
customer care. individual operator.

Admin Person who Not Username and password

take care Frequent are providing for admin
maintenance. user login.

2.3 Dependencies and Change Impacts

2.3.1 System Dependencies
1.1 User Interface Requirements:
I. Operating machine must have jre 7or above version install in it.
II. Database (postgres) must be installed in it.
1.2 Hardware / Software Requirements:
Hardware:
I. n/w cable
II. Lan connectivity
Computer:
I. ram: 4 GB DDR3
II. processor: i5 or above
III. Hard Disk: 500 GB or above
1.3 Operational Requirements:

128 byte service data must be sending from the terminal in order to customer care start its work

2.3.2 Change Impacts

<List and identify existing systems that will be impacted by the implementation of the proposed
solution.>

3. Functional Specifications
To communicate Customer Care application with L3 there will be connectivity through terminal. So
first will check that L3 is connected to the Customer care application. If L3 and Customer care
application connected then Customer care application will get 128 byte service data and/or balance(if
type- not pass i.e. normal) from the L3, on the bases of that customer care will took the decision

pg. 6
 CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

3.1 Customer Care User Interface

In Customer Care UI, Operator can see the last 4 log entries with movement type, and date time
detail. Here operator can update the movement type and do the dispute settlement.

(See the below diagram A.1).

Get Details

Log1 Log2

Dispute
Settlement Log3 Log3

Clear Transaction Details

Log No. St. Name Date & Time Mov. Type

Exit

A.1 Customer care user interface

3.2 Procedure
Below it is mention how conversation is done b/w terminal and Customer care.

Parameter Parameter Input/output Processing Summary

Type

Data Service Data, Input 128-byte service data Service Data

customer is received to receive from
structure for customer care. by terminal and
128-byte data taking the Data response send
structure and after back from
process (C.C) customer care.
Service Data updated 128-byte
Service Data Output service data structure
will be send to
terminal.

pg. 7
 CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

3.3 Communication manages between Customer Care and Terminal:

Transit data is generated & stored inside the card (as a transit log), when card interacts with the
terminal. Transit Data will be change according to the travel. Transit data may be changed for
transaction processing. 128 Byte service data will be parsed and fill into the structure, Operator
pass and operator info. This function accepts input type parameter byte[] which is the 128 byte
data provided by L3.Data primarily contains meaningful information log of each tap or Card-
Terminal interaction.

3.4 Types of Request:

GenMsg_REQ:

GenMsg_REQ (Key) (128 byte) (value) is used to get request from the terminal.

GenMsg_RESP:

GenMsg_RESP (Key) (128 byte) (value) is used to get response from Customer Care to the
terminal After Successful updating of the log.

GenMsg_ERR:

GenMsg_ERR is used to send response from Customer Care to terminal if the card is somehow
damage

I. INVLD_CRD: Invalid Card will be sent when there is a card which is not belongs to the
DMRC or N/W.
II. NO_CHG: This message will be sent when there is no change in the status or log.

GenMsg_ACK:

GenMsg_ACk after every successful transaction cycle will be completed by receiving response
at Customer Care.

pg. 8
 CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

3.5 Request handling schematic diagram

While card is damage:

C.C Terminal

(INVLD_ CRD)

GenMsg _ERR

FR 0.1

While penalty:

C.C Terminal
GenMsg_REQ

(128 byte)

(Update)

GenMsg_RESP

(128 byte data) GenMsg_ACK

FR 0.2

pg. 9
 CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

Valid card With No Change:

C.C Terminal
GenMsg_REQ

(128 byte)

GenMsg_ERR

(NO_CHG)

FR 0.3

3.6 Log Generation &Types of penalty Deduction:

Log will be generated by using the FIFO algorithm.

II. Double Entry
III. Double Exit
IV. Time Based

➢ New Card (Log Creation):

For every new card log will be generated using FIFO algorithm.

pg. 10
CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

(FIFO)

FR.1.0

➢ Complete four log entries in the Card:

Entry Exit

Entry Exit

Case 1: Double Entry

When a traveler tries to do the ENTRY again and the previous log is of ENTRY

Entry Exit

Entry

FR 1.1
➢ Log will be updated by completing the cycle & deducting the amount as per the fare rule.

Entry Exit

Entry Exit

Case 2: Double Exit

When a traveller tries to do the EXIT again and the previous log is of EXIT.
➢ EXIT Log don’t right on card

pg. 11
CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

Entry Exit

FR 1.2
➢ Customer care will put an ENTERY log in the card

Entry Exit

Entry

Case 3: Time based penalty

When the traveller exceed its time limit

Entry Exit

Entry

FR 1.3
➢ Entry station time will check and then penalty is deducted, now current
time will be updated in the card.

Entry Exit

Entry

2.4 Functional Requirements:

pg. 12
CUSTOMER CARE FUNCTIONAL DOCUMENT 03/14/2019

Below the functional requirements for each functional for the system to work properly

Section/
Requirement ID Requirement Definition
FR1.0. The card must be issued by the issuer(bank) and must have a min balance.
FR1.1 The traveler must be standing on entry gate and not able to do the entry.
FR1.2 The traveler must be standing on exit gate and not able to exit.
FR1.3 The system shall work when traveler must be standing on exit gate & not able
to exit.

pg. 13