Кто пишет ТЗ на разработку и что в нём должно быть: полное руководство

Фраза «заказчик приносит техническое задание» звучит логично, но в реальном IT-проекте почти всегда упрощает процесс. Заказчик приносит потребность, бизнес-контекст, ограничения и ожидания. Превратить их в однозначные, реализуемые и проверяемые требования — совместная работа заказчика, аналитиков, технических специалистов, дизайнера, QA и руководителя проекта.

Хорошее ТЗ не обязано быть документом на сто страниц. Для небольшого продукта это может быть связка из описания целей, границ MVP, пользовательских сценариев, макетов, требований, API-контрактов и критериев приёмки. Важен не объём, а то, может ли команда одинаково понять задачу, оценить её, реализовать и доказать готовность результата.

В статье разберём, кто отвечает за ТЗ, чем отличаются требования в in-house, outstaff и outsource-командах, что обязательно зафиксировать до разработки, как получать реалистичную оценку и как безопасно использовать GPT для подготовки черновика.

Что такое ТЗ на разработку

Техническое задание, или ТЗ, — согласованное описание результата, который нужно создать, условий его работы, ограничений и способа проверки. В международной практике чаще говорят о requirements specification — спецификации требований. ISO/IEC/IEEE 29148 рассматривает требования не как разовый текст, а как результат инженерного процесса, который сопровождает систему на протяжении жизненного цикла.

Поэтому ТЗ может существовать в разных формах:

• единый документ для договора или тендера;

• product backlog с Epic, Story и критериями приёмки;

• набор схем бизнес-процессов и пользовательских сценариев;

• макеты интерфейса и прототипы;

• спецификация API и модель данных;

• требования к безопасности, производительности и эксплуатации;

• план приёмки и матрица трассируемости.

Формат зависит от модели работы, цены ошибки, зрелости продукта и договорных обязательств. Для лендинга и банковской системы глубина документации будет разной, но требование в обоих случаях должно быть понятным, необходимым, непротиворечивым, реализуемым и проверяемым. Эти признаки согласуются с рекомендациями INCOSE по написанию требований.

Кто приносит и кто пишет ТЗ

Полезно разделять три разные ответственности:

1. Инициатор объясняет, какую проблему нужно решить и почему это важно.

2. Автор требований переводит потребность в структурированное и проверяемое описание.

3. Утверждающий принимает решения о приоритете, границах, бюджете и допустимых компромиссах.

В одном небольшом проекте эти роли может совмещать один человек. В крупной компании они распределяются между Product Owner, бизнес-аналитиком, системным аналитиком, владельцем процесса, архитектором и заказчиком.

Иллюстрация 1. Требования становятся рабочими, когда бизнес и техническая команда вместе проверяют сценарии, ограничения и критерии готовности.

Внутренний заказчик

Внутренний заказчик находится внутри компании. Им может быть Product Owner, руководитель отдела продаж, маркетинг, служба поддержки, финансовый директор или владелец бизнес-процесса.

Например, отдел продаж просит автоматизировать распределение входящих заявок. Он лучше всех знает проблему, текущий процесс и желаемый эффект, но не обязан самостоятельно проектировать API, роли доступа или обработку ошибок. Эти детали прорабатываются вместе с аналитиками и командой.

В Scrum ответственность за ценность продукта, Product Goal и управление Product Backlog несёт Product Owner. При этом Scrum Guide прямо допускает, что часть работы по формулированию элементов backlog выполняют другие участники: ответственность Product Owner от этого не исчезает.

Внешний заказчик

Внешний заказчик приходит со стороны и заказывает разработку продукта или отдельной системы. Он предоставляет:

• бизнес-цель и ожидаемый эффект;

• описание пользователей и процессов;

• обязательные функции;

• данные об интеграциях;

• юридические и отраслевые ограничения;

• бюджетные и календарные рамки;

• представителей, уполномоченных отвечать на вопросы и принимать решения.

Заказчик может принести готовый документ. Но исполнитель всё равно должен провести анализ: найти противоречия, неизвестные зависимости, непроверяемые формулировки и пропущенные сценарии. Подписанный файл сам по себе не делает требования полными.

Кто за что отвечает

Схема 2. Заказчик владеет потребностью и решениями о приоритете, аналитики структурируют требования, техническая команда проверяет реализуемость и оценку, QA — проверяемость, PM — управляемость процесса.

Главная ошибка — назначить единственного «писателя ТЗ» и исключить остальных. Аналитик без заказчика может неверно понять цель, заказчик без команды — выбрать нереализуемое решение, разработчик без QA — не предусмотреть проверяемые критерии, а PM без владельца продукта — принять решение, на которое у него нет полномочий.

In-house, outstaff и outsource: как модель команды меняет работу с требованиями

