System use case specification approve reject specimen data change - ESG-Project/documentation GitHub Wiki

← Home / Requirements / System Use Cases / System Use Cases Specification

Identification	UC32
Use case	Approve/Reject Specimen Data Change
Actors	Administrator, Moderator
Stakeholders and interests	Data Administrator: Needs to maintain the integrity and accuracy of specimen data by reviewing and finalizing change requests. Field Technician: Requires timely feedback on their submitted data corrections.
Pre-conditions	The Administrator/Moderator is viewing a pending specimen data change request (e.g., from UC31).
Minimum guarantees	System ensures a reason is provided for rejected requests.
Success guarantees	The change request's status is updated; if approved, specimen data is updated and relevant calculations are redone; the requester is notified of the decision.

Main Success Scenario

User Action	System Response
1. This use case begins when the Administrator/Moderator selects a pending specimen data change request from the list (from UC31).	2. The system displays the details of the request, including the original specimen data, the proposed changes, and the user's justification comment. All fields (e.g., Plot, Species, Height, CBH, Family, DBH, Basal Area) are shown with their current and proposed values.
3. The Administrator/Moderator reviews the information and evaluates the proposed changes.	4. The Administrator/Moderator chooses either "Approve" or "Reject."
If Approve:
5. The Administrator/Moderator confirms approval.	6. The system updates the specimen data (Plot, Species, Height, CBH) with the proposed information.
	7. The system automatically updates the Family field if the Species was changed and recalculates DBH and Basal Area.
	8. The system changes the request status to "Approved" and records the alteration in the specimen's historical log.
	9. The system notifies the original requesting user about the approval.
	10. The system confirms successful approval and data update.
If Reject:
5. The Administrator/Moderator chooses "Reject."	6. The system prompts the Administrator/Moderator to provide a mandatory reason for the rejection.
7. The Administrator/Moderator enters the rejection reason.	8. The system changes the request status to "Rejected" and records the reason.
	9. The system notifies the original requesting user about the rejection and the reason provided.
	10. The system confirms successful rejection.

Special Requirements

• Approval Actions: Upon approval, update specimen data, recalculate DBH and Basal Area, update Family (if necessary), and log the change.
• Rejection Requirement: Rejection must require a reason.
• Requester Notification: The original requester must be notified of the decision and the reason (if rejected).

Related Documents

• System Business Rule Specification: Request Approval or Rejection (BR15)
• User Story: US024