Skip to content

Use Cases

Jump to bottom
NFilin10 edited this page Dec 17, 2024 · 26 revisions

Use Case 1: Create new user account in active directory

Related User Story: As a user, I want to create new user accounts in AD through the REST API so that I can automate account management.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The REST API service is available and functional.

Postconditions:

  • A new user account is created in Active Directory with the specified attributes.

Main Flow

  1. Initiate account creation:

    • User sends a POST request to the REST API with the new user details.

  2. Validate input:

    • System checks if all required fields are provided.
    • System checks if all required fields have a correct format.
    • If validation is successful, the command is saved to the database.
    • If validation fails, an error message is returned.

  3. Create user account:

    • System retrieves the command from the database and executes it in AD to create the user account.
    • System confirms creation and returns a success response with the new user ID and saves the result back to the database.

Alternate flows

  • Invalid Input:
    • If the input is invalid, the system returns an error message specifying the issues.

Acceptance criteria

  • Acceptance test 1: successful user creation
  • Scenario: Valid input with all required fields.
  • Steps:
    1. Send a POST request with valid user details.
    2. The system validates the input.
    3. The system successfully creates the user in AD.
  • Expected Result:
    • The new user account is created in AD.
    • The system returns a success response.
    • The result is stored in the database.
  • Pass Criteria: User account is created successfully, and the correct data is saved.

Acceptance test 2: invalid input

  • Scenario: Missing required field or incorrect format.
  • Steps:
    1. Send a POST request with missing or incorrect user details.
  • Expected Result:
    • The system returns an error message specifying the issue.
    • The request is not processed further.
  • Pass Criteria: The system rejects the input and provides feedback to the user.

Use Case 2: Execute command on Active Directory

Related User Story: As a user, I want the system to execute commands in the correct order to ensure that dependent operations are handled correctly.

Actors:

  • User
  • System

Preconditions:

  • Commands are queued for processing.
  • The system has access to Active Directory and is authenticated to perform actions.

Postconditions:

  • The command is executed successfully.

Main flow:

  1. Submit command:

    • User sends a command request to the API.

  2. Validate command:

    • System checks the command format.
    • If validation fails, an error message is returned.

  3. Queue command:

    • If valid, the system places the command in the processing queue based on priority.

  4. Execute command:

    • The system processes the command in the correct order.
    • System executes the command against Active Directory.

Alternate Flows:

  • Command validation failure:
    • If the command is invalid, the system returns an error message detailing the issue.
  • Execution error:
    • If an error occurs during execution, the system logs the error and returns an appropriate error message to the user.

Acceptance criteria

Acceptance test 1: Successful command execution

  • Scenario: The user submits a valid command with correct format and parameters.
  • Steps:
    1. The user sends a POST request with a valid command.
    2. The system validates the command format.
    3. The system places the command in the processing queue.
    4. The system executes the command against Active Directory.
  • Expected result:
    • The system successfully processes and executes the command.
    • The system returns a success message with the result of the command.
  • Pass criteria:
    • The command is executed successfully, and the correct result is returned.

Acceptance test 2: Invalid command format

  • Scenario: The user submits a command with an invalid format.
  • Steps:
    1. The user sends a POST request with an invalid command.
    2. The system validates the command.
  • Expected Result:
    • The system returns an error message indicating the issue with the command.
  • Pass Criteria:
    • The system correctly identifies the error and provides feedback to the user.

Acceptance Test 3: Command execution error

  • Scenario: An error occurs during the execution of the command.
  • Steps:
    1. The user sends a valid command, but the system encounters an error during execution.
  • Expected Result:
    • The system logs the error and returns an appropriate error message to the user.
  • Pass Criteria:
    • The system handles the error and provides the user with clear information about the failure.

Use Case 3: Query user accounts in Active Directory

Related User Story: As a user, I want to query user accounts in AD so that I can retrieve user details.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to access user account details.

Postconditions:

  • User account details are retrieved and returned to the user.

