1269 - Annex 2 - Requirement Specifications (SRS) of E-Revenue License Project

Annex 2
Detailed Software
Requirements
Specification (DSRS)
and Use Case Design
for
e-RL Project

. . . . . . . . . .
ICTA-eRL-DSRS-Use-Cases-1.6

Table of Contents

1 Introduction ...................................................................................................... 1
1.1 Purpose ..................................................................................................... 1
1.2 Summary ................................................................................................... 1
1.3 Client Overview ......................................................................................... 1
1.4 Project Overview ....................................................................................... 2
1.5 Definitions, Acronyms and Terminology .................................................... 2
1.6 References ................................................................................................ 3
2 Project Scope and Impact ............................................................................... 4
2.1 Scope Inclusions and Exclusions .............................................................. 5
2.2 Stakeholders and Requirements Elicitation ............................................... 9
2.3 Impact on Other Systems ........................................................................ 10
2.3.1 System Integration............................................................................ 10
2.3.2 External System Dependencies ....................................................... 10
2.3.3 Deployment Dependencies .............................................................. 11
2.4 Key Assumptions ..................................................................................... 12
3 Domain and Business Logic ......................................................................... 14
3.1 High Level Use-Case Diagram ................................................................ 14
3.2 Envisioned Business Process .................................................................. 15
3.3 Entity Relationship Diagram .................................................................... 16
3.4 Licence Payment Logic............................................................................ 18
3.5 Mandatory Requirements for Revenue Licence Issuance ....................... 22
3.5.1 Vehicle Emissions Testing Certificate ............................................... 22
3.5.2 Insurance Certificate ......................................................................... 22
3.5.3 Route Permit and Fitness Certificate ................................................ 22
3.6 Blacklisting of Vehicles ............................................................................ 23
3.7 User Roles ............................................................................................... 25
3.8 High Level Business Process .................................................................. 26
3.8.1 Normal Issuance Process ................................................................. 26
3.8.2 Administrative Tasks ........................................................................ 29
3.9 Licence State Transition .......................................................................... 31
4 Functional Requirements .............................................................................. 33
4.1 e-RL Application Login............................................................................. 35
4.2 Normal User Dashboard .......................................................................... 39
4.3 Revenue Licence Issuance Scenarios ..................................................... 42
4.3.1 Normal Licence Issuance ................................................................. 42
4.3.2 Issuance of Licences for Vehicles with Converted Engines .............. 49
4.3.3 Issuance of Non-user Certificates..................................................... 51
4.4 Payment of Arrears .................................................................................. 53
4.5 Licence Issuance for Fleets of Vehicles................................................... 55
4.5.1 Issuing Quotations ............................................................................ 55

4.5.2 Issuance of Licences for Quotation .................................................. 58
4.6 Correction of Past Revenue Licence Information .................................... 61
4.6.1 Edit / Delete Existing Revenue Licence records ............................... 61
4.6.2 Add New Revenue Licence record ................................................... 63
4.7 Processing Ineligible Revenue Licence Applications ............................... 65
4.8 Edit Vehicle / Owner Information ............................................................. 68
4.9 Managing Transitions .............................................................................. 71
4.9.1 Categorising Vehicles as Free Licenced .......................................... 71
4.9.2 Categorising Vehicles as Non-user Licenced ................................... 73
4.9.3 Print Loose Slip ................................................................................ 75
4.9.4 Blacklisting of Vehicles ..................................................................... 77
4.10 Vehicle Activity Log ................................................................................. 80
4.11 Department of Motor Traffic Update Module ............................................ 82
4.12 Counter Configuration.............................................................................. 84
4.13 Holiday Configuration .............................................................................. 87
4.14 Adding Reference Data ........................................................................... 90
4.15 User Account Management ..................................................................... 94
4.15.1 Create / Edit / Delete User Account .................................................. 94
4.15.2 User Account Password Modification ............................................... 98
4.16 Reporting ............................................................................................... 100
4.17 Non-Western Province DS Data Upload ................................................ 104
4.18 Staff Lookup Portlet Scenarios .............................................................. 106
4.19 Country Portal eCitizen Scenarios ......................................................... 111
4.19.1 Revenue Licence Renewal via e-RL portlet .................................... 111
4.19.2 Issue RL for e-RL Portlet Requests ................................................ 118
4.20 Mobile Lookup Scenario ........................................................................ 120
4.21 Canonical Database .............................................................................. 123
4.22 Data Migration ....................................................................................... 124
4.23 Synchronisation of Databases ............................................................... 126
5 Non-functional Requirements ..................................................................... 128
5.1 Performance Requirements ................................................................... 128
5.1.1 e-RL Application ............................................................................. 128
5.1.2 e-RL Portlet .................................................................................... 128
5.2 Compatibility Requirements ................................................................... 129
5.2.1 Machines of eCitizen ...................................................................... 129
5.2.2 DS / PDMT Counter Clients ............................................................ 129
5.2.3 DS Superuser Machines ................................................................. 130
5.2.4 WPDMT Superuser Machines ........................................................ 130
5.2.5 DS Office Server............................................................................. 130
5.2.6 WPDMT Office Server .................................................................... 131
5.3 Usability Requirements .......................................................................... 132
5.4 Internationalisation and Localisation Support ........................................ 132
5.5 Security Requirements .......................................................................... 134
5.5.1 Data Access for WPDMT Users ..................................................... 134
5.5.2 Data Access for DS Users, eCitizens and Police ........................... 135
5.5.3 Action vs. Access Matrix for Business Process .............................. 136

5.5.4 Action vs. Access Matrix for Administrative Functions .................... 137
5.5.5 Data Storage Security .................................................................... 137
5.5.6 Data Communication Security ........................................................ 138
5.6 Scalability .............................................................................................. 138
5.7 Maintenance Requirements ................................................................... 139
5.8 Documentation Requirements ................... Error! Bookmark not defined.
5.9 Applicable Standards ............................................................................. 139
5.10 Intellectual Property Requirements ........................................................ 140
5.10.1 Copyright Requirements ................................................................. 140
5.10.2 Licensing Requirements ................................................................. 140
5.10.3 3
rd
Party Software Utilisation .......................................................... 140
6 Functionality Not Required ......................................................................... 141
7 Clarifications and Issues ............................................................................. 142
7.1 Closed Issues and Clarifications ............................................................ 142
8 Further Enhancements ................................................................................ 146
8.1 Superuser Dashboard............................................................................ 146
8.2 Export of Synchronisation Data ............................................................. 148
8.3 Centralized Reporting ............................................................................ 150
8.4 Setup Mobile Alerts for e-RL Portlet ...................................................... 151
8.5 Integration with Display Panel ............................................................... 152
Appendix 1 Traceability of User Stories to Use Cases ................................ 153
Appendix 2 List of Functional and Non-functional Requirements ............. 155
Appendix 3 List of User Stories ..................................................................... 157
Appendix 4 Revenue Licence Rates with effect from 01/01/2008 ............... 164
Appendix 5 Revenue Licence Rates before 01/01/2008 ............................... 167
Appendix 6 Changes to Requirements ......................................................... 170

List of Figures

Figure 1 - Scope of Functionality .......................................................................... 5
Figure 2 - High level Use Case Analysis ............................................................. 14
Figure 3 - e-RL Business Process ...................................................................... 15
Figure 4 - Entity-Relationship diagram ................................................................ 16
Figure 5 - Calculation of Normal Revenue Licence Fee ...................................... 18
Figure 6 - Blacklisting Logic Diagram .................................................................. 24
Figure 7 - Main flow for RL issuance ................................................................... 27
Figure 8 - Superuser Tasks ................................................................................ 29
Figure 9 - Revenue Licence Application State Transition ................................... 31
Figure 10 - Login Screen .................................................................................... 35
Figure 11 - New User Login Screen .................................................................... 36
Figure 12 - Forgotten Password Screen ............................................................. 36
Figure 13 - Login Process Flow .......................................................................... 37
Figure 14 - Initial RL Issuance Screen for RL Counter Staff ............................... 39
Figure 15 - Normal User Dashboard Flow .......................................................... 39
Figure 16 - Main RL Issuance Screen for RL Counter Staff ................................ 42
Figure 17 - Final RL Issuance Screen for RL Counter Staff ................................ 43
Figure 18 - Revenue Licence Issuance Flow ...................................................... 43
Figure 19 - Converted Engine Licence Issuance Flow ........................................ 49
Figure 20 - Non-user Licence Issuance Flow ...................................................... 51
Figure 21 - Arrears Payment Screen .................................................................. 53
Figure 22 - Arrears Payment Flow ...................................................................... 53
Figure 23 - Quotation Screen .............................................................................. 55
Figure 24 - Print Quotation Screen ..................................................................... 56
Figure 25 - Issuing a Quotation for a Fleet .......................................................... 56
Figure 26 - Payment for Quotation ...................................................................... 58
Figure 27 - Printing Licences for Fleet ................................................................ 58
Figure 28 - Issuance of Licences for Fleet .......................................................... 59
Figure 29 - Edit RL Records ............................................................................... 61
Figure 30 - Edit / Delete Existing Revenue Licence Records Flow ..................... 61
Figure 31 - Edit RL Records ............................................................................... 62
Figure 32 - Add RL Record Screen ..................................................................... 63
Figure 33 - Add New Revenue Licence Flow ...................................................... 63
Figure 34 - Add new RL record ........................................................................... 64
Figure 35 - Approval Screen of Escalated RL Application .................................. 65
Figure 36 - Processing Ineligible Revenue Licence Records Flow ..................... 66
Figure 37 - Superuser Tasks Screen .................................................................. 68
Figure 38 - Edit Existing Vehicle Information Flow .............................................. 69
Figure 39 - Categorise Vehicle as Free Licenced ............................................... 71
Figure 40 - Categorise Vehicle as Non-user Licenced ........................................ 73
Figure 41 - Format of Loose Slip......................................................................... 75
Figure 42 - Transfer to Other Province DSs ........................................................ 76
Figure 43 - Blacklisting Screen ........................................................................... 77
Figure 44 - Blacklisting Vehicles ......................................................................... 78

Figure 45 - Activity Log Screen ........................................................................... 80
Figure 46 - View Activity Log Flow ...................................................................... 80
Figure 47 - DMT Data Import Process Flow ........................................................ 82
Figure 48 - Counter Configuration Screen .......................................................... 84
Figure 49 - Configuring Licence Issuing Counters .............................................. 84
Figure 50 - Holiday Configuration Screen ........................................................... 87
Figure 51 - Add New Holiday .............................................................................. 87
Figure 52 - Configuring Holidays......................................................................... 88
Figure 53 - Initial Reference Data Screen ........................................................... 90
Figure 54 - Select Reference Data Category ...................................................... 91
Figure 55 - Add New Entry .................................................................................. 91
Figure 56 - Add Reference Data Flow ................................................................. 92
Figure 57 - User Management Screen ................................................................ 94
Figure 58 - Add User Screen .............................................................................. 94
Figure 59 - Managing User Accounts .................................................................. 95
Figure 60 - User Account Password Modification Screen ................................... 98
Figure 61 - Password Modification ...................................................................... 98
Figure 62 - Reporting Screen ............................................................................ 100
Figure 63 - Standard Reporting Template ......................................................... 100
Figure 64 - Generating Reports ........................................................................ 101
Figure 65 - Non-WP DS Data Upload Screen ................................................... 104
Figure 66 - Non-WP DS Data Upload Flow ....................................................... 104
Figure 67 - Lookup Portlet Welcome Screen .................................................... 106
Figure 68 - Login Screen to Lookup Portlet ...................................................... 107
Figure 69 - Lookup Vehicle Registration Number ............................................. 107
Figure 70 - Details of Vehicle ............................................................................ 108
Figure 71 - Lookup Portlet for DS/WPDMT Staff............................................... 109
Figure 72 - e-RL Portlet Welcome Screen ........................................................ 111
Figure 73 - Add Vehicle Screen ........................................................................ 112
Figure 74 - Confirm Vehicle Addition Screen .................................................... 113
Figure 75 - Proceed to Renewal Screen ........................................................... 113
Figure 76 - RL Renewal via Portlet ................................................................... 114
Figure 77 - Payment Confirmation Screen ........................................................ 115
Figure 78 - RL renewal via e-RL portlet ............................................................ 115
Figure 79 - Issue RL for e-RL portlet requests .................................................. 118
Figure 80 - Text Message for Mobile Lookup .................................................... 120
Figure 81 - Successful Response for Lookup ................................................... 120
Figure 82 - Unauthorised Access ...................................................................... 120
Figure 83 - Service Failure ................................................................................ 121
Figure 84 - Non-existent Vehicle ....................................................................... 121
Figure 85 - Mobile Lookup of RL details ........................................................... 121
Figure 86 - Data Synchronisation...................................................................... 126
Figure 8.1 - Superuser Dashboard Screen ....................................................... 146
Figure 8.2 - Superuser Dashboard Flow ........................................................... 146
Figure 3 - Export Local Database ..................................................................... 148
Figure 4 - Export of Synchronisation Data ........................................................ 148

Figure 5 - Generating Reports .......................................................................... 150
Figure 6 - Configure Alert Settings .................................................................... 151
Figure 7 - Licence Inventory Report ...................... Error! Bookmark not defined.
Figure 8 - Superuser Dashboard Flow .............................................................. 183

List of Tables

Table 1 - Definitions, Acronyms and Terminology................................................. 3
Table 2 - References ............................................ Error! Bookmark not defined.
Table 3 - Scope Inclusions and Exclusions ........................................................... 8
Table 4 - Stakeholders and Requirement Elicitation ........................................... 10
Table 5 - External System Dependencies ........................................................... 11
Table 6 - Deployment Dependencies .................................................................. 11
Table 7 - Entities of ER Diagram......................................................................... 17
Table 8 - Alternative Licencing Types ................................................................. 19
Table 9 - Business Rules .................................................................................... 21
Table 10 - Route Permit / Fitness Certificate Requirements ............................... 23
Table 11 - Blacklisting Logic ............................................................................... 23
Table 12 - User Roles ......................................................................................... 26
Table 13 - Stages in High Level Business Process............................................. 29
Table 14 - Superuser Tasks ................................................................................ 30
Table 15 - Licence States ................................................................................... 32
Table 16 - Scope of Use Cases .......................................................................... 34
Table 17 - Reports Provided by e-RL Application ............................................. 103
Table 18 - Data Migration Constraints and Strategies ...................................... 125
Table 19 - Data Access for WPDMT Users ....................................................... 134
Table 20 - Data Access for DS users ................................................................ 135
Table 21 - Action vs. Access Matrix for Business Process ............................... 136
Table 22 - Action vs. Access Matrix for Administrative Functions ..................... 137
Table 23 - Documentation Requirements ............. Error! Bookmark not defined.
Table 24 - Functionality not required by new e-RL Application ......................... 141
Table 25b - Closed Clarifications ...................................................................... 145
Table 26 - Traceability of User Stories to Use Cases ....................................... 154
Table 27 - List of Functional and Non-functional Requirements ....................... 156
Table 28 - List of User Stories .......................................................................... 163

1 Introduction
1.1 Purpose

This document describes the requirements for the e-Revenue Licence project.
The purpose of this document is to identify the system requirements and obtain a
sign-off on all requirements before finalising design.
1.2 Summary

This document provides all requirements gathered by the identified stakeholders
in the form of the business logic, functional requirements, and non-functional
requirements irrespective of the scope of effort involved as agreed in the
contract.

The functional requirements are captured as use-case scenarios and the non-
functional requirements include the performance requirements, compatibility
requirements, interface requirements, applicable standards and documentation
requirements.

In addition as the primary stakeholder (WPDMT) preferred to sign on a prototype
and user stories, additional effort was put in to capture this and a traceability
matrix has been attached to match the user stories to the use cases.

1.3 Client Overview

In November 2002, the Government of Sri Lanka (GoSL), launched e-Sri Lanka
as a national development initiative to foster social integration, peace, economic
growth and poverty reduction. The principal development outcomes of e-Sri
Lanka are anticipated to be:

A more effective, citizen-centred and transparent government
Empowerment of the rural poor, women and youth through increased and
affordable access to information and communication tools
Development of leadership and ICT skills
Creation of employment through the ICT industry, ICT-enabled services
and enhanced competitiveness of user industries and services

The core of this initiative, known as the Lanka Gate' initiative, is to have
electronic information in Sri Lanka to be delivered via a set of portals and

applications that is built on top of a wide collection of software infrastructure and
systems.

Many eServices will be implemented under the Lanka Gate initiative by different
stakeholders (ICT Agency, government, public and private sector organisations).

1.4 Project Overview

The project intends to automate the process of issuing revenue licences and
centralise the data to facilitate convenient renewals from any Divisional
Secretariat (DS). Furthermore, it will also facilitate the renewal of revenue
licences via the new Government Country Portal.

1.5 Definitions, Acronyms and Terminology

The following definitions, Acronyms and Terminology are used throughout this
document.

Term Explanation
CCPGP Credit Card Payment Gateway Proxy
DB Database
DMT Department of Motor Traffic
DS Divisional Secretariat
DSRS Detailed Software Requirement Specification
e-RL e-Revenue Licence
eServices Electronic Services
GUI Graphical User Interface
HTTP Hyper Text Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
ICTA Information and Communication Technology Agency
IDC Internet Data Centre
LGN Lanka Government Network
LIX Lanka Interoperability Exchange
MPG Mobile Payment Gateway
On the Wheel
Drive-in Revenue Licence counter where a customer may renew
their Revenue Licence
PDMT Provincial Department of Motor Traffic
RL Revenue Licence

Term Explanation
SAGE Software Architecture Group of Experts
Superuser Supervisor / Administrator / Commissioner
UI User Interface
VET Vehicle Emissions Testing
WPDMT Western Province Department of Motor Traffic
WSDL Web Services Description Language
Table 1 - Definitions, Acronyms and Terminology
1.6 References

2 Project Scope and Impact

In keeping with the Lanka Gate vision, the e-Revenue Licence Project is aimed at
centralising the Motor Vehicle Revenue Licence Issuance System for the
Western Province with automation of the activities related to the process. A key
objective of the project will be to enable citizens to access the revenue licence
issuance service through the country portal.

The projects development phase will need to implement the following key
system features over a carefully planned four-stage roadmap:

1. Centralised Licence data
2. Licence Lookup over multiple channels including Web and SMS
3. Re-engineered Revenue Licence Application
4. Revenue Licence Payment through the Web for Citizens through the
Country Portal

The project consists of a development phase and a support phase.

The development phase will extend over 16 weeks and include deploying the
application and dependencies to 3 Divisional Secretariats in the Western
Province, and the WPDMT (Western Province Department of Motor Traffic). It will
also include the deployment of the Central Database infrastructure and canonical
schema; Data Services and Modules, and the e-RL portlet to the ICTA
infrastructure including the LIX and Country Portal hosting environment.

In the support phase of this project, post implementation support will be provided
over a one-year period following the completion of the development phase. In
this phase, support engineers will monitor system performance and provide
monthly reports on system parameters with respect to the valid issuance of
revenue licences and access to related information from sources as Insurance,
Emission Testing, and Registration organisations.

2.1 Scope Inclusions and Exclusions

The following diagram depicts the high level scope of the functionality for the e-
Revenue Licence application to be developed.

Figure 1 - Scope of Functionality

In order to fulfil the business vision the system must provide the following critical
functions and capabilities:

1. Canonical Schema and Centralised database
2. Data Synchronisation
3. Data Migration
4. Provincial Data Upload
5. Web-based Licence Lookup
6. RL information Lookup for via SMS
7. New Revenue Licence Application
8. Interface Specifications
9. Revenue Licence Portlet

The following table indicates the functionality of each key component:

Component Function In Scope Out of Scope
1 Canonical
Database
Design
Canonical schema is
used by the new e-
RL application
Compatibility
with WPDMT
and Western
Province DS
database
schemas
Compatibility
with non-
Western DS
database
schemas
2 Data
Synchronisation
Module and
Service
This module is used
to synchronise the
data in the canonical
databases in the
WPDMT and 3 DSs
with the central
canonical database
at a pre-defined
frequency
Synchronisation
of data between
the WPDMT and
3 Western
Province DSs
and the central
canonical
database
Synchronisation
of data from
outside the
western province
3 Data Migration This module will
migrate the existing
data from the legacy
databases to the
central canonical
database
Migration of
data from all 40
DSs of western
province to the
central database
Data Cleansing
4 Provincial Data
Upload Module
and Service
This module is used
to upload data
received from other
provinces residing in
PDMT database to
the central database
Manual upload
of data from
other provinces
brought to the
WPDMT to the
central
canonical
database
Definition of
upload formats
Getting data
from other
provinces to the
WPDMT
Convert
provincial data
into specified
formats

5 RL Lookup
Portlet

This module is used
to lookup revenue
licence information
from the central
canonical database.
This helps a DS
officer or other
authorised
government officer to
validate RL
information of a
vehicle
Reading of data
available in the
central database
Update/Delete of
RL information
Securing access
to the RL
Lookup portlet
WAP access to
lookup portlet

6 RL information
lookup via SMS
Authorised mobile
users use this
interface to lookup
revenue licence
information via SMS
Provide a
eService for
SMS lookup
Authorising
SMS by mobile
number of
source
e-RL
functionalities
other than
licence
information
lookup (Update,
Delete, etc.)
Conversion of
SMS into a
SOAP request
for lookup
Developing an
SMS gateway
Ensuring the
integrity of SMS
transmission
7 New Revenue
Licence
Application
This application is
used by DS/WPDMT
staff to access e-RL
functionalities
Providing the
level of
functionality
provided by the
existing
application at
the WPDMT
Process
changes will be
done based on
recommendatio
ns and
stakeholder
feedback
A
comprehensive
BPR study will
not be done
User Interfaces
will not be
provided for
updating
business logic
8 Web Services to
External
Systems
These are services
that allow
connections to
external systems that
allow information
such as vehicle
emission tests and
insurance to be
verified
Consumption of
services
available
through LIX
Defining
interface
specifications
Development of
services to
connect to
external systems
in order to
retrieve
information
9 Revenue
Licence
Renewal Portlet
This is a portlet
hosted within the
Country Portal that
allows citizens to
renew vehicle
revenue licence
Renewing
annual revenue
licence
Redirecting to
Payment
Gateway for
credit card
processing
Processing of
credit card
payments by
connecting to
banks
WAP access to
renewal portlet

