Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Hi600 u04_inst_slides
Similar a Hi600 u04_inst_slides (20)
Más de ljmcneill33
Más de ljmcneill33 (20)
Último
Último (20)
Hi600 u04_inst_slides
- 1. HI-600: Analysis and Design of Health Information Systems Analysis: Part II Use Case Analysis
- 2. USE CASES (UC) • A use case depicts a set of activities that produce some output result. • Each use case describes how an external user triggers an event to which the system must respond. • Perceives the system strictly from users’ perspective. • With this type of event-driven modeling, everything in the system can be thought of as a response to some triggering event. • Creation of use cases is often done as a part of interview session with users or a part of JAD sessions.
- 3. Use Cases: Outline • Elements of a use case • Alternative use case formats • Use cases and testing • Building use cases • Identify the major use cases • Identify the major steps within each use case • Identify elements within steps • Confirm the use case
- 4. • Basic Information • A descriptive name and brief description • ID Number (usually sequential) • Priority: how important is it for the new system • Actor (user role): something that interacts with system to achieve a goal • Triggers (external or temporal): what starts the UC • Preconditions • Most UCs are sequential • What must happen before this UC occurs Elements of a Use Case
- 5. Elements of a Use Case • Big picture of user interactions with the system • List of steps needed to execute • Inputs needed for and outputs produced by the steps • Normal Course • Everything goes as planned (happy path) • Default options are chosen • Alternative Course • If normal course includes conditional steps • Branch logic (user chooses non-default option) • Still want to reach the desired end result
- 6. Elements of a Use Case • Post-Conditions • What happens after the end result is reached? • Also defines preconditions of the next UC • Exceptions • What possible errors/exceptions could be encountered and at which step? • What should happen is such error is encountered?
- 7. Elements of a Use Case • Summary Inputs and Outputs • List of all inputs and outputs (including all courses) • Including input sources and output destinations • Additional Use Case Issues • Frequency of use • Business rules • Special requirements • Assumptions • Notes and issues
- 8. Alternative Use Case Formats • A full-dressed use case is very thorough, detailed, and highly structured. • The project team may decide that a more casual use case format is acceptable.
- 9. Use Cases & Testing • Now that we know what the system must do… • Can create test plans for developers to test against • Test plans upfront to designate success / failure of a particular sequence of events
- 10. Building Use Cases • Through interviews, interactions, and observations of the as-is system or work-flow • Identify the major use cases • Identify the major steps within each use case • Identify elements within steps • Confirm the use case
- 11. Use Case Building Example • Want to build a new EHR • What are some of the possible major use cases? • Physician Order Entry • Medication Reconciliation • Pharmacy Verification • Pharmacy Order Placement • Medication Delivery • Inventory Management
- 12. Use Case Building Example: POE • Identify the major use cases (con’t) • Basic Information for Physician Order Entry • Name: Physician Order Entry • Actor: Physician (MD) • ID: EHR-UC1 • Description: Physician places a medication order for a patient by identifying the patient, the drug, and the dosage. The system creates the order and places it in the pharmacy verification list. • Trigger: Physician wants to place a medication order (External)
- 13. Use Case Building Example: POE • Identify major steps and their elements for Physician Order Entry 1. MD navigates to the intended patient 1. MD navigates to the floor / unit of the patient 2. System displays a list of patients for the floor / unit 3. MD navigates to the patient’s profile 2. MD navigates to the intended drug 1. MD navigates to the ordering section 2. System displays the formulary 3. MD selects a specific medication and enters dosage 3. MD places order 1. System displays the order, current medications, and their interactions 2. MD verifies and submits the order or cancels it (alt. course 3.2.1) 3. System creates an order pending pharmacy verification 4. System notifies the pharmacy Patient Location Existing Patients List Patient ID Orders Section ID Existing Formulary Med ID and dosage Current Meds and Int Submission Pending Order Pending Order Notice
- 14. Use Case Building Example • Confirmation • Was the medication order produced with all of the steps listed? • Would a developer be able to take those steps and understand what he/she is developing for? • Revise functional requirements based on use cases
- 15. SUMMARY • A use case contains all the information needed to build one part of a process model, expressed in an informal, simple way. • When writing a use case, • identify the triggering event, • develop a list of the major steps, • identify the input(s) and output(s) for every step, • have the users role-play the use case to verify.
Notas del editor
- Welcome to the fourth week of Analysis and Design of Health Information Systems. Last week, we started discussing the Analysis phase of the Systems Development Life Cycle: first talked about how to determine requirements for the system, which included three main steps; 1. understanding the as-is system, which could be an existing information system or a paper based workflow, 2. identifying improvements to the as-is system and 3. defining the requirements for the new system. We also talked about techniques that can be used to gather requirements And we discussed some of the common strategies that are used to encourage users to think critically during requirements gathering and to help the systems analyst discover requirements. We mentioned that the requirements definition statement, which is a list of functional and non-functional requirements, as the deliverable of the requirements determination process,. Last week, we mentioned that the requirements that describe what the users of the system need to do are called user requirements. This week, we are discussing use cases as a means of expressing those user requirements.
- Use cases are used extensively in the analysis phase. In a general sense, a use case represents how a system interacts with its environment, that is its users. Use cases illustrate (a) the kinds of user activities that trigger system events and (b) the system’s responses that are triggered by those events. For example: a physician would like to order a medication, she clicks on medication order form which triggers a “new medication order” system event to which the system responds by bringing up list of medications to select from. A use case would describe both users’ actions and system’s responses to those actions. Use cases perceive the system strictly from the user’s perspective and not from an internal, technological, or an architectural perspective. Therefore user involvement in developing use cases is essential. We should remember that the use cases can be used to create part of the functional requirements. However, they omit requirements that are not related to the users and therefore do not provide the entire list of requirements. Use cases started to be used in systems development with the introduction of object-oriented development. Before that, process models and data models were used during interviews with the users, which had some disadvantages: first of all, process and data modeling languages are not easy for users to understand; they are tools the developers are trained to use, but not the users. Also, they do not clearly demonstrate to the users what is possible and what the limitations are. On the other hand, use cases provide details about the functional requirements and help us understand exceptions, special cases, and error handling better. Of course, use cases may not be appropriate to describe all applications; they are more useful with applications that have user interfaces and less useful with background applications, such as batch processes or data warehousing. Use cases are also not necessary for simple and straightforward user requirements, since simple requirements do not need the level of detail, where a use case would be beneficial. As I said before, the use cases were introduced with the object-oriented development and we will get into object oriented development in Unit 10 when we review Chapter 14. There, we will see that use cases are described as use case diagrams, which is useful for object-oriented development. For the purposes of general system development, we will use text-driven use cases here. The text-based use case is easy for the users to understand, and also flows easily into the creation of process and data models that we will explore in the coming couple of week.
- Now that we have a general understanding of what use cases are, let me give an outline of how are going to get into the details of use cases: (the slide)
- There is no set standard in terms of the content, format, or the degree of formality for use cases. They may vary from one organization to another. For our purposes, we will follow the use case elements described in the textbook, which covers most varieties of use cases uses in the industry. So let us start with some of the basic elements that are common for almost all use cases: First of all, each use case has a descriptive name, that is a brief description that explains the purpose of the use case, An id number to identify it within the project. In some instances, the use case id may be prefixed by the project id. A priority may be assigned to a use case to indicate the relative significance of a particular use case within the entire system. Priority assignment is especially useful when a methodology is used that implements the system in versions, so that higher priority use cases can be targeted during the development of the earlier versions. The actor or user role of a use case refers to a person, another system, or a device that interacts with the system to achieve a useful goal. And a use case would also have a trigger, which refers to the event that causes the use case to begin. There could be triggers external to the system, such as physician placing a medication order, Or there could be temporal triggers activated by time-based events within the system, like pre-set timer to administer the next dose of a medication. Other than the priority, all of the 4 basic information elements are required for all use cases. Although it is not required, preconditions section is also a very common element of use cases, because the use cases are usually performed in sequence and we need to clearly define what conditions must be met before a use case is allowed to be run. The preconditions define the state that the system must be in before the use case takes place.
- The next part of a use case describes the course of user interactions with the system when the use case starts. The course describes a list major user-system interaction steps that are performed to execute the system’s response to the event. The list also includes inputs used for the steps, and the outputs produced by the steps. As you see on this example some steps require information from the user, other use cases, or system’s data-stores into the use case and some steps require the use case produce information for the user, system’s data-stores or other use cases. * A use case may include different courses of user-system interaction if its steps include conditionals describing multiple possible behaviors based on pre-determined conditions. The normal course describes the expected behavior when default behaviors are assumed for the conditional steps. And the alternative course(s) depict branches (alternative paths of the steps) that will also lead to a successful conclusion of the use case. For every possible outcome of every conditional step described in the normal course, there needs to be an alternative course.
- Post-Conditions: When the system includes a sequence of uses cases, just like we needed a pre-conditions section, we would also need a post-conditions section. The post-conditions section of a use case defines the final product of the use case. These post-conditions also serve to define the preconditions for the next use case in the sequence. Exceptions: Creating a system for a business workflow usually means recognizing patterns and mimicking them in your system. However, usually there are exceptions to the general pattern and it is impossible to program all exceptions in a deterministic system such as information systems. On the other hand, users can help determine at least most likely potential exceptions, so that the system would know what to do when they occur, instead of crashing or even worse producing wrong results that are hard for the user to recognize. In the exceptions section, a use case should describe any probable error conditions or exceptions that may occur as the use case steps are performed. These steps are different from the steps of alternative courses in the sense that they are not normal branches in decision logic, but are unusual occurrences or errors that could potentially be encountered and may lead to an unsuccessful result.
- The final section of a use case summarizes the set of major inputs and outputs of the use case, along with their source or destination. As you can imagine, this is very helpful for the developers and the analyst to be able to look at only this section of the use case and see its relation with other use cases without having to look at each step. Some additional sections may also be included in a use case depending on the kind of the project or the kind of use case at hand, or because of a general policy of the organization. These additional sections may include … (the slide)
- As I said at the beginning, there aren’t necessarily any standard format for a use case, so some use cases may have all of the elements we mentioned and some may only have the basic ones. A full-dressed use case is described as a very thorough, detailed, and highly structured use case including all elements of a use case we talked about. However, the project team may decide that a more casual use case format is acceptable based on how much the user representatives are engaged with the development team, complexity and potential risk of the project, whether comprehensive test cases are required, or whether teams of developers will be working on the project. So, there isn’t a standard for the level of detail a particular use case should have.
- Use cases are very helpful to create functional requirements. Moreover, they are also helpful to create test plans earlier in the development process to designate success or failure of a particular sequence of events. Including testing and quality assurance personnel in creating use cases would also help creating thorough exceptions section for the use cases, since they are likely to come up with “what if” scenarios to cover most of the possible exceptions and errors.
- Now that we have an understanding of what use cases are and what they can be used for, let’s now talk about a process of building use cases for a project. Use cases can be used for as-is systems to understand existing system or workflow better and identify improvements Or they can be used for to-be systems to help create user requirements. Building use cases often help identify requirements that are not included in the initial requirements definition. Therefore, the requirements definition is usually revised based on the use cases created for the to-be system. Through the use of requirements gathering techniques, the following steps are performed to build use cases: we first identify the major use cases, then we identify the major steps in each use case, then we identify triggers, inputs, and outputs for each step and finally we validate that each use case is correct and complete. So now, we will go through an example and explain each step of use case building process in more detail.
- So, let’s say our project is to build a new electronic health record system for a hospital. First we determine the major use cases. Since use cases are used to describe user requirements, the requirements definition would be a good place to look to identify major use cases. We should note that not every requirement is a good candidate for a use case. Some requirements may be very simple and straightforward, so they may not need a use case to describe them in detail. Also non-functional requirements are not directly user related, so they are not appropriate to have a use case either. Coming back to our example, obviously, there would be tens of use cases for such an electronic health record comprehensive system. If the system has more than eight or nine use cases, it may be useful to group related use cases into a package. The use cases could be conceptually related, but more importantly, packaged use cases should be the ones that follow each other. In our example, let’s say we are focusing on packaging only the use cases relevant to medication order and delivery of the EHR system. In order to identify the major use cases, it is helpful to create an event-response list based on requirement gathering activities, like interviews or document analysis. Events here refer to things that cause the users to perform some tasks and responses refer to the final results of the activities performed when the event occurs. At this stage, details of the use cases will not be apparent, but that is OK, all we are trying to determine here are the names of the major use cases. Since building use cases for a project is an iterative process, we will probably come back to make changes to the list of major use cases as we learn more details about the as-is and to-be systems. So, going back to our example, let’s say we have identified six use cases for the medication order and delivery use case package and they are (the slide)… As a deliverable of this step, the basic information section of the use case form is completed for each of the major use cases.
- So let us fill out the basic information for the Physician Order Entry use case. (The Slide)
- The next step is to complete the main body of the use case forms, which is what we want the system’s response be to the event. Let’s take the physician order entry use case to work on. Users and the analyst work together to determine the list of major system responses when physician order entry event occurs. First, pre-conditions need to be clarified. For example, in order for a physician to enter an order to the system, he or she has to be authenticated to the system and his or her role has to be determined as a physician. Then the normal course of the user-system interactions are listed in the order they are expected to happen. Order of steps implies sequence when it makes sense, however the order of steps does not require a sequence, since some of the steps may not be sequential. If the steps include conditionals, then major steps of the alternative course(s) should also be included. It is also important for the step sizes to be consistent for the use case to be effective and easy to communicate among various teams. So going back to our Physician Order Entry use case example, let us go through some of the major steps identified. (the slide) At this step of building use cases, we also identify the post-conditions, that are the final products of the use case. For our Physician Order Entry use case, the post conditions would be “a new order pending verification is stored” and “pharmacy is notified of an order creation”. Finally, if they exist exceptions should also be created at this step. * The next step is identification of input/output elements for each step. In this step of building use cases, users and the analyst are questioning the flow of the use case from a step to another. This process helps the users to recognize steps they may have omitted initially. After inputs and outputs of the steps are identified, they are collected in the Summary part of the Use Case Form along with the input sources and output destinations. In our example the input source for patient location would be the physician and output destination for Pending Order Notice would be the Pharmacy Verification use case.
- The final step of building uses cases is to go back and review each use case with the users. Role play is an effective technique for confirmation of use cases. During role-play, the analyst can ask the users to follow the use case step by step and see if they can successfully arrive at the final result that the use case was designed for. In our example, we would need to confirm if medication order got created and whether the pharmacy received a notification of a pending medication order. A follow-up step after creating use cases would be to revisit functional requirements and revise them based on the knowledge gained during the process of use case creation.
- So, that is the end of the lecture for this week. Just to recap, we have talked about use case this week: an important element of analysis phase that helps improve our understanding of the as-is system as well as the user requirements of the to-be system. Next week and the week after, we will take it from here and discuss how we can build process and data models based on requirements.