Main Flow:

  1. Initiate Query Request:

    • User sends a GET request to the REST API, specifying the search criteria.

  2. Validate Input:

    • System checks if the search criteria are valid.
    • If validation fails, an error message is returned.

  3. Query Active Directory:

    • The system retrieves the command from the database and executes it in AD.
    • The AD returns user account details matching the criteria.

  4. Return Results:

    • The system saves the result back to the database.
    • A success response with the user details is returned to the user.

Alternate Flows:

  • Invalid Search Criteria:
    • If the search criteria are invalid, the system returns an error message specifying the issue.

Acceptance Criteria

Acceptance Test 1: Successful Query

  • Scenario: The user submits a valid query.
  • Steps:
    1. Send a GET request with valid search criteria.
    2. The system executes the query and returns matching results.
  • Expected result:
    • The matching user details are returned from AD.
  • Pass criteria:
    • A success confirmation with the results is returned.

Acceptance Test 2: Invalid search criteria

  • Scenario: The user submits an invalid query.
  • Steps:
    1. Send a GET request with invalid search criteria.
  • Expected result:
    • An error message specifying the invalid criteria is returned.
  • Pass criteria:
    • A clear error message is returned.

Use Case 4: Update user account in Active Directory

Related User Story: As a user, I want to update user account information in AD to keep user details current.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to update user account information.

Postconditions:

  • User account information is updated in Active Directory.

Main Flow:

  1. Initiate Update Request:

    • User sends a PUT request to the REST API with updated user account details.

  2. Validate Input:

    • System checks if the user exists in AD.
    • System checks if all required fields for the update are provided and valid.
    • If validation fails, an error message is returned.

  3. Update User Account:

    • The system retrieves the command from the database and updates the user account in AD.
    • AD confirms the update.

  4. Return Confirmation:

    • The system saves the update result back to the database.
    • A success response with the updated details is returned to the user.

Alternate Flows:

  • Invalid Input:
    • If the input is invalid or the user does not exist, the system returns an error message specifying the issue.

Acceptance criteria

Acceptance test 1: Successful update

  • Scenario: The user submits valid account update details.
  • Steps:
    1. Send a PUT request with valid user details.
    2. The system validates and updates the account in AD.
  • Expected Result:
    • The user account is updated successfully in AD.
  • Pass Criteria:
    • A success confirmation with updated user details is returned.

Acceptance test 2: Invalid input

  • Scenario: The user submits invalid or incomplete account details.
  • Steps:
    1. Send a PUT request with invalid or incomplete details.
  • Expected Result:
    • The system returns an error message specifying the invalid input.
  • Pass Criteria:
    • A clear error message is returned.

Use Case 5: Delete User Account in Active Directory

Related User Story: As a user, I want to delete user accounts in AD through the REST API to remove outdated accounts.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to delete accounts.

Postconditions:

  • The user account is deleted from Active Directory.

Main Flow:

  1. Initiate Delete Request:

    • User sends a DELETE request to the REST API with the user ID or account details to be deleted.

  2. Validate Input:

    • System checks if the user exists in AD.
    • If the user does not exist, an error message is returned.

  3. Delete User Account:

    • The system retrieves the delete command from the database and deletes the user account in AD.
    • AD confirms deletion.

  4. Return Confirmation:

    • The system saves the delete result back to the database.
    • A success response is returned to the user.

Alternate Flows:

  • User Not Found:
    • If the user account does not exist, the system returns an error message specifying the issue.

Acceptance criteria

Acceptance Test 1: Successful deletion

  • Scenario: The user successfully deletes an account.
  • Steps:
    1. Send a DELETE request with a valid user ID.
    2. The system deletes the account in AD.
  • Expected result:
    • The user account is deleted successfully from AD.
  • Pass criteria:
    • A success confirmation is returned.

Acceptance test 2: User not found

  • Scenario: The user does not exist in AD.
  • Steps:
    1. Send a DELETE request for a non-existent user.
  • Expected result:
    • An error message indicating the user was not found is returned.
  • Pass criteria:
    • A clear error message is returned.

Use Case 6: Reset user password in Active Directory

Related User Story: As a user, I want to reset user passwords in AD via the REST API to assist with password recovery.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to reset passwords.

Postconditions:

  • The user password is reset in Active Directory.

