Документ требований нужен не для галочки: по нему разрабатывают, тестируют, принимают работу и разбирают споры. В РФ встречаются два мира: формальное ТЗ по ГОСТ 34 (госсектор, банки, крупные заказные проекты) и живая документация в Confluence или репозитории (продуктовые команды).
ГОСТ 34 кратко
Серия стандартов на автоматизированные системы (АС).
- ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы» (заменил ГОСТ 34.602-89, действует с 2022 года).
- ГОСТ Р 59793-2021 «Стадии создания автоматизированных систем» (заменил ГОСТ 34.601-90).
- ГОСТ 34.201-2020: виды, комплектность и обозначение документов.
Типовые разделы ТЗ по ГОСТ 34.602:
- Общие сведения (название, заказчик, исполнитель, сроки, основания).
- Цели и назначение создания системы.
- Характеристика объекта автоматизации.
- Требования к системе: в целом (структура, надёжность, безопасность, эргономика, совместимость), к функциям (задачам), к видам обеспечения (информационному, программному, техническому и др.).
- Состав и содержание работ.
- Порядок разработки системы.
- Порядок контроля и приёмки.
- Требования к подготовке объекта автоматизации к вводу системы в действие.
- Требования к документированию.
- Источники разработки.
Плюсы: полнота, юридическая сила, понятно, что принимать. Минусы: долго, тяжело менять, часто превращается в «книгу, которую никто не читает».
Другие форматы
- SRS (Software Requirements Specification) по ISO/IEC/IEEE 29148: структура введение, общее описание, конкретные требования.
- Частное ТЗ (ЧТЗ) на модуль или доработку.
- Спецификация фичи в Confluence: контекст, цель, user stories, макеты, API, данные, NFR, открытые вопросы.
- Docs as code: требования, OpenAPI, диаграммы (PlantUML, Mermaid) в Git рядом с кодом, ревью через pull request.
Что делает документ хорошим
- Есть цель и контекст: зачем, для кого, как измерим успех.
- Глоссарий: термины определены один раз.
- Требования пронумерованы: на них ссылаются тесты и задачи.
- Граничные случаи и ошибки описаны, а не только счастливый путь.
- Открытые вопросы вынесены отдельно с владельцем и сроком.
- История изменений: версия, дата, что поменялось.
Управление изменениями требований
- Базовая линия (baseline): согласованная версия, от которой считаются изменения.
- Запрос на изменение: что меняется, зачем, влияние на сроки, стоимость, другие требования (анализ влияния по матрице трассировки).
- Согласование и обновление всех связанных артефактов.
Частые ошибки
- Копировать шаблон ГОСТ и заполнять «водой».
- Писать требования без единиц измерения и условий.
- Держать актуальную версию в почте и чате, а не в одном месте.
- Не помечать, что изменилось после согласования.
Что спросят на собесе
- Что входит в ТЗ по ГОСТ 34? Какой стандарт сейчас действует?
- Чем ТЗ по ГОСТ отличается от спецификации в Agile-команде?
- Как ты организуешь документацию, чтобы она не устаревала?
- Как обрабатываешь изменение требований после согласования?
- Что такое docs as code?