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

docs/analiz_TZ.md

@@ -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-ФЗ), фиксация вариантов, устранение внутренних расхождений и уточнение нефункциональных требований. После этого ТЗ может служить основанием для договора и календарного плана.