User story : As a logged-in member of the system, I want to send a message to

another member, so that I can exchange information or have a conversation

with them.

Use Case ID: UC-17 Use Case Name: message other

users
Created By: Quang Vinh Date Created: 1/10/2023
Primary Actor: Member Secondary Actor: Another member
Description: A member (Primary Actor) wants to send a message to another member
(Secondary Actor) in the system to exchange information or conduct a
conversation. This use case enables the main member to interact with
other members through sending and receiving messages.
Priority: High
Users who want to send a message to another user will click on the
Trigger:
"messenger" button.
Preconditions: PRE-01: The primary user is logged into the system.
Post - POST-01: The message was sent successfully and main member can be
Conditions: viewed and managed in the message inbox.
Basic Flow: 1.The system displays an interface that allows users to enter message
content and select target users.
2.The user enters the message content and selects the target user from the
list of friends or contacts.
3.The user presses the "Send" button to send the message.
4.The message is encrypted and sent to the recipient.
5.The system records the message in the inboxes of both the sender and
the recipient.
6.The system sends a notification to the recipient to notify them of a new
message.
7.The recipient can read the message and reply if necessary.
Alternative 1.Target User Not Found (Step 2): If the user cannot find the target user in
Flow: their friends list or contacts, they can try searching by the target user's
name or contact information .
2.Message Not Sent (Step 5): If a problem occurs during the process of
encoding or sending the message, the system will notify you of an error
and the user needs to try again later.
Exception Flow: If there is an error during message delivery, the system will notify the
primary user of the error and attempt to fix the problem (e.g. lost network
connection, user does not exist, etc.).
Business Rules: Account Logged: The main user and other users need to log in to their
accounts to be able to send and receive messages.
Message Security: Sent and received messages need to be encrypted to
 ensure privacy and security.Message Security: Sent and received messages
need to be encrypted to ensure privacy and security.
Message Length Limit: Sent and received messages have a length limit to
support effective message management and display, specifically the
content must be less than 500 characters.
New Message Notification: Users need to receive notifications when there
are new messages from other users.

Use Case ID: UC-08 Use Case Name: Register for a Sale
Account
Created By: Date Created: 2023/10/08
Primary Actor: User Secondary Actor: None
This use case describes the process of a user registering an account to
Description: participate in online sales on the website.
Priority: High
User selects the option to register an account on the website.
Trigger:
Preconditions: No user accounts with the same email address already exist in the system.
The user has successfully created an account and is logged in.
Post -
Conditions:
1. User visits website or sales application.
2. The user clicks the "Register" link or similar option.
3. The system displays an account registration form with required
information fields such as name, email address, password, etc.
Basic Flow:
4. The user fills in the necessary information in the form.
5. The user clicks the "Register" button.
6. The system checks whether the email address exists or not. If it
already exists, display an error message and ask the user to use a
different email address.
7. If the email address does not exist, the system creates a new
account for the user with registration information and sends a
confirmation email to the provided email address.
8. The user checks the email and confirms the registration by clicking
the confirmation link.
9. The system confirms the account and displays a successful
registration message.
10. The user has successfully registered and can log in with his new
account.
Alternative 6a. If the user enters an invalid or malformed email address, the system
Flow: displays an error message and asks the user to re-enter.

6b. If the system encounters an error while processing the registration, it

displays an error message and asks the user to try again later.
Exception Flow:
Business Rules: The email address must be unique in the system and must be in a valid
format.
Passwords must meet certain security requirements (for example, at least
8 characters, contain at least one uppercase letter, one lowercase letter,
and one number).

Use Case ID: UC-33 Use Case Name: View Other User
Profile
Created By: Quang Vinh Date Created: 2023/10/08
Primary Actor: User Secondary Actor: None
This use case describes the process of a user viewing another user's profile
Description: on a website.
Priority: Average
User selects another user to view their profile.
Trigger:
Preconditions: The target user's profile is available in the system.
The user viewed the target user's profile.
Post -
Conditions:
1. User visits a website or application.
2. Users search or select target users to view their profiles.
3. The system displays the target user's profile, including information
such as name, avatar, description, etc.
Basic Flow:
4. Users browse the information in the profile and read the
description.
5. Users can perform tasks such as sending messages to target users
or following them
Alternative 4a. If the target user's profile does not have information or a profile
Flow: picture, the system still displays the profile with the available information.
3a. If the target user does not exist or cannot be found in the system, the
system displays an error message and asks the user to try again or check
the entered target user name.
Exception Flow:
Business Rules: Rules and restrictions on access to the target user's profile may be applied
based on their privacy.

