PennDOT ATX Use Cases

Shared by: keralaguest

Tags

Stats

views:: 5
posted:: 12/8/2011
language:
pages:: 15

Public Domain

Document Sample

MSE Studio
Carnegie Mellon University
Pittsburgh, PA 15213

PennDOT ATX Use Cases

Version 1.0

Team Stalagmite
Daniel Abramovich
Jeff Ditillo
Andrew Guletsky
Oksana Schubert
Alexey Stolpovskikh
Dehua Zhang

1
Document Revisions
Revision Date Author(s) Comments
0.1 1/24/03 Jeff Ditillo Initial version revised existing document from
requirements class and detailed the transaction
process case
0.2 1/30/03 Jeff Ditillo Team reviewed transaction processing and
deleted non-applicable cases
0.3 2/3/03 Jeff Ditillo More team revisions, specific changes to
transaction processing, created image receipt
and image transfer cases, more new cases
identified
0.4 2/10/03 Jeff Ditillo Combining individually assigned cases: Login,
logout, terminate session – timeout,
establishing PCCS – ATX relationship,
maintaining passwords, query status, PC
account mgmt, send docs to PennDOT
0.5 2/13/03 Jeff Ditillo Created separate use cases for Request
Forgotten Password, Change Password,
Timeout Session, Expire Password, Add/Delete
account, Change/Suspend/Reactivate account,
Request PCCS report, changes from Andrews
reviews, identified ATX Admin, TAX User
Mgr, ATX Scheduler as users
0.51 2/17/03 Jeff Ditillo Minor general changes from Andrew review
0.52 2/17/03 Jeff Ditillo Changes to Manual Reports and Accounts
Mgmt cases from Jeff’s analysis
0.53 2/17/03 Jeff Ditillo Dan’s revision to image transfer use cases after
analysis
0.54 2/19/02 Dan Abramovich Minor edits to Use Case 8 and 9.
2/20/03 Jeff Ditillo Put under document control (VSS) and updated
version number.
0.55 4/21/03 Jeff Ditillo Revised report and user account related, added
new cases based on client feedback
1.0 7/11/03 Jeff Ditillo Removed comments

2
USE CASE 1. Process a Transaction Request:
 Actors: Participating Company Client System (PCCS)
 Pre-condition:
o PCCS is logged on to the system.
o PCCS has required information (VIN, title number, etc.)
 Flow of Events (generic description):
