1 © 2005 course technology1 1 1 University Of Palestine Chapter 5 (Cont.) Scoping the IT Project with System Use Cases

2 Step 1b i: Identify Actors (Role Map) (Cont.) Case Study E1: Role Map Problem Statement: You’ve again met with stakeholders to determine which of the business actors and workers involved in business use cases will interact with the proposed IT system—either directly, by using the software, or indirectly, by receiving reports, statements, and so on, from it. Also, you’ve investigated the computer systems with which the proposed system needs to communicate.

3 © 2005 course technology3 Step 1b i: Identify Actors (Role Map) (Cont.) Case Study E1: Role Map (Cont.)

4 © 2005 course technology4 Step 1b i: Identify Actors (Role Map) (Cont.) Case Study E1: Role Map (Cont.)

5 © 2005 course technology5 Step 1b i: Identify Actors (Role Map) (Cont.) Case Study E1: Resulting Documentation

6 © 2005 course technology6 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) Managing a Large Number of Use Cases –If your project supports only one business use case, you may proceed directly to the following step, Identify system use cases. –But if it supports a number of business use cases, consider creating system use-case packages. –A system use-case package is a collection of system use cases and the diagrams that describe them. –The UML package icon looks like (and acts similarly to) a Windows folder.

7 © 2005 course technology7 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) What Criteria Are Used to Group System Use Cases into Packages? UML does not impose any criteria, but here are some common approaches: –Group system use-cases by the main actor who uses them. –Create a system use case package for each business use case.

8 © 2005 course technology8 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) Naming Use-Case Packages –Formally, since a package is a thing—specifically, a container—then it should be named with a noun phrase. –On the other hand, because of the way we are using the packages, it makes sense to name each package according to the business use case it supports.

9 © 2005 course technology9 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) Diagramming System Use-Case Packages –The diagram used to represent system use-case packages is, formally, a use-case diagram— though it looks a little odd in that it does not depict any actual use cases. –Figure 5.5 shows some of the system use case packages for a credit card system and the actors who interact with them.

10 © 2005 course technology10

11 © 2005 course technology11 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) Diagramming System Use-Case Packages (Cont.) –The direction of the arrow from the actor to the package indicates whether an actor initiates system use cases in the package (in which case the arrow points away from the actor) or whether the use cases initiate some action by the actor (the arrow points to the actor). –The dashed line indicates a dependency—a loose connection between modeling elements that means one element has some awareness of another one— and the arrowhead indicates the direction of the dependency.

12 © 2005 course technology12 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) What If a Use-Case Package Is Connected to All of the Specialized Actors of a Generalized Actor? –Connect the package to the generalized actor.

13 © 2005 course technology13 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) Example: –suppose that VERIFY was only one of a number of systems that were able to verify a person’s credit and that the system under design needed to be able to communicate with all of them. You’d indicate that as shown in the following figure:

14 © 2005 course technology14 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) –The use-case package diagram would now look like Figure 5.7. In the diagram in Figure 5.7, there is no need to show the specializations of the generalized Bank-to-Bank System, since they are described in the role map shown in Figure 5.6.

15 © 2005 course technology15 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) Case Study E2: System Use-Case Packages Problem Statement: You begin by considering the business use-case model that you identified earlier Also, you review the role map, which identifies users and external systems that interact with the IT system. Based on these diagrams and the initial draft of the BRD, your next step is to define the system use-case packages for the project.

16 Step 1b ii: Identify System Use-Case Packages (System Use-Case Diagram) Resulting Documentation See Book Page 97

17 Figure 5.9 System use-case package diagram for case study E2

18 Step 1b iii: Identify System Use Cases (System Use-Case Diagram) System Use Cases: The next step is to identify the system use cases that go into the packages. You do this by going back to the business use cases and reviewing the activities they describe. First try to determine, with stakeholders, which of these activities fall within the scope of the IT project. Where things are currently being done manually, you’re looking for activities that could be either fully or partially automated by the IT project. Where things are being done using IT, you’re looking for opportunities for improvement.

19 Step 1b iii: Identify System Use Cases (System Use-Case Diagram) (Cont.) System Use Cases (Cont.): Once you’ve identified the activities, you’ll need to group them into system use cases. How will someone sitting at a terminal actually use this system? What result is the user trying to achieve from the computer system with each interaction? Each of these results, expressed as a user goal, is a system use case. For example, for a Web banking system, some system use cases are View transaction history, Transfer funds, and Pay bill.

20 Step 1b iii: Identify System Use Cases (System Use-Case Diagram) (Cont.) What Is the Purpose of Segmenting the User Requirements into System Use Cases? System use cases become the central tool that governs the management of the project. With their user perspective, they keep the team focused on the user throughout the project. Here’s how: The requirements are written from the user’s point of view. System use cases help ensure that the user receives useful functionality with each release when a project is managed iteratively. System use cases lead to user interfaces that are organized from a user perspective.

21 Step 1b iii: Identify System Use Cases (System Use-Case Diagram) (Cont.) Modeling System Use Cases Once you’ve decided what system use cases are required to support a business use case, you document your findings in a system use-case diagram. Create one (or more if necessary) system use-case diagram for each system use-case package. The system use-case diagram shows which actors participate in each system use case. The system diagram does not show sequencing;

22 Figure 5.10 Example of a system use-case diagram

23 Step 1b iii: Identify System Use Cases (System Use-Case Diagram) (Cont.) Primary actor: An actor who initiates a use-case interaction. Secondary actor: An actor that the system initiates an interaction with, once the use case has already started.

24 Step 1b iii: Identify System Use Cases (System Use-Case Diagram) (Cont.) Here’s what the diagram says: A CSR (customer service representative) enters credit card application information. A Manager may adjudicate a credit card application. The system use case, once under way, may involve an interaction with an external computer system. The system use case may also involve an interaction with a bank customer, for example, by ing the customer a letter of acceptance or rejection.