docs: add technical specification (GOST 34.602-2020) and analysis

2026-09-26 18:42:46 +03:00
commit 4362489372
@@ -0,0 +1,156 @@
 # Анализ технического задания
 **Документ:** ТЗ на создание автоматизированной системы «Платформа ОПОРА РОССИИ»
 **Основание:** ГОСТ 34.602-2020
 **Версия:** 0.3 от 25.09.2026, статус — проект ТЗ (черновик для согласования)
 **Объём:** 9 разделов + 3 приложения (А, Б, В)
 ---
 ## 1. Общая характеристика
 Документ описывает создание автоматизированной системы для общероссийской общественной организации МСП «ОПОРА РОССИИ». Система объединяет три канала:
 - **мессенджер-бот** (Telegram, вариант — MAX) — точка входа, авторизация, рассылки;
 - **веб-приложение (mobile-first)** — личный кабинет, цели, рейтинги, карточки регионов, задачи, артефакты;
 - **серверная часть (API) + БД** — единое хранилище для бота и сайта.
 Ключевая бизнес-идея — прозрачный учёт целевых показателей (рост базы членов, «точка 0», прирост, рейтинг 89 регионов и 8 округов) и вовлечение региональных отделений через персональные рассылки и «красную зону».
 Документ подготовлен аккуратно, структура соответствует ГОСТ, открытые вопросы вынесены в варианты решений. Это **хороший черновик уровня «концепция + ТЗ»**, но до подписания требует устранения ряда пробелов и внутренних несоответствий.
 ---
 ## 2. Соответствие ГОСТ 34.602-2020
 | Требуемый раздел ГОСТ | Наличие | Комментарий |
 |---|---|---|
 | Общие сведения | ✅ | п. 1, но часть полей — заглушки |
 | Назначение и цели создания | ✅ | п. 2, цели измеримы |
 | Характеристика объектов автоматизации | ✅ | п. 3 |
 | Требования к системе | ✅ | п. 4 (в целом, функции, виды обеспечения) |
 | Состав и содержание работ | ✅ | п. 5, таблица по стадиям ГОСТ 34.601 |
 | Порядок контроля и приёмки | ✅ | п. 6 |
 | Требования к подготовке объекта | ✅ | п. 7 |
 | Требования к документированию | ✅ | п. 8 |
 | Источники разработки | ✅ | п. 9 |
 **Вывод:** формально структура полная. Основные проблемы — не в составе разделов, а в глубине и непротиворечивости требований.
 ---
 ## 3. Сильные стороны
 1. **Чёткая структура и трассируемость** — функции (4.2), виды обеспечения (4.3) и приёмка (6.3) связаны между собой.
 2. **Измеримые показатели назначения** (4.1.3): время загрузки ≤ 3 с, экран целей ≤ 2 с, рассылка ≤ 1 ч, доступность ≥ 99%.
 3. **Явные варианты решений** (Приложение В) — 10 открытых вопросов с рекомендацией «Вариант 1». Это правильный способ зафиксировать неопределённость до согласования.
 4. **Mobile-first и эргономика** (4.1.6) — учтён основной сценарий (смартфон, встроенные браузеры мессенджеров).
 5. **Безопасность входа** — одноразовые ссылки, блокировка повторного использования, привязка сессии к аккаунту мессенджера, журналирование.
 6. **Референс функциональности** (Приложение Б) — состав экранов аналогичной платформы, что снижает риск недопонимания.
 7. **Хостинг на территории РФ** (4.3.5) и патентная чистота (4.1.11) — учтены российские требования.
 ---
 ## 4. Пробелы и риски
 ### 4.1. Незаполненные обязательные поля
 - Шифр темы, заказчик и разработчик, сроки начала/окончания, источники финансирования, домен (пп. 1.1–1.5, 7).
 - Без этих данных ТЗ не может быть утверждено и не может служить основанием договора.
 ### 4.2. Персональные данные и регуляторика (критично)
 - Система хранит ФИО, аккаунты мессенджеров, членство, контакты. **Нет ни одного упоминания 152-ФЗ** «О персональных данных»: согласие на обработку, цели, сроки хранения, права субъекта, требования к защите (ПП-1119, при необходимости — ФСТЭК).
 - Нет требований к согласию и **отписке от массовых рассылок** (риск спама и жалоб).
 - Для AI-ассистента «Зам» (Вариант 1) не определено, где обрабатываются данные и какому LLM-провайдеру передаются — риск утечки ПДн за периметр РФ.
 ### 4.3. Нефункциональные требования заданы поверхностно
 - **Нагрузка:** нет профиля (число одновременных пользователей, пиковые нагрузки), хотя масштаб задан в пользователях/подписчиках.
 - **Надёжность:** RPO/RTO не заданы явно (только «восстановление ≤ 24 ч» и ежесуточный бэкап → RPO до 24 ч, что может быть неприемлемо).
 - **Мониторинг/алертинг/наблюдаемость** не описаны.
 - **Сроки хранения журналов** (аудит, действия ассистента, рассылки) не заданы.
 - **SLA** ограничен доступностью 99%; нет описания поддержки, времени реакции на инциденты.
 ### 4.4. Интеграции и данные
 - Интеграция с существующими учётными системами — только «при наличии» (п. 7), без анализа.
 - **MAX Bot API** — возможность интеграции не подтверждена (п. 4.1.13.2, Вариант 2). Это внешний риск, влияющий на сроки.
 - Нет требований к API: версионирование, лимиты, форматы ошибок, идемпотентность.
 - Не определён **владелец и жизненный цикл «точки 0»** (кто задаёт, можно ли менять, как корректируются ошибки выгрузок).
 ### 4.5. Функциональные неоднозначности
 - **Рейтинг, Вариант 2** — «взвешенная формула», но веса не заданы и не определены шкалы.
 - **Рассылки, Вариант 2** — конструктор, A/B-тесты, статистика открытий: существенно расширяет объём, но без оценки трудозатрат.
 - **Артефакты, Вариант 2** — медиатека с версионированием и правами: отдельная подсистема.
 - **AI-ассистент** — не заданы модель угроз, ограничения по типам действий, механизм подтверждения владельцем, поведение при ошибке публикации.
 - Нет требований к **модерации** «Советов от регионов» и пользовательского контента.
 ### 4.6. Отсутствующие разделы/темы
 - Оценка стоимости и трудозатрат (в п. 5 упоминается «оценка стоимости» на этапе концепции, но цифр нет).
 - Требования к тестированию и покрытию (кроме видов испытаний в п. 6).
 - Требования к доступности для людей с ограниченными возможностями.
 - Требования к резервному копированию файлов (артефактов), а не только БД.
 - План миграции данных и критерии качества данных.
 ---
 ## 5. Внутренние несоответствия и дефекты
 1. **Битая ссылка на подпункты.** П. 4.1.13 (строка 142) ссылается на «пп. 4.1.13.1–4.1.13.10», но фактически существуют только 4.1.13.1–4.1.13.3. Нужно либо добавить подпункты, либо исправить диапазон.
 2. **Расхождение онбординга.** П. 4.2.2: 5 шагов — «…защита проекта и получение поддержки». Приложение Б: «…Мурманск → защита проекта и грант». Формулировки и содержание шагов не совпадают.
 3. **Терминология.** В основном тексте — «проекты Организации», в Приложении Б — «МПР 2026» / «Регистрации МПР 2026». Нужен единый глоссарий (частично есть в 4.3.3, но «МПР» не раскрыт).
 4. **Ссылки на пункты в таблице В.1** корректны, но в тексте п. 4.1.13.1 назван «Масштаб системы», а в таблице — «Масштаб»; мелочь, но для утверждаемого документа важна точность.
 5. **Приложение Б** описывает референс, но не помечено, какие экраны **обязательны**, а какие — только ориентир. Это создаёт риск спора на приёмке.
 6. **Критерии приёмки** (6.3) ссылаются на «выбранные варианты», которые ещё не выбраны. До фиксации вариантов приёмка неопределима.
 ---
 ## 6. Сводка открытых вопросов (Приложение В)
 | № | Вопрос | Рекомендуемый вариант | Влияние на объём |
 |---|---|---|---|
 | 1 | Ассистент «Зам» | AI-ассистент | Высокое (LLM, безопасность, ПДн) |
 | 2 | Доступ к задачам | Все авторизованные | Среднее |
 | 3 | Артефакты | Простая загрузка | Низкое/Высокое (медиатека) |
 | 4 | Карточка региона | Только своё отделение | Среднее (риск открытой модели) |
 | 5 | Рассылки | Фиксированные шаблоны | Высокое (конструктор) |
 | 6 | Рейтинг | По приросту от точки 0 | Среднее |
 | 7 | История платформы | Публичная лента | Низкое |
 | 8 | Мессенджеры | Telegram + MAX сразу | Высокое (риск MAX API) |
 | 9 | Масштаб | До 10 тыс. пользователей | Высокое (кластер) |
 | 10 | Дизайн | По брендбуку | Среднее |
 **Рекомендация:** зафиксировать все 10 вариантов **до** заключения договора, иначе объём и стоимость будут плавающими.
 ---
 ## 7. Рекомендации
 **Приоритет 1 (блокеры утверждения):**
 1. Заполнить обязательные поля (заказчик, разработчик, сроки, финансирование, шифр, домен).
 2. Добавить раздел по **152-ФЗ**: правовые основания, согласия, сроки хранения, меры защиты, локализация ПДн.
 3. Зафиксировать выбор по всем 10 вариантам Приложения В.
 4. Устранить внутренние несоответствия (п. 5 настоящего анализа).
 **Приоритет 2 (управление рисками):**
 5. Провести техническое обследование **MAX Bot API** до фиксации Варианта 1 по п. 4.1.13.2.
 6. Задать профиль нагрузки и уточнить RPO/RTO, мониторинг, сроки хранения журналов.
 7. Для AI-ассистента — модель угроз, ограничения действий, требования к LLM-провайдеру и локализации данных.
 8. Определить жизненный цикл «точки 0» и правила корректировки данных.
 **Приоритет 3 (качество):**
 9. Добавить требования к API (версионирование, лимиты, ошибки).
 10. Добавить требования к тестированию, доступности (a11y), резервному копированию файлов.
 11. Пометить в Приложении Б обязательные и опциональные экраны.
 12. Приложить оценку трудозатрат и стоимости по каждому варианту.
 ---
 ## 8. Итоговая оценка
 | Критерий | Оценка |
 |---|---|
 | Соответствие ГОСТ 34.602-2020 (структура) | 9/10 |
 | Полнота требований | 6/10 |
 | Непротиворечивость | 6/10 |
 | Готовность к утверждению | 4/10 (черновик) |
 | Управление неопределённостью (варианты) | 9/10 |
 **Вывод:** документ — качественный черновик с правильной структурой и хорошей проработкой бизнес-логики. Главные доработки перед утверждением: правовой блок (152-ФЗ), фиксация вариантов, устранение внутренних расхождений и уточнение нефункциональных требований. После этого ТЗ может служить основанием для договора и календарного плана.