Эти термины описывают не квалификацию разработчиков, а способ организации ответственности и управления.

In-house

In-house-команда работает внутри компании и сохраняет знания о продукте. Коммуникация обычно быстрее, проще проводить эксперименты и менять приоритеты. Обратная сторона — постоянные расходы на найм, развитие и удержание полного состава специалистов.

Во внутреннем продукте требования могут быть легче по форме, но не по смыслу. Если договорённости существуют только в разговорах, новые сотрудники, QA и служба поддержки всё равно потеряют контекст.

Outstaff

При outstaff-модели внешние специалисты встраиваются в процесс заказчика: работают в его backlog, участвуют во встречах и подчиняются согласованным правилам. Заказчик должен обеспечить приоритеты, доступы, документацию, техническое руководство и своевременные решения.

В российской практике слово «аутстафф» используют широко, но договорная и трудовая модель имеет значение. Временное направление работников регулируется главой 53.1 Трудового кодекса РФ. Поэтому юридическую схему нельзя определять только разговорным названием услуги.

Outsource

При outsource-модели заказчик передаёт внешнему исполнителю функцию или проект. IBM определяет outsourcing как использование третьей стороны для выполнения деятельности или предоставления услуг, которые обычно могли бы выполняться внутри компании.

Заказчик не обязан управлять каждым разработчиком, но обязан назначить владельца решений, своевременно предоставлять информацию и принимать результаты. Подрядчик со своей стороны организует команду, декомпозирует объём, управляет рисками и показывает прогресс.

Схема 3. В in-house и outstaff ежедневное управление обычно остаётся у владельца продукта, а в outsource подрядчик берёт на себя организацию поставки согласованного результата.

Для outsource-проекта особенно важно зафиксировать не только функции, но и границы ответственности: кто предоставляет контент и доступы, кто оплачивает сторонние сервисы, сколько итераций дизайна включено, где заканчивается гарантия и как оцениваются новые требования.

Что должно быть в нормальном ТЗ

Универсального шаблона на все случаи нет. Но качественная спецификация должна отвечать на пять вопросов:

1. Зачем создаётся решение?

2. Для кого и в каких сценариях оно работает?

3. Что входит и не входит в объём?

4. Как именно система должна вести себя и с каким качеством?

5. Как участники поймут, что результат принят?

Схема 4. Полноценное ТЗ связывает бизнес-цель, границы, сценарии, функциональные и качественные требования, данные, ограничения и приёмку.

1. Паспорт документа и глоссарий

В начале фиксируют:

• название продукта и версии ТЗ;

• автора, согласующих и дату;

• статус: черновик, на согласовании или утверждено;

• историю изменений;

• связанные документы и макеты;

• определения терминов и сокращений.

Версия нужна не для бюрократии. Она позволяет понять, какой набор требований использовался для оценки, договора и приёмки.

2. Контекст, проблема и цель

Цель описывает изменение в бизнесе или пользовательском опыте, а не саму функцию.

Слабая формулировка:

Сделать новый поиск товаров.

Более сильная:

Сократить медианное время от открытия каталога до перехода в карточку подходящего товара с 90 до 45 секунд для мобильных пользователей в течение трёх месяцев после релиза.

Функция — это output, то есть созданный результат. Изменение показателя — outcome, ради которого результат создаётся. Не каждая задача требует финансовой метрики, но всегда должно быть понятно, какую проблему решает разработка.

3. Границы: in scope и out of scope

Раздел in scope перечисляет, что входит в текущий релиз. Out of scope прямо называет то, чего команда сейчас не делает.

Например, в MVP сервиса объявлений входят создание объявления, каталог и чат. Доставка, безопасная сделка и мобильные приложения не входят. Такая запись защищает проект от скрытого расширения объёма и помогает сравнивать варианты приоритизации.

4. Пользователи, роли и права

Нужно определить:

• типы пользователей;

• цели каждой роли;

• доступные действия;

• ограничения доступа;

• различия между гостем, зарегистрированным пользователем, модератором и администратором;

• правила блокировки и восстановления доступа.

Матрица ролей нужна не только интерфейсу. Она определяет авторизацию на уровне API и данных.

5. Пользовательские сценарии и бизнес-правила

Сценарий описывает путь от намерения пользователя до результата:

1. предусловия;

2. основной поток;

3. альтернативные варианты;

4. ошибки и исключения;

5. итоговое состояние.

Бизнес-правила отвечают на вопросы, которые интерфейс сам не объяснит: кто может редактировать объявление, сколько времени оно активно, когда требуется повторная модерация, кто видит заблокированный контент.

6. Функциональные требования

Функциональные требования описывают, что система должна делать. По классификации IIBA это часть solution requirements — требований к решению.

Хорошее функциональное требование содержит:

• уникальный идентификатор;

• действующее лицо или компонент;

