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 timely manner. A separate State Patrol system records accidents and verification of financial responsibility (insurance). Yet a third system produces driving record report from the ticket and accident records for insurance companies. Finally, a fourth system issues renews, or suspends drivers licenses. These four systems are obviously integrated in that the 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 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 officers 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 to fill in convenient dates and mail the questionnaire directly to the court. Upon receiving this information, the court schedules a trial date and notifies the driver of the date and time. When the trial is completed, the court sends the verdict to the ticketing system. The verdict and trial date are recorded for the ticket, If the verdict is innocent, the system that produces driving record reports for insurance 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 driver fails to pay the fine within the required period, the ticket 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 drivers 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 drivers 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 doesnt 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 1. Officer submits ticket 2. Driver sends in fine payment 3. Driver requests trial Trigger New ticket Fine Payment Trial request Source Officer Driver Driver Use Case Record new ticket Record fine payment Process trial request Trail data questionnaire Ticket details 4. Court sends in verdict 5. Time to produce warrant request Verdict two weeks after fine is due (originally or after trial) Court Record verdict Produce warrant request Warrant request notice Court Driver Response Destination

Court

2. cases

Develop fully developed use case descriptions for two of the primary use

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 drivers 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:

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 drivers 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.

Exception Conditions: