CTOMS UseCase

Use Cases
for
<Project>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>
Revision History
Name Date Reason For Changes Version
Copyright © 2013 by Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
Use Cases for <Project> Page 2
Use Case ID and Name

Give each use case a unique integer sequence number identifier. State a concise name for the use case that
indicates the value the use case would provide to some user. Begin with an action verb, followed by an
object.
Author and Date Created

Enter the name of the person who initially wrote this use case and the date it was written.
Primary and Secondary Actors

An actor is a person or other entity external to the software system being specified who interacts with the
system and performs use cases to accomplish tasks. Different actors often correspond to different user
classes, or roles, identified from the customer community that will use the product. Name the primary
actor that will be initiating this use case and any other secondary actors who will participate in completing
execution of the use case.
Trigger
Identify the business event, system event, or user action that initiates the use case. This trigger alerts the
system that it should begin testing the preconditions for the use case so it can judge whether to proceed
with execution.
Description
Provide a brief description of the reason for and outcome of this use case, or a high-level description of
the sequence of actions and the outcome of executing the use case.
Preconditions
List any activities that must take place, or any conditions that must be true, before the use case can be
started. The system must be able to test each precondition. Number each precondition. Example: PRE-1:
User’s identity has been authenticated.
Postconditions
Describe the state of the system at the successful conclusion of the use case execution. Label each
postcondition in the form POST-X, where X is a sequence number. Example: POST-1: Price of item in
the database has been updated with the new value.
Normal Flow
Provide a description of the user actions and corresponding system responses that will take place during
execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to
accomplishing the goal stated in the use case name and description. Show a numbered list of actions
performed by the actor, alternating with responses provided by the system. The normal flow is numbered
“X.0”, where “X” is the Use Case ID.
Alternative Flows
Document other successful usage scenarios that can take place within this use case. State the alternative
flow, and describe any differences in the sequence of steps that take place. Number each alternative flow
in the form “X.Y”, where “X” is the Use Case ID and Y is a sequence number for the alternative flow.
For example, “5.3” would indicate the third alternative flow for use case number 5. Indicate where each
alternative flow would branch off from the normal flow, and if pertinent, where it would rejoin the normal
flow.
Exceptions
Describe any anticipated error conditions that could occur during execution of the use case and how the
system is to respond to those conditions. Number each alternative flow in the form “X.Y.EZ”, where “X”
is the Use Case ID, Y indicates the normal (0) or alternative (>0) flow during which this exception could
take place, “E” indicates an exception, and “Z” is a sequence number for the exceptions. For example
“5.0.E2” would indicate the second exception for the normal flow for use case number 5. Indicate where
in the normal (or an alternative) flow each exception could occur.
Priority
Indicate the relative priority of implementing the functionality required to allow this use case to be
executed. Use the same priority scheme as that used for the functional requirements.
Frequency of Use
Estimate the number of times this use case will be performed per some appropriate unit of time. This
gives an early indicator of throughput, concurrent usage loads, and transaction capacity.
Business Rules
List any business rules that influence this use case. Don’t include the business rule text here, just its
identifier so the reader can find it in another repository when needed.
Other Information
Identify any additional requirements, such as quality attributes, for the use case that may need to be
addressed during design or implementation. Also list any associated functional requirements that aren’t a
direct part of the use case flows but which a developer needs to know about. Describe what should
happen if the use case execution fails for some unanticipated or systemic reason (e.g., loss of network
connectivity, timeout). If the use case results in a durable state change in a database or the outside world,
state whether the change is rolled back, completed correctly, partially completed with a known state, or
left in an undetermined state as a result of the exception.
Assumptions
List any assumptions that were made regarding this use case or how it might execute.
Use Case List
Primary Actor Use Cases
ID and Name: Order a Ticket

