We show several more examples, describe their basic elements, and show alternative formats.
Special Topics – Use Cases:
First, create a template for use cases – you may use the one in the textbook as an example. You may also choose to look at additional examples online. The textbook use cases are below
Once you’ve created your template, complete a use case for TWO of the steps in the process for buying glasses from the viewpoint of the patient (each tab below represents a potential use case for this scenario). Include the steps taken within each use case. Do not choose two steps in a row.
The first step is to see an eye doctor
who will give you a prescriiption.
Once you have a prescriiption, you go to a glasses store, where you select your frames
and place the order for your glasses.
Once the glasses have been made, you return to the store for a fitting
and pay for the glasses.
Create ONE WORD DOC with a separate page for each of the TWO use cases.
Use Case Analysis
Use cases are used to explain and document the interaction that is required between the user and the system to accomplish the user’s task. Use cases are created to help the development team understand more fully the steps that are involved in accomplishing the user’s goals. Once created, use cases often can be used to derive more detailed functional requirements for the new system.
Explain the purpose of use cases in the analysis phase of the SDLC.
Describe the various parts of a use case and the purpose of each part.
Describe how use cases contribute to the functional requirements.
Describe how use cases inform the development of test plans.
Explain the process used to create a use case.
Chapter 3 discussed the overall process of the analysis phase of the SDLC, resulting in the system proposal deliverable. Within the system proposal is the requirements definition, defining exactly what the new system should do. As we previously discussed, a key aspect of determining the requirements for the new system is understanding the user requirements: the things the users need to accomplish with the new system. In this chapter, we discuss use cases as a means of expressing user requirements. Since one of our goals in the systems development project is to create usable software, it is imperative to know what the users must do with it. Use cases help us understand and clarify the users’ required interactions with the system and can help us more fully understand the functional requirements of the new system. Consequently, use cases are used extensively in the analysis phase when working with the users in interviews and workshop settings as a means of discovering user and functional requirements.
A use case represents how a system interacts with its environment by illustrating the activities that are performed by the users of the system and the system’s responses. The goal is to create a set of use cases that describe all the tasks that users need to perform using the system. Use cases are often thought of as an external or functional view of a business process, showing how the users view the process rather than the internal mechanisms by which the process operates. Since use cases describe the system’s activities from the user’s perspective in words, it is essential to involve users in their development. Therefore, creating use cases helps ensure that users’ insights are explicitly incorporated into the new system.
For many years, traditional requirements elicitation techniques involved asking the users what they wanted the system to do. The systems analysts would sit down with users and try to express what the system should do by drawing process models and data models. This was difficult for the users for several reasons. First, the users may not know what is and is not possible for the system to do. Users are not likely to truly understand the capabilities and limitations of information systems technologies, especially new advances in technology. Second, users may have difficulty envisioning new ways to redesign business processes. Most of us find creating new ways of doing things to be a challenge because we are so accustomed to things being done the “old way.” Third, it is common for users to describe things they think they want from the new system, but our focus should be on the real needs for the new system. Finally, users often found it difficult to comprehend the process and data modeling graphical notations used by the analysts.
At one time, organizations applying traditional system development techniques used what were called business scenarios to describe user interactions with the system, while organizations applying object‐oriented techniques (see Chapter 14) used what were called use cases. At present, these distinctions have largely disappeared and the term use case is widely accepted.1 Regardless of the development approach (waterfall, RAD, or agile), we need to know and understand what the user needs to accomplish with the system.
Once the team has created a set of use cases that describe the things the users need to accomplish with the new system, there will be a number of important contributions to the analysis phase. First, the use cases will help the analysts develop a more detailed understanding of the new system’s functional requirements. System developers commonly find that a well‐constructed set of use cases includes most of the functional requirements. Second, use cases are very helpful in understanding exceptions, special cases, and error handling requirements in the new system. These requirements are easy to overlook, but creating use cases helps to discover them. Finally, the text‐based use case is easy for the users to understand and flows easily into the creation of process models (Chapter 5) and the data model (Chapter 6), which are used by the analysts to more fully define the software that will be developed in the new system.
Use cases are especially valuable for business system applications and websites. Both of these types of systems commonly involve extensive user interactions, so the use case is particularly helpful. Use cases are not as useful in certain other settings, such as batch processes, computationally intensive applications, or data warehousing. These settings have extensive “internal” complexity but limited user interactions. Therefore, the use case is not necessarily the best tool to use in these applications. As always, the analyst needs to be skilled in using a number of tools and must be able to select and apply the appropriate ones for the situation.
In this chapter, we first explain the use case through a simple illustration. We show several more examples, describe their basic elements, and show alternative formats. We then illustrate the process of creating use cases with another example, and conclude the chapter by applying the concepts to the DrōnTeq running case.
What Is a Use Case?
A use case depicts a set of activities performed to produce some output result. Each use case describes how an event triggers actions performed by the system and the user. With this type of event‐driven modeling, everything in the system can be thought of as a response to some trigger event. When there are no events, the system is at rest, patiently waiting for the next event to trigger it. When a trigger event occurs, the system (and the people using it) responds, performs the actions defined in the use case, and then returns to the waiting state.
The Use Case Concept in a Nutshell
The easiest way to appreciate the role of a use case is to follow along with this brief example. Imagine you have accompanied a friend to your local post office to purchase postage stamps. When you arrive at the post office, the service window is closed, but there is an automated postage vending kiosk to use. While your friend makes the purchase, you put your observation skills to work (Chapter 3). Your notes on your observation of the user/system interaction are as follows:
System: Displays Welcome message and flashes “Start” button
User: Presses “Start” button
System: Displays list of options (buy stamps, mail package, etc.)
User: Presses “Buy Stamps” button
System: Displays list of stamp buying options (type, denomination, quantity)
User: Selects desired stamps by pressing button next to choice
System: Displays dollar amount of purchase and asks for purchase confirmation
User: Presses “Yes” button to confirm purchase
System: Asks user to swipe card and flashes light next to card reader
User: Swipes debit card in card reader
System: Displays keypad for PIN entry and requests PIN
User: Types in PIN on keypad
System: Confirms payment transaction and asks if user wants a printed receipt
User: Presses “Yes” button to request receipt