• действие и результат;

• условия выполнения;

• бизнес-правила;

• ошибки и граничные случаи;

• приоритет;

• критерии приёмки;

• связь с бизнес-целью.

Вместо «система позволяет работать с объявлениями» лучше написать отдельные требования на создание, сохранение черновика, публикацию, редактирование, снятие с публикации и удаление.

7. Данные и интеграции

Отдельно описывают:

• сущности и обязательные поля;

• форматы, справочники и правила валидации;

• источники и владельцев данных;

• сроки хранения и удаления;

• импорт, экспорт и миграцию;

• внешние системы и API;

• тайм-ауты, повторные попытки и поведение при недоступности интеграции;

• требования к идемпотентности критичных операций.

Фраза «интегрироваться с CRM» недостаточна. Команде нужны направление обмена, события, состав данных, частота, авторизация, обработка ошибок и ответственный за тестовую среду.

8. Нефункциональные требования

Нефункциональные требования описывают, насколько хорошо и в каких условиях система выполняет функции. IIBA называет их требованиями к качеству или уровню сервиса, а ISO/IEC 25010:2023 предлагает модель характеристик качества программного продукта.

Формулировки «быстро», «удобно», «надёжно» и «безопасно» нельзя проверить. Нужны метрика, порог, условия измерения и способ проверки.

Порог LCP 2,5 секунды соответствует рекомендации Core Web Vitals, но не обязан автоматически попадать в каждый проект. Значения выбирают из бизнес-контекста и подтверждают измерением.

9. UX/UI и доступность

В ТЗ связывают требования с макетами, но макет не заменяет описание поведения. Нужно указать:

• адаптивные разрешения;

• состояния загрузки, пустого результата и ошибки;

• сообщения валидации;

• управление с клавиатуры;

• контраст и текстовые альтернативы;

• поведение длинного текста и больших данных;

• поддерживаемые браузеры и устройства.

WCAG 2.2 содержит проверяемые критерии доступности. Если проект заявляет соответствие уровню AA, нельзя выбрать только удобные пункты: требуется выполнение всех критериев A и AA, применимых к продукту.

10. Критерии приёмки

Критерии приёмки определяют условия, при которых заказчик принимает требование или результат. IIBA рассматривает их как условия, которые должны быть выполнены, чтобы решение считалось приемлемым для ключевых стейкхолдеров.

Пример:

Дано: авторизованный пользователь находится в своём активном объявлении.

Когда: он меняет цену на положительное число и сохраняет форму.

Тогда: новая цена отображается в карточке и каталоге, а время изменения фиксируется в журнале.

Также нужно описать, кто проводит приёмку, на каком стенде, с какими данными, сколько времени даётся на проверку и как фиксируются замечания.

11. Безопасность и законодательные требования

Безопасность нельзя свести к словам «использовать JWT» или «защититься от SQL-инъекций». Механизм выбирается архитектурой, а ТЗ должно зафиксировать требуемый результат:

• правила аутентификации и восстановления доступа;

• авторизацию для каждой операции;

• защиту персональных данных;

• безопасную загрузку файлов;

• журналирование значимых действий;

• ограничение частоты запросов;

• управление секретами;

• шифрование при передаче и хранении;

• реакцию на инциденты и уязвимости.

OWASP ASVS даёт основу для проверки технических мер безопасности веб-приложений. Для продукта, работающего с персональными данными в России, дополнительно анализируют требования Федерального закона № 152-ФЗ. Например, статья 19 требует правовых, организационных и технических мер защиты. Конкретные обязанности должен подтвердить профильный специалист с учётом состава данных и модели обработки.

12. Эксплуатация, релиз и поддержка

ТЗ должно учитывать жизнь продукта после разработки:

• DEV, TEST, PRE-PROD и PROD или другой согласованный набор окружений;

• CI/CD и правила поставки;

• миграции базы данных;

• резервное копирование и восстановление;

• логи, метрики, трассировки и алерты;

• feature flags и план отката;

• инструкции для поддержки;

• гарантийный период и границы сопровождения.

Если эти работы не включены в объём, это также нужно написать явно.

13. Ограничения, допущения, зависимости и изменения

Команда фиксирует:

• обязательные технологии или запреты;

• бюджетные и календарные рамки;

• сторонние лицензии и тарифы;

• доступность представителей заказчика;

• внешние API и поставщиков;

• неизвестные факторы;

• приоритеты Must, Should, Could и Won’t либо другой метод;

• порядок внесения изменений.

Технологический стек не всегда является требованием. Если заказчику важен бизнес-результат, выбор конкретного фреймворка может остаться архитектурным решением команды. Если система должна поддерживаться внутренними специалистами на определённой платформе, стек становится ограничением и фиксируется в ТЗ.

Когда нужны ГОСТы и формальное ТЗ

