Use Case Analysis PDF

Introduction 121 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...

Introduction 121 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 organ- izations 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 understand- ing 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 require- ments 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 web sites. Both of these types of systems commonly involve extensive user interactions, so the use case is particu- larly 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. 1 As you will see in Chapter 14, object-oriented techniques take the text-based use cases we describe in this chapter and create use case diagrams before moving to modeling structure and behavior (similar to the data and process models we describe in the next chapters). Use case diagrams are described in Chapter 14. We focus only on the text descriptions of the use cases in this chapter. For a more detailed description of business scenarios, see Karen McGraw and Karen Harbison, User-Centered Requirements: The Scenario-Based Engineering Process, Mahwah, NJ: Lawrence Erlbaum Asso- ciates, 1997. For a more detailed description of use cases, see I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Reading, MA: Addison-Wesley, 1992. 122 C ha pte r 4 Use Case Analysis 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 Tune Source 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 System: Prints receipt and asks user to take receipt User: Takes receipt System: Displays message to wait while it prints the purchased stamps User: Takes stamps when printing is done System: Displays Thank You Message for 30 seconds, then displays Welcome message As you can see from this user–system dialog, the postage purchase transaction is accom- plished through a coordinated series of prompts, user entries, and system actions. The user– system dialog tells a lot about what the user does to complete the desired task while working with the system, and that is its primary purpose. We use the description of user and system actions and responses to more fully understand the user’s perspective on the system. Any user who reads through this brief dialog should be able to fully grasp how he/she will accomplish the purchase of stamps with the kiosk.  Use Case Formats and Elements 123 Now let us change the situation slightly. Assume the vending kiosk has not been devel- oped. As the analysts are defining what this kiosk should do, a functional requirement stat- ing “The kiosk system will enable a user to purchase postage stamps” was included in the requirements definition. This statement clearly specifies a task that users want to perform with the help of the system, but provides few details about that task and how the system should support the user’s task performance. If a systems analyst works with a user and together create the user–system dialog shown above, we get a much clearer understanding of how the system can support the user in accomplishing this task. In essence, we have cre- ated a use case. Although we do not know much at all about what is going on “behind the scenes” of the system, we can now create a much more complete description of functional requirements: The kiosk system will: enable the user to begin a transaction display a list of purchase transaction options that are available on the kiosk enable the user to specify the type of purchase transaction desired display a list of options for the purchase type enable the user to specify the desired type of postage and quantity desired display the amount due for the purchase enable the user to confirm the purchase enable the user to pay for the purchase with credit/debit card complete the credit/debit card transaction securely print receipt if requested by user print stamps purchased This list shows that we are well on the way to clarifying the functional requirements for this system. This brief example displays the role of the use case in a nutshell—to define the expected interaction between user and system and use that interaction to clarify and more fully describe the system’s functional requirements. USE CASE FORMATS AND ELEMENTS Use cases can vary considerably from one organization to another in terms of the content included, the format followed, and the degree of formality employed. In this section, we show two alternative use case formats that vary in terms of formality and detail. Casual Use Case Format We begin with an example use case that is fairly casual. This use case is based on the scenario of a lawn care company that employs specially trained workers to apply lawn chemicals (fer- tilizers and pesticides) to customers’ lawns. The company maintains a chemical supply ware- house where the employees obtain the needed chemicals for their lawn care assignments. The process of obtaining lawn chemicals involves three main steps: authenticating the employee and ensuring he has the required training and credentials (a legal requirement for those who work with potentially dangerous materials such as pesticides); submitting a request for the needed chemical; and picking up the chemical from the chemical supply warehouse. The example use case focuses on the second step of this overall process: requesting a chemical. Refer to Figure 4-1 as we describe the sections of the use case. There are numerous pieces of information in the use case, each with an important role to play in describing the response to the triggering event. We will describe each section starting at the top. 124 C ha pte r 4 Use Case Analysis Use Case Name: Request a chemical ID: UC-2 Priority: High Actor: Lawn Chemical Applicator (LCA) Description: The Lawn Chemical Applicator (LCA) specifies the lawn chemical needed for a job by entering its name or ID number. The system satisfies the request by reserving the quantity requested or the quantity available and notifying the Chemical Supply Warehouse of the pick-up. Trigger: A Lawn Chemical Applicator (LCA) needs a chemical for a job. Type: ✓ External Temporal Preconditions: 1. The LCA identity is authenticated. 2. The LCA has necessary training and credentials on file. 3. The Chemical Supply datastore is up-to-date and on-line. Normal Course: 1.0 Request a lawn chemical from the chemical supply warehouse. 1. The LCA specifies a chemical needed and the quantity needed 2. The system lists chemical and quantity on hand from Chemical Supply datastore a. If the quantity on hand is less than the quantity needed, the LCA specifies the quantity he will take b. Purchasing is notified of chemical shortage 3. The system gives the LCA a Chemical Pick-up Authorization for the quantity requested 4. The system notifies the Chemical Supply Warehouse of the chemical pick-up 5. The system stores the Lawn Chemical Request in the Chemical Request datastore Postconditions: 1. The Lawn Chemical Request is stored in the Chemical Management System. 2. The Chemical Pick-up Authorization is produced for the LCA. 3. The Chemical Supply Warehouse is notified of the chemical pick-up. 4. Purchasing is notified of chemical outage. Exceptions: E1: Chemical is no longer approved for use (occurs at step 1) 1. The system displays message “That chemical is no longer approved for use” 2. The system asks the LCA if he wants to request another chemical or to exit 3a. The LCA asks to request another chemical 4a. The system starts Normal Course again 3b. The LCA asks to exit 4b. The system terminates the use case FIGURE 4-1 Request a Chemical Use Case—Casual Format A template for this figure is available on the student web site Basic Information Each use case has a name and number. The name should be as simple, yet descriptive, as possible. The number is simply a sequential number that serves to reference each use case (e.g., UC-2). The description briefly conveys the use case’s purpose. The priority may be assigned to indicate the relative significance of the use case in the overall system. Some use cases will describe essential activities that the system must perform and hence will have a high priority level. Other use cases may describe activities that are less critical, having medium or low priority. Classifying the priority level is especially useful with a methodology that implements the system in a series of versions so that the most essential system features can be targeted first.  Use Case Formats and Elements 125 The actor refers a person, another software system, or a hardware device that interacts with the system to achieve a useful goal. Some organizations use the term user role rather than actor because there may be several different user groups who interact with the system in the same way. For example, an order entry use case could be performed with either customers or order entry clerks performing the user role. In our example, the actor is the lawn chemical applicator (LCA) who is employed by the lawn care company to apply the lawn chemicals to customers’ lawns. Another element of basic information is the trigger for the use case—the event that causes the use case to begin. A trigger can be an external trigger, such as a customer placing an order, the fire alarm ringing, or in our example, the LCA needing a chemical for a job. A trigger can also be a temporal trigger, where the event is time-based, such as a DVD becoming overdue at the video store or it’s time to pay the weekly payroll. Preconditions Use cases are often performed in a sequence in order to accomplish an overall business task. When this practice is followed, it is important to define clearly what needs to be accomplished before each use case begins. These preconditions define the state the system must be in before the use case commences. In our example, you can see that in order for an LCA to request a chemical, he must be authenticated, his training and credentials must be up to date, and the datastore (a generic data repository) containing Chemical Supply information must be available and up to date. These tasks are taken care of in a different use case prior to the performance of this use case. Once these preconditions are established, the LCA can perform the Request a chemical use case. Normal Course The next major part of a use case is the description of the major steps that are performed to execute the response to the event, the inputs used for the steps, and the outputs produced by the steps. The normal course lists the steps that are performed when everything flows smoothly in the system. This is sometimes called the “happy path” because there are no problems or issues that arise when the steps are able to be followed normally. As you read through the steps, you can clearly understand the interactions that occur between the user and the system. The steps are listed in the order in which they are performed and you can see the “bird’s-eye” perspective illustrated in the steps, describing what an out- sider could observe while watching the user and system interact. Notice step 2, where a branching logical condition occurs. In this case, if the quantity of chemical on hand is not sufficient to fill the request, the LCA is given the option of taking the quantity of chemical that is available. If that choice is made, an alternative course is followed. Postconditions In this section of the use case, we define the final products of this use case. In our example, the Lawn Chemical Request is stored, the LCA has the Chemical Pick-up Authorization, the Chemical Supply Warehouse is notified of the pick-up, and Purchasing is notified of any chemical outage. These postconditions also serve to define the preconditions for the next use case in the series. In our example, that would be the use case that describes the chemical pick-up at the Chemical Supply Warehouse. Exceptions In order to be complete, a use case should describe any error conditions or excep- tions that may occur as the use case steps are performed. These are not normal branches in decision logic, but are unusual occurrences or errors that could potentially be encountered and will lead to an unsuccessful result. As the use case is written and reviewed, the analyst should ask the user if there are any special situations or errors that could occur with each step. If there are, they should be explained as an exception. We want to be sure that the system does not fail while in use because of an error that no one thought about. As you probably know, in many systems, handling exceptions can require more coding effort than the normal and alternative 126 C ha pte r 4 Use Case Analysis courses. It is essential to try to identify these trouble spots during the analysis phase so we do not encounter unexpected error conditions and crashes during testing and implementation. In our example, at step 1 in the normal course, it is possible that a chemical requested by the LCA is no longer available for use. This happens when a chemical is deemed too harmful in some way and is legally restricted. The E1 exception outlines the steps followed to give the LCA a chance to request a different chemical (steps 3a and 4a) or exit (steps 3b and 4b). Use Cases in Sequence While it might be possible to describe everything in one very large use case, that use case could become unwieldy. Therefore, it is common practice to create smaller, more focused use cases breaking the whole process down into parts. Consequently, it is important to know exactly what state the system should be in before the use case can begin and exactly what state the system should be in when the use case is complete. That is the purpose of the precondition and postcondition sections of the use case. In our example scenario, the use case depicted in Figure 4-1 was a part of the larger user goal of obtaining a chemical from the Chemical Supply Warehouse. We chose to divide that major task into three use cases that are performed in a series so that each use case is less complex and does not become confusingly large. When we take this approach, the preconditions and postconditions are essential, since the state at the conclusion of Use Case 1 (its postconditions) are also the preconditions for Use Case 2 (our example use case), and the postconditions for Use Case 2 are the preconditions for Use Case 3. As Figure 4-2 shows, postconditions of a use case define the required system state (preconditions) for the subsequent use case, essentially establishing the boundaries of each use case. We often separate the overall user task into individual use cases to take advantage of the potential reusability of a use case. In our example, the need to authenticate and validate cre- dentials probably occurs in several places throughout the system. We do not need to develop new use cases each time this task is needed; we can simply reuse the one use case we have already created. In situations like this, it is a good idea to add a notation on the use case describing the multiple places in the system that will utilize this use case. Fully Dressed Use Case Format The use case in Figure 4-3 represents a fully dressed use case.2 This means that the use case is very thorough, detailed, and highly structured. As you can see, there are several additional sections in this use case format. For example, you can see that a column is included showing the information that flows in or out of the steps. By recording the information for the steps, the inputs and outputs to the steps are clarified. We believe this helps to more fully explain the user–system interactions outlined in the steps. Obtain a chemical Postconditions Postconditions Postconditions Preconditions Preconditions Preconditions Authenticate and Request a chemical Pick up chemical validate credentials FIGURE 4-2 Chain of Use Cases with Boundaries 2 Alistair Cockburn, Writing Effective Use Cases (Boston, MA: Addison-Wesley, 2001).  Use Case Formats and Elements 127 Use Case Name: Request a chemical ID: UC-2 Priority: High Actor: Lawn Chemical Applicator (LCA) Description: The Lawn Chemical Applicator (LCA) specifies the lawn chemical needed for a job by entering its name or ID number. The system satisfies the request by reserving the quantity requested or the quantity available and notifying the Chemical Supply Warehouse of the pick-up. Trigger: A Lawn Chemical Applicator (LCA) needs a chemical for a job. Type: ✓ External Temporal Preconditions: 1. The LCA identity is authenticated. 2. The LCA has necessary training and credentials on file. 3. The Chemical Supply datastore is up-to-date and on-line. Normal Course: Information for Steps: 1.0 Request a lawn chemical from the chemical supply warehouse. 1. The LCA specifies the desired lawn chemical Chemical name or ID 2. The system verifies the chemical is approved for usage List of approved chemicals 3. The system displays the quantity of the lawn chemical on hand Quantity on hand 4. The LCA specifies the quantity needed Quantity needed 5. The system asks the LCA to confirm the request for the quantity needed or the quantity available (Alternative Course 1.1) Request confirmation 6. The system gives the LCA a Chemical Pick-up Authorization for the quantity requested Chemical Pick-up Authorization 7. The system notifies the Chemical Supply Warehouse of the chemical pick-up Chemical Pick-up Notice 8. The system stores the Lawn Chemical Request in the Chemical Request datastore Lawn Chemical Request Alternative Courses: 1.1 Quantity available is less than quantity needed (branch at step 5) 1. The system asks the LCA if he wants the quantity available or to cancel the request 2a. The LCA asks to take the quantity available Request quantity available 3a. The system changes the quantity requested to the quantity available 4a. The system gives the LCA a Chemical Pick-up-Authorization for the quantity available Chemical Pick-up Authorization 5a. The system notifies the Chemical Supply Warehouse of the chemical pick-up Chemical Pick-up Notice 6a. The system stores the Lawn Chemical Request in the Chemical Management System Lawn Chemical Request 7a. The system notifies Purchasing of the chemical outage Chemical Outage Notice 2b. The LCA asks to cancel the request Cancellation 3b. The system terminates the use case Postconditions: 1. The Lawn Chemical Request is stored in the Chemical Management System. 2. The Chemical Pick-up Authorization is produced for the LCA. 3. The Chemical Supply Warehouse is notified of the chemical pick-up. 4. Purchasing is notified of chemical outage. Exceptions: E1: Chemical is no longer approved for use (occurs at step 2) 1. The system displays message “That chemical is no longer approved for use” 2. The system asks the LCA if he wants to request another chemical or to exit 3a. The LCA asks to request another chemical 4a. The system starts Normal Course again 3b. The LCA asks to exit 4b. The system terminates the use case Summary Inputs Source Outputs Destination Chemical name or ID LCA Chemical Pick-up LCA List of approved chemicals Lawn Chemicals Supply datastore Authorization Chemical quantity on hand Lawn Chemicals Supply datastore Chemical Pick-up Notice Chemical Supply Quantity needed LCA Warehouse Request confirmation LCA Lawn Chemical Request Chemical Request Request quantity LCA datastore available or Chemical Outage Notice Purchasing cancellation FIGURE 4-3 Request a Chemical Use Case—Fully Dressed Format 128 C ha pte r 4 Use Case Analysis Another difference is shown in step 5, where the step defines two possible actions with an “or” clause. This is an example of a conditional step involving a branch in the logical flow. In this case, if the quantity of chemical on hand is not sufficient to fill the request, the LCA is given the option of taking the quantity of chemical that is available. If that choice is made, an alternative course is followed, which is described in the next section of the use case. Any con- ditional steps are clearly noted in this fashion and alternative courses are fully described. Alternative Courses In this section, the steps followed for alternative paths through the use case are outlined. Alternative courses are included to depict branches in logic that also will lead to a successful conclusion of the use case. Notice that the location where the branch in logic from the normal course occurred is clearly stated. The course described in our example also depicts two potential paths through these steps. If the user decides to accept the quantity of chemical available, steps 2a–7a will be performed; however, if the user decides to cancel the request, steps 2b and 3b will be performed. Summary Inputs and Outputs The final section of the use case summarizes the set of major inputs and outputs to the steps of the use case. Each of the major inputs and outputs to the use case are listed, along with its source or destination. These are all possible inputs and outputs, not just those that are part of the normal course. In this area, it is easy to see the inputs sup- plied by the LCA and the Chemical Supply datastore as the use case is performed, and the outputs produced and where the outputs go. Additional Use Case Issues Some organizations may choose to include additional sections on their use case forms. If appropriate, it may be helpful to include sections devoted to: Frequency of use Business rules Special requirements Assumptions Notes and issues These sections enable more detail to be listed about the use case as it is learned. The fully dressed use case is not always necessary, but does provide value in certain cir- cumstances. Fully dressed use cases are especially valuable when: User representatives are not closely engaged with the development team throughout the project. The application is complex and has a high risk associated with system failures. Comprehensive test cases will be based on the user requirements. Collaborating remote teams need a detailed, shared understanding of the user requirements.3 APPLYING USE CASES The use cases shown here are essential use cases, written to depict the user–system interactions as abstract, technology-independent steps. For example, in the first step of the Normal Course, “the LCA specifies the desired lawn chemical” nothing is said about the specific way this is done. This phrasing keeps our options open in terms of how this task will actually be imple- mented. In the analysis phase, this is the correct perspective to take, since we do not want our users to limit their thinking to just one way for the system to work too early in the process. 3 Karl E. Weigers, Software Requirements, 2nd ed. (Redmond, WA: Microsoft Press, 2003).  Applying Use Cases 129 Use Case Practical Tips As you might imagine after studying Figure 4-3, it takes considerable practice to write fully dressed use cases well. You should not realistically expect to create a perfect use case on the first try. The process of building use cases is one of gradual refinement: As users and analysts work through the parts of the use case, they often return to previous parts to correct them. As you gain experience, the creation of use cases will become more intuitive. Being detailed and thorough will get you a long way toward a use case that contributes a significant understand- ing of the system that we are developing. The project team may decide that the more casual use case format shown in Figure 4-1 is acceptable. As you saw, this format is less detailed than Figure 4-3. The essence of the user– system interaction is described, but with much less precision. It is important not to get too caught up in figuring out the “right” level of detail. Your focus should be on describing the user’s objectives in working with the system completely and accurately so that we will not have to rework the system later as it is being developed. Also, keep in mind that use cases are read and used by two very different groups of people, the users/business experts and the system development experts. It is hard to find a middle ground writing style that will provide the precision needed by the development experts with- out overwhelming the users/business experts. Many organizations have found that use case writing teams are helpful. On the team, there should be at least one person who has a program- ming perspective in order to ensure adequate precision and accuracy in the use case; another person who has deep knowledge of the business rules that the system must enforce; and another person who is thoroughly familiar with how the system will actually be used. We create use cases when they are likely to help us better understand the situation and help convey the required user–system interactions. For very simple processes that are well explained in the requirements definition, it is not necessary to create a use case. The informa- tion in the requirements definition itself is sufficient to describe what the system should do. It is important, however, to create use cases whenever we are reengineering processes or making any changes to business processes that will significantly alter the way people work. Remember that the use case describes what the system will do from the user’s perspective. Therefore, it is critical to involve the user in the creation of the use case so that the user understands the interactions planned for the new system. Also, the user helps to ensure that no essential steps or tasks are omitted from the use case and that rare, special circumstances are included. Use Cases and Functional Requirements As we stated earlier in the chapter, use cases are very helpful tools to use to understand user requirements. It is tempting for novice analysts, however, to incorrectly assume that the use case is all that is needed to fully define what the system must do. Use cases do explain the user’s interaction with the system, but they omit a lot of details that are necessary to know before the system can be developed. Use cases only convey the user’s point of view. Behind the scenes processing details are probably not included in the use case. Transforming the user’s view into the developer’s view by creating functional requirements is one of the impor- tant contributions that the systems analyst makes to the development project. Figure 4-4 lists functional requirements based on the Normal Course in the Request a chemical use case. As you can see, these requirements give more information to the developer about what the sys- tem must do to allow the user to accomplish his goals. Use Cases and Testing Many organizations develop test plans early in the development process. This strategy has a num- ber of advantages, including giving the testing/quality assurance personnel an early understand- ing of the system under development. By studying the use cases and the functional requirements 130 C ha pte r 4 Use Case Analysis The system shall allow the LCA who is logged in to the Chemical Request system to request one or more chemicals. The system shall allow the LCA to specify a chemical by entering its ID number or name. The system shall notify the LCA if the chemical is no longer approved for use. The system will prompt the LCA for the quantity of the chemical needed. The system shall search the Chemical Supply datastore for the quantity available of the requested chemical and display the quantity available. The system shall prompt the user to confirm his request. When the request is confirmed, the system shall do the following as a single transaction: o Assign the next Chemical Request number to the Chemical Request, assign the current date and time to the Chemical Request, record the LCA’s name and ID number on the request. o Update the amount available of the chemical by subtracting the quantity requested from the quantity available in the Chemical Supply datastore. FIGURE 4-4 o Print the Chemical Pick-up Authorization Notice for the LCA. Chemical Request o Send a message to the Chemical Supply Warehouse of the approved Chemical Pick-up. o Record the approved Chemical Request in the Chemical Request datastore, marked as “Pending (Normal Course) Pick-up.” Functional The system shall prompt the LCA to exit the system or to make another chemical request. Requirements derived from them, the testing personnel can readily identify elements of the tests they will want to perform when the system enters testing. When the time comes to actually perform the tests, the testing personnel are well prepared and not forced to develop and perform the tests in a rush. In addition, the quality assurance personnel often are able to make helpful suggestions about the system and it is valuable to gain this feedback early in the development process. CREATING USE CASES The most common ways to gather information for the use cases are through the same requirement determination techniques discussed in the previous chapter, especially inter- views and JAD sessions. Observation also is sometimes used for as-is use cases. Regardless of whether interviews or JAD sessions are used, research shows that some ways to gather the information for use cases are better than others. The most effective process has four steps4 (Figure 4-5). These four steps are performed in order, but, of course, the analyst often cycles among them in an iterative fashion as he or she moves from use case to use case. Identify the Major Use Cases As stated previously, use cases document one or more func- tional requirements outlined in the requirements definition. Therefore, identification of use cases begins with the requirements definition. The process-oriented functional requirements— things the system must do—suggest a direct action resulting from an external or temporal event. The information-oriented functional requirements—content the system must have— suggest things that happen involving information or time triggers to collect or produce infor- mation. Let us begin an example of creating use cases by revisiting the Holiday Travel Vehicles scenario. We have already seen a requirements definition for this situation (Figure 3-3). How was this information obtained? Figure 4-6 contains a transcript of an initial interview between Hal, the owner of Holiday Travel Vehicles, and Sarah, a systems analyst who is working on a project to provide an improved information system for the dealership. This interview took place early in the project when Sarah was just getting familiar with the organization, and basi- cally focuses on the as-is system. Take a moment and read the transcript now. 4 The approach in this section is based on the work of George Marakas and Joyce Elam, “Semantic Structuring in Ana- lyst Acquisition and Representation of Facts in Requirements Analysis,” Information Systems Research, 1998, 9(1), 37–63, as well as our own: Alan Dennis, Glenda Hayes, and Robert Daniels, “Business Process Modeling with Group Support Systems,” Journal of Management Information Systems, 1999, 15(4), 115–142.  Creating Use Cases 131 Step Activities Typical Questions Askeda 1. Identify the use cases. Start a use case report form for each use case Ask who, what, when, and where about the use by filling in the name, description and trigger. cases (or tasks). If there are more than nine use cases, What are the major tasks that are performed? group them into packages. What triggers this task? What tells you to perform this task? 2. Identify the major steps For each use case, fill in the major steps needed Ask how about each use case. within each use case. to complete the task. What information/forms/reports do you need to perform this task? Who gives you these information/forms/reports? What information/forms/report does this produce and where do they go? How do you produce this report? How do you change the information on the report? How do you process forms? What tools do you use to do this step (e.g., paper, e-mail, phone)? 3. Identify elements For each step, identify its triggers and its inputs Ask how about each step. within steps. and outputs. How does the person know when to perform this step? What forms/reports/data does this step produce? What forms/reports/data does this step need? What happens when this form/report/data is not available? 4. Confirm the use case. For each use case, validate that it is correct Ask the user to execute the process, using the written and complete. steps in the use case—that is, have the user role-play the use case. aWe have used the typical questions for the as-is model (e.g., “What are the…”). These same questions can be used for the to-be model, but they would be phrased in the future tense (e.g., “What should be the…”). FIGURE 4-5 Steps for Writing for Use Cases Interview transcript: Sarah (systems analyst) and Hal (owner, Holiday Travel Vehicles) Sarah: Hal, the purpose of our discussion today is for you to give me an overview of your business. As you know, I head up a team that will be helping to develop plans for new information systems for your business. Initially, I am interested in learning about the major activities that are performed here as you go about your daily business. Later, I’ll be asking more detailed questions about these activities. Hal: Sounds good to me, Sarah. I know the recreational vehicle business pretty well, having taken over this business from my uncle over 15 years ago. Let’s see... well, things begin with our placing orders for new recreational vehicles and travel trailers with our five main suppliers. We try to keep a good balance of sizes, prices, and styles of RVs and trailers on hand. We keep our inventory fairly low during the winter, of course. Our peak selling seasons are spring and fall. After we place our orders, our suppliers send us the vehicles we’ve requested. When a vehicle that we’ve ordered arrives, we check it into our records by recording its VIN number, model, name, year, manufacturer, date of arrival, and invoice cost. We have a new vehicle form that we fill out with all of this information, and we keep these forms in a file cabinet in our main office. Of course, the main activity of this business is selling those vehicles. We have a staff of knowledgeable salespeople who are here to determine our customers’ needs and wants and find a vehicle or trailer that will fill the bill. Sarah: Do you record any information about a customer while he’s looking at vehicles? FIGURE 4-6 Hal: No, nothing gets written down until the customer has decided on the vehicle he wants to buy. Then the salesperson and the customer fill out the offer form. This is pretty informal, but it does Holiday Travel Vehicles include the customer’s name, the vehicle he wants to buy, the offer he is making, and a value Interview Transcript for the trade-in vehicle if there is one. (continued) 132 C ha pte r 4 Use Case Analysis Sarah: Who provides the trade-in value? Hal: The salesperson goes to our used vehicle manager for that. Sarah: Okay. Then what is done with the offer form? Hal: Basically, the form contains all the details that I need to decide whether to accept the offer or not. The salesman brings the offer form in to me, and then I’ll look up the new vehicle form if necessary to remind me of the vehicle’s base cost. If therea trade-in listed, then I’ll check our Green Book that gives value estimates for older RVs and trailers to see if the trade-in value listed is reasonable. If I agree to all the terms, then I’ll sign the offer form and give it back to the salesperson. If I don’t agree to everything, then I tell the salesperson what I want changed, and he goes back to the customer to continue the negotiation. Sarah: So then, does the salesperson make out a new offer form or does he just change the original one? Hal: He usually writes out a new one if the customer agrees to modify his offer. It’s less confusing that way. Sarah: What happens to the original offer form? Hal: It just gets torn up and thrown away. We don’t want it floating around and someone accidentally finds out the details of a customer’s offer. Sarah: What if the customer doesn’t want to change his offer? Does the form just get thrown away then, too? Hal: No, in that case the salesperson usually keeps the offer form in his own customer file. That way, he has a record of the customer’s offer and he can use that down the road when he follows up with the customer and tries to persuade him to submit another offer. Sarah: So, let’s say the customer finally gets his offer accepted. Then what happens? Hal: Well, things get a lot more formal now. Once the offer is accepted, the salesperson fills out a sales contract. This sales contract form contains full customer information, a complete description of the purchase vehicle, complete details of the trade-in vehicle and trade-in allowance, and a full description of any dealer-installed options. Then we list... Sarah: (interrupting): Sorry, Hal, but that’s the first time I’ve heard you mention dealer-installed options. Tell me about them. Hal: Oh, right, I kind of skipped that, didn’t I? Well, we sell base-model vehicles only. If customers want them fancied-up with extras and options, we can add them, for a price, of course! Any options that the customer wants should have been listed on the offer forms I mentioned earlier. Sarah: Okay. So let’s go back to when I interrupted. The sales contract is filled out with customer information, purchased vehicle information, trade-in information, dealer-installed options... anything else? Hal: Just the final negotiated price, taxes, and license fees, and the amount of the required customer deposit. Once we’ve received the deposit check, we settle on a delivery date that gives us the time we need to install the options, and then all parties sign the purchase contract, and we have ourselves a deal. Oh, and we make sure we list the salesperson’s name so he can get his commission on the sale later. Sarah: What happens then? Hal: Well, the customer typically goes off to arrange financing for the balance due on the purchase. We don’t provide financing ourselves in-house. If the customer needs help with that, we have a couple of local banks we direct him to that are interested in that kind of business. We pull the new vehicle form out of our files and staple it to a new form we call the vehicle purchase record. The vehicle purchase record is kind of a summary of the main points of the purchase: the customer info, the vehicle info, the options added, and the final price info. These forms go into our files, ordered by customer, so we have a record of every customer’s vehicle purchase. At this point, we also write up a work order for the shop that lists all the work that needs to be done to get the vehicle ready for delivery to the customer. FIGURE 4-6 Sarah: So, when it’s time for a customer to take delivery on the vehicle, what happens? (continued)  Creating Use Cases 133 Hal: The customer comes in with the money needed to finalize the sale and the trade-in vehicle, if there is one. We go through the new vehicle with him and make sure it is satisfactory. We then collect his money, get a final signature from him, and give him a copy of the sales contract form. He gets the keys and is on his way! We then staple the last copy of the sales contract with the vehicle purchase record, and it gets filed by customer name. Sarah: What about the trade-in vehicle? Hal: We fill out a form called the used vehicle form that describes the vehicle and the trade-in value. This is kind of like the new vehicle form we fill out when our new vehicles arrive in inventory. This gives the information we need on the trade-in so we know how we should price it. If it needs any work, we prepare a shop work order, the work gets done, and the vehicle is put on the lot. Sarah: Is there anything else you can think of that’s written down or recorded in these processes you’ve described? Hal: Once the customer takes final delivery, we use a sales ledger to record the actual sale and the tax and license fees we’ve collected. Our bookkeeper needs that. Sarah, it looks like they need me on the sales floor. Can we talk again later? Sarah: Sure, Hal. Let me absorb everything you’ve told me today and I’ll get back in touch. This has FIGURE 4-6 been a great start. Thanks! (continued) As you read the interview transcript, look for things that happen that cause the dealership and its people to have to perform some tasks. These will be the major events of the system. Once you have identified an event, try to discover what the major response to the event is and how it is produced. Chances are, the details will be obscure at this stage, but they will be discovered later as Sarah digs deeper into the operations of the organization. Make a list of the forms, reports, and files that are mentioned by Hal. They will become significant as the use cases are filled out. Finally, try to determine how the event concludes. How do we know it is complete? Is there a final tangible result? If so, make note of that. So, go ahead and study Figure 4-6. Make your list before continuing your reading here. This interview gave Sarah quite a bit of information about the way the dealership operates. Following the meeting with Hal, Sarah began to organize what she learned in the interview by identifying the major events that occur in the typical operations of Holiday Travel Vehicles and the responses made to the events. The events suggest the primary things the users must accomplish with the system, and the responses describe the final results of the activities per- formed when the event occurs. Before looking at Sarah’s event-response list in Figure 4-7, if you have not already done so, develop your own list based on your study of the interview transcript in Figure 4-6. Event Response 1) New vehicles are needed for inventory. Purchase order is placed with vehicle manufacturer. 2) New vehicles arrive from manufacturer. Vehicle information is recorded on new vehicle record. 3) Customer makes an offer on a new vehicle. Details of offer are recorded and presented to owner for acceptance decision. 4) Customer’s offer is accepted. Details of accepted offer are recorded on a FIGURE 4-7 sales contract, and customer provides a deposit. Sample Event- 5) Customer takes delivery on new vehicle. Customer pays for vehicle once offer is accepted, Response List takes possession of the vehicle, and turns in trade- in. Details of the entire purchase are saved. A template for this figure is available on 6) Trade-in is added to used vehicle inventory. Used vehicle information is recorded on used vehicle form. the student web site 134 C ha pte r 4 Use Case Analysis As shown in Figure 4-7, Sarah identified six major events from her initial conversation with Hal. The first two events deal with new vehicles added to the inventory: identifying the need for additional inventory and placing orders and recording vehicles arriving from the manufacturers. Events 3, 4, and 5 are associated with selling vehicles. Finally, event 6 is focused on dealing with trade-in vehicles. Sarah has also listed, in the Response column, the things that signify that the response to an event is concluded. How does her list com- pare to yours? As Sarah studied the event-response list, she decided that the three events associated with vehicle sales (events 3, 4, and 5) involved significant user–system interactions and deserved to be expanded upon with use cases. She decided to focus on these events first. The other events (1, 2, and 6) may be straightforward enough that she can create detailed functional requirements without the need for use cases. If that does not work, she will develop use cases for them by working with the new vehicle manager and used vehicle manager at a later time. As she reflected on events 3, 4, and 5, Sarah could see that these events are three parts of the overall user goal of selling a vehicle to a customer. As shown in Figure 4-8, each event is an independent, but related part of the overall goal. After the use cases are identified, the top parts of the use case form should be filled in with name, ID, primary actor, short description, and trigger—it may be too early to assign the importance level of the use case. The goal is to develop a set of major use cases with the major information about each, rather than jumping into one use case and describing it completely. This prevents the users and analysts from forgetting key use cases and helps the users explain the overall set of business processes that they are responsible for. It also helps users understand how to describe the use cases and reduces the chance of overlap between use cases. In this step, the analysts and users identify a set of major use cases that could benefit from additional definition beyond the requirements definition. Identifying use cases is an iterative process, with users often changing their minds about what a use case is and what it includes. It is very easy to get trapped in the details at this point, so you need to remember that the goal at this step is to just identify the major use cases. For example, in the list of events shown in Figure 4-7, we have defined one event as “Customer makes an offer.” This event includes offers from customers who have trade-in vehicles as well as those who do not have trade-in vehicles. We could describe these two situations as separate use cases, but this would create a larger set of smaller use cases. Therefore, these two possible variations of the event will be combined into a single use case. The trick is to select the right size so that you end up with the major use cases that need additional explanation beyond the requirements definition. Remember that a use case is a set of end-to-end activities that starts with a trigger event and continues through many possible paths until some output has been produced and the system is again at rest. If the project team discovers more than eight or nine major use cases, this suggests that the system is complex (or that the use cases are not defined at the right level of detail). Sell a vehicle Postconditions Postconditions Postconditions Preconditions Preconditions Preconditions Record an offer Accept an offer Take delivery FIGURE 4-8 Chain of Use Cases for Selling a Vehicle  Creating Use Cases 135 If there really are more than eight or nine major use cases, the use cases are grouped together into packages of related use cases. For example, if we were to do a more thorough study of a recreational vehicle dealership, we would likely find more than the six events discussed in our example. The events leading to use cases could be grouped logically together in packages, such as all use cases for inventory, all use cases for sales, all use cases for the shop, etc. These packages are then treated as the major processes for the top level of the process model, with the use cases appearing on lower levels, or are treated as sepa- rate systems and modeled as separate systems. (Process modeling will be described in the next chapter.) Since Sarah was focusing on three use cases, she prepared use case forms for each with the basic information on the top of the forms (Figure 4-9). She then began to complete the use cases by working with a small group of salespeople from the dealership. Identify the Major Steps for Each Use Case At this point, the major use cases have been defined. In short, you have filled in the top portion of the use case (basic information). The next step is to complete the main body of the use case form. The users and analysts work together to describe the envisioned interactions between the user and the system in order to complete the response to the event. Use Case Name: Record an offer ID: UC-3 Priority: High Actor: Salesperson Description: This use case describes how the salesperson records a customer offer on a vehicle. Trigger: Customer decides to make an offer on a vehicle. Type: ✓ External Temporal Preconditions: Salesperson is authenticated Pending Offers datastore is available and on-line Vehicle Inventory datastore is available and on-line Use Case Name: Evaluate an offer ID: UC-4 Priority: High Actor: Sales Manager Description: This use case describes how the Sales Manager evaluates an offer and accepts it or suggests an offer revision. Trigger: A Pending Offer is created and the Sales Manager is notified. Type: ✓ External Temporal Preconditions: Sales Manager is authenticated Pending Offer is available in the Pending Offers datastore Use Case Name: Take delivery ID: UC-5 Priority: High Actor: Salesperson Description: This use case describes how the salesperson completes the vehicle sale to the customer. Trigger: Customer has the final payment for the vehicle. Type: ✓ External Temporal Preconditions: Salesperson is authenticated Sales Contract is complete FIGURE 4-9 Major Use Cases with Basic Information 136 C ha pte r 4 Use Case Analysis Before beginning a discussion of the steps, the analyst should ask the users what tasks need to be completed before the use case steps can begin. This helps clarify the precondi- tions that are necessary for the use case. Remember that the preconditions help define the starting state of the system. Record the preconditions in the proper section on the use case form. Next, the user–system interactions should be outlined as a series of steps in the Nor- mal Course section of the form. The steps focus on what an independent observer would see the user and system do in response to the event. The users should concentrate on the steps that are followed when everything flows smoothly, however, make note of places where branches in logic may occur. In general, the steps should be listed in the order in which they are performed, from first to last, but there also may be steps that are per- formed only occasionally, have no formal sequence in which they are done, or loop back and forth. The order of steps implies a sequence, but does not require it. It is fine to list steps that have no sequence in any order you like, but if there is a sequence, you should list the steps in that way. Each step should be about the same size as the others. For example, if we were writing steps for preparing a meal, steps such as “Take fork out of drawer” and “Put fork on table” are much smaller than “Prepare cake, using mix.” If you end up with more than nine steps or steps that vary greatly in size, you must go back and adjust the steps. Recognizing the size of the steps takes practice, but will become natural in time. One good approach to producing the steps for a use case is to have the users visualize themselves actually performing the use case and write down the steps as if they were writing a recipe for a cookbook. In most cases, the users will be able to quickly define what they do in as-is use cases. Defining the steps for to-be use cases may take a bit more coaching. In our experience, the descriptions of the steps change greatly as the users work through a use case. Our advice is to use an erasable blackboard or whiteboard (or paper with pencil) to develop the list of steps. Once the set of steps is fairly well defined, only then do you write it on the use case form. Occasionally, a use case is so simple that further refinement is not needed. The analyst simply writes a brief description and does not bother to develop the steps within the use case. The information at the top of the use case form is sufficient, because the use case need not be explained in more detail. Some of the use cases presented in the exercises at the end of this chapter are simple enough that they do not need information beyond what is at the top of the use case form. Once the steps have been outlined at the proper level of detail, the postconditions can be completed. Ask the users how they know they are finished with a task. What are the tangible results of performing the steps just listed? Record these in the Postconditions section of the form. Sarah decided that the best way to understand the use case steps for this part of the system was to hold a JAD workshop that involved the sales manager and two senior sales- people. In the workshop, the participants began by describing the initial state of the sys- tem. Sarah asked them to think about what needed to be accomplished before the use case steps could begin. Then, she asked them to describe how they envisioned working with the system to complete the task. Sarah was careful to guide them to think in terms of essential steps that did not assume a particular form of system implementation. Since the goal was to describe the user–system interactions in a new system, Sarah also helped the partici- pants think of what could be done using technology rather than just thinking about the “old way” the steps were performed. As the team worked, it became clear that initially, Sarah had only envisioned recording new offers on vehicles. She did not think about the revision of an offer after it had been rejected. However, after discussion, the team felt that  Creating Use Cases 137 there were only minor differences in recording a new offer versus modifying a previous offer following an offer rejection. Therefore, use case 3 (Record an offer) was written to apply to either situation. After a number of and revisions, the team settled on the partial use cases shown in Figure 4-10. Notice as you look at the examples in Figure 4-10 that Sarah has opted for a style that is not quite as formal as the use case in Figure 4-3, but also not quite as casual as the use case in Figure 4-1. Sarah’s style is suitable for her situation and is sufficient to provide the detail that her team requires. Use Case Name: Record an offer ID: UC-3 Priority: High Actor: Salesperson Description: This use case describes how the salesperson records a customer offer on a vehicle. The offer may be a new offer or a revision of a previously rejected offer. Trigger: Customer decides to make an offer on a vehicle. Type: ✓ External Temporal Preconditions: 1. Salesperson is authenticated. 2. Pending Offers datastore is available and on-line. 3. Vehicle Inventory datastore is available and on-line. 4. Rejected Offers datastore is available and on-line. Normal Course: Information for Steps: 1. Salesperson specifies the offer Vehicle using the Vehicle ID number. 2. The system checks for any pending offers on the vehicle. 3. If there is an offer pending on the vehicle, the system notifies the salesperson and the use case ends. 4. If there are no pending offers on the vehicle, the system asks if this is a new offer or an offer revision. 5. If this is an offer revision, a. The salesperson specifies the ID of the previous offer. b. The system fills the offer form with the content of the previous offer from the Rejected Offers datastore. Otherwise, a. The system fills the offer form with details on the offer vehicle. 6. Salesperson supplies/modifies additional information for the offer, including customer information and the specific offer details (cash plus trade-in value, desired dealer options). 7. The system displays offer summary. 8. The salesperson is asked to obtain customer permission to confirm the offer. 9. If not confirmed, the offer is discarded, otherwise, the confirmed offer is stored as a Pending Offer. 10. A copy of the Pending Offer is printed for the customer. 11. A Pending Offer Notice is sent to the Sales Manager for evaluation and approval. Postconditions: 1. Pending Offer is stored. 2. Sales Manager is sent notice of pending offer. FIGURE 4-10 Major Use Cases with Steps Completed (continued)  Use Case Name: Evaluate an offer ID: UC-4 Priority: High Actor: Sales Manager Description: This use case describes how the Sales Manager evaluates an offer and accepts it or rejects it with a reason. Trigger: A Pending Offer is created and the Sales Manager is notified. Type: ✓ External Temporal Preconditions: 1. Sales Manager is authenticated 2. Pending Offer is available in the Pending Offers datastore Normal Course: Information for Steps: 1. The Sales Manager retrieves the Pending Offer from the Pending Offers datastore. 2. The Sales Manager uses the Vehicle ID number to retrieve the Vehicle Record on the vehicle. 3. The system prompts the Sales Manager to Accept or Reject the offer. 4. If the offer is rejected, a. The system prompts the Sales Manager to provide a reason for the rejection. b. An offer rejection notice including the reason is sent to the salesperson. c. The Pending Offer is removed from the Pending Offers datastore and stored as a Rejected Offer in the Rejected Offers datastore accessible only to the logged in salesperson. 5. If the offer is accepted, a. The system uses information from the Pending Offer to produce a Sales Contract. b. The Sales Contract is stored in the Pending Sales Contracts datastore. c. Two copies of the Sales Contract are printed for the Salesperson and customer. d. The Pending Offer is removed from the Pending Offers datastore and stored in the Accepted Offers datastore. e. The customer deposit is recorded in the Deposits datastore. f. Any dealer options specified in the offer are used to prepare a Shop Work Order, which is stored in the Shop Work Orders datastore and sent to the Shop Manager. Postconditions: 1. Sales Contract is recorded in Pending Sales Contract datastore. 2. Pending Offer is removed from Pending Offers and added to Accepted Offers or to Rejected Offers. 3. Customer deposit amount is recorded for bookkeeper. 4. Work to be done on the sale vehicle is recorded as a show Work Order and Shop Manager is notified. Use Case Name: Take delivery ID: UC-5 Priority: High Actor: Salesperson Description: This use case describes how the salesperson completes the vehicle sale to the customer. Trigger: Customer has the final payment for the vehicle. Type: ✓ External Temporal Preconditions: 1. Salesperson is authenticated. 2. Sales Contract is available in Pending Sales Contract datastore. Normal Course: Information for Steps: 1. The salesperson retrieves the Sales Contract using the contract number. 2. The system asks the salesperson to confirm that the customer accepts the vehicle and has provided the required payment (cash plus trade-in). 3. If confirmed, a. The system stores the Sales Contract in the Final Sales Contract datastore. b. A Final Sales Contract is printed for the customer. c. Payment is recorded. Otherwise, the use case ends. Postconditions: 1. The Sales Contract is recorded in the Final Sales Contract datastore. 2. Payment is recorded. FIGURE 4-10 (continued)  Creating Use Cases 139 Identify Elements within Steps At this point, the steps have been described, but not the elements that further define and link the steps. In other words, the use case forms in Fig- ure 4-10 require some final work before they are complete. The last column (“Information for Steps”) must be completed and arrows may be drawn to describe inputs and outputs from the steps. The goal at this point is to identify the major inputs and outputs for each step. One could identify the inputs and outputs in great detail, but this would make it difficult to list them concisely in the summary area at the bottom of the form. In our example, we have chosen to refer to the inputs and outputs broadly rather than specifying great detail. Another solution would be to identify detailed information for the steps, but to provide only general categories in the summary area of the use case form. For example, if a step needs the customer name, address, and phone number, we might note these in the step description but list only “cus- tomer information” as the major input at the top of the form. The users and analysts now return to the steps in the use case and begin tracing the flow of the steps. Typically, this means asking what inputs (e.g., information, forms, reports) are used by each step or what outputs it produces. These are written in the last column on the use case form, with an arrow pointing into or out of a step (Figure 4-11). Sometimes, forms, reports, and information will flow from one step to the next to the next; these can be shown by arrows pointing from step to step. It is not unusual at this point for users to discover that they forgot to list the entire steps during their first time through the use case. These previously omitted steps are simply added to a revised use case. Our experience has shown that users can forget to include seldom-used activities that occur in special cases (e.g., when data is not available or when something unex- pected occurs), so it is helpful to carefully challenge the user about each step to make sure that nothing has been omitted. Remember our process of gradual refinement; it definitely applies to the creation of the use cases. The Summary area for inputs and outputs found at the end of the use case form is com- pleted once the team is satisfied with the steps, inflows, and outflows listed previously. In this section, all the input flows are listed in the left-most column and their source is specified in the adjacent column. In the third column, all the output flows are listed and their destination is specified in the right-most column. As we have mentioned, this summary area allows the team to easily view all the inputs that must be included to complete the use case and all the outputs that will be produced by the use case. This area of the use case form will be especially useful if the team decides to depict the system with data flow diagrams, which will be explained in Chapter 5. YO U R 4-1 Campus Housing TURN Create a set of use cases for the following high-level for $800 or less per month within 1/2 mile of campus). requirements in a housing system run by the Campus They then contact the apartment owners directly to see Housing Service. The Campus Housing Service helps the apartment and possibly rent it. Apartment owners students find apartments. Owners of apartments fill in call the service to delete their listing when they have information forms about the rental units they have avail- rented their apartment(s). able (e.g., location, number of bedrooms, monthly rent), In building the major use cases, follow the four- which are entered into a database. Students can search step process: identify the use cases, identify the steps through this database via the Web to find apartments within them, identify the elements within the steps, and that meet their needs (e.g., a two-bedroom apartment confirm the use cases. 140 C ha pte r 4 Use Case Analysis Use Case Name: Record an offer ID: UC-3 Priority: High Actor: Salesperson Description: This use case describes how the salesperson records a customer offer on a vehicle. The offer may be a new offer or a revision of a previously rejected offer. Trigger: Customer decides to make an offer on a vehicle. Type: ✓ External Temporal Preconditions: 1. Salesperson is authenticated. 2. Pending Offers datastore is available and on-line. 3. Vehicle Inventory datastore is available and on-line. 4. Rejected Offers datastore is available and on-line. Normal Course: Information for Steps: 1. Salesperson specifies the offer vehicle using the Vehicle ID number. Vehicle ID 2. The system checks for any pending offers on the vehicle. Existing Pending Offers 3. If there is an offer pending on the vehicle, the system notifies the Offer Pending Notice salesperson and the use case ends. 4. If there are no pending offers on the vehicle, the system asks if this is a new offer or an offer revision. Offer Type 5. If this is an offer revision, a. The salesperson specifies the ID of the previous offer. Offer ID b. The system fills the offer form with the content of the previous offer from the Previous Offer Details Rejected Offers datastore. Otherwise, a. The system fills the offer form with details on the offer vehicle. Vehicle Details 6. Salesperson supplies/modifies additional information for the offer, including customer information and the specific offer details (cash plus trade-in value, Customer Details desired dealer options). Offer Details 7. The system displays offer summary. Offer Summary 8. The salesperson is asked to obtain customer permission to confirm the offer. Offer Confirmation 9. If not confirmed, the offer is discarded, otherwise, the confirmed offer is stored as a Pending Offer. New Pending Offer 10. A copy of the Pending Offer is printed for the customer. Pending Offer 11. A Pending Offer Notice is sent to the Sales Manager for evaluation and approval. Pending Offer Notice Postconditions: 1. Pending Offer is stored. 2. Sales Manager is sent notice of pending offer. Summary Inputs Source Outputs Destination Vehicle ID Salesperson Offer Pending Notice Salesperson Existing Pending Offers Pending Offers datastore Offer Summary Customer Offer Type Salesperson New Pending Offer Pending Offer datastore Offer ID Salesperson Pending Offer Customer Previous Offer details Rejected Offers datastore Pending Offer Notice Sales Manager Vehicle datastore Vehicle details Customer details Customer Offer details Salesperson FIGURE 4-11 Major Use Cases with Information for Steps Completed  Creating Use Cases 141 Use Case Name: Evaluate an offer ID: UC-4 Priority: High Actor: Sales Manager Description: This use case describes how the Sales Manager evaluates an offer and accepts it or rejects it with a reason. Trigger: A Pending Offer is created and the Sales Manager is notified. Type: ✓ External Temporal Preconditions: 1. Sales Manager is authenticated. 2. Pending offer is available in the Pending Offers datastore. Normal Course: Information for Steps: 1. The Sales Manager retrieves the Pending Offer from the Pending Pending Offer ID Offer datastore. Pending Offer 2. The Sales Manager uses the Vehicle ID number to retrieve the Vehicle Vehicle ID Record on the vehicle Vehicle details 3. The system prompts the Sales Manager to Accept or Reject the offer. Offer decision 4. If the offer is rejected, a. The system prompts the Sales Manager to provide a reason for Reason for Rejection the rejection. b. An offer rejection notice including the reason is sent to the Offer Rejection Notice salesperson. c. The Pending Offer is removed from the Pending Offers datastore and stored as a Rejected Offer in the Rejected New Rejected Offer Offers datastore accessible only to the logged in salesperson. 5. If the offer is accepted, a. The system uses information from the Pending Offer to produce a Sales Contract. New Sales Contract b. The Sales Contract is stored in the Pending Sales Contracts datastore. c. Two copies of the Sales Contract are printed for the Sales Contract salesperson and customer. d. The Pending Offer is removed from the Pending Offers datastore and stored in the Accepted Offers datastore. New Accepted Offer e. The customer deposit is recorded in the Deposits datastore. Purchase Deposit f. Any dealer options specified in the offer are used to prepare a Shop Work Order, which is stored in the Shop Work Orders Shop Work Order datastore and sent to the Shop Manager. Postconditions: 1. Sales Contract is recorded in Pending Sales Contract datastore. 2. Pending Offer is removed from Pending Offers and added to Accepted Offers or to Rejected Offers 3. Customer deposit amount is recorded for bookkeeper. 4. Work to be done on the sale vehicle is recorded as a Show Work Order and Shop Manager is notified. Summary Inputs Source Outputs Destination Pending offer ID Sales Manager Offer Rejection Notice Salesperson Pending offer Pending Offers datastore New Rejected Offer Rejected Offers datastore Vehicle ID Sales Manager New Sales Contract Sales Contract datastore Vehicle details Vehicle datastore Sales Contract Customer/Salesperson Offer decision Sales Manager New Accepted Offer Accepted Offers datastore Reason for Rejection Sales Manager Purchase Deposit Deposits datastore Shop Work Order Shop Work Orders datastore Shop Work Order Notice Shop Manager FIGURE 4-11 (continued) 142 C ha pte r 4 Use Case Analysis Use Case Name: Take delivery ID: UC-5 Priority: High Actor: Salesperson Description: This use case describes how the salesperson completes the vehicle sale to the customer. Trigger: Customer has the final payment for the vehicle. Type: ✓ External Temporal Postconditions: 1. Salesperson is authenticated. 2. Sales Contract is available in Pending Sales Contract datastore. Normal Course: Information for Steps: 1. The saleperson retrieves the Sales Contract using the contract number. Sales Contract ID 2. The system asks the salesperson to confirm that the customer accepts Vehicle Accepted confirmation the vehicle and has provided the required payment (cash plus trade-in). Payment Submission verification 3. If confirmed, a. The system stores the Sales Contract in the Final Sales Contract datastore. New Final Sales Contract b. A Final Sales Contract is printed for the customer. Final Sales Contract c. Payment is recorded. Final Payment Oth