1. 155 CONCEPTUAL DESIGN: PURPOSE, ACTORS, FEATURES, AND UML USE CASES

2. 156 Information Systems Purpose n The overriding purpose of any information system is to support the mission of the enterprise n Every information system has a [specific] purpose or mission n No matter how trivial the purpose may seem, do not skip documenting it

3. 157 Information System Purpose Examples n A Convenience Store: The purpose of the information system is "To help each cashier work more effectively during checkout, to keep good records of each sale, and to support more efficient store operations." n A Warehouse: The purpose of the information system is "To improve warehouse profitability by helping team members put away and pick items more efficiently…by keeping more accurate inventory counts, and by increasing fill rate."

4. 158 Information Systems Purpose Guidelines Purpose Statements should be: Kept short – 25 words or less if possible Proactive in form Supportive the mission of the enterprise Broad in scope, yet specific to the problem Void of technology jargon

5. 159 Actors Actor definitions: An abstraction for entities outside a system, subsystem, or class that interact directly with the system. An actor participates in a use case or coherent set of use cases to accomplish an overall purpose. [UML] A coherent set of roles that users of use cases play when interacting with the use cases. [Booch, Rumbaugh and Jacobson] Roles people or other information systems play when interacting through a use case with this information system. [Norman]

6. 160 Actors n Actors are not part of the systemthey represent anyone or anything [another system] that must interact with the system n Actors input to and/or receive output from the information system n Actors are often identified via conversations with subject domain [matter] experts

7. 161 Actor Examples n Customer n Student n Employee n Faculty n Member n Credit Card Validation System Mary Tom Jack Dino

8. 162 Features n A prominent or significant functional, behavioral or descriptive part of an information system Broad in scope; apply to whole system Narrow in scope; apply to one part of the system n An end-to-end (start-to-finish) significant process of the information system n Synonymous with the UMLs Use Case n Granularity is arbitrary

9. 163 Feature Examples (note the start-to-finish characteristic) n Course Registration or Add a course Drop a course Check seat availability n Membership Maintenance or Add a members information Change a members information Delete a membership Print/Display membership information

10. 164 Log Information Conduct Business Analyze results Interact with other systems Types of Information System Features (needed information) Business Problem Reference Data (Master, Foundational data) Business Problem Transaction Data Business Problem Results Business Problem Integration A feature is a tangible, measurable, desired outcome that an information system could produce. page 1 of 3

11. 165 Features Examples u Log Information: Maintain membership information Maintain product information Maintain vendor (supplier) information Maintain employee security information etc… u Conduct Business: Rental transaction Sales transaction Order products transaction etc... page 2 of 3 (Maintain = adding, changing, deleting, & viewing)

12. 166 Features Examples u Analyze results: Produce Periodic Sales Report s by: Product Employee Fastest-moving rentals Fastest-moving sales Produce On-Order Report sorted by Vendor Produce On-Order Report sorted by Product etc… u Interact with other systems: Validation of Credit Cards etc... page 3 of 3

13. 167 Documenting Actors and Features n Actor #1 Feature #1 Feature #2 Feature #3 n Actor #2 Feature #1 Feature #2 Feature #3 n Actor #3 Feature #1 Feature #2 Feature #3 n Actor #4 Feature #1 Feature #2 Feature #3

14. 168 Use Case Diagram Example #1

15. 169 Use Case Diagram Example #2

16. 170 Use cases and Use-Case Diagrams 4 A use case is a description of a specific usage of the system 4 Use cases define the functionality requirements (features) of the system 4 A use case usually represents a user-recognizable end-to- end process rather than an individual step or activity within a process (e.g., rent a video instead of pay for video rental) 4 A use-case diagram shows any number of external actors and their connection to the use cases that the system provides 4 A use-case diagram generally includes a number of use cases 4 Use cases are often identified by: 4 identifying actors who input to or receive something from the system 4 external events that the system must respond to (e.g., purchase an airline ticket, check-out a video)

17. 171 Components of the Use Case 4 Actor (stick figure) þ a role that a user (e.g., people, other systems, and objects) plays with respect to the system 4 Use case (oval) þ significant end-to-end process 4 Stereotypes ( >) [guillemets] - provides the capability to extend the basic modeling elements of the UML to create new elements þ > - a similar chunk of behavior across more than one use case (artifact reuse) þ > - indicates that one use case is similar to another but it does more 4 Scenario (documented via an interaction diagram) þ documented step-by-step instantiation of an actual use case Valuation

18. 172 Figure 4.4 UML Use Case Diagram Notation (adapted from The Unified Modeling Language Reference Manual, p. 65) Actor A role played by a person, other system or other objects Use case A start-to-finish feature of the system Association The communication path between an actor and a use case that it participates in Extend The insertion of additional behavior into a base use case that does not know about it > Use case realization A relationship between a general use case and a more specific use case that inherits and adds features to it Include The insertion of additional behavior into a base use case that explicitly describes the insertion > Boundary The boundary of the information system TypeBrief DescriptionNotation

19. 173 Figure 4.5 UML Use Case Relationships (adapted from The Unified Modeling Language Reference Manual, p. 66) Place Order > Request Catalog Supply Customer Data Order Product Arrange Payment > Pay Cash Arrange Credit base use case extension use case parent use case child use case inclusion use cases

20. 174 QUITTING TIME