ГОСТ, отраслевой стандарт или шаблон заказчика нужен, если это предусмотрено договором, тендером, внутренним регламентом или требованиями регулируемой отрасли. Для коммерческого MVP без такого обязательства механическое копирование большой формы может создать документ, который никто не поддерживает.

Рациональный подход:

• определить обязательные нормативные документы;

• выбрать минимально достаточный набор артефактов;

• обеспечить трассируемость цели, требований, реализации и тестов;

• согласовать, что именно считается базовой версией объёма;

• обновлять документацию при принятых изменениях.

Стандарт полезен как контроль полноты, а не как замена анализа.

Как написать требование, которое можно реализовать и проверить

У требования должен быть один основной смысл. Слова «удобный», «современный», «быстрый», «при необходимости» и «и так далее» создают разные трактовки.

Пример слабого требования

Пользователь может удобно и быстро загружать фотографии объявления.

Неясно, сколько файлов допустимо, какие форматы поддерживаются, какой максимальный размер, что происходит при ошибке и как измеряется скорость.

Улучшенный вариант

FR-ADS-07. Загрузка фотографий. Авторизованный пользователь должен иметь возможность прикрепить к объявлению от 1 до 10 изображений в форматах JPEG, PNG или WebP размером до 10 МБ каждое. Перед сохранением система должна проверить фактический тип файла, удалить метаданные EXIF, сформировать превью и показать ошибку для неподдерживаемого или повреждённого файла. Порядок изображений пользователь может менять до публикации.

Критерии приёмки

• объявление нельзя опубликовать без изображения;

• 10 корректных изображений загружаются и сохраняются;

• 11-е изображение не принимается с понятным сообщением;

• файл больше 10 МБ отклоняется до сохранения;

• расширение .jpg с неподдерживаемым содержимым отклоняется;

• после смены порядка карточка показывает изображения в новом порядке.

Такое требование можно оценить, разработать и протестировать. Дополнительные правила безопасности загрузки файлов можно сверить с OWASP File Upload Cheat Sheet.

Когда можно назвать срок разработки

Оценка возможна и на ранней стадии, но её точность зависит от зрелости требований. До детализации команда может дать диапазон для бюджета и планирования. После декомпозиции, проверки интеграций и прототипирования неопределённость уменьшается.

Правильная последовательность:

1. зафиксировать цель, границы и допущения;

2. выделить крупные функциональные блоки;

3. найти неизвестные интеграции и технические риски;

4. подготовить сценарии и критерии приёмки;

5. декомпозировать работу вместе с исполнителями;

6. оценить трудоёмкость и доступную загрузку;

7. учесть зависимости, тестирование, согласования и резерв;

8. представить заказчику диапазон, допущения и уровень уверенности;

9. сократить объём, увеличить ресурсы или изменить срок — но зафиксировать выбранный компромисс.

Схема 5. Срок появляется после уточнения объёма и рисков; ранняя оценка остаётся диапазоном, а не обещанием точной даты.

PMI рекомендует проверять входные данные и допущения оценки, а не выдавать оптимистичное число без основания. Если бизнесу «нужно было вчера», профессиональный ответ — не скрытые переработки и костыли, а прозрачный выбор: уменьшить MVP, перенести менее важные функции, увеличить бюджет или принять конкретный технический долг с владельцем и сроком погашения.

Процесс подготовки ТЗ

Практический процесс выглядит так:

1. Brief. Инициатор описывает проблему, пользователей, желаемый эффект и ограничения.

2. Discovery. Аналитики и команда изучают текущий процесс, данные, альтернативы и риски.

3. Scope. Product Owner или заказчик определяет границы MVP и то, что не входит в релиз.

4. Моделирование. Появляются сценарии, схемы процессов, макеты, модель данных и контракты интеграций.

5. Спецификация. Требования получают идентификаторы, приоритеты и критерии приёмки.

6. Техническое ревью. Разработчики, архитектор, QA, DevOps и безопасность проверяют реализуемость и полноту.

7. Оценка. Исполнители декомпозируют работу и дают диапазон с допущениями.

8. Согласование. Уполномоченный заказчик подтверждает объём, сроки, критерии и порядок изменений.

9. Baseline. Версия требований фиксируется как основание для разработки и приёмки.

10. Управление изменениями. Новые запросы оцениваются по влиянию на объём, сроки, бюджет, качество и риски.

ТЗ не нужно «замораживать навсегда». Его нужно контролируемо развивать. Для каждого существенного изменения фиксируют автора, причину, влияние, решение и новую версию.

Как использовать GPT для подготовки ТЗ

GPT полезен как редактор и ассистент аналитика. Он может:

• разложить неструктурированный brief по разделам;

• предложить вопросы для интервью;

• найти неоднозначные формулировки;

• составить черновик сценариев и критериев приёмки;

