An Introduction to Use Cases

1. An Introduction to Use Cases Presented to: Albany, NY Chapter February 2, 2010 Presented by: J. Timothy Collier Information Technologies Associates, Inc.

2. Some advice from the Board • Stay away from statistics. • Studies have shown that 86.4% of all statistics mentioned in a presentation are made up, and … • The same studies have shown that 94.3% of studies mentioned on PowerPoint Slides never existed. • And this slide is no exception … February 2, 2010 2

3. Some advice from the Board • Try not to put every word you going to say on the Power Point slides. Although this eliminates the need to memorize your talk, ultimately this makes your slides crowded, wordy, and boring. You will loose your audience’s attention before you even reach the bottom of your … February 2, 2010 3

4. Some advice from the Board • …(continued) … first slide. • Also, please speel cheek your presentation to make it look more professional. • Eschew Obfuscation. • Avoid making confusing statements. February 2, 2010 4

5. Before getting to Use Cases, themselves, let’s take a half step back. February 2, 2010 5

6. What is it we’re trying to do? • Working as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. • Determine What it is the business is trying to do, write it down, give to somebody who can figure out How to do it. February 2, 2010 6

7. System Development Life Cycle Plan Define Requirements Analysis Measure Do Design Analyze Check Build Improve Test Act Control Deploy February 2, 2010 7

8. System Development Life Cycle Process Requirements Data Network Analysis WHAT Use Cases Design Build HOW Test Deploy Programs Databases Network February 2, 2010 8

9. Business Systems Other business system Other business system Your business system Other business system Other business system Other business system Other business system February 2, 2010 9

10. Business Process Start State Start Normal Stuff End End State Not so Normal Stuff February 2, 2010 10

11. Questions to answer • How to capture information about the external business systems? • How to capture information about the processes? • How to show the interrelationships between external business systems and the processes? • How to capture enough information so that the technical team can build the thing?

12. Use Cases • One way of answering all of the questions. • Has been around since 1986. • Improved communications between development teams and stakeholders. • Help teams understand the value the system must produce. • Describes how users will use the system.

13. Use Cases • Gets away from the “pile of requirements” concept. • Allows more definition of requirements than simple, declarative, “the system shall …” • Reduces ambiguity. • Attempts to capture the dynamics of a system in terms all stakeholders can easily understand.

14. Use Cases • All models are wrong, but some are useful. (Statistician George E P Box, in "Science and statistics", Journal of the American Statistical Association 71:791-799)

15. Parts of a Use Case Model February 2, 2010 15

16. Actors • An actor is a person or a thing that interacts with the process in question. • Actors have names. • Actors are external to the process. • Actors play a role. February 2, 2010 16

17. Use Case • Represent things of value the system performs for the actor. • Contains a verb. • It is not a function. • It is not a feature. • It cannot be decomposed. • Some writers feel it is a goal. • Other writers feel it is a contract with the user. February 2, 2010 17

18. Use Case Diagram • A pictorial representation of the actors, the relationships, and the use cases. • Unified Modeling Language Standards exist for how to draw them. • Tools exist for drawing them. • MS Visio • IBM Rational Software Modeler • Sybase PowerDesigner • Others • But … February 2, 2010 18

19. Use Case Diagram • The diagram is arguably the least useful part of the use case. • The words that describe the various pieces of the use case diagram are what is important. • Conceivably, valid, useful, descriptive use cases can be written without diagramming them at all. February 2, 2010 19

20. Unified Modeling Language • UML defines how to draw use case models. • UML does not define how to describe the pieces of a use case model. • Regardless of how it is that you decide to write the specifications for Use Cases, you should be able to draw that using UML.

21. Use Case Model • The complete set of actors, use cases, their relationships, and the complete descriptions are known as the use case model. February 2, 2010 21

22. Business Systems Other business system Other business system Your business system Other business system Other business system Other business system Other business system February 2, 2010 22

23. Actors • Start out with names the business recognizes.

24. Relationships Relationship

25. Relationships (Bittner, & Spence, 2003)

26. Actors • It may be discovered that several actors share common behaviors. • Generalize the actors.

27. Actors Generalization

28. Actors

29. Actors

30. Includes Relationship • A Use Case Include relationship says that the behavior of another use case is contained in this use case. • Implies the behavior of the included use case is inserted into the behavior of the including use case.