Main Flow:

  1. Initiate Password Reset Request:

    • User sends a POST request to the REST API with the user ID and the new password.

  2. Validate Input:

    • System checks if the user exists in AD.
    • System validates the new password format.
    • If validation fails, an error message is returned.

  3. Reset Password:

    • The system retrieves the reset password command from the database and updates the user password in AD.
    • AD confirms the password reset.

  4. Return Confirmation:

    • The system saves the reset result back to the database.
    • A success response is returned to the user.

Alternate Flows:

  • Invalid Password Format or User Not Found:
    • If the password format is invalid or the user does not exist, the system returns an error message specifying the issue.

Acceptance Criteria

Acceptance test 1: Successful password reset

  • Scenario: The user submits a valid reset request.
  • Steps:
    1. Send a POST request with the user ID and valid new password.
    2. The system validates the request and updates the password.
  • Expected result:
    • The user's password is reset successfully in AD.
  • Pass criteria:
    • A success confirmation is returned.

Acceptance test 2: Invalid password format

  • Scenario: The user submits a password that doesn't meet the required format.
  • Steps:
    1. Send a POST request with an invalid password format.
  • Expected Result:
    • The system returns an error message indicating the password is invalid.
  • Pass criteria:
    • A clear message about password format requirements is returned.

Acceptance Test 3: User not found

  • Scenario: The user doesn't exist in AD.
  • Steps:
    1. Send a POST request for a non-existent user.
  • Expected result:
    • The system returns an error message.
  • Pass criteria:
    • The correct error message is returned.

Use Case 7: Disable or Enable User Account in Active Directory

Related User Story: As a user, I want to enable or disable user accounts in AD using the REST API to manage user access.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to enable or disable accounts.

Postconditions:

  • The user account is enabled or disabled in Active Directory.

Main flow:

  1. Initiate enable/disable request:

    • User sends a PUT request to the REST API with the user ID and the desired action (enable/disable).

  2. Validate input:

    • System checks if the user exists in AD.
    • If the user does not exist, an error message is returned.

  3. Execute action:

    • The system retrieves the enable/disable command from the database and updates the user account status in AD.
    • AD confirms the change.

  4. Return confirmation:

    • The system saves the result back to the database.
    • A success response is returned to the user.

Alternate flows:

  • User Not Found:
    • If the user does not exist, the system returns an error message.

Acceptance Criteria

Acceptance test 1: Successful action

  • Scenario: The user submits a valid request to enable or disable an account.
  • Steps:
    1. Send a PUT request with valid user ID and action.
    2. The system validates and processes the request.
  • Expected Result:
    • The account is enabled or disabled successfully in AD.
  • Pass Criteria:
    • A success confirmation is returned.

Acceptance test 2: User not found

  • Scenario: The user does not exist in AD.
  • Steps:
    1. Send a PUT request for a non-existent user.
  • Expected result:
    • The system returns an error message ("User not found").
  • Pass criteria:
    • A clear error message is returned.

Use Case 8: Add or Remove Users from Groups in Active Directory

Related User Story: As a user, I want to add or remove users from groups in AD via the REST API to manage group memberships.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to modify group memberships.

Postconditions:

  • The user is added to or removed from the specified group in Active Directory.

Main Flow:

  1. Initiate Group Membership Change Request:

    • User sends a POST or DELETE request to the REST API with the user ID and group ID.

  2. Validate Input:

    • System checks if both the user and the group exist in AD.
    • If validation fails, an error message is returned.

  3. Modify Group Membership:

    • The system retrieves the command from the database and modifies the group membership in AD.
    • AD confirms the action.

  4. Return Confirmation:

    • The system saves the result back to the database.
    • A success response is returned to the user.

Alternate Flows:

  • User or Group Not Found:
    • If the user or group does not exist, the system returns an error message.

Acceptance criteria

Acceptance test 1: Successful removal from the group

  • Scenario: The user successfully adds or removes a user from a group.
  • Steps:
    1. Send a POST or DELETE request with valid user and group details.
    2. The system validates and modifies the group membership.
  • Expected result:
    • The user's group membership is updated in AD.
  • Pass criteria:
    • A success confirmation with the updated details is returned.