Online
verification of
VET and
Insurance by
consuming web
services
exposed by
relevant
companies
10 Data Security Data confidentiality,
integrity and
availability controls
Within the e-RL
application and
the e-RL country
portlets
LIX, Country
portal, OS and
Database
security controls
Table 2 - Scope Inclusions and Exclusions

2.2 Stakeholders and Requirements Elicitation

A RACI (Responsible, Accountable, Consult, and Inform) matrix was used to
manage the stakeholders and the approach was shared with ICTA. The following
stakeholders were identified and consulted using the mechanisms given in the
table below within the requirements phase.

Stakeholder Background Requirements Elicitation
WPDMT staff General staff involved in
the general licence
issuance process at
WPDMT
Meetings with reps, Supervisor /
Commissioner, Prototype
Demos/Reviews, User Stories
WPDMT
Management
Supervisors, System
Administrators and
Commissioner at WPDMT
Meetings, Prototype
Demos/Reviews, Implementation
committee meetings, User
Stories, Signoffs
DS staff Representatives of
WPDMT stationed in the
DS Offices and those with
dotted line responsibilities
on processing
Site Visits (1 Only), User Stories,
Representation of 2-3 DS in
Implementation Committee
SLIDA SLIDA has implemented
the current DS application
for WPDMT and will
maintain e-RL
This stakeholder, though initially
identified as the domain expert, is
instead now available to be
consulted in the deployment
stage
Citizens Individual Citizens wanting
to process their annual
vehicle revenue licence
Represented by WPDMT
Commissioner, Supervisor and
ICTA input
Organisations Private and Public Sector
Organisations wanting to
renew a fleet of vehicles
Commissioner, Supervisor and
ICTA input
Service
Provider
Organisations
(Insurance,
VET, DMT)
Organisations involved in
certifying validity of vehicle
as per regulatory
requirement for issuance
of revenue licence
Commissioner, Supervisor,
Project Steering Committee and
ICTA input
Motor Traffic
Police
The motor police who
need to check validity of
revenue licences
Commissioner, Project Steering
Committee and ICTA input
ICTA e-Sri Lanka vision and
architecture
Meetings, Workshops, Prototype
Demos, Sign-offs

Project
Steering
Committee
Cross functional
representatives from all
key organizations
including ICTA, WPDMT,
DMT, SLIDA
Meetings and Signoffs
Implementation
Committee
Cross departmental
representatives from
WPDMT and DS offices
involved in the deployment
Meetings, Demos and Signoffs
Table 3 - Stakeholders and Requirement Elicitation

Constraint 1. It would have been ideal to also survey Citizens, Motor Traffic
Police and Organizations as the primary stakeholder of the
system, however there was insufficient time during
requirements gathering to conduct such surveys.

2.3 Impact on Other Systems

The following subsections list the external systems that will interact with and/or
be affected by the proposed system.

2.3.1 System Integration

The e-RL system will be integrated into the following systems/infrastructure and
will require access for testing and deployment purposes.

Lanka Interoperability Exchange
Country Portal
Lanka Government Network

2.3.2 External System Dependencies

e-RL System functionality can only be delivered based on the availability of the
following external system / service dependencies which is outside the scope of
the work of this project:

External System /
Service
External System
Requirement
Functional Dependency
Mobile Payment
Gateway or SMS
A Web Service to send and
proxy SMS messages through
Sending and receiving
SMS messages to Motor

Gateway LIX Police and other
Credit Card
Payment Gateway
Proxy
Processing on online credit
card payment to be handled
entirely by this system
Online processing of e-RL
application
Insurance
Companys Web
Services
A Web Service implemented
to a given specification to
query insurance validity
application
Vehicle Emission
Testing centers
Web Services
A Web Service implemented
query emission test certificates
application
DMT Web Service A Web Service implemented
query vehicle data
Processing of Revenue
Licence applications for
new vehicles and
transfers
Table 4 - External System Dependencies

2.3.3 Deployment Dependencies

The successful deployment of the e-RL system will depend on the timely
availability of the following.

Dependency Scope
Hardware Integration Provision of hardware at the WPDMT/DS sufficient to
run the e-RL system is beyond the scope
Network Infrastructure Provision of network infrastructure within the
DS/WPDMT and interconnectivity between the offices
will not be provided
Table 5 - Deployment Dependencies

Constraint 2. The deployment will be limited to:
Deployment of the Canonical database at the LGN-IDC
Deployment of the e-RL application at the WPDMT and 3
Western Province DSs
Deployment of the e-RL portlet on the Country Portal

2.4 Key Assumptions

Assumption 1. Trilingual support will be provided for the e-RL application
while the database will support internationalisation so that it
can be localised if required. Trilingual support does not
include database data translation. Data entry will be in
English as requested by the Implementation Committee.
Assumption 2. Access Control mechanisms will be handled by the country
portal and the e-RL portlet will not implement any additional
authentication mechanism.
Assumption 3. The Canonical Database will not be compatible with non-
western province database schemas.
Assumption 4. Synchronisation of data from outside the western province
will not be implemented.
Assumption 5. The manual upload of data from other provinces into the
WPDMT canonical database is not required.
Assumption 6. The Web lookup service, the licence lookup service, SMS
and SOAP / HTTP lookups will only provide read functionality.
Assumption 7. Development of an SMS gateway is out of scope.
Assumption 8. Development of the DMT eService, Emissions Testing
eService, and Insurance eService is out of scope. However
for the purposes of testing these interface specifications will
be stubbed.
Assumption 9. Development of a Credit Card payment or Mobile Payment
gateway is out of scope.
Assumption 10. It is assumed that the requirements from the WPDMT,
Implementation Committee and Project Steering Committee
is the final requirement on the subject and reflects regulations
and all relevant Gazette notices.
Assumption 11. Accepted modes of payment for revenue licence renewal via
the e-RL application at the PDMT and DS offices will be
either cash, cheque or credit card
Assumption 12. The Prototype has been used as a primary source of
requirements gathering and thus may include interfaces
which are required by the stakeholders but out of scope.
Additionally the final look and feel of the prototype might vary
based on the eventual technology implementation constraints

Assumption 13. Use Interfaces for adding reference data will only be provided
for banks, insurance companies and vehicle emissions
testing companies.

Other Assumptions will be numbered and interspaced with the relevant
sections within this document.

3 Domain and Business Logic

The e-Revenue Licence application is being built for the Western Province
Department of Motor Traffic (WPDMT) and DS offices of the Western Province.
The operations of this department are governed by the Motor Traffic Statute of
the Western Province, No. 7 of 1991.

3.1 High Level Use-Case Diagram

The e-Revenue Licence application is required to provide the most value to the
Citizens of Sri Lanka followed by the Department of Motor Traffic and those that
process, administrate and maintain the Revenue Licence processing systems.

Figure 2 - High level Use Case Analysis

3.2 Envisioned Business Process

The business process envisioned external to the DMT with regard to processing
a Revenue Licence by a Citizen or Organisation:
1. Citizens who renew RL at WPDMT / DSs
2. eCitizens who renew RL via e-RL portlet of country portal
3. Institutions which renew RL for fleets of vehicles
4. Authorised mobile users (e.g. Motor Traffic Police) who wish to validate
Revenue Licences

Figure 3 - e-RL Business Process

3.3 Entity Relationship Diagram

The following diagram provides the main domain entities that need to be
referenced in the e-Revenue Licence application:

Figure 4 - Entity-Relationship diagram

Entity Description
Arrears
Contains individual records that provide a
breakdown of a matching total arrears for a
revenue licence record
Authority Contains all possible divisional secretariats
Cheque
Contains details of cheques used to pay for the
Revenue Licence records
Counter Contains details of all possible counters
Fleet Contains details of all fleets
Fuel Contains all possible types of fuel
Invoice Maps payments to Revenue Licences
Licence Status
Contains all possible licence status, e.g. issued,
printed, print and post
Licence Type
Contains all possible types of licences, e.g.
Normal Issuance, Reissuance
Other Rate Reason
Contains descriptions of possible other reasons
for a rate to exist
Payment
Contains details of all payments made for
Revenue Licence records
Province Contains all possible provinces
Rate Contains details of rates
Revenue Licence Record
Contains details of a revenue licence issued for a
particular vehicle
Vehicle Contains details of a vehicle
Vehicle Class Contains all possible types of vehicles
Vehicle Owner Contains details of the owners of vehicles
Vehicle Status
Contains all possible vehicle status, e.g.
Blacklisted
Table 6 - Entities of ER Diagram

3.4 Licence Payment Logic

The rules governing Revenue Licences and associated rates have a tendency to
change. The rules being implemented in this application to calculate the fees are
those which are given on the Gazette notification of 19/12/2007 (No. 1528/22)
and the Circular issued by the WPDMT. However, the circular issued by the
WPDMT will be given precedence where there is any divergence. The business
logic for the calculation of the Revenue Licence fee has been depicted in the
diagram below.

Figure 5 - Calculation of Normal Revenue Licence Fee

Apart from the above logic of calculating the Revenue Licence fee, there may be
alternative logic for the following two cases:

1. Issuance of Non-user Certificates

Non-user certificates may be issued in lieu of the normal revenue licence if
a vehicle meets the criteria outlined in the Motor Traffic Statute mentioned
above. The verification of non-user status would not be within the scope of
the system.

For a period of 6 months:
Class of Vehicle Fees (Rs.)
Motor Cycles and Motor Tricycles 50.00
Motor Coaches, Lorries and Other Vehicles 150.00

For a period of 6 to 12 months:
Class of Vehicle Fees (Rs.)
Motor Cycles and Motor Tricycles 100.00
Motor Coaches, Lorries and Other Vehicles 300.00
Table 7 - Alternative Licencing Types

2. Issuance of Free Licences

Government organisations may receive free licences subject to meeting
the necessary criteria. The cost involved for a free licence would be zero
and the verification process would not be within the scope of the system.

Arrears due from before 31/12/2007, will be calculated based on the licence fee
structure in appendix 5

Other business rules which relate to the issuance of revenue licence are
indicated below:

No. Business Rule Description
1 Vehicle registration format
should be valid
A valid vehicle format will adhere to the
following criteria;
Consists of two parts: the first part
being either digits or character and
the second part being up to 4 digits
The province prefix (E.g. WP, CP
etc) will not be part of the registration
number in the system
For the numbers with a province
prefix the subsequent alphanumeric
digits are unique irrespective of the
province prefix
Vehicle registration Numbers having
Sri will be considered as a dash -

Examples of valid registration number
formats are;
EN-3821
39-2654
301-6796
GY-9715
2 Reasons for a vehicle to be
ineligible for RL renewal
No Certificate of Registration
Original registration book not
submitted. However, vehicles
purchased under a lease agreement
may have a certified copy of the
registration book
No Route Permit Valid route permit
not submitted
No Fitness Certificate Valid fitness
certificate not submitted
No Previous Licence Previous
revenue licence not submitted. This
only applies to revenue licence
renewals
No Insurance Certificate Valid
insurance certificate not submitted
Blacklisted by DMT or PDMT
The Registration book check will not
be possible or needed for the
country portlet. The country portlet

will check all else through the
database or dependant eServices
The previous Revenue Licence will
be checked from the central
database for country portal renewals
3 Renewal of RL in advance A valid Revenue Licence can be
renewed in advance only if the time to
expiry from the current date is less
than or equal to 3 months
4 Other forms of vehicle
registration numbers
Registration codes from defence
establishments ( , , ) will
not be supported by the system
5 Fuel type conversions Fuel type conversions can have two
types:
With reg. no. change (considered as
new vehicle)
With same reg. no. (need conversion
logic)
6 Non-user certificates The maximum period for which
continuous non user certificate could
be obtained is 2 years
7 Engine Number requirement Vehicles without an engine number will
be considered as trailers
8 Due date for licence renewal Three working days from the
corresponding day of the
corresponding month of the year in
respect of which the licence is applied
for. This period will be 7 days in the
case of newly registered vehicles.
Holidays should be accounted for when
arriving at the due date for revenue
licence renewal.
Table 8 - Business Rules

Assumption 14. The system would not support the issuance of trade licences
and temporary licences.

3.5 Mandatory Requirements for Revenue Licence Issuance
3.5.1 Vehicle Emissions Testing Certificate

The following rules apply with regard to the VET requirement for revenue licence
issuance:

Any vehicle on its first revenue licence issuance does not require the VET
certificate. A vehicle will be deemed to be obtaining its first revenue
licence if there is no prior revenue licence issued for this vehicle
Brand new vehicles do not require vehicle emissions testing for the first 3
years
Land Vehicles do not require vehicle emissions testing
The application will capture the vehicle emission testing certificate number
but not the expiry date
The vehicle emission testing certificate should be within its validity period
at the date of renewing the RL

3.5.2 Insurance Certificate

The following rules apply with regard to the vehicle insurance requirement for
revenue licence issuance:

The requirement is to have a valid insurance certificate (i.e. insurance
expiry date should be greater than or equal to date of renewal)
The insurance expiry date will be captured by the application. However,
the insurance certificate number will not be required

3.5.3 Route Permit and Fitness Certificate

The following table depicts the requirement for fitness certificates and route
permits for different vehicles

Class of Vehicle Route Permit Required Fitness Certificate Required
Motor Car no no
Dual Purpose Vehicles no no
Motor Lorry no yes
Land Vehicle no no
Motor Cycle no no

SLTB no yes
Private Coach no yes
Omni-bus yes yes
Three Wheeler no no
Ambulance/Hearse no yes
Motor Car A-Z no no
Motor Tricycle Van no yes
Table 9 - Route Permit / Fitness Certificate Requirements

3.6 Blacklisting of Vehicles

The following table describes the possible types of blacklisting, their sources and
the rectification strategy.

Type Source Rectification Strategy
Request by Law
enforcement authority
Courts, Police Remove from blacklist after
receiving confirmation from courts
or police
Request from DMT Duplicate
Chassis
Numbers
Remove from blacklist only when
informed by DMT
Tax Fraud DMT, Inland
Revenue
Department
DMT system should be updated
Table 10 - Blacklisting Logic

Assumption 15. In case of blacklisting being requested by the DMT or a law
enforcement authority, rectification will be done after
receiving confirmation from the relevant authority

The following diagram depicts the possible reasons for blacklisting and their
sources. According to the diagram, blacklisting may either happen at the PDMT
or through the DMT data feed.

Figure 6 - Blacklisting Logic Diagram

Assumption 16. The DMT Data feed will have the particular reason for which
the vehicle has been blacklisted

3.7 User Roles

Described below are the main user roles identified for the e-Revenue Licence
system:

eCitizen A Sri Lankan Citizen with internet access to the country portal
and sufficient IT literacy to use simple web based applications
PDMT User The current licence issuing staff of the WPDMT with access
to process the normal licence issuance
PDMT Supervisor WPDMT System users with additional privileges to
be able to process exceptions, override the standard business logic and
correct errors
PDMT Admin The technical IT system supervisors with access to
perform security, update and maintenance of the system
PDMT Commissioner This will include both the commissioner and
senior most accountant at WPDMT who overlook WPDMT operations
DS (Divisional Secretariat) User Standard users in the Divisional
Secretariat office of the Western Province that are process normal licence
issuance
DS (Divisional Secretariat) Supervisor DS System users with
additional privileges to able to process exceptions and correct errors.
LGN Admin The technical IT system supervisors of the central LGN
databases and country portal
Motor Traffic Police Police personnel with access to revenue licence
information

The group of roles that has a higher level or authority than a standard user,
specifically the PDMT/DS Supervisor, PDMT Admin and PDMT Commissioner
will be referred to as superusers. The table below gives the breakdown of the
role based on the main value they obtain from the system, their relative IT
proficiency, domain knowledge, and security clearance to access data and the
frequency of use of the e-RL system.

Role System
Value
IT
Proficiency
Domain
Experience
Security
Clearance
Frequency
of use
eCitizen Process
Licence
efficiently
Low Low Low Annually
~1 million
PDMT
User
Process
Licence
Rapidly
Low Medium Medium Work
Hours
V.
Frequent
~10 users

PDMT Admin Handle
exceptions
Administration
High High High Work
Hours
2 admins
PDMT
Supervisor
Handle
exceptions
Medium High Medium-
High
Work
Hours
2-4 users
PDMT
Commissioner
Serve
Citizens more
efficiently
Medium V. High V. High Work
Hours
1 user
DS
User
Process
Licence
Rapidly
Low Low-
Medium
Low Work
Hours
~200 users
DS
Supervisor
Handle DS
exceptions
Low Medium Medium Work
Hours
~40 users
LGN Admin Backup and
maintain
Central DB
High Low Medium Weekly
~2 admins
Motor traffic
police
Confirm
Validity of
Revenue
Licence
Low Medium Low Daily
~ 200
mobiles
Table 11 - User Roles

3.8 High Level Business Process
3.8.1 Normal Issuance Process

The following depicts the steps followed for normal licence issuance with the e-
RL Application. The most common flow relating to the renewal of a Revenue
Licence has been highlighted in blue. It has also been further explained in the
table that follows.

Figure 7 - Main flow for RL issuance

Process Step Description Guards
Login to Counter Login and specify the Counter
Number the staff member is
assigned to
Counter number
should be selected
from a pre-populated
drop-down list
Enter Vehicle
Registration No.
The vehicle registration number
entered has to meet the correct
format before querying the
database. If the vehicle registration
no. exists in the local database the
owner and the vehicle information
will be retrieved and the relevant
field populated. If not it will be
fetched form the central database. If
the vehicle registration number does
not exist in central database a new
entry will be added
Format of vehicle
registration number
should be checked
Check Status Check for eligibility of the revenue
licence. If ineligible, the vehicle
owner will be directed to supervisor
or higher depending on the nature of
ineligibility.
If not, proceed to the next step
A vehicle classified as
ineligible needs
administrator approval
to be reclassified as
eligible
Check Relevant
Documentation
This step will request for the VET /
Insurance certificate / Fitness
certificate / route permit
documentation required for the
particular class of vehicle
N/A
Validate
Documentation
Requirements
Validation can be either by manual
verification of documents or by using
the insurance and VET web services
for online verification. However, the
Fitness Certificate and Route permit
will have to be verified manually.
If validation fails the RL application
may be classified as Ineligible and
escalated to a superuser for special
approval
Check correct date
format for expiry dates
Accept Payment Payment needs to be made before
the RL is issued. Payment may be
either by cash or cheque but not
both.
User may verify the
balance due by
entering the amount
received on the
screen
Issue and Print
Licence
Print the revenue licence information
on the pre-printed licence paper
Printing can be
cancelled if in case
there is a failure in the

printing process. This
will auto-increment
the licence number
Table 12 - Stages in High Level Business Process

3.8.2 Administrative Tasks

The following diagram depicts the business process followed by a superuser
when performing any of the tasks which require a higher level of authority than
the RL processing staff.

Figure 8 - Superuser Tasks

Process Step Description Guards

Login as Superuser Login with the superuser
credentials
N/A
Enter Vehicle
Registration
Number
The vehicle registration number
entered has to meet the correct
format before querying the
database. If the vehicle registration
no. exists in the database the
vehicle information and RL
transaction history will be retrieved
and the relevant field populated.
Format of vehicle
registration number
should be checked
Manage Transitions Perform the following superuser
tasks:
Print Loose Slip
Categorising Vehicles as Free
Licenced
Categorising Vehicles as Non-
user licenced
Change Fuel Type of Vehicles
Blacklisting of Vehicles
Maintain log of
activities
Owner / RL
Information
Correction
Correct erroneous owner / RL
information
Maintain log of
activities
Approve
Escalations
Approve exceptional scenarios so
that the RL application can proceed
to issuance
Maintain log of
activities
Reporting Generate standard set of reports for
monitoring and reconciliation
purposes
N/A
System
Administration
This includes a grouping of all
administrative tasks
N/A
User Management This includes
creating/modifying/deleting user
roles and access privileges
N/A
Counter
Configuration
Configuring counters in each DS
will be done locally by the system
administrator through this task
N/A
Holiday
Configuration
Configuring holidays at national,
province and DS level will be done
locally at the PDMT by the system
administrator through this task
N/A
Data Import This includes the Import of DMT
data through the web service
N/A
Table 13 - Superuser Tasks

3.9 Licence State Transition

The state transition diagram below provides the various states and transitions of
a vehicle licence application during the issuance process. The labels are
reflected prominently in the user interface associate to a vehicle Revenue
Licence record so that the user can be immediately aware of the current status of
the application and thus what steps follow. The licence state diagram is followed
by a tabular description of each state.

Figure 9 - Revenue Licence Application State Transition

State Description
Valid
A vehicle having a valid Revenue Licence would be in this
state. This would also mean that the expiration time of the RL
is greater than 3 months
Renewable
A vehicle having a Revenue Licence having an expiration time
to expiry of less than or equal to 3 months would be in this
state
Expired
A vehicle having a Revenue Licence which has expired would
be in this state
Verified
A vehicle from either the Renewable or Expired state will be
subject to verification of mandatory requirements before
renewal. Vehicles that meet these requirements (VET,
insurance, fitness certificate, route permit etc.), will be
classified in to the Verified state
Ineligible
If in case there is a failure to meet one of the requirements
and the vehicle owner wishes to seek special approval, the
vehicle may be classified as ineligible. If a supervisor grants
special approval to a vehicle owner with respect to one of the
mandatory requirements stated above, the vehicle will move
into the Verified state
Paid
Once payment is made to obtain a RL for a verified vehicle, it
will be moved into the Paid state. RL requests coming from
the e-RL portlet of the country portal will also be in this state.
Once the RL is printed and handed over to the customer, the
vehicle is classified under the Valid state
Table 14 - Licence States

4 Functional Requirements