Created By: Date Created: 10/5/19
Primary Actor: Buyer Secondary Actors: Trips list, Tickets list.
Description: A Buyer accesses the Coach Ticket Ordering System from the corporate intranet or
from home, views the list of available trips, selects trips specific coach if desired,
and choose seat(s) to order ticket.
Trigger: A buyer clicks on “buy ticket” button
Preconditions: PRE-1. Buyer is logged in successfully into CTOMS.
Postconditions: POST-1. Ticket order is stored in CTOMS with a status of “Accepted”.
POST-2. Inventory of available tickets is updated to reflect items in this order.
POST-3. Remaining capacity for the available tickets and trips are updated.
Normal Flow: 1.0 Order Tickets
1. Buyer request to view the list of available coach trips.
2. CTOMS displays available trips and seats.
3. Buyer chooses 1 or more seats from the displayed list.
4. CTOMS displays the price of the chosen items (both individual and total price
including all taxes)
5. Buyer can either confirm the order (continue normal flow) or request to
modify ticket order (return to step 3).
6. Buyer specifies payment method (VISA or PayPal).
7. CTOMS confirms acceptance of the order.
8. CTOMS sends confirmation and order information email to buyers.
9. CTOMS stores order, update available trips and tickets.
Alternative Flows:
Exceptions:
Priority: High
Frequency of Use: Approximately 10000 users, average of one usage per 2 months. Peak usage load
for this use case is between 9:00 A.M. and 10:00 A.M. local time.
Business Rules: BR-1 Each account can only buy maximum 6 tickets.
BR-2 Can only buy tickets before starting day.
Other Information: 1. Buyer shall be able to cancel the ticket ordering process at any time prior to
confirming it.
2. Buyer shall be able to view all tickets he or she ordered.
3. Buyer shall be able to cancel the ticket order 7 days before the trip starts.
(Priority = Medium)
Assumptions:
Use Case Template

UC ID and Name: Cancel ordered tickets
Created By: Date Created:
Primary Actor: Buyer Secondary Actors: Trips and tickets list
Trigger: The buyer request to cancel tickets that have been ordered.
Description: The buyer access the CTOMS, request to view a list of ordered tickets, then
select a number of tickets to cancel. The CTOMS will then check if the request is
valid before carry out the cancelation.
Preconditions: 1. PRE-1 User must have bought at least 1 ticket.
2. PRE-2 User must be logged in
Postconditions: POST-2 Ticket status is updated to “Canceled”
POST-2. Inventory of available tickets is updated to reflect items in this
order.
POST-3. Remaining capacity for the available tickets and trips are updated.
Normal Flow: 1.0 Cancel Tickets
1. Buyer request to view the order history
2. CTOMS displays the order history of that buyer.
3. Buyer choose an order to cancel.
4. CTOMS ask for buyer re-confirmation.
5. Buyer can either confirm to cancel or deny (return step 2)
6. CTOMS confirms the cancel of order, sends notification email to buyer.
7. CTOMS updates available trips and tickets.
Alternative Flows: 1.1 Cancel date overdue
1. CTOMS displays a message saying that this order cannot be canceled
2. Buyer clicks “OK” (returns to step 2 of normal flow)
Exceptions:
Priority: Medium
Frequency of Use: Approximately 3000 users, average of one cancel per 5 order.
Business Rules: BR-1 Cancel without losing money before 14 days.
BR-1 Cancel with a fee of 30% for each ticket before 7 days.
BR-1 Cancel with a fee of 50% for each ticket before 6-2 days.
BR-1 Cancel with a fee of 90% for each ticket before 1-0 days.
Other Information:
Assumptions:
UC ID and Name: View profile

