Инженер, ставший руководителем, обычно знает требования с одной стороны: получал задачу и ругался на её качество. Теперь он отвечает за то, чтобы между идеей заказчика и релизом не терялся смысл. Писать документы сам он не должен. Его работа: чтобы нужные документы существовали, у каждого был владелец, и по каждому требованию было видно, где оно реализовано и чем проверено.
Как отличить хорошее требование от плохого, разобрано в статье про уровни и свойства требований. Здесь другой вопрос: какой набор артефактов нужен проекту и как руководителю держать его в порядке.
Карта артефактов: что за чем идётспросят на собеседовании
Названий много, а уровней немного. Документы отличаются тем, на какой вопрос отвечают и кто их читает.
| Артефакт | Вопрос | Читатель | Когда не нужен |
|---|---|---|---|
| BRD (бизнес-требования) | Зачем и какой результат для бизнеса | Заказчик, спонсор, руководство | Мелкая доработка внутри понятной цели |
| ФТ / FSD (функциональная спецификация) | Что система делает: сценарии, правила, роли | Разработка, QA, аналитики соседей | Никогда, меняется только форма: от документа до набора историй с критериями приёмки |
| ТЗ по ГОСТ | Юридически значимый перечень требований и порядок приёмки | Заказчик, приёмочная комиссия, юристы | Внутренняя продуктовая разработка без договора на создание системы |
| SRS | Требования к программе целиком, включая нефункциональные | Разработка, архитектор, QA | Когда ФТ плюс design doc уже это покрывают |
| Design doc | Как строим и почему так | Инженеры, ревьюеры архитектуры | Задача без развилок |
| API-контракт | Что ровно передаётся между системами | Команды-потребители, QA | Нет внешних потребителей |
| Тест-модель | Чем проверяем каждое требование | QA, разработка, приёмка | Не бывает ненужной |
Две вещи из этой таблицы стоит запомнить. Первая: ТЗ и SRS не уровни, а форматы. ТЗ по ГОСТ это договорной документ для заказной разработки и госсектора, SRS это инженерный документ о требованиях к программе. В продуктовой компании их часто нет вовсе, а их роль играют ФТ и design doc. Вторая: документ «как строим» (design doc) не заменяет документ «что должно получиться». Когда проект пишет только design doc, критерии приёмки рождаются у разработчика в голове.
Для SRS международный ориентир сейчас ISO/IEC/IEEE 29148:2018 «Systems and software engineering - Life cycle processes - Requirements engineering». Старый IEEE 830-1998, который до сих пор встречается в шаблонах, IEEE отметил как заменённый стандартом 29148:2011, а тот в 2018 году вышел второй редакцией.
Кто за какой документ отвечаетспросят на собеседовании
Чаще всего проблема не в качестве документа, а в том, что у него нет владельца. Владелец это не тот, кто напечатал текст, а тот, кто отвечает на вопросы по нему и вносит изменения.
| Артефакт | Владелец | Согласует | Руководитель следит |
|---|---|---|---|
| BRD | Заказчик или продакт-овнер | Спонсор | Есть ли измеримый результат |
| ФТ / истории | Системный или бизнес-аналитик, в продуктовой команде продакт | Лид разработки, QA | Есть ли критерии приёмки до начала работы |
| ТЗ по ГОСТ | Аналитик со стороны исполнителя, утверждает заказчик | Архитектор, руководитель проекта, юрист | Разделы приёмки и документирования не пустые |
| Design doc, ADR | Ведущий инженер или архитектор | Ревьюеры из соседних команд | Ревью прошло до кода |
| API-контракт | Команда-поставщик API | Команды-потребители | Изменения проходят проверку совместимости |
| Тест-модель | QA-лид | Аналитик | Покрытие требований, а не число кейсов |
Руководитель не владеет ни одним документом из таблицы, и это правильно. Если он пишет ФТ сам, значит, в команде не хватает аналитика, и это надо решать наймом или перераспределением, а не героизмом. Связь с владением сервисами описана в статье про структуру команды и владение.
API-контракт как артефакт требований
Для интеграций главное требование это контракт. В подходе contract-first спецификацию OpenAPI пишут и согласуют до кода, по ней генерируют заглушки, а потребители начинают работу параллельно. Подробно о процессе и ловушках генераторов в статье API-first и contract-first, о правилах версий в статье про версионирование REST API. Актуальная ветка спецификации OpenAPI 3.2, последняя редакция 3.2.1 от 10 сентября 2026 года опубликована на spec.openapis.org.
Что из этого нужно руководителю:
- Контракт лежит в репозитории и проходит ревью, как код. Контракт в вики или в письме устаревает через спринт.
- Ломающие изменения видны в сборке. Сравнение спецификаций в CI отвечает на вопрос «сломаем ли мы кого-то» до релиза, а не после звонка соседней команды.
- Версия означает договор. В семантическом версионировании мажорная версия растёт при обратно несовместимых изменениях API. Если команда выпускает несовместимое изменение без новой версии, это инцидент процесса, а не мелочь.
- У каждой версии есть дата вывода из эксплуатации и список потребителей. Без него v1 живёт годами.
Трассировка: от требования до тестаспросят на собеседовании
Трассировка отвечает на три вопроса, которые рано или поздно задаёт заказчик или аудит: откуда взялась эта функция, всё ли из обещанного сделано, чем это проверено. Если ответ требует недели раскопок, трассировки нет.
Минимальная цепочка выглядит так:
BR-07 Сократить время оформления заявки с 15 до 5 минут
FR-31 Автозаполнение реквизитов по ИНН
STORY-412 Подстановка реквизитов из справочника
PR !1873, !1880
TC-118, TC-119 (ручные), autotest requisites_by_inn_*
NFR-04 Ответ автозаполнения не дольше 1 секунды при 200 запросах в секунду
STORY-415 Кэш справочника
TC-L-12 (нагрузочный)
Как это сделать без отдельной бюрократии:
- Идентификатор у каждого требования. Без номера на требование нельзя сослаться, а значит, нельзя и проследить.
- Связи живут в трекере, а не в таблице. Задача ссылается на требование, тест-кейс на задачу или требование, коммит и merge request на задачу. Матрица трассируемости тогда строится выгрузкой, а не руками.
- Обратная проверка раз в итерацию. Два отчёта: требования без задач (обещали и забыли) и задачи без требований (делаем то, что никто не просил). Второй отчёт обычно интереснее первого.
- Трассировка соразмерна риску. Для ТЗ с приёмкой комиссией нужна полная цепочка до протокола испытаний. Для внутренней продуктовой фичи хватает связи «история - критерии приёмки - автотест».
Сама матрица трассируемости для тестировщика разобрана в статье про тестирование требований.
Контроль качества без микроменеджментаспросят на собеседовании
Читать каждый документ целиком руководитель не может и не должен. Контролируют не текст, а точки, в которых плохой артефакт становится дорогим.
Определение готовности на входе. Задача не берётся в работу, пока у неё нет критериев приёмки, а требование не уходит в ТЗ, пока у него нет способа проверки. Это правило команды, а не ваша личная проверка: его соблюдение видно на планировании.
Ревью артефакта как ревью кода. ФТ читают разработчик и тестировщик до старта, контракт читают потребители, design doc проходит ревью дизайна. Руководитель проверяет факт ревью и число открытых вопросов, а не формулировки. Приём QA задавать вопросы к требованиям работает на любом уровне.
Выборочное чтение. Раз в месяц возьмите одно требование и пройдите цепочку до теста сами. Десять минут дают больше, чем отчёт о «готовности документации на 90 процентов».
Метрики сигнала, а не отчётности. Полезны три числа:
| Сигнал | Что значит рост |
|---|---|
| Доля задач, вернувшихся с тестирования из-за непонятного требования | ФТ пишется без участия QA |
| Число изменений требований после начала разработки | Требования не согласованы с владельцем бизнес-цели |
| Требования без тестов в матрице к релизу | Приёмка будет спором, а не проверкой |
Где руководитель обязан вмешаться сам: требование меняется в середине итерации без решения владельца, два документа противоречат друг другу и никто не берётся решить, ТЗ подписывается с пустым разделом приёмки. Всё остальное решают владельцы.
Типичные ошибки
- Документ ради документа. SRS на 200 страниц, который никто не открывал после согласования. Проверка простая: спросите разработчика, где описано поведение, которое он сейчас делает. Если ответ «в задаче в трекере», документ мёртв.
- ТЗ пишет исполнитель в одиночку. Заказчик подписывает не читая, а на приёмке выясняется, что «очевидное» не записано. Если разделы цели и приёмки заполнил только исполнитель, спор на приёмке почти гарантирован.
- Нефункциональные требования в конце и одной строкой. «Система должна работать быстро» не проверить. Нагрузка, время ответа, доступность и требования к персональным данным пишутся с числами, иначе их не будет в оценке.
- Контракт API меняется в коде, а не в спецификации. Документация расходится с реальностью, потребители узнают об этом в продакшене.
- Трассировка для аудита, а не для работы. Матрицу заполняют в последнюю неделю перед сдачей. Она тогда описывает желаемое, а не сделанное.
- Руководитель становится главным редактором. Все документы идут через него, он узкое место, а владельцы перестают отвечать за качество.
Глубже: ТЗ по ГОСТ 34.602-2020расширенноеспросят на собеседовании
Если вы делаете системы для госзаказчика, банка или крупной промышленной компании, слово «ТЗ» почти всегда значит ГОСТ 34.602. Действующая редакция ГОСТ 34.602-2020 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» введена с 1 января 2022 года приказом Росстандарта от 19.11.2021 № 1522-ст взамен ГОСТ 34.602-89. В тендерной документации до сих пор пишут «по ГОСТ 34.602-89»: это повод уточнить у заказчика редакцию до подписания, а не после.
Обязательные разделы ТЗ на АС по тексту стандарта (раздел 4):
- Общие сведения.
- Цели и назначение создания автоматизированной системы.
- Характеристика объектов автоматизации.
- Требования к автоматизированной системе.
- Состав и содержание работ по созданию автоматизированной системы.
- Порядок разработки автоматизированной системы.
- Порядок контроля и приёмки автоматизированной системы.
- Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу АС в действие.
- Требования к документированию.
- Источники разработки.
Что важно руководителю из самого стандарта:
- Раздел без требований не удаляют, а оставляют с пометкой, что требований нет. Пустой раздел приёмки поэтому заметен сразу.
- Изменения оформляют дополнением, которое становится неотъемлемой частью ТЗ. Правки «по почте» юридически не существуют, и на приёмке комиссия сверяет систему с подписанным текстом.
- Допускаются частные ТЗ на составные части (подсистемы, программное обеспечение, оборудование), и они не должны повторять разделы общего ТЗ. Для программного обеспечения стандарт отсылает к ЕСПД, единственная нормативная ссылка в нём ГОСТ 19.201 «ЕСПД. Техническое задание. Требования к содержанию и оформлению».
Практика: раздел «Порядок контроля и приёмки» пишите вместе с QA-лидом, а не в последний день. Именно по нему через год будут подписывать акт, и каждое расплывчатое слово в нём превращается в неделю спора.
Глубже: какие диаграммы UML нужны менеджерурасширенноеспросят на собеседовании
Действующая версия UML 2.5.1 опубликована OMG в декабре 2017 года. Рисовать её руководителю не нужно, читать нужно. Достаточно четырёх видов.
| Диаграмма | Что показывает | Зачем менеджеру |
|---|---|---|
| Вариантов использования | Кто из ролей что делает в системе | Проверить объём: все ли роли и сценарии из BRD учтены |
| Последовательности | Порядок вызовов между системами во времени | Увидеть интеграции, синхронные цепочки и точки отказа |
| Состояний | Жизненный цикл сущности: заявка, заказ, платёж | Найти пропущенные переходы: отмена, возврат, повтор |
| Деятельности | Бизнес-процесс с развилками | Сверить процесс с тем, как работает заказчик на самом деле |
Диаграмма классов и компонентов для архитектуры обычно уступает модели C4, которая читается без знания нотации. Вопрос, который стоит задавать к любой диаграмме: что на ней не нарисовано. Пропущенный переход «отменено после оплаты» на диаграмме состояний стоит дешевле, чем такой же пропуск в продакшене.
Коротко
- Уровней требований мало: зачем (BRD), что делает система (ФТ, истории), как строим (design doc), что передаётся между системами (контракт), чем проверяем (тест-модель). ТЗ и SRS это форматы, а не уровни.
- У каждого артефакта есть владелец, и это не руководитель. Руководитель следит, что владелец есть и документ проходит ревью.
- Трассировка строится связями в трекере: требование, задача, merge request, тест. Раз в итерацию смотрят требования без задач и задачи без требований.
- Качество контролируют в точках перехода: критерии приёмки на входе в работу, ревью артефактов, выборочный проход цепочки, три сигнальные метрики.
- Для заказной разработки действует ГОСТ 34.602-2020 с 1 января 2022 года; изменения только дополнением, раздел приёмки пишут вместе с QA.
- Из UML менеджеру хватает четырёх диаграмм на уровне чтения: варианты использования, последовательности, состояния, деятельности.
- API-контракт хранится в репозитории, совместимость проверяется в сборке, несовместимое изменение означает новую мажорную версию.
Что почитать дальше
- Уровни и свойства хороших требований - как проверить отдельное требование.
- От модели понятий к контракту, который исполняет агент - спецификация среза, по которой можно принимать работу.
- Как оформить и защитить дизайн системы - design doc, C4 и ревью дизайна.
- API-first и contract-first - контракт раньше кода.
- ADR: фиксируем архитектурные решения - где хранить ответ на «почему так».
- Стейкхолдеры и ожидания - как договариваться с владельцами бизнес-требований.