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).