Primary Actor: Authorized user Secondary Actors: User list
Trigger: Buer clicks on view profile button
Description: The authorized user access the CTOMS, request to view his/her personal profile
detail. The profile detail panel will show the user’s name, email, address. They
buyer can change any of these information if desired, and the CTOMS will be
updated accordingly
Preconditions: PRE-1. User is logged in successfully into CTOMS.
Postconditions: POST-1-A panel displaying profile information
Normal Flow: 1. The user request to view the profile information.
2. CTOMS displays the profile information of that buyer.
Alternative Flows: 1.1 Update information
1. The user change any of the displaying field, then clicks on “Update profile”
button.
2. CTOMS validates the input data. Return to step 1 if validate failed, else
continue.
3. CTOMS update the user information in the database.
4. CTOMS displays update successful message.
Exceptions:
Priority: Medium
Frequency of Use: Approximately 45000 users, average once per day for each user. Peak usage load
for this use case is between 5:00 P.M. and 10:00 P.M. local time.
Business Rules:
Other Information:
Assumptions:
UC ID and Name: View order history

Created By:
Primary Actor: Buyer
Trigger: The buyer request to view order history
Description: The buyer access the CTOMS, request to view a list of ordered tickets. The
CTOMS will retrieve and display the data from the database.
Preconditions: PRE-1 The user must be logged in
Postconditions: POST-2 Order history list is displayed
Exceptions:
Priority: Medium
Frequency of Use: Approximately 10000 users, average once per day for each user. Peak usage load
for this use case is between 5:00 P.M. and 10:00 P.M. local time.
Business Rules:
Other Information:
Assumptions:
UC ID and Name: Change ordered ticket

Created By:
Primary Actor: Buyer
Trigger: The buyer request to change ordered ticket(s) to a different seat on the same
coach.
Description: The buyer access the CTOMS, request to view a list of ordered tickets. The
CTOMS will retrieve and display the data from the database.
Preconditions: PRE-1 The user must be logged in.
Postconditions: POST-1 All related ticket status is updated.
POST-2. Inventory of available tickets is updated to reflect items in this change.
POST-3. Remaining seat position for the available tickets and trips are updated.
Exceptions:
Priority: Medium
Frequency of Use: Approximately 3000 users, average of one cancel per 5 order.
Business Rules: 1. User must change ticket 3 days before Trip starts
2. User cannot change Ticket beyond the Trip that User choose
Other Information:
Assumptions:
UC ID and Name: Receive promotion codes

Primary Actor: Buyer Secondary Actors: Promotion code list
Trigger: CTOMS sends buyer’s promotion codes retrieved from the database.
Description: A process will run in background at all time, waiting to receive promotion codes
from the system handler.
Postconditions: POST-1 A message indicates everytime new code is received.
Normal Flow: 1. CTOMS sends promotion codes to buyers
2. The client app receive the codes and display a message notifying buyers.
Alternative Flows:
Exceptions:
Priority: Low
Frequency of Use: Approximately 50000 users, average of one promotion code every week to all
users.
Business Rules:
Other Information:
Assumptions:
UC ID and Name: Receive notifications

Primary Actor: Buyer Secondary Actors: Notification list
Trigger: CTOMS sends buyer’s notifications retrieved from the database.
Description: A process will run in background at all time, waiting to receive notifications from
the system handler.
Postconditions: POST-1 A message indicates everytime new notifications is received.
Normal Flow: 1. CTOMS sends notifications to buyers
2. The client app receive the notifications and display a message notifying buyers.
Alternative Flows:
Exceptions:
Priority: Low
users.
Business Rules:
Other Information:
Assumptions:
UC ID and Name: View promotion codes

Primary Actor: Buyer Secondary Actors: Promotion code list
Trigger: Buyer access the CTOMS, request to view received promotion codes.
Description: After the buyer clicks on the “View promotion codes” button. CTOMS will
retrieve all available promotion codes for that buyer from the database then
display it to the user.
Postconditions: POST-1 A panel displaying all available promotion codes is showed.
Normal Flow: 1. The buyer request to view promotion codes list
2. CTOMS displays the available promotion codes of that buyer.
Alternative Flows:
Exceptions:
Priority: Low
users.
Business Rules:
Other Information:
Assumptions:
UC ID and Name: Notice Change

