Что такое техническое задание на разработку программного обеспечения
Техническое задание на разработку ПО фиксирует, какой результат ожидается от создания или доработки системы. В нём описывают назначение и границы работы, требования к функциям, ограничения и способ проверки результата. Состав документа зависит от проекта: ТЗ для небольшого изменения корпоративного приложения и ТЗ для сложной автоматизированной системы не обязаны выглядеть одинаково.
Ценность технического задания определяется не количеством страниц. Документ полезен, когда заказчик, аналитик и разработчик одинаково понимают, что входит в работу, как должна вести себя система и по каким признакам результат можно принять. Подробный, но неоднозначный текст решает эту задачу хуже, чем компактное описание с ясными сценариями, правилами и критериями.
Для чего ТЗ нужно заказчику, аналитику и разработчику
Заказчику ТЗ помогает проверить, соответствует ли предлагаемое решение исходной потребности. Аналитику — связать цели, пользовательские сценарии и ограничения в непротиворечивую модель. Разработчику — понять ожидаемое поведение системы и не принимать за участников проекта решения, которые не были обсуждены.
ТЗ помогает зафиксировать общее понимание ожидаемого результата для обсуждения, реализации и приёмки. Это не означает, что документ останется неизменным при любых обстоятельствах. Если потребность или решение меняются, важно определить затронутые требования, согласовать изменения и сохранить новую версию документа. Подробнее этот процесс разобран в материале об управлении требованиями.
Почему общей формулировки недостаточно для разработки
Представим исходную постановку:
Нужно добавить возможность создавать задачи.
Фраза передаёт потребность, но ещё не описывает результат разработки. Неясно, кто может создавать задачу, какие данные вводятся и что из них обязательно. Не определено, можно ли оставить задачу без исполнителя, какие значения доступны для срока и приоритета, что происходит после сохранения и где пользователь увидит созданную задачу.
Не меньше вопросов возникает вокруг состояний и ограничений. Что показать при незаполненном названии? Кто может изменить исполнителя? Можно ли редактировать завершённую задачу? Должна ли система фиксировать дату завершения? Какие действия доступны пользователям с разными ролями?
Какие вопросы остаются у разработчика
Если эти решения не зафиксированы, разработчику придётся уточнять их во время реализации либо выбирать поведение самостоятельно. В результате технически работающая функция может отличаться от того, что ожидал заказчик. Приёмка тоже становится субъективной: исходная фраза не позволяет однозначно проверить, выполнена ли задача.
Проблему не решает механическое увеличение объёма. Даже длинное описание остаётся неоднозначным, если в нём нет роли, условий, наблюдаемого результата и значимых исключений. Задача анализа — не написать как можно больше текста, а превратить потребность в проверяемые требования. По каждому такому требованию должно быть понятно, что реализовать и как убедиться, что результат ему соответствует.
Что должно входить в техническое задание на разработку ПО
Единой практической структуры, подходящей без изменений любому программному проекту, нет. Однако при подготовке ТЗ полезно проверить, достаточно ли в нём сведений о самом решении и отдельно — об управлении документом.
Содержание решения
- Цель и границы. Какую проблему решает разработка, какой результат ожидается, что входит и не входит в работу. Границы защищают документ от незаметного расширения и помогают отделить текущую функцию от возможных следующих этапов.
- Роли и участники. Кто работает с системой, какие задачи выполняет и какие права ему нужны. Роль должна объяснять различия в поведении, а не просто повторять должность сотрудника.
- Пользовательские сценарии. Какая последовательность действий ведёт пользователя к результату, какие существуют альтернативные пути и исключения.
- Экраны, данные и состояния интерфейса. Какие формы и элементы нужны, какие данные вводятся или отображаются, что видит пользователь до действия, после него и при ошибке.
- Функциональные требования. Что система должна позволять сделать и какой наблюдаемый результат возникает.
- Бизнес-правила и ограничения. Какие условия влияют на доступность действий, расчёты, переходы и изменение данных.
- Ошибки и исключения. Как система реагирует на некорректные данные, недоступность связанного сервиса или действие, запрещённое текущим состоянием.
- Критерии приёмки. Какие проверки подтверждают, что требование реализовано.
- Нефункциональные требования. Какие качественные свойства и эксплуатационные ограничения существенны для конкретной системы.
Подробнее определить результат и ограничения помогает материал о цели и границах проекта.
Не забудьте о нефункциональных требованиях
Описание экранов и функций не отвечает на все вопросы о качестве системы. В зависимости от проекта могут потребоваться требования к производительности и нагрузке, безопасности и разграничению доступа, совместимости и поддерживаемым платформам, доступности и отказоустойчивости, интеграциям и обмену данными, журналированию и аудиту, резервному копированию и восстановлению, эксплуатации и сопровождению.
Это чек-лист для анализа, а не исчерпывающая классификация. Состав определяется назначением системы, средой использования, рисками и обязательствами проекта. Такие требования нельзя получить только из прототипа интерфейса: их необходимо выявить и сформулировать отдельно. Формулируйте качественные требования так, чтобы было понятно условие и способ проверки; где это уместно, задавайте измеримый порог.
Нужно ли составлять ТЗ по ГОСТ
Выбор структуры зависит от объекта разработки, договора, требований организации, отрасли и применимых нормативных документов. ГОСТ 19.201-78 устанавливает требования к техническому заданию на программу или программное изделие. ГОСТ 34.602-2020 относится к техническому заданию на создание, развитие или модернизацию автоматизированной системы.
Не стоит автоматически выбирать один из этих стандартов как универсальный шаблон любого программного проекта. Структура этой статьи — практическая основа для постановки задачи, разработки и приёмки. Если проект должен соответствовать конкретному стандарту, договору или внутреннему регламенту, состав и оформление документа нужно проверить по применимому источнику и дополнить необходимыми разделами.
Управление документом
Содержание решения следует отличать от сведений, которые помогают управлять ТЗ. К ним относятся связанные материалы, участники и результат согласования, номер или дата версии, а также история изменений. Эти данные не заменяют требования, но позволяют установить, какую именно редакцию обсуждали и что изменилось позднее.
Как подготовить исходные данные для технического задания
Пустой шаблон помогает не забыть разделы, но сам по себе не создаёт содержание. Начинать лучше с потребности и ожидаемого результата: что происходит сейчас, какое изменение необходимо и для кого оно важно. Затем следует определить заинтересованных участников и собрать сведения через интервью, обсуждение, наблюдение за текущей работой или анализ существующей системы.
От потребности к согласованному решению
Сначала зафиксируйте границы: какую функцию проектируют сейчас, какие смежные процессы не входят в работу и какие ограничения уже известны. Разложите потребность на пользовательский сценарий. Определите начальное условие, действия пользователя, реакцию системы и конечный результат. После этого можно описать или спроектировать экраны, данные и состояния, уточнить бизнес-правила, сформулировать User Stories и критерии приёмки.
Если решение связано с интерфейсом, его полезно проверить до фиксации окончательных требований. Прототип помогает увидеть пропущенные состояния, неоднозначные переходы и вопросы к данным. Подробнее этот процесс разобран в материале о прототипировании программного обеспечения.
Откуда брать сведения для документа
Источниками ТЗ могут быть интервью с заинтересованными сторонами, регламенты, договорные ограничения, данные действующей системы, схемы процессов, прототип, результаты согласования и применимые нормативные требования. Ни один источник не следует считать достаточным автоматически. Например, прототип показывает интерфейс и часть поведения, но не определяет сам по себе требования к нагрузке или резервному копированию.
В Prototype Story Builder функциональный контекст может накапливаться в процессе проектирования: в проекте связываются экраны, действия, требования, User Stories и критерии. Инструмент не выявляет потребности вместо аналитика. Он помогает сохранить уже проработанные сведения в контексте решения, из которого позднее формируется версия документа.
Как сделать требования в ТЗ проверяемыми
Проверяемое требование описывает результат достаточно конкретно, чтобы команда могла реализовать его, а затем подтвердить выполнение. Полезно определить роль или начальное условие, действие, необходимые данные, наблюдаемый результат и существенные ограничения.
Избегайте оценочных слов без установленного смысла: «удобно», «быстро», «понятно», «современно». Они могут выражать важную цель, но не объясняют, какое поведение требуется. Если скорость существенна, укажите операцию, условия нагрузки и допустимое время. Если важна понятность интерфейса, определите пользовательскую задачу и способ её проверки.
Плохая и улучшенная формулировка
Плохо:
Система должна позволять удобно создавать задачи.
Лучше:
Пользователь с ролью руководителя проекта может создать задачу, указав название, срок и исполнителя. Название обязательно. После сохранения задача отображается в списке задач.
Улучшенная версия ещё не описывает всю функцию, но уже отвечает на несколько вопросов: кто выполняет действие, какие данные участвуют, какое поле обязательно и какой результат наблюдает пользователь. Если исполнитель может отсутствовать или срок должен быть не раньше текущей даты, эти правила следует добавить отдельно.
Как перейти от требования к критериям приёмки
Критерии приёмки превращают формулировку в набор проверок. Для примера выше они могут описывать успешное создание задачи с заполненным названием, появление задачи в списке после сохранения и отказ в сохранении при пустом названии. Значимые альтернативы — например, создание без исполнителя — тоже фиксируются, если такое поведение согласовано.
Требование не должно без необходимости предписывать внутреннюю реализацию. Конкретная технология, структура базы или способ вызова сервиса становятся частью ТЗ, когда это реальное ограничение проекта. В остальных случаях важнее зафиксировать проверяемый результат. User Story помогает сохранить связь между потребностью пользователя и поведением системы; подробнее — в материале о том, как описать потребность пользователя и критерии приёмки.
В PSB правила и критерии можно сохранять в контексте соответствующих экранов и элементов. Это не превращает описание в исполняемый код, но помогает не отделять текст требования от той части интерфейса, к которой оно относится.
От исходной потребности к фрагменту технического задания
Рассмотрим на примере TaskForMe, как общая потребность постепенно превращается в сведения, достаточные для разработки и приёмки функции. Исходная постановка остаётся прежней:
Нужно добавить возможность создавать задачи.
Это начало анализа, а не готовое ТЗ. Чтобы получить проверяемый результат, последовательно определим границы функции, сценарий, интерфейс, поведение, правила и критерии.
Исходная потребность и границы функции
Сначала уточняем, кому и зачем нужна функция. В нашем примере руководитель проекта создаёт задачу, чтобы передать работу конкретному участнику и видеть её в общем списке. В текущие границы входят создание карточки, заполнение основных данных, сохранение и отображение новой задачи. Учёт рабочего времени, расчёт затрат и расширенный маршрут согласования можно явно оставить за пределами этого фрагмента.
Уже на этом шаге в ТЗ появляются цель, роль пользователя, ожидаемый результат и границы. Без них команда могла бы по-разному понимать слово «создание»: как простую запись с названием, подробную карточку, импорт из другой системы или часть большого процесса планирования.
Сценарий, экраны и данные
Основной сценарий можно описать так: пользователь открывает список задач, выбирает создание, заполняет карточку и сохраняет её. После успешного действия система показывает созданную задачу в списке.
Прототип карточки уточняет состав интерфейса. На форме предусмотрены название задачи, ответственный и срок. Список страниц показывает связь карточки со списком задач и отдельным экраном проверки результата. Эти сведения превращаются в описание экранов и данных будущего ТЗ.
Само изображение не определяет обязательность полей и не доказывает правила сохранения. Эти решения нужно сформулировать текстом. Например, название обязательно, а исполнитель в демонстрационном сценарии может быть не выбран. Такая граница важна: прототип показывает элементы, а требования объясняют их смысл и условия использования.
Поведение и бизнес-правила
Следующий слой — реакция системы на действия пользователя. Для кнопки «Сохранить задачу» в прототипе настроено действие по клику с переходом к странице «Список задач». Этот переход можно пройти без написания программного кода, чтобы проверить последовательность экранов до разработки.
Настроенный переход подтверждает маршрут сценария, но не означает, что прототип сохраняет производственные данные или выполняет все будущие проверки. Бизнес-правила фиксируются отдельно. Для демонстрационного фрагмента можно определить: задача не сохраняется без названия; исполнитель необязателен; после успешного сохранения задача отображается в списке. Если проект охватывает завершение задачи, отдельным правилом можно указать фиксацию даты завершения при смене статуса.
Каждое правило добавляет в ТЗ конкретное решение. Разработчику уже не нужно угадывать, можно ли сохранить пустое название, а тестировщик получает условие, которое можно проверить.
User Story и критерии приёмки
User Story связывает функцию с потребностью пользователя:
Как руководитель проекта, я хочу создать задачу и назначить исполнителя, чтобы передать работу конкретному участнику команды.
К ней добавляются критерии приёмки:
- пользователь с нужной ролью может открыть форму создания задачи;
- при заполненном названии задача сохраняется и появляется в списке;
- при пустом названии система не создаёт задачу и сообщает о необходимости заполнить поле;
- если исполнитель не выбран, задача сохраняется без назначения, если именно это правило согласовано;
- выбранный исполнитель отображается в карточке сохранённой задачи.
Критерии описывают наблюдаемый результат, а не внутренний код. Их можно использовать для обсуждения до разработки, для подготовки тестов и для приёмки готовой функции.
Сформированная версия ТЗ
После проработки исходная фраза больше не существует отдельно от решения. В проекте накоплены цель и границы, формы, сценарий, требования, User Stories и критерии. Из заполненных данных PSB можно сформировать сохранённую версию технического задания и скачать её в Markdown или Word .docx.
.md и .docx.Сохранённая версия фиксирует состояние сведений на момент формирования. Если позднее изменить проект, старый документ не переписывается автоматически: для обновлённого решения формируется новая версия.
Контраст с исходной постановкой теперь очевиден. Вместо «добавить создание задачи» разработчик знает роль пользователя, границы функции, состав данных, обязательность названия, результат сохранения, переход между экранами и критерии проверки. В материале «Техническое задание из прототипа» подробнее показано, как результаты проектирования собираются в документ.
Как согласовывать техническое задание и учитывать изменения
Согласование имеет смысл только применительно к определённой версии решения. Фразы «ТЗ согласовано» недостаточно, если участники открывают разные редакции документа или обсуждают уже изменившийся прототип. Зафиксируйте версию, дату и состав материалов, которые были переданы на проверку.
Зафиксируйте версию, которую согласовали
Комментарии лучше связывать с конкретным экраном, элементом, правилом или критерием. Тогда понятно не только содержание замечания, но и какой фрагмент решения оно затрагивает. Например, вопрос о возможности изменить исполнителя после сохранения задачи влияет на поведение карточки, права пользователя и критерии приёмки.
В PSB публичная версия прототипа может использоваться для просмотра и обратной связи в пределах предусмотренного share/review flow. Это помогает обсуждать решение в его интерфейсном контексте. Share/review flow предназначен для обсуждения и фиксации обратной связи по проекту. Договорный порядок утверждения технического задания определяется отдельно.
Что делать при изменении требований
После замечания сначала обновляют затронутые экраны, правила и критерии, затем проверяют непротиворечивость сценария. Для согласованного нового состояния формируют следующую версию ТЗ. Ранее сохранённая версия в PSB не меняется автоматически, поэтому остаётся возможность установить, какое решение было зафиксировано раньше и чем оно отличается от текущего.
История версий не отменяет необходимости объяснять изменения. Для каждой новой редакции полезно кратко указать причину, затронутые требования и статус согласования. Так версия становится не просто копией файла, а понятной точкой в развитии решения.
Как сформировать версию технического задания в Prototype Story Builder
Prototype Story Builder не придумывает содержание ТЗ вместо аналитика. Документ формируется из данных, которые команда заполнила в проекте во время анализа и проектирования. Поэтому полнота результата напрямую зависит от того, насколько подробно определены цель, границы, интерфейс, поведение и требования.
Какие данные попадают в документ
В сохранённую версию могут войти заполненные сведения проекта: назначение и границы, формы, требования, User Stories, критерии и другие предусмотренные разделы. Связь с прототипом помогает сохранять контекст: текст объясняет, к какому экрану или элементу относится решение, а не существует отдельным несвязанным списком.
Это не означает, что любой необходимый раздел появляется автоматически. Например, требования к производительности, безопасности или эксплуатации нужно сначала выявить и сформулировать с учётом конкретной системы. Перед формированием версии аналитик проверяет полноту заполненных данных и согласованность требований.
Форматы и история версий
Сформированную версию можно скачать в Markdown (.md) и Microsoft Word (.docx). Оба файла относятся к сохранённому состоянию документа. Не следует описывать процесс как автоматическое превращение краткой идеи в готовое ТЗ: PSB структурирует накопленные сведения, но не заменяет анализ.
Последующие изменения проекта не переписывают ранее сохранённую версию. После обновления экранов или требований можно сформировать новую и сохранить историю. Это позволяет отделить актуальную редакцию от той, которая обсуждалась или была зафиксирована раньше.
Частые вопросы о техническом задании на разработку ПО
Что такое техническое задание на разработку программного обеспечения?
Это документ, который фиксирует ожидаемый результат разработки или доработки: назначение и границы, требования, ограничения и способ проверки. Конкретный состав зависит от проекта, договора и применимых правил.
Кто должен составлять ТЗ — заказчик или исполнитель?
Универсального правила нет: ответственность зависит от процесса, договора и распределения ролей. Заказчик или владелец продукта предоставляет цели, потребности, ограничения и критерии ожидаемого результата. Аналитик либо исполнитель помогает выявить недостающие детали, проверить реализуемость и оформить сведения в конкретные требования. Рабочее ТЗ следует согласовать с участниками, которые отвечают за потребность, реализацию и приёмку.
Что должно входить в техническое задание на разработку ПО?
Практическая структура может включать цель и границы, роли, сценарии, экраны и данные, функциональные требования, бизнес-правила, исключения и критерии приёмки. При необходимости отдельно добавляют требования к качеству и эксплуатации. Точный состав определяется особенностями проекта.
Чем ТЗ отличается от требований, спецификации и постановки задачи?
Требование — отдельное утверждение о необходимом результате, свойстве или ограничении системы. Спецификация требований объединяет такие утверждения в структурированный набор. В контексте этой статьи техническое задание фиксирует назначение и границы разработки, требования и способ проверки результата. Постановкой задачи часто называют более компактное описание конкретной работы. На практике названия и состав документов зависят от процесса организации, поэтому важнее явно определить содержание и назначение каждого артефакта.
Нужно ли составлять ТЗ по ГОСТ?
Это зависит от объекта разработки, договора, требований организации, отрасли и применимых нормативных документов. ГОСТ 19.201-78 устанавливает требования к ТЗ на программу или программное изделие, а ГОСТ 34.602-2020 — к ТЗ на создание, развитие или модернизацию автоматизированной системы. Не следует автоматически выбирать один из них как универсальный шаблон любого программного проекта. Если соответствие определённому стандарту обязательно, структуру и оформление документа нужно проверять именно по нему.
Как сделать требования в ТЗ проверяемыми?
Укажите роль или начальное условие, действие, данные, наблюдаемый результат и существенные ограничения. Добавьте критерии приёмки для успешного сценария и важных исключений. Избегайте слов «удобно» или «быстро» без способа проверки и, где это уместно, задавайте измеримый порог.
Нужно ли добавлять в ТЗ прототип интерфейса?
Не всегда. Прототип полезен, когда нужно согласовать состав экранов, переходы, состояния и реакцию системы на действия пользователя. Он может быть связанным материалом или источником конкретных требований, но необходимость его включения зависит от проекта.
Заменяет ли прототип техническое задание?
Нет. Прототип показывает интерфейс и часть поведения системы. ТЗ фиксирует необходимый для проекта набор сведений: назначение и границы, функциональные и при необходимости нефункциональные требования, бизнес-правила, критерии приёмки и другие ограничения. Прототип может быть источником требований или дополнением к документу.
Как учитывать изменения после согласования ТЗ?
Зафиксируйте согласованную версию, обновите затронутые требования, экраны и критерии, а затем сформируйте новую редакцию. В истории изменений укажите причину и состав корректировок, чтобы участники понимали, какая версия актуальна и что было согласовано раньше.
Можно ли сформировать ТЗ в Prototype Story Builder и в каких форматах его скачать?
Из заполненных данных проекта PSB формирует сохранённую версию технического задания. Её можно скачать в Markdown (.md) и Word (.docx). Если позднее изменить проект, ранее сохранённая версия не переписывается автоматически: для обновлённого состояния можно сформировать новую.
Начните с технического задания для одной функции
Не обязательно пытаться сразу описать всю систему. Выберите одну функцию, определите её цель и границы, пройдите пользовательский сценарий и зафиксируйте требования и критерии приёмки. Создайте проект в Prototype Story Builder и постепенно соберите данные, из которых можно сформировать версию технического задания.