1. 1 Modeling System Requirements with Use Cases

2. 2 Why Do We Need Use Cases? Primary challenge in a system design process –ability to elicit correct and necessary system requirements from stakeholders –specify requirements in a manner understandable to users so they can be verified and validated. –SDLC models understood by designers not by users. –Leads to scope creep, schedule creep, cost overruns.

3. 3 IS Development Project Track Record Source: The Standish Group International, Inc., “Chaos: A Recipe for Success” canceled before completion Over budget, late, or without needed features

4. 4 Introduction Use-case modeling – the process of modeling a system’s functions in terms of business events, who initiated the events, and how the system responds to those events. –roots in object-oriented modeling (question1 ) –Gained popularity in non-object development environments because of its usefulness in communicating with users –Compliments traditional modeling tools Focuses on Users and their tasks Logical model

5. Role of Use Cases Describes how system reacts to an event that triggers the system –Trigger – event that causes the use case to be executed (opening the app, pushing a button) –Event-driven modeling All possible system responses are documented 5

6. 6 Use Case Process –Gather requirements from users –Prepare Use-Case Diagram –Prepare Use-Case Narratives (describes what happens in each step in the app) Deliverables: –Use-Case Diagram –Use-Case Narratives

7. 7 Advantages (question 2) Tool for capturing and tracking functional requirements System scope decomposition Easily understood user communication of functionality(primary advantage) Incremental and iterative development. Aids estimating project scope Provides testing baseline (test plans and test cases) Provides documentation baseline (user and system) Aids in data object or entity identification & db access Provides functional specifications for user and system interface design

8. 8 Definitions Use-case diagram – a diagram that depicts the interactions between the system and external systems and users. –It graphically describes who will use the system and in what ways the user expects to interact with the system. Use-case narrative – a textual description of the business even and how the user will interact with the system to accomplish the task. Use case – a behaviorally related sequence of steps (a scenario), both automated and manual, for the purpose of completing a single business task. –Description of system functions from the perspective of external users in terminology they understand.

9. 9 Sample Use-Case Diagram

10. 10 Use-Case Diagram for a Hoosier Burger’s System

11. 11 Basic Use-Case Symbols Use case – subset of the overall system functionality –Represented graphically by a horizontal ellipse with the name of the use case appearing above, below, or inside the ellipse. –Describes ONE and ONLY ONE function –Associated with ONE and ONLY ONE role that a user can play

12. 12 Basic Use Case Symbols Actor – anything that needs to interact with the system to exchange information. –Could be a human, an organization, another information system, an external device, or even time. Temporal event – a system event triggered by time. –The actor is time.

13. 13 Four Types of Actors Primary business actors Primary system actors External server actor External receiver actor Remember an Actor is a ROLE not an individual –A given individual can have multiple roles –Multiple individuals can have the same role

14. 14 Relationships Association – relationship between an actor and a use case – only one we will use Others –Extend – relationship between use cases –Includes – relationship between use cases –Depends-on – relationship between use cases

15. 15 Association Relationship Definition and modeling rules –Modeled as a solid line connecting the actor and the use case. –Association with an arrowhead touching the use case indicates that the use case was initiated by the actor. –Association lacking arrowhead indicates a receiver actor. –Associations may be bidirectional or unidirectional.

16. 16 Objectives of Use-Case Modeling Elicit and analyze enough requirements & information to prepare a model that: –Communicates what is required from a user perspective. –Is free of specific details about how the system will be built or implemented.

17. 17 Use-Case Technique Steps Steps 1.Identify business actors. 2.Identify business use cases. 3.Construct use-case model diagram. 4.Documents business requirements use-case narratives

18. 18 Identifying Business Actors Ask the following questions: –Who or what provides inputs to the system –Who or what receives output from the system –Are there interfaces with other Information Systems –Are there automatically triggered events (temporal events) –Who will maintain the information in the system Create an Actor Glossary

19. 19 Sample Actor Glossary

20. 20 Identifying Business Requirements Use Cases Identify and document critical or important use cases, often called essential use cases. Ask questions on next slide Look at DFD (good match between them) Summarize information in a Use Case Glossary

21. 21 Use Case Identification Ask the following questions: –What are the main tasks of the actor –What information does the actor need from the system –Does the system need to inform the actor of any changes or events that have occurred –Does the actor need to inform the system of any changes or events that have occurred

22. 22 Sample Use Case Glossary

23. 23 Sample Use Case Glossary Continued

24. 24 Sample Use Case Glossary Continued

25. Event Response List Prepare for your Use Case Diagram and Use Case Narrative by creating an Event Response list. –Actor –Event (or use case) –Trigger (typically an input) –Reponses (system responses) Sample on Moodle 25

26. 26 Construct Use-Case Diagram Depicts Scope and Boundaries of system Outside system boundaries – draw and label primary actors Inside system boundaries – draw and label primary use cases Show relationships between actors and use cases and between the use cases

27. 27 Guidelines for Use-Case Diagram Construction Identify system’s boundaries – scope List primary actors (stakeholders & users is good place to start) – remember actors are ROLES List goals of primary actors –Functionality required of system –Tasks (update, read, create, delete) –Communication of external conditions to system –Extraction of information from system Identify major use cases Use glossaries and event table to help you Review (iterative process)

28. 28 Sample Use Case Diagram

29. 29 Create Use-Case Narratives Document first at high level to quickly obtain an understanding of the events and magnitude of the system. Then expand to a fully-documented business requirement narrative. –Include the use case’s typical course of events and its alternate courses.

30. 30 Sample Use-Case Narrative

31. 31 continued Sample Expanded Use-Case Narrative

32. 32 continued Sample Expanded Use-Case Narrative

33. 33 Sample Expanded Use-Case Narrative

34. 34 Guidelines for Writing Use Cases Focus on Flow of Events – critical to get it right (Event table should help) Write each step in form of Subject-Verb- Direct Object –The patient contacts the office regarding an appointment Identify initiator (trigger) of the action and the receiver of the action

35. 35 Guidelines continued Write each step from an independent observer perspective Write each step at same level of abstraction (try to accomplish equal amounts in each step) Sensible set of actions KISS Iterate until comfortable

36. 36 Parts of a Use Case Think of each one as a ‘transaction’ Should have 4 parts –Primary actor triggers (sends data or request) –System ensures request/data sent is valid –System processes request/data – may result in a change to the internal state of system –System sends result of processing to an actor (results may include data)

37. 37 Expanding Use Case Narratives Choose major use case and expand it Fill in details –Identify all stakeholders –Identify all relationships Expand on the normal flow of events Identify all alternate or exception flows Confirm (typically with user)

38. 38 Expanding Use Case Narratives Simplify –Decompose into smaller use cases –Combine or merge too simple or too small use cases –Look for generic, common or general syntax –Look for ways to extend, include or generalize use cases Iterate

39. 39 Extension of Use Cases Use the basic Use Case diagram and some of the Use Case narratives to build DFDs (that is where we will go next) Identify data required by each use case – use to build data models Refer to Use Cases and data models when doing form and report design and system navigation

40. 40 Use Cases and Project Management Use-case model can drive the entire development effort. Project manager or systems analyst uses business requirements use cases to plan (estimate and schedule) the build cycles of the project. –Build cycles are scoped on the basis of the importance of the use case and the time it takes to implement the use case.