Обзор ТЗ
Предварительное техническое задание — первоисточник требований к платформе.
Это предварительное ТЗ заказчика — первоисточник требований проекта.
Оригинал хранится в documantation/docx/Предварительное ТЗ.docx. Раздел
передаёт требования как есть; принятая реализация описана в
Архитектуре.
Назначение проекта
Необходимо разработать региональную образовательную платформу для школьников Мурманской области «НА СЕВЕРЕ — ЖИТЬ!», объединяющую:
- публичный портал возможностей региона;
- личные кабинеты школьников;
- личные кабинеты учителей;
- профориентационный модуль с ИИ-помощником;
- каталог курсов внеурочной деятельности;
- каталог событий, путёвок, допобразования, мероприятий, работодателей и учебных заведений;
- аналитический контур для школ, муниципалитетов и Министерства образования.
Ключевая задача платформы — связать интересы школьника, образовательные маршруты, региональные учебные заведения, работодателей и мероприятия в единую цифровую систему сопровождения.
Два контура платформы
Публичная часть
Доступна без авторизации и должна работать как витрина возможностей региона для школьников, родителей, педагогов и партнёров. Основные разделы:
| Витрина возможностей | Контент и сервис | Вход |
|---|---|---|
| Профориентация | Главная страница | Вход для ученика |
| Курсы внеурочной деятельности | О проекте | Вход для учителя |
| Путёвки | Новости и объявления | |
| Интересные события | Документы | |
| Работа рядом | Контакты | |
| Дополнительное образование | ||
| Пушкинская карта | ||
| Интересные каникулы | ||
| Работодатели региона | ||
| Учебные заведения |
Закрытая часть
Доступна после авторизации. Роли:
- Ученик
- Родитель
- Учитель
- Администратор школы
- Муниципальный координатор
- Администратор Министерства
- Работодатель / партнёр
- Администратор платформы
- Модератор контента
- Аналитик
Короткая формулировка для разработчика
Проект нужно проектировать не как обычный сайт, а как региональную цифровую платформу с двумя контурами: публичная витрина возможностей и закрытая система персональных маршрутов. Критично сразу заложить разделение обезличенной диагностики и персонального профиля, ролевую модель, журналирование действий, управление согласиями, ИИ-оркестратор и аналитическое хранилище. На старте допустим модульный монолит, но архитектура должна позволять выделить ИИ, аналитику и уведомления в отдельные сервисы.
ТЗ и принятая реализация
ТЗ называет свой стек «один из рабочих вариантов», а не жёсткое требование. Команда приняла другой стек — решение зафиксировано в Журнале изменений. Требования ТЗ по ролям, персональным данным, аналитике и нефункциональным показателям остаются обязательными.
| Что предлагает ТЗ (раздел 13) | Что принято | Где описано |
|---|---|---|
| PostgreSQL + ClickHouse для аналитики | MongoDB + Qdrant | Архитектура |
| PHP Laravel / Node.js NestJS / Python FastAPI | Go | Архитектура |
| Внешние LLM через AI Gateway | Локальный vLLM с Qwen3 на NEURO CORE | Журнал изменений |
| Vue 3 / Nuxt или React / Next.js | React | Архитектура |
| Kubernetes или простой кластер — по бюджету | Два сервера без Kubernetes | Архитектура |
Решением команды PostgreSQL, ClickHouse, Laravel, NestJS и FastAPI в проекте запрещены — ни в основном коде, ни во вспомогательных сервисах, ни в прототипах. Хранилища — только MongoDB и Qdrant, backend — только Go. Предложение любого из запрещённых компонентов отклоняется на ревью без обсуждения.
Дальше
Кабинеты и роли
Шесть личных кабинетов, их разделы и функции, админка.
Профориентационный модуль
Диагностика, логика ИИ-диалога и результат для ученика.
Персональные данные и согласия
Обезличенный и персональный режимы, требования к согласиям.
Модель данных
Основные сущности и их поля.
Требования безопасности
RBAC, аутентификация, защита данных, ИБ-документы, логирование.
Этапы, НФТ и команда
MVP-1…MVP-4, нефункциональные требования, интеграции и состав команды.