HR software requirements should describe employment events, authoritative decisions, effective-dated data, employee and manager tasks, controls and evidence. A module list cannot show whether hire, change, leave or exit works across HR, payroll, identity and the business.
Start with the event and its consequence. Protect sensitive information and keep unknown policy decisions visible rather than asking the product to define them.
Set the workforce boundary
Define countries, entities, worker types, locations, languages, bargaining or policy variation and systems in scope. Name the employee populations and HR services the solution must support.
Separate current scope from future expansion. Global language without current jurisdiction detail creates requirements that cannot be tested.
Model employment events
Use hire, transfer, promotion, compensation change, absence, leave, return, termination and rehire. For each, define trigger, authority, effective date, required data, participants, downstream action and evidence.
Include correction, cancellation and retroactive change. HR data is time-dependent; overwriting a value can corrupt payroll, access and history.
Create an event requirement card
| Field | Example question |
|---|---|
| Authority | Who approves this change and under which policy? |
| Effective date | When does it change worker state and consumers? |
| Data | Which values are required, sensitive or derived? |
| Workflow | Who acts, waits, rejects or delegates? |
| Downstream | What reaches payroll, identity, finance or reporting? |
| Evidence | What proves approval, delivery and reconciliation? |
Define worker-data authority
For identity, organisation, position, manager, location, employment terms, pay, time, absence and documents, name system of entry, approver, update right and consumers. Use stable identifiers.
Test duplicate workers, name change, manager change and return. Do not use email as the permanent key.
Design access from role and purpose
Specify employee, manager, HR, payroll, recruiter, auditor and administrator access by task and population. Include delegated action, temporary access, support impersonation and audit where justified.
Test what happens after a transfer and termination. Old access must not persist because an organisational hierarchy updated late.
Write employee and manager scenarios
Ask a worker to view and correct data, request leave, complete a required action and find help. Ask a manager to approve, initiate a change and review team information. Include accessibility and mobile needs.
State expected messages, status and privacy. A completed workflow that leaves the employee uncertain is not a successful service.
Connect payroll and identity safely
Specify event, fields, effective date, cut-off, acknowledgement, rejection, retry and reconciliation. A delivered interface file is not proof that pay or access is correct.
Run future-dated and retroactive changes, withdrawn hires and emergency terminations. Give every exception an operational owner.
Define migration and history
Decide which worker, employment, document, absence, pay-reference and organisational history is needed for operation, employee access, reporting and retention. Preserve effective dates and source identity. Do not flatten history into the latest value.
Rehearse conversion with control totals by population and event. Sample complex employees and give every rejected record an owner and disposition.
Specify workflow operations
For every approval, define delegation, absence, timeout, escalation, cancellation and correction. Test the workflow after an organisational change and confirm that historical approval remains understandable.
Separate notification from responsibility. An email does not establish ownership unless the case and expected action are visible.
Request vendor evidence
Use the event scenarios in demonstrations and require the proposed edition and configuration boundary. Mark available, configurable, integration-dependent, custom, roadmap or unsupported. Record administration and operating effort.
Do not accept “best practice” as a substitute for the organisation deciding its employment policy and control.
Plan content and support
Requirements should cover employee messages, instructions, help, accessibility, languages and support hand-off. Content changes with policy and interface, so assign ownership and review triggers.
A correct transaction can still create avoidable failure when the worker cannot understand status, action or correction path.
Define reporting through decisions
List workforce questions, population, period, definition, authority and action. Separate operational lists from analytical measures. Protect small groups and sensitive characteristics.
Require traceability from summary to authorised records and disclose definition changes.
Specify non-functional context
Set critical periods, volumes, recovery, availability, security, privacy, retention, accessibility, languages and support in relation to employment events. “Compliant” and “user-friendly” are not testable alone.
Identify jurisdictions and controls that require specialist validation. Do not ask a generic feature checklist to provide legal assurance.
Prioritise and accept
Make an item mandatory when failure blocks an event, control or acceptable employee outcome. Record consequence and owner. Score preferences only after mandatory scenarios pass.
Reuse the event cards in demonstration, configuration, testing and release. Requirements remain valuable when they preserve the link between business decision and operating evidence.
Close the requirements phase with a versioned decision pack: population and event boundaries, policy decisions, source register, mandatory scenarios, data authority, integration contracts, non-functional context, open risks and acceptance owners. Review it with implementation and service teams before signature. This prevents a procurement document from becoming detached from the system that must later operate.
Keep unresolved questions visible with owners and deadlines; uncertainty must not become a hidden supplier assumption.