Gathering LMS Requirements Before You Talk to Vendors

The best time to do LMS requirements gathering is before you've seen a single demo. Once a vendor has shown you their slickest feature, it anchors your thinking — suddenly "we need that" enters the list, even though nobody wanted it last week. Requirements gathered before vendor contact describe your operation. Requirements gathered after describe the vendors'.

This guide is the groundwork that makes everything else in selection work: who to interview, how to turn conversations into use cases, how to sort what matters with must/should/could, and how to build the integration inventory your IT team will thank you for.

Talk to the people who depend on it

An LMS at a multi-site manufacturer, food producer, utility, or retailer serves far more than the L&D team. Interview each group and you'll surface requirements you'd never invent at a desk.

• L&D and training leads — the courses, learning paths, and reporting they need to run programs.
• Plant and site managers — who needs to know, in real time, who on the floor is certified and current.
• EHS and compliance — the records, certification tracking, and audit reports they're accountable for.
• IT and security — SSO, data residency, and the systems the LMS must connect to. Bring them in early, not at the end.
• Frontline supervisors — the people who'll assign and chase completions, often on a shared device or a phone.
• The learners themselves — a few floor workers and field crew. If it's painful for them, adoption fails regardless of how good the admin side is.

Keep the interviews concrete. Don't ask "what do you want from an LMS?" — you'll get a wish list. Ask "walk me through how training works for a new hire on your line today, and where it breaks." The pain is where the real requirements live.

Turn conversations into use cases

Raw interview notes aren't requirements. Convert them into use cases — short, specific scenarios from your actual operation. A use case is concrete enough to test in a demo and to write into an RFP.

For example:

• "A new forklift operator is hired at the Memphis distribution center and must complete safety certification before their first shift; their supervisor needs to confirm completion from the floor."
• "A food-safety certification is expiring in 30 days for 12 line workers across three plants; compliance needs an automatic alert and a single report showing who's at risk."
• "A seasonal retail hire needs onboarding training assigned the day they're added to the HRIS, with no manual enrollment step."

Each of these tests automation, multi-site structure, mobile access, reporting, and integration all at once. A dozen good use cases will do more for your selection than a hundred feature checkboxes. They become the scenario-based requirements you hand vendors in the RFP — and later, the exact scenarios worth putting through a short pilot or proof-of-concept before you commit to a finalist.

Sort with must / should / could

Now prioritize. Every requirement and use case gets one label:

• Must — the project fails without it. Non-negotiable. "Audit-ready completion records." "US data residency." "Automatic enrollment from our HRIS."
• Should — important and expected, but you could launch without it and add it soon. "Mobile push reminders." "Manager self-serve dashboards."
• Could — nice to have, genuinely optional. "Gamification." "Social learning feeds."

The value isn't the labels — it's the argument they force. When two stakeholders fight over whether something is a must or a should, that conversation surfaces assumptions you need surfaced now, not during a demo. It also protects your timeline later: scope creep is mostly coulds masquerading as musts, and a clean must/should/could list is the fastest way to keep an implementation on schedule (see how implementation timelines actually move).

Be ruthless about the must list. If everything is a must, nothing is — and you've given yourself no room to trade off when budget or timeline gets tight.

Build the integration inventory

This is the deliverable IT and security care about most, and the one most requirements processes skip. List every system the LMS will need to touch, by name.

For each, capture what data flows, in which direction, how often, and who owns the system internally. This inventory tells you a lot before you talk to anyone — deep integration needs point toward an owned, built-to-fit platform, while a short list of standard connectors may be served fine off the shelf. Our HRIS integration and SSO/SAML pages show what these connections look like done properly.

Where this feeds

Done well, requirements gathering produces three artifacts you'll reuse constantly: a sorted must/should/could list, a set of concrete use cases, and an integration inventory. Those go straight into your RFP, your demo scripts, and your vendor scorecard — and they're the foundation of the full process in How to Choose an LMS.

They also answer the strategic question earlier than you'd expect. A short must list with standard integrations leans toward buying off the shelf. A long must list, deep integration, audit-grade compliance, and multi-site complexity lean toward owning a platform built to fit. That's the decision laid out in the buy-vs-build guide.