System use case specification maintain conditionings - ESG-Project/documentation GitHub Wiki
← Home / Requirements / System Use Cases / System Use Cases Specification
| Identification | UC07 |
| Use case | Maintain conditionings |
| Actors | Administrator, Technician |
| Stakeholders and interests | Consulting company: Ability to maintain the conditionings of each license. |
| Pre-conditions | User is logged into the system as an administrator or technician; Has at least one registered client; Has at least one registered project; Has at least one registered environmental license. |
| Minimum guarantees | System prevents duplicate records. |
| Success guarantees | User performs any CRUD manipulation of conditionings. |
Main Success Scenario
| User Action | System Response |
|---|---|
| 1. This use case begins when the user selects the option to list conditionings of a license | 2. The system redirects to a list of registered conditionings linked to the license |
| 3. The user then accesses the option to register a new conditioning | 4. The system redirects to the conditioning registration form |
| 5. The user fills in the conditioning's information | 6. The system validates the input |
| 7. The user selects the save option | 8. The system validates all information and saves the conditioning data |
| 9. The system confirms the successful registration of the conditioning | |
| 10. The system generates a list with the expected expiration dates for the conditioning |
Alternative Flows
3a Edit conditioning
| User Action | System Response |
|---|---|
| 1. The user accesses the option to edit a conditioning | 2. The system displays the conditioning information in an editable form |
| 3. The user modifies the conditioning's information | 4. The system validates the changes |
| 5. The user selects the save option | 6. The system validates all information and updates the conditioning data |
| 7. The system confirms the successful update of the conditioning | |
| 8. The system generates an updated list with the expected expiration dates |
3b Delete conditioning
| User Action | System Response |
|---|---|
| 1. The user accesses the option to delete a conditioning | 2. The system displays a confirmation dialog |
| 3. The user confirms the deletion | 4. The system verifies if the conditioning can be deleted |
| 5. The system removes the conditioning data | |
| 6. The system confirms the successful deletion of the conditioning |
3c User cancels the action
| User Action | System Response |
|---|---|
| 1. The user cancels the action | 2. The system returns to the conditionings list without making any changes |
6a Invalid conditioning information
| User Action | System Response |
|---|---|
| 1. The system detects invalid or missing information | |
| 2. The system displays an error message | |
| 3. The user corrects the information and resubmits | 4. The system validates the corrected information and returns to step 6 of the Main Success Scenario |
Special Requirements
- Duplicate Prevention: The system must check for existing conditionings with similar information before saving.
- Data Validation: All conditioning information must be validated according to business rules.
- Access Control: Only authorized users can modify conditioning information based on their role.
- Audit Trail: The system must maintain a history of all changes made to conditioning records.
- Search Functionality: The system must provide search and filter capabilities for the conditioning list.
- Sorting Options: Users must be able to sort conditionings by date, type, and other relevant criteria.
- Expiration Tracking: The system must track and notify about upcoming conditioning expirations.