Acceptance test 2: User or group not found

  • Scenario: The user or group does not exist.
  • Steps:
    1. Send a POST or DELETE request for a non-existent user or group.
  • Expected result:
    • The system returns an error message indicating the missing entity.
  • Pass criteria:
    • A clear error message is returned.

Use Case 9: Assign Roles to Users in Active Directory

Related User Story: As a user, I want to assign roles to users in AD via the REST API to manage their access rights.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to assign roles.

Postconditions:

  • The role is assigned to the user in Active Directory.

Main Flow:

  1. Initiate Role Assignment Request:

    • User sends a POST request to the REST API with the user ID and the role to be assigned.

  2. Validate Input:

    • System checks if the user exists and the role is valid.
    • If validation fails, an error message is returned.

  3. Assign Role:

    • The system retrieves the command from the database and assigns the role in AD.
    • AD confirms the role assignment.

  4. Return Confirmation:

    • The system saves the result back to the database.
    • A success response is returned to the user.

Alternate flows:

  • User or Role Not Found:
    • If the user or role does not exist, the system returns an error message.

Acceptance criteria

Acceptance test 1: Successful role assignment

  • Scenario: The user successfully assigns a role to a user.
  • Steps:
    1. Send a POST request with valid user ID and role.
    2. The system assigns the role to the user in AD.
  • Expected result:
    • The role is successfully assigned to the user.
  • Pass criteria:
    • A success response confirming the role assignment is returned.

Acceptance test 2: Invalid role or user

  • Scenario: The user or role does not exist.
  • Steps:
    1. Send a POST request with a non-existent user or invalid role.
  • Expected result:
    • An error message indicating that the user or role was not found.
  • Pass criteria:
    • A clear error message specifying the issue is returned.

Use Case 10: Query role assignments in Active Directory

Related User Story: As a user, I want to query role assignments in AD via the REST API to audit user permissions.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to query role assignments.

Postconditions:

  • Role assignment information is retrieved and returned to the user.

Main Flow:

  1. Initiate Query Request:

    • User sends a GET request to the REST API with search criteria (e.g., user ID, role).

  2. Validate Input:

    • System checks if the search criteria are valid.
    • If validation fails, an error message is returned.

  3. Query Role Assignments:

    • The system retrieves the role assignment data from AD.
    • AD returns the role assignments.

  4. Return Results:

    • The system saves the result back to the database.
    • A success response with the role assignment details is returned to the user.

Alternate Flows:

  • Invalid Search Criteria:
    • If the search criteria are invalid, the system returns an error message specifying the issue.

Acceptance criteria

Acceptance test 1: Successful query

  • Scenario: The user successfully queries role assignments.
  • Steps:
    1. Send a GET request with valid search criteria.
    2. The system retrieves the role assignment data from AD.
  • Expected result:
    • The role assignment details are returned successfully.
  • Pass criteria:
    • A success response with the role assignments is returned.

Acceptance test 2: Invalid search criteria

  • Scenario: The user submits invalid search criteria.
  • Steps:
    1. Send a GET request with invalid search criteria.
  • Expected result:
    • An error message specifying the invalid criteria is returned.
  • Pass criteria:
    • A clear error message indicating the issue is returned.

Use Case 11: View command execution status

Related User Story: As a user, I want to view the status of command execution in AD to monitor task completion.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to view command statuses.

Postconditions:

  • The status of the command execution is displayed to the user.

Main Flow:

  1. Initiate Status Query Request:

    • User sends a GET request to the REST API with the command ID.

  2. Validate Input:

    • System checks if the command ID is valid.
    • If validation fails, an error message is returned.

  3. Retrieve Command Status:

    • The system retrieves the command status from the database.

  4. Return Results:

    • A success response with the command status is returned to the user.

Alternate Flows:

  • Command Not Found:
    • If the command ID does not exist, the system returns an error message specifying the issue.

Acceptance criteria

