Вы нашли эту статью, а значит у вас появилась потребность в написании технического задания, и мы поможем вам в этом.
Если кратко, ТЗ — определяет структуру и цель вашей системы. Без него сложно представить качественную разработку программного обеспечения. Правильно составленное ТЗ поможет вам сэкономить время, бюджет и нервы.
В статье я расскажу:
В конце статьи вы сможете скачать шаблон технического задания, а перед тем, как описывать сам шаблон, давайте я попробую на примере объяснить, в чём его преимущество.
ТЗ, в котором понятно прописаны функциональные и нефункциональные требования, правила тестирования системы и условия её приемки поможет избежать двух неприятных сценариев.
Первый сценарий — это работа с недобросовестным подрядчиком, когда он делает “тяп-ляп”.
Часто недобросовестные вендоры просят за разработку системы гораздо меньше всех остальных по рынку. Когда ищите разработчика, лучше забыть правило “дороже — не значит лучше”. Как раз-таки дороже — значит лучше, но и тут есть свои огрехи.
Второй сценарий — это когда вы работаете с нормальным подрядчиком, но из-за нечетких требований в ТЗ вы с исполнителем встречаетесь с недопониманием, что в результате влияет на конечный вид системы.
Если в обоих случаях нет внятного технического задания, где не описывается процесс приёмки, правила тестирования, тогда оспорить полученный результат будет крайне сложно.
Техническое задание прилагается к договору и является основным рассудительным документом в решении спорных и конфликтных ситуаций.
Представьте, что ваше приложение — это дом. Этот дом должен стоять на крепком фундаменте. Так вот, техническое задание и есть этот фундамент для вашего программного обеспечения.
Плохо, если ТЗ прописано поверхностно или, наоборот, в нём содержится множество ненужных технических деталей и уточнений. Помните, главное правило при оформлении ТЗ — оно должно быть понятным, поэтому зачастую его пишут без использования сложных терминов.
Если без использования узко профессиональных терминов не обойтись, то их определения рекомендуется вынести в начало ТЗ. Тем не менее старайтесь максимально отказываться от их использования.
Всё ТЗ описывается “бизнесовым языком”, то есть, как должна вести себя система с точки зрения пользователя (о пользователях и их ролях расскажу позже). Такое описание упрощает компании разработчику его вычитку, а в дальнейшем и оценку, так как, вероятно именно бизнес-аналитик будет вычитывать ТЗ, а затем собирать оценку на выполнение задач у команды разработчиков.
Не бойтесь детально описывать функциональность с точки зрения пользователя, но постарайтесь избежать лишних технических деталей, которые могут негативно сказаться на разработке вашего приложения.
Например, вы указываете в ТЗ, что хотите использовать определённую базу данных для хранения информации, а также описываете логику хранения этих данных.
В процессе разработки ТЗ часто дополняется. В какой-то момент разработчики понимают, что согласованный способ хранения данных ненадежен, невозможен или неудобен — в общем, можно сделать лучше. Однако, в ТЗ уже прописаны требования к хранению данных. Составляя ТЗ вы не учли некоторые детали, и теперь, чтобы продолжить разработку, нужно согласовывать дополнительные документы с уточнениями к ТЗ. Всё это растягивает время разработки, а значит и стоимость (если вы работаете по модели Time & Material).
Перечитывать свое ТЗ — не такая плохая идея. Даже так — это замечательная идея!
Приведу пример. Автомобильной дилерской сети нужна корпоративная система, в которой будет учитываться количество принятых автомобилей с завода с разбивкой на комплектации, количество предварительных продаж, отработанных часов автомеханика, продаж, закрепленных за менеджером и др.
Вы указываете в ТЗ логику работы системы, перечитываете на корректность написанного и начинаете рассылать ТЗ потенциальным вендорам, затем выбираете вендора и принимаетесь работать с ним. В процессе разработки вы понимаете, что некоторых функций не хватает, и продолжаете добавлять требования в ТЗ.
Но что, если вы не заметили очевидных вещей, которые должны быть предусмотрены?
Например, сотрудник отметил количество проданных автомобилей, но ошибся, а редактирование пользователем не было предусмотрено, и в администраторской панели такая функция тоже отсутствует. Получается, единственный вариант — исправлять руками в базе данных.
Просто представьте, как часто вы опечатываетесь и ошибаетесь за день тяжелой работы. А если на ошибочных данных производится множество важных расчетов в системе, а ошибка не была вовремя замечена — это может стать для вас огромной проблемой.
В случае с примером, отсутствие возможности корректировать введенные данные — это существенный недостаток в системе, а виной всему — непроработанное ТЗ.
Конечно, можно вносить правки в ТЗ во время разработки. Тот же метод работы по Agile способствует этому. Однако, случается и так, что для внесения правок нужно затронуть архитектуру и переписать уже готовый функционал. Получается уже какая-то доработка системы. Время, затраченное на введение такой фичи в процессе разработки больше, чем если бы вы указали её сразу в ТЗ.
Если вы работаете по модели Time & Material (почасовая ставка), помните пословицу “Время — деньги”, а вместе с ней запомните — “Рассеянный делает одну работу дважды”.
Представьте, что на разработку приложения выделено 5 миллионов. Вы присылаете ТЗ некоторому количество разработчиков и получаете оценку в 7-8 миллионов.
Как посчитать затраты на разработку самостоятельно и не прогадать с бюджетом — это хорошая тема, но для отдельной статьи.
У вас есть 5 миллионов и точка, а система очень нужна. С проработанным ТЗ вы можете поступить следующим образом: самостоятельно, или обратившись к разработчику убрать требования к функциональности, которые не будут мешать основному назначению и целям системы. Назначение и цели системы прописываются в ТЗ. Об этом расскажу чуть позже.
В результате корректировок ТЗ изменится, не особо важная функциональность исключена. Вы получите MVP систему, урезанную по набору возможностей в сравнении с полным ТЗ, но которая будет соответствовать вашим целям.
Если продукт будет успешно выполнять свои функции, позже вы сможете обратиться за его доработкой, или доработать его самостоятельно.
Как сказал Майкл Францезе: “Делайте то, что у вас лучше всего получается, а остальное перепоручите соответствующим специалистам.”
Отличная идея! Почему бы не поступить также? У вас нет подходящего сотрудника, который сможет простым и понятным языком описать систему, при этом не упустив важных деталей? Тогда обратитесь к сторонней компании.
Практически любая аутсорсинговая компания разработчик может разработать за вас ТЗ. Конечно, в 9 из 10 случаев за это придется заплатить. Зато вы получите отличное, полное техническое задание! Более того, вы можете не обращаться к тому же подрядчику за разработкой, а начать исследования рынка и найти того вендора, который вам понравится.
В дальнейшем, если возникнут новые задачи на разработку, вы сделаете новое ТЗ по шаблону старого. Это очень удобно, не правда ли?
Обратите внимание, что мы описываем структуру ТЗ по нашему шаблону. Наше ТЗ — гибрид из стандарта по ГОСТу и собственных предпочтений. Можно сказать, что этот шаблон — тот документ, который мы видим у “идеального” заказчика. По нашему мнению, такая структура ТЗ максимально удобна для описания системы, и поверьте, технических заданий за 10 лет работы мы видели не малое количество…
Документ состоит из основных разделов:
В общих сведениях обычно фиксируются реквизиты исполнителя (разработчика ПО) и заказчика. Обратите внимание, что реквизиты исполнителя добавляются после того, как вы нашли подрядчика, с которым будете работать.
Добавьте в раздел сроки начала и окончания работ. Вообще, я бы порекомендовал вам разбить всю разработку на этапы и для каждого этапа написать свои сроки. Поделив реализацию на этапы, вы сможете наблюдать за процессом разработки, и если вдруг какой-то этап провалится по срокам, тогда у вас получится оперативно среагировать (узнать почему так случилось, что нужно сделать, чтобы нагнать сроки и следующий этап сдать вовремя).
Не забудьте добавить требования, которые не относятся к реализации проекта. Требования касаются регулирования работы двух сторон, например:
Резюмируем. Добавьте:
Помните, это то, о чём мы ранее говорили в разделе “ТЗ позволяет сокращать расходы”? Так вот, цель проекта — это основная причина, почему вам нужно разработать приложение, и примерно, что оно будет из себя представлять.
Пример содержимого цели. Наша компания занимается логистикой и сейчас мы пользуемся коробочным продуктом, который раньше нас устраивал. После того, как предприятие начало расти, коробочный продукт не смог автоматизировать новые бизнес-процессы. Доработка не подходит, так как она слишком дорогая. Вдобавок, если мы согласимся на доработку, тогда права на продукт мы всё равно не получим.
После прочтения цели мы понимаем, зачем вам нужна кастомная разработка (в данном случае нужно автоматизировать бизнес-процессы), и, если вы укажите “прототип” того, что нравится — это упростит дальнейшую разработку.
Скорее всего, вопросы, которые последуют после такого описания: какие бизнес-процессы продукт не может разрешить, что это за продукт (если он не указан), есть ли продукты, у которых уже существует такая функциональность и тд.
Что такое назначение? Назначение заключается в том, как будет использоваться продукт.
Пример назначения. В случае с той же логистикой указывается, что продукт будет использоваться менеджерами и диспетчерами, которые курируют доставку грузов, разгрузку, загрузку на склад и на точку доставки.
Резюмируем.
В этом разделе нужно зафиксировать все нефункциональные требования. Давайте поделим раздел на следующие пункты:
В этом разделе опишите структуру (архитектуру) системы. Пишите абстрактно, не вдаваясь в детали, чтобы у исполнителя просто сложилось впечатление, что это за система, из чего она состоит, как модули связаны друг с другом.
Для разработчика важен этот подраздел, потому что такое описание открывает общий вид на систему и её компоненты. Это позволяет лучше оценить фронт предстоящих работ.
Ранее мы уже разобрали, что такое назначение. Давайте разберём это простыми словами на примере.
Пример назначения. Использование приложения людьми, которые хотят найти вторую половинку или друга, а может просто пообщаться и поиграть на досуге
Пример цели. Вы хотите создать приложение для знакомств, в котором объединить функции классического приложения знакомств с мини-играми и матчмейкингом. Т.е. пользователи смогут знакомиться с другими людьми во время игр.
Цель добавили просто для того, чтобы вы точно не перепутали эти определения. На неё можно не обращать внимание.
Чтобы достичь нашего назначения нам нужно:
Готово! Теперь представьте, чтобы найти пару в любом нормальном приложении для знакомств у вас должна быть анкета, которая будет участвовать в поиске партнёра, матчах, подборе игр и в переписке.
Выполнив 1 пункт, мы можем создать анкету. Чтобы найти другого человека, а в дальнейшем играть и общаться с ним, нужно выполнить 2 пункт.
Последующая логика такая же. Каждый выполненный пункт — показатель того, насколько система соответствует назначению. Если система соответствует назначению — значит всё работает как надо.
В этом разделе можно встретить следующие формулировки:
В общем, здесь рекомендую прописать, какие экстренные аварийные ситуации могут произойти и как система должна отреагировать.
Показатели надёжности и системные требования могут вас запутать. Давайте раз и навсегда разделим эти определения!
К показателям надёжности относится всё, что касается функционирования самого приложения в аварийных, нежелательных ситуациях, а к системным требованиям относится всё, что касается характеристик и способа обслуживания сервера или ПК, на котором будет установлено ваше ПО.
Системные требования охватывают вопросы:
Замудренная формулировка, не правда ли? На самом деле здесь всё просто.
Этот раздел посвящен UX интерфейсу, т.е. как человек должен взаимодействовать с нашим ПО: какие кнопки, поля, ссылки, таблицы будут находиться на странице приложения, и, как они будут работать при взаимодействии пользователя с этими элементами.
На примере страницы регистрации, описание UX выглядит примерно так...
Для начала напишем какие элементы находятся на этой странице.
На странице регистрации будет три обязательных поля и чекбокс, а также две кнопки.
Теперь опишем расположение этих элементов...
Все эти поля и кнопки будут появляться в модальном окне. Поля расположены друг под другом (первым идет поле для ввода логина и тд). Чекбокс находится под полем ввода пароля. Кнопка зарегистрироваться центрирована в модальном окне по горизонтали, но находится ниже всех полей и чекбокса. Кнопка вернуться на главную находится в левом верхнем углу модального окна.
В дальнейшем UX описание понадобится дизайнеру для создании макета, а разработчикам для вёрстки.
В разделе указываете способы транспортировки оборудования.
Пример. Нужно разработать ПО для передвижных метеостанций. Тогда в разделе описываем, как метеостанции нужно перевозить, что их нельзя ронять, они должны быть упакованы в специальные чехлы, при какой температуре разрешены перевозки и так далее.
Этот раздел относится к серверам. Часто здесь дают ответы на следующие вопросы:
Этот раздел будет важен для вас, если вы планируете размещать программное обеспечение на ваших серверах или ПК (допустим это десктоп приложение).
Судя по нашему опыту работы с банками, (а работаем мы преимущественно с фин. организациями) именно они уделяют особое внимание этому разделу. Они наиболее детально описывают:
Такие требования обусловлены внутренними регламентами и требованиями к безопасности.
Представьте, что сервера, где хранилось ваше приложение — сгорели, при обновлении по неосторожности удалили базу данных или другие неполадки, из-за которых вы потеряете информацию. Как быть тогда? В большинстве случаев это будет катастрофа.
Чтобы такого не произошло пропишите сюда, куда при аварийных ситуациях сохранять информацию, когда и при каких ситуациях следует делать бэкапы. Бэкапы — это откат информации и состояния приложения до последнего стабильного.
Раздел касается серверов. Вы указываете, какими характеристиками должны обладать сервера, чтобы противостоять внешнему воздействию Внешнее воздействие — это процесс, явление или фактор природного или техногенного происхождения.
Например, чем должен обладать сервер, чтобы защититься от температурных влияний, влаги, механических повреждений и тд.
Пример. Чтобы защитить сервер от механических повреждений нужен прочный корпус. Чтобы защитить сервер от переохлаждения или перегрева нужен дополнительный контроль температуры с подогревом и охлаждением. Водонепроницаемый корпус нужен, чтобы защитить сервер от влаги и тд
Этот раздел носит юридический характер. Давайте кратко и для общего познания обговорим, что это такое.
Патентная чистота — это исключительные права на ваше приложение, которые еще называются “интеллектуальной собственностью”.
В зависимости от законодательства страны правила о патентном праве могут различаться.
Если вы собираетесь продвигать приложения в разных странах, вам нужно убедиться, что приложение (что касается его целей и назначения, а также использования технологий для его разработки) не противоречит этим правилам.
В случае отсутствия нарушений, вы в полном праве использовать приложение сколько угодно, без нарушения чужих прав (а значит сможете продавать его и тд)
Пример. У вас появилась идея сделать веб приложение, связанное с криптовалютой. По сути, это веб платформа, на которой владельцы биткоинов могут сдавать их в аренду, а банки арендовать. В дальнейшем банки могут обращаться с криптовалютой, как с активом. Ваше веб приложение разработали в РФ, и здесь вы можете оформить патентную чистоту.
В результате продукт выстрелил... Отличный старт! Пора расти. Больше всего популярна криптовалюта за рубежом, поэтому будем продвигать своё приложение на иностранном рынке. Здесь то мы и встречаемся с проблемой.
Оказалось, что в этих странах уже запатентована система сдачи биткоинов в аренду. Вы никак не сможете иметь на приложение исключительные права, и в лучшем случае вам придётся платить процент за использование запатентованной идеи.
Именно юристы составляют требования для оформления патентной чистоты приложения. Если у вас Наполеоновские планы, не забудьте “потыкать” юриста, чтобы он добавил всю необходимую информацию в этот раздел.
Если в процессе работы для вас очень важно соблюдать ГОСТ или другие стандарты, тогда зафиксируйте их в этом разделе.
Приведу пару возможных формулировок:
В разделе фиксируется всё, что не касается предыдущих и следующих разделов.
Часто сюда прописывают следующие пункты:
Мы всё ближе к функциональным требованиям! Потерпите ещё чуть-чуть.
В этот раздел заполните общую информацию о том, какие возможности в системе должны быть, но без подробностей.
Пример. В приложении должна быть система регистрации и авторизации, оформление и оплата заказов, функция добавления товаров в корзину, каталог товаров, управление списком товаров и тд.
Сюда же можете записать временные регламенты — когда должна отрабатывать какая-нибудь функция.
Пример. Ваше приложение — маркетплейс. Вам нужно, чтобы с 04:00 до 05:00 утра по МСК обновлялась цена по нижнему уровню стоимости каждого товара, взятая из других маркетплейсов.
Если ваше приложение выполняет множество расчетов, то для каждой функции пропишите алгоритм вычислений.
Если у вас есть пожелание к тому, как должна выглядеть информация в интерфейсе, тогда зафиксируйте логику вывода информации в этот раздел.
Пример. Вам нужно, чтобы расчитанная системой цифра округлялась в большую сторону и конвертировалась сразу во все курсы валют.
Совместный для заполнения исполнителем и заказчиком раздел. В нём фигурируют пункты:
Математическое обеспечение системы — это математические модели и алгоритмы, которые исполнитель будет использовать. Здесь могут быть ранее не прописанные вами алгоритмы вычислений, к которым пришёл исполнитель в процессе изучения ТЗ. Это достаточно важный пункт, так как на основе прописанных здесь моделей будут производиться вычисления в системе.
Информационное обеспечение — это то, как информация передается внутри приложения: как работают компоненты между собой, как и в каком виде сохраняется информация внутри приложения, а также, как компоненты связаны с внешними сервисами.
Перечислю всё, что должен написать исполнитель:
Лингвистическое обеспечение — это перечень всех технологий, которые будут использоваться: языки программирования (C#, TypeScript), базы данных (mongoDB, SQL Lite), библиотеки (React, Angular)
Программное обеспечение системы — здесь перечисляются те программы, которые нужны для работы продукта.
Например, для сайтов можно указать перечень браузеров, а для десктопных приложений — операционные системы.
Вот ещё один пример. Вам нужно шифровать данные, тогда укажите ПО, с помощью которого нужно это делать (например, Валидата).
Техническое обеспечение — это требования к серверу или ПК, на котором будет работать ПО
Например, технические характеристики серверов, если это веб-приложение, или технические характеристики компьютера, на котором будет работать десктопное приложение.
Требования к метрологическому обеспечению — пункт, касающийся аппаратной разработки. Здесь указываются те приборы, которыми можем проверить корректность работы ПО.
Пример. Вы автоматизировали шиномонтаж. Когда клиент подъезжает на автомобиле для замены резины, система сама определяет и накачивает шину до нужного атмосферного давления. Проверить корректность работы системы мы можем с помощью манометра, его и нужно указать в разделе.
Организационное обеспечение — пункт, в котором вы указываете, кто будет пользоваться приложением и какие права доступа будут у этих пользователей.
Пример. Для вашего отеля разработано мобильное приложение, с помощью которого посетители отеля могут заказывать еду в номер, планировать время уборки номера, наблюдать за растущим счётом за пребывание в отеле и др. Тогда посетитель отеля — пользователь, а персонал — администраторы и модераторы с разными правами доступа.
Для каждой группы пользователей нужно разбить роли и права доступа. Условно, если даже у уборщика и менеджера роль называется “администратор”, то админские права могут отличаться. Уборщик не может забронировать номер для клиента, а менеджер не может отметить, что в номере завершили уборку.
Методическое обеспечение — сюда входит техническая и пользовательская документация. По необходимости может быть создан документ “пользовательские сценарии”.
Техническая документация — это инструкция для разработчиков. В ней содержатся любые технические детали: описание API, комментирование кода, описание архитектуры.
Пользовательская документация (руководство пользователя) — это документ, в котором описано как пользователю начать работать с системой, и какие возможности приложения он может использовать.
Пользовательские сценарии — это описание действий пользователя. Т.е. описывается порядок действий пользователя.
Пример пользовательского сценария. Пользователь зашёл на сайт. На экране появляется модальное окно для входа или регистрации. По умолчанию пользователь в модальном окне видит вкладку с авторизацией Чтобы начать работу в системе, пользователю нужно войти или зарегистрироваться. В зависимости есть у него аккаунт или нет, он выбирает нужную вкладку и вводит свой Email и Пароль.).
Пользовательские сценарии, в отличие от пользовательской документации, нужны не для пользователя, а для разработчика.
Требования к численности и квалификации персонала. В разделе прописываются минимальные требования к умениям пользователя для работы в системе. Например:
Если у вас предусмотрен регламент работы пользователей в системе, то зафиксируйте его здесь.
Пример. У вас банковское приложение и вам необходимо, чтобы перед выходом из системы сотрудник загрузил отчёт. Сотрудник по окончанию рабочего дня пытается выйти из системы, но получает оповещение о том, что выход из системы невозможен без загрузки ежедневного отчёта.
В этом разделе описываются все функции системы. Уделите разделу особое внимание. Не забудьте перечитать его в своём ТЗ несколько раз.
Когда перечитываете, постарайтесь представить, что вы пользователь и пытаетесь воспользоваться одной из функций. С таким подходом, вы сможете заметить и убрать недостатки в описании.
Вспомните то, о чём я писал в начале статьи: часто функциональные требования пишутся языком бизнес-аналитиков, то есть в формате “на странице авторизации мы видим форму, состоящую из двух полей, введите в поле Логин, значения формата…. , если введете неправильно — должна появляться ошибка” и так далее.
Я бы предложил описывать систему, используя один из двух вариантов:
Описание функционала постранично. Если вам нужно разработать веб-приложение, тогда составьте список страниц и опишите их содержание с точки зрения пользователя: что должно там находиться и как работать. Например, что может делать пользователь в своём личном кабинете (страница личного кабинета).
Давайте приведу пример сложнее. Вы работаете в маркетинговом агентстве и планируете разработать корпоративное веб приложение для управления проектами клиентов (проверять эффективность продвижения, следить за балансом клиента, ставить и отслеживать достижение целей и тд). Опишем с вами одну страницу, где будет отображаться список проектов.
На странице со списком проектов вверху слева находится поле для ввода. В это поле вы можете ввести номер (идентификатор), который присваивается проекту или ввести его название.
Справа сверху вы можете нажать на иконку своего профиля, чтобы зайти в личный кабинет.
Правее от профиля находится кнопка, по нажатию на которую всплывает модальное окно. В модальном окне есть три кнопки:
В центре экрана находится список проектов, оформленный в виде таблицы со столбцами:
Если вы используете этот вариант, то не забудьте добавить общее описание системы. Обычно это то, что не содержится на самой странице, например:
Логическое разделение функций. Будьте осторожны с этим способом. Если у вас ещё мало опыта, то лучше описывайте требования к функционалу постранично. Самое главное в этом способе точно определить, какую цель выполняет данная функция.
Пример разделения функций. Функция регистрации выполняет цель добавления пользователя в систему.
Функция входа позволяет пользователю получить определенную роль и работать в системе. Функция загрузки отчёта…. Правильно, загружает отчёт в систему. Функция корзины — сохраняет за пользователем определенные объекты, которые он выбрал.
Пример состоит из 4х функций, которые не связаны друг с другом. Т.е. мы их логически разделили. После этого можно приступить к описанию работы каждой функции Таким образом, вы не запутаетесь и сможете детально описать, как всё должно работать и какие возможности должна предоставлять эта функция пользователю.
Оформляйте этот раздел как вам удобно. Главное, чтобы это было понятно вам и тому, кому направите ТЗ. Мне было бы удобно составлять требования следующим образом:
В этом разделе мы описываем:
Резюмируем. В этом разделе фиксируем все организационные моменты, которые касаются управления разработкой проекта.
Здесь заказчик, либо исполнитель прописывает, как будут проходить этапы сдачи, из чего они будут состоять, что будет требоваться при сдаче каждого этапа, как определить, что все требования выполнены.
Пример. Ваш проект поделен на 4 этапа разработки. Для каждого этапа вы составляете перечень требований, которые необходимо выполнить, а затем указываете, что этап будет считаться сданным, если будет работать минимум 90% заявленных функций.
Ещё здесь можно указать документы, которые будут участвовать в приёмке. Допустим, вам по регламенту нужно составить документ программы и методики испытаний
В этом разделе указывается:
Вот вы и дочитали статью до конца. Я очень надеюсь, что статья поможет вам в написании ТЗ. Как и обещал, шаблон ТЗ вы можете скачать, нажав СЮДА. Желаю вам удачи в написании крепких ТЗ и в поиске подходящего вендора!
Все
Технологии
Ликбез
Места
HowTo
Стартапы
Новости
Сервисы
Приложения
