System use case specification maintain complements - ESG-Project/documentation GitHub Wiki
← Home / Requirements / System Use Cases / System Use Cases Specification
| Identification | UC10 |
| Use case | Maintain complements |
| Actors | Administrator, Technician |
| Stakeholders and interests | Consulting company: Ability to maintain the complements of each letter. |
| 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 letter. |
| Minimum guarantees | System prevents duplicate records. |
| Success guarantees | User performs any CRUD manipulation of complements. |
Main Success Scenario
| User Action | System Response |
|---|---|
| 1. This use case begins when the user selects the option to list complements of a letter | 2. The system redirects to a list of registered complements linked to the letter |
| 3. The user then accesses the option to register a new complement | 4. The system redirects to the complement registration form |
| 5. The user fills in the complement's information | 6. The system validates the input |
| 7. The user selects the save option | 8. The system validates all information and saves the complement data |
| 9. The system confirms the successful registration of the complement |
Alternative Flows
3a Edit complement
| User Action | System Response |
|---|---|
| 1. The user accesses the option to edit a complement | 2. The system displays the complement information in an editable form |
| 3. The user modifies the complement's information | 4. The system validates the changes |
| 5. The user selects the save option | 6. The system validates all information and updates the complement data |
| 7. The system confirms the successful update of the complement |
3b Delete complement
| User Action | System Response |
|---|---|
| 1. The user accesses the option to delete a complement | 2. The system displays a confirmation dialog |
| 3. The user confirms the deletion | 4. The system verifies if the complement can be deleted |
| 5. The system removes the complement data | |
| 6. The system confirms the successful deletion of the complement |
3c User cancels the action
| User Action | System Response |
|---|---|
| 1. The user cancels the action | 2. The system returns to the complements list without making any changes |
6a Invalid complement 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 complements with similar information before saving.
- Data Validation: All complement information must be validated according to business rules.
- Access Control: Only authorized users can modify complement information based on their role.
- Audit Trail: The system must maintain a history of all changes made to complement records.
- Search Functionality: The system must provide search and filter capabilities for the complement list.
- Sorting Options: Users must be able to sort complements by date, type, and other relevant criteria.