Case Study: The State Patrol Ticket Processing System
The State Patrol Ticket Processing System The purpose of the State Patrol ticket processing system is to record driver violations, to keep records of the fines paid by drivers when they plead guilty or are found guilty of moving violations by the courts, and to notify the court that a warrant for arrest should be issued when such fines are not paid in a timel timely y mann manner er.. A sepa separa rate te Stat State e Patr Patrol ol syst system em reco record rds s acci accide dent nts s and and verification of financial responsibility (insurance). Yet a third system produces driving driving record record report report from from the ticket ticket and accide accident nt record records s for insura insurance nce compan companies ies.. Finally Finally,, a fourth fourth system system issue issues s renews renews,, or suspen suspends ds driver’ driver’s s licens licenses. es. These These four four system systems s are obviou obviously sly integr integrate ated d in that that the share share access to the same database, but otherwise, they are operated separately by different departments of the State Patrol. State Patrol operations (what the officers do) are entirely separate. The portion of the database used with the ticket processing system involves driver driver data, ticket data, officer data, and court data. Driver data, officer data, and court data are used by the system. The system creates and maintains ticket data. Driver attributes include license number, name, address, date of birth, date licensed, and so on. Ticket attributes include ticket number (each is unique and pre-printed on each sheet of the officer’s ticket book), location, ticket type, ticket date, ticket time, plea, trial date, verdict, fine amount, and date paid. Court and officer data include the name and address of each, respectively. Each driver may have zero or more tickets, and each ticket applies to only one driver. Officers write quite a few tickets. When an officer gives a ticket to a driver, a copy of the ticket is turned in and entered into the system. A new ticket record is created, and relationships to the correct driver, officer, and court are established in the database. If the driver pleads guilty, he or she mails in the fine in a pre-printed envelope with the ticket number on it. In some cases, the driver claims innocence and wants a court date. When the envelope is returned without a check and the trial request box has an “X” in it, the system notes the plea on the ticket record, looks up driver, ticket, and officer information, and sends a ticket details report to the appropriate court. A trial date questionnaire form is also produced at the same time and is mailed to the driver. The instructions on the questionnaire tell the driver driver to fill in convenient convenient dates and mail the questionnaire questionnaire directly directly to the court. Upon receiving this information, the court schedules a trial date and notifies the driver of the date and time. When When the trial is comple completed ted,, the court court sends sends the verdic verdictt to the ticketing ticketing system. The verdict and trial date are recorded for the ticket, If the verdict is innoce innocent, nt, the system system that that produc produces es drivin driving g record record report reports s for insura insurance nce companies will ignore the ticket. If the verdict is guilty, the court gives the driver another envelope with the ticket number on it for mailing in the fine. If the the driv driver er fail fails s to pay pay the the fine fine with within in the the requ requir ired ed peri period od,, the the tick ticket et processing system produces a warrant request notice and sends it to the court. This happens if the driver does not return the original envelope within
two weeks or does not return the court-supplied envelope within two weeks of the trial date. What happens then is in the hands of the court. Sometimes the court requests that the driver’s license be suspended, and the system that processes drivers’ licenses handles the suspension.
1.
To what events must the ticket processing system respond? Create a complete event table listing the event, trigger, source, use case, response, and destination for each event.
List of events and resulting use cases with explanations:
1. Event: Officer submits a ticket. Use case: Record new ticket.
The officer giving the ticket to the driver is outside of the scope of this system. It is part of the state patrol operations system that also includes checking the driver’s license and car registration and other interactions between the officer and the driver.
2. Event: Driver sends in fine payment. Use case: Record fine payment.
The fine payment event can happen right after the ticket if the plea is guilty or after a trial is completed if the verdict is guilty. In this respect, the event is “reused.” Some students might call this event “driver pleads guilty” versus “driver requests a trial.” They are on the right track, but this doesn’t allow the reuse of the event following a trial.
3. Event: Driver requests a trial. Use case: Process trial request.
Even though the same envelope is returned in the existing physical system, this is a separate event in terms of the processing required. If a trial is requested, the system sends information to the court and sends the questionnaire to the driver. The driver and the court then work out the details of the trial. The questionnaire is not returned to the ticket processing system
4.
Event: Court sends in verdict. Use case: Record verdict.
Here the court simply sends in information about the verdict, either guilty or innocent. If the verdict is guilty, the court gives another envelope to the driver to send in payment for the fine.
5.
Event: Time to produce warrant request. Use case: Produce warrant request.
This event occurs if the fine is not paid immediately or if the fine is not paid following a trail. It is another example of reuse.
Event Table
Event
Trigger
Source
Use Case
1. Officer submits ticket
New ticket
Officer
Record new ticket
2. Driver sends in fine payment
Fine Payment
Driver
Record fine payment
3. Driver requests trial
Trial request
Driver
Process trial request
Response
Destination
Trail data questionnaire
Driver
Ticket details 4. Court sends in verdict
Verdict
5. Time to produce warrant request
“two weeks after fine is due (originally or after trial)”
2.
Court
Court
Record verdict Produce warrant request
Warrant request notice
Court
Develop fully developed use case descriptions for two of the primary use cases
Use Case Name: Scenario: Triggering Event: Brief Description:
Actors: Stakeholders:
Record traffic ticket Record traffic ticket Officer sends in new ticket The officer gives the traffic ticket to the clerk. Using the information on the traffic ticket, the clerk first verifies the officer by entering the badge number. Then, the clerk verifies the driver information by entering the driver’s license number. Finally, the clerk enters the ticket information. Clerk Manager
Preconditions: Postconditions: Flow of Events:
Exception Conditions:
Use Case Name: Scenario: Triggering Event: Brief Description:
Actors: Stakeholders: Preconditions:
Postconditions: Flow of Events:
Exception Conditions:
Officer The officer must exist. The driver must exist. The ticket must exist and be associated with the driver, the officer, and a court. Actor System 1. Clerk enters officer badge 1.1 System reads officer number. information and displays the name. 2.1 System reads the driver 2. Clerk enters driver’s license information and displays the number. driver name and address. 3.1 System displays ticket 3. Clerk enters ticket and driver information. information. 1.1 Officer is not found. 2.1 Driver is not found.
Enter plea Enter not guilt plea Driver requests trial. The clerk reviews the letter from the driver. If the driver requests a court date (pleads not guilty), the clerk enters that information. The system produces a formatted return letter to the driver. Clerk Manager The driver must exist. The ticket information must exist. The court must exist. The ticket information is updated. Actor System 1. The clerk enters the not guilty 1.1 The system finds the plea requesting a court date. driver and ticket and updates the ticket information. 1.1 Driver or ticket cannot be found in the system.