Use Case ID: UC-35 Use Case Name: Change User Role

Created By: Quang Vinh Date Created: 2023/10/08

Primary Actor: Administrator Secondary Actor: None
(Admin)
This use case describes the process by which an administrator changes the
Description: role of a user in the system.
Priority: High
Administrator selects a user and makes a role change.
Trigger:
Preconditions: The administrator has logged into the system.
The target user already exists in the system.
The user's role has been changed.
Post -
Conditions:
1. Administrator logs into the system.
2. Administrator accesses user list or searches for target users.
3. Administrator selects target users to change roles.
4. The system displays the target user's profile with current roles and
Basic Flow:
change options.
5. The administrator selects the new role for the target user from the
list of available roles (e.g. Administrator, Regular User, Moderator,
etc.).
6. Administrator saves changes.
7. The system updates the target user's role.
8. The system displays a confirmation message to the administrator.
Alternative 4a. If no specific role has been selected, the administrator can change the
Flow: role by entering a new role.
3a. If the administrator does not have permission to change the user's
role or the target user does not exist, the system displays an error
message and does not perform the role change.
Exception Flow:
Business Rules: Administrators need to have access and change user roles.
Access rules and restrictions and role changes can be applied based on
system and user privacy.

Use Case ID: UC-36 Use Case Name: See list of users

Created By: Quang Vinh Date Created: 2023/10/08

Primary Actor: Administrator Secondary Actor: None

(Admin)
This use case describes the process of an administrator viewing the list of
Description: users in the system.
Priority: Average
Administrator selects option to view user list.
Trigger:
Preconditions: The administrator has logged into the system.
 The administrator has viewed the user list.
Post -
Conditions:
1. Administrator logs into the system.
2. Administrator accesses part of the system or "User List" option.
3. The system displays a list of users with basic information such as
name, email address, and role.
Basic Flow:
4. Administrators can perform tasks such as sorting lists, searching
for users, and viewing a specific user's profile details.
Alternative 3a. If there are no users in the system, the system will display a message
Flow: saying there is no data to display.
2 a. If the administrator does not have permission to access the user list
or there are no users available, the system displays an error message and
does not attempt to view the user list.
Exception Flow:
Business Rules: Administrators need to have access to the user list.
Rules and restrictions on access and viewing of user lists may be applied
based on system and user privacy.

Use Case ID: UC-37 Use Case Name: Delete user

Created By: Quang Vinh Date Created: 2023/10/08

Primary Actor: Administrator Secondary Actor: None

(Admin)
This use case describes the process by which an administrator deletes a
Description: user from the system using a form.
Priority: High
Administrator selects a user to delete and executes deletion via form.
Trigger:
Preconditions: The administrator has logged into the system.
The target user already exists in the system.
The user has been removed from the system.
Post -
Conditions:
1. Administrator logs into the system.
2. Administrators access user lists or search for specific users to
delete.
3. The administrator selects the target user to delete.
Basic Flow:
4. The system displays a confirmation form with the target user's
information and a request to confirm deletion.
5. The administrator confirms the deletion of the user.
6. The system deletes the target user from the system.
7. The system displays a confirmation message to the
administrator.Administrators can perform tasks such as sorting
 lists, searching for users, and viewing a specific user's profile
details.
Alternative 4a. If the administrator decides not to delete the user and cancels the
Flow: operation, the process ends.
2 a. If the administrator does not have permission to access the 3a. If the
administrator does not have permission to delete a user or the target
user does not exist, the system displays an error message and does not
Exception Flow: delete the user.
Business Rules: Administrators need to have access and delete users.
Deleting a user can result in irrecoverable data loss, so this process needs
to be done carefully and controlled by the system and administrator..