1. Scenario & use cases

2. scenario Definition Note on terminology
A scenario is scene that illustrates some interaction with a proposed system.
A scenario is a tool used during requirements analysis to describe a specific use of a proposed system. Scenarios capture the system, as viewed from the outside, e.g., by a user, using specific examples.
Note on terminology
Some authors restrict the word "scenario" to refer to a user's total interaction with the system.
Other authors use the word "scenario" to refer to parts of the interaction.
In this course, the term is used with both meanings.

3. Describing a Scenario
At the very least, the description should include
A statement of the purpose of the scenario
The individual user or transaction that is being followed through the scenario
Assumptions about equipment or software
The steps of the scenario

4. Developing a Scenario with a Client
Example of how to develop a scenario with a client
The requirements are being developed for a system that will enable university students to take exams online from their own rooms using a web browser.
Create a scenario for how a typical student interacts with the system.
In the next few slides, the questions in blue are typical of the questions to ask the client while developing the scenario

5. Developing a Scenario with a Client: a Typical Student
Purpose: Scenario that describes the use of an online Exam system by a representative student Individual: [Who is a typical student?] Student A, senior at Cornell, major in computer science. [Where can the student be located? Do other universities differ?] Equipment: Any computer with a supported browser. [Is there a list of supported browsers? Are there any network restrictions?]

6. Developing a Scenario with a Client (continued)
Student A authenticates. [How does a Cornell student authenticate?]
Student A starts browser and types URL of Exam system. [How does the student know the URL?]
Exam system displays list of options. [Is the list tailored to the individual user?]
Student A selects CS 1234 Exam 1.
A list of questions is displayed, each marked to indicate whether completed or not. [Can the ques7ons be answered in any order?]
Student A selects a question and chooses whether to submit a new answer or edit a previous answer. [Is it always possible to edit a previous answer? Are there other options?]
[What types of question are there: text, multiple choice, etc.?] The first question requires a written answer. Student A is submitting a new answer. The student has a choice whether to type the solution into the browser or to attach a separate file. Student A decides to attach a file. [What types of file are accepted?]

7. Developing a Scenario with a Client (continued)
For the second question, the student chooses to edit a previous answer. Student A chooses to delete a solution previously typed into the browser, and to replace it with an attached file. [Can the student edit a previous answer, or must it always be replaced with a new answer?]
As an alternative to completing the entire exam in a single session, Student A decides to saves the completed questions work to continue later. [Is this always permitted?]
Student A logs off
Later Student A log in, finishes the exam, submits the answers, and logs out. [Is this process any different from the ini7al work on this exam?]
The Student A has now completed the exam. The student selects an option that submits the exam to the grading system. [What if the student has not attempted every question? Is the grader notified?]
Student A now wishes to change a solution. The system does not permit changes once the solution has been submitted. [Can the student still see the solutions?]
Later Student A logins in to check the grades. [When are grades made available? How does the student know?]
Student A requests a regrade.[What are the policies? What are the procedures?]

8. Scenarios for Analyzing Special Requirements
Scenarios are very useful for analyzing special requirements.
Examples
Questioners
Reversals. In a financial system, a transaction is credited to the wrong account. What sequence of steps are used to reverse the transaction?
Errors. A mail order company has several copies of its inventory database. What happens if they become inconsistent?
Malfeasance. In a voting system, a voter has houses in two cities. What happens if he attempts to vote in both of them?
Gamification

9. Scenarios for Analyzing Special Requirements (continued)
Scenarios for error recovery Murphy's Law: "If anything can go wrong, it will ". Create a scenario for everything that can go wrong and how the system is expected to handle it.
Questioners
Gamification

10. Modeling Scenarios as Use Cases
Models
Scenarios are useful in discussing a proposed system with a client, but requirements need to be made more precise before a system is fully understood.
This is the purpose of requirements modeling.
A use case provides such a model.

11. Use case A requirements analysis concept
A case of a use of the system/product
Describes The system’s actions from a point of view of a user
Tells a story
Specifies one of aspect the behavior of a system, without specifying the structure of the system .
Is oriented toward satisfying a user's goal
A sequence of events involving
Interactions of a user with the system

12. How do we describe use cases?1
Textual or tabular descriptions 2
User stories 3
Diagrams

13. What is an Actor? Include all user roles that interact with the system
Include system components only if they responsible for initiating/triggering a use case.
primary - a user whose goals are fulfilled by the system
supporting - provides a service (e.g., info) to the system
offstage - has an interest in the behavior but is not primary or supporting, e.g., government
For example, a timer that triggers sending of an reminder
importance: define user goals
importance: clarify external interfaces and protocols
importance: ensure all interests (even subtle) are identified and satisfied

14. Finding Actors External objects that produce/consume data:
Our Vision
Buying and selling a product is the best that includes advertising lorem ipsum service.
External objects that produce/consume data:
Must serve as sources and destinations for data
Must be external to the system

15. Finding Actors [continued]
Ask the following questions 01
Who are the system’s primary users? 02
Who requires system support for daily tasks? 03
Who are the system’s secondary users?
© Copyright Showeet.com 04
What hardware does the system handle? 05
Which other (if any) systems interact with the system in question? 06
Do any entities interacting with the system perform multiple roles as actors? 07
Which other entities (human or otherwise) might have an interest in the system's output?

16. What is a user story? An abbreviated description of a use case
Used in agile development
As a <type of user>،
I want <some behavior from the system>
So that <some value is achievid>
Answers 3 questions:
WHO?
DOES WHAT?
AND WHY?