@@ -0,0 +1,456 @@
 ТЕХНИЧЕСКОЕ ЗАДАНИЕ
 на создание автоматизированной системы «Платформа ОПОРА РОССИИ»
 Документ разработан в соответствии с ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»
 Таблица 1 — Сведения о документе
 Шифр темы
 (заполняется при утверждении)
 Версия документа
 0.3
 Дата
 25.09.2026
 Статус
 Проект ТЗ (черновик для согласования)
 1. Общие сведения
 1.1. Полное наименование системы: Автоматизированная система «Платформа ОПОРА РОССИИ» (далее — Система).
 Условное обозначение: АС «Платформа ОПОРА РОССИИ».
 1.2. Наименования заказчика и разработчика (участников работ) — заполняются при утверждении настоящего ТЗ.
 1.3. Перечень документов, на основании которых создаётся Система:
 – настоящее техническое задание;
 – описание бизнес-процессов Организации «ОПОРА РОССИИ» (Приложение А);
 – материалы обследования аналогичной действующей платформы (референс функциональности): скриншоты экранов сайта `rmpred.ru` и бота `@pmpred_bot` (Приложение Б).
 1.4. Плановые сроки начала и окончания работ по созданию Системы — заполняются при утверждении настоящего ТЗ.
 1.5. Сведения об источниках и порядке финансирования — заполняются при утверждении настоящего ТЗ.
 1.6. Порядок оформления и предъявления заказчику результатов работ: результаты работ по этапам предъявляются заказчику в соответствии с календарным планом; приёмка осуществляется в порядке, установленном разделом 6 настоящего ТЗ.
 2. Назначение и цели создания (развития) системы
 2.1. Назначение Системы.
 Система предназначена для автоматизации деятельности общероссийской общественной организации малого и среднего предпринимательства «ОПОРА РОССИИ» (далее — Организация), а именно:
 – автоматизации учёта, расчёта и отображения целевых показателей Организации (цели, рейтинги, динамика региональных отделений и округов);
 – автоматизации коммуникаций с членами Организации через мессенджер-бот (информационные, образовательные и рейтинговые рассылки);
 – обеспечения авторизованного доступа членов Организации к личному кабинету через бота (мессенджеры Telegram и MAX);
 – ведения данных региональных отделений (карточка отделения, члены, численность, ссылки на сообщества и чаты);
 – хранения и загрузки артефактов;
 – ведения задач (трекер);
 – обмена практиками между региональными отделениями («Советы от регионов»);
 – поддержки ассистента «Зам» (вариант — см. п. 4.2.14).
 2.2. Цели создания Системы:
 – рост базы членов Организации до целевого значения (общая цель, например +1096 к базе от «точки 0»);
 – обеспечение прозрачности результатов: каждое региональное отделение и округ видит свой вклад в общий результат;
 – сокращение времени на сбор, обработку и публикацию данных (автообновление срезов);
 – повышение вовлечённости региональных отделений: выявление «красной зоны» (отделения без динамики) и адресная помощь;
 – снижение рутинных операций за счёт автоматических рассылок и (вариант) AI-ассистента;
 – создание единой точки входа: бот → сайт → личный кабинет.
 3. Характеристика объектов автоматизации
 3.1. Объектом автоматизации является деятельность Организации «ОПОРА РОССИИ», включающая:
 – руководителей региональных отделений (89 регионов, 8 федеральных округов);
 – членов Организации;
 – координаторов (выдача ссылок для входа);
 – администраторов платформы.
 3.2. Автоматизируемые процессы:
 – регистрация и авторизация членов Организации через бота;
 – рассылки: информационные, образовательные, рейтинговые (еженедельный фокус целей);
 – учёт целевых показателей (проекты Организации и др.): «точка 0», текущие срезы, прирост, динамика;
 – формирование рейтингов региональных отделений;
 – ведение карточек региональных отделений (численность, ссылки на сообщества и чаты, члены);
 – загрузка и хранение артефактов;
 – ведение задач;
 – обработка запросов (заявки на вступление, на доступ, на участие в мероприятиях, на поддержку);
 – ведение базы знаний, календаря событий, истории платформы.
 3.3. Условия эксплуатации: пользователи работают с Системой преимущественно с мобильных устройств (основной сценарий) через браузер; бот функционирует в мессенджерах Telegram и (вариант) MAX. Допускается работа с персональных компьютеров.
 4. Требования к системе
 4.1. Требования к системе в целом
 4.1.1. Требования к структуре и функционированию Системы.
 Система включает следующие подсистемы и компоненты:
 1. Мессенджер-бот (Telegram, MAX) — точка входа, авторизация, рассылки, интерактив.
 2. Веб-приложение (mobile-first) — личный кабинет, цели, рейтинги, данные региональных отделений, задачи, артефакты.
 3. Серверная часть (API) — единое API для бота и сайта.
 4. База данных — единое хранилище данных.
 5. Модуль выгрузок данных — загрузка срезов, расчёт прироста от «точки 0», автообновление.
 6. Модуль рассылок — формирование и отправка сообщений через бота.
 7. Модуль AI-ассистента «Зам» (вариант — см. п. 4.2.14).
 Требования к функционированию:
 – бот и сайт используют единые данные (то, что загружено на сайте, используется в рассылках бота);
 – вход на сайт выполняется только через бота по одноразовой ссылке;
 – после подтверждения входа ботом сайт открывается автоматически (при сбое — кнопка «Открыть сайт»);
 – данные целей обновляются автоматически по выгрузкам (режим «Автообновление»).
 4.1.2. Требования к численности и квалификации персонала Системы.
 Таблица 2 — Роли и функции персонала
 Роль
 Функции
 Кол-во (ориентировочно)
 Администратор платформы
 Управление ролями, выгрузками, рассылками, справочниками
 1–3
 Координатор
 Выдача одноразовых ссылок, поддержка пользователей
 5–20
 Руководитель регионального отделения
 Работа с целями, рейтингами, карточкой отделения
 до 89
 Член Организации
 Регистрация, участие, загрузка артефактов
 по мере роста базы
 Квалификация: уверенный пользователь мобильных устройств и мессенджеров; специальная подготовка не требуется (обучение — по п. 7).
 4.1.3. Показатели назначения.
 – время загрузки основных экранов мобильной версии — не более 3 с при типовом канале связи;
 – отображение экрана «Цели организации» с данными по 89+ регионам — без заметных задержек (не более 2 с);
 – доставка массовой рассылки по всей базе подписчиков — не более 1 часа;
 – автообновление срезов — без ручного вмешательства, по расписанию;
 – доступность Системы — не менее 99% в месяц.
 4.1.4. Требования к надёжности.
 – доступность Системы — не менее 99% в месяц (допустимый простой — не более 7,2 ч/мес);
 – корректная обработка устаревших выгрузок: цели со свежестью выгрузки более 7 дней исключаются из рассылки «Еженедельный фокус целей»;
 – резервное копирование базы данных — ежесуточно;
 – восстановление работоспособности после сбоя — не более 24 часов;
 – отсутствие потери данных при штатном завершении работы.
 4.1.5. Требования к безопасности.
 – вход по одноразовым ссылкам; повторное использование ссылки блокируется с сообщением «Ссылка уже была использована. Запросите новую у координатора»;
 – привязка сессии к аккаунту мессенджера пользователя;
 – разграничение прав доступа по ролям (п. 4.1.8);
 – передача данных по защищённому протоколу (TLS);
 – журналирование действий пользователей и ассистента (кто, что, когда).
 4.1.6. Требования к эргономике и технической эстетике.
 – интерфейс проектируется по принципу mobile-first (ширина экрана 360–430 px);
 – крупные элементы управления, удобные для касания;
 – ключевые показатели отображаются крупными цифрами с подписями («Точка 0», «Сейчас», «Цель»);
 – цветовое кодирование зон: динамика / «красная зона» / нейтральное состояние;
 – единый визуальный стиль с брендом «ОПОРА РОССИИ»;
 – пустые состояния сопровождаются подсказками (например: «Советов пока нет. Когда отделение даст динамику по цели, в боте появится кнопка "Дать совет для других лидеров"»).
 4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению.
 Эксплуатация Системы осуществляется в соответствии с регламентом, разрабатываемым на этапе «Ввод в действие». Техническое обслуживание — силами разработчика (или эксплуатационной организации) по договору сопровождения.
 4.1.8. Требования к защите информации от несанкционированного доступа.
 – ролевая модель доступа: администратор, координатор, руководитель регионального отделения, член Организации, (вариант) заместитель;
 – аутентификация — через аккаунт мессенджера (Telegram/MAX) по одноразовой ссылке;
 – авторизация — на уровне API и интерфейса;
 – защита от перебора ссылок (случайные токены достаточной длины);
 – журналирование попыток несанкционированного доступа.
 4.1.9. Требования по сохранности информации при авариях.
 – ежесуточное резервное копирование БД;
 – хранение резервных копий не менее 30 дней;
 – восстановление данных — не более 24 часов.
 4.1.10. Требования к защите от влияния внешних воздействий.
 Система функционирует в стандартной серверной среде; специальные требования к стойкости к внешним воздействиям не предъявляются (типовые требования к веб-приложениям: защита от DDoS, ограничение частоты запросов).
 4.1.11. Требования к патентной чистоте.
 Используемые технические решения должны обеспечивать патентную чистоту на территории Российской Федерации.
 4.1.12. Требования по стандартизации и унификации.
 При создании Системы руководствоваться: ГОСТ 34.601-2020 (стадии создания), ГОСТ 34.602-2020 (настоящее ТЗ), ГОСТ 34.603-2021 (испытания), ГОСТ 19.201-78 (при разработке программной документации).
 4.1.13. Дополнительные требования.
 – поддержка русского языка интерфейса;
 – работа в основных мобильных браузерах (Chrome, Safari) и встроенных браузерах мессенджеров;
 – масштабируемость в соответствии с выбранным вариантом (п. 4.1.13.1);
 – варианты решений по открытым вопросам приведены в пп. 4.1.13.1–4.1.13.10.
 4.1.13.1. Масштаб системы (варианты).
 Вариант 1 (рекомендуемый): до 10 000 зарегистрированных пользователей, до 100 000 подписчиков рассылок. Достаточно одного сервера приложений и СУБД с репликацией.
 Вариант 2: до 100 000 пользователей, до 1 000 000 подписчиков рассылок. Требуется кластерная архитектура, горизонтальное масштабирование, очередь сообщений для рассылок.
 4.1.13.2. Мессенджеры (варианты).
 Вариант 1 (рекомендуемый): интеграция с Telegram и MAX с первого этапа создания Системы (единый бот-адаптер с двумя каналами).
 Вариант 2: на первом этапе — только Telegram; интеграция с MAX — на втором этапе, после подтверждения возможностей Bot API мессенджера MAX.
 4.1.13.3. Дизайн интерфейса (варианты).
 Вариант 1 (рекомендуемый): разработка интерфейса на основе брендбука / гайдлайнов «ОПОРА РОССИИ» (при наличии у заказчика).
 Вариант 2: разработка нового дизайн-концепта с нуля (создание фирменного стиля интерфейса).
 4.2. Требования к функциям (задачам), выполняемым системой
 4.2.1. Функция «Авторизация и управление доступом».
 – выбор мессенджера на сайте: «Войти через MAX» / «Войти через Telegram»;
 – подтверждение входа ботом; автооткрытие личного кабинета;
 – одноразовые ссылки входа, выдаваемые координатором; блокировка повторного использования;
 – сценарий «Нет доступа? Начните регистрацию через бота»;
 – подтверждение входа в боте: «{ФИО}, вход выполнен!»;
 – завершение сессии («Выйти»).
 4.2.2. Функция «Бот: онбординг, меню, команды».
 – онбординг в формате 5 шагов: 1) регистрация на платформе; 2) заявка на вступление в Организацию; 3) онлайн-обучение; 4) участие в очном мероприятии; 5) защита проекта и получение поддержки;
 – главное меню: «Войти на сайт», «Мои возможности», «Регионы и пользователи», «Цели организации», «Регистрации на мероприятия», «Помощь»;
 – команды: `/start`, `/login`, `/requests`, `/regions`, `/goals`, `/events`, `/help`;
 – кнопки: «Открыть сайт», «Открыть цели», «Меню», «Дать совет для других лидеров».
 4.2.3. Функция «Рассылки».
 Три типа рассылок:
 Таблица 3 — Типы рассылок
 Тип
 Содержание
 Периодичность
 Информационные
 Новости, анонсы, изменения платформы
 По мере необходимости
 Образовательные
 Материалы обучения, шаги программ, практики
 По расписанию программ
 Рейтинговые / целевые
 «Еженедельный фокус целей» — персональная сводка по региону
 Еженедельно
 Формат «Еженедельного фокуса целей»:
 – регион получателя (например, «Донецкая Народная Республика»);
 – включаются только цели со свежей выгрузкой за последние 7 дней;
 – позиция региона: «Ваш регион: топ прироста, прирост от 11.06.2026: +134»;
 – динамика округа: «Округ: ЮФО: +365, с динамикой 12/12 регионов»;
 – рекомендация: «Что делать: удержать темп и поделиться рабочими действиями с округом»;
 – кнопка «Открыть цели» — переход на сайт.
 4.2.3.1. Управление рассылками (варианты).
 Вариант 1 (рекомендуемый): фиксированные шаблоны рассылок (еженедельный фокус целей, анонсы, образовательные материалы). Администратор редактирует тексты шаблонов и запускает рассылки; аудитория определяется автоматически (по региону, роли, подписке).
 Вариант 2: конструктор рассылок: произвольный текст/медиа, выбор аудитории (регион, округ, роль), отложенный запуск, статистика доставки и открытий, A/B-тестирование.
 4.2.4. Функция «Цели организации».
 Экран целевых показателей: «что набираем, где есть движение и кому нужна помощь». Состав экрана:
 – общая цель Организации — например, «+1096 к базе членов»; пояснение: «У Организации одна общая цель: вырасти на 1096 от точки 0. Округа показываются как вкладчики в общий результат»;
 – вклад в общую цель — суммарный вклад округов (например, +338), численность, зарегистрированные члены, кнопка «Открыть»;
 – динамика по цели — «Точка 0» / «Сейчас» / «Цель» с числовыми значениями;
 – проекты Организации: активные цели, регионы с динамикой (например, 89), «Есть динамика», «Численность», «Организация: вклад сейчас» (+25), «Проекты: прирост от точки 0» (+2 594);
 – параметры среза: «Точка 0: 2026-05-08; текущий срез: 2026-08-07», режим «Автообновление»;
 – накопительная динамика регистраций по регионам — график/список прироста от точки 0, стартовая точка (например, 11.06.2026);
 – топ включившихся регионов — «Кто сильнее всего включился в проекты» (Москва +224, Башкортостан +217, Санкт-Петербург +159, Донецкая Народная Республика +136, Татарстан +132 и др.);
 – красная зона проектов — регионы без накопительного прироста от точки 0; при отсутствии проблемных регионов — статус «все регионы дали прирост»; кнопка «Полный список»;
 – советы от регионов — практики региональных лидеров; пустое состояние с подсказкой о кнопке «Дать совет для других лидеров» в боте.
 4.2.5. Функция «Рейтинг регионов».
 – список/таблица регионов с показателями (прирост, динамика, численность);
 – сортировка, фильтры по округам, выделение «красной зоны».
 4.2.5.1. Методика расчёта рейтинга (варианты).
 Вариант 1 (рекомендуемый): рейтинг по накопительному приросту от «точки 0» (чем больше прирост, тем выше место).
 Вариант 2: комплексный рейтинг по взвешенной формуле: прирост от точки 0 + численность + активность членов + выполнение задач. Состав весов утверждается заказчиком.
 4.2.6. Функция «Карточка региона».
 – основные данные региона (название, округ, статус);
 – численность — ввод и обновление;
 – ссылки на сообщества и чаты — добавление, редактирование, удаление;
 – члены — добавление, список, статусы;
 – резиденты (активные члены) — добавление, список;
 – история изменений карточки.
 4.2.6.1. Права редактирования карточки региона (варианты).
 Вариант 1 (рекомендуемый): руководитель регионального отделения редактирует только карточку своего отделения; администратор — карточки всех отделений.
 Вариант 2: все авторизованные пользователи могут редактировать карточки любых региональных отделений (открытая модель).
 4.2.7. Функция «Члены Организации».
 – добавление членов и резидентов (активных членов);
 – просмотр списков, поиск;
 – учёт численности (общая и по категориям).
 4.2.8. Функция «Артефакты».
 – загрузка файлов с привязкой к региону / цели / задаче;
 – список, скачивание, удаление.
 4.2.8.1. Модель хранения артефактов (варианты).
 Вариант 1 (рекомендуемый): простая загрузка файлов (изображения, PDF, DOCX, XLSX, до 50 МБ на файл) с привязкой к объекту.
 Вариант 2: медиатека с категориями, тегами, поиском, версионированием файлов и контролем прав на скачивание.
 4.2.9. Функция «Задачи» (трекер).
 – создание задачи: название, описание, срок, приоритет, ответственный;
 – назначение исполнителя (член Организации / отделение / роль);
 – статусы: новая → в работе → на проверке → выполнена;
 – комментарии, прикрепление артефактов;
 – список задач с фильтрами (мои, по региону, просроченные).
 4.2.9.1. Доступ к задачам (варианты).
 Вариант 1 (рекомендуемый): задачи доступны всем авторизованным членам Организации: каждый ведёт свои задачи; руководитель регионального отделения видит задачи своего отделения; администратор — все задачи.
 Вариант 2: задачи доступны только руководителям региональных отделений и администраторам (члены Организации задачи не ведут).
 4.2.10. Функция «База знаний».
 – статьи, инструкции, материалы Организации;
 – категории, поиск.
 4.2.11. Функция «Календарь событий».
 – события Организации (мероприятия, вебинары, дедлайны);
 – отображение по месяцам;
 – напоминания через бота.
 4.2.12. Функция «Запросы».
 – заявки членов Организации (на вступление, на доступ, на участие в мероприятиях, на поддержку);
 – статусы обработки, ответы.
 4.2.13. Функция «История платформы».
 4.2.13.1. Содержание раздела (варианты).
 Вариант 1 (рекомендуемый): публичная лента новостей и достижений платформы (хронология событий, доступна всем пользователям).
 Вариант 2: внутренний журнал изменений Системы (аудит-лог), доступен только администраторам.
 4.2.14. Функция «Ассистент "Зам"».
 4.2.14.1. Модель ассистента (варианты).
 Вариант 1 (рекомендуемый): AI-ассистент — программный агент на базе технологий искусственного интеллекта. Подключается к личному кабинету владельца; по командам владельца публикует информацию от его имени: заполняет карточку региона, загружает данные для рейтинга, выкладывает артефакты, создаёт задачи. Требования:
 – ассистент действует в рамках прав владельца (не выше);
 – все действия ассистента фиксируются в журнале и доступны владельцу;
 – владелец может отключить ассистента или ограничить его действия (например, только публикация, без удаления);
 – подключение — через настройки кабинета с подтверждением владельца.
 Вариант 2: живой заместитель — отдельная роль «Заместитель» (человек). Владелец кабинета выдаёт заместителю права на публикацию информации от своего имени. Требования:
 – назначение заместителя — владельцем кабинета или администратором;
 – действия заместителя журналируются;
 – владелец может отозвать права в любой момент.
 4.3. Требования к видам обеспечения
 4.3.1. Математическое обеспечение.
 – алгоритм расчёта накопительного прироста от «точки 0»: прирост = значение текущего среза − значение точки 0;
 – алгоритм определения динамики региона/округа (наличие положительного прироста за период);
 – алгоритм расчёта вклада округа в общую цель (сумма приростов регионов округа);
 – алгоритм определения «свежести» выгрузки (не старше 7 дней);
 – (вариант) алгоритм комплексного рейтинга (п. 4.2.5.1, Вариант 2).
 4.3.2. Информационное обеспечение.
 – справочники: регионы (89), федеральные округа (8), роли пользователей, типы целей, типы рассылок, статусы задач, статусы запросов;
 – данные целей: «точка 0» (дата и значение), текущий срез (дата и значение), история срезов;
 – данные региональных отделений: карточка отделения, численность, члены, ссылки на сообщества и чаты;
 – артефакты: файлы с метаданными (тип, размер, автор, дата, привязка);
 – задачи: атрибуты и статусы;
 – советы регионов: текст, автор, регион, цель, дата;
 – журналы: действий пользователей, действий ассистента, рассылок.
 4.3.3. Лингвистическое обеспечение.
 – язык интерфейса — русский;
 – единая терминология: «точка 0», «текущий срез», «прирост», «динамика», «красная зона», «вклад округа», «фокус целей»;
 – тексты сообщений бота — в едином стиле, с персональными вставками (регион, ФИО, числа).
 4.3.4. Программное обеспечение.
 – серверная часть: API (REST), СУБД (реляционная), очередь сообщений для рассылок (при Варианте 2 п. 4.1.13.1);
 – веб-клиент: адаптивная вёрстка (mobile-first), поддержка Chrome и Safari;
 – бот: адаптеры Telegram Bot API и (вариант) MAX Bot API;
 – (вариант) модуль AI-ассистента: интеграция с LLM-провайдером через API;
 – состав конкретного ПО определяется на этапе технического проектирования.
 4.3.5. Техническое обеспечение.
 – серверное оборудование — в соответствии с выбранным вариантом масштаба (п. 4.1.13.1);
 – требования к клиентским устройствам: смартфон с современным браузером, ПК — не ниже типовых офисных конфигураций;
 – хостинг — на территории Российской Федерации.
 4.3.6. Метрологическое обеспечение.
 Система не выполняет измерительных функций; метрологическое обеспечение не требуется.
 4.3.7. Организационное обеспечение.
 – регламент выдачи одноразовых ссылок координаторами;
 – регламент проведения рассылок;
 – регламент загрузки и обновления выгрузок данных;
 – должностные инструкции администратора и координатора.
 4.3.8. Методическое обеспечение.
 – методика работы руководителя регионального отделения с целями и рейтингами;
 – методика формирования «Советов от регионов»;
 – (вариант) методика работы с AI-ассистентом «Зам».
 5. Состав и содержание работ по созданию системы
 Таблица 4 — Состав и содержание работ по созданию системы
 Этап (по ГОСТ 34.601-2020)
 Содержание работ
 Результат
 1. Формирование требований
 Обследование объекта автоматизации, анализ референсной платформы, утверждение ТЗ
 Утверждённое ТЗ
 2. Разработка концепции
 Выбор варианта реализации (по пп. 4.1.13, 4.2), оценка стоимости
 Концепция, план
 3. Техническое задание
 Настоящий документ
 ТЗ
 4. Эскизный проект
 Архитектура, макеты экранов, прототип бота
 Эскизный проект
 5. Технический проект
 Проектные решения по подсистемам, структура БД, API
 Технический проект
 6. Рабочая документация
 Разработка ПО, вёрстка, настройка бота, документация
 Рабочая документация, ПО
 7. Ввод в действие
 Подготовка данных, обучение, опытная эксплуатация, приёмка
 Акт ввода в действие
 8. Сопровождение
 Исправление ошибок, развитие
 Регламент сопровождения
 6. Порядок контроля и приемки системы
 6.1. Виды испытаний:
 – предварительные испытания — после завершения разработки, на тестовых данных;
 – опытная эксплуатация — продолжительностью не менее 30 дней, на реальных данных (пилотные регионы);
 – приёмочные испытания — после успешной опытной эксплуатации.
 6.2. Приёмка осуществляется комиссией заказчика с участием разработчика.
 6.3. Критерии приёмки:
 – реализованы все функции, закреплённые в разделе 4 настоящего ТЗ (по выбранным вариантам);
 – показатели назначения (п. 4.1.3) достигнуты;
 – замечания опытной эксплуатации устранены;
 – документация передана в соответствии с разделом 8.
 6.4. Результаты испытаний оформляются актами по ГОСТ 34.603-2021.
 7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
 – подготовка исходных данных: справочник регионов и округов, «точка 0» и стартовые срезы по целям, база членов Организации;
 – регистрация бота в Telegram и (вариант) MAX, настройка домена (заполняется при утверждении ТЗ);
 – назначение администраторов и координаторов;
 – обучение персонала: администраторов, координаторов, руководителей региональных отделений (вебинары + инструкции);
 – разработка регламентов (п. 4.3.7);
 – план переноса данных из действующих учётных систем Организации (при наличии).
 8. Требования к документированию
 Состав документации:
 – руководство пользователя (сайт);
 – руководство пользователя (бот);
 – руководство администратора;
 – руководство координатора;
 – регламент рассылок;
 – регламент выгрузок данных;
 – (вариант) руководство по работе с AI-ассистентом «Зам»;
 – протоколы и акты испытаний.
 Документация разрабатывается в соответствии с ГОСТ 19.201-78 и ГОСТ 34.201-2020.
 9. Источники разработки
 1. Описание заказчика (краткое описание платформы, назначение, сценарии использования).
 2. Материалы обследования аналогичной действующей платформы (референс функциональности): скриншоты сайта `rmpred.ru` и бота `@pmpred_bot` (Приложение Б).
 3. ГОСТ 34.601-2020 «Стадии создания автоматизированных систем».
 4. ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы».
 5. ГОСТ 34.603-2021 «Виды испытаний автоматизированных систем».
 6. ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».
 7. ГОСТ 34.201-2020 «Виды, комплектность и обозначение документов при создании автоматизированных систем».
 Приложение А. Описание бизнес-процессов (краткое)
 А.1. Сценарий «Вход на сайт».
 Пользователь открывает сайт → выбирает мессенджер (MAX/Telegram) → бот подтверждает вход по одноразовой ссылке → открывается личный кабинет. При повторном использовании ссылки — сообщение об ошибке и запрос новой ссылки у координатора.
 А.2. Сценарий «Еженедельная рассылка».
 Система формирует персональную сводку по каждому региону (прирост от точки 0, динамика округа, рекомендация) → отправляет через бота → кнопка «Открыть цели» ведёт на сайт.
 А.3. Сценарий «Работа с целями».
 Руководитель регионального отделения открывает раздел «Цели организации» → видит общую цель, вклад округов, топ регионов, красную зону, советы → при наличии динамики у отделения в боте появляется кнопка «Дать совет для других лидеров».
 А.4. Сценарий «Ведение региона».
 Руководитель отделения заполняет карточку регионального отделения (численность, ссылки на сообщества и чаты), добавляет членов, загружает артефакты, ведёт задачи.
 А.5. Сценарий «Ассистент "Зам"» (по выбранному варианту п. 4.2.14).
 Владелец подключает ассистента → ассистент публикует информацию от имени владельца → действия фиксируются в журнале.
 Приложение Б. Состав экранов аналогичной действующей платформы (референс функциональности, по скриншотам)
 Ниже приведён состав экранов аналогичной действующей платформы, использованной в качестве референса функциональности. Финальный состав экранов Системы уточняется на этапе эскизного проектирования.
 Таблица Б.1 — Состав экранов референсной платформы
 Экран
 Содержимое
 Вход
 «Вход через рабочий бот», выбор MAX/Telegram, одноразовая ссылка, «Нет доступа? Начните регистрацию через бота»
 Бот — приветствие
 5 шагов: регистрация → заявка на интенсив → онлайн-обучение → Мурманск → защита проекта и грант
 Бот — меню
 Войти на сайт, Мои возможности, Регионы и пользователи, Цели сообщества, Регистрации МПР 2026, Помощь; команды /start /login /requests /regions /goals /mpr /help
 Бот — рассылка
 «Еженедельный фокус целей»: регион, прирост от 11.06.2026, динамика округа, «Что делать», кнопка «Открыть цели»
 Бот — вход
 «{ФИО}, вход выполнен!», «Сайт откроется автоматически», кнопка «Открыть сайт»
 Сайт — меню
 Главная, Цели сообщества, Календарь событий, Запросы, База знаний, Рейтинг регионов, История платформы, Выйти
 Сайт — цели
 Общая цель +1096, вклад округов +338, точка 0 / сейчас / цель, МПР 2026: прирост +2594, 89 регионов с динамикой
 Сайт — динамика
 Точка 0: 2026-05-08, срез: 2026-08-07, автообновление, накопительная динамика регистраций
 Сайт — топ
 Москва +224, Башкортостан +217, Санкт-Петербург +159, ДНР +136, Татарстан +132
 Сайт — красная зона
 Регионы без прироста от точки 0, «все регионы дали прирост», полный список
 Сайт — советы
 «Советы от регионов», пустое состояние с подсказкой про кнопку в боте
 Приложение В. Сводная таблица вариантов решений
 Таблица В.1 — Сводная таблица вариантов решений
 №
 Вопрос
 Вариант 1 (рекомендуемый)
 Вариант 2
 1
 Ассистент «Зам» (п. 4.2.14)
 AI-ассистент (программный агент)
 Живой заместитель (роль-человек)
 2
 Доступ к задачам (п. 4.2.9.1)
 Все авторизованные члены
 Только руководители отделений и администраторы
 3
 Артефакты (п. 4.2.8.1)
 Простая загрузка файлов
 Медиатека с категориями и версиями
 4
 Карточка региона (п. 4.2.6.1)
 Только своё отделение (+админ — все)
 Открытое редактирование
 5
 Рассылки (п. 4.2.3.1)
 Фиксированные шаблоны
 Конструктор рассылок
 6
 Рейтинг (п. 4.2.5.1)
 По приросту от точки 0
 Комплексный (взвешенная формула)
 7
 История платформы (п. 4.2.13.1)
 Публичная лента новостей
 Внутренний аудит-лог
 8
 Мессенджеры (п. 4.1.13.2)
 Telegram + MAX сразу
 Сначала Telegram, MAX — этап 2
 9
 Масштаб (п. 4.1.13.1)
 До 10 тыс. пользователей
 До 100 тыс. пользователей
 10
 Дизайн (п. 4.1.13.3)
 По брендбуку «ОПОРА РОССИИ»
 Новый дизайн-концепт с нуля
 Документ подготовлен как проект для согласования. Позиции, отмеченные как «Вариант 1 (рекомендуемый)», предлагаются к утверждению по умолчанию; заказчик вправе выбрать Вариант 2 по любому пункту.