• предложить граничные случаи;

• проверить единообразие терминов;

• превратить заметки встречи в список решений и открытых вопросов.

Но модель не знает скрытого контекста компании и может уверенно придумать требования, ограничения или оценки. Поэтому нельзя поручать ей окончательное согласование, архитектурные решения, юридическую квалификацию, безопасность и обещание срока.

Схема 6. ИИ ускоряет черновик и поиск пробелов, но источником истины остаются подтверждённые данные, а финальное решение принимают ответственные люди.

Правила безопасной работы:

• не отправляйте в публичный сервис пароли, секреты, персональные данные и закрытые документы без разрешённого корпоративного контура;

• отделяйте факты от предположений;

• просите модель помечать неизвестные данные;

• проверяйте каждый числовой порог и ссылку;

• проводите ревью с заказчиком и профильными специалистами;

• храните принятую версию в корпоративной системе, а не только в истории чата.

NIST AI RMF Generative AI Profile рекомендует управлять специфическими рисками генеративного ИИ в контексте целей, законодательства и допустимого риска организации.

Готовый промпт для черновика ТЗ

Ниже — полноценный промпт без пропусков. Он просит модель не выдумывать неизвестные факты и выдавать оценку только как диапазон с допущениями.

Ты — старший бизнес-аналитик и системный аналитик веб-продуктов.

Подготовь черновик технического задания на MVP веб-сервиса частных объявлений «Доска». Это самостоятельный продукт, а не копия существующего маркетплейса.

Цель MVP:
проверить, могут ли частные продавцы самостоятельно разместить объявление, а покупатели — найти подходящее предложение и начать диалог с продавцом.

Целевая аудитория:
физические лица старше 18 лет в России.

Платформа:
адаптивное веб-приложение для актуальных версий Chrome, Safari, Firefox и Edge. Нативные мобильные приложения в MVP не входят.

Роли:
1. Гость.
2. Зарегистрированный пользователь.
3. Модератор.
4. Администратор.

Функции MVP:
1. Регистрация по email и паролю, подтверждение email, вход, выход и восстановление пароля.
2. Профиль с именем, городом, аватаром и контактным телефоном.
3. Создание, сохранение черновика, редактирование, публикация, снятие с публикации и удаление объявления.
4. Поля объявления: заголовок, описание, цена, категория, город и от 1 до 10 фотографий.
5. Каталог объявлений с пагинацией, сортировкой по дате и цене, фильтрами по категории, городу и диапазону цены.
6. Карточка объявления с галереей, описанием, ценой, данными продавца и кнопкой начала диалога.
7. Чат один на один по конкретному объявлению, список диалогов и счётчик непрочитанных сообщений.
8. Жалоба на объявление.
9. Модерация объявлений и жалоб.
10. Административная панель для просмотра пользователей и объявлений, блокировки пользователя и скрытия объявления.

В MVP не входят:
безопасная сделка, онлайн-оплата, доставка, рейтинги и отзывы, платное продвижение, видеозвонки, геопоиск на карте, рекомендации на базе машинного обучения и нативные мобильные приложения.

Плановая стартовая нагрузка:
до 5 000 зарегистрированных пользователей, до 500 одновременно активных пользовательских сессий и до 50 000 активных объявлений. Для нагрузочного теста используй профиль 50 запросов в секунду в течение 30 минут и кратковременный пик 100 запросов в секунду в течение 5 минут.

Команда полностью занята проектом:
- 1 Project Manager;
- 1 Business/System Analyst;
- 1 UX/UI Designer;
- 2 Frontend-разработчика;
- 3 Backend-разработчика;
- 1 QA-инженер;
- 1 DevOps-инженер с загрузкой 50%.

Ограничения:
- персональные данные обрабатываются с учётом применимых требований законодательства РФ;
- пароли нельзя хранить в открытом или обратимо зашифрованном виде;
- пользовательский ввод и загрузка файлов должны проходить серверную проверку;
- решение должно иметь журналирование ошибок, мониторинг, резервное копирование и документированный план восстановления;
- окончательный технологический стек выбирает команда после архитектурного ревью;
- Kubernetes не считать обязательным для MVP без доказанной необходимости.

