ТЗ по ГОСТ vs SRS на собеседовании системного аналитика

Зачем спрашивают на собесе SA

В РФ работают и госсектор / банки (ГОСТ обязателен), и продуктовые команды (Agile + SRS-стиль). На собесе SA: «опиши структуру ТЗ по ГОСТ», «чем SRS отличается от ГОСТ», «как описать нефункциональные требования». Senior — нюансы РТМ, версионирования, deviation.

Главная боль без понимания — SA пришёл из стартапа в банк, написал ТЗ как user stories — банковский комплаенс отказывается принимать.

ТЗ по ГОСТ 34.602: структура

ГОСТ 34.602-2020 — стандартное Техническое задание на создание автоматизированной системы (АС). Используется в госсекторе, телекомах, банках.

Обязательные разделы:

1. Общие сведения

   • Полное и сокращённое наименование системы
   • Заказчик и исполнитель
   • Основания для разработки
   • Плановые сроки начала и окончания
   • Источники финансирования
   • Порядок оформления и предъявления заказчику результатов работ

2. Назначение и цели создания системы

   • Назначение (для чего)
   • Цели (что должно быть достигнуто)

3. Характеристика объектов автоматизации

   • Описание объекта, на котором эксплуатируется АС
   • Сведения об условиях эксплуатации

4. Требования к системе

   • 4.1. Требования к системе в целом (структура, режимы функционирования, надёжность, безопасность, эргономика и т.д.)
   • 4.2. Требования к функциям (задачам) системы
   • 4.3. Требования к видам обеспечения (информационное, программное, техническое, организационное, методическое)

5. Состав и содержание работ по созданию системы

6. Порядок контроля и приёмки

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие

8. Требования к документированию

9. Источники разработки

Особенности:

• Жёсткий формат с пронумерованными разделами.
• Обязательные виды испытаний (ПИ — предварительные, ПрИ — приёмочные).
• Связь с другими ГОСТ 34 (комплект документации: ОР, ТЗ, ТП, РП и т.д.).
• РД 50-34.698 — требования к содержанию документов.

ГОСТ 19 — для программных продуктов (изделия), 34 — для АС. Разные стандарты, иногда комбинируются.

SRS (IEEE 830 / 29148)

Software Requirements Specification — стандарт описания требований к ПО.

Структура (упрощённая):

1. Introduction

   • Purpose
   • Scope
   • Definitions, acronyms, abbreviations
   • References
   • Overview

2. Overall Description

   • Product perspective (контекст системы)
   • Product functions (что делает на высоком уровне)
   • User characteristics (кто пользователи)
   • Constraints (юридические, технические, организационные)
   • Assumptions and dependencies

3. Specific Requirements

   • Functional requirements (что должна делать система — детально)
   • Non-functional requirements (производительность, безопасность, надёжность)
   • External interface requirements (UI, API, hardware)
   • Other requirements

4. Appendices

Свойства SRS:

• Гибче ГОСТ — можно адаптировать структуру.
• Каждое требование имеет уникальный ID (REQ-001, FR-3.2.1).
• Тестируемые требования — обязательно.
• Часто использует use cases и user stories внутри.

IEEE 29148 — современная замена 830, объединяет с системными требованиями (ISO/IEC/IEEE 29148:2018).

Чем отличаются практически

Виды требований

Стандартный набор (применяется в обоих стандартах с разной формулировкой):

Функциональные — что система должна делать.

ФТ-1: Система должна позволять регистрировать заказы через REST API.
ФТ-2: Система должна отправлять SMS-уведомление об оплате.

Нефункциональные:

• Performance: «P95 < 300 мс при 100 RPS».
• Reliability: «Availability ≥ 99.9% за месяц», «MTTR < 30 мин».
• Security: «Аутентификация по OAuth 2.0», «шифрование данных at rest AES-256».
• Maintainability: «Документация API через OpenAPI», «логи в формате JSON».
• Usability: «Десктопная версия Chrome ≥ 100», «доступность WCAG AA».
• Portability: «Работает на Linux x86_64 и ARM».
• Compliance: «152-ФЗ, ПДн локализованы в РФ».