Acceptance test 1: Successful command status retrieval

  • Scenario: The user successfully retrieves the status of a command.
  • Steps:
    1. Send a GET request with a valid command ID.
    2. The system retrieves the command status.
  • Expected Result:
    • The command status is returned successfully.
  • Pass Criteria:
    • A success response with the command status is returned.

Acceptance test 2: Command not found

  • Scenario: The command ID does not exist.
  • Steps:
    1. Send a GET request with a non-existent command ID.
  • Expected result:
    • An error message indicating the command was not found is returned.
  • Pass criteria:
    • A clear error message specifying the issue is returned.

Use Case 12: Create new group in Active Directory

Related User Story: As a user, I want to create new groups in AD through the REST API to organize users efficiently.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to create groups.

Postconditions:

  • A new group is created in Active Directory.

Main Flow:

  1. Initiate Group Creation Request:

    • User sends a POST request to the REST API with the group details (e.g., group name, description).

  2. Validate Input:

    • System checks if all required fields are provided and if the group name is unique.
    • If validation fails, an error message is returned.

  3. Create Group:

    • The system retrieves the command from the database and creates the group in AD.
    • AD confirms the group creation.

  4. Return Confirmation:

    • The system saves the result back to the database.
    • A success response is returned to the user.

Alternate Flows:

  • Invalid Input or Duplicate Group Name:
    • If the group name already exists or the input is invalid, an error message is returned.

Acceptance criteria

Acceptance test 1: Successful group creation

  • Scenario: The user successfully creates a new group.
  • Steps:
    1. Send a POST request with valid group details.
    2. The system creates the group in AD.
  • Expected result:
    • A new group is created successfully in AD.
  • Pass criteria:
    • A success response with group details is returned.

Acceptance test 2: Invalid or duplicate group name

  • Scenario: The group name is invalid or already exists.
  • Steps:
    1. Send a POST request with an invalid or duplicate group name.
  • Expected result:
    • An error message indicating the invalid input or duplication is returned.
  • Pass criteria:
    • A clear error message is returned.

Use Case 13: Delete group in Active Directory

Related User Story: As a user, I want to delete groups in AD through the REST API to remove obsolete groups.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to delete groups.

Postconditions:

  • The group is deleted from Active Directory.

Main Flow:

  1. Initiate Group Deletion Request:

    • User sends a DELETE request to the REST API with the group ID.

  2. Validate Input:

    • System checks if the group exists in AD.
    • If the group does not exist, an error message is returned.

  3. Delete Group:

    • The system retrieves the deletion command from the database and deletes the group in AD.
    • AD confirms the deletion.

  4. Return Confirmation:

    • The system saves the result back to the database.
    • A success response is returned to the user.

Alternate Flows:

  • Group Not Found:
    • If the group does not exist, the system returns an error message.

Acceptance criteria

Acceptance test 1: Successful group deletion

  • Scenario: The user successfully deletes a group.
  • Steps:
    1. Send a DELETE request with a valid group ID.
    2. The system deletes the group in AD.
  • Expected Result:
    • The group is deleted successfully from AD.
  • Pass Criteria:
    • A success confirmation is returned.

Acceptance test 2: Group not found

  • Scenario: The group does not exist.
  • Steps:
    1. Send a DELETE request for a non-existent group.
  • Expected result:
    • An error message indicating the group was not found is returned.
  • Pass criteria:
    • A clear error message specifying the issue is returned.

Use Case 14: List all members of a group in Active Directory

Related User Story: As a user, I want to list all members of a group in AD using the REST API to audit group composition.

Actors:

  • User

Preconditions:

  • The system is connected to Active Directory.
  • The user is authenticated and authorized to query group memberships.

Postconditions:

  • The list of group members is returned to the user.

Main Flow:

  1. Initiate Query for Group Members:

    • User sends a GET request to the REST API with the group ID.

  2. Validate Input:

    • System checks if the group exists in AD.
    • If the group does not exist, an error message is returned.

  3. Retrieve Group Members:

    • The system retrieves the list of group members from AD.
    • AD returns the group membership details.

  4. Return Results:

    • The system saves the result back to the database.
    • A success response with the list of members is returned to the user.

Alternate Flows:

  • Group Not Found:
    • If the group does not exist, the system returns an error message.

