Написание частного технического задания (чтз) / хабр

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

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

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

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

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

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

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

Отличия между техническим заданием и заданием на проектирование

Задание на проектирование завершает стадию предпроектной подготовки и определяет общие требования заказчика к проектной документации с учетом технических правил и требований юридического характера к разрабатываемому (проектируемому) объекту. Техническое задание в отличие от задания на проектирование содержит в себе максимально полный перечень исходных данных и учитывает возможные планировочные и ресурсные ограничения.

Техническое задание – исходный документ для проектной организации. Именно на его основе формируется и оформляется задание на проектирование. Это своего рода часть этого документа с указанием потенциальных ограничений по проекту.

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

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

Особенности ТЗ

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

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

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

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

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

В целом, основная разница между ТЗ и ЧТЗ заключается в том, что ТЗ является более общим документом, который описывает требования заказчика, а ЧТЗ является более специфическим документом, описывающим требования при проведении конкретного тестирования.

Участники и процесс разработки ТЗ

Процесс разработки технического задания (ТЗ) представляет собой важную стадию в жизненном цикле проекта. Участники этого процесса включают исполнителя и постановщика задач.

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

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

Ключевая разница между ТЗ (техническим заданием) и ЧТЗ (частичное техническое задание) заключается в уровне детализации и специфичности требований. ТЗ содержит общие и технические требования, которые должны быть выполнены в проекте, в то время как ЧТЗ уточняет и детализирует эти требования в более конкретные и специфичные задачи.

Участники процесса разработки ТЗ	Роли и обязанности
Исполнитель	— Изучение требований и деталей проекта— Разработка проекта, основываясь на ТЗ— Внесение изменений и корректировок по требованию заказчика
Постановщик задач	— Формулирование требований и целей проекта— Разработка ЧТЗ на основе ТЗ— Контроль и управление процессом разработки— Оценка и согласование результатов работы исполнителя

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

Необходимость и своевременность обновления ТЗ

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

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

Обновление ТЗ также позволяет исполнителю лучше ориентироваться в проекте, увидеть новые возможности и принять во внимание изменения во внешней среде, что может повлиять на результаты проекта. Кроме того, обновление ТЗ способствует достижению высокого уровня качества проекта и улучшению коммуникации между постановщиком требований и исполнителем

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

Обязательные составляющие тех. задания на разработку

Итак, вы собрали бизнес и функциональные требования, определили кто будет формировать техническое задание

Теперь важно определить блоки, которые должны быть в ТЗ. Сразу отметим, что техническое задание может содержать неограниченное количество блоков, в этом материале мы расскажем о наборе требований к ТЗ на разработку, без которых любое ТЗ не будет полным и емким

Также важно отметить, что существует несколько регламентов, в том числе и ГОСТ, которые описывают составляющие технического задания на разработку IT-проекта.

Например:

ГОСТ 34
IEEE 29148-2011 — стандарт разработки сложных систем
Rational Unified Process — спецификация для разработки требований к IT-продуктам

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

Обязательные составляющие эффективного процесса разработки читайте в гайде: «Разработка IT-продукта».

Как составить бриф для ТЗ

Бриф, анкета с вопросами, поможет составить скелет техзадания и расширять его.

Блок 1. Описание проекта

Цель проекта — для чего затевается вся разработка, зачем заказчик хочет получить этот продукт.
Сопутствующие ссылки на документы — текущий сайт заказчика, документ с фирменными стилями в Figma или Canva.
В сложных проектах — бизнес-процессы, которые будут выполняться в разрабатываемом проекте.
Хорошо бы иметь название будущего проекта — хотя бы рабочее.
В эту часть правильно включить данные о текущем проекте заказчика. Количество аудитории, посетителей сайта, пользователей. И здесь же — отразить планы развития и масштабирования, особенно если это входит в цель разработки нового продукта.

Блок 2. Требования к проекту

Системные требования

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

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

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

Типовые сценарии использования

Описание главных сценариев — как пользователь совершает покупку, заказывает услугу.
Описание сопутствующих сценариев — как пользователь регистрируется, как входит в приложение первый раз и как входит повторно после регистрации.

