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