Сформируй документ в следующей структуре:
1. Паспорт и версия документа.
2. Контекст, проблема и измеримые цели.
3. Заинтересованные стороны и матрица ответственности.
4. Допущения, ограничения и зависимости.
5. Границы MVP: in scope и out of scope.
6. Пользовательские роли и матрица прав.
7. Основные пользовательские сценарии.
8. Функциональные требования с уникальными идентификаторами.
9. Для каждого функционального блока — позитивные, негативные и граничные критерии приёмки.
10. Бизнес-правила.
11. Модель данных на уровне сущностей и обязательных полей.
12. Внешние интеграции и поведение при их недоступности.
13. Нефункциональные требования: производительность, нагрузка, доступность, безопасность, конфиденциальность, доступность интерфейса, совместимость, наблюдаемость, резервное копирование и восстановление.
14. Требования к окружениям, CI/CD, релизу и откату.
15. Тестовая стратегия и порядок приёмки.
16. Предварительная декомпозиция на этапы.
17. Предварительная оценка календарного срока диапазоном, с допущениями, рисками и уровнем уверенности.
18. Реестр открытых вопросов.
19. Матрица трассируемости: бизнес-цель → требование → критерий приёмки → вид проверки.

Правила ответа:
- пиши простым русским языком;
- не используй слова «быстро», «удобно», «надёжно» и «безопасно» без измеримого критерия;
- не выдумывай ответы на неизвестные вопросы;
- каждое неизвестное значение помечай как «требует решения» и выноси в реестр открытых вопросов;
- не обещай фиксированный срок до декомпозиции;
- не подменяй требования архитектурой;
- отделяй обязательные требования от рекомендаций;
- для каждого числового порога указывай условия измерения;
- в конце проведи самопроверку документа на полноту, непротиворечивость, реализуемость, проверяемость и трассируемость.

Даже хороший ответ на этот промпт остаётся черновиком. Команда должна проверить его на реальных данных, интеграциях, юридических требованиях и технических ограничениях.

Пример ТЗ: MVP сервиса частных объявлений

Ниже — сокращённый, но пригодный для проектного обсуждения пример. Он показывает уровень конкретики, которого не хватало в исходной формулировке «сделать MVP Авито».

1. Паспорт

• Название: MVP веб-сервиса частных объявлений «Доска».

• Версия ТЗ: 1.0.

• Статус: базовая версия для оценки и разработки.

• Владелец продукта: Product Owner заказчика.

• Автор требований: Business/System Analyst.

• Утверждают: Product Owner, Tech Lead и уполномоченный представитель заказчика.

• Платформа: адаптивное веб-приложение.

2. Цель и критерии успеха

Цель — проверить ключевой цикл двусторонней площадки: продавец публикует объявление, покупатель находит его и начинает диалог.

В течение первых восьми недель пилота команда измеряет:

• не менее 70% пользователей, начавших заполнение корректного объявления, публикуют его;

• медианное время публикации объявления без учёта модерации — не более пяти минут;

• не менее 20% просмотров активного объявления приводят к открытию диалога или просмотру контакта;

• доля технических ошибок в основных сценариях — не более 1% сессий;

• продуктовые метрики считаются аналитикой, а не используются как гарантия рыночного спроса.

3. Границы MVP

Входит:

• регистрация, авторизация и восстановление пароля;

• профиль пользователя;

• CRUD и жизненный цикл объявления;

• фотографии;

• каталог, фильтры, сортировка и карточка объявления;

• чат и уведомления внутри приложения;

• жалобы и модерация;

• административная панель;

• аналитика основных событий;

• мониторинг, резервное копирование и документация релиза.

Не входит:

• онлайн-оплата и безопасная сделка;

• доставка;

• рейтинги и отзывы;

• платное продвижение;

• нативные мобильные приложения;

• рекомендации на базе ML;

• геопоиск по карте;

• интеграция с государственными системами;

• импорт объявлений с внешних площадок.

Схема 7. MVP проверяет публикацию, поиск и коммуникацию; транзакционные и масштабные функции сознательно остаются за его границами.

4. Роли

Любая серверная операция проверяет роль и принадлежность объекта. Скрытие кнопки в интерфейсе не считается защитой.

5. Функциональные требования

FR-AUTH-01. Регистрация

Пользователь регистрируется по уникальному email и паролю, принимает документы сервиса и подтверждает email одноразовой ссылкой.

Критерии приёмки:

• повторная регистрация подтверждённого email не создаёт второй аккаунт;

• ссылка имеет ограниченный срок действия и после использования становится недействительной;

• неподтверждённый пользователь не может публиковать объявления;

• ответы системы не позволяют массово определять наличие email в базе.

FR-AUTH-02. Восстановление пароля

Пользователь запрашивает одноразовую ссылку, задаёт новый пароль и завершает активные сессии, кроме текущей, если это разрешено выбранной политикой.

Критерии приёмки:

• ссылка одноразовая и ограничена по времени;

• после смены пароля старый пароль не работает;

• запросы ограничены по частоте;

• событие записывается в журнал безопасности.

FR-PROFILE-01. Профиль

Пользователь может изменить имя, город, телефон и аватар. Телефон не показывается гостям без отдельного действия пользователя «Показать телефон».

FR-ADS-01. Создание объявления

Авторизованный пользователь создаёт черновик с полями:

• заголовок — от 10 до 80 символов;

