CS-255 SNHU System Analysis and Design
Briefly summarize the DriverPass project. Who was the client? What type of system did they want you to design?
The client DriverPass wanted to increase the passing rate of students taking driving tests at their local DMV by creating a system that allowed users to schedule on-the-road driving lesson with trainers and cars, as well as take online classes and practice tests to increase their driving experience and knowledge. The system would be accessible from any computer or mobile device on any web-browser, anywhere and anytime. They wanted to sell different packages over this web-based cloud hosted system to unlock the additional functionality of scheduling to take driving lessons and actively taking online courses and practice tests. It was never clarified how DriverPass would measure the success of their overall goal, as users would have to self-report the success or failure after presumably not needing the system anymore.
What did you do particularly well?
Despite mostly negative feedback, I believe my final business requirements document contains all necessary information. Additionally, the UML Use Case diagram I created is easy for me to read and understand after lots of editing.
If you could choose one part of your work on these documents to revise, what would you pick? How would you improve it?
I have already spent dozens of hours on the business requirements document, so I would focus on improving my UML diagrams. The resources provided to learn to create different UML diagrams did not offer many examples to reference, so knowing if they are consistent with industry standards, if such a thing even exists, is impossible. I would ensure that every element in each diagram was appropriately placed, sized, and used.
How did you interpret the user’s needs and implement them into your system design? Why is it so important to consider the user’s needs when designing?
There was only one interview transcript defining what DriverPass wanted its users to accomplish in the system. By breaking down each topic discussed in that interview, the user's needs to accomplish desired tasks became apparent. For instance, a secretary will need to be able to access student info to make a reservation for them, which helps define what must be included in design documents concerning the secretary, students, and reservations. Interpreting the client's desires is as simple as listening to what they want and writing it down. If something sounds too complicated to be broken down into easy parts, additional dialogue with the client should clear it up.
How do you approach designing software? What techniques or strategies would you use in the future to analyze and design a system?
Starting with an initial pass of an interview transcript between representatives from both a consulting company and their client, DriverPass, I tried to determine what the client wanted from a new system. I placed those requirements in a business requirements document (BRD) and submitted it for review. Through feedback, I was informed several details were lacking in my BRD. Even after several iterations of incorporating notes, additional feedback from a second review stated it was still lacking specifics. Prior to submitting my BRD to this repository, I reviewed the interview transcript for perhaps a thirtieth time to squeeze any further detail from it that I may have missed. Below is my last set of notes I took during this final review with quotes directly taken from the interview transcript that I used to crosscheck and update my attached BRD. Although to some readers my BRD may still be incomplete even now. In the future I will be overly specific during the requirements gathering phase to account for every word that may even hint at a desired requirement. Clearing up requirements should be an iterative process with a two-way discussion, which is not how this project was designed to be... designed.
Last notes from the DriverPass Interview Transcript:
Liam, the owner (a.k.a., “the big boss”) of DriverPass, wants to offer “better driving training” to students so they pass their driving tests “at their local department of motor vehicles (DMV).” He also wants to access “my data” and download “reports” from “anywhere” on “any computer or mobile device” so he can work on them in “Excel”, for example. Additionally, the owner would like “tracking” on “who made a reservation, who canceled it, who modified it last” for accountability and “to be able to print an activity report” to see where responsibility lies. Furthermore, the big boss wants to initially offer “three packages” with the immediate ability to “disable” them for registration control. He also wants to be able to “customize these packages—remove some of them, add new ones” in the future “so the system has to be flexible.” All three packages include time “in a car with a trainer” for driving lessons in two-hour “on-the-road training” sessions. There are also “an in-person lesson” with an explanation of the “DMV rules and policies” and “access to” an “online class with all the content and material” including “practice tests.” Package one has three two-hour sessions (i.e., “Six hours in a car with a trainer”), package two has four two-hour sessions (i.e., “Eight hours“) plus an in-person lesson, and package three has six two-hour sessions (i.e., “Twelve hours“), an in-person lesson, and access to the online training materials including classes and practice tests. A student registering for a package must enter “their first name, last name, address, phone number, state, and their credit card number, expiration date, and security code”, presumably so a payment for registering may be processed. Students should be able to “take online classes and practice tests” after purchasing package three. Additionally, by providing “the day and time when they want to take” a lesson, students should also “be able to make reservations for driving lessons” appointments “online using their account” that are “two hours long”. Besides time, the reservations should also “identify the driver the customer is scheduled to go out with” as well as the “car” for tracking purposes. Students should also be able to “cancel” or “modify appointments online if they wish”. Liam had mentioned while discussing registration to include a “pickup location from where the customer wants to be picked up” and “a drop-off location” which should be the same location, but that information seems more appropriate for specific appointments as a student’s permanent address may change, for example. A student should also be able to “automatically reset” their password if they forget it. A DriverPass secretary may help students “make reservations for driving lessons” appointments that are “two hours long” if the student were to call or visit the office. While not clearly defined in the interview, secretaries should be able to “cancel” or “modify appointments” for a student as well. Also, while not clearly defined in the interview, Liam mentioned “we get a phone call” during the package registration section which indicates a secretary may also help a student buy a package. However, the mention of “do not want to deal with backup and security” further in the interview may conflict with employees handling sensitive student data, such as credit card information. DriverPass should stay “connected to the DMV” to keep updated “with new rules, policies, or sample questions” and send “notifications” when any update occurs. This “up-to-date” connection provides “compliance” with the DMV by ensuring that the “tests and practice” provided are “current with what the DMV requires.” The system’s interface “needs to run off the web, preferably over the cloud” so DriverPass employees can focus “on running the business with minimal technical problems” instead of dealing “with backup and security”. What to backup was not clearly defined, but the same “reports” wanted by the owner and account information is the data I would choose to back up. The “security” may be related to account information, logging in, or the credit card transaction used to purchase packages, but is also not clearly defined. Passing on the responsibility for “backup and security” would have to be handled by outside actors, such as renting a database with security from a trusted online vendor and having a payment processor for credit card transactions. The “big boss” provided an image of what he wanted the interface to look like, which included a “LOGO”, “Online test progress” (including “show the tests the customer took”, “show what’s in progress and the ones that the customer completed”, with the fields: “test name, time taken, score, and status” and status having the subfields: “not taken, in progress, failed, or passed.”), “Information(first name, last name, address, city, state, zip, phone, email, …etc.)”, “Driver notes” (including “Lesson Time”, “Start Hour”, “End Hour”, and “Driver Comments”), “Special needs”, “Driver photo”, and “Student photo”. There “should be a page for contacting” DriverPass “and a way to contact the student.” Ian, the information technology (IT) officer at DriverPass, wants “full access over all accounts” so he may “reset them if someone forgets their password” or “block their access” if a different employee at the company is let go. Each employee role will have different rights in the system. Ian “will be responsible for maintaining the system, modifying it, et cetera”. The consulting company’s schedule for the project gave a clear layout of the schedule and of the limited team members working on the project. I created a GANTT chart based on that schedule. There was a mention the consulting company would “build the database tables and link it to the interface” and the “need to add the business logic(security, role, right) layer” which helps loosely define each role will have different rights or access to the system’s functions.