This section presents the functional requirements for the e-RL project. Each
functional requirement is elaborated upon by including prototype figures,
preconditions, main flow, success criteria, alternative flow, error flow, business
rules / user stories, and the stage to which it is relevant.
The scope of the Use Cases described in this section is described in the table
below.
Use Case In Scope Out of Scope
Data Migration Use case is in scope -
Data Synchronisation Use case is in scope
Reliable messaging and
error handling will not be
handled for data
communications
Country Portal Lookup Use case is in scope -
SMS Lookup Use case is in scope -
Normal Issuance of Licences Use case is in scope -
Manage Fleets None
Current application only
supports issuance of
quotations. This is
considered an extended
feature and hence is out of
scope
Manage Fleet of Vehicles None
Current application only
supports issuance of
quotations. This is
considered an extended
feature and hence is out of
scope
Issuing Quotations Use case is in scope -
Issuing Licences for
Quotations
Licence will be issued
iteratively for each vehicle
of the quotation by going
through the normal
licence issuance process.
However, this feature is
recommended for
implementation due to its
significant value addition
-
Normal User Dashboard Use case is in scope -
Correction of Data Entry
Errors in Revenue Licence
Information
Use case is in scope -
Processing Ineligible Use case is in scope -

Revenue Licence Records
Update Vehicle Information Use case is in scope -
Update Vehicle Owner
Information
Categorising Vehicles as
Free Licenced
Categorising Vehicles as
Non-user licenced
Blacklisting of Vehicles
Use case is in scope. This
is new functionality that is
critically needed to
implement the new
business process
between DMT and
WPDMT / DS Offices
-
Print Loose Slip
can be supported through
the lookup portlet, but
requires a policy level
decision to do so
-
Vehicle Activity Log Use case is in scope -
Non-Western Province DS
Data Upload
Department of Motor Traffic
Data Import
Counter Configuration
Localised counter
configuration (within a
given DS)
Centralised counter
configuration
Holiday Configuration
Localised holiday
configuration (within a
given DS)
Centralised holiday
configuration
User Account Management
will be managed centrally.
-
User Account Password
Modification
e-RL Application Login Use case is in scope -
Reports Use case is in scope -
Manage List of Vehicles on
e-RL portlet
None
Managing a list of vehicles
that belong to a particular
citizen
Revenue Licence Renewal
via e-RL portlet
Issue RL for e-RL Portlet
Requests
Table 15 - Scope of Use Cases

4.1 e-RL Application Login

This user level scenario covers the steps involved in logging into the e-RL
application as a normal user or a superuser. It also includes the steps followed
by new users and users who have forgotten their passwords in logging into the
system.

Figure 10 - Login Screen

Figure 11 - New User Login Screen

Figure 12 - Forgotten Password Screen

Figure 13 - Login Process Flow

Description This use case explains the login of users to the e-RL application
at PDMT / DSs. It also describes the process followed by new
users and users who have forgotten their passwords
Relevant
Prototype
Figures
Figure 10 - Login Screen
Figure 11 - New User Login Screen
Figure 12 - Forgotten Password Screen
Preconditions None
Main Flow 1. Access e-RL Application
2. Login to the System Users have to provide their username
and password to login to the system. The province and the
DS will be disabled for DS users as it will be preconfigured
at deployment. New users and users who have forgotten
their username or password can click on either the New
User or Forgotten Password buttons. This will take them
to alternative flow 2a
3. Validate Username / Password The system will validate
the username and password provided with the local
database
Success
Criteria
Successfully login to the system as normal user or
superuser
Alternative
Flow
New user or Forgotten Password
2ai New User/ Forgotten Password: New users or
existing users of the system who have forgotten their
password may click on the appropriate button
2aii Add User / Reset Password: According to the
instructions given on the screen, the user will contact the
PDMT administrator. The PDMT administrator will add a

new user or reset the password as per the request. Refer
section 4.15 for user management activities.
2aiii Update Database: The User management activity
carried out by the PDMT administrator will be updated in
2aiv Inform User: DS user will be informed about the
creation of the new user account or the resetting of the
password
2av Synchronize Database: The DS user will click on
the Synchronize button to retrieve the latest user
information from the central database
2avi Retrieve Update: The system will retrieve the
updated information from the central database to the
local database and allow the user to login
Error Flow Incorrect username / password
1. Display the message Invalid Username and/or
password.
Cannot synchronise with central database
1. Display the message Cannot synchronize now. Please
try again later.
No updates found
1. Display the message No updates found. Please try
again after receiving confirmation from PDMT.
2. The user will be retained in the screen without being
redirected to the login screen
Business
Rules / User
Stories
Password should be changed on first login. This default
behaviour may be overridden at the time of creating the new
user account in the central application, if required
Stage Stage 3

Assumption 17. Contacting the PDMT and subsequent confirmation of user
management activity will be done manually

Assumption 18. The application will not check for a particular number of login
attempts since it is an internal application and less vulnerable
to password attacks

4.2 Normal User Dashboard

This user level scenario covers the steps involved in accessing the normal user
dashboard.

Figure 14 - Initial RL Issuance Screen for RL Counter Staff

Figure 15 - Normal User Dashboard Flow

Description This use case explains the displaying of the normal user

dashboard and its requirements
Relevant
Prototype
Figures
Preconditions None
Main Flow 1. Login as Normal User
2. View Dashboard This will include a summary of all the
transactions carried out by the particular counter within the
day and the RL transactions put on hold (pending
Issuances). This will be retrieved from the local database
3. Proceed to Licence Issuance The user may either proceed
to normal licence issuance or licence processing for fleets
from here. Normal Licence processing can be done by
entering the vehicle registration number or by clicking on any
of the pending issuances. Fleet management related
activities can be initiated by entering the fleet identification
number.
Success
Criteria
Display of summary information at particular counter and
proceed to either normal licence issuance or fleet related
activities
Alternative
Flow
None
Error Flow None
Business
Rules / User
Stories
The following information will be included for each counter in
the dashboard under history of issued licences;
1. Licence No.
2. Vehicle No.
3. Owner Name
4. Type
5. Fee
6. Fine
7. Total
the dashboard under pending issuances;
1. Vehicle No.
2. Owner Name
3. Type
4. Fee
5. Fine
6. Total
7. Status
8. Time on hold
9. Action
The following Summary level information will also be
displayed
1. Counter Name

2. Current Time
3. Total Amount
4. Total Cash Collected
5. Total Cheques Collected
6. Total Credit Card Collection
Pending Issuances will only include transactions that are put
on-hold by clicking the relevant button (Section 4.3.1
Alternative Flow 5a)
Stage Stage 3

4.3 Revenue Licence Issuance Scenarios
4.3.1 Normal Licence Issuance
This scenario describes the steps involved in the issuance of a Revenue Licence.
The different types of revenue licence issuances that are considered under this
scenario are given below:
Revenue Licence Renewal
Revenue Licence Reissuance
Free Licence Issuance

Figure 16 - Main RL Issuance Screen for RL Counter Staff

Figure 17 - Final RL Issuance Screen for RL Counter Staff

Figure 18 - Revenue Licence Issuance Flow

Description This use case describes the normal licence issuance process
followed by the PDMT / DS staff at the counters. It includes the
retrieval of data from either the local or central database,
verification of documentation, accepting of payments and
issuance and printing of licences
Relevant
Prototype
Figures
Preconditions User is logged into the system
Main Flow 1. Initiate Revenue Licence Issuance The customer hands
over their documents to a Revenue Licence counter
2. Validate Vehicle Number At the Initial RL Issuance
Screen (shown in Figure 14) The RL counter staff enter the
vehicle registration number, which is validated when the
Search button is clicked or when the Enter key is pressed.
The vehicle and owner information will be retrieved either
from the local database or from the central database through
alternative flow 2a. This navigates the user to the Main RL
Issuance Screen (shown in Figure 16) where they may
manually verify the owner and vehicle information against
the documentation provided. If there is a discrepancy in the
information the user may follow alternative flow 2b
3. Verify Vehicle Details The following steps take place
during this process:
Previous RL: When a previous RL is available, it is shown
in the Previous Lic. No field
The Revenue Licence history is displayed in the Licence
Payment History section below the Vehicle Information
section. The user will be initially shown the 2 latest
records form the database. However, the counter staff
may view the last 5 records by clicking on the View
More button. Furthermore, the user may view additional
details of past revenue licence payments by clicking on
the particular record which will display a popup with
additional information
Insurance Certificate: By default the Insurance Cert field
is set to No. A valid insurance certificate is one that has
an expiry date greater than or equal to the current date. If
the customer has not provided his / her insurance
certificate or RL counter staff is in doubt as to the validity
of the provided certificate, they may verify the same
through alternate flow 3b. If the insurance certificate is
verified through this, then the insurance certificate expiry
date is also populated through the same web service call.
VET Certificate: The RL counter staff enters a manually
verified valid VET certificate number. A valid VET

certificate is one that has been obtained within a period of
one month to the day the RL is being issued. If the
customer has not provided the VET certificate or counter
staff are in doubt as to the validity of the provided
certificate, they may verify the same through alternate
flow 3a.
Fitness Certificate: If a fitness certificate is required for
that class of vehicle (Please refer to section 3.5.3) then
the following values may be used in the fitness certificate
field:
o Yes Valid fitness certificate available
o No No valid fitness certificate available
o Brand New A fitness certificate is not required
Route Permit: If a route permit is required for that class of
vehicle (Please refer to section 3.5.3) then route permit
number and route permit expiry dates fields must be filled
by an RL counter staff member
If any of the documents (VET, Insurance, Fitness Certificate,
Route Permit) cannot be verified or if there is any other
reason which requires superuser intervention, the vehicle is
marked as ineligible and escalated to a superuser (see
alternative flow 3c).
4. Calculate Arrears / Fines / Issuance fee Any arrears, fines
on arrears, the issuance fee and applicable fines are
calculated according to section 3.4. If licence is in
Renewable state (i.e. less than 3 months to expiry) the
user will have the option to increment the expiry date by
clicking the right arrow icon. The button will be disabled after
the year is incremented. Arrears before 31/12/2007 (if any),
will be displayed separately, since they are subject to a
different revenue licence fee structure (see Appendix 5)
5. Issue and Print the Revenue Licence The counter staff
collecting the required payment from the customer, the RL
counter staff member clicks the Issue Licence button which
takes them to the Final RL Issuance Screen (shown in
Figure 17) where they are shown the total amount to be
paid. The RL counter staff member enters the amount
received from the customer and is shown the balance to be
returned. The licence will be printed once the Print Licence
button is clicked. The issuance will be updated in the local
database
Please note that in the above flow, fields may be traversed
using the tab key and have the function key F8 assigned to
clear the screen and prompt for a new entry

Success A new Revenue Licence record is created in the local

Criteria database and printed
Alternative
Flow
Verify Vehicle Number
2a Verify Vehicle Number: If the vehicle number does
not exist in the local database, retrieve information from
the central database. If not found in the central database,
an application hosted at the central database will connect
to the DMT eService and retrieve the record
2b Update Vehicle / Owner Information: If there is a
discrepancy between the vehicle / owner information in
the system and the documents provided by the vehicle
owner, the counter staff may update the system
information by retrieving the latest information from the
DMT by clicking on the Update button. Clicking this
button will invoke the application hosted at the central
database, which in turn will retrieve the latest information
from the DMT eService
Verify Vehicle Details
3a Verify Vehicle Emissions Testing Details: If in doubt,
the e-RL counter staff may request verification of the
VET certificate. This will be via the VET eService. The
VET company will have to be selected by the user in the
popup dialog box
3b Verify Vehicle Insurance Details: If in doubt, the e-
RL counter staff may request verification of the Insurance
certificate. This will be via the Insurance eService. The
insurance company will have to be selected by the user
in the popup dialog box
3c Mark as ineligible and escalate to e-RL Superuser:
The application submitted may be classified as ineligible
due to the reasons mentioned in Rule No. 2 of Section
3.4. This can be done by clicking on the status button
and selecting the appropriate reason. The ineligible
transaction will be added to a common queue for the
superusers.
Revenue Licence Reissuance
4a Calculate Reissuance Fee: The e-RL application will
proceed to reissuance if the status of the revenue licence
application is valid. The reissuance fee is calculated
proportionate to the number of months until expiry
Free Licence Issuance
4b Process Free Licence Issuance: The vehicle has to
be configured as one which is eligible for free licence
issuance by the superuser (refer superuser tasks). If so,
the revenue licence fee will be calculated as zero and the
application will proceed to the licence printing screen
Put On-hold

5a Put RL transaction On-hold: The user can put a
transaction on hold before payment is made so that it
may be retrieved later. This is then listed under pending
issuances of the normal user dashboard
Pay Arrears Only
4b Pay Arrears Only: The user will be taken to a screen
where arrears could be paid separately. This use case
has been described in section 4.4
Cancel Printing
6 Reprint Revenue Licence: Once Print Licence is
clicked, the record will be saved in the database and the
licence will be printed subsequently. Thereafter, the user
will be shown a dialog box inquiring if printing was
successful. If during / after printing there is found to be a
problem with the printed licence, e.g. the licence did not
print properly, then counter staff may confirm the same
by clicking No in the dialog box. This takes the user
back to the Final RL Issuance Screen . Here the RL
number is incremented but the field is also left editable
for counter staff to edit if required. They may then issue
and print the licence again as earlier
Error Flow Invalid format of vehicle registration number
1. Display the message Invalid format of vehicle
registration number
Vehicle registration number does not exist in local database
or central database
1. Display the message This vehicle is not available in the
system
Invalid format of Insurance / route permit expiry date
1. Display the message Invalid insurance / route permit
expiry date
VET number not provided
1. Display the message Please enter VET number
If the vehicle is Blacklisted
1. The status will display the text Blacklisted
Business
Rules / User
Stories
Rates and taxes as per the Gazette notification of
19/12/2007. Please refer Section 3.4
Legislation as per Motor Traffic Statue of the Western
Province, No. 7 of 1991
Arrears refer to revenue licence renewals that have not been
made on time. Arrears are also subject to fines as per the
table in Appendix 4
The VET number entered in to the e-RL application is a
concatenation of the VET certificate number and the first
letter of the name of the issuing company
Revenue licence payments for periods less than a year

should be calculated proportionately. In doing so, a fraction
of a month should be treated as an entire month
The system should account for national, provincial holidays
and times when calculating the due date for revenue licence
renewal
A vehicle owner cannot renew their RL until the time to
expiry is 3 months or less
A vehicle owner renewing his/her RL within the 3 month
period prior to expiry and having lost the current RL has to
be charged for the remaining period and also the year ahead
For a list of classes of vehicles requiring fitness
certificates/route permits please refer section 3.5.3
If any of the vehicle or owner fields do not contain required
data the vehicle will be displayed as temporarily blacklisted.
This needs to be rectified via a superuser in order to
proceed with licence issuance
Stage Stage 3

4.3.2 Issuance of Licences for Vehicles with Converted Engines

This user level scenario covers the steps involved in issuing a licence for
vehicles with Fuel Type Conversions. There are two main possibilities due to
Fuel Type Conversions:

1. Change in Vehicle Registration Number
In this case, the vehicle is considered as a newly registered vehicle
and licences are issued starting from the effective conversion date.

2. No Change in Vehicle Registration Number
In this case, the vehicle will continue to be issued revenue licences
while considering the effective conversion date as the licence start date

Figure 19 - Converted Engine Licence Issuance Flow

Description This use case describes the process followed when issuing
revenue licences for vehicles that have undergone a fuel type
change. A fuel type change impacts the revenue licence fee
calculation logic and therefore needs to be addressed
separately
Relevant
Prototype
Figures
Fuel Type Conversion has to be updated in the DMT system
or else should be changed by a PDMT superuser

Main Flow 1. Initiate Renewal Process for Verified Vehicle The steps
mentioned in the Normal Licence Issuance Process of
section 4.3.1 will be followed in verifying the vehicle details
2. Calculate Arrears / Fines / Issuance fee Any arrears, fines
and the issuance fee are calculated based on the new fuel
type starting from the effective conversion date.
3. Issue and Print Revenue Licence After collecting the
required payment from the customer, the RL counter staff
member clicks the Issue the Licence button which takes
them to the Final RL Issuance Screen (shown in Figure 17)
where they are shown the total amount to be paid. The RL
counter staff member enters the amount received from the
customer and is shown the balance to be returned. The user
may then print the licence. The issuance will be recorded in
the local database

Success
Criteria
A Revenue Licence record for the new fuel type is created in
the database and issued
Alternative
Flow
Cancel Printing
licence will be printed subsequently. Thereafter, the user
will be shown a dialog box inquiring if printing was
successful. If during / after printing there is found to be a
problem with the printed licence, e.g. the licence did not
print properly, then counter staff may confirm the same
by clicking No in the dialog box. This takes the user
back to the Final RL Issuance Screen . Here the RL
number is incremented but the field is also left editable
for counter staff to edit if required. They may then issue
and print the licence again as earlier
Error Flow None
Business
Rules / User
Stories
Revenue Licence will be issued for the remaining period
from the effective date to the normal licence expiry date of
the corresponding year.
Subsequent revenue licence issuances will be for the regular
annual period based on the first registration date
Business Rules mentioned in section 4.3.1 are applicable
here
Stage Stage 3

4.3.3 Issuance of Non-user Certificates

This user level scenario covers the steps involved in issuing a Non-user Licence.

Figure 20 - Non-user Licence Issuance Flow

Description Registered owners or any person in possession of motor vehicle
may apply for a non-user certificate on or before the due date of
the payment of licensing fee in any year by giving written notice
to the licensing authority that he / she does not intend to use the
motor vehicle for the underlying period. This use case describes
the process followed in obtaining the non-user certificate via the
e-RL application
Relevant
Prototype
Figures
Vehicle has been configured as non-user licenced by a
superuser
Main Flow 1. Initiate Non-user Issuance Process for Verified Vehicle
The steps mentioned in the Normal Licence Issuance
Process of section 4.3.1 will be followed in verifying the
vehicle details
2. Calculate Non-user fee The non-user certificate issuance
fee is calculated according to section 3.4
3. Accept Payment The system will accept payment and be
updated with the non-user certificate issuance. A revenue
licence will not be printed in this scenario. Instead, a receipt
will be given to indicate that a non-user certificate has been

issued. This is handled separately without any intervention
of the e-RL application. The issuance will be updated in the
local database.

Success
Criteria
A new Revenue Licence record marked as a non-user
licence is created in the database and issued
Alternative
Flow
None
Error Flow None
Business
Rules / User
Stories
Non-user fee is calculated as per the guidelines in section
3.4
When issuing a non-user certificate the receipt number will
be stored in place of the revenue licence number
Stage Stage 3

Assumption 19. Printing of the non-user certificate and the receipt will be
done separately

4.4 Payment of Arrears

This user level scenario covers the steps involved in paying arrears due for a
particular vehicle.

Figure 21 - Arrears Payment Screen

Figure 22 - Arrears Payment Flow

Description Vehicle owners are allowed to pay arrears that have been
accrued due to the non-renewal of revenue licences. This use
case describes the process followed in making payment for
such arrears accrued
Relevant
Prototype
Figures
Figure 21 - Arrears Payment Screen
Main Flow 1. Initiate Arrears Payment Process for Verified Vehicle The
steps mentioned in the Normal Licence Issuance Process of
section 4.3.1 will be followed in verifying the vehicle details
2. Proceed to Arrears Payment All arrears due for the vehicle
will be selected for payment by default. The user can
proceed to arrears payment by clicking the Pay Arrears
Only button. However, if the vehicle owner intends to pay
only a part of the arrears payments due the counter staff
should select the appropriate checkboxes. Clicking on the
Pay Arrears button will display a popup window with
arrears payment details
3. Accept Payment Payment can be made for accrued
arrears and fines which will be updated in the database
4. Update Database The local database will get updated with
the arrears payment
Success
Criteria
The database will be updated with the arrears payment
Alternative
Flow
None
Error Flow Amount entered is a part of an arrears payment
1. Display the message Please enter an amount received
which is not a part payment of arrears
When paying arrears separately the receipt number will be
stored in place of the revenue licence number
Business
Rules / User
Stories
Part Payment of an arrears other than those relating to
either the period before 2007-12-31 or the period after 2008-
01-01 is not allowed
Stage Stage 3

4.5 Licence Issuance for Fleets of Vehicles
4.5.1 Issuing Quotations

This user level scenario covers the steps involved in creating and printing a
quotation for a group of vehicles.

Figure 23 - Quotation Screen

Figure 24 - Print Quotation Screen

Figure 25 - Issuing a Quotation for a Fleet

Description Quotations are issued for a set of vehicles belonging to the fleet
that have either expired or renewable revenue licences. This
use case handles the addition of vehicles into the quotation,
verification of vehicles and printing of the finalised quotation
Relevant
Prototype
Figures
Figure 23 - Quotation Screen
Figure 24 - Print Quotation Screen

Main Flow 1. Initiate Quotation Request The customer hands over the
list of vehicles together with their relevant documents
2. Verify and Validate Vehicle This is done by entering the
vehicle registration number and clicking search followed by
the normal documentation verification procedure as
described in Section 4.3.1.
3. Add to Quotation The user can create the quotation by
clicking on Create Quote in the normal licence issuance
screen. This will create a quotation and add the currently
verified vehicle into it
4. Add More Vehicles to Quotation The user can add more
vehicles to the quotation by entering the registration number
of another vehicle and clicking on the Add more button.
The user can go through the same verification and validation
steps for the particular vehicle and click on Add to Quote to
add it on the currently open quotation
5. Print Quotation Once the user has iterated through all the
vehicles that need to be added into the quotation, he / she
may proceed to printing the quotation.

Success
Criteria
A quotation will be created and printed
Alternative
Flow
Add more vehicles to quotation
4a Add More vehicles: RL counter staff may add more
vehicles to the open quotation by going through the
normal verification and validation procedures
Error Flow Same error flows of main licence issuance scenario apply in
the case of adding new vehicles to the quotation
Business
Rules / User
Stories
Vehicles need to meet the mandatory documentation
requirements in order to be added to the quotation
Once a quotation is created and issued, alteration to the
composition of vehicles cannot be done
Stage Stage 3

4.5.2 Issuance of Licences for Quotation

This user level scenario covers the steps involved in issuing Revenue Licences
for a fleet of vehicles.

