Assignment

QUESTION 1: At this time, what is your best / favorite definition of "System Analysis"? Provide a reference to the source of the definition.

QUESTION 2: What is the "System Development Life Cycle (SDLC)"?

QUESTION 3: Explain about the Unified Modeling Language (UML) so far. To continue to get familiar with "UML" style diagrams, please fill in the following Table 1:

Table 1. UML Summary

QUESTION 4: We have introduced"Use Cases". What information is provided by either a List Format Use Caseor a Use Case Diagram? Please summarize.

QUESTION 5: From our textbook, the SDLC Core Process 3 essentially represents "Systems Analysis", where you Gather Detailed information, Define Requirements, Prioritize Requirements, Develop User-Interface Dialogues and Evaluate Requirements with users. A key repeating term here is "requirement". With that in mind, please research and provide answers to the following questions about "requirements". (Note: Do NOT use your textbook. Find an online resource. Provide the reference.

Question 6: The RMO CSMS problem discussed in class identifies many "Stakeholders" - "Internal" and "External" as well as "Operational" and "Executive", with multiple types of each. In your own words, what do you believe is the primary problem / issue / challenge in dealing with "Stakeholders"? Justify your response.

Question 7: Our textbook suggests that, when interviewing stakeholders, there are multiple "themes" that must be covered with all stakeholders. What are these "themes"?

Question 8: Research "Use Case Diagram" and "Class Diagram". How do a Use Case Diagram and a Class Diagram collectively (together) drive the overall system development process?

Question 9: What are the benefits of doing vendor research during early project information-gathering activities?

Question 10: One problem in investigating system requirements is to make sure they are completeand comprehensive. How would you go about ensuring that you get all the right information during an interview session with Stakeholders. Start with your textbook.

Question 11: Research the topic of "scope creep", which occurs when stakeholder request additional features an1 functions. How would you go about keeping a system that you are analyzing from growing and possibly including new functions that should not be part of the system?

Questions 12-23: THE STATE PATROL TICKET PROCESSING SYSTEM (TPS)

Imagine that you have been asked to perform "Systems Analysis" on the following Ticket Processing System (TPS) Description and Requirements. Please read:

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 separate system produces driving record reports from the ticket and accident records for insurance companies. Finally, a fourth separatesystem 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.

How to Analyze: So...how do you get started making sense of all these words? In industry, a "time-proven" approach is to parse the words into individual, concise, single thought statements in order to "expose" and separate out "requirements" from "non-requirements". This parse is performed to the level where you can recognize individual Requirements. Recall that in class we discussed Requirements and the fact that they must be simple, concise, verifiable statements.

Your instructor has parsed the above TPS description into the following Table 2 . The Statements are numbered in tens (10, 20, 30, etc.). This is done in case you ever want to add in 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 2. TPS Statements Parse

With this TPS information now in hand, please answer these questions:

Question 12: Review the original TPS description and compare it to the "parse" provided inTable 2. Is the parse complete? Or, was anything missed when translating the TPS description to the parse?(Hint: It is possible something is missing).

Question 13: Do you agree with the stated TPS functions and interfaces listed in the parse provided in Table 2? (Hint: It is OK if you do not. This is just one person's take on the TPS system. What is your opinion?).

Question 14: What primary "Actors / Stakeholders" are outside the TPS and trigger events? Please list.

Question 15: Consider External and Internal Events (discussed in Session 3 / Chapter 5. Also discussed in detail in Chapter 3 of textbook). To what Events must the TPS respond?Using Table 3 (see below), please fill in the list of event(s), type of event and define a resulting use case. Use as many rows as necessary (you can add rows to the table).

Table 3. TPS Events Summary

Question 16: For each Use Case listed in Table 3 above, please write a brief textual Use Case Description. Use Table 4. Add rows as necessary.

Table 4. Use Case Descriptions Summary

Question 17: What external interfaces provide inputs to the TPS?Please list external inputs in Table 5 below.

Table 5. TPS Input Interface Summary

Question 18: What data does the TPS store in the Database that is shared with the other systems?Please list.

Question 19: Based on what you know so far, what MAJOR internal TPS Functions are required to process inputs and turn them into outputs? Look for core functionality in the requirements.

Question 20: What outputs are provided by the TPS? To who? Please fill in the following table.

Table 6. TPS Output Interface Summary

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.

Figure 1. Sample TPS "Context Diagram"

Question 21: Using your drawing tool of choice, please draw your own best original version of Figure 1. Do not just provide this back as your input. You must draw your own diagram. It must show a) TPS System Boundary, b) External Input Interfaces, c) External Output Interfaces, d) Major Internal System Functions, e) Major Internal System Interfaces.

Question 22: Pick one Use Case listed in Table 3 or Table 4. Develop a System Sequence Diagram (SSD) (discussed in Session 3 / Chapter 5) for that one Use Case. Provide a written explanation with the System Sequence Diagram.

Question 23: Develop a State Machine Diagram(SMD) for a ticket being issued to a driver. Consider that the "ticket" is an object that changes states over time.