Границы работ
Что входит в проект, что исключено и какие есть зависимости.
Техническое задание
Опишите требования так, чтобы результат можно было проверить
Свяжите границы проекта, требования, сценарии и критерии приёмки в одной системе идентификаторов.
01структура ТЗ02REQ-0103пользовательские сценарии04критерии приёмки
Содержание документа
Требование должно иметь проверяемый результат
Избегайте слов «удобный» и «быстрый» без метрики или сценария проверки.
Требования
Функции, данные, роли пользователей и ограничения.
Сценарии
Действия пользователя, ответы системы и исключения.
Приёмка
Условия, по которым результат считается готовым.
Границы работ
Что входит в проект, что исключено и какие есть зависимости.
Точность формулировок
Используйте стабильные идентификаторы
Метки REQ-01 и AC-01 связывают требование, реализацию и проверку.
- Один ID — одно требование
- Сценарий содержит ошибочный путь
- Критерий можно подтвердить
Рабочий процесс
От контекста к приёмке
-
1
Определите scope
Зафиксируйте цель, роли и границы проекта.
-
2
Запишите сценарии
Опишите основной и альтернативный пути.
-
3
Добавьте критерии
Укажите измеримый ожидаемый результат.
Практика и сценарии
Как использовать «Техническое задание» в реальной работе
Этот раздел помогает перейти от общей идеи к готовому файлу: понять адресата, собрать исходные данные, выстроить разделы и проверить результат перед отправкой.
Исполнителю
Быстро подготовить основу для задачи «создание технического задания» и не пропустить обязательные сведения.
Руководителю
Проверить логику, последовательность блоков и точность формулировок по критерию «Требования пронумерованы».
Получателю
За несколько минут понять назначение документа, ключевые факты и ожидаемое следующее действие.
До первого абзаца
Соберите материалы заранее
Черновик получается точнее, когда факты отделены от формулировок. Подготовьте даты, имена, показатели, ссылки и подтверждающие материалы, которые относятся к теме «техническое задание».
- SCOPEГраницы работ: Что входит в проект, что исключено и какие есть зависимости.
- REQТребования: Функции, данные, роли пользователей и ограничения.
- FLOWСценарии: Действия пользователя, ответы системы и исключения.
- ACПриёмка: Условия, по которым результат считается готовым.
Требование должно иметь проверяемый результат
Избегайте слов «удобный» и «быстрый» без метрики или сценария проверки.
1
Понятная задача: создание технического задания.
2
Проверяемая структура: границы работ и требования.
3
Готовая версия с учётом условия «Границы обозначены».
Контент без воды
Что должен получить читатель
Сначала — контекст. Первый экран или первый абзац объясняет, что это за документ, кому он адресован и почему его нужно прочитать сейчас. Для темы «техническое задание» используйте конкретные существительные и проверяемые формулировки вместо общих обещаний.
Затем — доказательства и структура. Разделы «Границы работ», «Требования» и «Сценарии» должны идти в логичном порядке. Таблицы, списки и выделения добавляйте только там, где они ускоряют понимание, а не украшают страницу.
В конце — действие. Читателю должно быть ясно, что сделать после ознакомления: проверить данные, подтвердить решение, ответить, согласовать или сохранить документ. Перед экспортом убедитесь, что выполнены условия «Границы обозначены», «Требования пронумерованы», «Ограничения видимы».
-
01
Определите scope
Зафиксируйте цель, роли и границы проекта.
-
02
Запишите сценарии
Опишите основной и альтернативный пути.
-
03
Добавьте критерии
Укажите измеримый ожидаемый результат.
Практическое применение
Когда пригодится техническое задание
Страница нужна заказчикам, аналитикам и исполнителям, которым важно одинаково понимать границы и критерии готовности результата.
-
01
Запускается новый сайт, сервис или функция
-
02
Нужно согласовать объём работ с подрядчиком
-
03
Требуется подготовить проверяемую приёмку
Практический пример
Как превратить задачу в готовый документ
Создание технического задания. Сначала зафиксируйте управленческую задачу и адресата, затем соберите факты и критерии решения.
- 01 · Границы работ
- Что входит в проект, что исключено и какие есть зависимости.
- 02 · Требования
- Функции, данные, роли пользователей и ограничения.
- 03 · Сценарии
- Действия пользователя, ответы системы и исключения.
- 04 · Приёмка
- Условия, по которым результат считается готовым.
Смысловая карта
Что решить до открытия редактора
До открытия редактора согласуйте владельца документа, источник данных и решение, которое должен принять читатель.
Используйте стабильные идентификаторы. Метки REQ-01 и AC-01 связывают требование, реализацию и проверку.
SCOPE
Границы работ
Что входит в проект, что исключено и какие есть зависимости.
REQ
Требования
Функции, данные, роли пользователей и ограничения.
FLOW
Сценарии
Действия пользователя, ответы системы и исключения.
AC
Приёмка
Условия, по которым результат считается готовым.
Подробное руководство
От контекста к приёмке: подробный порядок
Рабочий документ становится полезным, когда каждый раздел ведёт к конкретному решению или проверяемому результату. Избегайте слов «удобный» и «быстрый» без метрики или сценария проверки.
Определите scope
Зафиксируйте цель, роли и границы проекта.
Запускается новый сайт, сервис или функция
Запишите сценарии
Опишите основной и альтернативный пути.
Нужно согласовать объём работ с подрядчиком
Добавьте критерии
Укажите измеримый ожидаемый результат.
Требуется подготовить проверяемую приёмку
Контрольные вопросы
- Границы обозначены?
- Требования пронумерованы?
- Ограничения видимы?
- Приёмка измерима?
Типичные ошибки
Что проверить до финального оформления
В документе «Техническое задание» эти ошибки влияют на ясность и пригодность результата сильнее, чем выбор шрифта или декоративных элементов.
-
01
Использовать слова «удобный» и «быстрый» без критерия
-
02
Не описывать исключения и границы проекта
-
03
Смешивать бизнес-цели с конкретной реализацией
По следующей задаче
Связанные документы и материалы
Выберите продолжение работы по смыслу документа, а не по совпадению отдельных слов.
Расширенная структура ТЗ
Что включить в техническое задание
Полное ТЗ связывает бизнес-цель, пользовательские сценарии и критерии приёмки. Каждый раздел должен помогать исполнителю принять решение или проверяющему подтвердить результат.
-
01
Контекст и цель
Опишите исходную ситуацию, проблему и измеримый результат проекта. Отдельно укажите, какие показатели не входят в цель.
-
02
Границы работ
Перечислите функции, интеграции и материалы внутри проекта. Рядом зафиксируйте исключения, чтобы они не превратились в скрытые ожидания.
-
03
Роли и сценарии
Назовите пользователей, их права и последовательность действий. Для критичных сценариев добавьте альтернативный путь и обработку ошибки.
-
04
Требования
Присвойте каждому требованию стабильный идентификатор: REQ-01, REQ-02. Не объединяйте несколько независимых функций в один пункт.
-
05
Данные и интеграции
Укажите источники, форматы, обязательные поля, правила проверки, частоту обновления и поведение при недоступности внешней системы.
-
06
Приёмка и ограничения
Свяжите каждый критерий AC с конкретным REQ. Добавьте ограничения по срокам, производительности, безопасности и совместимости.
Классификация
Разделяйте требования по назначению
Функциональные требования объясняют, что делает система. Нефункциональные задают качество, ограничения и условия эксплуатации. Бизнес-правила определяют, почему система принимает конкретное решение.
| Тип | На какой вопрос отвечает | Пример | Как проверить |
|---|---|---|---|
| Функциональное | Что должен сделать продукт? | Пользователь может восстановить черновик. | Пройти основной и ошибочный сценарии. |
| Нефункциональное | С каким уровнем качества? | Страница открывается не дольше двух секунд. | Измерить при заданных условиях и нагрузке. |
| Бизнес-правило | По какому условию принимается решение? | Скидка применяется только к активному тарифу. | Проверить набор граничных значений. |
| Ограничение | Что нельзя изменить в рамках проекта? | Авторизация остаётся в существующем сервисе. | Сверить архитектуру и границы поставки. |
Язык требований
Заменяйте оценочные слова наблюдаемым результатом
Формулировка должна одинаково пониматься заказчиком, исполнителем и тестировщиком. Условия проверки лучше записывать одновременно с требованием.
«Сделать удобную и быструю форму регистрации».
Неясно, что означает «удобная», какие действия измеряются и при каких условиях оценивается скорость.
«Новый пользователь создаёт аккаунт за один экран, заполняя не более четырёх обязательных полей; ответ сервера отображается в течение двух секунд для 95% запросов».
Названы роль, действие, ограничение, метрика и условие, которое можно подтвердить тестом.
- Одна мысльОдин идентификатор описывает одно проверяемое поведение.
- Конкретный субъектПонятно, кто выполняет действие: пользователь, администратор или система.
- Условие и результатУказано, что запускает сценарий и какой итог должен увидеть участник.
- Границы измеренияДля скорости, объёма и точности указаны числа и среда проверки.
Матрица приёмки
Свяжите требование с доказательством выполнения
Матрица трассировки помогает увидеть требования без сценария проверки и тесты, которые не подтверждают ни одной заявленной функции.
IDТребованиеКритерийСтатус
REQ-01Автосохранение черновикаAC-01 · восстановление после перезагрузкиСогласовано
REQ-02Экспорт готового документаAC-02 · PDF открывается без ошибокНа проверке
REQ-03Разграничение доступаAC-03 · гость не видит закрытый файлУточнить
Управление версиями
Как согласовывать изменения после старта
Новая идея не должна незаметно менять уже утверждённые сроки и приёмку. Записывайте изменение отдельно и показывайте его влияние до включения в рабочую версию ТЗ.
-
1
Зарегистрировать запрос
Кто предложил изменение, какую проблему оно решает и какие требования затрагивает.
-
2
Оценить влияние
Изменение стоимости, срока, архитектуры, данных, рисков и критериев приёмки.
-
3
Принять решение
Одобрить, отклонить или перенести запрос. Указать ответственного и дату решения.
-
4
Обновить версию
Изменить связанные REQ и AC, добавить запись в историю и уведомить участников.
Перед передачей исполнителю
Убедитесь, что в ТЗ нет демонстрационного текста, открытых комментариев и противоречащих друг другу версий требований. Приложения перечислены, ссылки доступны, а ответственные за согласование названы.
Создать техническое задание →Контроль качества
Проверьте документ перед отправкой
- ✓Границы обозначены
- ✓Требования пронумерованы
- ✓Ограничения видимы
- ✓Приёмка измерима
FAQ
Короткие ответы перед началом
Формат, структура и подготовка готовой версии документа.
Чем требование отличается от задачи?+
Требование описывает ожидаемое поведение результата, задача — работу по его созданию.
Нужно ли описывать ошибки?+
Да, важные альтернативные и ошибочные сценарии уменьшают неоднозначность.
Как управлять изменениями?+
Фиксируйте версию документа и историю согласованных правок.
Готовый первый шаг
Создать техническое задание
Свяжите границы проекта, требования, сценарии и критерии приёмки в одной системе идентификаторов.