LMS requirements are the capabilities, technical conditions, and business constraints a learning platform must meet for your organization. This guide helps you document them with a checklist, clear examples, and tests a vendor can actually pass or fail.
A polished LMS demo can make almost anything look easy. The presenter clicks three buttons, a chart appears, and someone from HR says, “Great, that solves our problem.” Six months later, an administrator discovers that the chart cannot show the one field HR needs.
I would rather find that out on demo day. Below, I’ll show you how to turn everyday training problems into clear LMS requirements and make vendors demonstrate the answers. You can use the example wording directly in your own requirements document.
What Are LMS Requirements?
LMS requirements are the specific capabilities, operating conditions, and business constraints a company needs its learning management system to meet. They describe the work the platform must support, the technical rules it must follow, and the resources the organization can commit to running it.
“Automated onboarding” is a feature wish. “Assign the correct onboarding path within 24 hours of a new hire appearing in our HR system” is a requirement. You know when the second one has failed.
I separate LMS requirements into three groups:
Functional requirements cover what people can do inside the system, such as assigning a course when someone changes jobs, recording a quiz attempt, or letting a manager see overdue training.
Technical and non-functional requirements cover the conditions under which the LMS needs to work. Can employees sign in with their company accounts? Does the platform handle your existing course packages? Can it protect records, stay available during busy periods, and work on the devices people use?
Business and operational requirements cover what the LMS will cost and what running it involves. That includes licensing, implementation help, support commitments, staff time, and what happens to your data if you leave the vendor.
These categories overlap. Single sign-on is a technical capability, but an employee unable to log in has a functional problem. The point of categorizing requirements is to give each one a clear owner, not to start an argument about labels.
LMS Requirements Checklist at a Glance
Before you spend an afternoon listing every feature you’ve ever seen in an LMS, check the areas below. Think of this as a first pass for a mid-sized company training employees, not a universal list of must-haves. Your own priorities will depend on the people, content, systems, and risks involved.
People, groups, and permissions. Every learner needs a consistent identity, and the system must know which department, location, role, and manager they belong to. Groups should update when those details change. A line manager should be able to work with their team without seeing confidential records from another department.
Assignments and follow-up. Decide how people are enrolled, how due dates are set, and who receives reminders. A rule that assigns onboarding to new hires sounds simple. It becomes more interesting when someone transfers, goes on leave, or is rehired. Ask vendors to show those exceptions.
Courses and proof of learning. Check that learners can find their assigned courses, follow any required sequence, complete assessments, and see their results. If your organization issues certificates, decide how expiry, renewal, retakes, and older completion records should work. For live sessions, include bookings, cancellations, and attendance.
Reporting and daily administration. Managers need reports they are allowed to access; administrators need to correct errors without rebuilding the whole report. Write down the fields you need in exports and the tasks your team performs every week.
Connections and course compatibility. List your HR system, identity provider, and any other system exchanging learner information. Record your actual SCORM versions rather than asking generally for SCORM support. If a course resumes incorrectly or an employee record fails to sync, someone needs to see the error.
Security, reliability, and data access. Agree who can change completion records, what should appear in an audit log, how long data is retained, and how you will get it back. Ask about backups, downtime notices, service commitments, and the number of learners expected at peak times.
Accessibility and devices. Identify the browsers, phones, shared devices, and assistive technologies your learners use. An attractive desktop demo says very little about a technician trying to complete a course between shifts.
Cost, support, and ownership. Ask what is included in the quoted license, what implementation and training cost, who provides support, and what happens at renewal or contract exit. A seemingly cheaper platform can create more work for your internal team.
These are the areas I would settle first. If you are still deciding which capabilities are available in the market, my guide to key LMS features covers them. Use the questions above to decide which ones you actually need.
How to Define Your Organization’s LMS Requirements
Start with the people and the work
Before writing a feature list, write down your audiences. For each group, answer four questions: Who joins the LMS? What training must they complete? Who assigns or approves it? Who needs proof afterward?
Consider two companies that each have 200 employees. The first has office-based staff, company laptops, one HR system, and annual security training. The second has technicians at 30 locations, shared devices, shift changes, and safety certifications that expire at different times.
The first may focus on single sign-on, automated onboarding, and manager reports. The second will care far more about device access, location-based assignments, renewal rules, and training that works around shifts. If onboarding is your main use case, my employee onboarding LMS guide goes deeper into the workflows and products.
Pick three to five workflows that would cause genuine trouble if the platform mishandled them. Walk each one from trigger to proof. For onboarding: new hire created -> role received -> course assigned -> reminder sent -> result recorded -> manager sees status.
Find the manual work and inspect your current data
Ask the LMS administrator to show you what they do on a Monday morning. Watch them import a roster, resend reminders, fix a duplicate account, or rebuild a monthly report. “Our LMS is difficult” tells you little. “I spend two hours every Friday rebuilding the overdue training report” gives you something to fix.
Inventory what already exists: course packages and versions, learner IDs, organizational fields, completion history, certificates, reports, integrations, and any records you must retain. Note what is missing or unreliable.
A recent instructional design discussion about testing LMS products raised a very believable problem: historical completions and notifications can collide during a migration, causing employees to receive assignments they already finished. It is a good example of why data conditions belong in the requirements, even though the migration itself comes later.
Give each stakeholder a specific job
L&D should own the learning workflows and administrator tasks. HR should confirm job roles, employment status, and manager relationships. IT should confirm identity, integrations, devices, and account lifecycle. Security and privacy teams should define appropriate controls and evidence. Procurement and finance should check pricing, supplier commitments, and exit conditions.
Do not ask everyone to brainstorm their dream LMS. Give them the draft workflows and ask, “What would make this fail for your team?” You’ll get fewer shiny features and more useful objections.
Functional LMS Requirements
Functional requirements describe the work people need to complete inside the LMS. For each item, specify the trigger, expected behavior, exceptions, and proof.
1. Users, groups, roles, and permissions
Specify which fields define a learner: employee ID, department, job role, location, manager, and status. Decide who can edit those fields. Then name the permission boundaries for learners, managers, instructors, local administrators, and central administrators.
Example requirement: A regional manager can view training records for current direct reports but cannot open another region’s learner profiles.
Vendor test: Create two regions and move an employee between them. Sign in as both managers before and after the move. Check what each can see, including exported reports.
2. Enrollment, reminders, and automation
Write the assignment rules in ordinary language: who gets the course, when the clock starts, how due dates are calculated, and what happens after a promotion, transfer, leave of absence, or termination. Include exemptions and manual overrides.
Example requirement: When HR marks a new employee active, the LMS assigns orientation within 24 hours and sends one reminder seven days before its due date, provided the course remains incomplete.
Vendor test: Add a new hire, change their department, complete one assigned course, and run the next synchronization. Check for duplicate assignments and unnecessary reminders.
3. Courses, catalogs, and learning paths
Decide how people find training. Write down how a revised course affects learners halfway through the old version.
Example requirement: A learner who completes module A unlocks module B; someone who has not completed A cannot launch B from the catalog.
Vendor test: Use one completed learner and one incomplete learner. Try opening B directly, not only through the learning path menu. Check what happens after the administrator republishes module A.
4. Classroom and virtual instructor-led training
Live training produces awkward records: someone attends half a session, another moves to a new date, and a third completes the assessment but misses the workshop. Define attendance rules, capacity, waitlists, calendar invitations, instructor permissions, and the evidence of completion.
Example requirement: An instructor can mark attendance for a scheduled session; only attendees marked present receive session credit, and a cancellation does not create a completion record.
Vendor test: Register five employees, cancel one booking, add a waitlisted employee, and record two absences. Compare the learner transcript with the attendance list. My instructor-led training guide covers the learning format itself.
5. Assessments, certificates, and renewals
Separate quiz behavior from certification behavior. Specify passing score, allowed attempts, question randomization if needed, certificate fields, expiry rules, grace periods, and requalification.
For more examples of recurring training needs, see my compliance training software guide.
Example requirement: A certificate expires 12 months after passing; renewal becomes due 30 days beforehand; the earlier pass remains visible in the historical transcript.
Vendor test: Create a fictional learner with a prior-year pass, advance the test dates, and confirm a new attempt is created while the old record stays intact. If certificates are the heart of your program, see my certification software guide for the broader use case.
6. Reports, exports, and manager views
“Powerful analytics” is one of my least favorite phrases on a requirements sheet. Name the question the report must answer, the fields it must contain, its audience, and how frequently it needs to run.
Example requirement: A department manager can view overdue mandatory courses for direct reports, filter by location, and export employee ID, course title, due date, and last completion date.
Vendor test: Supply a dataset that includes transfers, overdue learners, exemptions, and previously completed courses. Have the manager build the report while logged into a restricted account. Check the actual export rather than relying on the dashboard. I cover the wider measurement questions in LMS reporting and analytics.
7. Learner experience, accessibility, and mobile use
Example requirement: A learner using a supported phone can open assigned training, resume at the saved point, and see their completion status without needing a desktop computer.
Vendor test: Put the phone in a frontline worker’s hands, not the sales representative’s. Repeat with keyboard navigation and assistive technology appropriate to your audience. Accessibility also has technical requirements, which we’ll come to next. If mobile access is central to the training program, use my mobile LMS comparison to explore the device-related questions further.
8. Optional capabilities: external portals, eCommerce, social learning, and AI
This is where many checklists become shopping catalogs. A course seller may require checkout, tax handling, tenant-specific branding, and customer reporting. A company training only its own employees may need none of them. The same goes for discussion boards, badges, recommendations, and AI authoring.
Example requirement, if you sell training: Each customer organization can have a delegated administrator who sees only that organization’s users, purchases, and results.
Vendor test: Create two customer organizations, try cross-organization search and exports, and inspect the exact licensing tier needed. Buyers discussing multi-tenant LMS procurement on Reddit called out tenant isolation and unexpected portal charges as questions to settle early. Treat those comments as buyer experiences, not universal market data.
Technical and Non-Functional LMS Requirements
Non-functional requirements describe how reliably and safely the system operates. Technical requirements also cover interfaces, data formats, and infrastructure. For most cloud LMS buyers, “system requirements” means supported browsers, devices, connections, integrations, and service conditions rather than the server specifications needed to install software.
Integrations and identity management
For each connection, document five things: source system, fields exchanged, direction, frequency, and owner. Add error handling as a sixth. For an HRIS connection, for example, HR may own employment status while the LMS owns course completion. Mixing up that ownership creates bad data in both systems.
Example requirement: The LMS imports employee ID, department, manager ID, employment status, and effective date from the HRIS each night, and shows failed records in an administrator-accessible error report.
Vendor test: Import a valid employee, an employee with a missing manager ID, and a terminated employee. Inspect the error report and the resulting permissions. Ask whether the connector, API access, and setup services are included in the quote.
Course formats and learning-data standards
If you have 120 existing SCORM courses, make a list of the versions they actually use. SCORM 1.2 and SCORM 2004 are not interchangeable labels. SCORM 2004 separates completion status and success status, for example, while SCORM 1.2 records them differently. Rustici’s SCORM runtime reference documents that distinction.
Example requirement: The LMS must launch our supplied SCORM 1.2 and SCORM 2004 packages and record the completion, pass/fail, score, and resume behavior each package is designed to send.
Vendor test: Upload three actual packages: a simple course, a scored course with a failed attempt, and a course with bookmarking. Close them mid-lesson, reopen them, complete them, and compare raw results with the LMS report. My SCORM testing guide explains how to check packages independently.
My SCORM-compliant LMS guide explains the broader compatibility questions. Ask about xAPI and a learning record store only when you have a defined reason to collect learning events beyond your normal LMS records. For tools integrated through LTI, specify the version and services required. A vendor saying “standards compliant” should still have to run your test. Importing a SCORM ZIP file also does not transfer a learner’s old course history.
Security, privacy, and auditability
Confirm data locations, encryption in transit and at rest, access control, administrator logs, backup and recovery, subprocessors, retention, and deletion.
Example requirement: Only designated administrators may change completion records, and the system records who made a change, which record changed, and when.
Vendor test: Change a test completion using an administrator account; attempt the same action using a manager account; retrieve the audit record; then ask what appears in a standard export and how long the log is retained.
NIST’s Cybersecurity Framework supply-chain guide recommends defining supplier security requirements and checking them through due diligence. Your security and legal teams should decide which certifications, contractual provisions, and privacy obligations apply to your organization.
Uptime, performance, and realistic scale
“Scales to thousands of users” sounds reassuring until 800 employees try to open a mandatory course on the same morning. Specify the number of registered learners, realistic concurrent sessions, data imports, peak reporting times, and service availability targets.
Example requirement: The supplier must disclose its contractual availability target, maintenance exclusions, incident notification process, and the support path for a service outage.
Vendor test: Review the actual service-level agreement (SLA), not a sales slide. Ask for the assumptions behind any load-testing evidence and how performance will be checked for your expected usage pattern. Do not invent a millisecond threshold without knowing your network and course content.
Accessibility, browsers, and devices
W3C describes WCAG 2.2 as a web accessibility standard, but meeting a criterion in a vendor’s learner portal does not establish that every uploaded course is accessible.
Example requirement: The learner dashboard, course launch flow, and required completion screens must meet the accessibility criteria agreed with our accessibility lead on our supported browsers and devices.
Vendor test: Request an accessibility conformance report, review known exceptions, and test representative workflows with keyboard navigation and relevant assistive technology. Record who is responsible for accessibility problems inside third-party course content.
Data portability and migration prerequisites
Decide which fields must leave the LMS: stable user IDs, assignments, enrollment dates, attempt outcomes, completion dates, certificate expiry, course versions, and relevant audit records. Define what can be exported by your team and what requires a service request.
The full transfer process belongs in a separate LMS migration plan.
Example requirement: An authorized administrator can export historical completions with employee identifiers, course identifiers, dates, and statuses in a documented machine-readable format.
Vendor test: Obtain a sample export with multiple attempts, expired certificates, and inactive learners. Match a few records to their on-screen transcripts. Document gaps before signing.
Business and Operational LMS Requirements
You can find a technically capable platform and still be unable to afford, support, or leave it. Give commercial requirements the same level of attention as features.
Licensing and total cost. Ask whether charges follow registered users, active users, enrollments, administrators, portals, storage, or another unit. Then include implementation, integration, migration, content conversion, support, training, and any required add-ons. Model today’s usage and the number you expect after growth. There is no meaningful “average LMS price” without those assumptions.
Implementation services. Specify what the vendor will configure, which data it will import, who connects the HRIS, who performs acceptance testing, and how administrators are trained. “Onboarding included” is too vague.
Support and service terms. Record support hours, channels, response targets by severity, escalation, maintenance notices, and responsibilities during outages. Ask who can reach support: one named administrator or any authorized administrator. Practitioner comments in an LMS frustrations discussion emphasized weak post-sale support and missing reporting fields. Those are opinions, but they point to sensible questions for a vendor.
Ownership and exit. Confirm ownership and permitted use of content and data, termination notice, renewal rules, price-change provisions, export formats, deletion timetable, and paid assistance at exit. For customer-training portals, include branding and tenant fees if they apply. Get important commitments into the agreement, not the meeting notes.
Ongoing administration. Ask who will manage rules, reporting, courses, failed imports, and user access after launch. If each change requires a vendor ticket, that is an operating cost. My rule is simple: have your future administrator perform an everyday task during the demo.
If a genuinely unusual workflow still cannot be configured in a standard platform, compare the build-versus-buy case for a custom LMS before commissioning development.
LMS Requirements Examples: From Business Need to Acceptance Test
The difference between a feature wish and a requirement becomes obvious when you write down the test. Here are three examples you can adapt. The dates and rules are sample acceptance criteria, not claims about any particular LMS.
Example 1: Onboarding that does not create duplicate assignments
HR says, “We need automated onboarding.” Fair enough, but automated needs a definition.
I would write: “Within 24 hours of a new employee with a valid role appearing in the HRIS, assign that role’s onboarding path once. Re-synchronizing an unchanged employee record must not create another assignment.”
HR Operations owns this requirement. For a company hiring regularly, I would usually mark it a must-have. To test it, ask the vendor to import a new hire, run the same import again, then change the employee’s role. The vendor should show the learner’s assignments and any exceptions. If the second import creates two welcome courses, you’ve learned something useful before signing.
Example 2: Compliance renewal with an actual history
“We need compliance tracking” leaves too much unsaid. A certificate that disappears when someone renews it may be fine for a casual course. It is a problem when you need evidence of earlier completions.
A clearer requirement is: “Renew the specified safety certification every 12 months, start reminders 30 days before expiry, and retain the completion date and result from each training cycle.”
The compliance owner should decide if this is mandatory and confirm any applicable retention rules. Have the vendor create two training cycles for the same learner, show the previous and current records, then export them with expiry dates. A new certificate on screen is only half the test.
Example 3: Manager reports that respect department boundaries
I often see the phrase “easy reporting” in requirements documents. It tells a vendor almost nothing about the report someone needs at 9 a.m. on Monday.
Try: “A manager can filter overdue mandatory training by department and export employee ID, course title, due date, and last completion date. The manager must not be able to view records outside their authorized team.”
L&D and HR can own this together. Ask the vendor to create employees in two departments, log in as each manager, apply the filter, and inspect the exported file. Check the data as well as the interface. A report that looks correct but includes another department’s employees has failed.
When a vendor says it can meet a requirement “with customization,” ask four follow-up questions: Is that configuration or new code? Who maintains it? Is it included in the proposed price? What happens when the platform is updated?
How to Prioritize and Validate Your Checklist
I use three priority labels for an early requirements draft:
- Must-have: Failure would block a critical training workflow, breach an agreed policy, or make the system unusable for a core audience.
- Should-have: It removes meaningful work or friction, but there is an acceptable interim process.
- Optional: It would be welcome, but the organization has no strong evidence it needs it now.
Imagine L&D wants AI-generated courses, IT requires single sign-on, and HR wants automatic reassignment after department transfers. If AI authoring saves some drafting time but employees cannot access training or receive the right assignments without the other two, I’d put SSO and reassignment first. Another company may reach a different conclusion based on its own workflows.
For each requirement, keep a brief written record: the business goal, owner, priority, expected behavior, acceptance test, and any exceptions. Ask the vendor to label each item standard, configurable, paid customization, or unsupported, and provide a demonstration, documentation, or contract clause as evidence. “Yes” without evidence is an invitation to have the same conversation twice.
Once the document is agreed, use it in a consistent shortlist and demo process. My guide to choosing an LMS covers supplier comparisons, scoring, and proof-of-concept testing. After selection, use an LMS implementation plan to turn those promises into a working system.
Common Mistakes When Writing LMS Requirements
Shopping for features before describing the job. Start with the training event and the record or decision it should produce.
Using adjectives instead of acceptance criteria. “Simple,” “robust,” and “flexible” mean whatever the presenter wants them to mean. Replace them with one person, one task, and one expected result.
Taking a demonstration as proof. Sample data is tidy. Real employee records contain duplicates, transfers, expired certificates, and incomplete histories. Give the vendor awkward test data with permission to use it in a controlled environment.
Leaving administrators out of the room. Learners may open one course a month; administrators handle exceptions every day. Have an administrator create a rule, troubleshoot a failed sync, and change a report without a sales engineer taking over.
Making everything mandatory. Forty must-haves often means the team hasn’t resolved its disagreements. Challenge every item that cannot be tied to a business consequence. Allow a workaround when it is genuinely affordable and safe.
Forgetting how data gets out. A product may import new courses beautifully and export historical completions poorly. Ask for a realistic sample data export while you still have negotiating leverage.
Treating certifications or standards as magic words. An accessibility statement, security certificate, or SCORM claim is relevant evidence, not a demonstration of your exact use case. Ask what was assessed, which version is covered, what exceptions exist, and what still needs testing.
Final Thoughts
The best LMS requirements document isn’t the longest one. It’s the one an HR manager, IT lead, LMS administrator, and vendor can read and agree on without having four different conversations about what “automatic” means.
Choose a few high-stakes workflows. Write down what should happen, including the strange cases. Give every requirement an owner and an observable test. Then make vendors show their work.
FAQs
How do I make an LMS requirements checklist?
List your learner groups and the training workflows that matter most. For each workflow, record the trigger, the action the LMS should perform, exceptions, and the evidence you expect to see. Add integrations, security, support, and cost constraints. Finally, mark priorities and have the people who run those workflows review the list before vendors see it.
What technical requirements should I ask about?
Ask about SSO and account provisioning, HRIS or CRM connections, your exact course formats, data export, access controls, logs, hosting, retention, service commitments, accessibility, and supported browsers and devices. For each integration, identify field mappings and ownership. Ask to test your own packages and data. A list of supported products or acronyms is not proof that the required workflow works.
Is an LMS requirements checklist the same as an LMS RFP?
No. A checklist defines the needs and tests that matter to your organization. A request for proposal (RFP) is the formal document inviting suppliers to explain their solution, costs, delivery approach, and contractual terms. Your checklist can become the requirements section of an RFP, but you can also use it to run focused vendor demonstrations without issuing a formal RFP.