Figure 26 - Payment for Quotation

Figure 27 - Printing Licences for Fleet

Figure 28 - Issuance of Licences for Fleet

Description This use case describes the process followed in accepting
payment for a quotation, issuing and printing the revenue
licence
Relevant
Prototype
Figures
Figure 26 - Payment for Quotation
Main Flow 1. Initiate Fleet Activity
2. Access Fleet This is done by entering the quote ID and
clicking on the Search button in case of an existing fleet or
clicking on the Search button with an empty quote ID field
in order to view currently configured fleets. The fleet can be
accessed by clicking on the relevant fleet.
3. Proceed to Issuance If a quotation has been issued for a
set of vehicles belonging to the fleet, the user may proceed
by clicking the Pay button
4. Print Licence and Update Database Revenue licence
could be printed by clicking the relevant icon in front of each
vehicle for which the RL needs to be issued
Success
Criteria
Fleet of vehicles will be updated based on the licence issued
Alternative
Flow
None
Error Flow None
Business
Rules / User
The RL fees and fine needs to be recalculated to ensure that
the payment due is updated as of the payment date and not

Stories the date on which the quotation was given
A payment for a fleet may be made by cheque as the
primary mode of payment along with cash or credit card
If the set of vehicles that belong to the fleet needs to be
changed after a quotation has been printed, this will require
a new quotation to be created
Stage Stage 3

4.6 Correction of Past Revenue Licence Information
4.6.1 Edit / Delete Existing Revenue Licence records

This Supervisor level scenario covers the steps involved in editing existing
Revenue Licence records.

Figure 29 - Edit RL Records

Figure 30 - Edit / Delete Existing Revenue Licence Records Flow

Description This use case handles the process followed in correction of
erroneous revenue licence records. It includes editing and
deleting old revenue licence records. The errors that are
corrected are the ones caused by data entry errors of the
counter staff
Relevant
Prototype
Figures
Figure 31 - Edit RL Records

Preconditions User is logged into the system as a Superuser
Main Flow 1. Provide Details The Customer hands over their documents
to the Superuser requesting them to edit their Revenue
Licence Information
2. Validate Vehicle Number At the Initial RL screen (shown
in Figure 14) the Superuser enters the vehicle registration
number, which is validated when the Search button is
clicked or the enter key is pressed. Valid formats have been
described in Rule No. 1 of Section 3.4. This takes them to
the Main RL screen (shown in Figure 16)
3. Edit / Delete RL Details The Superuser may edit existing
vehicle information by clicking the edit button at the end of
each Revenue Licence record to enable editing of the RL
record fields. After making the necessary edits they click the
save button. To delete RL records, the delete button at the
end of a revenue licence record is clicked

Success
Criteria
If edited, the edited Revenue Licence record is successfully
stored in the database
If deleted, the Revenue Licence record status is updated to
deleted in the database
Alternative
Flow
2a Verify Vehicle Number: This is same as described in
Section 4.3.1-Alternative Flow 2a
registration number. Allow Superuser to re-enter vehicle
registration number
Business
Rules / User
Stories
Only the current days RL record may be deleted. In order to
delete RL records that are older, the Superuser must be
either an Administrator or Commissioner
Stage Stage 3

4.6.2 Add New Revenue Licence record

This Superuser level scenario covers the steps involved in adding a new
Revenue Licence record.

Figure 32 - Add RL Record Screen

Figure 33 - Add New Revenue Licence Flow

Description This use case handles the process of adding backdated
revenue licence records. This is required to remedy erroneous
revenue licence issuances
Relevant
Prototype
Figures
Figure 34 - Add new RL record
Main Flow 1. Provide Details The Customer / RL Counter Staff hands
over the documents to the Superuser requesting them to
add a new RL record
clicked or the enter key is pressed. Valid formats have been
described in Rule No. 1 of Section 3.4. This takes them to
the Main RL screen (shown in Figure 16)
3. Add New RL Details The Superuser may add new RL
record by clicking the Add Record button. After completing
the required information, they click the save button.
Success
Criteria
If edited, the edited Revenue Licence record is successfully
stored in the database
If deleted, the Revenue Licence record is marked as deleted
and saved in the database
Alternative
Flow
registration number. Allow Superuser to re-enter vehicle
registration number
Business
Rules / User
Stories
The issuance date of the Revenue Licence should be less
than or equal to the current date
Stage Stage 3

4.7 Processing Ineligible Revenue Licence Applications

This Superuser level scenario covers the steps involved in processing Revenue
Licence records that have been marked as ineligible.

Figure 35 - Approval Screen of Escalated RL Application

Figure 36 - Processing Ineligible Revenue Licence Records Flow

Description This use case describes the process followed in approving
revenue licence applications that have been escalated to the
superuser. Escalations may occur when superuser approval is
required to proceed with revenue licence issuance for
exceptional scenarios
Relevant
Prototype
Figures
Figure 35 - Approval Screen of Escalated RL Application
to the Superuser requesting them to approve their RL
in Figure 14) the Superuser can proceed by either selecting
the particular vehicle from the common queue of escalated
items or by directly entering the vehicle registration number.
When the superuser enters the vehicle registration number,
it is validated when the Search button is clicked or the
enter key is pressed. Valid formats have been described in
Rule No. 1 of Section 3.4. This takes them to the Main RL
screen (shown in Figure 16)
3. View Reason The superuser may view the reason for
escalation by clicking the status button which will display a
popup menu with the relevant reasons checked.
4. Approve Once the reason for ineligibility has been verified

manually, the Superuser approves the RL by clicking the
Approve button. The user should add a comment for
approving and click the OK button.
Success
Criteria
The ineligible Revenue Licence record is changed to verified
and the change saved in the database
Alternative
Flow
registration number. Allow superuser to re-enter vehicle
registration number
No approval comment provided
1. Display the message Please provide an approval
comment
Business
Rules / User
Stories
A RL application set as ineligible cannot proceed with
licence issuance until it is made eligible by the PDMT or by a
DS
Stage Stage 3

4.8 Edit Vehicle / Owner Information

This Superuser level scenario covers the steps involved in editing vehicle / owner
information.

Figure 37 - Superuser Tasks Screen

Figure 38 - Edit Existing Vehicle Information Flow

Description This use case describes the editing of vehicle / owner related
data from the e-RL application. This is required as a temporary
measure to deal with the delays in updating the DMT system
and inaccuracies between data of the DMT and the PDMT / DS
databases
Relevant
Prototype
Figures
to the Superuser requesting them to update their Vehicle
Information
clicked or the enter key is pressed
3. Edit Vehicle / Owner Details The Superuser may edit
vehicle / owner information by clicking the Edit button
provided that necessary documentary evidence is submitted.
The superuser may also click on Archived checkbox to
exclude the vehicle from being considered for lost revenue
calculations.

4. Add Comment and Save When the superuser clicks on the
Save button he/she will have to enter a comment before
the change is saved on the database.
Success
Criteria
The edited vehicle / owner information is successfully stored
in the database
Alternative
Flow
Edit Details
3a Update from DMT: The superuser may alternatively
update the vehicle / owner information by connecting to
the DMT system.
registration number. Allow superuser to re-enter vehicle
registration number
Vehicle registration number does not exist in local database
or central database
1. Display the message This vehicle is not available in the
database.
Business
Rules / User
Stories
Superusers will have to verify documentary evidence before
making any changes to vehicle / owner information
A vehicle can be archived if the superuser needs to exclude
the vehicle being considered for reporting purposes. This
may be done for vehicles which have been disposed of,
dismantled, destroyed etc. These reasons will be decided by
the WPDMT and appropriate action will be taken
The system needs to capture the effective date along with a
superuser comment for changes in fuel type
This is required because revenue licence fees need to be
calculated from the effective date of the transition and not
the date on which the vehicle owner comes for renewal
Stage Stage 3

4.9 Managing Transitions
4.9.1 Categorising Vehicles as Free Licenced

This superuser scenario covers the steps involved in categorising vehicles as
free licenced.

Figure 39 - Categorise Vehicle as Free Licenced

Description Free licences are issued to vehicles which belong to
government departments and institutions which meet specific
criteria. This use case describes the process followed in
categorising a vehicle into one that is eligible for free licencing
Relevant
Prototype
Figures
1. Figure 37 - Superuser Tasks Screen
Preconditions User needs to have superuser privileges to perform this task
Main Flow 1. Initiate Superuser Transaction
2. Access Vehicle Record This can be done by directly
entering the vehicle registration number into the search field
3. Classify as free licenced The superuser can classify the
vehicle as free licenced by clicking the edit button and
clicking on the Free Licence check box. The superuser will

click the Save button thereafter. The system will require the
superuser to enter the effective date and a comment before
saving any changes
4. Update database The database is updated with the fact
that the vehicle has been classified as a free licenced
vehicle.
Success
Criteria
The vehicle is classified as a free licenced vehicle
Alternative
Flow
None
Error Flow No comment added
1. Display the message Please enter a comment.
Effective Date not added
2. Display the message Please enter the effective date.
Business
Rules / User
Stories
Customers claiming for free licence eligibility to submit
required documents for verification by the superuser
Once categorised as a Free Licenced, a Vehicle will be
issued revenue licences in future at zero licensing cost until
a superuser removes this status
Stage Stage 3

Assumption 20. Verification of documents submitted for free licensing will be
done manually

4.9.2 Categorising Vehicles as Non-user Licenced

This superuser scenario covers the steps involved in categorising vehicles as
non-user licenced.

Figure 40 - Categorise Vehicle as Non-user Licenced

Description Non-user certificates are issued to vehicles which will not be
used during the licensing period. This use case describes the
process followed in categorising a vehicle into one that is
eligible for non-user licencing
Relevant
Prototype
Figures
Preconditions User needs to have administrative privileges to perform this
task
2. Access Vehicle Record This can be done either by directly
entering the vehicle registration number into the search box
3. Classify as non-user licenced The superuser can classify
the vehicle as non-user licenced by clicking the edit button
and clicking on the Non-user check box. The superuser will
click the Save button thereafter. The system will require the
superuser add a comment before saving any changes
that the vehicle has been classified as eligible for non-user
licences.

Success
Criteria
The vehicle is classified as a non-user licenced vehicle
Alternative
Flow
None
Error Flow No comment added
1. Display the message Please enter a comment.
Business
Rules / User
Stories
Customers claiming for non-user licence eligibility need to
submit required documents for verification by the superuser
Once the non-user certificate is issued the non-user status
will be cleared from the database
Stage Stage 3

Assumption 21. Verification of documents submitted for non-user licensing will
be done manually

4.9.3 Print Loose Slip

This superuser scenario covers the steps involved in printing a loose slip which is
required when transferring a vehicle to a DS of another province.

Figure 41 - Format of Loose Slip

Figure 42 - Transfer to Other Province DSs

Description Loose slips are issued when transferring a vehicle into another
province. It is a system generated document detailing the
revenue licence history of the particular vehicle and is a
mandatory requirement when allowing transferred vehicles to
obtain revenue licences from another province
Relevant
Prototype
Figures
task
Main Flow 1. Initiate Admin Transaction
or by selecting the particular transaction from among the
pending requests
3. Generate Loose Slip The superuser enters the name of
the target DS and clicks Print Loose Slip. The transfer is
affected by printing a Loose Slip addressed to the particular
DS authority
4. Print Loose Slip A Loose Slip addressed to the particular
DS will be printed along with the revenue licensing history of
that particular vehicle
Success
Criteria
A Loose slip with the revenue licensing history of the
particular vehicle is printed
Alternative
Flow
None
Error Flow Destination DS (Licence Authority) not entered
1. Display the message Please enter the Licence Authority
to which the vehicle will be transferred.

Business
Rules / User
Stories
The five last records should be displayed under the revenue
licencing history
The loose slip will be printed in the English Language only
Printing of a Loose Slip does not result in the transfer of a
vehicle. The transfer should be done by the DMT and
updated in their system in order to take effect.
Stage Stage 3

4.9.4 Blacklisting of Vehicles

This superuser scenario covers the steps involved in blacklisting vehicles.

Figure 43 - Blacklisting Screen

Figure 44 - Blacklisting Vehicles

Description Vehicles can be blacklisted due to many reasons mentioned in
section 3.6. This use case handles the process by which a
vehicle can be blacklisted

Relevant
Prototype
Figures
task

3. Classify as Blacklisted The superuser can classify the
vehicle as blacklisted by clicking on the status of the vehicle
and clicking on the checkbox corresponding to the
appropriate reason for blacklisting on the popup menu. The
superuser may add a comment and save the status
thereafter.
that the vehicle has been classified as blacklisted

Success
Criteria
The vehicle will be classified as a blacklisted vehicle and will
be denied of RL renewal until the reason for blacklisting is
rectified
Alternative
Flow
None
Error Flow None
Business
Rules / User
Stories
Refer reasons, types and rectification strategy for
blacklisting described in section 3.6
Stage Stage 3

4.10 Vehicle Activity Log

This Superuser level scenario covers the steps involved in viewing the activity log
pertaining to a particular vehicle.

Figure 45 - Activity Log Screen

Figure 46 - View Activity Log Flow

Description This use case gives the process followed in displaying a list of
activities performed with regard to a particular vehicle in read-
only mode. The activity log can be used to monitor and audit
vehicle and revenue licence related transactions

Relevant
Prototype
Figures
Figure 45 - Activity Log Screen
Preconditions User needs to have superuser privileges to perform this task
Main Flow 1. Login as Superuser
2. Validate Vehicle Registration Number This can be done
either by directly entering the vehicle registration number
into the search box
3. Retrieve Activity Log The superuser can click on the
Activity Log button to vie the actions that have been
performed on the particular vehicle. The audit log of all
activities performed on the particular vehicle will be
displayed by querying the central database
Success
Criteria
Activity Log is displayed Successfully
Alternative
Flow
None
Business
Rules / User
Stories
The activity log will contain the following details
o Date
o Updated / Added / Deleted Attribute
o User
o Old Value
o New Value
Stage Stage 3

4.11 Department of Motor Traffic Update Module

This scenario covers the steps involved in importing the details of newly
registered vehicles and updated vehicles from the DMT to the centralised
database.

The DMT web service will be accessed by this module which is hosted at the
central database. Any requests that come from DS offices seeking updates from
the DMT will invoke this module which in turn will consume the DMT web service
and retrieve the updated information.

Figure 47 - DMT Data Import Process Flow

Description This use case covers the updating and retrieval of vehicle data
from the DMT system via web services
Relevant
Prototype
Figures
None
Preconditions Data upload via web services depends on availability of
network connectivity and the DMT system availability
Main Flow 1. Invoke DMT Update This will be done by clicking the DMT
update button on the User Interface or by entering a vehicle
registration number which does not exist either in the local or
central database

2. Connect to DMT eService The DMT update application
hosted at the central database will connect to the DMT
eService
3. Retrieve Data from DMT Data will be retrieved from the
DMT system as requested by the user
4. Update Central Database The central database will be
updated with new information retrieved via the DMT web
service and sent back to the e-RL application
Success
Criteria
Updated information is retrieved from the DMT eService
successfully
Alternative
Flow
None

Error Flow If DMT Update Module cannot connect to the DMT eService,
the following message will be displayed
1. Display the message DMT eService is not available.
Business
Rules / User
Stories
Frequency of automated retrieval of data from the DMT
eService will be once in 24 hours
Stage Stage 3

Assumption 22. The DMT data feed will only have vehicles which have been
newly registered and vehicles which have undergone any
change in owner / vehicle related information

Assumption 23. There will be no user interface to invoke the DMT update

4.12 Counter Configuration

This superuser level scenario covers the steps involved in configuring a Counter.

Figure 48 - Counter Configuration Screen

Figure 49 - Configuring Licence Issuing Counters

Description This use case covers the centralised management of counters
belonging to a particular DS

Relevant
Prototype
Figures
Figure 48 - Counter Configuration Screen
Preconditions User is logged into the system as a superuser with
administrative privileges

Main Flow 1. Initiate Counter Configuration View the Counter
Configuration screen (Figure 48 - Counter Configuration)
2. Add Counter On clicking the Add Counter Range button,
a dialog box is shown allowing the user to set Counter
information (Counter number, Name) and Licence number
range. When done the user clicks the Create button
3. Search The superuser with administrative privileges enters
their search criteria and clicks the Search button which then
displays matching records in a grid below. The search
criteria will obtain the licence number range.
4. Edit / Delete Counter After matching records have been
displayed in the grid, they may be edited / deleted:
Edit - Pressing the Edit button brings up a dialog box
allowing the user to set Counter information (Counter
Number, Type) and Licence number range
Delete Pressing the Delete button deletes the counter
after confirmation
the latest information

Success
Criteria
If a counter is added, it is successfully configured and stored
in the central database
If a counter is edited, it is successfully updated and stored in
If a counter is deleted, it is successfully deleted from the
central database

Alternative
Flow
None
Error Flow Trying to add multiple counters with same counter letter
1. Display error message This counter is already
configured. Please delete it before trying to add it as
another type.
No entries matching the search criteria are found
1. Display error message No results found.

Business
Rules / User
Stories
The counter name is a text field where the administrator may
add an appropriate name
Stage Stage 3

Assumption 24. A counter configured as a Cash Counter may accept
cheque or credit card payments too. The classification is
done with the intention of improving efficiency by having
specialised counters and does not imply a limitation in the
payment types that can be handled. The payment type will be
set to cash by default for a counter configured as cash.

4.13 Holiday Configuration

This superuser level scenario covers the steps involved in configuring holidays.

Figure 50 - Holiday Configuration Screen

Figure 51 - Add New Holiday

Figure 52 - Configuring Holidays

Description This use case covers the centralised management of holidays in
order to ensure that the fee calculation logic accounts for non-
working days
Relevant
Prototype
Figures
Figure 50 - Holiday Configuration Screen
Figure 51 - Add New Holiday
Main Flow 1. Initiate Holiday Configuration View the Holiday
Configuration screen (Figure 50 - Holiday Configuration
Screen)
2. Add Holiday On clicking the Add Counter Range button, a
dialog box is shown allowing the user to set Holiday
information (Year, Month, Day, Type, Description and a
comment). When done the user clicks the Create button
which update the central database
3. Search The superuser enters their search criteria and
clicks the Search button which then displays matching
records in a grid below. The search criteria will include the
year, month and type of holiday; either National,
Provincial or DS level.
4. Edit / Delete Holiday After matching records have been
displayed in the grid, they may be edited / deleted and the
same synchronised to the central database:
Edit Pressing the Edit button brings up a dialog box
allowing the user to set Holiday information (Year, Month,

Day, Type, Description and a comment)
Delete Pressing the Delete button deletes the counter
after confirmation
the latest information

Success
Criteria
If a holiday is added, it is successfully configured and stored
in the local database and the Central database
If a holiday is edited, it is successfully updated and stored in
the local database and the Central database
If a holiday is deleted, it is successfully deleted from the
local database and the Central database
Alternative
Flow
None
Error Flow No entries matching the search criteria are found
Business
Rules / User
Stories
Holidays are classified into three levels
1. National Holidays
2. Provincial Holidays
3. DS Holidays or closure of the DS Office
Stage Stage 3

4.14 Adding Reference Data

This superuser level scenario covers the steps involved in adding reference data
to the system. The reference data types associated with the system are given
below:
Classes of Vehicles
Fuel Types
DS Authorities
Licence Status
Vehicle Status
Licence Types
Provinces
Revenue Licence Rates
Insurance Companies
VET Companies
Banks

All types of reference data can be added through an update in the central
database which will be propagated by initiating a synchronisation of reference
data from the DSs. A User Interface will be provided only for adding Insurance
Companies, Vehicle Emission Testing Companies and Banks (to be associated
with cheque payments) to the e-RL system.

Figure 53 - Initial Reference Data Screen

Figure 54 - Select Reference Data Category

Figure 55 - Add New Entry

Figure 56 - Add Reference Data Flow

Description This use case covers the addition of reference data with regard
to Insurance companies, Vehicle Emissions Testing companies
and Banks required to keep track of cheque payments
Relevant
Prototype
Figures
Figure 4.44 Initial Reference Data Screen
Figure 54 - Select Reference Data Category
Figure 55 - Add New Entry
Main Flow 1. Access Reference Data Screen
2. Select Reference Data Category The User will select
either Insurance companies, Vehicle Emissions Testing
Companies or Banks to add a new entry
3. Add New Data The new entry will be added to the local
database
4. Update Database The central database will get updated
with the latest information
Success
Criteria
New reference data is successfully added to the local
database
Alternative
Flow
None
Error Flow All data required for adding a new entry is not provided
1. Throw error message Please complete all required
fields
Business
Rules / User
Stories
Adding reference data through this user interface will be
limited to:
1. Insurance Companies
2. Vehicle Emission Testing Companies

3. Banks
Stage Stage 3

Assumption 25. Changes to reference data tables will be limited to addition of
new data. Deletion of existing data or editing will be
prohibited due to its impact on a large number of past records

4.15 User Account Management
4.15.1 Create / Edit / Delete User Account

This Superuser level scenario covers the steps involved in managing user
accounts.

Figure 57 - User Management Screen

Figure 58 - Add User Screen

Figure 59 - Managing User Accounts

Description This use case covers the creation, editing and deletion of users.
These tasks will be carried out by a superuser with
administrative privileges at the PDMT. DSs will not be allowed
to create, delete or edit user accounts.
Relevant
Prototype
Figures
Figure 58 - Add User Screen

Preconditions User is logged into the system as a superuser having
Main Flow 1. Access User Account Management The superuser
accesses the Main User Account Management screen
(Figure 57 - User Management Screen).
2. Search Users The superuser enters the criterion to search
by and clicks the Search button. Search can be done based
on a particular login name, user name, user role or authority.
3. Update / Delete User Account After locating the user
account to be updated / deleted, the Superuser may:
Update user account - Click the Edit button and an Edit
screen is brought up from where the user account may be
updated. Password reset is also possible from here

Delete user account Click the Delete button and the
user account is deleted after confirming whether to delete
the account
4. Update Database The modifications / deletions of user
accounts will be updated in the central database

