Техническое задание на LMS: структура и пример требований

Техническое задание на LMS — практический каркас для заказчика

Техническое задание на LMS нужно, чтобы чётко зафиксировать требования к платформе обучения, разграничить обязательные и желательные функции, описать сценарии пользователей и сформировать проверяемые критерии приёмки. В этой статье даю готовую структуру ТЗ, объясняю, что обязательно включать, что можно отнести к пожеланиям, и приводю условные примеры требований к курсам, отчётам и размещению материалов.

Что включать в техническое задание на LMS?

ТЗ на СДО (система дистанционного обучения) должно быть документом, который позволяет подрядчику и заказчику однозначно понимать, что будет реализовано и как это будет тестироваться. Включите в ТЗ следующие блоки:

• Вводная часть: цель проекта, заказчик, контактные лица, сроки и бюджетные рамки.
• Область применения: для кого платформа, какие типы курсов и оценочных мероприятий будут проводиться.
• Функциональные требования: перечень функций с приоритетами (обязательно/желательно).
• Нефункциональные требования: производительность, надёжность, безопасность, локализация, совместимость (SCORM, H5P и т.п.).
• Роли и права: описать набор ролей (администратор, методист, преподаватель, студент, менеджер) и разграничение прав.
• Сценарии пользователей: ключевые пользовательские сценарии с шагами и ожидаемым результатом.
• Критерии приёмки и тестовые сценарии: как проверять каждую функцию.
• Инфраструктура и развёртывание: облако/локальная установка, требования к серверу, резервное копирование.
• Интеграции: бухгалтерия, SSO, CRM, Web-сервисы — указать протоколы и точки обмена.
• Отчётность и аналитика: набор отчётов, периодичность, формат экспорта данных.
• Приложения: прототипы интерфейсов, диаграммы процессов, примеры данных.

Обязательное и желательное: как разделять требования

Разделяйте требования на обязательные (MUST) и желательные (SHOULD/WANT). Это упрощает техническую и коммерческую оценку.

Обязательное (пример):

• Регистрация и аутентификация пользователей.
• Управление ролями и правами доступа.
• Загрузка и воспроизведение видеоуроков и файлов.
• Создание модулей курса: главы, уроки, задания.
• Тесты с автоматической проверкой (множественный выбор, сопоставление).
• Формирование и экспорт отчётов по прохождению курса.
• Возможность импорта SCORM-пакетов (совместимость проверяется отдельно).
• Критерии приёмки: успешное выполнение контрольных сценариев в тестовой среде.

Желаемое (пример):

• Геймификация (баллы, бейджи).
• Интеграция с платёжными системами.
• Встроенный ИИ-тьютор и генерация курсов ИИ (если планируете автоматизацию контента).
• Прокторинг при тестировании.

Отмечайте приоритет и минимально приемлемую реализацию для каждой функции — это снизит риски недопонимания.

Роли: какие роли описать в ТЗ?

Типичные роли, которые стоит подробно описать в ТЗ:

• Администратор платформы: настройка, права, загрузка бэкапов.
• Методист/контент-менеджер: создание и редактирование курсов.
• Преподаватель/тьютор: выпуск оценочных заданий, проверка работ, общение со студентами.
• Студент/ученик: прохождение курса, выполнение заданий, получение сертификата.
• Менеджер/HR: распределение пакетов обучения, отчётность по сотрудникам.

Для каждой роли опишите типичные операции и ограничения доступа.

Сценарии пользователей: как их формулировать

Сценарии нужны, чтобы тестировать поведение системы в реальных потоках работы. Для каждого сценария укажите: цель, роль, предварительные данные, шаги, ожидаемый результат и критерий приёмки.

Пример сценария (условный):

• Название: Регистрация участника на курс и прохождение первого урока.
• Роль: студент.
• Предусловия: на платформе есть курс с открытым доступом.
• Шаги:

1. Пользователь регистрируется через форму (имя, email, пароль).
2. Пользователь подтверждает почту (если включена валидация).
3. Заходит в каталог, находит курс и записывается.
4. Открывает первый урок, просматривает видео и выполняет задание.
   • Ожидаемый результат: пользователь видит прогресс 1/?, задание отправлено на проверку.
   • Критерий приёмки: форма регистрации создаёт запись в базе; прогресс увеличивается; преподаватель видит отправленное задание в списке.

Сценарии должны покрывать критические процессы: покупка курса, выдача сертификата, массовая загрузка пользователей, прохождение теста, восстановление пароля.

Критерии приёмки: как конкретизировать

Критерии приёмки — это список проверок, которые однозначно определяют успех. Для каждой функции укажите конкретные тесты и ожидаемый результат.

Пример формата критерия приёмки:

• Функция: импорт курса в формате SCORM.
• Тест: загрузить SCORM-пакет размером N МБ, включающий структуру из 5 модулей.
• Ожидаемый результат: пакет распознан, модули созданы, трек события прохождения сохраняется.
• Условие при ошибке: если пакет не соответствует спецификации, система выдаёт понятное сообщение и сохраняет лог.

Ниже приведён чек-лист для ключевых направлений приёмки.

Чек-лист приёмки (основное)

1. Регистрация и вход: формы, подтверждение, восстановление пароля.
2. Управление ролями: назначение и проверка прав.
3. Курсы: создание, редактирование, удаление, импорт/экспорт.
4. Материалы: загрузка видео, файлов, встроенных презентаций.
5. Тесты: вариативность вопросов, оценивание, просмотр ответов.
6. Задания с ручной проверкой: загрузка ответов, уведомления для проверяющего.
7. Отчётность: формирование отчётов по пользователям и курсам, экспорт CSV/XLS.
8. Производительность: время ответа на типичные операции в тестовом окружении.
9. Резервное копирование и восстановление: создание бэкапа и восстановление данных на тестовой среде.
10. Интеграции: проверка обмена данными по указанным API.

Условные примеры требований к курсам, отчётам и размещению

Ниже — несколько условных примеров, которые можно включить в ТЗ как шаблон.

Курсы (условный пример)

• Каждый курс состоит из глав и уроков. Урок может содержать текст, видео, презентацию и задание.
• Видео: поддержка MP4, адаптивный плеер, автоплей отключён по умолчанию.
• Прогресс: фиксируется процент пройденного контента и результаты тестов.
• Сертификат: генерируется по завершении курса с возможностью выгрузки в PDF.

Отчёты (условный пример)

• Отчёт «Прохождение курса»: список студентов, статус (не начат/в процессе/завершён), баллы, дата последней активности. Экспорт в CSV.
• Отчёт «Активность за период»: количество входов, среднее время на урок, список самых просматриваемых уроков.

Размещение материалов (условный пример)

• Лимит на общий объём хранилища указываете в ТЗ; при локальном развёртывании — требования к дисковому пространству и резервным копиям.
• Правила доступа: приватные и общедоступные ресурсы, возможности публикации через внешние ссылки.

(Все примеры отмечены как условные и требуют уточнения под ваш проект.)

Нагрузочные требования: что прописать

Опишите ожидаемую нагрузку и пиковые сценарии:

• Ожидаемое число одновременных пользователей (конкурентных сессий).
• Сценарии пиковой нагрузки (например, 1000 учеников одновременно запускают тест).
• Ожидаемое время ответа на операции (загрузка урока, отправка задания).
• Требования к масштабированию: вертикальное/горизонтальное.

Укажите виды тестирования: функциональное, нагрузочное, регрессионное и приёмочное. Для локальной установки уточните требования к серверной платформе и резервному копированию.

Безопасность и защита данных

Пропишите требования к хранению персональных данных, шифрованию соединений, журналированию действий и процедурам восстановления после инцидента. Если планируется прокторинг — опишите, какие события фиксируются и как хранятся записи (см. раздел о прокторинге в требованиях).

Алгоритм составления ТЗ: пошаговый план

1. Соберите команду заказчика: методист, ИТ, представитель бизнеса.
2. Опишите целевые сценарии обучения и критические процессы.
3. Выпишите минимальный набор функций (MVP) и желательные функции.
4. Подготовьте прототипы интерфейса и схемы интеграций.
5. Пропишите критерии приёмки для каждой функции.
6. Проведите обходное тестирование и согласуйте документ с подрядчиком.
7. Внесите правки и утверждайте финальную версию ТЗ.

Кому подойдёт типовое ТЗ и куда двигаться дальше

Этот каркас подходит компаниям и учебным организациям, которые планируют выбрать платформу или заказать разработку/кастомизацию СДО. После подготовки ТЗ вы можете запросить коммерческие предложения у вендоров, приложив документ и тестовые сценарии.

Если вы рассматриваете готовую платформу, обратите внимание на подтверждённые функции у поставщика. Платформа GetLMS поддерживает ряд возможностей, которые часто фигурируют в ТЗ: размещение курсов, тесты и задания, аналитика, SCORM, вебинары, геймификация и инструменты для корпоративного обучения — проверьте соответствие конкретным требованиям на https://getlms.ru/. Также доступна серверная версия для установки у заказчика (условия уточняйте отдельно) — https://getlms.ru/.

Помните: ТЗ — это инструмент управления ожиданиями. Чем подробнее вы опишете обязательные функции, сценарии и критерии приёмки, тем меньше риск недопонимания при внедрении.

LMS-01, LMS-05 — отмеченные внутренние ссылки/идентификаторы разделов для дальнейшей детализации требований.