System use case specification maintain clients - ESG-Project/documentation GitHub Wiki
← Home / Requirements / System Use Cases / System Use Cases Specification
| Identification | UC03 |
| Use case | Maintain clients |
| Actors | Administrator, Technician |
| Stakeholders and interests | Consulting company: Ability to maintain information about the company's clients. |
| Pre-conditions | User is logged into the system as an administrator or technician. |
| Minimum guarantees | System prevents duplicate records. |
| Success guarantees | User performs any CRUD manipulation of clients. |
Main Success Scenario
| User Action | System Response |
|---|---|
| 1. This use case begins when the user selects the option to list clients | 2. The system displays the list of registered clients |
| 3. The user accesses the option to register a new client | 4. The system displays the client registration form |
| 5. The user fills in the client's information | 6. The system validates the input |
| 7. The user selects the save option | 8. The system validates all information and saves the client data |
| 9. The system confirms the successful registration of the client |
Alternative Flows
2a Invalid client 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 |
3a Edit client
| User Action | System Response |
|---|---|
| 1. The user accesses the option to edit a client | 2. The system displays the client information in an editable form |
| 3. The user modifies the client's information | 4. The system validates the changes |
| 5. The user selects the save option | 6. The system validates all information and updates the client data |
| 7. The system confirms the successful update of the client |
3b Delete client
| User Action | System Response |
|---|---|
| 1. The user accesses the option to delete a client | 2. The system displays a confirmation dialog |
| 3. The user confirms the deletion | 4. The system verifies if the client can be deleted |
| 5. The system removes the client data | |
| 6. The system confirms the successful deletion of the client |
3b.4a Client cannot be deleted
| User Action | System Response |
|---|---|
| 1. The system detects that the client has associated records (e.g., proposals, projects) | |
| 2. The system displays an error message explaining why the client cannot be deleted | |
| 3. The system returns to the clients list |
3c User cancels the action
| User Action | System Response |
|---|---|
| 1. The user cancels the action | 2. The system returns to the clients list without making any changes |
Special Requirements
- Client Information: Must include name, contact information, address, and other relevant business details.
- Duplicate Prevention: The system must check for existing clients with similar information before saving.
- Data Validation: All client information must be validated according to business rules.
- Access Control: Only authorized users can modify client information based on their role.
- Audit Trail: The system must maintain a history of all changes made to client records.
- Soft Delete: When a client is deleted, their information should be archived rather than permanently removed.
- Search Functionality: The system must provide search and filter capabilities for the client list.
- Export Option: The system must allow exporting client information to common formats (e.g., PDF, Excel).