Success
Criteria
The Potential user is able to successfully login to the e-RL
system
Alternative
Flow
Create User Account
2a At the Main User Account Administration screen
the Superuser clicks the Add User button and is asked
to enter the required details (Figure 58 - Add User
Screen) for the new user account and clicks the Ok
button. This is immediately updated in the Central
database
View Activity Log
2b The superuser clicks the View Activity Log button
for the User they wish to view the Activity Log for which
brings up the Activity Log. They click the Close button to
go back to the User Account Management screen

Error Flow Trying to create a new user account with an existing Login
name in the same DS
1. Display error message This Login name already exists.
Please enter another one
No entries matching the search criteria are found
Passwords do not match when creating a user account
1. Display error message Passwords do not match. Please
re-enter the password and clear the Password and Re-
enter Password fields
Password does not satisfy password policy
1. Display error message Inadequate Password Strength

Business
Rules / User
Stories
The following are the user roles available in the system:
Commissioner
PDMT Administrator
DS Administrator
PDMT Supervisor
DS Supervisor
Mobile User
Lookup User
Operator This role applies to both PDMT and DS
counter staff
The request for a new user account will be handled as per
the guidelines of the procedure mentioned in section 4.1

The request for the creation of a mobile user account or
lookup user account will be handled by a manual process.
Users at DS will have to initiate an update from their end to
synchronize with the central database

Stage Stage 3

4.15.2 User Account Password Modification

This user level scenario covers the steps involved in changing a users
password.

Figure 60 - User Account Password Modification Screen

Figure 61 - Password Modification

Description This use case covers the password modification by individual
users at PDMT / DSs of the e-RL application
Relevant
Prototype
Figures
Figure 60 - User Account Password Modification Screen
Preconditions User is logged into the system as an Administrator or a
Commissioner
Main Flow 1. Initiate Password Change The User accesses the
password change screen by clicking on their name on that
screen (Located in the top right hand corner of the window)
2. Change Password The User enters their current password,
and then their new password twice in the boxes provided
and clicks the Change Password button. This updates the
local database
3. Synchronise with database The new password is
synchronised to the local database

Success
Criteria
The Users password is successfully changed and the same
stored in the local database and the Central database
Alternative
Flow
None
Error Flow Current Password Incorrect
1. Throw error message Your current password is
incorrect. Please enter the correct current password
New Passwords do not Match
1. Throw error message Your new passwords do not
match. Please re-enter
Password does not satisfy password policy
1. Throw error message Inadequate Password Strength
Business
Rules / User
Stories
Password policy should be enforced
1. Password will need to be renewed every three
months
Stage Stage 3

Assumption 26. Users are responsible for adopting strong passwords to
mitigate the possibility of their passwords being
compromised.

4.16 Reporting

This scenario covers the steps followed by authorised users in the PDMT or DS
when generating reports.

Figure 62 - Reporting Screen

The format of the report will follow the following template layout.

Figure 63 - Standard Reporting Template

Figure 64 - Generating Reports

Description This use case describes the reporting functionality available
through the e-RL application. It covers the retrieval of data from
either local or central database and the display of reports based
on agreed upon formats
Relevant
Prototype
Figures
Figure 62 - Reporting Screen
Main Flow 1. Access Reports Screen
2. Select Report The User selects the required report and
specifies the criteria for that particular report. The list of
available reports and their input / out fields are listed out in
Table 16 - Reports Provided by e-RL Application
3. Extract data from Database The data needed for the report
will be extracted from the database of the PDMT / DS. Data
may have to be retrieved wither from Central or Local
database based on the type of report selected
4. Preview Report A preview of the report will be displayed to
the user after which it can be printed
Success
Criteria
The required report is displayed and printed successfully
Alternative
Flow
None
Error Flow Input field not specified
1. Display error message Please specify values for
relevant input fields
Business
Rules / User
Stories
All input/output criteria have been defined in Table 16 -
Reports Provided by e-RL Application
The Lost Revenue Report at Province Level and the

Synchronisation Status Report are only available to the
PDMT administrator

Stage Stage 3

The following reports will be accessible to superusers at PDMT / DSs.

Report Name Description Input Fields Output Fields
Detailed Report Get detailed report of all
transactions carried out by a
particular counter for a
particular day
Counter, date Serial No., Reg. No.,
Prev. Licence No.,
New Lic. No.,
Duration, Type, Fee,
Fine, Cash, Cheque,
Total
Summary
Report
Summary of all transactions
for each counter on a
particular day
Date Counter, User (last
logged in), Vehicles
Count, Fee, Fine,
Cash, Cheque, Total
Summary
Report based
on vehicle
categories
The number and value of all
licence issued between two
dates per class of vehicle
Date range Class of Vehicle,
Licences Count, Fee,
Fine, Total
Non-licenced
Report
New vehicle registrants who
havent obtained revenue
licence within 3 months of
registration
None Reg. No., Name,
Address, Registration
Date
Other Income
Report
Arrears collected between
two dates grouped by the
first part of the licence plate
number (e.g. GA or 301)
Date range Reg. No., Licence
No., Duration, Fee,
Fine, Cash, Cheque,
Total
Special Licence
report
Includes details of other
authority licences (other
DSs), free licences and
licences for vehicles with
fuel conversion between two
dates. Note that the report
can be sorted based on
licence authority, licence no.
or date
Date range,
sort criteria
Year, Reg. No.,
Licence expiry,
Licence No.,
Authority, Issued
Date, User
Deleted Report
Other
authority
Report of deleted records of
vehicles belonging to other
licence authorities
None Deleted Date, User,
Reg. No., Licence
No., Expiry date,
Inserted User,
Authority, Inserted
Date
Deleted Report Report of deleted records None Deleted Date,

Licence and
Arrears
relating to arrears and
licence records
Deleted User, Reg.
No., Licence No.,
Amount, Fine,
Inserted User,
Inserted Date
Lost Revenue
Report (DS
Level)
Report of Vehicles for each
DS for which Revenue
licences have not been
obtained
DS authority Reg. No. (Grouped
by first part of
registration number),
Licencing Years (Last
four years will be
listed separately
while balance years
are grouped
together), Fee, Total
Fee
Lost Revenue
Report
(Province
Level)
Summary of number of
vehicles and lost revenue for
each DS
None Authority, Licencing
Years (Last four
years will be listed
separately while
balance years are
grouped together),
Total, Count
Synchronisation
Report (only for
PDMT)
Report of synchronisation
status of DSs within the
province. The DSs which
have had not had a
successful synchronisation
within the last 24 hours
should be highlighted
None DS, Synchronisation
start time and end
time of latest
synchronisation job,
Synchronisation
Status
Table 16 - Reports Provided by e-RL Application

Assumption 27. If two transactions relate to one vehicle (e.g. Normal issuance
and reissuance), it should be counted as one vehicle but two
licence transactions.

Assumption 28. This Use case includes reporting functionality within the local
authority. Centralized reporting at provincial level is out of
scope and thus has been added to section 8.3 as further
enhancements

4.17 Non-Western Province DS Data Upload

This scenario covers the steps involved in uploading RL data of non-Western
Province DSs through the Data Upload Application.

Figure 65 - Non-WP DS Data Upload Screen

Figure 66 - Non-WP DS Data Upload Flow

Description The use case covers the uploading of non-Western Province
DS data into the central canonical database
Relevant
Prototype
Figures
Figure 65 - Non-WP DS Data Upload Screen
Preconditions The data uploaded should adhere to a pre-defined format
Main Flow 1. Initiate Data Upload This is done by launching the non-WP
DS data upload application
2. Upload Data Browse the file containing the non-WP DS
data from the WPDMT. Click on the Upload button
3. Validate Data Data will be validated to make ensure that it
adheres to the pre-defined format
4. Update database Update central database with validated

records that do not violate the integrity of the canonical
database
Success
Criteria
Non-WP data is uploaded successfully
Alternative
Flow
None
Error Flow Input file not specified
1. Throw error message Please select file to upload
Incorrect format of data file
1. Throw error message The format of the file selected for
upload is different from the required format
Business
Rules / User
Stories
Inconsistent data will be cleansed through a manual process
and not handled by the system
Stage Stage 2

4.18 Staff Lookup Portlet Scenarios

This scenario covers the steps followed by authorised users in the PDMT, DS or
any other government institute to lookup vehicle details from the central
database.

Figure 67 - Lookup Portlet Welcome Screen

Figure 68 - Login Screen to Lookup Portlet

Figure 69 - Lookup Vehicle Registration Number

Figure 70 - Details of Vehicle

Figure 71 - Lookup Portlet for DS/WPDMT Staff

Description This use case covers the lookup functionality provided by the e-
RL lookup portlet
Relevant
Prototype
Figures
Figure 68 - Login Screen to Lookup Portlet
Figure 69 - Lookup Vehicle Registration Number
Figure 70 - Details of Vehicle
Preconditions User has to be authorised to access the lookup portlet
Main Flow 1. Access the Lookup Portlet on the Country Portal
2. Login to the Lookup Portlet DS/WPDMT staff will be
provided with user accounts to access the Lookup portlet
hosted on the country portal and perform lookups on the
database
3. Enter and validate vehicle registration number Ensure that
the entered vehicle registration number adheres to the
correct format
4. Retrieve information from the central database
Success
Criteria
Vehicle related information and status of revenue licence will
be displayed on the portlet
Alternative
Flow
None
Error Flow Vehicle registration number does not exist in central
database
Incorrect format of vehicle registration number
Business
Rules / User
Stories
Vehicle should be registered with the DMT and have at least
one revenue licence in order to have a successful lookup
The user accounts created for lookup will be different from
the normal e-RL user accounts. These user accounts will
belong to a special role named Lookup User
The following revenue licence related information will be
displayed as a result of a successful lookup;
1. Status of the Revenue Licence (either valid,

renewable or expired)
2. Owner Name
3. Vehicle Details
i. First Registration Date
ii. Province
iii. Fuel Type
iv. Vehicle Class
4. Revenue Licences History Table (List of RL obtained)
This will include the Year, Licence No., Issued Date,
Expiry Date, Authority, Fee, Fine, Total and the Type
of Licence
The portlet will be maximised when displaying the results
unless otherwise minimized by the user.
If the vehicle is blacklisted, a statement to that affect will be
displayed at the beginning of the lookup results
The five last records should be displayed under the revenue
licencing history
Stage Stage 2

Assumption 29. A thorough evaluation of the persons being granted access is
recommended to avoid compromising the security of sensitive
information.

4.19 Country Portal eCitizen Scenarios
4.19.1 Revenue Licence Renewal via e-RL portlet

This scenario covers the steps followed by eCitizens to renew their vehicle
revenue licence via the e-RL portlet of the Country Portal

Figure 72 - e-RL Portlet Welcome Screen

Figure 73 - Add Vehicle Screen

Figure 74 - Confirm Vehicle Addition Screen

Figure 75 - Proceed to Renewal Screen

Figure 76 - RL Renewal via Portlet

Figure 77 - Payment Confirmation Screen

Figure 78 - RL renewal via e-RL portlet

Description This use case describes the renewal of revenue licences via the
e-RL Renewal Portlet of the Country Portal
Relevant
Prototype
Figures
Figure 72 - e-RL Portlet Welcome Screen
Figure 73 - Add Vehicle Screen
Preconditions User is logged into the country portal
Main Flow 1. Initiate revenue licence renewal This is done by clicking on
the Renew Licence button on the initial screen
2. Validate Vehicle Reg. No. and Chassis No. This is done by
adding Vehicle Registration number, Chassis No. and
Previous Licence no.
3. Confirm Address of Owner The eCitizen needs to confirm
that the details are accurate and that the revenue licence will
be posted to the registered address of the owner
4. Lookup details of registration number and resolve availability
previous licence
5. Verify validity of emission testing results and indicate same
6. Verify validity of insurance certificate for the given
registration number and indicate same
7. If above tests are satisfied, calculate arrears/fines/issuance
fee
8. Re-direct eCitizen to Credit Card Payment Gateway
9. Process credit card payment
10. Send RL issue request to Print and Post counter This will
be queued in the workflow and can be processed by the
Print and Post counter staff at the PDMT.
11. Issue, print and post revenue licence Issuance and printing
will be done by counter staff via the e-RL application while
posting will be a manual workflow which is out of scope
Success
Criteria
A new Revenue Licence request is made and recorded in
the database to be printed and posted by the WPDMT
Alternative
Flow
None
Vehicle registration number does not exist in central
database
Revenue Licence is not renewable for given vehicle
registration number
Verification of insurance returned invalid status
Verification of VET returned invalid status
The particular class of vehicle requires fitness certificate /
route permit and is not supported by the e-RL Renewal
Portlet
Failure in processing credit card payment

Business The following criteria should be met for the revenue licence

Rules / User
Stories
to be renewable:
1. Vehicle should be registered with the DMT and have
at least one revenue licence
2. Vehicle should have a valid vehicle insurance
certificate Validity is resolved by having an
insurance expiry date which is greater than or equal
to the date of renewal
Vehicles having free licences may not be renewed via the
portlet
Vehicles that have undergone a fuel type conversion need to
visit the PDMT
Revenue Licence reissuance is not possible via the portlet
Vehicles requiring route permits/fitness certificates cannot
renew their revenue licences via the e-RL portlet
Non-user revenue licence issuance is not possible via the
portlet
Vehicles that have been classified as ineligible by a DS or
PDMT due to not meeting the criteria required for renewal
shall not be able to renew via the e-RL portlet
The system should not account for national, provincial
holidays and times when calculating the due date for
revenue licence renewal (because the e-RL Renewal Portlet
is available on internet regardless of holidays)
The Revenue Licence will be posted to the registered owner
of the vehicle (as stated in the book of the vehicle) and not
the current user (if different to the registered owner)
Stage Stage 4

Assumption 30. The address to which RL will be posted is the address on the
vehicle registration book. Therefore, it is the responsibility of
the eCitizen to ensure that the certificate of registration is
updated with his current address.
Assumption 31. The vehicle registration number, chassis number and the
previous licence number will be the only inputs required to
permit an eCitizen to renew the RL of a vehicle.

4.19.2 Issue RL for e-RL Portlet Requests

This scenario covers the issuance and printing of RL for requests that come via
the e-RL portlet (see section) of the country portal.

Figure 79 - Issue RL for e-RL portlet requests

Description This use case covers the issuance of revenue licence for
requests that come from the e-RL Renewal Portlet of the
Country Portal. This process will be handled by a separate
counter at the WPDMT
Relevant
Prototype
Figures
Preconditions User is logged in as Print and Post Staff
Main Flow 1. Access e-RL application
2. Select Pending Request Pending Requests will be
displayed in the initial screen (Figure 14 - Initial RL Issuance
Screen for RL Counter Staff)
3. Issue Licence This will issue the licence for a pending
request for which all verifications have been done via the e-
RL portlet and payment has been made through the credit
card
4. Update database Database will be updated with the
issuance of the RL for the particular vehicle
5. Print RL The revenue licence will be printed and
subsequently posted to the vehicle owner

Success
Criteria
A Revenue Licence will be successfully printed

Alternative
Flow
Cancel Printing
licence will be printed subsequently. Thereafter, the user will
be shown a dialog box inquiring if printing was successful. If
during / after printing there is found to be a problem with the
printed licence, e.g. the licence did not print properly, then
counter staff may confirm the same by clicking No in the
dialog box. Takes the user back to the Final RL Issuance
Screen . Here the RL number is incremented but the field is
also left editable for counter staff to edit if required. They
may then issue and print the licence again as earlier
Error Flow None
Business
Rules / User
Stories
N/A
Stage Stage 4

Assumption 32. Posting of printed RL is not part of the e-RL system and will
be handled as a separate manual process by the Print and
Post staff at the PDMT

4.20 Mobile Lookup Scenario

This scenario covers the steps followed by authorised mobile users in retrieving
revenue licence information via SMS.

Figure 80 - Text Message for Mobile Lookup

Figure 81 - Successful Response for Lookup

Figure 82 - Unauthorised Access

Figure 83 - Service Failure

Figure 84 - Non-existent Vehicle

Figure 85 - Mobile Lookup of RL details

Description This use case describes the lookup of revenue licence related
information by authorised mobile users via SMS
Relevant
Prototype
Figures
Figure 80 - Text Message for Mobile Lookup
Figure 81 - Successful Response for Lookup
Figure 82 - Unauthorised Access
Figure 83 - Service Failure
Figure 84 - Non-existent Vehicle
Preconditions User has to be authorised to retrieve information via SMS
Main Flow 1. Send SMS with the vehicle registration number The
message should adhere to the defined format. The SMS
should be sent to a short code which is assigned to all
government services
2. The SMS request will invoke the lookup web service at the
central database and provide the registration number.
3. Retrieve information from the central database.
4. Send the vehicle information along with revenue licence
status to the mobile user via SMS
Success
Criteria
Vehicle related information and status of revenue licence will
be received by the authorised mobile user
Alternative
Flow
None
Error Flow If licence plate number is invalid the following message will
be returned to the user
Invalid vehicle number format
If service is not available the following message will be
returned to the user
Service unavailable
Incorrect format of text message will lead to no response
being received
If mobile user is not authorised
Your mobile number is not authorised to use this
service
If vehicle registration number does not exist in central
database the following message will be displayed
Vehicle number not found
If the message does not adhere to the correct format, the
following message will be displayed
Cannot understand your request. Please check
the message and resend
Business
Rules / User
Stories
The text message to be sent should adhere to the following
format;
ERL VEH <vehicle registration number>
where:
ERL Service Provider (In this case eRevenue Licence)
VEH Service Name (Vehicle lookup service)

Vehicle Reg. No. should adhere to the correct format
(excluding province prefix)
Vehicle should be registered with the DMT and have at least
one revenue licence
Any person whose mobile number has been authorised may
perform a lookup from the central database
The response will be of the following format:
<vehicle registration number>, <authority>:<revenue licence
number>, from <DD/MM/YYYY> to <DD/MM/YYYY>, <full
name>, <city>
If the full name exceeds the total number of characters
available, it will be truncated to fit into the available number
of characters after the other data fields have been
considered
Stage Stage 2

Assumption 33. The exact syntax will be constrained to that which is
supported and permitted by the SMS or MPG gateway.

4.21 Canonical Database

A canonical database should be designed based on the legacy databases at the
WPDMT and all other Western Province DSs. The new canonical database will
later be deployed both as the central database at the LGN-IDC and at the PDMT
and DSs. It will be designed to encapsulate the current level of information being
held in the database. Designing the new canonical database schema includes
preparing the complete data dictionary with each of different source legacy data
column information as well. This is very important as the canonical databases
and the Central database mostly rely on legacy data that will go through severe
cleansing and consolidation.

Assumption 34. The database provided for the purpose of analysing the
current schema is complete and comprehensive. There will
be no additional data that are different to the current schema.

4.22 Data Migration

Migration involves the process of transforming and transferring existing data from
the legacy databases at the WPDMT and other Western Province DSs. The
following description summarise the data migration development methodology
and the steps taken to progressively analyse, script and schedule the transfer
job.

Implement Capture Assess Design Test Deploy

Step Action
1. Capture Capture legacy data structure, DS Process, new canonical database
structure, future requirements and trends
2. Assess Assess mappings, importance of data, consolidation requirements,
quality of data and cleansing requirements and get stakeholder
approval
3. Design Design the mapping tables, flow of data , look ups, cleansing,
consolidations, synchronisation module and synchronisation services
4. Implement Implement migration views, web services and web service calls, audit
scripts, active monitoring, performance tuning
5.Test Test application data validity, data integrity checks, data constraints
checks, data dictionary mismatches, Perform a full system test to
confirm that migrated data behaves as expected and get stakeholder
acceptance
6.Deploy Deploy the solution, monitor activity and audit reports

Assumption 35. All 40 DSs will have the same database structure. Any
inconsistencies among DS data may require rework on the
migration scripts and will be carried out as a change request.

The migration task implemented for this project is not generic and depends on
the structure of the source database. A migration plan will be provided, detailing
the approach and steps to be followed when performing a migration. Inconsistent
data will be identified and segregated without being migrated to protect the
integrity of the new canonical database.

The following table deals with the data integrity constraints encountered in the
data migration process and the methodology of handling them.

Data Integrity Constraint Strategy
Revenue Licence records without
vehicle records in the DS
database
Ignored during migration
Revenue Licence records without
some vehicle / owner related
details
It will be migrated and flagged, so that the
next time it is accessed for renewal missing
details can be completed
Vehicles having an null value or
an unrecognised value for one of
the following:
Fuel type
Class of vehicle
Tare / Gross Weight
Migrated with dummy record and changed to
a appropriate value upon renewal
Empty of non-existent values for
local authority
Migrated with dummy record and changed to
a appropriate value upon renewal
Vehicles in DS databases but not
in WPDMT database
All vehicles are expected to be having a
record in the WPDMT database due to the
fact that the first revenue licence is issued at
the WPDMT. However, in instances where
vehicle records exist in a DS database but
not in the WPDMT, it will be migrated as a
separate vehicle. This scenario is caused
due to a relaxation of the requirement to
obtain the first revenue licence from the
WPDMT
Same vehicle exists in both
WPDMT and DS databases
If the DS database has the latest revenue
licence records, the WPDMT records will be
replaced by it
If the WPDMT database has the latest
records, it will be migrated in place of the old
DS database records
Table 17 - Data Migration Constraints and Strategies

4.23 Synchronisation of Databases

Synchronisation is the process of maintaining consistency of the central
database with any changes that have taken place at the DS databases. Changes
may include addition, deletion or editing of records. Automated synchronisation
will only take place from the DSs to the central canonical database while the
reverse process may take place on-demand (if initiated by DS).

This scenario covers the steps followed in synchronising between the canonical
database at the DS/PDMT and the central canonical database.

Assumption 36. Synchronisation will be done from the WPDMT and other
Western Province DS Databases to the central canonical
database. Synchronisation between the legacy database and
the canonical database will not be required.

Figure 86 - Data Synchronisation

Relevant
Prototype
Figures
None
Preconditions Synchronisation settings should be configured prior to the

