THE STATE PATROL TICKET PROCESSING SYSTEM (TPS)
System Description and Requirements:
The purpose of the State Patrol Ticket Processing System (TPS) is to record driver violations, keep records of 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 reports from the ticket and accident records for insurance companies. Finally, a fourth system issues, renews, or suspends driver’s licenses. These four systems are integrated in that they share access to the same database, but otherwise they are operated separately by different State Patrol departments. State Patrol operations (what the officers do on a daily basis) are entirely separate. Our focus is the TPS.
The portion of the database used with the TPS 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 Data attributes include license number, name, address, date of birth, date licensed, and so on. Ticket Data attributes include ticket number (each is unique and preprinted 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 preprinted 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; the system looks up driver, ticket, and officer information; then, 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 driver’s license be suspended, and the system that processes drivers’ licenses handles the suspension.
Requirements Parse – PLEASE REVIEW
How do you go about making sense of the above TPS description? One time-proven method is to “parse” the description into discrete Statements. This parse is performed to the level where you can discern the individual Requirements. Recall that in class we discussed Requirements and the fact that they must be simple, concise statements.
Your instructor has parsed the above TPS description into the following table. The Statements are numbered in tens (10, 20, 30, etc.). This is done in case you ever want to add statements. What you should find here is that every single character (word, comma, period) has been accounted for in this parse. Nothing should be missing from the original description. The “Statement Type” (column 3) indicates whether or not the Statement is a TPS requirement. The “TPS Functionality?” (column 4) contains comments regarding TPS Functionality.
Table 1. TPS Description Statements Parse
No. |
Statement |
Statement Type | TPS Functionality? |
10 | The purpose of the State Patrol Ticket Processing System (TPS) is to record driver violations, | Requirement | Yes – record driver violations |
20 | [The purpose of the State Patrol Ticket Processing System (TPS) is to] keep records of fines paid by drivers when they plead guilty or are found guilty of moving violations by the courts, and | Requirement | Yes – keep records of finds paid by drivers |
30 | [The purpose of the State Patrol Ticket Processing System (TPS) is to] notify the court that a warrant for arrest should be issued when such fines are not paid in a timely manner. | Requirement | Yes – notify court that a warrant for arrest should
be issued |
40 | A separate State Patrol system records accidents and verification of financial responsibility (insurance). | Guidance | No – separate system |
50 | Yet a third system produces driving record reports from the ticket and accident records for insurance companies | Guidance | No – separate system |
60 | Finally, a fourth system issues, renews, or suspends driver’s licenses. | Guidance | No – separate system |
70 | These four systems are integrated in that they share access to the same database, but otherwise they are operated separately by different State Patrol departments. | Guidance | No, but note specification of four systems |
80 | State Patrol operations (what the officers do on a daily basis) are entirely separate. Our focus is the TPS. | Guidance | No |
90 | The portion of the database used with the TPS involves Driver Data, Ticket Data, Officer Data and Court Data. | Requirement | Yes, specifies data requirements |
100 | Driver Data, Officer Data, and Court Data are used by the system. | Requirement | Yes, specifies input data requirements |
110 | The system creates and maintains Ticket Data. | Requirement | Yes. TPS must create and maintain
Ticket Data |
120 | Driver Data attributes include license number, name, address, date of birth, date licensed, and so on. | Requirement | Yes, specifies data requirements |
130 | Ticket Data attributes include ticket number (each is unique and preprinted 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 | Requirement | Yes, specifies data requirements |
140 | Each driver may have zero or more tickets, and each ticket applies to only one driver. Officers write quite a few tickets. | Guidance | TPS must handle multiple tickets per deriver and officer |
150 | When an officer gives a ticket to a driver, a copy of the ticket is turned in and entered into the system. | Requirement | Yes. TPS required input |
160 | A new ticket record is created, and relationships to the correct driver, officer, and court are established in the database. | Requirement | Yes. TPS required function. |
170 | If the driver pleads guilty, he or she mails in the fine in a preprinted envelope with the ticket number on it. | Requirement | Yes. TPS Required function. |
180 | 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; the system looks up driver, ticket, and officer information; then, sends a ticket details report to the appropriate court. | Requirement | Yes. TPS Required function and interface to Court |
190 | 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. | Guidance | No. Court function, not TPS. |
200 | 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. | Requirement | Yes. Required TPS interface and function. |
210 | 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 | Requirement | Yes. Required TPS interface and function. |
220 | 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. | Guidance | No. Court function. |
Please answer the following questions:
Refer to the (above) description of the State Patrol Ticket Processing System. Based on this description, please develop the following requested information. ( Note: This is an individual assignment. There is no exact “right” answer, depending on your interpretation of the description. The goal here is for you to carefully read – probably multiple times to get a full understanding – and interpret the description. Do not labor long hours over “is my answer “right” or “wrong”, but do show that you made a strong effort).
1. Review the original TPS description and compare it to the “parse” provided in Table 1.
Question: Is the parse complete? Or, was anything missed when translating the TPS description to the parse? (Hint: It is possible something is missing).
2. Do you agree with the stated TPS functions and interfaces listed in the parse provided in Table 1? (Hint: It is OK if you do not. This is just one person’s take on the TPS system).
3. Using Visio, PowerPoint or your favorite drawing tool – or even by hand – then embedding that diagram in this file – draw a context diagram showing how the TPS “fits” with the other State Police functions. For example, from the above description:
a. What external interfaces provide inputs to the TPS?
b. What MAJOR internal TPS Functions are required to process inputs and turn them into outputs?
c. What data does the TPS store in the Database that is shared with the other systems?
d. What are the major INTERNAL INTERFACES that are required to make the TPS Work?
e. What outputs are provided by the TPS? To who?
The following Figure 1 is one person’s version of a TPS Context Diagram. Please use it for INSPIRATION, recognizing that it may or may not be complete or correct. You must provide your own original version of this diagram in your submitted homework. Do not just provide this back as your input. You must draw your own diagram.
Figure 1. Sample TPS Context Diagram
4. What primary Actors / Stakeholders are outside the TPS and trigger events? Please list.
5. Consider External and Internal Events (discussed in Session 3 / Chapter 5. Also discussed in detail in Chapter 3 of textbook).
Question: To what Events must the TPS respond? Using Table 2 (see below), please fill in the list of event(s), type of event and a resulting use case. Use as many rows as necessary (you can add rows to the table).
Category of Event
(External or Internal) |
Triggered by |
Required TPS Response |
Required Use Case |
6. For each Use Case listed in Table 2, please write a brief Use Case Description. Use Table 3; add rows as necessary.
Table 3. Use Case Descriptions Summary
Use Case Name | Brief Use Case Description |
7. Pick one Use Case. Develop a System Sequence Diagram (SSD) (discussed in Session 3 / Chapter 5) for that Use Case. Provide a written explanation with the System Sequence Diagram.
8. Develop a State Machine Diagram for a ticket being issued to a driver. Consider that the
“ticket” is an object that changes states over time.
HINTS:
Q1. Is the original “System Description and Requirements” and the parse in Table 1
the same? You just need to compare the two and comment. You should find them
to be very, very close but not necessarily identical
Q2. In Table 1, do the identified TPS Functions and Interfaces make sense? Read each Statement in Table 1, focusing on the Requirements, and comment. Again, you should find that they make sense. You just need to review and comment.
Q3. Based on the information in Table 1, draw a “Context Diagram” that looks like the one shown in Figure 1; Figure 1 gives you a very good start. I built mine in PowerPoint, but you can use any drawing tool. I am just looking for you to draw your
own diagram. Everything inside the box should be major functions or interfaces
inside the TPS; everything outside the box should be an external interface. Essentially, convert the information from Table 1. into this diagram.
Q4. From Table 1 and your Context Diagram, identify the external Actors / Stakeholders. Make a list.
Q5. As discussed in lecture Session 3 (also book Chapters 3, 5), make of all the external Events to which the TPS must respond. A first obvious one Is receipt of a new ticket from an officer. Another one would be receipt of a ticket payment from a driver. Fill in Table 2 the best you can.
Q6. While filling out Table 2, you are ask to identified required Use Cases (right-most column). List these Use Cases again in Table 3 (left column) and provide a brief Use Case Description in right-hand column.
Q7. For just one Use Case in Table 3, develop an SSD (discussed in lecture
Session 3). Draw a System Sequence Diagram (SSD) and provide a brief written description.
Q8. Assume that a “ticket” is an object. For this object, develop a State Machine Diagram (SMD). Draw this picure. For example, a ticket is “issued”. What states does a ticket go through before it is finished?
Rev. 1 09/2016 Page 1 of 6
TPS BoundaryDriverOfficerTicketDatabaseProcessTicketNew TicketDataPleaProcessPleaPleaProcess Innocent Plea and VerdictCourtInnocent PleaVerdictWarrant RequestState Police Accidents / Insurance ReportingState Police DrivingRecord ReportsState Police DriversLicenses Processing•Court interacts with Driver re: Trial Date,unpaid fines and Warrant