Acceptance criteria

Acceptance test 1: Successful group membership query

  • Scenario: The user successfully lists all members of a group.
  • Steps:
    1. Send a GET request with a valid group ID.
    2. The system retrieves the group membership details.
  • Expected result:
    • The list of group members is returned successfully.
  • Pass criteria:
    • A success response with the group members is returned.

Acceptance test 2: Group not Found

  • Scenario: The group does not exist.
  • Steps:
    1. Send a GET request for a non-existent group.
  • Expected result:
    • An error message indicating the group was not found is returned.
  • Pass criteria:
    • A clear error message specifying the issue is returned.

Use Case 15: Prioritize Command Execution in Active Directory

Related User Story: As a user, I want the system to prioritize urgent commands when executing, ensuring critical operations are completed promptly.

Actors:

  • User
  • System

Preconditions:

  • Commands are queued for processing.

Postconditions:

  • The command is executed according to its priority.

Main Flow:

  1. Submit Command with Priority:

    • User sends a command request to the API, specifying the command and its priority level.

  2. Validate Command:

    • System checks the command format and priority level.
    • If validation fails, an error message is returned.

  3. Queue Command:

    • If valid, the system places the command in the processing queue based on priority (high, medium, low).

  4. Execute Command:

    • The system processes commands, executing higher-priority commands first.
    • System executes the command against Active Directory.

Alternate Flows:

  • Command Validation Failure:
    • If the command is invalid, the system returns an error message detailing the issue.

Acceptance criteria

Acceptance test 1: Successful command execution with priority

  • Scenario: The user successfully prioritizes and executes a command.
  • Steps:
    1. Submit a command with a specified priority.
    2. The system executes the command based on the priority.
  • Expected result:
    • The system processes and executes the command in the correct priority order.
  • Pass criteria:
    • A success response confirming the command execution is returned.

Acceptance test 2: Command validation failure

  • Scenario: The command is invalid or has an invalid priority level.
  • Steps:
    1. Submit an invalid command or priority level.
  • Expected result:
    • An error message indicating the validation failure is returned.
  • Pass criteria:
    • A clear error message specifying the issue is returned.

Use Case 16: Log command execution errors

Related User Story: As a user, I want a system to handle command execution errors and log them to provide feedback on failed operations.

Actors:

  • User
  • System

Preconditions:

  • The system is connected to Active Directory.

Postconditions:

  • Errors encountered during command execution are logged.

Main Flow:

  1. Execute Command:

    • System attempts to execute a command against Active Directory.

  2. Check for Errors:

    • If an error occurs during execution, the system logs the error details (e.g., command ID, error message).

  3. Return Error to User:

    • System sends an appropriate error message to the user regarding the failed operation.

Alternate Flows:

  • No Errors Encountered:
    • If the command executes successfully, the system proceeds to log the success instead.

Acceptance criteria

Acceptance test 1: Command execution error logged

  • Scenario: An error occurs during command execution.
  • Steps:
    1. Send a command that will trigger an error in AD.
    2. The system logs the error details and returns an error message.
  • Expected result:
    • The system logs the error and sends a corresponding message to the user.
  • Pass criteria:
    • The error details are logged successfully and an error message is returned to the user.

Acceptance test 2: Successful command execution

  • Scenario: No errors occur during command execution.
  • Steps:
    1. Send a valid command to AD.
    2. The system logs the success and no error occurs.
  • Expected result:
    • The system logs the success and completes the operation.
  • Pass criteria:
    • The success is logged and no errors are returned.

Use Case 17: Validate Command Inputs Before Execution

Related User Story: As a user, I want the system to validate command inputs before execution to prevent invalid requests from being processed.

Actors:

  • User
  • System

Preconditions:

  • The system is connected to Active Directory.

Postconditions:

  • Only valid commands are executed.

Main Flow:

  1. Submit Command:

    • User sends a command request to the API.

  2. Validate Command Inputs:

    • System checks the format and required fields of the command.
    • If validation fails, an error message is returned.

  3. Execute Command:

    • If validation is successful, the system retrieves the command from the database and executes it in Active Directory.