Created By: Duc Date Created:
Primary Actor: System handler Secondary Actors: Buyers
Trigger: Trigger when moderator or Admin announce new Change in System
Description: When Admin change something related to Buyers,System Handler will
automatically announce to Buyers
Preconditions: 1. Admin or Moderator change something related to Buyers
Postconditions: Buyers are received notification from System handler
Normal Flow: 1. Admin Change something in the System that need Buyers to know
2. System Automatically send Notice to all related Buyers
Alternative Flows:
Exceptions:
Priority: Medium
Frequency of Use: Approximately 100 per days
Business Rules:
Other Information:
Assumptions:
UC ID and Name: Notice Promotion Code

Created By: Duc Date Created:
Primary Actor: System Handler Secondary Actors: Buyers
Trigger: When a Promotion is Created or Expired
Description: When Admin or Moderator created a Promotion Code or a Promotion Code is
Expired System handler will automatically announce to Buyers related
Preconditions: Admin or moderator Create a Promotion Code or A Promotion Code Expire
Postconditions: Buyers are received notification from System handler
Normal Flow: 1. Admin or Moderator Creates some promotion codes or promotion code is
expired
2. System Automatically sends Notice to all related Buyers
Alternative Flows:
Exceptions:
Priority: Medium
Frequency of Use: Approximately 5 times a month
Business Rules:
Other Information:
Assumptions:
UC ID and Name: Auto change status outdated trips

Created By: Khang Date Created:
Primary Actor: System handler Secondary Actors: List of trips
Trigger: When System clock turns to 24:00
Description: When System clock turns to 24:00, System handler will automatically changes
status of all outdated trips
Preconditions:
Postconditions: Outdated trips status are changed
Normal Flow: 1. When System clock turns to 24:00, System handler will find all trips that
outdated and status are not changed
2. System Automatically changes those trips status
Alternative Flows:
Exceptions:
Priority: Medium
Frequency of Use: Once a day
Business Rules:
Other Information:
Assumptions:
UC ID and Name: Register

Created By: Duc Phi Date Created:
Primary Actor: Guest Secondary Actors: List of Users
Trigger: Guest Click on “Register” and fill all the blank and Click “Submit”
Description: A Guest will register to be a ticket buyer.Guest provide username,password and
Email etc..
Preconditions: 1.
Postconditions: 1. A Ticket Buyer account will be create.
Normal Flow: 1. Guest click on”Register” button.
2. Register Page displays some information that need guest to fill in .
3. Guest must fill all the blank.
4. Guest click on Submit button .
5. CTOMS will validate Guest information base on List of Users.
6. CTOMS confirms and insert new account into the DataBase.
Alternative Flows:
Exceptions: 1. Information not fulfil.
1. CTOMS informs Guest that information must be filled.
2. Guest must fill in the Blank.
3. Guest then continue with normal flow but skip to step 4.
2. Duplicate username
1. CTOMS informs Guest input another username.
2. Guest insert new username,then continue with normal flows but skip
to step 4.
Priority: High
Frequency of Use: Approximately 100 users,average of one usage per day.
Business Rules: 1. User Must older than 14 years old to Register to CTOMS
Other Information:
Assumptions:
UC ID and Name: Log in

Primary Actor: Guest Secondary Actors: List of User
Trigger: Guest click on “Log in “ Button
Description: Guest want to buy ticket will Log in to the System
Preconditions:
Postconditions: 1. Guest Login into System
Normal Flow: 1. CTOMS displays Login page with username and password to fill in.
2. Guest fill in the Blank
3. CTOMS validate information base on List of User
4. CTOMS confirm and accepted for user log in to the
Alternative Flows:
Exceptions: 1. Information not fulfill
3. Guest then continue with normal flow.
2. Wrong username or password
Priority: Extremely high

Business Rules:
Other Information:
Assumptions:
UC ID and Name: View trips

Created By: Duc phi Date Created:
Primary Actor: Guest Secondary Actors: List of trip and journey
Trigger: When user click on home “button”
Description: Guest access the CTOMS , view trips and detail of all journey
Preconditions:
Postconditions: 2. List of trip and journey show all detail
Normal Flow: 1. Guest click home or search button
2. Guest click on Journey to view trips
3. Guest click on 1 trip to view detail
Alternative Flows:
Exceptions:
Priority: normal
Business Rules:
Other Information:
Assumptions:
UC ID and Name: View profile

