Conversation Form

1
Conversation Form

• One path through a use case that emphasizes
  interactions between an actor and the system
• Can show optional and repeated actions
• Each action can be described by one or more
  substeps
• May describe
• Actor actions
• System responsibilities and actions

2
A ConversationMake A Payment - General Flow
3
Maintain a Consistent Level of Detail

• Do not mix intent, action and detail in the same
  use case
• Write at a level that seems appropriate to your
  readers
• This typically means describing actions, not
  minute details
• Description within a use case should be at the
  same level of abstraction ( one)

4
Maintain a Consistent Level of Detail
5
Choosing Between Conversations and Scenarios

• Use a scenario when
• a simple list of actions is sufficient
• actor-system interactions arent interesting
• Use a conversation when
• there are many interactions and you want to
  describe them
• you want to show more detailed system responses
• you want to separate the roles of actor and
  system

6
Dont Embed Alternatives
7
Leave Out Information Formatsand Validation Rules
8
Dont Mention Objects inSystem Actions
9
Leave Out Presentation Details

• Widget details described
• Display note in a read/write text field
• From account in a drop-down list box
• Amount in a currency field
• Fixed
• Display payment template editable fields (note,
  from account, amount)
• Reference screens used by a conversation
• Screens See Login Page

10
Writing a Conversation
11
Showing More Detail

• Describe what is done to accomplish the use case
• Basic functionality
• Variations
• Exceptional conditions
• Things that must be true before starting the use
  case
• Things that must be true on exiting the use case

12
Keep Rules in a Policies Section
13
Use a Table for Complex Rules
14
Document Global Requirementsin a Central Place

• Distinguish between system-wide requirements and
  those than span several use cases
• Example System must run 7 by 24
• Example Account information should be encrypted
  and transmitted over a secure connection
• Reference those requirements that are satisfied
  by the use case below the use case body

15
Document Hints and Ideas

• Design Notes
• Errors and warnings about registration
  information contents should be collected and
  returned to the user in a detailed message rather
  than stopping at the first detectable error.
• Payments should be shown in time order, with the
  current date first.
• The user should not see payments that he should
  have visibility of. Prevent a user from seeing a
  payment from secret accounts that he should be
  unaware of.
• Add design notes as they occur to you

16
Alternative Paths

• For each significant action
• Is there another significant way to accomplish it
  that could be taken at this point? (Variation)
• Is there something that could go wrong?
  (Exception)

17
Choices for Describing Variations

• Add textual descriptions of variations in the
  variations section of the use case template,
  which may reference an additional use case or
• Modify the body of the use case to show the
  variation, especially when you want to emphasis
  the variation, which may reference an additional
  use case or
• Draw an activity diagram that shows decision
  points, alternate paths, and parallel activities

18
Choices for Describing Exceptions

• Add textual descriptions of exception in the
  exceptions section of the use case template,
  which may reference an additional use case or
• Draw an activity diagram that shows decision
  points, alternate paths, and parallel activities

19
Describing Exceptions MakesRequirements More
Complete
20
Exceptions Addedto Place An Order
21
When to Create a New Use Case to Describe An
Alternative

• Write another...
• when an alternative appears complex
• when an alternative is important and you want to
  emphasize it
• Document simpler alternatives in the
  supplementary part
• Document more complex ones as separate use cases
• Rewrite and reorganize for clarity!
• Give new use cases specific names that identify
  specific conditions

22
Alternatives inRegistration w/ Auto Activation
23
Keep Steps at Roughly theSame Level of Detail
24
Describe Exceptions at a High-Level
25
Documenting Exceptions

• Name the exception below the use case body
• Tell what step it relates to
• Tag an exception when it is unrecoverable.
  Describe what happens after it is detected, or
• When an exception is recoverable, describe the
  steps the actor or system takes to recover
• Document what happens
• Choose an appropriate form
• Briefly describe what happens, or
• Refer to another use case describing the
  exception handling

26
Documenting Variations

• Decide whether the variation should be described
  within the use case body or if it should be
  referenced below the use case body (consider
  emphasis)
• Decide whether it needs a separate description
• Document what happens. Either
• Briefly describe the variation, or
• Refer to a new scenario or conversation that
  describes the variation in detail

27
Use Cases Can Be Related
28
Use Case Levels

• Use cases can be written at differing levels of
  abstraction and scope. Each serves a purpose
• Summary General descriptions and sweeping
  overviews of system functionality or business
  processes
• Core Task-related descriptions of users and how
  they interact with the system descriptions of a
  specific business process
• Supporting Descriptions of lower-level
  activities used to complete subparts of a core
  use case
• InternalDescriptions of the behaviors of and
  interactions between internal system components

29
Use Case Model ExampleClassic Business Functions
30
Use Case Model ExampleAd hoc information
query/data warehousing
31
Use Case Model ExampleSoftware application
development environment
32
Emphasize Whats ImportantWithin a Use Case
33
Whats Emphasized?
34
Whats Emphasized?
35
Emphasize Whats ImportantWithin a Use Case Model

• Place first those use cases you wish to emphasize
• Choose the form of use case descriptions
  according to what you want to emphasize
• A conversation emphasize the dialog between
  system and actor
• A narrative emphasizes the high points of a
  story, not the details
• Repeat and restate things to make them stand out
• Choose a template that doesnt inadvertently
  emphasizes the wrong things

36
A Use Case Writing Process
37
Organize Your Use Case Descriptions

• Choose an organization for your use cases
• by level (summary first, core next, supporting,
  then internal ones last)
• by actor
• by type of task
• arranged in a workflow

38
Use Case Model Review Checklist

• Check for internal consistency between use cases
• Identify central use cases
• Identify unmet or externally satisfied
  preconditions
• Review the actors view for completeness
• Review the handling of exceptions
• Document use case dependencies, extensions and
  includes relationships
• Document external dependencies

39
Example Register for a Course

1. Display a blank schedule.
2. Display a list of all classes in the following
   way The left window lists all the courses in the
   system in alphabetical order. The lower window
   displays the times the highlighted course is
   available. The third window shows all the courses
   currently in the schedule.
3. Do
4. Student clicks on a course.
5. Update the lower window to show the times the
   course is available.
6. Student clicks on a course time and then clicks
   on the "Add Course" button.

40
Example Register for a Course

1. Check if the Student has the necessary
   prerequisites and that the course offering is
   open.
2. If the course is open and the Student has the
   necessary prerequisites, add the Student to the
   course. Display the updated schedule showing the
   new course. If no, put up a message, "You are
   missing the prerequisites. Choose another
   course."
3. Mark the course offering as "enrolled" in the
   schedule.
4. End do when the Student clicks on "Save
   Schedule."
5. Save the schedule and return to the main
   selection screen.

41
Improved Version

1. Student requests a new schedule.
2. The system prepares a blank schedule form and
   pulls in a list of open and available courses
   from the Course Catalog System.
3. Student selects primary and alternate courses
   from the available offerings.
4. For each course, the system verifies that the
   Student has the necessary prerequisites and adds
   the Student to the course, marking the Student as
   "enrolled" in that course in the schedule.
5. When the Student indicates the schedule is
   complete, the system saves the schedule.