initiation of this process
Main Flow 1. Initiate Synchronisation The synchronisation will be
automatically initiated at pre-defined time intervals
2. Identify Updated / Deleted / New RL information The first
task is to identify the exact records which have been either
updated, added or deleted from the database to be
synchronised
3. Transfer data to Central database The data to be
synchronised will be transferred to the central database
through the transmission service
4. Transmission of Payload The transmission service will
handle error correction and verify the integrity of the data
being transmitted
5. Update Destination Database The transmitted
synchronisation data will be updated on to the central
canonical database
Success
Criteria
The central canonical database have been successfully
synchronised
Alternative
Flow
None
Error Flow The transmission service will be responsible for handling
error conditions in the transmission service
Business
Rules / User
Stories
The preferable frequency of synchronisation is once a day
Stage Stage 3

5 Non-functional Requirements
5.1 Performance Requirements
5.1.1 e-RL Application

Number of Concurrent
Users at PDMT
12 Concurrent Web Based Users
Number of Concurrent
Users at DS
5 Concurrent Web Based Users
Processing Time of
Normal Issuance
1 minute 30 seconds for the average case (without any
exception handling)
Response Time Result of an interaction has to be visible within 5 sec max
except for LIX eService based interactions

Assumption 37. The times indicated above does not include the latency in
making a web service call to third party service providers
(Insurance, VET etc.) for verification of mandatory
requirements. A maximum latency of 5 seconds from the
eServices is required to meet the above requirements.

5.1.2 e-RL Portlet

Number of Concurrent 40 Concurrent users
Response Time Result of an interaction has to be visible within 5 sec max
except for LIX eService based interactions

Assumption 38. Response time for e-RL portlet is the time consumed from the
point of initiating a RL renewal to the point where a reference
token is provided for a successful transaction. Initiation of RL
renewal is defined as the entering of vehicle registration
number for renewal.

5.2 Compatibility Requirements
5.2.1 Machines of eCitizen

The machine compatibility requirements below are used to test the access by the
Citizen of the country portal.

HTML Versions to be Supported
Version 4.0
Browser Versions to be Supported
Firefox 3.0, Internet Explorer 7
Platform Version to be Supported
Windows XP SP2
Windows Vista
Ubuntu 9.04

Assumption 39. It is assumed that most people with internet access are using
Windows XP SP2, Vista or Ubuntu. The scope of testing will
be restricted to these OSs.

5.2.2 DS / PDMT Counter Clients

The machine compatibility requirements below are that which is expected at the
counters that mainly will only be using the eRL application through a web
browser. DS Offices complained on Virus issues maintaining their Windows XP
machines and it was recommended to adopt a Free and Open Source Linux
distribution such as Kubuntu. ICTA has suggested that most people would be
more comfortable in Kubuntu due to its similarity with the Windows user
interface. These machines can also be very basic as only a browser is needed.

Version 4.0
Firefox 3.0
Kubuntu 9.04

Assumption 40. It is assumed that ICTA or WPDMT will be providing and
maintaining all required hardware machines and OS
dependencies for the e-RL application.

5.2.3 DS Superuser Machines

The machine compatibility requirements listed below are those which are
expected to be with the Superusers at the DS. The superusers commonly use
their computers for multiple applications which are mostly based on Microsoft
Windows.

Version 4.0
Firefox 3.0
Windows XP SP2

Assumption 41. The above superuser machines will only be executing the
Correction of Past Revenue Licence Data flows (see Section
4.6) and the Processing of Ineligible Applications flow (see
Section 4.7). These flows will be tested and validated under
the above mentioned specifications

5.2.4 WPDMT Superuser Machines

The machine compatibility requirements listed below are those which are
expected to be with the Superusers at the WPDMT.

Version 4.0
Firefox 3.0
Kubuntu 9.04

5.2.5 DS Office Server

The compatibility requirements for the server machines are given below, however
the power of the machine is expected to change with the amount of data the DS
is managing. In DS offices, the server is also expected to dually operate as one
of the counter clients and in DS office with just one counter will be the sole client
and server

Version 4.0
Firefox 3.0
Database Versions to be Supported
MySQL 5.1
Kubuntu 9.04

5.2.6 WPDMT Office Server

The compatibility requirements for the server machine are given below. The
WPDMT Server is expected to be a enterprise grade machine that can handle a
large amount of data for the western province.

Version 4.0
Firefox 3.0
Database Versions to be Supported
MySQL 5.1
Kubuntu 9.04

5.3 Usability Requirements

The new e-Revenue Licence application should meet the following usability
requirements:

The RL issuance interface for the normal flow should be designed to
eliminate the use of both vertical and horizontal scroll bars
Normal user interface should display all screen elements required for the
issuance of revenue licence on one screen
The colour scheme used in the interfaces should be soothing to the eye
and minimise strain during continuous usage
Drop down and option lists should be used whenever information is
available on the database to minimise data entry errors by the users
Font sizes of the display elements on the interface should be readable
Switching between input fields on the RL issuance screen should be
supported with convenient keyboard shortcuts

Assumption 42. e-RL application user interface should be tailored to the
English language version. The Sinhala and Tamil language
versions may require further modifications for display
consistency
Assumption 43. Application will be self intuitive as much as possible.
Documentation will be provided as described in section
Error! Reference source not found. for the places where
the users are required to have some knowledge about the
terminology

5.4 Internationalisation and Localisation Support

Internationalisation support will be provided for both portlets and the e-RL
application. Tri-lingual localisation will be done for the e-RL application and the e-
RL portlet of the Country Portal.

Localisation support at the database level will be provided by maintaining an
additional column to hold the preferred language translation for each of the
vehicle owner data fields given below:
Name
Address
City

The implementation of database localisation support will be limited to the scope
mentioned in the table below:

e-RL Application
The localised data in the database will be brought only
up to the service layer. The user interface will display the
data in the English language only.
e-RL Lookup Portlet
If the language selected by the lookup user (through the
Country Portal) is the same as the citizens preferred
language, the data fields identified above will be
displayed in that language. If data pertaining to that
particular language is not available in the database, the
data should be displayed in the English Language
e-RL Online Renewal
Portlet
If the language selected by the citizen (through the
Country Portal) is the same as the citizens preferred
language, the data fields identified above will be
displayed in that language. If data pertaining to that
particular language is not available in the database, the
data should be displayed in the English Language

Assumption 44. Any Sinhala/Tamil translation for the terms used in the
application will be tested and reviewed by ICTA.

5.5 Security Requirements

The following tables groups the data by the roles and what CRUD (Create, Read,
Update and Delete) permissions each role might have per each of these data
groups. The data is segregated by the DS and location, thus certain types of
access by the user, would be restricted to his DS. Special circumstances are
noted are annotated and referenced below the table.

5.5.1 Data Access for WPDMT Users

The table below provides the access levels to data groups for WPDMT users
only and also indicates data owned by the Department of Motor Traffic.

Data Group
WPDMT
User
WPDMT
Supervisor
System
Admin
Commissioner DMT
Current Vehicle
Details
R RU
1
RU
1
CRUD
3

Current Owner
Details
R RU
1
RU
1
CRUD
3

New Revenue
Licences
CR RU
4
RUD
Old Revenue
Licences
R CRU
4
CRUD
4

Insurance, VET,
Fitness Cert,
Route Permit
Checks
CR CRU CRU
Licence Fee /
Arrears
R R RU
5

Fleet Details CRU CRU CRUD CRUD
Black Listing of
Vehicle
R CR CRU CRU
Access Control
(Users)
CRUD CRUD
Table 18 - Data Access for WPDMT Users

Notes on special cases:
1. Superusers can update this only once provided sufficient documentary
evidence is provided (e.g. MT76 and MT11 forms)
2. Access in DMT is as per their own business process
3. Updating can only happen whilst the new revenue licence is processed
4. For correcting of erroneous records provided sufficient evidence is
presented

5. The commissioner can only remove fines on arrears payments due for a
particular vehicle. However, this will be done by a manual process by
granting approval, upon which the counter staff may remove the arrears

Assumption 45. The final matrix above will be the outcome of the Project
Steering Committee decision.

5.5.2 Data Access for DS Users, eCitizens and Police

Data Group DS
User
DS
Supervisor
Lookup
User
eCitizen Police
Mobile
Current Vehicle
Details
R R R R
Current Owner
Details
R
3
R R
3
R
New Revenue
Licence
CR CRU
1,2
R R
Old Revenue Licence
History
R RU
2
R R
Insurance, VET,
Fitness Cert, Route
Permit Checks
CR CRU
2
R
R (as valid
only)
R
Licence Fee / Arrears R R R
R (totals
only)

Fleet Details CRU CRU
2

Black Listing of
Vehicle
R R R R R
Table 19 - Data Access for DS users

1. Updating can only happen whilst the new revenue licence is processed
2. For correcting of erroneous records provided sufficient evidence is
provided
3. Read access to the owner and owners address details will be removed
from the lookup to avoid potential threats due to password disclosure
especially at the DS level

5.5.3 Action vs. Access Matrix for Business Process

The following table gives the main actions as performed and the users access to
perform that action. An X marks the authority to perform the action.

Action User WPDMT
Supervisor
DS
Supervisor
WPDMT
Admin
Commissioner
Normal Licence
Issuance
X
Issue Free Licence X
View Licence Record X X X X X
Re-Issuance X
Editing Vehicle
Information
X
1
X
1

Editing Owner
Information
X
1
X
1

Insurance, VET,
Fitness Cert, Route
Permit Checks
X X X X
Remove Fines X
Approve Ineligible
Licences
X X X
Print Quotation for
Fleet
X
Change Password X X X X X
User Management X X
Process Payment /
Print Licence
X
Table 20 - Action vs. Access Matrix for Business Process

1. Superusers can update this only once provided sufficient documentary
evidence is provided (e.g. MT76 and MT11 forms)

5.5.4 Action vs. Access Matrix for Administrative Functions

The following table gives the main actions as performed and the users access to
perform that action. An X marks the authority to perform the action.

Action Supervisor /
Admin (DS)
Supervisor
(WPDMT)
Admin
(WPDMT)
Commissioner
(WPDMT)
Counter Configuration X
1
X
1
X
1
X
1

Holiday Configuration X
1
X
1
X
1
X
1

Black Listing of
Vehicles
X X X
View User Activity
Logs
X X X
Generate Reports X
1
X X X
User Account
Management
X X
Table 21 - Action vs. Access Matrix for Administrative Functions

1. Action will be constrained to the DS office Data

5.5.5 Data Storage Security

The system should meet the following requirements with regard to data security:
1. Users not having administrative privileges should not be able to directly
access the database
2. Only authorised users should have access to the web server and the
computer hosting it
3. Data packets used for database synchronisation will be checked for data
integrity at the destination
4. All changes to revenue licence records in the database will be captured in
an activity log
5. Complex password policies should be enforced during the creation and
modification of user accounts
6. All passwords stored in the database should be hashed and there should
be a password policy
7. Certain fields in the database will be encrypted to prevent potential abuse
by middle man attacks and unauthorised direct access to the database.
The suggested data fields for this are:

User password
Chassis Number
Engine Number
Owner name
Owner address

5.5.6 Data Communication Security

The system should meet the following requirements with regard to data
communication security:
WS-security policies
All communication to external systems should occur through web services
Communication between the country portal, SMS gateway (stubbed) and
CCPGP (stubbed) should be encrypted and digitally signed
Communication security for external systems will depend on the WS-
Security policies enforced by the respective systems
The system will not be responsible for the data communication security of
the mobile communication network

5.6 Scalability

The system should be scalable enough to be deployed in all of the Divisional
Secretariats of Sri Lanka in the future, thought the current scope of work will be
restricted to the Western Province. The number of nodes that can be added to
the system will only be limited by infrastructural constraints.

5.7 Maintenance Requirements

The business rules and logic governing the issuance of revenue licences should
be maintainable.

Assumption 46. The maintenance of certain central administrative tables,
such as class of vehicles, fuel types, etc will be handled
directly by the maintenance team as modifications in the
database, especially those requiring changes on a Gazette
notification or that which would change annually.

5.8 Applicable Standards

The e-RL web application and the portlet need to adhere to the following
standards.

W3C Web Accessibility Standards
I. Images and animations. Use the alt attribute to describe the
function of each visual
II. Image maps - Use the client-side map and text for hotspots
III. Multimedia - Provide captioning and transcripts of audio, and
descriptions of video
IV. Hypertext links - Use text that makes sense when read out of
context. For example, avoid "click here"
V. Page organisation - Use headings, lists, and consistent structure.
Use CSS for layout and style where possible
VI. Graphs and charts - Summarise or use the longdesc attribute
VII. Scripts, applets, and plug-ins - Provide alternative content in case
active features are inaccessible or unsupported
VIII. Frames - Use the noframes element and meaningful titles
IX. Tables - Make line-by-line reading sensible. Summarise
X. Check your work - Validate. Use tools, checklists, and guidelines at
http://www.w3.org/TR/WCAG

Base Content

I. XHTML 1.0 The Extensible HyperText Mark-up Language
(Second Edition) http://www.w3.org/TR/xhtml1/
II. Doc Type XHTML-1.0-Transitional
III. CSS 2.0 http://www.w3.org/Style/CSS/
IV. JavaScript 1.1

e-RL application should support UTF-8 encoding standard

5.9 Intellectual Property Requirements
5.9.1 Copyright Requirements

ICTA will hold the copyright for code and deliverables. ICTA requires the
exclusive right to modify and redistribute any of the deliverables of this project.
Third party software and frameworks will be subject to their own copyright.

5.9.2 Licensing Requirements

ICTA should have the right to redistribute the source code and the binaries. ICTA
should also be able to modify the source code and release/ redistribute the
modifications. Replication of the RL application across DSs should be possible
with zero licensing costs.

5.9.3 3
rd
Party Software Utilisation

Typical licences that will be permitted for the 3
rd
party components are:
1. GPL licences (e.g. v2,3)
2. LGPL licences
3. BSD licences
4. Apache licences
5. Other OSI Approved Licences
6. Other FSF Approved Licences

All other proprietary and free licences will be declared and signed off by ICTA.

Assumption 47. It is assumed that no express permission is required for the
Free and Open Source licence list above.

6 Functionality Not Required

The following functionality is not provided after re-engineering the legacy
application for the reasons specified.

Functionality Reason for Exclusion
Editing Owner Information Owner information will be accessible directly from the
DMT eService and will reflect the latest details on the
registration book.
Assumption 48. There will be no access to correct
this data through the e-RL
application except for the
exceptional scenarios mentioned
in Section 4.8
Editing Vehicle Information Vehicle information will be accessible directly from the
DMT eService and will reflect the latest details on the
registration book.
in Section 4.8
Transferring owning DS The transfer of owning DS will only happen through the
DMT
Changing Fuel Type The Fuel type of the vehicle will only be permissible to
be changed and verified by the DMT
in Section 4.8
Changing Erroneous Vehicle
Registration Numbers
The Vehicle Registration Number will only be
permissible to be changed and verified by the DMT
Enforce Expiry date of
revenue licences (Set Final
Date function)
This can be handled by either deleting/updating
revenue licence records or adding new backdated
revenue licence records
Table 22 - Functionality not required by new e-RL Application

7 Clarifications and Issues
7.1 Closed Issues and Clarifications

The following clarifications and issues have been answered and a conclusion
reached by the respective stakeholder as given below:

Question/Issues Who Can
Answer
Solutions / Answers Stage /
Severity
1. Where are all country portal
licences issued and posted
from?
WPDMT
(Notify
PSC)
Options:
1. WPDMT
2. Each DS
3. Each Provincial DMT
4. Other central location
for all country
Decided on WPDMT
Stage 4
High
2. Vehicle lookup functionality
from country portal is
potentially a security risk as
the management of
usernames and passwords at
DS is very weak (if the DS
logins are used for the staff
lookup of the country portal). It
is best we avoid this and only
permit access to other
provinces through the LGN.
ICTA Host e-RL application at
LGN-IDC with special user
accounts which only have
lookup privileges. Lookup
can only be accessed from
within the LGN

A separate instance of
country portal will be setup
internal to the LGN with
restricted access to
Government staff only
Stage 2
Medium
3. How will access to the country
portal and mobile lookup be
processed? By Whom?
WPDMT
(Notify
PSC)
By the eRL administrator at
the WPDMT
Stage 3
Medium
4. Who is going to issue login
credentials to eRL portlet
through country portal to the
staff? Will this be the same
login as that used for the e-RL
application or is it a separate
login?
WPDMT/
ICTA
Options:
1. All e-RL Users
2. New users created by
WPDMT

Decided on Option 2
In Stage 2 this be done
manually to the database
until the admin interface is
available in Stage 3
Stage 2
High
5. Who will manage the central
database (DB)? Who will
authorize access at the
Central DB? Will there be any
owner who has access
beyond the PDMTs
superuser?
ICTA Options
1. WPDMT Admin
2. LGN Admin
3. ICTA Admin

Stage 2
Medium

6. Will there be a special
number assigned for the
mobile phone gateway for
eGovernment? Will this be a
common number for
government services? What
flexibility do we have to
propose a code for e-RL
ICTA ICTA mentioned that there
will be a single number for
all government services
High
7. How is the ownership of data
distributed with other PDMTs
in other provinces? Can one
province modify certain data
of another province? What
rights do WPDMT have to
update other provincial data?

How is the first owning DS
assigned? Currently this
seems to be done based on
experience. Can we get this
from the DMT eService?
WPDMT
(Notify or
dispute
resolution
at PDMT)
Commissioner mentioned
that any staff member,
either from a DS or PDMT
will have read-only access
to information of vehicles
belonging to other
provinces

Owning DS is no longer
required. Identifying the
province to which a vehicle
belongs would be sufficient
Medium
8. What happens when there is
a discrepancy between DMT
vehicle/owner data and
sufficient evidence provided
at PDMT/DS?
WPDMT/D
MT
(Notify or
dispute
resolution
at PDMT)
Commissioner mentioned
that WPDMT may require to
edit information when DMT
updates take time or data is
incorrect

PDMT superusers will be
allowed to edit vehicle /
owner data if relevant
documentation is provided.
This can only be done
once, after which the
vehicle will be blacklisted
until the discrepancy is
corrected by the DMT
High
9. There are less controls at DS
offices. Does the DS staff
have access to correct the
owner and vehicle details
provided sufficient evidence is
provided

WPDMT /
DMT
(Notify
PSC)
Any data discrepancy can
be rectified by the PDMT
superusers only
High
10. When renewing RL via
Country Portal how do we
verify availability of original
copy of registration book?
WPDMT Checking the certificate of
registration will not be done
for renewals done via the
country portal.
High

11. What about brand new
vehicles which do not require
emissions testing for the first
3 years? How do we get the
brand new status from the
data?
DMT
(Notify
PSC)
DMT will send the brand
new status of the vehicle in
their data feed
High

12. We expect that it will take a
while for DMT to have the
latest data on their system.
We suggest a phased access
control, which monitored until
exceptions are negligible
PSC PDMT superusers will be
allowed to rectify data
discrepancies once only.
The vehicles will be
blacklisted to prevent
further issuances. Any
renewals thereafter, will be
done only after the data
discrepancy is rectified by
the DMT
High
13. It was identified that there
were overlapping vehicle
registration numbers starting
with TR as in the past trailers
were given the TR prefix
before the new system came
into place. Currently they are
identified with TR<dot> in the
database.
WPDMT This affects only about 100
entries.

It was decided to move the
trailers to TRA- in the
database to identify them
distinctively as trailers
High
14. What is the best model for the
motor traffic police to access
this system?
WPDMT /
Police
(Notify
PSC)
The following two methods
are available:
1. Two way radio access
to back office with
access to lookup portlet
2. Authorized officer with
mobile lookup capability
Stage 2
Medium
15. Who will pay for the mobile
phone charges for access to
this information?
ICTA
(Notify
PSC)
ICTA will negotiate free or
sponsored mobile access

Stage 2
High
16. Can the VET and Insurance
data be stored in the LGN-
IDC? Technically this would
enable verification without
requesting the company name.
However are the issues
legally?
ICTA,
DMT
(Notify
PSC)
VET data is owned by DMT
and can be stored in IDC.

However, the system will
directly connect to the
company web services and
retrieve data until a
centralised store is made
available

Stage 3
Medium
17. Will the counter machines use
Ubuntu or Kubuntu?
ICTA Kubuntu will be used on the
counter machines.
Stage 3
High

18. Can the WPDMT Supervisor
edit vehicle / owner information
if there is a discrepancy?
DMT
Commissi
oner
A super user role specified
by the commissioner will be
able to edit vehicle / owner
information
Stage 3
High
19. Can the WPDMT Supervisor
add details vehicles which
have not been registered in the
DMT system?
DMT
Commissi
oner
This is not allowed by the
new system
Stage 3
High
20. The normal transfer service
will have a delay of 21-30 days
as indicated by DMT, however
there are instances where the
transfers have taken longer
and a few beyond a year. The
vehicle should not be
blacklisted as a result of a
transfer. How shall we handle
these cases? Also there is a
big risk that the transfer will not
be done within 30 days?
DMT,
WPDMT
(PSC)
If documentary evidence is
provided the superuser can
edit relevant information
and proceed with revenue
licence issuance
Stage 3
High
21. SMS Message format and
gateway details and eService
needs to be finalized
ICTA SMS message format
finalized at meeting with
Police
Stage 2
High
22. The DS Staff will now also
have access to country wide
vehicle data. Due to reduced
security controls observed in
the DS office should we restrict
their sensitive viewable data in
some form?
WPDMT Options
1. Restrict viewing
address data at DS
level only
2. Do not restrict

Do not restrict.
Stage 3
Medium
23. Can we charge for postage
and SMS notifications to the
end user? What is the postal
charge on top of the licence?
WPDMT
(Notify
PSC)
Commissioner suggested a
service charge of 4%
Stage 4
Medium
Table 23b - Closed Clarifications

8 Further Enhancements

This section lists out requirements that were gathered during the requirements
phase but are out of scope for this project. They are aimed at improving the
efficiency and effectiveness of the business processes at PDMT / DS and also
providing a greater convenience to the eCitizens who interact with the Revenue
Licence Portlet.