Primary Actor: Authorize User Secondary Actors: User Information
Trigger: Click on “View profile” button
Description: User can see user profile and
Preconditions: 1. User must be logged in
Postconditions: User see the information of his/her in profile page
Normal Flow: 1. User click on “view profile” button
2. CTOMS redirect User to Profile page,show that User Information
Alternative Flows:
Exceptions:
Priority: low
Business Rules:
Other Information:
Assumptions:
UC ID and Name: Update profile

Primary Actor: Authorize User Secondary Actors:
Trigger: Click on “View profile” button,and then click on “Update profile” Button
Description: User can see user profile and able to update profile,when User fill all the blank for
Update,User click on Submit to change old Profile to new Profile
Preconditions: 1. User must be logged in
Postconditions: User see new information of his/her in profile page
Normal Flow: 1. User click on “view profile” button
2. CTOMS redirect User to Profile page
Alternative Flows:
Exceptions: 1. Information not fulfill
1. Wrong Format
Priority: low
Business Rules:
Other Information:
Assumptions:
UC ID and Name: View Revenue

Primary Actor: Admin Secondary Actors: List Of Revenue
Trigger: Click on “View Revenue” button
Description: Admin can see Revenue
Preconditions: 1. Admin must be logged in
Postconditions: Revenue per Month ,Year
Normal Flow: 2. User click on “view Revenue” button
3. CTOMS redirect Admin to View page
Alternative Flows:
Exceptions:
Priority: high
Frequency of Use: Approximately 4 usage per month
Business Rules:
Other Information:
Assumptions:
UC ID and Name: View Statistic

Primary Actor: Admin Secondary Actors: List Of Statistic
Trigger: Click on “View Statistic” button
Description: Admin can see Statistic
Preconditions: 2. Admin must be logged in
Postconditions: Statistic per Month ,Year
Normal Flow: 4. User click on “view Statistic” button
5. CTOMS redirect Admin to View page
Alternative Flows:
Exceptions:
Priority: high
Frequency of Use: Approximately 4 usage per month
Business Rules:
Other Information:
Assumptions:
ID and Name: UC-1 Add tickets

Created By: KhangNDN Date Created: 04/06/2019
Primary Actor: Moderator Secondary Actors: List of tickets
Description: A moderator may want to add new tickets for a trip.
Trigger: A moderator clicks on Insert Tickets button
Preconditions: PRE-1. Moderator is logged into CTOMS.
Postconditions: POST-1. New ticket is added to a specific trip.
Normal Flow: 1.0 Add a ticket

1. Moderator clicks on Add New button.
2. CTOMS displays Add Ticket Form.
3. Moderator fills in Ticket Form.
4. Moderator clicks on Insert Ticket button to insert new ticket.
5. CTOMS informs Moderator that the ticket is added successfully
Alternative Flows: None
Exceptions: 1.0.E1 Ticket ID is existed
1. CTOMS informs Moderator that Ticket ID is existed
2. Moderator input new ID, then return to step 4 of Normal Flow
1.0.E2 Field is empty
1. CTOMS informs Moderator that Fields can not be blank
2. Moderator fill in each field, then return to step 4 of Normal Flow
1.1.E1 Chairs are full
1.CTOMS informs Moderator that can not add more tickets
2.CTOMS terminate use case
Priority: Medium
Frequency of Use: Average 100 times per day

Business Rules: 1. Number of remaining chairs equal Total chairs minus number of tickets
Other Information: 1. Moderator shall be able to cancel the Add Tickets process at any time before
to confirming it.
Assumptions:
ID and Name: UC2- View tickets

Description: A moderator may want to view all tickets or retrieve tickets for a specific date or
trip or status.
Trigger: A moderator clicks on View Tickets button
Postconditions: POST-1. List of ticket is shown.
Normal Flow: 2.0 View tickets

