hakiba67/csms-space at main

79.3 kB

Ctrl+K

1 contributor

1.1 Purpose This System Design Document (SDD) provides a technical blueprint for the Civil Service Management System (CSMS) phase 1, detailing its architecture, components, data models, interfaces, and deployment strategies. It guides developers, testers, and stakeholders to ensure consistent implementation, aligning with the Software Requirements Specification (SRS) and Inception Report provided. 1.2 Scope The CSMS phase 1 automates HR operations for the CSC, covering the following modules: • Employee Confirmation • Leave Without Pay (LWOP) • Promotion • Complaints • Change of Cadre • Retirement • Resignation (Employee) • Service Extension • Termination • Dismissal • Authentication & Authorization • Dashboard • Employee Profile Management • Reports & Analytics • Audit Trail Out-of-Scope: • Payroll and pension system integration. • Recruitment modules. • Mobile app development (planned for phase 2). The system integrates solely with HRIMS to fetch employee data, with no connections to payroll or pension systems. 1.3 Timeline The project spans from May 20, 2025, to December 9, 2025, with milestones for requirements gathering, design, development, testing, and deployment. 2. System Overview 2.1 System Description The CSMS is a web-based platform to manage the civil servant lifecycle, from confirmation to retirement or dismissal. It supports user roles (HR Officer (HRO), HR Management Officer (HRMO), Head of HR Management (HHRMD), Disciplinary Officer (DO), Employees) with role-based access control (RBAC). The system automates HR processes, provides real-time dashboards and reports, and ensures compliance through immutable audit trails. 2.2 Key Objectives • Automate HR processes (e.g., confirmations, promotions, complaints). • Provide real-time insights for decision-making. • Ensure data security, auditability, and compliance with CSC business plan. • Support scalability for 50,000+ employee records. 2.3 Key Features • Secure authentication with RBAC and multi-factor authentication (MFA). • CRUD operations for employee profiles with document uploads (PDF, ≤2MB). • Automated HR processes with approval/rejection by HHRMD/HRMO or HHRMD/DO, notifying HRO. • Real-time dashboards with role-based widgets and alerts. • Customizable reports in PDF/Excel formats with date-based filtering. • Integration with HRIMS for data fetching. • Immutable audit trails for all actions. 3. System Architecture 3.1 Architectural Style The CSMS adopts a microservices-based architecture for scalability, modularity, and maintainability, using a layered approach: • Presentation Layer: Angular 15+ frontend, WCAG 2.1 AA-compliant. • Application Layer: Spring Boot 3 (Java 17) for business logic and REST APIs. • Data Layer: PostgreSQL 14 with read replicas for high availability. • Integration Layer: Apache Camel for HRIMS integration (SOAP/REST). • Security Layer: Keycloak for OAuth 2.0/OIDC authentication and RBAC. 3.2 System Components The system is structured into layers: • Frontend: Angular 15+ with TypeScript, HTML5, CSS3, and Tailwind CSS. • Backend Services: o Authentication Service (Keycloak integration). o Employee Profile Service (CRUD operations for admin only). o Workflow Services (Confirmation, LWOP, Promotion, etc.). o Reporting Service (PDF/Excel generation). o Audit Trail Service (logging user actions). • Database: PostgreSQL 14 in a clustered configuration with read replicas. • Integration: Apache Camel for HRIMS data fetching. • Notifications: Email (SMTP) and in-system alerts for status updates and SLA breaches. Architecture Diagram PlantUML Code for Architecture Diagram @startuml skinparam titleFontSize 20 skinparam titleFontColor #00008B skinparam titleFontName Arial title System Architecture package "Presentation Layer" { [Angular 15+ Frontend] } package "Application Layer" { [Spring Boot 3 Microservices] } package "Data Layer" { [PostgreSQL 14 Database] } package "Integration Layer" { [Apache Camel] } package "Security Layer" { [Keycloak] } [Angular 15+ Frontend] -> [Spring Boot 3 Microservices] [Spring Boot 3 Microservices] -> [PostgreSQL 14 Database] [Spring Boot 3 Microservices] -> [Apache Camel] [Spring Boot 3 Microservices] -> [Keycloak] @enduml 4. Module Design Each module is a microservice with its own API endpoints, business logic, and database interactions. Below are the designs, with workflows detailed in Appendix D. 4.1 Authentication & Authorization • Purpose: Secure user access with RBAC. • Components: o Keycloak for authentication (OAuth 2.0/OIDC). o Custom RBAC for roles (HRO, HRMO, HHRMD, DO, Employee,… etc). o Password recovery via OTP (60-minute expiry). • APIs: o POST /auth/login: Authenticate user. o POST /auth/otp: Generate OTP for recovery. o GET /auth/roles: Fetch user roles and permissions. • Non-Functional: o 99.9% availability. o Login response time <1.5 seconds for 95% of users. o Audit logging of authentication attempts. 4.2 Dashboard • Purpose: Provide role-based, real-time insights and module access. • Components: o Angular components for widgets (charts, tables, alerts). o REST API for real-time data (e.g., pending requests). • APIs: o GET /dashboard/summary: Fetch pending request counts. o GET /dashboard/alerts: Fetch SLA deadline alerts. • Non-Functional: o Load time <5 seconds. o Responsive on desktop and tablet (WCAG 2.1 AA). o Data restricted by RBAC. 4.3 Employee Profile Management • Purpose: Manage employee records with CRUD operations. • Components: o Angular forms for profile creation/editing. o Spring Boot service for CRUD operations. o PostgreSQL tables for employee data and documents. • APIs: o POST /employees: Create profile. o GET /employees/{id}: Retrieve details. o PUT /employees/{id}: Update profile. o DELETE /employees/{id}: Deactivate profile. o POST /employees/search: Search by name, zan_id, or department. • Non-Functional: o Search response time <1 second for 10,000 records. o Document encryption with AES-256. 4.4 HR Workflow Modules • Modules: Confirmation, LWOP, Promotion, Change of Cadre, Retirement, Resignation, Service Extension, Termination, Dismissal. • Purpose: Automate HR processes with forms and approval mechanisms. • Components: o Angular forms for request submission with document uploads (PDF, ≤2MB). o Spring Boot service for request processing and status updates. o PostgreSQL tables for requests and documents. • APIs: o POST /{module}: Submit request (e.g., /confirmation, /termination). o GET /{module}/{id}: View request status. o PUT /{module}/{id}/approve: Approve request (HHRMD/HRMO or HHRMD/DO). o PUT /{module}/{id}/reject: Reject request with reason (HHRMD/HRMO or HHRMD/DO). • Details: See Appendix D for workflows. • Non-Functional: o Form load time <3 seconds. o Audit logging of all actions. 4.5 Complaints Module • Purpose: Allow employees to submit and track complaints which will be resolved by HHRMD or DO. • Components: o Angular form for complaint submission with category selection and evidence upload. o Spring Boot service for complaint management. o PostgreSQL tables for complaints and documents. • APIs: o POST /complaints: Submit complaint (Employee). o GET /complaints/{id}: View complaint status. o PUT /complaints/{id}/approve: Resolve complaint (HHRMD/DO). o PUT /complaints/{id}/reject: Reject complaint with reason (HHRMD/DO). • Details: See Appendix D for workflow. • Non-Functional: o Form load time <3 seconds. o Audit logging of all actions. 4.6 Reports & Analytics • Purpose: Generate customizable reports in PDF/Excel formats for HR processes, with date or date interval selection. • Components: o Frontend: Angular interface with drag-and-drop report builder, date pickers, and filters (e.g., ministry, gender). o Backend: Spring Boot service using JasperReports for PDF/Excel generation, querying PostgreSQL. o Database: PostgreSQL tables (Employee, Request, Complaint) with indexed fields. • Report Types (see Appendix F for formats): 1. Service Extension: Lists employees with extended service periods. 2. Retirement (Compulsory): Lists employees retiring at mandatory age. 3. Retirement (Voluntary): Lists employees retiring early. 4. Retirement (Illness): Lists employees retiring due to illness. 5. Leave Without Pay (LWOP): Lists employees on leave without pay. 6. Promotion in Position/Rank: Summarizes promotions by Institution. 7. Termination and Dismissal: Lists termination/dismissal cases. 8. Complaints: Lists employee complaints and resolutions. 9. Change of Cadre: Lists employees with cadre changes. 10. Employee Resignation: Lists approved resignations. 11. Confirmation of Employment: Lists confirmed employees. • APIs: o POST /reports/generate: Generate report (parameters: report_type, date_from, date_to, ministry, gender, etc.). o GET /reports/templates: List report types and fields. o GET /reports/{id}: Retrieve generated report (PDF/Excel). • Non-Functional: o Report generation time <30 seconds for 10,000 records. o Supports 100 concurrent users. o PDF/Excel files <10MB, optimized for printing. o Audit logging of report generation. 4.7 Audit Trail • Purpose: Display immutable audit logs for compliance. • Components: o Angular table for viewing logs with filters (date range, user, action). o Spring Boot service for log retrieval. • APIs: o GET /audit-logs: Retrieve logs with pagination and filtering. • Non-Functional: o Log retrieval time <5 seconds for 1-year range. 5. Data Model 5.1 Key Entities Entity Key Fields Constraints Employee employee_id (PK), full_name, zan_id, payroll_number, zssf_number, cadre, date_of_appointment, status (Confirmed/Not Confirmed), department, date_of_birth, gender, phone_number Unique zan_id, payroll_number, zssf_number User user_id (PK), username, email, role_id (FK), status (Active/Inactive) Unique username, email Role role_id (PK), role_name (e.g., HRO, HRMO, HHRMD, DO), permissions (JSONB) Unique role_name Document document_id (PK), employee_id (FK), request_id (FK), file_name, file_type (PDF), file_size (≤2MB), encrypted_content (BYTEA) File size ≤2MB Request request_id (PK), employee_id (FK), request_type (ENUM: Confirmation, LWOP, Promotion, Cadre Change, Retirement, Resignation, Service Extension, Termination, Dismissal), status (Pending, Approved, Rejected), created_by (FK), approver_id (FK), details (JSONB, e.g., start_date, reason), submission_date, decision_date Foreign keys for integrity Complaint complaint_id (PK), employee_id (FK), category (ENUM: Unconfirmed Employees, Job-Related, Other), status (Pending, Resolved, Rejected), details (JSONB), submission_date Foreign key for employee_id Audit_Log log_id (PK), user_id (FK), request_id (FK), action, timestamp, before_value (JSONB), after_value (JSONB) Immutable logs with SHA-256 signing 5.2 Entity Relationship Diagram (ERD) [Employee] --1:N--> [Document] [Employee] --1:N--> [Request] [Employee] --1:N--> [Complaint] [User] --N:1--> [Role] [User] --1:N--> [Audit_Log] [Request] --1:N--> [Audit_Log] [Complaint] --1:N--> [Audit_Log] [Request] --1:N--> [Document] PlantUML Code for ERD @startuml entity Employee { * employee_id : VARCHAR(50) <<PK>> -- full_name : VARCHAR(100) <<Not Null>> zan_id : VARCHAR(20) <<Unique, Not Null>> payroll_number : VARCHAR(20) <<Unique, Not Null>> zssf_number : VARCHAR(20) <<Unique, Not Null>> cadre : VARCHAR(50) <<Not Null>> date_of_appointment : DATE <<Not Null>> status : ENUM('Confirmed', 'Not Confirmed') <<Not Null>> department : VARCHAR(100) date_of_birth : DATE gender : ENUM('Male', 'Female') phone_number : VARCHAR(15) } entity User { * user_id : VARCHAR(50) <<PK>> -- username : VARCHAR(50) <<Unique, Not Null>> email : VARCHAR(100) <<Unique, Not Null>> password_hash : VARCHAR(256) <<Not Null>> role_id : VARCHAR(50) <<FK, Not Null>> status : ENUM('Active', 'Inactive') <<Not Null>> } entity Role { * role_id : VARCHAR(50) <<PK>> -- role_name : VARCHAR(50) <<Not Null>> permissions : JSONB <<Not Null>> } entity Document { * document_id : VARCHAR(50) <<PK>> -- employee_id : VARCHAR(50) <<FK, Not Null>> request_id : VARCHAR(50) <<FK, Nullable>> file_name : VARCHAR(100) <<Not Null>> file_type : ENUM('PDF') <<Not Null>> file_size : INTEGER <<Not Null, <=2MB>> encrypted_content : BYTEA <<Not Null>> } entity Request { * request_id : VARCHAR(50) <<PK>> -- employee_id : VARCHAR(50) <<FK, Not Null>> request_type : ENUM('Confirmation', 'LWOP', 'Promotion', 'Cadre Change', 'Retirement', 'Resignation', 'Service Extension', 'Termination', 'Dismissal') <<Not Null>> status : ENUM('Pending', 'Approved', 'Rejected') <<Not Null>> created_by : VARCHAR(50) <<FK, Not Null>> approver_id : VARCHAR(50) <<FK, Nullable>> details : JSONB submission_date : DATE <<Not Null>> decision_date : DATE } entity Complaint { * complaint_id : VARCHAR(50) <<PK>> -- employee_id : VARCHAR(50) <<FK, Not Null>> category : ENUM('Unconfirmed Employees', 'Job-Related', 'Other') <<Not Null>> status : ENUM('Pending', 'Resolved', 'Rejected') <<Not Null>> details : JSONB submission_date : DATE <<Not Null>> } entity Audit_Log { * log_id : VARCHAR(50) <<PK>> -- user_id : VARCHAR(50) <<FK, Not Null>> request_id : VARCHAR(50) <<FK, Nullable>> action : VARCHAR(100) <<Not Null>> timestamp : TIMESTAMP <<Not Null>> before_value : JSONB after_value : JSONB } Employee ||--o{ Document Employee ||--o{ Request Employee ||--o{ Complaint User }o--|| Role User ||--o{ Audit_Log Request ||--o{ Audit_Log Complaint ||--o{ Audit_Log Request ||--o{ Document @enduml 6. Interface Design 6.1 User Interface (UI) • Framework: Angular 15+ with Tailwind CSS for responsive design. • Key Screens: o Login Screen: Username/password input, OTP recovery. o Dashboard: Role-based widgets (pending requests, alerts, quick links). o Employee Profile: CRUD forms with search/filter functionality. o HR Workflow Forms: Standardized forms for each module with document upload. o Complaints: Form for submitting complaints with category selection. o Reports: Drag-and-drop interface with date pickers, ministry/gender filters, and export options (PDF/Excel). o Audit Trail: Table view of logs with filtering. • Accessibility: WCAG 2.1 AA-compliant (keyboard navigation, screen reader support). 6.2 API Design • Base URL: /api/v1 • Endpoints (examples): o GET /employees/{id}: Retrieve employee profile. o POST /confirmation: Submit confirmation request. o PUT /complaints/{id}/approve: Resolve complaint. o POST /reports/generate: Generate report. • Response Format: JSON with { "status": "success", "data": {...}, "message": "Operation completed" }. • Error Handling: HTTP status codes (400, 401, 403, 500) with descriptive messages. 7. Integration Design 7.1 HRIMS Integration • Purpose: Fetch employee data from HRIMS for synchronization. • Technology: Apache Camel for SOAP/REST connectors. • APIs: o GET /hrims/employees: Fetch employee records. • Error Handling: Fallback to CSV import/export for API failures. • Note: No integration with payroll or pension systems. 7.2 Notification System • Email: SMTP server for approvals, rejections, and SLA breaches. • In-System Alerts: Stored in PostgreSQL, displayed on Dashboard. • Triggers: o Request status changes (Approved/Rejected). o SLA breaches. 8. Security Design • Authentication: Keycloak with OAuth 2.0/OIDC, supporting username/password and MFA. • Authorization: RBAC with roles (HRO, HRMO, HHRMD, DO, Employee). • Data Protection: o AES-256 encryption for documents and sensitive fields at rest. o TLS 1.3 for data in transit. • Audit Trail: Immutable logs with SHA-256 signing. • Security Measures: o Account lockout after 5 failed login attempts (15-minute lock). o OTP for password recovery (60-minute expiry). o Regular security audits and penetration testing. 9. Non-Functional Requirements Implementation • Performance: o Database query optimization with indexing and Redis caching. o Response time <2 seconds for 95% of transactions under 1,000 concurrent users. • Availability: o 99.9% uptime with clustered PostgreSQL and failover. o Scheduled maintenance communicated in advance. • Scalability: o Supports 50,000+ employee records with read replicas. • Compliance: o Audit logs retained in WORM format for 10 years. o Adheres to CSC regulations and data privacy laws. • Usability: o Intuitive UI requiring ≤1 hour training. o Responsive design for desktop and tablet. 10. Deployment Strategy • Environment: o Development: Local /online servers for coding and testing. o Staging: Virtual machine (VM) on government’s data center server, mirroring production. o Production: Single physical server with virtualization. • Virtualization Platform: VMware ESXi or Proxmox for isolated VMs: o Frontend VM: Angular 15+, 4 vCPUs, 8GB RAM, 50GB storage. o Backend VM: Spring Boot 3, 8 vCPUs, 16GB RAM, 100GB storage. o Database VM: PostgreSQL 14, 8 vCPUs, 32GB RAM, 500GB SSD. o Security VM: Keycloak, 4 vCPUs, 8GB RAM, 50GB storage. • Deployment Process: o Rolling updates for microservices to minimize downtime. o Blue-green deployment for major releases using VM snapshots. • Backup and Recovery: o Daily backups to a separate partition, retained for 30 days. o Offsite archival for 10-year compliance. • Monitoring: o Prometheus and Grafana for system health and performance. o Alerts for CPU, memory, disk usage, and suspicious activities. • Infrastructure: o Server: ≥32 cores, ≥128GB RAM, ≥1TB SSD, redundant power supplies. o Network: Dedicated VLAN with firewall rules. 11. Testing Strategy • Unit Testing: JUnit for Spring Boot, Jest for Angular. • Integration Testing: Test API endpoints and HRIMS integration. • Performance Testing: Load test for 1,000 concurrent users. • Security Testing: Penetration testing and vulnerability scans. • User Acceptance Testing (UAT): o Conducted with CSC stakeholders (HRO, HRMO, HHRMD, DO, Employees and other external users). o Validates modules, UI, and reports. o Scheduled for November 4, 2025. 12. Maintenance and Support • Maintenance: o Regular updates for Angular, Spring Boot, and PostgreSQL. o Bug fixes and performance optimizations during sprints. • Support: o Helpdesk managed by CSC ICT Support Staff. o User manuals and training materials provided. • Monitoring: o Real-time monitoring via Prometheus/Grafana. o Alerts for system health and security issues. 13. Assumptions and Constraints 13.1 Assumptions • Reliable internet connectivity (≥5Mbps) at Government offices. • Users complete 8-hour mandatory training. • Stable HRIMS APIs with consistent data formats. • Primary use during working hours (Monday–Friday, 8:00 AM–5:00 PM EAT). • Government data center provides stable power, cooling, and network infrastructure. • Users have access to modern browsers (Chrome, Firefox, Edge) on desktops or tablets. 13.2 Constraints • Integration limited to HRIMS; no payroll or pension system integration. • 12-month parallel run with HRIMS for data synchronization. • Web-based platform only (no mobile app in phase 1). • Deployment on a single physical server with virtualization. • Project completion within budget and timeline (May 20, 2025–December 9, 2025). 14. Risk Mitigation Strategies Risk Description Mitigation Strategy Inaccurate HRIMS Data Inconsistent employee data from HRIMS. Validation checks; admin CRUD permissions; audit logs. HRIMS Integration Failures Unstable APIs or connectivity issues. Apache Camel with retries; CSV fallback; error logging. Security Breaches Unauthorized access or data leaks. AES-256 encryption, RBAC, MFA, TLS 1.3; audits; lockout after 5 failed attempts. Performance Issues High concurrency or large datasets. Query optimization; Redis caching; sufficient VM resources. Server Failure Hardware failure causing downtime. Daily VM snapshots; backups; offsite archival; redundant power. User Resistance Resistance to system adoption. Training; UAT involvement; manuals and helpdesk. Scope Creep Additional feature requests. Adhere to SRS; defer any feature requests to phase 2; stakeholder communication. 15. Appendices 15.1 Appendix A: Entity Relationship Diagram (ERD) Provided in Section 5.2 with PlantUML representation. 15.2 Appendix B: UI Prototypes UI mockups in Figma, covering: • Login Screen • Dashboard (role-based widgets) • Employee Profile (CRUD forms) • HR Workflow Forms (Confirmation, LWOP, etc.) • Complaints (category selection, evidence upload) • Reports (drag-and-drop interface) • Audit Trail (log table with filters) Link: Figma Prototypes (placeholder; actual link to be provided at later stage). 15.3 Appendix C: API Specification OpenAPI 3.0 specification for endpoints (e.g., /employees, /confirmation). Key details: • JSON responses with standardized format. • JWT-based authentication via Keycloak. • Error codes: 400, 401, 403, 500. Link: OpenAPI Specification (placeholder; actual link to be provided). 15.4 Appendix D: Sample Workflows Detailed workflows for all phase 1 HR modules, including actors, text-based flows, and PlantUML diagrams. Workflow 1: Employee Confirmation Purpose: Automate confirmation after a 12-month probation period. Actors: HRO (user3, ajuma), HHRMD/HRMO (user2, msmith), Employee (emp1, Ali Juma Ali, zan_id: 221458232). Text-Based Flow: [Start] → [HRO Login] → [Navigate to Confirmation] → [Submit Request with Employee Details and Documents] → [HHRMD/HRMO Login] → [Review Request and Documents] → [Approve or Reject with Reason] → [Update Employee Status] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to Confirmation; :Submit Request with Employee Details and Documents; :HHRMD/HRMO Login; :Review Request and Documents; if (Decision?) then (Approve) :Approve Request; :Update Employee Status to Confirmed; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml Workflow 2: Leave Without Pay (LWOP) Purpose: Automate LWOP requests for specified durations. Actors: HRO (user3, ajuma), HHRMD/HRMO (user2, msmith), Employee (emp3, Fatma Said Omar, zan_id: 334589123). Text-Based Flow: [Start] → [HRO Login] → [Navigate to LWOP] → [Submit Request with Duration and Documents] → [HHRMD/HRMO Login] → [Review Request and Documents] → [Approve or Reject with Reason] → [Update Request Status] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to LWOP; :Submit Request with Duration and Documents; :HHRMD/HRMO Login; :Review Request and Documents; if (Decision?) then (Approve) :Approve Request; :Update Request Status; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml Workflow 3: Promotion Purpose: Automate promotion based on qualifications/performance. Actors: HRO (user3, ajuma), HHRMD/HRMO (user2, msmith), Employee (emp2, Safia Juma Ali, zan_id: 125468957). Text-Based Flow: [Start] → [HRO Login] → [Navigate to Promotion] → [Submit Request with Performance Records and Documents] → [HHRMD/HRMO Login] → [Review Request and Documents] → [Approve or Reject with Reason] → [Update Employee Cadre/Status] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to Promotion; :Submit Request with Performance Records and Documents; :HHRMD/HRMO Login; :Review Request and Documents; if (Decision?) then (Approve) :Approve Request; :Update Employee Cadre/Status; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml Workflow 4: Complaints Purpose: Manage employee complaints with resolution. Actors: Employee (emp3, user7, hmohamed), HHRMD/DO (user5, kabdul). Text-Based Flow: [Start] → [Employee Login] → [Navigate to Complaints] → [Submit Complaint with Category and Evidence] → [HHRMD/DO Login] → [Review Complaint and Evidence] → [Resolve or Reject with Reason] → [Update Complaint Status] → [Notify HRO and Employee via Email/In-System Alert] → [End] PlantUML Code: @startuml start :Employee Login; :Navigate to Complaints; :Submit Complaint with Category and Evidence; :HHRMD/DO Login; :Review Complaint and Evidence; if (Decision?) then (Resolve) :Resolve Complaint; else (Reject) :Reject Complaint with Reason; endif :Update Complaint Status; :Notify HRO and Employee via Email/In-System Alert; stop @enduml Workflow 5: Change of Cadre Purpose: Update employee cadre based on qualifications. Actors: HRO (user3, ajuma), HHRMD/HRMO (user2, msmith), Employee (emp4, Hassan Mzee Juma, zan_id: 445678912). Text-Based Flow: [Start] → [HRO Login] → [Navigate to Cadre Change] → [Submit Request with New Cadre Details and Documents] → [HHRMD/HRMO Login] → [Review Request and Documents] → [Approve or Reject with Reason] → [Update Employee Cadre] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to Cadre Change; :Submit Request with New Cadre Details and Documents; :HHRMD/HRMO Login; :Review Request and Documents; if (Decision?) then (Approve) :Approve Request; :Update Employee Cadre; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml Workflow 6: Retirement Purpose: Automate retirement processing (compulsory, voluntary, illness). Actors: HRO (user3, ajuma), HHRMD/HRMO (user2, msmith), Employee (emp5, Zainab Ali Khamis, zan_id: 556789345). Text-Based Flow: [Start] → [HRO Login] → [Navigate to Retirement] → [Submit Request with Retirement Type and Documents] → [HHRMD/HRMO Login] → [Review Request and Documents] → [Approve or Reject with Reason] → [Update Employee Status] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to Retirement; :Submit Request with Retirement Type and Documents; :HHRMD/HRMO Login; :Review Request and Documents; if (Decision?) then (Approve) :Approve Request; :Update Employee Status; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml Workflow 7: Resignation Purpose: Process employee resignations. Actors: HRO (user3, ajuma), HHRMD/HRMO (user2, msmith), Employee (emp3, Fatma Said Omar, zan_id: 334589123). Text-Based Flow: [Start] → [HRO Login] → [Navigate to Resignation] → [Submit Request with Documents] → [HHRMD/HRMO Login] → [Review Request and Documents] → [Approve or Reject with Reason] → [Update Employee Status] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to Resignation; :Submit Request with Documents; :HHRMD/HRMO Login; :Review Request and Documents; if (Decision?) then (Approve) :Approve Request; :Update Employee Status; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml Workflow 8: Service Extension Purpose: Extend employee service beyond retirement age. Actors: HRO (user3, ajuma), HHRMD/HRMO (user2, msmith), Employee (emp5, Zainab Ali Khamis, zan_id: 556789345). Text-Based Flow: [Start] → [HRO Login] → [Navigate to Service Extension] → [Submit Request with Extension Details and Documents] → [HHRMD/HRMO Login] → [Review Request and Documents] → [Approve or Reject with Reason] → [Update Retirement Date/Status] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to Service Extension; :Submit Request with Extension Details and Documents; :HHRMD/HRMO Login; :Review Request and Documents; if (Decision?) then (Approve) :Approve Request; :Update Retirement Date/Status; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml Workflow 9: Termination Purpose: Process employee termination due to misconduct. Actors: HRO (user3, ajuma), HHRMD/DO (user2, msmith), Employee (emp4, Hassan Mzee Juma, zan_id: 445678912). Text-Based Flow: [Start] → [HRO Login] → [Navigate to Termination] → [Submit Request with Misconduct Evidence] → [HHRMD/DO Login] → [Review Request and Evidence] → [Approve or Reject with Reason] → [Update Employee Status] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to Termination; :Submit Request with Misconduct Evidence; :HHRMD/DO Login; :Review Request and Evidence; if (Decision?) then (Approve) :Approve Request; :Update Employee Status; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml Workflow 10: Dismissal Purpose: Process employee dismissal due to severe misconduct. Actors: HRO (user3, ajuma), HHRMD/DO (user2, msmith), Employee (emp6, Juma Omar Ali, zan_id: 667890456). Text-Based Flow: [Start] → [HRO Login] → [Navigate to Dismissal] → [Submit Request with Misconduct Evidence] → [HHRMD/DO Login] → [Review Request and Evidence] → [Approve or Reject with Reason] → [Update Employee Status] → [Notify HRO via Email/In-System Alert] → [End] PlantUML Code: @startuml start :HRO Login; :Navigate to Dismissal; :Submit Request with Misconduct Evidence; :HHRMD/DO Login; :Review Request and Evidence; if (Decision?) then (Approve) :Approve Request; :Update Employee Status; else (Reject) :Reject Request with Reason; :Update Request Status; endif :Notify HRO via Email/In-System Alert; stop @enduml 15.5 Appendix E: Sample Data Table Entity ID Employee ID Description Employee emp1_id emp1 Ali Juma Ali, zan_id: 221458232, Confirmation Employee emp2_id emp2 Safia Juma Ali, zan_id: 125468957, Promotion Employee emp3_id emp3 Fatma Said Omar, zan_id: 334589123, LWOP, Resignation, Complaints Employee emp4_id emp4 Hassan Mzee Juma, zan_id: 445678912, Cadre Change, Termination Employee emp5_id emp5 Zainab Ali Khamis, zan_id: 556789345, Retirement, Service Extension Employee emp6_id emp6 Juma Omar Ali, zan_id: 667890456, Dismissal Employee emp7_id emp7 Hamid Khalfan Abdalla, zan_id: 778901234, Service Extension Employee emp8_id emp8 Khamis Mcha Machano, zan_id: 889012345, Compulsory Retirement Employee emp9_id emp9 Zahran Ali Hamad, zan_id: 990123456, Voluntary Retirement Employee emp10_id emp10 Khamis Omar Moh’d, zan_id: 101234567, Illness Retirement Employee emp11_id emp11 Mgeni Mussa Haji, zan_id: 112345678, LWOP Employee emp12_id emp12 Salum Omar Haji, zan_id: 123456789, Dismissal Employee emp13_id emp13 Shehe Omar Yussuf, zan_id: 134567890, Cadre Change Employee emp14_id emp14 Feisal Ali Salum, zan_id: 145678901, Resignation User user3_id user3 HRO, username: ajuma, submits requests (all except Complaints) User user2_id user2 HHRMD/HRMO, username: msmith, approves/rejects Confirmation, LWOP, Promotion, Cadre Change, Retirement, Resignation, Service Extension User user5_id user5 DO, username: kabdul, approves/rejects Complaints, Termination, Dismissal User user7_id user7 Employee, username: hmohamed, submits Complaints Request req1_id–req10_id req1–req10 Requests for Confirmation, LWOP, Promotion, Cadre Change, Retirement, Resignation, Service Extension, Termination, Dismissal Complaint comp3_id comp3 Complaint by emp3, category: Unconfirmed Employees Audit_Log log8_id–log37_id log8–log37 Logs for login, request creation, approval/rejection, report generation 15.6 Appendix F: Sample Report Formats Structured formats for all phase 1 report types, based on provided sample data. Report 1: Service Extension S/N Name Ministry/Institution Position Gender (M/F) Total Start Date End Date 1 Hamid Khalfan Abdalla Afisi ya Rais Fedha na Mipango Dereva M:1, F:0 1 01/07/2025 30/06/2026 2 Subira Juma Abdalla BLM Katibu Mahasusi M:0, F:1 1 14/12/2024 13/12/2026 3 Somoe Said Mussa Wizara ya Elimu na Mafunzo ya Amali Afisa Elimu M:0, F:1 1 01/02/2025 31/01/2027 Total M:1, F:2 3 Report 2: Retirement (Compulsory) S/N Name Ministry/Institution Gender (M/F) Total Position Date of Birth Retirement Date 1 Khamis Mcha Machano Wizara ya Elimu na Mafunzo ya Amali M:1, F:0 1 Mwalimu 1965 30/06/2025 2 Biubwa Said Seif Wizara ya Elimu na Mafunzo ya Amali M:0, F:1 1 Mwalimu 1965 30/06/2025 3 Khamis Ali Makame Baraza la Mji Mkoani M:1, F:0 1 Tarishi 15/06/1965 14/06/2025 Total M:2, F:1 3 Report 3: Retirement (Voluntary) S/N Name Ministry/Institution Position Gender (M/F) Total Date of Birth Age 1 Zahran Ali Hamad Wizara ya Afya Mfamasia M:1, F:0 1 09/02/1970 55 2 Omar Said Omar WEMA Mwalimu M:1, F:0 1 26/06/1966 58 3 Asha Khamis Mwinshehe Wizara ya Biashara na Viwanda Afisa Viwanda M:0, F:1 1 30/05/1966 57 Total M:2, F:1 3 - Initial Deployment

272646f verified about 1 year ago