IS 401 CH. 3 (Terms) Flashcards
use case
A use case is an activity the system performs, usually in response to a request by a user.
Two techniques are recommended for identifying use cases: the user goal technique and the event decomposition technique. An additional technique, known as the CRUD technique, is often used to validate
and enhance the list of use cases.
user goal technique
is to ask users to describe their goals for using the new or updated system. The analyst first identifies all the users and then conducts a structured interview with
each user. By focusing on one type of user at a time, the analyst can systematically address the problem of identifying use cases.
During the interview, the analyst guides the user to identify specific ways that a computer system can help the user perform his or her assigned tasks. The overarching objective is to identify how a system can improve the user’s performance and productivity.
The user goal technique for identifying use cases includes these steps:
- Identify all the potential users for the new system.
- Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales).
- Further classify potential users by organizational level (e.g., operational, management, executive).
- For each type of user, interview them to find a list of specific goals they will have when using the new system. Start with goals they currently have and then get them to imagine innovative functions they think would add value. Encourage them to state each goal in the imperative verb-noun form, such as Add customer, Update order, and Produce month end report.
- Create a list of preliminary use cases organized by type of user.
- Look for duplicates with similar use case names and resolve inconsistencies.
- Identify where different types of users need the same use cases.
- Review the completed list with each type of user and then with interested stakeholders.
event decomposition technique
The most comprehensive technique for identifying use cases is the event decomposition technique. The event decomposition technique begins by identifying all the business events that will cause the information system to
respond, and each event leads to a use case.
Starting with business events helps the analyst define each use case at the right level of detail. For example,
one analyst might identify a use case as typing in a customer name on a form. A second analyst might identify a use case as the entire process of adding a new customer. A third analyst might even define a use case as working with customers all day, which could include adding new customers, updating customer records, deleting customers, following up on late-paying customers, or contacting former customers. The first example is too narrow to be useful. The second example defines a complete user goal, which is the right level of
analysis for a use case. Working with customers all day—the third example—is too broad to be useful.
elementary business processes (EBPs)
The appropriate level of detail for identifying use cases is one that focuses on elementary business processes (EBPs). An EBP is a task that is performed by one person in one place in response to a business event, adds measurable business value, and leaves the system and its data in a stable and consistent state.
In Figure 3-1, the RMO CSMS customer goals that will become use cases are Search for item, Fill shopping cart, View product ratings and comments, and so forth. These use cases are good examples of elementary business processes. To fill a shopping cart is in response to the business event “Customer wants to shop.” There is one person filling the cart, and there is measurable value for the customer as items are added to the cart. When the customer stops adding items and moves to another task, the system remembers the current cart and is ready to
switch to the new task.
event
Note that each EBP (and thus each use case) occurs in response to a business event.
An event occurs at a specific time and place, can be described, and should be remembered by the system. Events drive or trigger all processing that a system does, so listing events and analyzing them makes sense when you need to define system requirements by identifying use cases.
external event
is an event that occurs outside the system—usually initiated by an external agent or actor. An external agent (or ACTOR) is a person or organizational unit that supplies or receives data from the system.
EX: external agents wants something resulting in a transaction, external agent wants some information, data changed and needs to be updated, management wants some information
temporal event
an event that occurs as a result of reaching a point in time. Many information systems produce outputs at defined intervals, such as payroll systems that produce a paycheck every two weeks (or each month) or reports that management wants to receive regularly, such as performance reports or exception reports. These events are different from external events in that the system should automatically produce the required output without being told to do so. In other words, no external agent or actor is making demands, but the system is supposed to generate information or other outputs when they are needed.
Temporal events do not have to occur on a fixed date. They can occur after a defined period of time has elapsed. For example, a bill might be given to a customer when a sale has occurred. If the bill has not been paid within 15 days, the system might send a late notice. The temporal event “Time to send late notice” might be defined as a point 15 days after the billing date.
Temporal events to look for:
Internal outputs needed
- management reports (summary or exceptions)
- operational reports (detailed transactions)
- internal statements and documents (including payroll)
External outputs needed
-statements, status reports, bills, reminders
state event
an event that occurs when something happens inside the system that triggers the need for processing. State events are also called internal events. For example, if the sale of a product results in an adjustment to an inventory record and the inventory in stock drops below a reorder point, it is necessary to reorder. The state event might be named “Reorder point reached.” Often, state events occur as a consequence of external events. Sometimes, they are similar to temporal events, except the point in time cannot be defined.
system controls
are checks or safety procedures put in place to protect the integrity of the system. These controls are important to the system, and they will certainly be added to the system during design. But spending time on these controls during analysis only adds details to the requirements model that users are not typically very
concerned about; they trust the system developers to take care of such details.
perfect technology assumption
The assumption that a system runs under perfect operating and technological conditions
States that events should be included during analysis only if the system would be required to respond under perfect conditions (i.e., with equipment never breaking down, capacity for processing and storage being unlimited, and people operating the system being completely honest and never making mistakes). By pretending that technology is perfect, analysts can eliminate events like “Time to back up the database” because they can assume that the disk will never crash. Again, during design, the project team adds these controls because technology is obviously not perfect.
Using the Event Decomposition Technique
To summarize, the event decomposition technique for identifying use cases includes these steps:
- Consider the external events in the system environment that require a response from the system by using the checklist.
- For each external event, identify and name the use case that the system requires.
- Consider the temporal events that require a response from the system by using the checklist
- For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case.
- Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases.
- For each state event, identify and name the use case that the system requires and then define the state change.
- When events and use cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in as system controls.
CRUD
Another important technique used to validate and refine use cases is the CRUD technique.“CRUD”is an acronym for Create, Read or Report, Update, and Delete
use case diagram
is the UML model used to graphically show the use cases and their relationship to users.