Alternate Flows:

  • Invalid Input:
    • If the input is invalid, the system returns an error message specifying the issues.

Acceptance criteria

Acceptance test 1: Valid command inputs

  • Scenario: The user submits a valid command.
  • Steps:
    1. Send a correctly formatted command request.
    2. The system validates the inputs and executes the command.
  • Expected Result:
    • The command is successfully executed without issues.
  • Pass Criteria:
    • The command executes correctly and produces the expected outcome.

Acceptance test 2: Invalid command inputs

  • Scenario: The user submits an invalid command.
  • Steps:
    1. Send a command with missing or incorrect inputs.
    2. The system validates the inputs and returns an error message.
  • Expected result:
    • The system returns an error message detailing the invalid input.
  • Pass criteria:
    • The error message clearly identifies the input problem.

Use Case 18: Update Command Status in Database

Related User Story: As a user, I want the system to update command status in the database after execution, so I know which commands have been completed and their outcomes.

Actors:

  • User
  • System

Preconditions:

  • The command has been executed.

Postconditions:

  • The command status is updated in the database.

Main Flow:

  1. Execute Command:

    • The system executes a command against Active Directory.

  2. Update Command Status:

    • System updates the command status in the database (e.g., success, failure).

  3. Notify User:

    • A success response with the updated command status is returned to the user.

Alternate Flows:

  • Status Update Failure:
    • If the status update fails, the system returns an error message to the user.

Acceptance criteria

Acceptance test 1: Successful status update

  • Scenario: The system successfully updates the command status in the database.
  • Steps:
    1. Execute a command.
    2. The system updates the command status in the database and returns the result to the user.
  • Expected Result:
    • The command status is updated to "success" or "failure."
  • Pass Criteria:
    • The system returns a success response with the updated status.

Acceptance test 2: Status update failure

  • Scenario: The system fails to update the command status.
  • Steps:
    1. Execute a command.
    2. The system fails to update the status in the database.
  • Expected result:
    • The system returns an error message indicating the status update failure.
  • Pass criteria:
    • An error message specifying the failure is returned.

Use Case 19: Container management for command execution

Related User Story: As a user, I want the command execution environment to be isolated within Docker containers, ensuring that my Active Directory operations are secure and do not affect other system processes.

Actors:

  • User
  • System (Docker)

Preconditions:

  • Docker is set up and configured for command execution.

Postconditions:

  • Commands are executed within isolated Docker containers.

Main Flow:

  1. Submit Command:

    • User sends a command request to the API.

  2. Launch Docker Container:

    • The system launches a Docker container for the command execution.

  3. Execute Command:

    • The command is executed within the Docker container.

  4. Return Results:

    • The results are returned to the user once the command execution is complete.

  5. Terminate Container:

    • After execution, the Docker container is terminated to free resources.

Alternate Flows:

  • Container Launch Failure:
    • If the Docker container fails to launch, an error message is returned to the user.

Acceptance criteria

Acceptance test 1: Successful command execution in docker

  • Scenario: The user successfully executes a command in an isolated Docker container.
  • Steps:
    1. Submit a command to be executed.
    2. The system launches a container, executes the command, and returns the result.
  • Expected result:
    • The command is executed in an isolated container, and the result is returned.
  • Pass criteria:
    • The container is launched and terminated successfully, and the command results are returned to the user.

Acceptance test 2: Container launch failure

  • Scenario: The Docker container fails to launch.
  • Steps:
    1. Submit a command for execution.
    2. The system fails to launch the Docker container.
  • Expected result:
    • An error message indicating the failure to launch the container is returned.
  • Pass criteria:
    • A clear error message specifying the issue with container launch is returned.

Use Case 20: Store Command Results in Database

Related User Story: As a user, I want the system to write the results of executed commands back to the database to make them accessible to the REST API.

Actors:

  • User
  • System

Preconditions:

  • A command has been executed against Active Directory.

Postconditions:

  • The results of the executed command are stored in the database.

