IS 401 Use Case Flashcards
use case
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.
One approach to identifying use cases, called the 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.
potential users of the CSMS.
The user goal technique for identifying use cases includes these steps:
Satzinger, John W.; Jackson, Robert B.; Burd, Stephen D. (2011-11-16). Systems Analysis and Design in a Changing World (Page 69). Cengage Textbook. Kindle Edition.
- 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.
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.
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.
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.
An 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. To identify the key external events, the analyst first tries to identify all the external agents that might want something from the system.
A second type of event is a 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). Sometimes, the outputs are 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.
A third type of event is a 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.
External events include
external agent wants something resulting in a transaction, external agent wants some info, data changed and needs to be updated, management wants info
State events include
Internal outputs needed: management reports, operational reports, internal statements and documents
external outputs needed: statements, status reports, bills, reminders
system controls
which are checks or safety
procedures put in place to protect the integrity of the system.
The perfect technology
assumption 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).
CRUD technique.
“CRUD”is an acronym for Create, Read or Report, Update, and Delete, and it is often introduced with respect to database management.
The CRUD technique for validating and refining use cases includes these steps:
- Identify all the data entities or domain classes involved in the new system.
- For each type of data (data entity or domain class), verify that a use case has been identified that creates a new instance, updates existing instances, reads or reports values of instances, and deletes (archives) an instance.
- If a needed use case has been overlooked, add a new use case and then identify the stakeholders.
- With integrated applications, make sure it is clear which application is responsible for adding and maintaining the data and which system merely uses the data.