Бизнес-требования — высокоуровневые цели бизнеса.

Пользовательские требования — что юзеры ожидают.

Системные требования — конкретные технические предписания (детализация).

Переходные требования — миграция с предыдущей системы (только для апгрейдов).

Когда что использовать

ГОСТ 34.602:

• Госконтракты (44-ФЗ, 223-ФЗ).
• Заказная разработка для банков, телекомов, ОПК.
• Аудит требует формальную документацию.
• Есть СБ / комплаенс / юристы, которые проверяют.

SRS:

• Внутренняя разработка коммерческого продукта.
• Стартапы / продуктовые команды.
• Международная разработка.
• Iterative / Agile с эволюцией требований.

Гибрид:

• Большие продуктовые команды в банках/телекомах: высокоуровневое ТЗ по ГОСТ + детализация в Confluence через user stories.

Гибридный подход в продуктовых командах

Реалистичный подход, который чаще всего применяется в РФ-продуктовых командах:

• Vision / OKR — на уровне бизнеса.
• Roadmap — крупными мазками.
• Epic / User Story — детализация спринтов в Jira.
• Acceptance Criteria — для каждого story.
• API contract в OpenAPI — для интеграций.
• PRD (Product Requirements Document) — для крупных фич, замена ТЗ.
• Confluence / Notion — единая база знаний.

ГОСТ-формат остаётся для:

• Договорных обязательств с заказчиком (агентство, госконтракт).
• Регуляторных требований (ЦБ РФ, ФСТЭК, ПДн).
• Архивной документации с длинным сроком хранения.

Частые ошибки

Применять ГОСТ-формат там, где он не нужен. Накатать 200 страниц ТЗ для 2-недельного спринта — потеря времени.

Не указывать ID требований. Без ID невозможно сделать трассировку — какое требование закрывается какой задачей и каким тестом.

Смешивать функциональные и нефункциональные. «Система должна работать быстро» — это не функциональное, это NFR. Ставь в правильную секцию.

Описывать решение вместо требования. «Использовать PostgreSQL» — это решение, не требование. Требование — «время ответа < 200 мс».

Размытые формулировки. «Должно быть удобно», «надёжно», «эффективно» — не тестируемо.

Игнорировать nonfunctional. Производительность, безопасность, accessibility часто забывают, потом героически переделывают на этапе нагрузочного тестирования.

Не вести версионирование. Без version, changelog, approvers документ моментально устаревает и теряет authority.

Копировать ТЗ из соседнего проекта. Структура одинаковая, но содержание разное. Слепое копирование = ошибки и неприменимые требования.

Связанные темы

• User Stories и Acceptance Criteria для SA
• Acceptance Criteria Given/When/Then на собесе SA
• UML Use Case на собесе SA
• OpenAPI и Swagger на собесе SA
• Подготовка к собесу системного аналитика

FAQ

ГОСТ 34 или ГОСТ 19?

ГОСТ 34 — для автоматизированных систем (АС). ГОСТ 19 — для программных продуктов как изделия. Если предмет договора — «АС», ГОСТ 34. «Программа» — ГОСТ 19. На практике в банках чаще ГОСТ 34.

Можно ли составить ТЗ по ГОСТ в Agile?

Технически — да, на старте проекта (waterfall начало) с дальнейшей детализацией. На практике Agile-команды используют PRD/SRS, а ГОСТ — формальная обёртка для контракта.

SRS требует use cases?

Не обязательно, но в IEEE 830 use cases — типовая часть детализации функциональных требований. Можно через user stories в современных интерпретациях.

Как обновлять ТЗ?

Через формальный change request с одобрением заказчика. Версионирование документа обязательно. В Confluence — история правок встроена.

Что делать, если требования противоречат?

Эскалация к стейкхолдерам, фиксация решения в дополнении к ТЗ, обновление трассировки. SA часто медиатор в таких случаях.

Это официальная информация?

Нет. Статья основана на ГОСТ 34.602-2020, IEEE 830-1998, ISO/IEC/IEEE 29148:2018 и практике документирования.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.