1. PCCS initiates a Title and Registration request and provides relevant
information. (ex. VIN, title #)
2. ATX reads the contents of the request (implied verification of format – header
and body).
3. ATX sends PCCS an acknowledgement of message received.
4. ATX logs request to Activity Log.
5. (Optional) ATX validates all data contained in the message.
6. ATX identifies the associated GK message.
7. ATX sends proper message to Gatekeeper (GK) (see Send Message to
Gatekeeper use case)
8. ATX logs action to Activity Log.
9. ATX sends a notification to the PCCS that the request has been successfully
submitted and discloses the WID for the transaction (NOTE: this will allow
the PCCS to issue license plates and decals and print permanent registration
cards)
10. ATX logs action to Activity Log.
11. ATX records information regarding the transaction in the Transaction Log.
12. ATX logs action to Activity Log.
13. ATX notifies the PCCS to scan any applicable documents (see TBD use case).
14. ATX identifies transaction request as complete with document transmission
pending to Transaction Status.
 Post-condition: Exception Cases:
1. Invalid (header) or unreadable request is submitted by the PCCS
 Response: ATX system sends an error indication to the PCCS
2. When attempting to send a message to the GK interface, the PennDOT system
is determined to be unavailable.
 Response: ATX initiates a “Resend” of the message (TBD - time interval
and maximum number of attempts)
3. ATX receives an error message from the GK when submitting the request.
 Response: ATX handles the error and takes the appropriate action.
 Scenario: Joe bought a used-car from Sara and needs to transfer the title, and
register the car.

USE CASE 2. Perform an Inquiry:
 Actor: Participating Company Client System (PCCS)
 Pre-condition:
o Specifically, this will be used by the system to query for data to auto-
populate form fields for a customer transaction.
o PCCS is logged on to the system.

3
o PCCS has required “key” information (VIN, title number, etc.)
 Flow of Events:
1. PCCS sends inquiry message to ATX system with proper key information, as
well as PCCS secondary business partner ID.
2. ATX constructs proper AAMVA/BPEVR record for the specific inquiry type,
filling in key information, as well business partner ID and PCCS ID.
3. ATX sends AAMVA/BPEVR record to Gatekeeper using MQ
4. ATX receives response from Gatekeeper that matches the PCCS ID, inquiry
type, and key information.
5. ATX sends response message to PCCS
 Post-condition: ATX has sent a response to the inquiry to the PCCS
 Exception Cases:
1. Invalid Participating Company ID or business transaction ID is provided by
the PCCS
 Response: ATX system sends an error indication to the PCCS
2. Invalid or incomplete information is provided by the PCCS
 Response: ATX system sends an error indication to the PCCS
3. Error response is received from Gatekeeper
 Response: ATX system sends an error indication to the PCCS
4. No response is received from Gatekeeper in a certain amount of time
 Response: ATX system resends inquiry to Gatekeeper
Scenario: The Operator wants to see the history of a particular vehicle that he knows
the VIN for.

USE CASE 3. Perform Daily Backup:
 Actor: ATX Scheduler
 Assumption: During normal working conditions ATX stores all the information in
three database files:
 System Configuration (used to restore System settings after a new installation)
 Activity Log
 Transactions Log

 Flow of Events for automatic backup:
1. Administrator sets the backup schedule.
2. Administrator selects backup options:
 Backup of System Configuration
 Backup of Activity Log
 Backup of Transaction Log
 Any combination of previous three items
3. Administrator selects the path to backup.
 Hard disk letter and a path
 Tape recorder

 Flow of Events for manual backup:
1. Administrator selects backup options:
 Backup of System Configuration

4
 Backup of Activity Log
 Backup of Transaction Log
 Any combination of previous three items
2. Administrator selects the range of dates.
 From – the first calendar day to backup.
 To – the last day to backup.
3. Administrator selects the path to backup.
 Hard disk letter and a path
 Tape recorder
4. Administrator runs the backup.
5. System performs the backup to selected media.

 Post conditions: The backup files are created on media.
 Scenario: The Administrator performs daily backup.

USE CASE 4. Run Manual Reports:
 Actor: ATX Administrator, ATX Support Staffer
 Pre-condition:
o PennDOT or ATX staff requests the generation of specific reports.
o The ATX Admin logs on to the system.
o Report templates and database requests are created as specified in the
Gatekeeper User’s Guide.
 Flow of Events:
1. ATX Admin selects a report to run from Reports GUI
2. ATX system runs the report. This includes:
 Query for information
 Build report
3. The system gives the ATX Admin the options to view, save and print the
report
4. (Optional) ATX Admin or Support Staffer views report
5. (Optional) ATX Admin or Support Staffer saves the report
6. (Optional) ATX Admin or Support Staffer prints report
 Post-condition: Report is available to view/save/print report
 Scenario: PennDOT wants to see a list of all the dealers under contract to the
Business Partner (ATX) and notifies ATX via email or regular mail that the report
is required. The ATX Admin runs, prints and then sends the report to PennDOT
via regular mail.

USE CASE 5. Run Scheduled Reports:
 Actor: ATX Scheduler, ATX Administrator
 Pre-condition:
o Report templates are created as specified in the Gatekeeper User’s Guide

5
o ATX Scheduler is configured to run specific reports at specific times (these
are required by PennDOT or ATX Staff on a regular basis).
o Reports are designed to summarize activity for all PCCS Users for a specific
period of time.
 Flow of Events:
1. ATX system starts report processing at scheduled time.
2. ATX system is authorized to run reports on all PCCS activity
3. ATX executes the query and generates the report. This shall involve
formatting the results of the query with the standard template.
4. Reports are saved and available for the ATX Administrator to access.
5. The ATX Admin views and prints the reports at some point in time after the
reports are generated
 Post-condition: Report is available to the ATX Administrator to view and print.
 Scenario: PennDOT requires some reports to be generated at some predefined
regular intervals, so

USE CASE 6. Run PCCS User Reports:
 Actor: PCCS User
 Pre-condition: Report templates are created to summarize transaction activity for
the initiating PCCS location for the specified time period.
 Flow of Events:
1. PCCS initiate a standard report from ATX
2. ATX authorizes the request – only allow reports on activity for the following:
 PCCS’s account
 PCCS User’s specific transactions. This also implies associated dealers for
that location
3. ATX executes the query and generates the report. This shall involve
formatting the results of the query with the standard template.
4. The system shall allow the PCCS User to view and/or print the report via the
client software.
 Post-condition: Report is available to the PCCS User
 Scenario: A PCCS user wants a report on of all transactions that were processed at
their location for the last week of business.

USE CASE 7. Send Message to Gatekeeper:
 Actors: PCCS (where ATX is acting in response to the initial request by the
actor), Gatekeeper (GK)
 Pre-condition: ATX received a request from (authenticated) PCCS, reads the
contents of the request and identifies the appropriate GK message to send (for
example see Process a Transaction Request use case).
 Flow of Events (generic description):
1. ATX creates an AAMVA BPEVR record with the information supplied.
2. ATX sends the message to the GK interface.

6
3. ATX determines that the message is successfully received, and then waits for
an acknowledgement from the GK.
4. ATX receives a successful acknowledgement from GK with WID.
 Post-condition: Successful acknowledgement received and WID is saved.
 Exception Cases:
1. ATX determines that the information supplied is incomplete.
 Response: ATX sends the PCCS a notification of the error.
2. ATX timeout condition is reached while waiting for GK response (Timeout
value TBD)
 Response: ATX resends the message to GK. After TBD attempts is sends
the PCCS a notification of the error.
 Scenario: “Process a transaction request” use case is executed.

USE CASE 8. Receive Document Images from PCCS:
 Actors: Participating Company Client System (PCCS)
 Pre-conditions:
o The Gatekeeper portion of the transaction has completed successfully and a
WID has been returned to the PCCS.
o PCCS has image files named according to WID convention.

 Flow of Events (generic description):
1. PCCS sends image files to ATX (TBD - likely through FTP)
2. PCCS informs ATX that images have been sent and ready for transmission to
PennDOT and sends checksum of image files.
3. ATX confirms checksum of local images match signature sent by PCCS.
4. ATX updates associated transaction record to identify that images are
awaiting transmission to PennDOT.
5. ATX adds each image to the list of daily image queue that should be
transmitted to PennDOT.
 Post-condition: The document transfer is identified as complete.
 Exception Cases:
1. Images transfer did not occur or files were corrupt.
a. Response: ATX must indicate to PCCS to resend.
 Scenario: During a title transfer transaction, the initial request is successfully
processed by Gatekeeper. Gatekeeper responds with WID. ATX requests PCCS
transfer related images.

USE CASE 9. Transfer Images to PennDOT:
 Actors: ATX scheduler
 Pre-condition: Images have been received from PCCS, and are in appropriate
“pickup” location.
 Flow of Events (generic description):
1. At scheduled time, Scheduler initiates image transfer task.
2. ATX opens FTP session to PennDOT.
3. ATX transfers each images on daily images list to PennDOT.

7
4. ATX transmits log file w/ checksum of each file. (TBD - This is something
that we should suggest to PennDOT so they can confirm that images were
received ok)
5. ATX updates transaction record associated with each image to indicate that
the images have been transferred to PennDOT.
6. ATX deletes images from local storage (TBD - can we do this now?)
 Post-condition: Images successfully transferred to PennDOT.
 Exception Cases:
1. ATX can not open FTP session to PennDOT, site not available.
b. Response: ATX scheduler schedules a resend at current time +
30mins.
c. Three attempts will be made then if still not available, transfer is
cancelled and error notification is sent to PennDOT via email (TBD –
is this how it should work?)
 Scenario: PCCS transfers images related to a title transfer transaction. At the end
of the business day, ATX forwards these images along with other received during
the day to PennDOT.

USE CASE 10. Process client log in:
 Actors: Participating Company Client System (PCCS)
 Pre-condition: PCCS user enters a username and password and starts the log in
process. PCCS and the system exchange data via cleartext protocol (e.g. TCP/IP).
PCCS has a public key issued by the system when partnership is first established.
 Flow of events (generic description):
Authentication between PCCS and the system is done through challenge/response.
Security features include public/private key, nonce and salting. The use case
protects the authentication protocol against dictionary attack, reply attack, session
hijacking and other easily exploitable security holes. The data exchange between
PCCS and the system consists of the username, password and security add-ons.
All other information (e.g. PennDOT required information) is stored in the system
in an account associated with the username.

o PCCS initiates client log in by sending its username to the system
o The system replies with an encrypted nonce. This step is designed to prevent
replay attacks. The following steps are necessary to generate the message:
 Generate a random nonce
 Encrypt the nonce with the private key associated with the username from
step 1
 Send encrypted nonce back to PCCS
o PCCS sends username, password along with security add-ons to the system.
The following steps are necessary to generate the message:
 Decrypt nonce using its public key
 Calculate a hash H1 of username|password|nonce
 Send {username, password, hash H1} to the system
o The system calculates its own hash H2 for username|password|nonce. The
system uses nonce it originally generated in step 2.

8
o The system verifies that H1 == H2.
o The system looks up the stored salt for the password; applies salt and
calculates a new hash H3
o The system verifies that H3 matches hash H4 stored in the user account
o User and computer are authenticated.
 Post-condition: If the user is using an authorized computer and supplies proper
credentials, the user is authenticated by the system. Otherwise, log in attempt is
denied by the system. If the user is authenticated, the session begins.
 Exceptions:
 If H1 != H2, log in is denied. The denial is most likely due to use of an
unregistered computer (computer authentication). Error message is sent to
PCCS.
 If H3 != H4, log in is denied. The denial is most likely due to the use of a
wrong password (user authentication). Error message is sent to PCCS.
 Scenario: Alice, an employee of a PCCS, comes to work and begins serving
customers. In order to use the workstation she provides user name and password
at the start of her work day.

USE CASE 11. Process client log out:
 Actors: Participating Company Client System (PCCS)
 Pre-condition: The user is logged in into the system and an active session is in
progress.
 Flow of events (generic description):
1. PCCS requests a log out
2. The system clears session state for the user
3. PCCS is notified that log out is complete
 Post-condition: The user is logged out from the system. Any further use of the
system requires a new log in (see USE CASE 10.)
 Scenario: At the end of the work day Alice, an employee of a PCCS, logs out
from the system.

USE CASE 12. Terminate Session
 Actors: ATX User Manager
 Pre-condition: At least one active session with PCCS is in progress
 Flow of events (generic description):
1. Scheduling agent determines the timestamp for the last transaction in each
active session
2. (Optional) If timestamp is near a specified threshold (e.g. a minute away)
o PCCS is notified with a warning message
o PCCS can specify to keep the session alive
 Exception:
1. If timestamp is older than a specified threshold (TBD)
o Response: The session is terminated and the PCCS is notified (for
example with a message)
 Post-condition: At all times only sessions which have recent transaction remain
active

9
 Scenario: At the end of the work day Alice, an employee of a PCCS, forgets to
log out from the system. To prevent a security breach, Alice's session is
automatically terminated.

USE CASE 13. Expire Password
 Actors: ATX User Manager
 Pre-condition: User logs in to the system
 Flow of events (generic description):
1. ATX User Manager determines the password of the user has exceeded the
expiration threshold (TBD)
2. ATX User Manager prompts PCCS user to change password
3. PCCS user changes password
4. ATX system stores password with proper encryption
 Exception:
1. User refuses to change password
o Response: ATX suspends user account
 Post-condition: new user password is stored with proper encryption
 Scenario: After (TBD) days of using the system, the user logs in.

USE CASE 14. Reset Forgotten Passwords
 Actors: ATX Support Staffer
 Pre-conditions:
o PCCS User has a username and an established relationship with the
system.
o PCCS User has successfully logged onto the system in the past (active
account).
o PCCS User forgot his/her password
o PCCS Admin requests a password reset from ATX staff via email.
 Flow of events (generic description):
1. ATX Support Staffer views the PCCS account using the PC Account
Management UI.
2. ATX Support Staffer selects the account that will be affected.
3. ATX Support Staffer selects reset password action
4. ATX system updates the account information in the PC Accounts repository.
5. ATX system notifies the associated PCCS Admin that the password has been
reset. This notification indicates temporary password.
 Post-condition: PCCS User account is updated with temporary password and re-
activation is required. Email is sent to PCCS Admin.
 Scenarios: PCCS user attempts to log on to the system but has forgotten his/her
password

USE CASE 15. Change Passwords
 Actors: Participating Company Client System (PCCS)
 Pre-conditions: PCCS has a username and an established relationship with the
system. PCCS logs on to the system
 Flow of events (generic description):

10
1. PCCS enters and confirms the new password
2. The system verifies that the password meets the strong password guidelines
(e.g. at least 6 characters long, has both upper and lower case characters, has
at least one number)
3. If PCCS supplied password does not meet the strong password criteria, the
system will explain to PCCS why the password was not changed
 Post-condition: Strong passwords are maintained by the system for all active
PCCS accounts at all times.
 Scenarios: When an Eve, a poorly performing employee, is fired from PCCS,
manager wants to change the password to make sure that there is no security
breach. The system helps the manager to pick a strong password.

USE CASE 16. Add Participating Company Account
 Actors: ATX Administrator
 Pre-condition:
o PennDOT approves a new Participating Company for the Business Partner
o Server Administrator logs on to the system.
 Flow of Events:
1. ATX Administrator adds accounts for a new Participating Company (PC)
using the Account Management UI by entering information for the PC
2. ATX (system) verifies that an account for the PC does not already exist
3. ATX stores account information in the PC Accounts repository
4. ATX indicates the creation of the PC account is successful.
5. ATX Administrator views the Participating Company (PC) accounts using
the PC Account Management UI.
 Exception:
1. ATX determines that the PC account already exists
 Response: ATX notifies the ATX admin of the error
 Post-condition:
o The account management should start working right after the Server
Administrator confirms the modification, e.g. even in case of the affected
account already logged into the server, the management purpose (add,
delete) should take into effect.
 Scenario:
o When the contract with some Participating Company has expired,
Business Partner will remove the accounts associated with that company.
o A new Participating Company has been approved by PennDOT and ATX,
Business Partner will add the accounts associated with that company..

USE CASE 17. Change/Delete Participating Company Account
 Actors: ATX Administrator
 Pre-condition:
o ATX staff or PennDOT determines that a participating company account
should be changed, deleted, suspended, or reactivated.
o Server Administrator logs on to the system.

11
 Flow of Events:
1. ATX Administrator views the Participating Company (PC) accounts using
the PC Account Management UI.
2. ATX Administrator selects the account that will be affected.
3. ATX Administrator selects the desired action. Actions include:
 Change Participating Company account
 Delete Participating Company account
 Suspend Participating Company account
 Re-activate a previously suspended Participating Company account
4. In the case of changing the account, ATX Administrator edits the account
information
5. ATX (system) updates the account information in the PC Accounts
repository
6. ATX indicates the update to the PC account is successful.
 Post-condition:
o The account management should start working right after the Server
Administrator confirms the modification, e.g. even in case of the affected
account already logged into the server, the management purpose (change,
delete, suspend, reactivate) should take into effect.
 Scenario:
o Under request of Participating Company, Business Partner wants to reduce
some account associated with the Participating Company.

USE CASE 18. Schedule Tasks
 Actors: ATX Administrator
 Pre-condition:
o Report templates and database requests are created as specified in the
Gatekeeper User’s Guide.
o Necessary hardware for performing backup is ready for use (e.g. DAT
drive and tape).
o ATX Admin is logged on to the system
o If task involves non-integrated configuration software (e.g. COTS
backup), ATX admin has access to configuration parameters
 Flow of Events:
1. ATX Admin selects the type of task to schedule from Scheduling GUI.
Three types of tasks are possible:
 Send images to PennDOT
 Run reports
 Perform system backup
2. ATX Admin views and/or changes task parameters
3. ATX Admin inputs start date of task and recurring schedule.
4. ATX stores scheduling information
5. (Optional) ATX Admin views currently scheduled tasks
 Post-condition: The following tasks can be scheduled to occur at the time
specified
o Send images to PennDOT

12
o Run reports
o Perform system backup
 Scenario:
o ATX Admin wants to schedule the time that document images will be
transferred to PennDOT FTP site each day.

USE CASE 19. Run PCCS Summary Reports:
 Actor: PCCS Administrator
 Pre-condition: Report templates are created to summarize activity for all PCCS
locations for a specified time period.
 Flow of Events:
1. PCCS Admin initiates a standard report from ATX
2. ATX authorizes the request – only allow reports for the following:
 PCCS’s account
 Associated Users and dealers for that PCCS
 All locations for that PCCS
3. ATX executes the query and generates the report. This shall involve
formatting the results of the query with the standard template.
4. The system shall allow the PCCS Admin to view and/or print the report
via the client software.
 Post-condition: Report is available to the PCCS Admin
 Scenario: A PCCS Admin wants a report on of all transactions that were
processed at all their locations for the last week of business, so the report is run,
saved and printed to send to the ATX staff via regular mail.

USE CASE 20. Create New User Account
 Actors: ATX Support Staffer
 Pre-condition:
o PennDOT sends a letter to ATX staff indicating that a new user account
has been approved for a particular participating company
o The notification includes user information, PCCS information, temporary
user name and new secondary ID
 Flow of Events:
1. ATX Support Staffer views the PCCS account using the PC Account
Management UI.
2. ATX Support Staffer selects the account that will be affected.
3. ATX Support Staffer selects new user add action.
4. New User Entry screen of PC Account Management UI allows ATX Support
Staffer to enter information and active the account
5. ATX system updates the account information in the PC Accounts repository.
This includes
 Setting privileges for account
 Setting new user password
 Indication of new account to Account Manager (requiring first-
time user action – change password)

13
6. ATX system notifies the associated PCCS Admin that a new user has been
added. This notification indicates new user name and temporary password.
7. ATX system indicates to ATX Support Staffer
 Post-condition:
o A new user account is established for the particular user for an associated
PCCS
 Scenario: A new user is requested by PCCS to be added to their account.

USE CASE 21. Identify Stale User Account
 Actors: ATX User Manager
 Pre-condition:
o No activity has been logged for a particular user for a period of one year
 Flow of Events:
1. ATX User Manager queries transaction record for the last year to date for all
active accounts
2. A particular user is identified as having no activity for the last year
3. ATX User Manager sets the status of the account to Suspended.
4. ATX User Manager notifies the PCCS Admin and the ATX admin that the
account has been suspended.
 Post-condition:
o The account of the user that has not processed any transaction in the last
year is set to Suspended and email notification is sent.
 Scenario: A user has been terminated by the PCCS and notification has not been
given to ATX.

USE CASE 22. Identify Inactive User Account
 Actors: ATX User Manager
 Pre-condition:
o A suspended account has not been reactivated since it was suspended 3
months ago
 Flow of Events:
1. ATX User Manager queries transaction record for last 3 months for all
suspended accounts
2. A particular suspended account is identified as having no activity for the last 3
months
3. ATX User Manager sets the status of the account to Inactive.
4. ATX User Manager notifies the ATX admin that the account has been
Inactivated.
 Post-condition:
o The suspended account is set to Inactivated and email notification is sent.
 Scenario: A user has been terminated by the PCCS and notification has not been
given to ATX even after suspension notification sent.

USE CASE 23. Update PCCS Inventory Sequence
 Actors: ATX Support Staffer
 Pre-condition:

14
o A PCCS notifies the ATX staff that new inventory of license plates have
been received.
 Flow of Events:
1. ATX Support Staffer views the PCCS account using the PC Account
Management UI.
2. ATX Support Staffer selects the account that will be affected.
3. ATX Support Staffer selects update inventory sequence.
4. New User Entry screen of PC Account Management UI allows ATX Support
Staffer to enter sequence of new inventories
5. ATX system updates the account information in the PC Accounts repository.
This includes
6. ATX system indicates that inventory sequence is updated successfully
 Post-condition:
o The PCCS account is updated with new inventory sequence
 Scenario: A PCCS received a new set of license plates from PennDOT