• описание — от 50 до 5 000 символов;

• цена — целое число от 0 до 100 000 000 рублей;

• категория — значение из активного справочника;

• город — значение из справочника;

• фотографии — от 1 до 10 файлов JPEG, PNG или WebP до 10 МБ каждый.

Критерии приёмки:

• черновик сохраняется без обязательного заполнения всех полей;

• публикация доступна только после прохождения всех проверок;

• HTML и исполняемый код из пользовательского текста не выполняются;

• неподдерживаемые и повреждённые файлы отклоняются;

• после отправки объявление получает статус На модерации.

FR-ADS-02. Жизненный цикл объявления

Статусы: Черновик, На модерации, Активно, Отклонено, Скрыто, Снято с публикации, Удалено.

Разрешённые переходы фиксируются в матрице состояний. Изменение категории, заголовка, описания или фотографий активного объявления отправляет его на повторную модерацию. Изменение цены не требует повторной модерации, но записывается в журнал.

FR-CATALOG-01. Каталог

Гость и пользователь видят только активные объявления. Доступны:

• пагинация;

• сортировка по дате публикации, возрастанию и убыванию цены;

• фильтры по категории, городу и диапазону цены;

• сохранение фильтров в URL;

• пустое состояние, если результатов нет.

FR-CARD-01. Карточка объявления

Карточка содержит галерею, заголовок, описание, цену, город, дату публикации, имя продавца, ссылку на его профиль и действия «Написать» и «Пожаловаться».

Удалённое или скрытое объявление недоступно публично. Автор и модератор видят его с соответствующим статусом.

FR-CHAT-01. Диалог

Авторизованный покупатель начинает один диалог с продавцом по конкретному объявлению. Разрешены текстовые сообщения длиной от 1 до 2 000 символов.

Критерии приёмки:

• продавец не может открыть диалог с самим собой;

• участники видят только собственные диалоги;

• повторное нажатие «Написать» открывает существующий диалог по объявлению;

• отправитель видит состояние отправки и ошибку;

• счётчик непрочитанных обновляется не позднее пяти секунд после получения сообщения при активном соединении.

FR-COMPLAINT-01. Жалоба

Авторизованный пользователь выбирает причину из справочника, добавляет комментарий до 1 000 символов и отправляет одну активную жалобу на объявление.

FR-MOD-01. Модерация

Модератор видит очередь, данные объявления, историю изменений и жалобы. Он может одобрить, отклонить с обязательной причиной или скрыть активное объявление.

FR-ADMIN-01. Административная панель

Администратор ищет пользователей и объявления, блокирует пользователя с указанием причины и срока, управляет категориями и просматривает журнал действий модераторов.

6. Данные

Основные сущности:

• User;

• UserSession;

• City;

• Category;

• Advertisement;

• AdvertisementImage;

• AdvertisementStatusHistory;

• Conversation;

• Message;

• Complaint;

• ModerationDecision;

• AuditEvent.

Для каждой сущности системный аналитик готовит словарь полей, типы, обязательность, ограничения, связи, срок хранения и правила удаления. Удаление пользовательского аккаунта не должно разрушать обязательные журналы, но персональные данные сохраняются только при наличии законного основания.

7. Интеграции

В MVP используются:

• email-провайдер для подтверждения адреса и восстановления пароля;

• S3-совместимое объектное хранилище для изображений;

• сервис продуктовой аналитики;

• система мониторинга и сбора ошибок.

При временной недоступности email-провайдера запрос ставится в очередь повторной отправки. Пользователь получает нейтральное сообщение, а после исчерпания повторов формируется алерт.

8. Нефункциональные требования

9. Технологические решения

Команда выбирает стек на архитектурном ревью. Базовое направление:

• frontend — React или Next.js;

• backend — Node.js, Python или Go в соответствии с компетенциями команды;

• база данных — PostgreSQL;

• изображения — S3-совместимое хранилище;

• контейнеризация — Docker;

• автоматизация — CI/CD;

• логи, метрики и ошибки — согласованный наблюдаемый стек.

Kubernetes не является обязательным требованием MVP. Его добавляют только при подтверждённой эксплуатационной необходимости.

10. План и предварительный срок

При полном составе команды предварительный диапазон — 14–16 календарных недель:

Это предварительная оценка с ориентировочной точностью ±30%. После декомпозиции backlog, подтверждения дизайна, email-провайдера и инфраструктуры команда должна обновить оценку. Срок предполагает полную доступность Product Owner для решений не реже двух раз в неделю и отсутствие платёжной функции.

11. Приёмка

Результат принимается на PRE-PROD по согласованным критериям. Заказчик получает:

• ссылку на сборку;

• тестовые учётные записи;

• перечень функций версии;

• протокол выполненных проверок;

• список известных ограничений;

• инструкцию администратора;