1. Moderator choose a specific date or trip
2. Moderator clicks on View Ticket button.
3. CTOMS shown list of tickets.
Alternative Flows: No ticket exists for the specific date or trip. CTOMS shows a message and let
moderator chooses again.
Exceptions:
Priority: Medium
Business Rules:
Other Information:
Assumptions:
ID and Name: UC3- Update tickets

Description: A moderator may want to retrieve tickets for a specific date or trip, modify it and
save the modify.
Trigger: A moderator clicks on Update button
PRE-2. Ticket list is shown by date or trip
Postconditions: POST-1. Ticket is updated
Normal Flow: 3.0 Update ticket

1. Moderator chooses a ticket to modify
2. CTOMS shows ticket detail
3. Moderator changes ticket infomation
4. Moderator clicks on Update button
5. CTOMS informs ticket update successfully
Exceptions: 3.0.E1 Field is empty
2. Return to step 3 of Normal Flow
Priority: Medium
Business Rules: 1. Tickets which are sold or out of date can not be modified
Other Information:
Assumptions:
ID and Name: UC4- Delete tickets

Description: A moderator may want to retrieve tickets for a specific date or trip and remove it.
Trigger: A moderator clicks on Delete button
PRE-2. Ticket list is shown by date or trip
Postconditions: POST-1. Ticket status is changed
Normal Flow: 4.0 Delete ticket

1. Moderator chooses a ticket to remove
2. Moderator clicks on Delete button
3. CTOMS shows confirm dialog
4. Moderator choose Yes to remove
5. CTOMS informs ticket remove successfully
Alternative Flows:
Exceptions:
Priority: Medium
Business Rules: 1. Tickets which are sold can not be delete
Other Information: Moderator shall be able to cancel the Delete Tickets process at any time before to
confirming it.
Assumptions:
ID and Name: UC5- View buyer’s profiles

Primary Actor: Moderator Secondary Actors: List of buyers
Description: A moderator may want to view all buyers by name or buyers id
Trigger: A moderator clicks on Search button
Postconditions: POST-1. List of buyers is shown.
Normal Flow: 5.0 View buyer’s profiles

1. Moderator input name or buyer id
2. Moderator clicks on Search button.
3. CTOMS shown list of buyers.
Alternative Flows: No buyers exists. CTOMS shows a message and let moderator input again.
Exceptions: No buyers exists. CTOMS shows a message and let moderator input again.
Priority: Medium
Business Rules:
Other Information:
Assumptions:
ID and Name: UC6- View buyer’s promotion codes

Primary Actor: Moderator Secondary Actors: List of promotion code
Description: A moderator may want to view all buyer’s promotion codes
Trigger: A moderator clicks on View Promotion button
PRE-2. Moderator chooses a buyer.
Postconditions: POST-1. List of buyer’s promotion codes is shown.
Normal Flow: 6.0 View buyer’s promotion codes

1. Moderator click on View Promotion code button
2. CTOMS shown list of buyer’s promotion codes.
Exceptions:
Priority: Low
Business Rules:
Other Information:
Assumptions:
ID and Name: UC7- Deny members

Primary Actor: Moderator Secondary Actors: List of buyers
Description: A moderator may want to deny members that not follow rules
Trigger: A moderator clicks on Deny button
PRE-2. List of buyers are shown.
Postconditions: POST-1. Buyers are denied
Normal Flow: 7.0 Deny members

1. Moderator chooses member to deny
2. Moderator clicks on Deny button
4. Moderator chooses Yes to deny
5. CTOMS informs members are denied successfully
Alternative Flows:
Exceptions: 1. Buyers who still have booking tickets can not be deny. CTOMS informs
moderator terminate use case.
Priority: Medium
Frequency of Use: Rarely. Average once a week

