16 KiB
Анализ технического задания
Документ: ТЗ на создание автоматизированной системы «Платформа ОПОРА РОССИИ» Основание: ГОСТ 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. Сильные стороны
- Чёткая структура и трассируемость — функции (4.2), виды обеспечения (4.3) и приёмка (6.3) связаны между собой.
- Измеримые показатели назначения (4.1.3): время загрузки ≤ 3 с, экран целей ≤ 2 с, рассылка ≤ 1 ч, доступность ≥ 99%.
- Явные варианты решений (Приложение В) — 10 открытых вопросов с рекомендацией «Вариант 1». Это правильный способ зафиксировать неопределённость до согласования.
- Mobile-first и эргономика (4.1.6) — учтён основной сценарий (смартфон, встроенные браузеры мессенджеров).
- Безопасность входа — одноразовые ссылки, блокировка повторного использования, привязка сессии к аккаунту мессенджера, журналирование.
- Референс функциональности (Приложение Б) — состав экранов аналогичной платформы, что снижает риск недопонимания.
- Хостинг на территории РФ (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. Внутренние несоответствия и дефекты
- Битая ссылка на подпункты. П. 4.1.13 (строка 142) ссылается на «пп. 4.1.13.1–4.1.13.10», но фактически существуют только 4.1.13.1–4.1.13.3. Нужно либо добавить подпункты, либо исправить диапазон.
- Расхождение онбординга. П. 4.2.2: 5 шагов — «…защита проекта и получение поддержки». Приложение Б: «…Мурманск → защита проекта и грант». Формулировки и содержание шагов не совпадают.
- Терминология. В основном тексте — «проекты Организации», в Приложении Б — «МПР 2026» / «Регистрации МПР 2026». Нужен единый глоссарий (частично есть в 4.3.3, но «МПР» не раскрыт).
- Ссылки на пункты в таблице В.1 корректны, но в тексте п. 4.1.13.1 назван «Масштаб системы», а в таблице — «Масштаб»; мелочь, но для утверждаемого документа важна точность.
- Приложение Б описывает референс, но не помечено, какие экраны обязательны, а какие — только ориентир. Это создаёт риск спора на приёмке.
- Критерии приёмки (6.3) ссылаются на «выбранные варианты», которые ещё не выбраны. До фиксации вариантов приёмка неопределима.
6. Сводка открытых вопросов (Приложение В)
| № | Вопрос | Рекомендуемый вариант | Влияние на объём |
|---|---|---|---|
| 1 | Ассистент «Зам» | AI-ассистент | Высокое (LLM, безопасность, ПДн) |
| 2 | Доступ к задачам | Все авторизованные | Среднее |
| 3 | Артефакты | Простая загрузка | Низкое/Высокое (медиатека) |
| 4 | Карточка региона | Только своё отделение | Среднее (риск открытой модели) |
| 5 | Рассылки | Фиксированные шаблоны | Высокое (конструктор) |
| 6 | Рейтинг | По приросту от точки 0 | Среднее |
| 7 | История платформы | Публичная лента | Низкое |
| 8 | Мессенджеры | Telegram + MAX сразу | Высокое (риск MAX API) |
| 9 | Масштаб | До 10 тыс. пользователей | Высокое (кластер) |
| 10 | Дизайн | По брендбуку | Среднее |
Рекомендация: зафиксировать все 10 вариантов до заключения договора, иначе объём и стоимость будут плавающими.
7. Рекомендации
Приоритет 1 (блокеры утверждения):
- Заполнить обязательные поля (заказчик, разработчик, сроки, финансирование, шифр, домен).
- Добавить раздел по 152-ФЗ: правовые основания, согласия, сроки хранения, меры защиты, локализация ПДн.
- Зафиксировать выбор по всем 10 вариантам Приложения В.
- Устранить внутренние несоответствия (п. 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-ФЗ), фиксация вариантов, устранение внутренних расхождений и уточнение нефункциональных требований. После этого ТЗ может служить основанием для договора и календарного плана.