Purpose and Business Need
The purpose of this stage was to define what the YongAn staff scheduling system must do and what must remain outside the project scope. The current process separates employee information, certifications, availability, schedules, requests, and attendance. This makes it difficult for a manager to see all relevant information before making a staffing decision.
The proposed system will provide one source of information for staff scheduling and attendance. It will help managers identify conflicts and coverage problems before a schedule is published. It will also give employees a direct way to view schedules and submit requests.
Users and Scope
The system has three user roles:
– Administrators manage accounts, employee records, positions, and system reference information.
– Managers prepare schedules, review requests, correct attendance, and view reports.
– Employees view their published schedules, maintain availability, submit requests, respond to open shifts, request swaps, and record attendance.
The project includes employee and certification management, schedule creation, validation, availability, time off, open shifts, swaps, attendance, notifications, and management reports. Resident records, clinical information, payroll calculation, biometric devices, and government reporting are outside the scope.
Main Functional Requirements
The authentication requirements include secure sign-in, sign-out, active-account checks, sessions, and server-side role restrictions. Managers must be able to create, search, update, and deactivate employee records without deleting historical information. Certifications must include their type, issue information, expiry date, and status.
The scheduling requirements are the centre of the project. Managers must be able to create a schedule period, add shifts, assign employees, validate the schedule, and publish it. Employees should only see published assignments. The server must check overlapping shifts, required rest time, approved leave, availability, expected weekly hours, minimum staffing, and required certifications.
The request requirements cover recurring availability, temporary unavailability, time off, open shifts, and shift swaps. A swap must not change the published schedule until the proposed employee has responded and a manager has approved it.
Attendance requirements include clock-in and clock-out, separate scheduled and actual times, manager corrections, quarter-hour rounding, weekly totals, and overtime above forty hours. Reports must show staffing coverage, qualification gaps, regular hours, overtime, and totals for a selected date range.
Important Business Rules
The main rules are:
– Only active employees can receive new assignments.
– An employee cannot work overlapping shifts.
– Ten hours of rest are required between shifts.
– Approved time off blocks an assignment.
– Certifications must be valid on the date of the shift.
– A draft schedule may be incomplete, but blocking conflicts must be visible.
– Missing required qualifications block publication.
– A general staffing shortage requires a manager explanation before publication.
– Clock-in is available from thirty minutes before the shift until the scheduled end.
– Worked time is rounded to the nearest fifteen minutes.
– Hours above forty in a week are reported as overtime.
Quality Requirements
Security is enforced by the server rather than only by hidden buttons in the interface. Passwords must be hashed, inputs validated, secrets kept outside the source code, and important changes audited. Related database changes must use transactions when partial completion would leave invalid data.
The interface must work on current desktop and mobile browsers. Status cannot be communicated by colour alone, validation messages must be understandable, and common pages should respond quickly under normal use.
Acceptance Direction
The requirements are prioritized so that authentication, employee records, scheduling, validation, and coverage reporting are completed first. Availability, requests, attendance, notifications, and additional reports follow after the scheduling core is stable.
The next stage will analyse how the current process works, how information moves through the proposed system, and how the main workflows should behave before implementation begins.