Main Flow:

  1. Execute Command:

    • The system executes a command against Active Directory.

  2. Retrieve Command Results:

    • The system retrieves the output/results of the command execution.

  3. Store Results:

    • The system writes the results to the database for later retrieval.

  4. Notify User:

    • A success response confirming that the results have been stored is returned to the user.

Alternate Flows:

  • Result Storage Failure:
    • If the results cannot be stored, the system returns an error message detailing the issue.

Acceptance criteria

Acceptance test 1: Successful storage of results

  • Scenario: The system successfully stores command results in the database.
  • Steps:
    1. Execute a command.
    2. The system stores the results in the database and returns confirmation.
  • Expected Result:
    • The results are stored and accessible.
  • Pass Criteria:
    • The results are stored and a success confirmation is returned.

Acceptance test 2: Result storage failure

  • Scenario: The system fails to store command results.
  • Steps:
    1. Execute a command.
    2. The system fails to store the results.
  • Expected Result:
    • An error message indicating the failure to store results is returned.
  • Pass Criteria:
    • A clear error message specifying the issue is returned.

Use Case 21: Ensure Data Encryption for API Requests

Related User Story: As a user, I want all data transmitted to and from the API to be encrypted using HTTPS, ensuring that my data is secure during access.

Actors:

  • User
  • System

Preconditions:

  • The API is configured to support HTTPS.

Postconditions:

  • All data transmitted to and from the API is encrypted.

Main Flow:

  1. Send API Request:

    • User sends a request to the API using HTTPS.

  2. Encrypt Data:

    • The system ensures that all data transmitted is encrypted during transit.

  3. Receive Encrypted Response:

    • The system returns an encrypted response to the user.

  4. Decrypt Response:

    • The user’s client decrypts the response for readability.

Alternate Flows:

  • HTTPS Configuration Failure:
    • If the API is not configured to use HTTPS, the system returns an error message indicating that the request cannot be processed securely.

Acceptance criteria

Acceptance test 1: Data transmission is encrypted

  • Scenario: The system ensures data is encrypted during transmission.
  • Steps:
    1. Send an API request over HTTPS.
    2. The system ensures that the data is encrypted.
  • Expected Result:
    • The data is encrypted and secure during transmission.
  • Pass Criteria:
    • HTTPS encryption is confirmed, and no data leaks are detected.

Acceptance test 2: HTTPS configuration failure

  • Scenario: The API is not configured for HTTPS.
  • Steps:
    1. Attempt to access the API.
    2. The system returns an error message indicating the lack of HTTPS configuration.
  • Expected Result:
    • An error message is returned indicating that secure communication cannot be established.
  • Pass Criteria:
    • A clear error message is returned.

Use Case 22: Documentation Access for New Users

Related User Story: As a new user, I want detailed documentation for setup, configuration, and usage so that I can deploy and use both applications without confusion.

Actors:

  • New User

Preconditions:

  • The documentation is prepared and accessible.

Postconditions:

  • The new user can view and understand the documentation.

Main Flow:

  1. Access Documentation:

    • The new user navigates to the documentation site.

  2. Browse Topics:

  • The user browses through the available topics (setup, configuration, usage).

  1. Read Documentation:

    • The user reads through the documentation to understand how to deploy and use the applications.

  2. Follow Setup Instructions:

    • The user follows the instructions provided in the documentation to set up the applications.

Alternate Flows:

  • Documentation Not Found:
    • If the documentation is unavailable, the user receives an error message indicating that it cannot be found.

Acceptance criteria

Acceptance test 1: Successful access to documentation

  • Scenario: The new user successfully accesses and reads the documentation.
  • Steps:
    1. The new user navigates to the documentation site.
    2. The user reads and follows the documentation.
  • Expected result:
    • The user successfully navigates and uses the documentation for setup.
  • Pass criteria:
    • The user can follow the instructions and set up the applications.

Acceptance test 2: Documentation not found

  • Scenario: The user cannot access the documentation.
  • Steps:
    1. The user tries to access the documentation.
    2. The system returns an error message indicating that the documentation is unavailable.
  • Expected result:
    • An error message indicating the documentation is missing is returned.
  • Pass criteria:
    • The error message clearly indicates the issue.

Clone this wiki locally