1. Contents What is “RUP?” What are Requirement Types
What is a “Use Case”?
How to Write a Use Case
Use Case Example
How to Diagram a Use Case
Activity Diagram Example

2. What is RUP?
The Rational Unified Process (RUP) is a process for building, deploying, and maintaining software
Marketed by Rational, now owned by IBM
A widely adopted software development method for building object-oriented systems

3. RUP is… Driven by the “Use-Case”:
a conceptual framework to organize requirements specification, analysis, design, development, and testing
Iterative and Incremental
Divides a very large undertaking into small “mini-projects”; (iteration) through common workflows, prioritized by risk, that incrementally add to the scope of the product
Architecture-Centric
the early development of the software architecture provides
drawings and models to visualize the form and structure of the system

4. Stages of RUP

5. Requirement Types Organizes requirements into specific groups.
There can be many requirement types (needs, features, use cases, business rules, etc…)

6. Needs Needs are business objectives that the system must meet.
Example:
The system must be external to bank facility.
The system must be secure.
The system must be reliable.

7. Features
Features are requirements that specify specific functionality the system must perform.
Example:
The ability to accept ATM cards.
The ability to enter PIN for ATM cards.
The ability to print receipts.

8. Use Case The specification of a system function
From the user’s perspective
Focused on the value to be obtained or goal to be accomplished
Defined by the interaction that the user has with the system in performing the function
Detailed sequence of the user’s actions and the system’s responses

9. Use Case (cont.)
The set of scenarios that define how the user interacts with the system to accomplish the function, both main scenarios and alternate scenarios, make up a Use Case
The set of use cases that specify the full functionality of a system make up the Use Case Model

10. How requirements trace together
Requirements trace together based off their level of detail.
Needs
Features
Use Cases
Less Detail
More Detail
Must be
secure.
Ability to enter
PIN
through the
ATM.
Obtain cash
from ATM
Ex:

11. POP QUIZ What does the acronym ‘RUP’ represent?
What is a Need? Provide an example.
What is a Feature? Provide an example.
What is a Use Case?
What is the term for how Needs, Features, and Use Cases relate?

12. Using the Use Case Specification
The Use Case specification has evolved into two distinct uses:
The original intent – a System Use Case (or more typically just “Use Case”)
A higher-level modeling technique of an overall Business Process – a Business Use Case

13. How To Write a Use Case 1. Focus on the User Technical Label: “Actor”
Represents a “type” of user or user “role”
Ask “What HAT would the user wear to perform this task?”
The “user” may not be a person; it may be an external system that “interacts” with the system being specified
Bank
ATM Customer

14. How To Write a Use Case 2. Focus on a basic business process:
a task performed by one person in one place at one time,
in response to a business event,
which adds measurable business value and
Produces a ‘success guarantee’ (post-condition).

15. Use Case How To’s Outline for a Use Case Specification: Use-Case Name
Description
Actor
Preconditions
Triggering Events
Basic Flow (RUP’s “Happy Path”)
Requester: initiate a request.
Approver: check money in budget, check price of goods, complete request for submission. …
Alternative Flows
1a. Requester does not know price: Leave blank and continue.
Post Conditions (Success Guarantees)
Inclusion/Extension Points
Functional Capabilities
Business Rules
Supplemental Requirements
Outline for a Use Case Specification:

16. Use Case How-To’s Filling in the details:
Name – The name should reflect the primary goal to be achieved by the use case, like “Obtain Cash from ATM”.
Description – Documents the purpose of the use case. The purpose should be decomposed into the names of the flows included in the use case document.

17. Use Case How To’s
Customer
Filling in the details:
Actors (users) – Actors having primary portions of system interaction
Use Case Diagram – Depicts the relationship between the actors and use case OR use cases.

18. Sample Use Case Notation
Use Case Diagram
Print Receipt
Obtain Cash from ATM
Customer
A system is a compilation of many use cases.

19. Use Case How To’s Filling in the details:
Activity Diagram (optional) – picture of the steps that an actor takes to accomplish a work activity. (Section at end of this lesson)
Preconditions – conditions which must be true before the system should allow the use case to start
Example: “The customer must have an ATM, Debit, or Credit Card.”
Triggering Events – events which get the use case started.
Example: Customer swipes ATM card.

20. Use Case How To’s Filling in the details:
Basic Flow – a sequence of action steps that proceed towards achieving the goal
Three types of action steps:
An interaction between two actors (including the system), like “customer enters address”
A validation step, like “system validates PIN”
An internal change, like “system deducts from balance”
Alternative Flows – define particular conditions that can cause a branch in behavior and resulting action steps

21. Use Case How To’s
Filling in the details:
Post-Condition (Success Guarantee) – a condition that should be true when the main success scenario is completed (what happens after the use case is finished)
Example: “The customer receives cash.“

22. Use Case How To’s Filling in the details:
Inclusion/Extention Points – Narrative listing of the use cases related to the current use case.
Business Rules – ‘IF…,THEN’ statements that state specific conditions that must be satisfied to complete a use case step.
Example: If entering a ‘Date of Birth’, then date cannot be a future date.
Supplemental Requirements – any other requirements that will be applied globally through the system.
Example: When user cancels a step, system returns user to home page.

23. POP QUIZ What are the 2 focus points of a Use Case?
Can you name two points from each Use Case focus?
What is the outline of a use case? Define each section.

24. Let’s Develop the ‘Obtain Cash from ATM’ Use Case
Case Study
Let’s Develop the ‘Obtain Cash from ATM’ Use Case

