Use Case Example
Yearlong Case Study Shows
Role Solves Problems
that Actor Cannot - Part 1 of 3
Executive Summary
This use case example is a case study of a financial Transaction Auditing Program (TAP) was put into production. It was then changed twice before a third change request was made. Every change represents additional cost to the organization including:
• Analysis time
• Architect time
• Developer time
• Testing time
• Delayed benefit stream projected for the program in the original cost-benefit analysis that got the project approved Additionally, the project users were unhappy leading to low customer satisfaction ratings. The case study finds that the way analysts originally thought about the business problem led them to write faulty requirements. That, in turn, forced developers to build a fragile system that could not handle change easily. The root cause of the thinking that led to the faulty requirements is using use case actors in the “industry standard” way. The case study shows how and why using roles instead of actors leads to better requirements that result in applications that satisfy, or even delight, your customers.
Start of Case Study - Problems with Actors
The use case example case study began when we received the following Change Request Form to modify an existing production application called Transaction Audit Program (TAP). TAP was designed to audit financial transactions to ensure compliance to standards and to detect potential fraud. Note: This use case example case study is based on actual events surrounding a financial application attempting to solve real business problems that would add dollars directly to the bottom line by identifying wrong payments, overpayments and fraudulent payments. It has been made generic enough, without changing the facts, that it applies to many organizations and yet not disclose the actual organization. The phrases highlighted in yellow on the Change Request Form below are relevant to the case study and will be used in use case diagrams and discussed as we go through the case study. The form is included because it clearly defines the issues and the history that led to the current predicament. The case study does embellish this real-life example.
The Change Request Form will open in a new window
so you can refer to it easily any time you want during the use case example case study.
Original View of TAP
This is the view that the original designers had of TAP using standard UML notation. The TAP system is denoted by the gray box with TAP in the upper left corner. The system contains use cases that describe its functionality. Note that the use cases come from the Change Request Form and may not be well formed. This will become clear as we go through the case study. Entities are added as we need them. The class box titled Kim::Person is underlined. This means that Kim represents a real, living, breathing person with a specific address and a specific social security number. The two stick men are the roles Field Auditor and Home Office Auditor. The {my office} is a constraint that limits a Field Auditor to viewing only lists belonging to that auditor’s local office. Each local office handles financial transactions for a defined geographic area. There are many local offices.
1st Change in Production
After this application was rolled out into production, it did not work right. The organization approved a new project to “enhance” functionality in the TAP system. Note: “enhance” here is a code word for “fix what we missed the last time”. A few months later, the next version of TAP was put into production. It looked like the following diagram as described in the Change Request Form:
Field Auditors who needed to work in multiple offices, including Kim, were made into Home Office Auditors. Now Kim could work in multiple offices – a plus. However, as a Home Office Auditor, Kim could view all lists because the path to the View List use case does not have the same constraint as the path from Field Auditor. Additionally, Kim can disqualify a transaction without replacement – potentially one that Kim knows was poorly handled or even fraudulent. This clearly is not good. With this “solution” TAP has taken one step forward and two steps backwards in production as noted by the blue plus and two red minuses.
2nd Change in Production
So the next attempt to get the right business functionality was undertaken. Months later another new enhancement was rolled out. As described on the Change Request Form it looked like:
Now Kim is an Audit Administrator! Kim can do the unspecified something and still work in multiple offices for two blue pluses. However, Kim can still view all lists and, as Audit Administrator, do anything in TAP. Being conservative, we’ll call the rollup use case Do Anything You Want as five red minuses. Now TAP has taken two steps forward and seven steps backwards in production. There is a trend to this TAP activity and its direction is not favorable. Needless to say, the affected end users and their managers are not happy. Imagine a financial regulator inspecting the TAP application in this condition. “Hmm, this financial auditing application has thirty-three Audit Administrators. That is a security concern. I wonder how big this fine will be.” Or worse! Please continue on to Part 2 of 3 in this use case example.
From Use Case Example Part 1 of 3 to Use Case Example Part 2 of 3
From Case Study Part 1 of 3 to Use Case Concepts 201
|
