How do we write an HR software requirements list?

From the work, not from a template. Walk a complete cycle of your own calendar and record everything it contains: the payroll cut-off, the input collection, the approvals, the corrections, the filings, the reports someone asks for, the joiners and the exits. Note who does each task, what it depends on and where the data comes from. Then add the exceptions you handled by judgement, because those are what configuration has to absorb and they never appear on a vendor checklist. A downloaded list of HR software features describes what products do; a calendar walk describes what you do, and only the second one can tell you whether a product fits.

Write it as an observable outcome with an actor and a condition. Supports leave management is untestable, so every vendor passes it. An employee can apply for leave against a balance that reflects accruals to date, and the request routes to two approvers in sequence, with the second able to reject after the first approves is testable, so a demo either shows it or does not. Include the awkward variant deliberately: the backdated request, the mid-cycle joiner, the person whose manager changed. Requirements written loosely are the reason evaluations end in impressions rather than evidence, and impressions are exactly what a well-run demo is designed to produce.

Apply one question to each line: if this failed, would we walk away? Anything that gets a yes is a must-have and there should be fewer than people expect - typically statutory outputs, the transactions that run every cycle, data export, and whatever your organisation is uniquely constrained by. Everything else is a preference, and preferences only break ties. The discipline matters because inflated must-have lists eliminate good products for reasons nobody genuinely cared about, and because a long list of equally weighted requirements is functionally unweighted. Fix the classification before you see any demo, since it is remarkably easy to reclassify a requirement after watching a product handle it well.

The unglamorous half. Data export in a usable format, and what it costs to obtain. Permissions granularity, especially who can see compensation. An audit trail on changes, with who and when. Corrections and backdated adjustments into closed periods, which every organisation needs and few ask about. Offboarding, including access removal and final settlement inputs. Bulk operations, because uploading changes one at a time will not survive a restructure. Reporting you can build yourself, since a fixed report library ages badly - decent people reporting is what keeps a system useful once the novel questions start. Write these in before the first call, when nobody is influencing your list.

You run the session, they follow. Send the list ahead, give the vendor a small set of your own anonymised records, and ask them to work through your scenarios in order rather than presenting theirs. When the answer is a roadmap item or a workaround, write down which and move on without debating it. Keep the same scenarios and the same order for every vendor, because comparability is the entire point. Booking a structured walkthrough against a written list also changes who is being evaluated by whom, and a vendor who cannot work to your agenda has told you something useful about how implementation and support will feel later.

Fix the weights before the first demo and refuse to change them afterwards. Score each requirement on evidence - demonstrated on your data, demonstrated on their data, described, or not available - rather than on a general impression of the product. Have every attendee score independently before discussing, since the loudest opinion in a room otherwise becomes the consensus. Record the reason next to each score, not just the number, because the reasons are what you will need when you revisit the decision. Where two products tie, resist inventing a new criterion to break it; look instead at exit rights, support responsiveness and how each vendor behaved when something did not work.

It becomes the acceptance criteria for implementation, which is its most valuable second life. Every must-have should be demonstrated in your configured tenant before go-live, using your data, and signed off individually rather than as a batch. The gaps you accepted knowingly become a documented list of manual workarounds with owners, so nobody rediscovers them as surprises during the first live cycle. Keep the file. At renewal it tells you what you actually bought and whether it was delivered, and if you ever evaluate again it saves rebuilding the whole thing from memory - by then your process will have changed, but the structure and most of the awkward cases will still hold.