Business Rules: 1. Members who spam ordering and cancelling tickets rapidly could be ban
Other Information: Moderator shall be able to cancel the Deny process at any time before to
confirming it.
Assumptions:
ID and Name: UC-8 Add trips

Primary Actor: Moderator Secondary Actors: List of trips
Description: A moderator may want to add new trips.
Trigger: A moderator clicks on Insert Trip button
Postconditions: POST-1. New trip is added.
Normal Flow: 8.0 Add a trip
1. Moderator clicks on Add New Trip button.
2. CTOMS displays Add Trip Form.
3. Moderator fills in Trip Form.
4. Moderator clicks on Insert Trip button to insert new trip.
5. CTOMS informs Moderator that the trip is added successfully
Exceptions: 8.0.E1 Trip ID is existed
1. CTOMS informs Moderator that Trip ID is existed
2. Moderator input new ID, then return to step 4 of Normal Flow
Priority: Medium
Business Rules: 1. Drivers and cars must be available
Other Information: 1. Moderator shall be able to cancel the Add Trips process at any time
before to confirming it.
Assumptions:
ID and Name: UC9- View trips

Description: A moderator may want to view all trips or retrieve trips for a specific date or place
or status.
Trigger: A moderator clicks on View Trips button
Postconditions: POST-1. List of ticket is shown.
Normal Flow: 9.0 View Trips

1. Moderator choose a specific date or place
3. Moderator clicks on View Trip button.
4. CTOMS shown list of trips.
Alternative Flows: No trip exists for the specific date or place. CTOMS shows a message and let
moderator chooses again.
Exceptions:
Priority: Medium
Business Rules:
Other Information:
Assumptions:
ID and Name: UC10- Update trips

Description: A moderator may want to retrieve trips for a specific date or place, modify it and
save the modify trip.
PRE-2. Trip list is shown by date or place
Postconditions: POST-1. Trip is updated
Normal Flow: 10. Update Trip

1. Moderator chooses a trip to modify
2. CTOMS shows trip detail
3. Moderator changes trip information
4. Moderator clicks on Update button
5. CTOMS informs trip update successfully
Priority: Medium
Business Rules: 1. Trips which are out of date can not be modified
2. Moderator just can modify trip time
Other Information:
Assumptions:
ID and Name: UC11- Delete trips

Description: A moderator may want to retrieve trips for a specific date or place and remove it.
PRE-2. Trip list is shown by date or place
Postconditions: POST-1. Trip status is changed
Normal Flow: 11. Delete trip

1. Moderator chooses a trip to remove

5. CTOMS informs trip remove successfully
Alternative Flows:
Exceptions: 1. Trips which are booked can not be deleted. CTOMS informs moderator and
terminates use case
Priority: Medium
Business Rules: 1. Trips which are out of date can not be deleted
Other Information: Moderator shall be able to cancel the Delete trip process at any time before to
confirming it.
Assumptions:
ID and Name: UC-12 Add promotion code

Primary Actor: Moderator Secondary Actors: List of promotion codes
Description: A moderator may want to add new promotion codes.
Trigger: A moderator clicks on Insert Promotion button
Postconditions: POST-1. New promotion codes is added.
Normal Flow: 12. Add a promotion code
1. Moderator clicks on Add New Promotion button.
2. CTOMS displays Add Promotion Code Form.
3. Moderator fills in promotion Codes Form.
4. Moderator clicks on Insert Promotion button to insert new promotion
code.
5. CTOMS informs Moderator that the promotion code is added successfully
Exceptions: 12.0.E1 Promotion Codes is existed
1. CTOMS informs Moderator that promotion code is existed
2. Moderator input new ID promotion code then return to step 4 of Normal Flow
Priority: Low
Business Rules: 1. Promotion code can not overcome 100%
Other Information: Moderator shall be able to cancel the Add Promotion ode process at any
time before to confirming it.
Assumptions:
ID and Name: UC13- View All Promotion Codes

Description: A moderator may want to view all promotion codes.
Trigger: A moderator clicks on View All Promotion button

