Артефакты и требования: что руководитель контролирует и как

← назад к разделу

Инженер, ставший руководителем, обычно знает требования с одной стороны: получал задачу и ругался на её качество. Теперь он отвечает за то, чтобы между идеей заказчика и релизом не терялся смысл. Писать документы сам он не должен. Его работа: чтобы нужные документы существовали, у каждого был владелец, и по каждому требованию было видно, где оно реализовано и чем проверено.

Как отличить хорошее требование от плохого, разобрано в статье про уровни и свойства требований. Здесь другой вопрос: какой набор артефактов нужен проекту и как руководителю держать его в порядке.

Обязательно

Карта артефактов: что за чем идётспросят на собеседовании

Названий много, а уровней немного. Документы отличаются тем, на какой вопрос отвечают и кто их читает.

Артефакт	Вопрос	Читатель	Когда не нужен
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: фиксируем архитектурные решения - где хранить ответ на «почему так».
Стейкхолдеры и ожидания - как договариваться с владельцами бизнес-требований.