System use case specification maintain projects - ESG-Project/documentation GitHub Wiki
← Home / Requirements / System Use Cases / System Use Cases Specification
| Identification | UC04 |
| Use case | Maintain projects |
| Actors | Administrator, Technician |
| Stakeholders and interests | Consulting company: Ability to maintain the projects of each client of the company. |
| Pre-conditions | User is logged into the system as an administrator or technician; Has at least one registered client. |
| Minimum guarantees | System prevents duplicate records. |
| Success guarantees | User performs any CRUD manipulation of projects. |
Main Success Scenario
| User Action | System Response |
|---|---|
| 1. This use case begins when the user selects the option to list projects of a client | 2. The system displays the list of registered projects linked to the client |
| 3. The user accesses the option to register a new project | 4. The system displays the project registration form |
| 5. The user fills in the project's information | 6. The system validates the input |
| 7. The user selects the save option | 8. The system validates all information and saves the project data |
| 9. The system confirms the successful registration of the project |
Alternative Flows
2a Invalid project information
| User Action | System Response |
|---|---|
| 1. The system detects invalid or missing information | |
| 2. The system displays an error message to the user | |
| 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 project
| User Action | System Response |
|---|---|
| 1. The user accesses the option to edit a project | 2. The system displays the project information in an editable form |
| 3. The user modifies the project's information | 4. The system validates the changes |
| 5. The user selects the save option | 6. The system validates all information and updates the project data |
| 7. The system confirms the successful update of the project |
3b Delete project
| User Action | System Response |
|---|---|
| 1. The user accesses the option to delete a project | 2. The system displays a confirmation dialog |
| 3. The user confirms the deletion | 4. The system verifies if the project can be deleted |
| 5. The system removes the project data | |
| 6. The system confirms the successful deletion of the project |
3b.4a Project cannot be deleted
| User Action | System Response |
|---|---|
| 1. The system detects that the project has associated records (e.g., tasks, documents) | |
| 2. The system displays an error message explaining why the project cannot be deleted | |
| 3. The system returns to the projects list |
3c User cancels the action
| User Action | System Response |
|---|---|
| 1. The user cancels the action | 2. The system returns to the projects list without making any changes |
Special Requirements
- Project Information: Must include name, description, start date, end date, status, and client association.
- Duplicate Prevention: The system must check for existing projects with similar information before saving.
- Data Validation: All project information must be validated according to business rules.
- Access Control: Only authorized users can modify project information based on their role.
- Audit Trail: The system must maintain a history of all changes made to project records.
- Soft Delete: When a project is deleted, its information should be archived rather than permanently removed.
- Search Functionality: The system must provide search and filter capabilities for the project list.
- Status Management: The system must support different project statuses (e.g., Planning, In Progress, Completed).
- Client Association: Each project must be associated with a valid client.