17. Use Case Diagrams A picture Diagrams are not essential
They are helpful in giving an overview, but only secondary in importance to the textual description
They do not capture the full information of the actual use cases
In contrast, text is essential
describes how actors relate to use cases
and use cases relate to one another

18. Use Case Diagram Objective
Built in early stages of development
 Purpose
Specify the context of a system
Capture the requirements of a system
Validate a systems architecture
Drive implementation and generate test cases
Developed by analysts and domain experts

19. How do use case diagrams fit in?
This applies also to use case descriptions.
Diagram reproduced from

20. Example Use-Case Diagram
A standard form of use case diagram is defined in the Unified Modeling Language.

21. Elements of use case diagram: Actor
Actor is someone interacting with use case (system function). Named by noun.
Similar to the concept of user, but a user can play different roles; (example: a prof. can be instructor and researcher – plays 2 roles with two systems)
Actor triggers use case.
Actor has responsibility toward the system (inputs), and Actor have expectations from the system (outputs).

22. Elements of use case diagram: Use Case
Do something
User Goal= Use Case
User/actor
look up time availability
Create new order
Update order
Older clerk
Record order fulfillment
Record back order
Shipping clerk
Create special promotion
Produce catalog report
Merchandising manager
System function (process – automated or manual).
Named by verb.
Each Actor must be linked to a use case, while some use cases may not be linked to actors.

23. Elements of use case diagram: Other details
Connection between Actor and Use Case
Boundary of system
Include relationship between Use Cases (one UC must call another; e.g., Login UC includes User Authentication UC)
Extend relationship between Use Cases (one UC calls Another under certain condition; think of if-then decision points)

24. Linking Use Cases 1 2 3 4 Extend relationships
Association relationships 2
Generalization relationships
One element (child) "is based on" another element (parent)
Include relationships 3
One use case (base) includes the functionality of another (inclusion case)
Supports re-use of functionality 4
Extend relationships
One use case (extension) extends the behavior of another (base)

25. Use Case Levels

26. Generalization
The child use case inherits the behavior and meaning of the parent use case.
The child may add to or override the behavior of its parent.

27. More about Generalization

28. Generalization Example
The actor Order Registry Clerk can instantiate the general use case Place Order.
Place Order can also be specialized by the use cases Phone Order or Internet Order.

29. Generalization Example

30. Include
The base use case explicitly incorporates the behavior of another use case at a location specified in the base.
The included use case never stands alone. It only occurs as a part of some larger base that includes it.

31. More about Generalization
Enables us to avoid describing the same flow of events several times by putting the common behavior in a use case of its own.

32. Include relationship
Include relationship – a standard case linked to a mandatory use case.
Example: to Authorize Car Loan (standard use case), a clerk must run Check Client’s Credit History (include use case).
The standard UC includes the mandatory UC (use the verb to figure direction arrow)
Standard use case can NOT execute without the include case tight coupling

33. Reading use case diagram with Include relationship

34. Include Example

35. Extend
The base use case implicitly incorporates the behavior of another use case at certain points called extension points.
The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case.

36. More about Extend
Enables to model optional behavior or branching under conditions.

37. Extend relationship
Extend relationship – linking an optional use case to a standard use case.
Example: Register Course (standard use case) may have Register for Special Class (extend use case) – class for non-standard students, in unusual time, with special topics, requiring extra fees…).
The optional UC extends the standard UC
Standard use case can execute without the extend case loose coupling.
Reading extend relationship

38. Extend Example #1

39. Extend Example #2

40. Extend Example #2 cont

41. Relationships between Use Cases and Actors
Actors may be connected to use cases by associations, indicating that the actor and the use case communicate with one another using messages

42. Example #1

43. Example #2 Altered State University (ASU) Registration System
Our Team
Professors indicate which courses they will teach on-line.
Awards
A course catalog can be printed
Our Maps
Allow students to select on-line four courses for upcoming semester.
Infographics
No course may have more than 10 students or less than 3 students.
Portfolio
When the registration is completed, the system sends information to the billing system.
Portfolio
Professors can obtain course rosters on-line.
Portfolio
Students can add or drop classes on-line.

44. Example #2 cont
Altered State University (ASU) Registration System

45. How to create use case diagram
List main system functions (use cases) in a column:
Draw ovals around the function labels
Draw system boundary
Draw actors and connect them with use cases (if more intuitive, this can be done as step 2)
Specify include and extend relationships between use cases (yes, at the end – not before, as this may pull you into process thinking, which does not apply in UC diagramming)
think of business events demanding system’s response
users’ goals/needs to be accomplished via the system
Create, Read, Update, Delete (CRUD) data tasks
Naming use cases – user’s needs usually can be translated in data tasks

46. Use-Case Diagrams: Example
Begin with a Use Case!
A user placing an order with a sales company might follow these steps :
Then translate Use Case sequence into Diagram
Browse catalog and select items.
Call sales representative.
Supply shipping information.
Supply payment information.
Receive conformation number from salesperson.

47. Use-Case Diagrams: Example [continued]
The salesperson could also be included in this use case diagram because the salesperson is also interacting with the ordering system.

48. Use-Case Diagram Case Study
Vending Machine
After client interview the following system scenarios were identified:
On the basis of these scenarios, the following three actors can be identified: Customer; Supplier; Collector (in this case Collector=Supplier)
A customer buys a product
The supplier restocks the machine
The supplier collects money from the machine

49. Use-Case Diagram Case Study [continued]

50. Use-Case Diagram Case Study [continued]
Introducing annotations (notes) and constraints.

51. Example

52. Cell Company System

53. restaurant

54. Railway

55. سیستم مدیریت سفارش

56. دیجی کالا

57. دیجی کالا

58. دیجی کالا

59. دیجی کالا