Блок 3. Структура и функциональность

Структуру можно отобразить в текстовом виде, но визуализация в виде схемы эффективнее.

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

Блок 4. Сопутствующая информация

Ожидания и требования к скорости работы сайта, условия работы сайта в разных версиях браузеров, расширений и прочее, адаптивность продукта под различные устройства.
Дизайн сайта. Фирменный стиль к проекту должен был появиться ещё на этапе Блока 1, но здесь нужно оговорить внешний вид новых элементов, надписей, шрифтов, иконок, которые должны появиться в разрабатываемом продукте.
Обязанности. В ТЗ должно быть прописано, кто и за что отвечает. Иначе получится так, что заказчик ожидал авторских текстов разработчика, а разработчик этого делать и не собирался и везде поставил «Lorem ipsum».

Откуда берется информация?

В предыдущем разделе мы выяснили, какой может быть перечень разделов ЧТЗ. Поэтому и наполнение разделов, описывающих общесистемные требование, можно брать из ТЗ, либо вообще не включать в разрабатываемый документ, если иное не нужно для каждого конкретного случая.

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

Поэтому технический писатель может передать аналитику подраздел «Требования к функциям (задачам), выполняемым АС» для заполнения (если мы говорим просто структуру документа согласно ГОСТ 34.602-2020).

Что такое ЧТЗ

ЧТЗ является основным руководством для всех участников проекта: заказчиков, проектировщиков, строителей, поставщиков оборудования. Он определяет требования к функциональности объекта, его характеристикам, процессу строительства и финансирования.

ЧТЗ должно быть разработано в соответствии с принципами разумной достижимости и экономической эффективности. Он должен быть четким, конкретным и понятным для всех участников проекта. ЧТЗ должно содержать информацию о технических параметрах объекта, требованиях к конструкции, качеству материалов, срокам строительства и затратам на проект.

ЧТЗ служит основой для оценки работ и контроля за выполнением проекта. Он позволяет участникам проекта иметь общее представление о полном объеме работ и их последовательности.

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

Определение и функции ЧТЗ

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

ЧТЗ имеет несколько функций:

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

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

Как используется ЧТЗ

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

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

Введение: описание цели проекта, его задач и ожидаемых результатов.
Общие требования: указание на платформы, операционные системы, браузеры и другие технические требования.
Функциональные требования: описание основных функций и возможностей проекта.
Дизайн и пользовательский интерфейс: описание внешнего вида проекта и требований к его удобству использования.
Безопасность: указание на методы и требования по обеспечению безопасности проекта.
Производительность: описание требований к скорости работы и оптимизации проекта.
Тестирование: указание на требования к тестированию проекта и проверке его работоспособности.
План работ: описание этапов и сроков выполнения проекта.
Обратная связь: указание на механизмы связи между заказчиком и исполнителем, а также на процедуры изменения ЧТЗ.

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

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

Как определить и описать основные цели ЧТЗ

Цель проекта

В начале процесса разработки ЧТЗ необходимо четко определить основную цель проекта. Цель проекта — это основное назначение и ожидаемый результат от его выполнения. Она должна быть ясной, конкретной и измеримой.

Описание цели

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

Формулировка целей

Цели ЧТЗ должны быть измеримыми и достижимыми. Они должны быть сформулированы таким образом, чтобы их можно было измерять и оценивать по достижению или недостижению. Формулировка цели должна быть специфической, избегайте использования общих фраз. Определите конкретные числовые или качественные показатели для измерения достижения цели.

Примеры целей проекта:

Увеличение продаж продукта на 20% в течение следующего квартала.
Сокращение времени отклика на обращения клиентов до 24 часов.
Улучшение пользовательского опыта интерфейса продукта путем увеличения скорости загрузки страниц до 2 секунд.

Основные цели проекта

В ЧТЗ также следует указать основные цели проекта. Основные цели являются конкретными задачами или результатами, которые должны быть достигнуты в рамках проекта. Определите основные цели, которые наиболее важны для достижения общей цели проекта.

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