• план релиза и отката.

Критичное замечание блокирует приёмку. Некритичные замечания фиксируются отдельными задачами и не расширяют автоматически согласованный объём.

12. Основные риски

Этот пример не заменяет Discovery, но показывает, чем рабочее ТЗ отличается от списка функций: оно связывает цель, границы, правила, качество, проверку и условия оценки.

Чек-лист готовности ТЗ

Перед передачей в разработку проверьте:

• цель и владелец решения определены;

• in scope и out of scope согласованы;

• роли и права описаны;

• основные, альтернативные и ошибочные сценарии разобраны;

• каждое требование имеет идентификатор и приоритет;

• числовые пороги имеют условия измерения;

• интеграции и владельцы доступов известны;

• макеты содержат все состояния;

• критерии приёмки проверяемы;

• безопасность, персональные данные и эксплуатация учтены;

• зависимости и допущения записаны;

• команда участвовала в оценке;

• порядок изменений согласован;

• нет противоречий между текстом, макетами и API;

• неизвестные вопросы имеют владельца и срок решения.

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

Заказчик сам выбрал решение до исследования проблемы

Фраза «нам нужен чат-бот» описывает средство, а не цель. Возможно, проблему быстрее решит изменение формы, базы знаний или процесса поддержки.

ТЗ состоит только из позитивного сценария

Реальная система должна обрабатывать ошибки, пустые состояния, повторные запросы, отсутствие прав, недоступность интеграций и повреждённые данные.

Нефункциональные требования не измеряются

«Высокая производительность» не даёт оснований ни разработчику, ни тестировщику. Нужны профиль нагрузки, метрика и порог.

Стек назначен без архитектурной причины

Docker, Kubernetes, микросервисы или JWT не делают продукт автоматически надёжным. Сначала определяют требования, затем выбирают минимально достаточное решение.

Срок назван одним числом без допущений

Заказчик воспринимает его как обязательство, хотя команда ещё не проверила интеграции и объём. Диапазон с рисками честнее и полезнее.

GPT принят за источник истины

Модель может красиво оформить ошибочное предположение. Любое сгенерированное требование должно иметь источник и ответственного за подтверждение.

Как мы готовим требования в Avenir

В Avenir мы начинаем не с шаблона, а с цели проекта и границ решения. Проводим интервью, моделируем пользовательские и системные сценарии, связываем макеты с требованиями, проверяем интеграции и только после этого вместе с командой формируем оценку.

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

Подробнее о разработке цифровых продуктов — на сайте Avenir.

Методологическая база

Материал опирается на первичные и профильные источники:

• ISO/IEC/IEEE 29148:2018 — процессы инженерии требований;

• IIBA Business Analysis Standard и BABOK — типы требований и бизнес-анализ;

• INCOSE Guide for Writing Requirements — качества отдельных требований и их набора;

• Scrum Guide — ответственность Product Owner и Scrum Team;

• ISO/IEC 25010:2023 — модель качества программных продуктов;

• OWASP ASVS — проверяемые требования безопасности веб-приложений;

• WCAG 2.2 — доступность веб-контента;

• NIST AI RMF: Generative AI Profile — управление рисками генеративного ИИ.

Ни один стандарт не следует применять механически. Глубина ТЗ должна соответствовать масштабу продукта, договору, зрелости команды, цене ошибки и требованиям отрасли.

Частые вопросы о ТЗ

Кто обязан написать ТЗ: заказчик или исполнитель?

Заказчик отвечает за потребность, бизнес-правила и согласование результата. Исполнитель обычно помогает собрать и формализовать требования. Точное распределение обязанностей закрепляют в договоре и RACI-матрице.

Может ли разработчик начать без полного ТЗ?

Да, если команда осознанно работает итерационно и ближайшая задача достаточно подготовлена. Но должны быть понятны цель, границы, критерии приёмки и зависимости. Отсутствие одного большого документа не означает отсутствие требований.

Чем ТЗ отличается от брифа?

Бриф фиксирует исходный запрос и контекст. ТЗ описывает согласованный результат, поведение системы, ограничения и проверку. Бриф — вход для анализа, ТЗ — один из его результатов.

Чем функциональные требования отличаются от нефункциональных?

Функциональные требования описывают возможности и поведение системы. Нефункциональные — качество и условия этого поведения: скорость, безопасность, доступность, совместимость и восстановление.

Можно ли написать ТЗ только в Jira?

Можно, если backlog связан с целями, макетами, системной документацией, критериями приёмки и версиями. Важно, чтобы информация оставалась целостной и доступной всем участникам.

Можно ли полностью доверить ТЗ GPT?

Нет. GPT ускоряет подготовку черновика и поиск пробелов, но не несёт ответственности за факты, архитектуру, право, безопасность, сроки и согласование с заказчиком.