31. Includes Relationship

32. Extends Relationship • This relationship specifies that the behavior of a use case may be extended by the behavior of another use case. • Unlike a Use Case Include, the Use Case may or may not be extended by another use case. • The extending use case may not be able to exist by itself; it provides a degree of modularity to the extended use case.

33. Extends Relationship

34. How to describe the use case model. • Actors • Stakeholder . • Primary or Secondary Actor. • System under design. • Other systems. • Internal actors. • Roles versus Actors. • Description. • Responsibilities. • Goals and objectives the actor has for the system.

35. Use Case Description • Triggers. • Activity Steps. • Extension Points. • Exceptions. • Preconditions. • Post Conditions. • Processing Rules. Process Start State Start Normal Stuff End End State Not so Normal Stuff

36. Use Case Description • Triggers. • The arrival of an event into the use case that causes execution of the use case to begin. • Activity Steps. • Contains a text description of the normal sequence of actions associated with a use case. • Number the steps to identify them. • Example: 1. open a file, 2. give a new registration number and 3. write down medical treatment would be action steps for a use case called 'register patient' in a hospital. • Extension Points. • Contains a text description of actions that extend the normal sequence of actions. It opens up the use case to the possibility of extension (extend). Usually introduced with an if ....then. • The step causing the extension is identified. • Example: 2. if the patient already has a registration number, then retrieve his personal file. • Exceptions. • Signal raised in response to behavioral faults during system execution. • Example. 3. Doctor fails to sign medical treatment form. Reject treatment • Preconditions • A constraint that must be true when an operation is invoked. • Post Conditions. • A constraint that must be true at the completion of an operation. • Processing Rule • A statement that guides how the use case is processed. It will many times consist of If … then statements. • Example: If order amount > $1,000,000 then Set Discount to 15%, else, No discount is applied.

37. System Development Life Cycle Process Data Network WHAT Use Cases HOW Programs Databases Network Process WHAT Business Use Case HOW Programs Requirements Requirements Analysis Analysis Design Design Build Build Test Test Deploy Deploy February 2, 2010 37

38. Different Levels of Use Cases • High Level to Low Level • To move from high level to low level, ask “How?” • To move from low level to high level, ask “Why?”

39. Functional Use Cases • Start with the Business Use Cases • Ask the question, “How do I realize this use case?” • The Actor will now have relationships with several, lower-level, use cases. • Not really decomposition.

40. Functional Use Cases • Everything that applies to business use cases applies to Functional Use Cases. • The Activity Steps are much more detailed. • Processing rules play a larger role.

41. Functional Use Cases • While the business use case might be: • Get Cash From Bank. • The functional use cases might be: • Locate an ATM. • Identify ATM User. • Verify account balance sufficient. • Extract money from safe drawers. • Assemble withdrawal. • Disburse withdrawal. • Update Account balance.

42. UML Stuff. • Activity Diagrams • Sequence Diagrams • Collaboration Diagrams

43. Functional Use Cases

44. Group Functional Use Cases

45. Functional Use Cases

46. Functional Use Cases

47. More Requirements • Robustness Models. • Identifies boundary classes. • Identifies control classes. • Identifies data access classes. • User Interface Design. • Based on the boundary classes discovered during Robustness Modeling. • Other design considerations.

48. System Development Life Cycle Process Requirements Analysis WHAT Business Use Case Design Functional Use Case Build UI Other Requirements Use Cases HOW Test Component Creation Deploy Unit, Integration, System, User Acceptance Testing Programs February 2, 2010 48

49. What How After the Requirements are defined, then what? Requirements Analysis Design Module Design UAT Plan Quality Metrics Sys Test Plan Int Test Plan User Acceptance Test System Test Integration Test Code / Unit Test

50. Agile Development • Customer satisfaction by rapid, continuous delivery of useful software • Working software is delivered frequently (weeks rather than months) • Working software is the principal measure of progress • Even late changes in requirements are welcomed • Close, daily cooperation between business people and developers • Face-to-face conversation is the best form of communication (co-location) • Projects are built around motivated individuals, who should be trusted • Continuous attention to technical excellence and good design • Simplicity • Self-organizing teams • Regular adaptation to changing circumstances