Use CaseModeling Part 1: Context Diagram Develop a usecase context diagram for the NexGen POS system based on the format of Larmanfigure 6.3 and referencing figures 6.4 and 6.5. Use Larman chapter 6, especially 6.16 and 6.17, as guides.

Use Cases Start the name of use cases with a verb. A common exception to one use case per goal is to collapse CRUD (create, retrieve, update, delete) separate goals into one CRUD use case, idiomatically called Manage For example, the goals edit user," "delete user," and so forth are all satisfied by the Manage Users use case. 6.16. Guideline: What Tests Can Help Find Use- ful Use Cases? Which of these is a valid use case? Negotiate a Supplier Contract Handle Returns Log In Move Piece on Game Board An argument can be made that all of these are use cases at different levels, depending on the system boundary, actors, and goals. But rather than asking in general, "What is a valid use case?", a more practical question is: "What is a useful level to express use cases for application requirements analysis?" There are several rules of thumb, including: The Boss Test The EBP Test The Size Test The Boss Test Your boss asks, "What have you been doing all day?" You reply: "Logging in!" Is your boss happy? If not, the use case fails the Boss Test, which implies it is not strongly related to achieving results of measurable value. It may be a use case at some low goal level, but not the desirable level of focus for requirements analysis. That doesn't mean to always ignore boss-test-failing use cases. User authentication may fail the boss test, but may be important and difficult The EBP Test An Elementary Business Process (EBP) is a term from the business process engineering field, defined as: A task performed by one person in one place at one time, in response to a business event, which adds mea- surable business value and leaves the data in a consistent state, e.g., Approve Credit or Price Order (original source lost), SEBP is similar to the term user task in usability engineering, although the meaning is less strict in that domain. 72 Use Cases Focus on use cases that reflect EBPs. The EBP Test is similar to the Boss Test, especially in terms of the measurable business value qualification The definition can be taken too literally: Does a use case fail as an EBP if two people are required, or if a person has to walk around? Probably not, but the feel of the definition is about right. It's not a single small step like "delete a line item" or "print the document." Rather, the main success scenario is probably five or ten steps. It doesn't take days and multiple sessions, like "negotiate a supplier contract"; it is a task done during a single session. It is probably between a few minutes and an hour in length. As with the UP's definition, it emphasizes adding observable or measurable business value, and it comes to a resolution in which the system and data are in a stable and consistent state. The Size Test A use case is very seldom a single action or step, rather, a use case typically contains many steps, and in the fully dressed format will often require 3-10 pages of text. A common mistake in use case modeling is to define just a single step within a series of related steps as a use case by itself, such as defining a use case called Enter an Item ID. You can see a hint of the error by its small sizethe use case name will wrongly suggest just one step within a larger series of steps, and if you imagine the length of its fully dressed text, it would be extremely short. Example: Applying the Tests Negotiate a Supplier Contract Much broader and longer than an EBP. Could be modeled as a business use case, rather than a system use case Handle Returns . OK with the boss. Seems like an EBP. Size is good. Log In Boss not happy if this is all you do all day! Move Piece on Game Board Single stepfails the size test. Reasonable Violations of the Tests Although the majority of use cases identified and analyzed for an application should satisfy the tests, exceptions are common It is sometimes useful to write separate subfunction-level use cases representing subtasks or steps within a regular EBP-level use case. For example, a subtask or extension such as "paying by credit" may be repeated in several base use cases. If so, it is desirable to separate this into its own use case, even though it does not really satisfy the EBP and size tests, and link it to several base use cases, to avoid duplication of the text. see the use case "include" relationship for more on linking subfunction use cases p. 494 73 Use Cases Authenticate User may not pass the Boss test, but be complex enough to warrant careful analysis, such as for a single sign-on" feature, 6.17. Applying UML: Use Case Diagrams The UML provides use case diagram notation to illustrate the names of use cases and actors, and the relation- ships between them (see Figure 6.3). Figure 6.3. Partial use case context diagram. system boundary NextGen POS communication Process Sale alternate notation for a computer system actor Customer Payment Authorization Service Handle Returns actor wactor Tax Calculator Cashier Cash In cactor Accounting System Manager Analyze Activity cactor HR System actory Sales Activity System Manage Security System Administrator Manage Users use case Use case diagrams and use case relationships are secondary in use case work. Use cases are text docu- ments. Doing use case work means to write text. A common sign of a novice (or academic) use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text. World-class use case experts such as Fowler and Cockburn, among others, downplay use case diagrams and use case relationships, and instead focus on writing. With that as a caveat, a simple use case diagram provides a succinct visual context diagram for the system, illustrating the external actors and how they use the system. *Cash In" is the act of a cashier arriving with a drawer insert with cash, logging in, and recording the cash amount in the drawer insert. 74 Use Cases Guideline Draw a simple use case diagram in conjunction with an actor-goal list. A use case diagram is an excellent picture of the system context; it makes a good context diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets used. It serves as a communication tool that summarizes the behavior of a system and its actors. A sample partial use case context diagram for the NextGen system is shown in Figure 6.3. Guideline: Diagramming Figure 6.4 offers diagram advice. Notice the actor box with the symbol actor. This style is used for UML keywords and stereotypes, and includes guillemet symbolsspecial single-character brackets (actor), not >) most widely known by their use in French typography to indicate a quote. Figure 6.4. Notation suggestions. For a use case context Show computer system actors diagram, limit the use cases to with an alternate notation to user-goal level use cases. human actors. NextGen Process Sale actor Payment Authorization Service Cashier primary actors on the left supporting actors on the right To clarify, some prefer to highlight external computer system actors with an alternate notation, as illustrated in Figure 6.5. Figure 6.5. Alternate actor notation. NextGen Process Sale -actone Payment Authorization Service system Payment Authorization Service Some UML alteratives to illustrate external actors that are other computer systems. The class box style can be used for any actor, computer or human. Using it for computer actors provides visual distinction Payment Authorization Service 75 Use Cases Start the name of use cases with a verb. A common exception to one use case per goal is to collapse CRUD (create, retrieve, update, delete) separate goals into one CRUD use case, idiomatically called Manage For example, the goals edit user," "delete user," and so forth are all satisfied by the Manage Users use case. 6.16. Guideline: What Tests Can Help Find Use- ful Use Cases? Which of these is a valid use case? Negotiate a Supplier Contract Handle Returns Log In Move Piece on Game Board An argument can be made that all of these are use cases at different levels, depending on the system boundary, actors, and goals. But rather than asking in general, "What is a valid use case?", a more practical question is: "What is a useful level to express use cases for application requirements analysis?" There are several rules of thumb, including: The Boss Test The EBP Test The Size Test The Boss Test Your boss asks, "What have you been doing all day?" You reply: "Logging in!" Is your boss happy? If not, the use case fails the Boss Test, which implies it is not strongly related to achieving results of measurable value. It may be a use case at some low goal level, but not the desirable level of focus for requirements analysis. That doesn't mean to always ignore boss-test-failing use cases. User authentication may fail the boss test, but may be important and difficult The EBP Test An Elementary Business Process (EBP) is a term from the business process engineering field, defined as: A task performed by one person in one place at one time, in response to a business event, which adds mea- surable business value and leaves the data in a consistent state, e.g., Approve Credit or Price Order (original source lost), SEBP is similar to the term user task in usability engineering, although the meaning is less strict in that domain. 72 Use Cases Focus on use cases that reflect EBPs. The EBP Test is similar to the Boss Test, especially in terms of the measurable business value qualification The definition can be taken too literally: Does a use case fail as an EBP if two people are required, or if a person has to walk around? Probably not, but the feel of the definition is about right. It's not a single small step like "delete a line item" or "print the document." Rather, the main success scenario is probably five or ten steps. It doesn't take days and multiple sessions, like "negotiate a supplier contract"; it is a task done during a single session. It is probably between a few minutes and an hour in length. As with the UP's definition, it emphasizes adding observable or measurable business value, and it comes to a resolution in which the system and data are in a stable and consistent state. The Size Test A use case is very seldom a single action or step, rather, a use case typically contains many steps, and in the fully dressed format will often require 3-10 pages of text. A common mistake in use case modeling is to define just a single step within a series of related steps as a use case by itself, such as defining a use case called Enter an Item ID. You can see a hint of the error by its small sizethe use case name will wrongly suggest just one step within a larger series of steps, and if you imagine the length of its fully dressed text, it would be extremely short. Example: Applying the Tests Negotiate a Supplier Contract Much broader and longer than an EBP. Could be modeled as a business use case, rather than a system use case Handle Returns . OK with the boss. Seems like an EBP. Size is good. Log In Boss not happy if this is all you do all day! Move Piece on Game Board Single stepfails the size test. Reasonable Violations of the Tests Although the majority of use cases identified and analyzed for an application should satisfy the tests, exceptions are common It is sometimes useful to write separate subfunction-level use cases representing subtasks or steps within a regular EBP-level use case. For example, a subtask or extension such as "paying by credit" may be repeated in several base use cases. If so, it is desirable to separate this into its own use case, even though it does not really satisfy the EBP and size tests, and link it to several base use cases, to avoid duplication of the text. see the use case "include" relationship for more on linking subfunction use cases p. 494 73 Use Cases Authenticate User may not pass the Boss test, but be complex enough to warrant careful analysis, such as for a single sign-on" feature, 6.17. Applying UML: Use Case Diagrams The UML provides use case diagram notation to illustrate the names of use cases and actors, and the relation- ships between them (see Figure 6.3). Figure 6.3. Partial use case context diagram. system boundary NextGen POS communication Process Sale alternate notation for a computer system actor Customer Payment Authorization Service Handle Returns actor wactor Tax Calculator Cashier Cash In cactor Accounting System Manager Analyze Activity cactor HR System actory Sales Activity System Manage Security System Administrator Manage Users use case Use case diagrams and use case relationships are secondary in use case work. Use cases are text docu- ments. Doing use case work means to write text. A common sign of a novice (or academic) use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text. World-class use case experts such as Fowler and Cockburn, among others, downplay use case diagrams and use case relationships, and instead focus on writing. With that as a caveat, a simple use case diagram provides a succinct visual context diagram for the system, illustrating the external actors and how they use the system. *Cash In" is the act of a cashier arriving with a drawer insert with cash, logging in, and recording the cash amount in the drawer insert. 74 Use Cases Guideline Draw a simple use case diagram in conjunction with an actor-goal list. A use case diagram is an excellent picture of the system context; it makes a good context diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets used. It serves as a communication tool that summarizes the behavior of a system and its actors. A sample partial use case context diagram for the NextGen system is shown in Figure 6.3. Guideline: Diagramming Figure 6.4 offers diagram advice. Notice the actor box with the symbol actor. This style is used for UML keywords and stereotypes, and includes guillemet symbolsspecial single-character brackets (actor), not >) most widely known by their use in French typography to indicate a quote. Figure 6.4. Notation suggestions. For a use case context Show computer system actors diagram, limit the use cases to with an alternate notation to user-goal level use cases. human actors. NextGen Process Sale actor Payment Authorization Service Cashier primary actors on the left supporting actors on the right To clarify, some prefer to highlight external computer system actors with an alternate notation, as illustrated in Figure 6.5. Figure 6.5. Alternate actor notation. NextGen Process Sale -actone Payment Authorization Service system Payment Authorization Service Some UML alteratives to illustrate external actors that are other computer systems. The class box style can be used for any actor, computer or human. Using it for computer actors provides visual distinction Payment Authorization Service 75