Как обеспечить качество поставок?

В правоотношениях по контрактной системе под качественным товаром понимается товар, соответствующий договору. Общие требования к качеству товаров работ и услуг (ТРУ) прописаны в ст. 469, 721 ГК РФ:

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

Рассмотрим некоторые нюансы.

Пригодность для конкретных целей.

Если вы покупаете бумагу для принтера или стакан, то в ТЗ не обязательно указывать, что на бумаге можно писать, что стакан применим, чтобы пить из него: в ГК РФ и так сказано, что поставляемый товар должен соответствовать целям, для которых он обычно предназначен. Однако бывают ситуации, когда товар закупается для специальных целей: например, не просто мебель, а мебель для школьников младших классов. И если есть такие специальные цели совершения закупки, в техзадании их обязательно прописывают.

Обратите внимание на то, что техническое задание в рамках Закона о контрактной системе должно соответствовать, с одной стороны, потребностям инициатора закупки, с другой – требованиям множества нормативных актов

* Федеральный закон от 26.07.2006 № 135-ФЗ «О защите конкуренции».

** Постановление Правительства РФ от 08.02.2017 № 145 «Об утверждении Правил формирования и ведения в единой информационной системе в сфере закупок каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд и Правил использования каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд».

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

Поскольку нормативных требований достаточно много, они иногда не состыкуются между собой. Не всегда очевидно, как, например, поступить в ситуации, если каталог продукции устанавливает одни требования, ГОСТ – другие, а какой-то акт нормирования у заказчика – третьи.

Возникли сомнения – изучите подход контролирующих органов (регионального УФАС, центрального аппарата), посмотрите судебную практику.

Техническое задание (ТЗ)

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

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

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

Ключевые компоненты технического задания: ТЗ должно включать в себя всю необходимую информацию для реализации проекта. В нем могут быть представлены следующие компоненты:
1. Общая информация о проекте: в этом разделе описывается фоновая информация, цели и ожидаемые результаты проекта.
2. Описание функциональности: здесь приведено детальное описание основных функций продукта или услуги.
3. Требования к проектированию и разработке: этот раздел содержит информацию о необходимых технических требованиях, разработке программного обеспечения и других компонентах проекта.
4. Требования к интерфейсу и дизайну: здесь указывается информация о внешнем виде и интерфейсе продукта или услуги.
5. Требования к тестированию и контролю качества: этот раздел включает информацию о стратегии тестирования и контроля качества продукта или услуги.
6. Требования к срокам выполнения и бюджету: в данном разделе указывается информация о сроках выполнения проекта и ограничениях бюджета.
Правильно структурированное и понятное ТЗ помогает участникам проекта лучше понять задачи и достичь наиболее эффективного результата.
Преимущества использования ТЗ: Четко сформулированное техническое задание помогает участникам проекта избежать недоразумений и конфликтов, определить конкретные цели и задачи, а также проследить и контролировать процесс выполнения проекта. Оно также позволяет подтвердить соответствие результата требованиям клиента и определить успешность работы.

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

Следующий шаг — список конкурентов

После проверки вы получите разноцветные URL-сайтов под каждым из запросов кластера.

Если есть фразы, у которых URL не окрашены, то они не подходят к кластеру.

Цветные URL адреса в этом сервисе — это адреса ваших конкурентов. Первым делом вам нужно отсеять из них агрегаторы. Далее берем хотя бы тех, кто чаще других занимает первые три позиции. В идеале нужно анализировать всех оставшихся.

Как еще использовать список конкурентов

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

Не хотите в этом разбираться? Проанализируем страницы, соберем конкурентов и составим все ТЗ за вас в рамках ROI-маркетинга.

Как это сделать?

Оцените, что за страница в выдаче: это главная или страница каталога? Каких страниц в выдаче больше?
Проанализируйте, какие элементы находятся на этой странице и как они располагаются? Есть ли характеристики товара или услуги? Фильтр? Указана ли цена?

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

Конкурировать с каталогом вы просто не сможете.

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

Но эта статья про seo-текст, так что возвращаемся к текстовому анализу.