Postconditions: POST-1. List of promotion codes is shown.
Normal Flow: 13.0 View all promotion codes

1. Moderator clicks on View All Promotion button.
2. CTOMS shown list of promotion codes.
Exceptions:
Priority: Medium
Frequency of Use: Once a week
Business Rules:
Other Information:
Assumptions:
ID and Name: UC14- Update promotion codes

Description: A moderator may want to retrieve promotion codes, modify it and save the modify
promotion code.
PRE-2. Promotion codes list is shown
Postconditions: POST-1. Promotion codes is updated
Normal Flow: 14. Update promotion codes

1. Moderator chooses a promotion code to modify
2 CTOMS shows promotion code detail
3 Moderator changes promotion code infomation
4 Moderator clicks on Update button
5 CTOMS informs promotion code update successfully
Priority: Medium
Business Rules: 1. Promotion codes which are out of date can not be modified
Other Information:
Assumptions:
ID and Name: UC15- Delete promotion codes

Description: A moderator may want to retrieve trips to remove it.
PRE-2.Promotion codes list is shown by date or place

Postconditions: POST-1. Promotion code status is changed
Normal Flow: 15.Delete promotion codes

1. Moderator chooses a promotion code to remove
3. CTOMS shows comfirm dialog
5. CTOMS informs promotion code remove successfully
Alternative Flows:
Exceptions:
Priority: Medium
Business Rules: 1. Promotion codes which are out of date or in used can not be delete
Other Information: Moderator shall be able to cancel the Delete promotion codes process at any time
before to confirming it.
Assumptions:

CTOMS UseCase

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CTOMS UseCase

Uploaded by

Copyright:

Available Formats

Use Cases

Name Date Reason For Changes Version

Use Case ID and Name

Author and Date Created

Primary and Secondary Actors

Use Case List

Primary Actor Use Cases

ID and Name: Order a Ticket

Use Case Template

UC ID and Name: View profile

UC ID and Name: View order history

UC ID and Name: Change ordered ticket

UC ID and Name: Receive promotion codes

UC ID and Name: Receive notifications

UC ID and Name: View promotion codes

UC ID and Name: Notice Change

UC ID and Name: Notice Promotion Code

UC ID and Name: Auto change status outdated trips

UC ID and Name: Register

UC ID and Name: Log in

Priority: Extremely high

UC ID and Name: View trips

UC ID and Name: View profile

UC ID and Name: Update profile

UC ID and Name: View Revenue

UC ID and Name: View Statistic

ID and Name: UC-1 Add tickets

Normal Flow: 1.0 Add a ticket

Frequency of Use: Average 100 times per day

ID and Name: UC2- View tickets

Normal Flow: 2.0 View tickets

ID and Name: UC3- Update tickets

Normal Flow: 3.0 Update ticket

ID and Name: UC4- Delete tickets

Normal Flow: 4.0 Delete ticket

ID and Name: UC5- View buyer’s profiles

Normal Flow: 5.0 View buyer’s profiles

ID and Name: UC6- View buyer’s promotion codes

Normal Flow: 6.0 View buyer’s promotion codes

ID and Name: UC7- Deny members

Normal Flow: 7.0 Deny members

Frequency of Use: Rarely. Average once a week

ID and Name: UC-8 Add trips

ID and Name: UC9- View trips

Normal Flow: 9.0 View Trips

ID and Name: UC10- Update trips

Normal Flow: 10. Update Trip

ID and Name: UC11- Delete trips

Normal Flow: 11. Delete trip

2. Moderator clicks on Delete button

ID and Name: UC-12 Add promotion code

ID and Name: UC13- View All Promotion Codes

Trigger: A moderator clicks on View All Promotion button

Normal Flow: 13.0 View all promotion codes

ID and Name: UC14- Update promotion codes

Normal Flow: 14. Update promotion codes

ID and Name: UC15- Delete promotion codes

PRE-2.Promotion codes list is shown by date or place

Normal Flow: 15.Delete promotion codes

You might also like