25. Use Case Example Name: Obtain Cash from an ATM Actor: Customer
Use Case Diagram: (on separate slide)
Activity Diagram: (on separate slide)
Triggering Events: Customer inserts card.
Precondition: The customer must have an ATM, Debit, or Credit Card.

26. Use Case Example Basic Flow
The user swipes his card through the card reader on the ATM.
The ATM prompts the user to enter his PIN number.
The user enters his PIN number.
The ATM validates that the PIN number entered is correct.
The user selects the option to retrieve money.
The ATM prompts the user to enter the amount to retrieve.
The user enters the amount to retrieve.
The ATM validates that the user has sufficient funds available to retrieve.
The ATM dispenses the funds.
The ATM asks the user if he would like a receipt.
The ATM prints a receipt.
Use case ends.

27. Use Case Example Alternate Scenarios:
4a. If the card number and PIN do not match, the ATM presents an error message and returns to step 3.
8a. If the customer does not have sufficient funds, the ATM presents an error message and returns to step 7.
10a. If the customer does not want a receipt, skip to step 12.

28. Use Case Example
Post Conditions – the customer has successfully retrieved money from the ATM.
Inclusion/Extension Points – N/A
Functional Capabilities – Ability to use ATM or credit card. Ability to enter PIN.
Business Rules – If receipt printer is out of paper and ATM is on physical bank institution site, the customer must consult teller.
Supplemental Requirements – the customer may cancel their transaction at any time. The ATM displays home page upon cancellation of transaction.

29. Example Register Use Case

30. Brief Description
This business use case will allow a user to add a “person record” to the Master Person Index (MPI). The person can identified to the health department from various sources including self-referral, a referral from a medical provider, a contact investigation, targeted testing, etc. The person may need treatment, be part of a targeted testing, be part of a contact investigation, etc.

31. Actors
Health Care Worker (HCW)
Health Department Staff

32. Pre-Conditions
The user must have proper security rights to enter a patient in the system.
System is available and operable
The user is notified that a person requires TB services and the person satisfies jurisdiction criteria for assessment and/or treatment.
The person requires TB assessment and/or treatment needs to be added into the MPI.
The person with special needs is provided assistance that may include translation services, transportation, etc.

33. Trigger
The MPI search does not retrieve a person record that matches the search criteria and the person must added to the MPI.

34. Basic Flow The user searches the MPI. User selects register option
1.1 System displays zero (0) search results indicating that the person does not exist in the MPI.
User selects register option
System displays register screen
3.1 User enters basic patient information in the register screen. Basic information may include last name, first name, sex, date of birth, address and if a translator is needed.
User enters the reason for adding the person to the MPI which may have the following values: suspect case, confirmed case, contact investigation, targeted testing, etc.
User selects the save option
System saves registration in the MPI
End Use Case

35. Alternate Flow 1
Client resides outside health department jurisdiction.
The original health department sends a notification (via secure , phone call, fax, or mail) to the appropriate health department. From Step 3.1:
User enters associated system identifiers
System links patient with other system identifiers as described in UC.110.MPI Search.
Use case resumes at step 5.
Use case ends.

36. Post conditions
A person record is created in the MPI.

37. Optional Use Case Section
Let’s Discuss How to Develop an Activity Diagram

38. Activity Diagram: How to Diagram a Use Case
The action steps within a Use Case can be modeled in a Unified Modeling Language (UML) Activity Diagram
We will normally use an Activity Diagram to diagram a Business Use Case (not a System Use Case)

39. Activity Diagram: Definition
A picture of the steps that an actor takes to accomplish a work activity.
Optional. (Optimal use is to pictorally represent use cases more easily transition into use case narrative.)
Can be developed prior to use case, in parallel, or after use case has been developed.

40. Activity Diagram Notation: Activities
Activities are the ‘steps’ of the process.
User swipes card
through ATM card
reader
ATM prompts for PIN
Users enters PIN

41. Activity Diagram Notation: Decision Points
A Decision Point is the place where a question is asked. The next activity is determined by the answer.
Funds Available?
Dispense Funds
Positive
Negative
Notify User of Insufficient Funds

42. Activity Diagram Notation: Actors
Actors are people or systems that initiate a use case.
Bank
Customer

43. Activity Diagram Notation: Synch Bars
Synch Bars represent activities that can be done in parallel – there are no requirements for them to be performed in sequence.
Get Balance
Change PIN
Get Stamps
Transfer Funds

44. Activity Diagram Notation: Synch Bars
The brackets ‘[xx]’ represent activities that are optional. In this example, the user must enter the child and provider information but may choose not to enter the address and/or laboratory information.
[Change PIN}
[Get Stamps]
Get Balance
Change PIN
Get Stamps
Transfer Funds

45. Activity Diagram Notation: Additional Notations
Start Icon Indicates the start of the activity.
Stop Icon Indicates the end of the activity flow.
Send Signal Indicates that the path leaves the current activity diagram and resumes in another activity diagram. This would indicate leaving the current flow and resuming in the Environmental Case Management flow.

46. Let’s Develop the Activity Diagram for ‘Obtain Cash from ATM Use Case’
Case Study
Let’s Develop the Activity Diagram for ‘Obtain Cash from ATM Use Case’

48. Summary Rational Unified Modeling (RUP) Needs Features
Iterations
Needs
Business Requirements
Features
Requirements the system must meet
Use Cases (user requirements)
Functional Requirements
Activity Diagram