8.1 Superuser Dashboard

Figure 8.1 - Superuser Dashboard Screen

Figure 8.2 - Superuser Dashboard Flow

Description This use case covers the display of a summary of all the counter s

and transactions of a particular local authority (DS / PDMT) to the
superusers. It will be displayed as their home screen
Relevant
Prototype
Figures
Figure 8.1 - Superuser Dashboard Screen
Preconditions Superuser is logged into the system
2. View Summary of all counters
3. Proceed to required superuser task
Success
Criteria
Display of summary information at local authority proceed to
required task
Alternative
Flow
None
Error Flow None
Business
Rules / User
Stories
the dashboard;
1. Counter name
2. User logged in to counter
3. Number of RL processed
4. Number of free licences issued
5. Total amount received
The following summary information will also be included
1. Total cash received
2. Total cheques received
3. Total normal RL issuances
4. Total free licences processed
5. Total Print and Post issuances
The Dashboard menu on the top right corner will provide
access to other administrative and/or superuser functionality
based on the users access privileges
Stage Stage 3

8.2 Export of Synchronisation Data

This Administrator level scenario covers the steps involved in exporting the
synchronisation data from the DS or PDMT for manual synchronisation.

Figure 3 - Export Local Database

Figure 4 - Export of Synchronisation Data

Description This use case covers the export of the added, deleted and edited
revenue licence records from a particular local database for manual
synchronisation. This would be useful in case of network connectivity
disruptions
Relevant
Prototype
Figures

Figure 3 - Export Local Database
Preconditions User needs to have superuser privileges to perform
administrative tasks
The output file format will be the same as the pre-defined
format for import from non-WP DSs
Main Flow 1. Initiate Data Export The initial screen will show a summary
of the statistics relating to the data imports
2. Export Data Select either the date range or the time period
since last export in order to export the data
3. Extract Data from local database Data will be extracted
from the local database and written into a file
Success
Criteria
Data exporting is completed successfully
Alternative
Flow
None
Error Flow None
Business
Rules / User
Stories
None
Stage Stage 3

8.3 Centralized Reporting

This scenario covers the steps followed by authorised users in the PDMT, DS or
any other government institute to lookup vehicle details from the central
database.

Figure 5 - Generating Reports

Report Name Description Input Criteria Output Criteria
Detailed
Report
Get detailed report of all
transactions carried out by
a particular counter of a DS
on a given day
DS, Counter, Date Serial No., Reg.
No., Prev.
Licence No., New
Lic. No.,
Duration, Status,
Fee, Fine, Cash,
Cheque, Total
Summary
Report
Total value of all
transactions for each
counter on a particular day
DS, Date Counter, User
(last logged in),
Total Vehicles,
Fee, Fine, Cash,
Cheque, Total
Fleet Report Report of all fleets
configured through a given
local authority
DS Fleet ID, No. of
Vehicles, Total
Due
DS Summary
Report
A summary of the RL
issued at each DS
belonging to the province
DS, No. of RL
issued, Cash,
Cheque, Total
Revenue

8.4 Setup Mobile Alerts for e-RL Portlet

This scenario covers the configuration of alert settings in the e-RL portlet.

Figure 6 - Configure Alert Settings

Description This use case describes the configuring of mobile alerts for
revenue licence renewal
Relevant
Prototype
Figures
None
Preconditions User is logged into the country portal
Main Flow 1. Access e-RL portlet
2. Configure alert settings Add mobile number and/or email
address
3. Send verification token A verification token will be sent to
the mobile number which will be requested in the next
process step to ensure that the mobile number is associated
to the particular eCitizen
4. Validate Token The verification token will have to be
entered in to the relevant text box to confirm the authenticity
of the eCitizen
5. Save Settings The alert settings of the particular eCitizen
will be saved on the central DB
Success
Criteria
Alert settings are successfully verified and saved
Alternative Verify Vehicle Number

Flow 2a Verify Vehicle Number: If the vehicle number does
not exist in the
Vehicle registration number does not exist in central DB
Vehicle registration number is not renewable
Verification of insurance returned invalid status
Verification of VET returned invalid status
Failure in processing credit card payment
Business
Rules / User
Stories
The following criteria should be met for the revenue licence
to be renewable:
1. Vehicle should be registered with the DMT and have
at least one revenue licence
2. Vehicle should have a valid vehicle insurance
certificate Validity is resolved by having an
insurance expiry date which is greater than or equal
to the date of renewal
Vehicles having free licences may not be renewed via the
portlet
Vehicles that have undergone a fuel type conversion need to
visit the PDMT
Revenue Licence reissuance is not possible via the portlet
Non-user revenue licence issuance is not possible via the
portlet
Vehicles that have been classified as ineligible by a DS or
PDMT due to not meeting the criteria required for renewal
shall not be able to renew via the e-RL portlet
Stage Stage 4

8.5 Integration with Display Panel

The total payment due, including the arrears, fee and fine can be displayed on a
Liquid Crystal Display (LCD) panel connected to the computer at the counter.
This will enable the vehicle owner to easily understand the total payment and its
breakdown. The following advantages may be derived with this enhancement:

Eliminate cancelation of licences due to the citizen not having sufficient
money to make payment
Counter staff need not explain breakdown of total payment
Improved throughput of revenue licence issuances

Appendix 1 Traceability of User Stories to Use Cases

User Story ID Description Use Case(s) / NFR ID
STR01 Reconciliation of revenue and
logging of user activity
UC17, NF05
STR02, STR61 Maintain or Improve current level
of efficiency
UC03, NF01, NF03
STR03, STR22 Handling of exceptional RL
issuance scenarios
UC11
STR04, STR24 Accurate and updated reporting UC24
STR05 Issue non-user licences UC05
STR06, STR39 User Management and access
control
UC22, UC23
STR10 Ensure that data entered from
one province cannot be edited by
another province
NF05
STR11, STR31 Issue 'free licences' UC03
STR15, STR16,
STR43
Issue Quotations and Licences
for Fleets
UC07, UC08
STR17, STR52,
STR62
User Dashboard UC02
STR25, STR26,
SR27
Add/Edit/Delete RL information
with approval
UC09, UC10
STR21 Integration with offsite counter UC30
STR30 Superuser tasks (transitions) UC13, UC14, UC15, UC16
STR34, STR36 Pay arrears only for normal
issuances
UC06
STR38, STR19 Configure holidays UC20
STR41 Maintain activity log UC17, UC22
STR45 Record Cheque based
transactions
UC03
STR07, STR37,
STR54, STR50,
STR53, STR55
Improve Usability NF03
STR56, STR57,
STR58, STR51
Issue RL via e-RL portlet UC27, UC28
STR63 System Security NF05
STR08 Exception Scenario Handling UC12
STR49 Centralized user access control UC21
STR40, STR46,
STR47, STR13,
STR14, STR35
Business rules Defined Separately

STR09, STR28,
STR29, STR20,
STR23, STR33,
STR12, STR32
Edit/Delete Vehicle/Owner
information, transfer DS
authority, Change fuel type
Conflict of Information Domain
STR65 Search vehicles based on
chassis no and engine no.
Out of Scope
STR18 Enter and upload data between
1995-2000 to a separate
database
Out of Scope
STR42 Issue trade licences Out of Scope
STR44 Issue temporary licence Out of Scope
STR59 Display payment on LCD screen Out of Scope
Table 24 - Traceability of User Stories to Use Cases

Appendix 2 List of Functional and Non-functional Requirements

Code Use Case
UC01 Application Login
UC02 Normal User Dashboard
Revenue Licence Issuance Scenarios
UC03 Normal Licence Issuance
UC04 Issuance of Licences for Vehicles with Converted Engines
UC05 Issuance of Non-user Certificate
UC06 Payment of Arrears
Licence Issuance for Fleets of Vehicles
UC07 Issuing Quotations
UC08 Issuance of Licences for Fleet
Correct RL Information
UC09 Edit / Delete Existing Revenue Licence records
UC10 Add new Revenue Licence record
UC11 Processing Ineligible Revenue Licence Records
UC12 Edit Vehicle / Owner Information
Transitions
UC13 Categorising Vehicles as Free Licenced
UC14 Categorising Vehicles as Non-user Licenced
UC15 Print Loose Slip
UC16 Blacklisting of Vehicles
UC17 Vehicle Activity Log
UC18 Department of Motor Traffic Data Import
UC19 Counter Configuration - Administration
UC20 Holiday Configuration - Administration
UC21 Add Reference Data
Account Management- Administration
UC22 Manage User Account
UC23 User Account Password Modification
UC24 Reporting
UC25 Non-Western Province DS Data Upload

UC26 Staff Lookup Portlet Scenarios
Country Portal e-Citizen Scenarios
UC27 Revenue Licence Renewal via e-RL portlet
UC28 Issue RL for e-RL requests
UC29 Mobile Lookup Scenario
UC30 Synchronisation of Databases
UC31 Canonical Database
UC32 Data Migration

Code Non-functional Requirement
NF01 Performance Requirements
NF02 Compatibility Requirements
NF03 Usability Requirements
NF04 Localisation Support
NF05 Security Requirements
NF06 Scalability
NF07 Maintainability
NF08 Documentation Requirements
NF09 Applicable Standards
NF10 Intellectual Property Requirements

Table 25 - List of Functional and Non-functional Requirements

Appendix 3 List of User Stories

Code # Priority As a (Role) I want to (need) So that (value)
STR01 1 High Super Admin
(Commissioner)
Ensure that all revenue
collected are accounted
for by the system
(referred to as 'security')
No fraud is committed
STR02 2 High Super Admin
(Commissioner)
Improve or maintain the
current level of
efficiency with the new
application
Citizens continue to
be satisfied with the
services provided
STR03 3 High Administrator Overrule the insurance,
vet and other mandatory
requirements in issuing
revenue licences
Exceptions to the
rules can be made by
the commissioner as
he sees fit
STR04 4 Medium Administrator Automate the generation
of lost revenue reports
The department can
easily verify the
revenue that should
have been generated
STR05 5 Low Administrator Issue non-user revenue
licences
Citizens applying for
non-user licences can
obtain them
efficiently through the
new system
STR06 6 Low Administrator Configure user roles and
access privileges
Delegate
responsibility to
achieve an efficient
service and integrity
of the system
STR07 7 High RL user Issue revenue licence
with minimum keyboard
and mouse involvement
The time consumed
for issuing RL is
improved
STR08 8 High RL user Direct exceptional
scenarios (fuel
conversions, transfers) to
administrators
Exceptional cases
should be handled by
users with higher
authority
STR09 9 High Advanced user Generate report of RL
history and payments
when transferring to
another DS
Other DS will be
aware of the RL
obtained by the
citizen in the past

STR10 10 Medium Administrator Ensure that data entered
from one province cannot
be edited by another
province
Integrity of data is
ensured and their
ownership to the
respective DS and
province is protected
STR11 11 High RL user Configure a vehicle as a
'free licence' vehicle
Vehicles that have the
necessary documents
to be classified as
'free licence' can be
processed efficiently
STR12 12 High Administrator Record the fuel
conversion of a vehicle
Citizens who convert
the fuel type of their
vehicle can thereafter
process their RL
renewals through the
RL application
STR13 13 Medium RL user Process refund of
existing revenue licence
in case of fuel conversion
Citizens who undergo
fuel conversion for
their vehicles can
easily get there
refund without having
to go through another
manual process
STR14 14 Medium RL user Process refund of in case
of a duplicate payments
Citizens who
erroneously make
duplicate payments
should be able to get
their money refunded
STR15 15 Medium RL user Provide quotation for
fleet registrations
Institutions which own
fleets of vehicles
an estimate of the
entire revenue licence
fee to be paid
STR16 16 Medium RL user Issue RL for Fleet of
vehicles
Institutions which
obtain quotations and
submit payment for a
fleet of vehicles
RL processed
efficiently
STR17 17 High RL user Maintain counter history
for a given day
Total value of RL
issued can be
reconciled with the
cash in hand
STR18 18 Low RL user Enter and upload data
between 1995-2000 to a
separate database
Records pertaining to
RL history during the
1995-2000 period
need to be printed for

verification
STR19 19 High RL user Ensure that the leap
years are accounted for
in calculating licence fee
and fines
Save time by avoiding
manual processing of
leap year issues
STR20 20 High RL user Edit owner information,
chassis no., engine no.,
and licence authority for
a given vehicle
The citizen does not
have to spend time
going back to an
admin to correct any
inaccurate
information with
regard to his/her
vehicle
STR21 21 High Administrator Upload weekly data from
the counter being
operated at Narahenpita
into the database
Licences issued from
the Narahenpita
counter will be
reflected accurately
in the system once a
citizen come to PDMT
for subsequent
renewal
STR22 22 High Administrator Convert vehicle status to
legal / illegal
Citizens can be
allowed / disallowed
to obtain licence from
the WPDMT
STR23 23 High Administrator Edit vehicle information Inaccurate records
can be easily updated
with latest
information
STR24 24 High Administrator Check all entries of the
previous day
Any erroneous
transaction could be
identified
STR25 25 High Administrator Delete RL records
entered within the day
without additional
authorization
Any incorrect
transaction added to
the database can be
deleted for the
correct entry to be
added
STR26 26 High Administrator Delete historic RL
records (entered before
current day) with
additional authorization
Any incorrect
transaction added in
the past can be
rectified to make sure
that the database
reflects accurate
records

STR27 27 High Administrator Enter new transaction
manually
Erroneous transactions
that were deleted can
be added manually
and for the issue of
non-user licences
STR28 28 High Administrator Print loose slips Citizens transferring
out of the province be
provided with a
document detailing
the revenue licence
history of their
vehicle
STR29 29 High Administrator Change vehicle
registration number
Any change in the
vehicle reg. no. can
be correctly reflected
in the database
STR30 30 High Administrator Handle Duplicate
Revenue Licence
Issuance
Any duplicate revenue
licence issuances can
be resolved to ensure
that citizens can
receive accurate
Revenue licences
STR31 31 High Administrator Categorize vehicles as
free licenced
Vehicles that meet
the criteria to be
categorized as free
licenced can be
configured as same
STR32 32 High Administrator Convert the licence
authority from other DS
to PDMT
Vehicles that
previously belonged to
other DSs can be
permanently
transferred to the
PDMT
STR33 33 High Administrator Delete vehicle from DB
after ensuring that all RL
records have been
deleted
No further RL
issuances may happen
for that particular
reg. no.
STR34 34 High RL user Have separate records in
the DB for Arrears
payments and normal
issuances
The RL history can be
easily read to
understand arrears
and normal licence
payments for a
particular vehicle
STR35 35 High RL user Set the status of a
vehicle belonging to
other DS in the same
province to 'illegal' after
issuing licence
The owning DS
authority will not be
changed permanently
in the database

STR36 36 High Administrator Allow part payment of
accumulated arrears
Citizens can settle
their arrears partially
in case they are short
of money
STR37 37 High RL user restrict keyboard
navigation to the 'print
licence' button and
require a mouse click on
it'
RL transaction is
checked for accuracy
and cash received
before proceeding
with printing
STR38 38 Medium RL user System should account
for holidays when
calculating fines due
System can accurately
calculate fines
without requiring
manual rectification
for holidays
STR39 39 High Administrator DSs should be able to
handle admin tasks
without having to revert
to PDMT admins
The time consumed
for issuing RL at DSs
are reduced
STR40 40 High Administrator Some DSs should be able
to handle the first
registration for Motor
cycles/Three wheelers
Motor cycle and three
wheel owners can
continue to register
their vehicles at some
DSs as per the current
regulations
STR41 41 High Administrator Maintain log of tasks
carried out by DS
supervisors
Any issue can be
traced back to the
supervisor/user who is
responsible for it
STR42 42 Low RL user Issue trade licences time can be saved in
the manual processing
of trade licences
STR43 43 High Administrator Charge arrears/fines
resulting from delayed
cheques separately
Fines and/or arrears
that are part of an
earlier transaction
need not be entered
under a new RL
issuance transaction
STR44 44 Low RL user Handle the issuance of
temporary licence for
vehicles bearing foreign
licence plate nos.
The system can be
used to efficiently
issue temporary
licences for foreigners
with vehicles having
licence plate no.
formats other than
the standard sir
Lankan format
STR45 45 Medium RL user Record details of cheque
payments made for fleet
RL issuances
There is a distinction
between recording
cash and cheque

payments in the
system
STR46 46 High RL user Issue RL without VET
requirement for special
conditions (1st
registration and brand
new vehicle)
the VET regulations
are followed
accordingly
STR47 47 High RL user Issue RL for up to three
years without the VET
requirement for brand
new vehicles
the VET regulations
are followed
accordingly
STR48 48 Medium Administrator Control and monitor the
RL issuance system at
each DS
All issues which
require WPDMT
intervention can be
performed online
without having to visit
each DS
STR49 49 Medium Administrator administer access control
to the DS systems from
WPDMT
DSs that lack technical
competence to
manage their own
system can receive
WPDMT assistance
remotely
STR50 50 Medium RL user Ensure that accurate
data is entered to the
system
Careless mistakes can
be avoided during RL
issuance
STR51 51 High RL user Print and post RL issued
via the country portal
Citizens can renew
and receive their RL
to their homes
STR52 52 High RL user Access counter history
whenever required
The RL transactions
done previously can
be viewed instantly
for verification
purposes
STR53 53 Medium RL user Learn how to issue RL on
new application in a very
short time
Minimum effort is
spent on learning a
new application
STR54 54 High RL user Have a color scheme that
is soothing to the eye
Stress caused by long
hours of work with the
same screen would be
minimized

STR55 55 High RL user Avoid changing the
counter erroneously
between transactions
All transactions
occurring at a
particular counter can
be tracked correctly
for reporting purposes
STR56 56 High RL user Charge an additional
service fee for country
portal renewals
Credit card payment
commissions and
postage charges can
be compensated
STR57 57 High Administrator Provide minimum
information to the
eCitizens who renew RL
via country portal
Sensitive information
is not divulged online
STR58 58 High RL user Require eCitizens to
provide vehicle chassis
no. as a means of
authentication
Fraudulent renewals
can be minimized
STR59 58 High Administrator Blacklist vehicles Vehicles which have
been identified with
legal violation can be
denied renewal of RL
STR60 59 Low RL user Display total payment on
a LCD display
Customers will be
aware of the payment
due before RL is
printed
STR61 60 Medium RL user Auto increment the
insurance expiry date
Time taken to perform
a routine RL renewal
can be minimized
STR62 61 Medium Administrator Configure Holidays for
each DS separately
In the event of a
natural disaster, DS
specific holidays can
be configured
STR63 62 Medium RL user Keep track of partially
processed RL
transactions
If the same
transaction is
restarted at a
different counter, no
duplication occurs
STR64 63 High Administrator Keep the system safe of
constant virus attacks
System security and
data security is not
compromised
STR65 64 Medium RL user Keep note of leased
vehicles
Copy of registration
book can be accepted
in lieu of original copy
STR66 65 Low RL user Search vehicles based on
chassis no and engine no.
Even if vehicle
registration no. is
incorrect, vehicle can
be searched for
Table 26 - List of User Stories

Appendix 4 Revenue Licence Rates with effect from 01/01/2008

Class of Vehicle Fees (Rs. per passenger seat)
SLTB Bus 25.00
Omnibus 80.00
Motor Coach 300.00

Class of Vehicle Weight (kg) Fuel Fee (Rs.)
Land Vehicles
(Fee calculation is
based on Tare
Weight)
Up to 1778 N/A 400.00
Above 1778 up to 2032 N/A 800.00
Above 2032 up to 2540 N/A 1000.00
Above 2540 up to 3048 N/A 1200.00
Above 3048 up to 3556 N/A 1400.00
Above 3556 up to 5080 N/A 1500.00
Above 5080 up to
15240
N/A 2200.00
Above 15240 up to
25400
N/A 2500.00
Above 25400 N/A 3000.00

Class of Vehicle Weight (kg) Fuel Fees (Rs)
Class of Vehicle Fee (Rs.)
Motor Cycle 300.00
Motor Tricycle and Motor tricycle vans 275.00
Motor Vehicles in A to Z series 100.00

Car, Ambulance or
Hearse
(Fee calculation is
based on Tare Weight)
Up to 762
Petrol 900.00
Diesel 2000.00
Above 762 up to 1016
Petrol 1500.00
Diesel 3000.00
Petrol 2000.00
Diesel 4800.00
Above 1270
Petrol 2800.00
Diesel 6400.00
Motor Lorry
(Fee calculation is
based on Gross
Weight)
Up to 2000
Petrol 1200.00
Diesel 2400.00
Petrol 1500.00
Diesel 3200.00
Above 5000 up to
10000
Petrol 2000.00
Diesel 4800.00
Above 10000 up to
15000
Petrol 2400.00
Diesel 6000.00
Above 15000 up to
20000
Petrol 3600.00
Diesel 8200.00
Above 20000 up to
25000
Petrol 3800.00
Diesel 9000.00
Above 25000 up to
30000
Petrol 4500.00
Diesel 11400.00
Above 30000
Petrol 5500.00
Diesel 12500.00
Dual Purpose Vehicle
(Fee calculation is
based on Gross
Up to 1000
Petrol 900.00
Diesel 2000.00

Weight)
Petrol 1400.00
Diesel 3000.00
Petrol 1800.00
Diesel 3200.00
Petrol 2200.00
Diesel 4400.00
Petrol 3200.00
Diesel 6400.00
Petrol 3900.00
Diesel 8000.00
Petrol 4500.00
Diesel 9400.00
Above 4000
Petrol 10000.00
Diesel 15000.00

Delay Penalty (% of annual fee)
Not exceeding 6 months from the due date 10
Over 6 months but less than 12 months from due date 20
Over 12 months 30
For newly registered vehicle exceeding due date (7 days from
registration date)
10

Appendix 5 Revenue Licence Rates before 01/01/2008

Class of Vehicle Fees (Rs. per passenger seat)
SLTB Bus 20.00
Omnibus 80.00
Motor coach 250.00

