# Анализ технического задания

**Документ:** ТЗ на создание автоматизированной системы «Платформа ОПОРА РОССИИ»
**Основание:** ГОСТ 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-ФЗ), фиксация вариантов, устранение внутренних расхождений и уточнение нефункциональных требований. После этого ТЗ может служить основанием для договора и календарного плана.