Class of Vehicle Weight (kg) Fuel Fee (Rs.)
Land Vehicles
(Fee calculation is
Up to 1778 N/A 150.00
Above 1778 up to 2032 N/A 275.00
Above 2032 up to 2540 N/A 350.00
Above 2540 up to 3048 N/A 425.00
Above 3048 up to 3556 N/A 500.00
Above 3556 up to 5080 N/A 550.00
Above 5080 up to 15240 N/A 1050.00
Above 15240 up to 25400 N/A 1400.00
Above 25400 N/A 2100.00

Class of Vehicle Weight (kg) Fuel Fees (Rs)
Car, Ambulance,
Hearse or other private
passenger vehicle
Up to 762 Petrol 350.00
Diesel 700.00
Class of Vehicle Fee (Rs.)
Motor Cycle 275.00
Motor Tricycle and Motor tricycle vans 275.00
Motor Vehicles in A to Z series 25.00

(Fee calculation is
Above 762 up to 1016 Petrol 700.00
Diesel 1400.00
Diesel 2800.00
Above 1270 Petrol 2100.00
Diesel 4200.00
Motor Lorry
(Fee calculation is
based on Gross
Weight)
Diesel 850.00
Diesel 1675.00
Above 5000 up to
10000
Petrol 1400.00
Diesel 2800.00
Above 10000 up to
15000
Petrol 2100.00
Diesel 4200.00
Above 15000 up to
20000
Petrol 2800.00
Diesel 5600.00
Above 20000 up to
25000
Petrol 3500.00
Diesel 7000.00
Above 25000 up to
30000
Petrol 4200.00
Diesel 8400.00
Diesel 9800.00
Dual Purpose Vehicle
(Fee calculation is
based on Gross
Weight)
Diesel 700.00
Diesel 1050.00

Diesel 1900.00
Diesel 3150.00
Diesel 4200.00
Diesel 5250.00
Diesel 6300.00
Diesel 7350.00

Appendix 6 Changes to Requirements

Section Description of Changes
3.4 Licence Payment
Logic Business
Rule: Due date for
licence renewal
Three working days from the corresponding day of the
corresponding month of the year in respect of which the
licence is applied for. This three working days period is
applicable regardless of that vehicle has arrears or not.
4.2 Normal User
Dashboard
The Issued Licences grid of the normal user dashboard
should exclude licences that have been automatically
cancelled due to an error and/or failure in the printing
process
Normal User Dashboard should include the Sequence no.
and the duration of the licence issued
A column indicating the cumulative total should be added to
the Issued Licences grid of the normal user dashboard
4.3.1 Normal Licence
Issuance
Valid vehicle number, In following format,
[a-zA-Z]{1..2} or [0-9]{1..3} - [0-9]{4}
A valid vehicle registration number should not include leading
zeros
E.g.:GF-5053
E-6029
1-3456
18-1234
301-4567
When a valid registration number is searched, the system
will first look into the local database. If available the vehicle
information along with any revenue licence records will be
displayed. If the vehicle registration number does not exist
in the local database the central database will be searched
automatically. If the vehicle is found in the central database
it will be retrieved along with the latest revenue licence
record. The operator can check the central database to
verify if there are any other licences that have been
obtained from other DSs by clicking the Licence Update
button. If the vehicle does not exist in either of the two
databases, the user should be allowed to enter the vehicle
in to the system. This functionality should be configurable
(i.e. could be activated / deactivated on request).
Insurance status should be automatically changed to Yes
when a valid insurance date is entered
Slashes should be inserted automatically to the Insurance
expiry date field in the Main Licence Issuance Screen in
order to minimize the number of keystrokes
Increment the insurance expiry date of the previous
revenue licence by one year when obtaining a new revenue
licence
Display a label depicting the format of the insurance expiry

date below the input field
The VET number field should only accept numbers [0-9] or
letters [a-zA-Z] as input
Fine values should be rounded up to the nearest rupee
In the event of the fine being edited by a authorized
supervisor, the normal licence issuance flow should be
followed in order to obtain a licence with the edited fine
values. However, if the vehicle owner intends to proceed
with Pay arrears only functionality the arrears payments
will be calculated with the relevant fines
The Revenue Licence No. should be printed on the licence
counterfoil
Vehicle owners should be able to obtain the revenue
licence for the year ahead if the expiry date of the newly
generated licence is less than three months from the
current date
All input fields which require currency values to be entered
should disallow the input of characters.
Licence Issuances put on-hold should be in the verified
state only until the end of the day. If not processed within
the day, the licence will have to go through the verification
process again
When the user clicks Re-Print due to a failure or error in
the printing process, the licence records entered to the
database should be cancelled automatically and a new
record should be saved in the database with the
incremented licence no.
In case of a revenue licence reissuance, the insurance
expiry date, vehicle emission testing certificate no., route
permit no. and fitness certificate status of the previous valid
revenue licence should be populated in the relevant input
fields
The user should be able to navigate through all the relevant
input fields of the normal licence issuance flow using the +
key (+ tabbing functionality is supported only in the licence
issuance screen. For all other places, tab key or mouse
can be used)
Sequence Number should be printed on the revenue
licence
Address of the Vehicle owner and the title should not be
printed on the revenue licence
In transactions that require a comment, users should be
able to select one from among a common set of comments
or specify his/ her own comment
When reissuing licences need to have a confirmation dialog
box
In "View More" grid of "Licence Payment History of normal
user, the type of licence records inserted from other
authorities should be OA (other authority)

4.3.3 Issuance of Non-
user Certificates
If a vehicle owner needs a non-user certificate, vehicle
owner has to go to the supervisor. Supervisor will update
the vehicle status as non-user.
After that the vehicle owner has to go to a counter and get
the non-user certificate.
If the non-user certificate is successfully issued, the non-
user status of the vehicle should be cleared.
If the vehicle owner needs another non-user issuance again
(this can be after 6 months or 12 months), vehicle owner
has to go to the supervisor to update vehicle status as non-
user.
According to above rules, every time after issuing a non-
user certificate, the non-user status of the vehicle should
be cleared.
4.4 Payment of
Arrears
Vehicle owners should be allowed to make payment in
settlement of arrears accrued for any period (in multiples of
years) starting from the date from which the arrears falls
due
4.5.2 Issuance of
Licences for
Quotations
Vehicles added to a quotation should be in the verified state
for a period of 30 days. Thereafter the quotation should be
recreated after verifying each and every vehicle
If the amount due for vehicles added to a quotation exceeds
the original value at the time of making payment (due to
additional fines), the balance amount should be collected by
cash or credit card.
The licence(s) for which the cheque payment is insufficient
will have a partial payment in cash. However, there is no
specific requirement on the order in which payment records
should be assigned to the licences
4.6.1 Edit / Delete
Existing Revenue
Licence records
Both DS Supervisors and PDMT Supervisors should only
be able to edit / delete revenue licence records that have
been issued from their respective local authority. The
Commissioner should be allowed to edit / delete any
revenue licence record irrespective of the authority which
issued it. However, the system should allow to edit/ delete
licence records inserted for "other authorities", if those
records are inserted by users of the current authority of
system.
Inserted date should be displayed when adding and editing
revenue licence records. The input field should initially
disabled and made editable if required only
Supervisors should be able to edit cancelled license records
4.6.2 Add New
Revenue Licence
record
The superuser should be able to specify a counter to which
the added record should be assigned.
The superuser should be able to specify whether the added
record should be excluded from being synchronised to the
central database
It should be allowed to add old licence records of authorities
within same provide by specifying the authority

In "Licence Payment History of superuser, the type of
licence records inserted from other authorities should be
OA (other authority)
4.7 Processing
Ineligible Revenue
Licence Applications
The grid containing vehicles that have been escalated to
the superuser should be refreshed every two minutes
4.8 Edit Vehicle /
Owner Information
Normal users should be allowed to edit vehicle owner
information (Name and Address)
When editing Vehicle owner information the following
validations need to be done:
- Street or City input field is mandatory
- Number field is optional
Both Normal users and Superusers should be able to add
vehicles that are not currently in the system (either local
database, central database or DMT system)
The effective date should be captured when saving new
vehicles to the system
When saving any changes done to either vehicle or owner
information, the system should prompt for a reconfirmation
from the superuser
The order of traversal (using keyboard) in edit vehicle
information should be changed as follows
1. Chassis
2. Engine
3. 1st Reg
4. Tare
5. Gross
6. Seats
7. Authority
8. Fuel Type
9. Class
The effective date of fuel/ vehicle class converted vehicles
received from DMT Update should be captured when
editing vehicle information of vehicles that have undergone
a fuel/ vehicle class conversion
4.9.3 Print Loose Slip A separate role should be available for the printing of loose
slips
The Loose slip printed should contain the image of the
letterhead of the respective authority which is stored at a
predefined folder location on the DS server
There should be records to represent conversions from fuel/
vehicle class
The licence year should be displayed in front of revenue
licence history records
4.12 Counter
Configuration
Superusers should be able to configure up to two ranges of
licence paper numbers for each counter
The history of licences assigned to each counter should be
maintained

4.13 Holiday
Configuration
Users should not be able to enter the same type of holiday
for the same date range under the same name for a given
DS
4.15 User Account
Management
In search results of "Main User Account Administration"
screen, the "created_by" user name should be displayed
4.22 Data Migration Leading zeros should be removed from the first part of the
registration number
Leading zeros should be added to the second part of the
vehicle registration number
4.23 Synchronisation
of Databases
The owning authority of a vehicle should not be changed
after obtaining a revenue licence from an authority other
than the former.
When the vehicle / owner information of a vehicle is edited
by the users of a particular authority, the owning authority of
the vehicle should be changed to the one at which the
modification took place
6 Functionality not
Required Transfer of
Vehicles from Other
Provinces
This functionality should be provided by the system. The
system should capture the effective date, previous licence
no. and the previous authority when transferring from
another province
6 Functionality not
Required Edit /
Vehicle Owner
Information
This functionality should be configurable (i.e. could be
activated / deactivated on request) and provided as follows:
1. Normal users should be able to edit the Name and
Address of the vehicle owner
2. Superusers should be able to edit all fields relating to
vehicle / owner information
3. When editing vehicle owner information, it should be
possible to set the authority of vehicle owner to a DS
other than the DS modifying this data

Revised Security Matrix

Action Operator
DS
Supervisor
DS
Admin
WPDMT
Supervisor
WPDMT
Admin
Commissioner
Issue Revenue
Licences
X
Pay Arrears Only X
Create Quotation X
Approve Ineligible
Applications
X X X
Blacklisting of
Vehicles
X X X
Holiday
Configuration
X X X
Counter
Configuration
X X X
Centralized User
Management
X X
View Activity Log X X X X X
Edit Fines X
1

Delete Revenue
Licence Records
(within DS)
X X X
Delete Revenue
Licence Records (All
DSs within Province)
X
Edit Revenue
Licence Records
(within DSs)
X X X
Edit Revenue
Licence Records (All
DSs)
X
Add Revenue
Licence Record
X X X
Reporting X X X X X
Edit Vehicle
Information
X X X
Edit Owner
information
X X X X X X

1
Edit Fine only applies to the normal licence issuance process. Any fines edited will not be
effective if the user proceeds with the Pay Arrears Only flow

Add New Vehicles X X X X X X
Add Reference Data X X
Update Reference
Data
X X
Print Loose Slip X X X

In addition to above user roles, there is a specific user role named Loose Slip Officer who has
the authority to print loose slips only.

Reporting Functionality (DS Application)

Report Name Description Input
Fields
Output Fields
Detailed Income
Report
A report of all transactions
carried out by a particular
counter within a given date
range. This report should be
categorized into three different
sections:
1. Licence Issuances
2. Pay Arrears Only
3. Non User Issuances

Redundant data should not be
displayed for different records
relating to the same vehicle.
Licences that have been issued
to vehicles transferring from
other provinces needs to be
displayed with an asterisk.
Furthermore, licence records
that have been Cancelled or
Deleted should also be
displayed. However, the fields
relating to monetary values
should be left blank for such
records. In Licence Issuances
category all records should be
sorted by the transaction number
followed by the current licence
no. In Pay Arrears Only and
Non User Issuances categories
all records should be sorted by
receipt no.
Counter,
Date
range
Sequence No.,
Registration No.,
Current Licence
No., Licence
Status, Duration,
Type, Fee, Fine,
Cash, Cheque,
Credit card, Total,
Login Name
Summary Report Summary of all transactions for
each counter on a particular day
Date
Range
Counter, Login
Name, Count of

Issuances, Count of
Pay-
Arrears-Only, Count
of Non-User,
Amount of
Issuances, Amount
of Pay-
Arrears-Only,
Amount of Non-
User Fee, Fine,
Cash, Cheque,
Credit Card, Total
Summary Report
based on Vehicle
Classes
The number and value of all
licence issued between two
dates per class of vehicle
Date
range
Vehicle Class,
Vehicle Count,
Licence Fee,
Arrears, Fine of
Fee, Fine on
Arrears, Total
Other Income
Report
Arrears and Non User fees
collected between two dates
grouped by the first part of the
licence plate number (e.g. GA or
301). This report should contain
two sub-categories:
1. Non User Issuances
2. Arrears Only Payments

The report should be sorted by
the vehicle registration number
Date
range
Receipt No.,
Vehicle Reg. No.,
Duration, Fee, Fine,
Cash, Cheque,
Credit Card, Total,
Login Name,
Counter
Special Licence
report
Includes details of free licences,
licences issued for vehicles with
fuel conversion and records
inserted by superusers between
two dates.
Above subsections should be in
following order.
1. Free Licences
2. Fuel Conversions
3. Inserted Licences

Note that the report can be
sorted based on licence
authority, licence no. or date
Date
range,
sort
criteria
(sort by
authority,
licence
no. or
date)
Registration
No., Licence No.,
Duration, Authority,
Login Name
Deleted Licences
Report
Report of deleted records. This
should contain two
subcategories:
1. Current Licences: Licences
Issued and Deleted on the
end date of the date range
2. Licence History: Licences
deleted before the end date
Date
Range
Deleted Date, User,
Reg. No., Licence
No., Expiry date,
Amount, Fine,
Originated User,
Originated Date

but on or after the start date
of the date range.
Transfers from
Other Provinces
List of licences issued for
vehicles that have transferred
from other provinces within a
given date range
Date
Range
Registration No.,
Current Licence
No., Duration,
Type, Fee, Fine,
Cash, Cheque,
Credit card, Total,
Login Name
Report on Edited
Vehicle and
Owner Details
Report of all modifications that
have been done to either vehicle
owner information or vehicle
information
Date
Range
Registration No.,
Modified Field,
Modified Time,
Login Name, Old
Value, New Value
Summary Report
of Vehicles
Report containing the number of
vehicles under each weight class
of each fuel type pertaining to
vehicle classes
None Vehicle Class,
Weight Class, Fuel
Type, No. Of
Vehicles
Note: Null values in reports will be represented as a -

Assumption 51. Reports generated on migrated data will not necessarily be
accurate for historic periods where transactions were carried
out through the legacy application. This is due to data
inconsistencies affecting the reports generated.

Centralized Reporting Functionality

Report Name Description Input Fields Output Fields
Detailed Income
Report
Get detailed report of all
transactions carried out by
a particular counter within
a given date range.
Licences that have been
issued to vehicles
transferring from other
provinces needs to be
displayed with an asterisk.
This report should be
categorized into three
different sections
containing Licences
Issues, Pay Arrears Only
transactions and Non User
issuances. Redundant
data should not be
displayed for different
records relating to the
same vehicle
DS, Counter,
Date range
Sequence No.,
Registration No.,
Current Licence No.,
Licence Status,
Duration, Type, Fee,
Fine, Cash, Cheque,
Credit card, Total,
Login Name
Summary Report Summary of all
transactions for each
counter within a date range
in a given DS
DS, Date
Range
Counter, Login Name,
Issuances, Pay-
Arrears-Only, Non-
User, Fee, Fine, Cash,
Cheque, Credit card,
Total
Summary Report
based on
Vehicle Classes
The number and value of
all licence issued between
two dates for each class of
vehicle in a given DS
DS, Date
Range
Vehicle Class, Vehicle
Count, Licence Fee,
Arrears, Fine of Fee,
Fine on Arrears, Total
Special Licence
report
Includes details of free
licences, licences issued
for vehicles with fuel
conversion and records
inserted by superusers
between two dates. Note
that the report can be
sorted based on licence
authority, licence no. or
date
DS, Date
range, sort
criteria
Registration
No., Licence No.,
Duration, Authority,
Login Name
Deleted Report Report of deleted records.
This should contain two
subcategories:
1. Licences Issued and
Deleted on the end
date of the date range
DS, Date
Range
Deleted Date, Login
Name, Reg. No.,
Licence No., Expiry
date, Amount, Fine,
Originated User,
Originated Date

2. Licences issued before
the end date but after
the start date of the
date range that have
been deleted
Lost Revenue
Summary Report
vehicles and lost revenue
for each DS. This report
should not contain
archived vehicles.
A particular
DS authority
or all DSs
If a particular DS is
chosen, output fields
should be:
Vehicle Class, 1991-
2005, 2006, 2007,
2008, Vehicle Count
(2008), Total

If All DSs is chosen,
output fields should be:
Authority, 1991-2005,
2006, 2007, 2008,
Vehicle Count (2008),
Total
Lost Revenue
Detailed Report
Details of vehicles which
have accrued arrears. This
can be obtained in the
following two formats:
1. With vehicle owner
details
2. With arrears details

The report with arrears
details should be grouped
by vehicle classes and
sorted by vehicle
registration no.
Furthermore, intermediate
totals should be shown at
the end of all records
having the same first part
of the vehicle registration
no. This report should not
contain archived vehicles.
A particular
DS authority,
Vehicle
Owner
Details or
Arrears
Details
If Vehicle Owner
Details option is
selected, output fields
should be:
Registration No.,
Owner Name, Address

If Arrears Details
option is selected,
Registration No., 1991-
2005, 2006, 2007,
2008, Total
Synchronisation
Summary Report
(only for PDMT)
Report of synchronisation
status of DSs within the
province. The DSs which
have had not had a
successful synchronisation
within the last 24 hours
should be highlighted.
None DS, Synchronisation
start time and end time
of latest
synchronisation job,
Synchronisation status.

Detailed Report
on
Synchronisations
(only for PDMT)
This report should contain
details of synchronization
activity log related to the
failed synchronisations in
DS, Date
Range
DS, Synchronization
job ID, Number of
records inserted,
Number of records

Synchronisation Summary
Report
updated, Reason for
failure and relevant
entity name (if any)

Online Licence
Renewal Report
Revenue licence details of
online licence renewal
requests made through the
e-RL portlet of the country
portal
Date Range Vehicle Registration
No., Licence No.,
Reference No., Date/
Time of Transaction,
Licence Duration,
Type, Fee, Fine,
Convenience Fee,
Postage Fee, Total
Amount
Credit Card
Transaction
Report
Report of all credit card
transactions carried out
through the e-RL portlet of
the country portal
Date Range Reference No., Vehicle
No., Date/Time of
Transaction,
Transaction Status,
Payment Approval
Code, Amount
Non-Licenced
Report
Vehicle owners who have
expired licences and non
Licenced Vehicles Without
Owner. This report should
not contain archived
vehicles.
None Reg. No., Name,
Address, Registration
Date

Vehicles free
from Previous
Year Lost
Revenue
Summary Report
vehicles which had
accrued arrears in
previous year lost revenue
report, but not in this year
lost revenue report. This
report has a column format
similar to Lost Revenue
Summary Report. This
report should not contain
archived vehicles.
A particular
DS authority
or all DSs
If a particular DS is
chosen, output fields
should be:
Vehicle Class, 1991-
2005, 2006, 2007,
2008, Vehicle Count
(2008), Total

If All DSs is chosen,
Authority, 1991-2005,
2006, 2007, 2008,
Vehicle Count (2008),
Total
Vehicles free
from Previous
Year Lost
Revenue
Detailed Report
Details of vehicles which
had accrued arrears in
previous year lost revenue
report, but not in this year
lost revenue report.

This report has a column
format similar to Lost
Revenue Detailed Report.
However this report should
A particular
DS authority,
Vehicle
Owner
Details or
Arrears
Details
Registration No., 1991-
2005, 2006, 2007,
2008, Total

only contain paid arrears
details, but not vehicle
owner details. This report
should not contain
archived vehicles.

Note: Null values in reports will be represented as a -

e-RL Citizens Portlet

Requirement Description
Enquiry Functionality

This functionality facilitates e-Citizens to enquire the progress
of their online licence renewal requests. The e-Citizen should
provide the reference number which was generated during the
license renewal, upon which he/she will be displayed the status
of the renewal. Any further inquiries beyond this point will not
be handled through the e-RL system and would require the e-
Citizen to contact the WPDMT.

Postage fee Postage fee should be captured and it should be externally
configurable
Convenience fee Convenience fee should be configurable as slabs
Temporary receipt
Upon successful license renewal a printable receipt should
be displayed to the user
The same above receipt should be e-mailed to the users
registered e-mail account

Superuser Dashboard

Figure 7 - Superuser Dashboard Flow

Description This use case covers the display of a summary of all the counters and
transactions of a particular local authority (DS / PDMT) to the
superusers.
Relevant
Prototype
Figures
None
Preconditions Superuser is logged into the system
2. View Summary of all counters
3. Proceed to required superuser task
Success
Criteria
Display of summary information at local authority proceed to
required task
Alternative
Flow
None
Error Flow None
Business
Rules / User
Stories
the dashboard;
1. Counter name
2. User logged in to counter
3. Number of Licences Issued
4. Total amount received
The following summary information will also be included
1. Total Cash received
2. Total Cheques received
3. Total Credit Card Payments
4. Total Number of Licences Issued
The Dashboard menu on the top right corner will provide access

to other administrative and/or superuser functionality based on
the users access privileges
Stage Stage 3

1269 - Annex 2 - Requirement Specifications (SRS) of E-Revenue License Project

Uploaded by

Copyright:

Available Formats

1269 - Annex 2 - Requirement Specifications (SRS) of E-Revenue License Project

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1269 - Annex 2 - Requirement Specifications (SRS) of E-Revenue License Project

Uploaded by

Copyright:

Available Formats

Annex 2

You might also like