Что относится к функциональным требованиям
Понятие требования. Классификации требований
Системные требования и требования к программному обеспечению
Существуют различные трактовки понятия «Системные требования» ( system requirements ).
INCOSE (International Council on Systems Engineering ) дает более детальное определение системы: «комбинация взаимодействующих элементов, созданная для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы». Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99 [2.8]: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.
Функциональные, нефункциональные требования и характеристики продукта
Функциональные требования регламентируют функционирование или поведение системы (behavioral requirements). Функциональные требования отвечают на вопрос «что должна делать система» в тех или иных ситуациях. Функциональные требования определяют основной «фронт работ» Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.
Нефункциональные требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс [2.2] выделяет следующие основные группы нефункциональных требований:
Среди внешних интерфейсов в большинстве современных АИС наиболее важным является интерфейс пользователя (User Interface, UI). Кроме того, выделяются интерфейсы с внешними устройствами (аппаратные интерфейсы), программные интерфейсы и интерфейсы передачи информации (коммуникационные интерфейсы).
Основные атрибуты качества:
достаточно хорошо раскрыты в модели FURPS (см. ниже).
Существует и более общий взгляд на данное понятие [2.9]: «features могут быть как относящимися к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта».
С.Орлик в [2.6] отмечает, что «с точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными».
Роль характеристик проявляется в первую очередь в области маркетинга: не всякий потенциальный потребитель продукта станет читать его функциональные описания, а набор ключевых характеристик, характеризующих конкурентные преимущества, можно сделать лаконичным и уместить на одной странице рекламной листовки, либо напечатать на компакт-диске.
Классификация RUP
В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [2.1].
Акроним FURPS обозначает следующие категории требований:
Символ «+» расширяет FURPS-модель, добавляя к ней:
часть из которых уже была рассмотрена выше.
Кроме того, в спецификациях RUP выделяются такие категории требований, как
FURPS (Functionality Usability Reliability Performance Supportability: функциональность, удобство использования, надежность, производительность, удобство сопровождения)— классификация требований к программным системам, разработанная в Hewlett-Packard. Согласно классификации, все требования подразделяются на 5 категорий, непосредственно следующих из составляющих наименования классификации. В настоящее время используется, как составная часть более общей классификации FURPS+.
FURPS+ (Functionality Usability Reliability Performance Supportability +: функциональность, удобство использования, надежность, производительность, удобство сопровождения, дополнительные требования) — расширенная версия классификации требований FURPS. Дополнительно включает в себя ограничения, разделенные на следующие группы требований:
Подробно описана в работе Роберта Грейди.
Методологии и стандарты, регламентирующие работу с требованиями
Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие.
Документирование требований
Документирование требований в соответствии с ГОСТ РФ
Второй документ, по сути, является более проработанной версией первого, адаптированной к созданию автоматизированных информационных систем, поэтому далее рассмотрена структура ТЗ в соответствии с ГОСТ 34.602-89.
Структура ТЗ в соответствии с ГОСТ 34.602-89
В задачи лекции не входит перечисление всех правил и рекомендаций данного ГОСТ, желающие могут ознакомиться с ним непосредственно. Ниже будут перечислены разделы, предусмотренные ГОСТ и рассмотрены основные моменты, на которые следует обратить внимание.
Раздел «Состав и содержание работ по созданию системы», говоря современным языком, описывает процесс создания системы, включая выбор методологии, определяющий содержание стадий, этапов и фаз и его конкретизацию для проекта (количество этапов и итераций, их основное содержание).
Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие, опять же, аппелируя к современной терминологии, оговаривают порядок проведения реинжиниринга предприятия, который необходимо осуществить для того, чтобы добиться от внедрения АИС должного эффекта (подбор и обучение персонала, изменения в организационной структуре и т.п.).
Документ заканчивается разделами «требования к документированию» и «источники разработки», определяющими, соответственно, перечень и формы документации, подлежащей разработке и перечень уже имеющихся документов, содержащих предпосылки для разработки.
В качестве приложений ГОСТ рекомендует использовать расчет ожидаемой эффективности системы и оценку научно-технического уровня системы.
Описание требований к системе в соответствии с ГОСТ 34.602-89
ГОСТ разделяет все требования к системе на три класса:
Среди требований к системе в целом (системные требования) указываются требования к:
а также показатели назначения (параметры, характеризующие степень соответствия системы ее назначению) и дополнительные требования (распространяются на обучающие подсистемы, средства контроля работоспособности системы и др.).
Требования ГОСТ к функциям (задачам), в переводе на современный язык, подразделяются на:
Требования к видам обеспечения. Среди видов обеспечения ГОСТ указывает математическое, информационное, лингвистическое, программное, техническое, метрологическое, организационное, методическое.
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в Retail Rocket мы остановились на этом варианте и пока не жалеем.
Функциональные требования: что это такое и зачем они нужны
Для начала давайте разберемся, что такое функциональные требования.
Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.
Функциональные требования, как правило, состоят из:
User story
User story описывает, что делает пользователь определенной роли для достижения результата, и что нужно сделать разработчику, чтобы воплотить эту задачу в жизнь.
Как правило используется шаблон:
Существуют различные примеры применения этой методологии. Например, так это работает в Trello:
В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.
Например, так выглядит задача об отслеживании NPS для интернет-магазина:
Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.
Use cases
Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.
Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.
Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.
Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.
Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.
Примеры use case’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
Функциональные и нефункциональные требования: полное руководство
Точно знать, какие функции и возможности клиент хочет от приложения, довольно сложно для команды разработчиков программного обеспечения. Во избежание недоразумений заказчику и команде разработчиков программного обеспечения необходимо определить требования к проекту: как функциональные, так и нефункциональные требования для будущего приложения. В этой статье мы объясним разницу между двумя типами требований и поделимся лучшими практиками их сбора.
Что такое функциональные требования?
При разработке программного обеспечения функциональные требования определяют функции, которые должно выполнять все приложение или только один из его компонентов. Функция состоит из трех шагов: ввод данных — поведение системы — вывод данных. Он может вычислять, манипулировать данными, выполнять бизнес-процессы, устанавливать взаимодействие с пользователем или выполнять любые другие задачи.
Другими словами, функциональное требование — это то, ЧТО приложение должно или не должно делать после ввода некоторых данных.
Функциональные требования важны, поскольку они показывают разработчикам программного обеспечения, как должна вести себя система. Если система не соответствует функциональным требованиям, значит, она не работает должным образом.
Что такое нефункциональные требования?
Нефункциональные требования определяют стандарты производительности и атрибуты качества программного обеспечения, например удобство использования системы, эффективность, безопасность, масштабируемость и т.д.
В то время как функциональные требования определяют, что делает система, нефункциональные требования описывают, КАК система это делает. Например, веб-приложение должно обрабатывать более 15 миллионов пользователей без какого-либо снижения производительности, или веб-сайт не должен загружаться более 3 секунд.
Если приложение не соответствует нефункциональным требованиям, оно продолжает выполнять свои основные функции, однако не сможет обеспечить удобство для пользователя.
Нефункциональные требования важны, поскольку они помогают разработчикам программного обеспечения определять возможности и ограничения системы, которые необходимы для разработки высококачественного программного обеспечения. Следовательно, нефункциональные требования так же важны, как и функциональные требования для успешного внедрения продукта.
Почему важна разница между функциональными и нефункциональными требованиями?
Четко определенные функциональные и нефункциональные требования помогают разработчикам программного обеспечения создавать продукт, точно соответствующий потребностям клиента. Однако действительно ли необходимо знать разницу между функциональными и нефункциональными требованиями?
Основная причина знать разницу между функциональными и нефункциональными требованиями заключается в том, что они определяют объем работ по проекту. Разработчики программного обеспечения должны идти в ногу с этим объемом, чтобы разработать приложение в рамках своих временных рамок и бюджета.
Если объем работ постоянно меняется, команде разработчиков приходится продлевать сроки, и затраты на разработку возрастают. Это может привести к неблагоприятным последствиям для проекта.
Важность различения двух типов требований имеет первостепенное значение при создании MVP. Команда разработчиков и заказчик должны обсудить, какие функции и функции следует реализовать в приложении в первую очередь. Заказчик может иметь собственное видение проекта и его требований. Если заказчик решает удалить или изменить какую-либо функцию, важно понимать, что это за требование. В большинстве случаев разработчики программного обеспечения могут просто изменить нефункциональные требования, в то время как функциональные требования потребуют дополнительной работы и серьезных изменений.
Когда заказчик и поставщик разработки программного обеспечения знают разницу между функциональными и нефункциональными требованиями, это помогает им более точно определять объем работ, более точно ранжировать требования по важности, оптимизировать затраты на проект и лучше удовлетворять потребности заказчика..
Как собираются функциональные и нефункциональные требования?
В идеале, прежде чем обращаться в компанию по разработке программного обеспечения, у клиентов уже должны быть под рукой все функциональные и нефункциональные требования. Поэтому их необходимо подготовить заранее самостоятельно или попросить стороннего поставщика.
Давайте посмотрим, что включает в себя каждый тип требований.
Функциональные требования можно разделить на три группы:
Нефункциональные требования подпадают под различные категории, в том числе:
Примеры и передовой опыт
Существует множество других форматов, которые могут помочь в выполнении требований проекта. Давайте посмотрим на самые эффективные.
Истории пользователей
Обычно требования формулируются в виде пользовательских историй. Пользовательские истории — это требования, предъявляемые пользователем. Обычно они имеют форму нескольких простых предложений, имеющих один и тот же образец:
Как (пользователь) я хочу (цель), чтобы (причина).
Пример пользовательской истории: как руководитель проекта я хочу понимать прогресс команды разработки программного обеспечения, чтобы я мог сообщить о результатах генеральному директору и заинтересованным сторонам проекта.
Разработчики программного обеспечения обычно составляют требования с использованием пользовательских историй, когда они хотят донести идеи о функциях и функциях продукта до участников, не являющихся техническими специалистами.
Сценарии использования
Сценарии использования шире, чем пользовательские истории. Они включают типы пользователей и все возможные действия, которые пользователь может выполнять в приложении. В отличие от пользовательских историй, описывающих конечную цель функции, варианты использования включают последовательность шагов, ведущих к цели.
Например, если вы хотите создать приложение для управления логистикой и цепочкой поставок, разработчики программного обеспечения должны подумать о следующих ролях: продавцы, покупатели, поставщики, менеджеры, диспетчеры и многие другие.
Действия для этих ролей могут выглядеть следующим образом:
Документ со спецификацией требований к программному обеспечению
Спецификация требований к программному обеспечению ( SRS ) — это документ, на который группа разработчиков программного обеспечения полагается при создании приложения. Он включает в себя все потребности и пожелания клиентов, переведенные на понятный для команды разработчиков язык — подробное описание всех функций и возможностей продукта.
Основные разделы, которые обычно включаются в документ SRS:
Создание SRS, пользовательских примеров и пользовательских историй имеет важное значение для эффективной разработки приложений.
Однако есть и другие документы, не менее важные для успешного запуска и развития проекта.
Заключение
С помощью специализированных программных услуг компании могут создавать приложения любого типа для эффективного развития своего бизнеса. Однако для того, чтобы приложение действительно соответствовало потребностям их бизнеса, оно должно иметь подробные функциональные и нефункциональные требования.
Чтобы сформировать функциональные и нефункциональные требования, вы можете обратиться за помощью к своей компании-разработчику программного обеспечения, сторонним компаниям или сделать это самостоятельно. Хорошо продуманные требования гарантируют, что ваш партнер по разработке программного обеспечения будет полностью понимать, как разработать цифровое решение, которое полностью соответствует вашим ожиданиям и удовлетворяет потребности вашего бизнеса.
Важные шаги до постановки ТЗ на разработку сайта: собираем функциональные и бизнес-требования правильно
Перед постановкой технического задания (ТЗ) на разработку заказчик должен четко понимать, какие задачи будет решать его сайт и как взаимодействовать с посетителями. На языке разработчиков это называется «собрать функциональные и бизнес-требования». В таком случае заказчик сможет точно оценить бюджет и время выполнения, а разработчику не придется переделывать свою работу.
В этой статье расскажу, что такое функциональные и бизнес-требования и почему их нужно собрать перед постановкой ТЗ.
Что такое функциональные требования
Функциональные требования – это особенности сайта, которые должен воплотить в жизнь разработчик. Они описывают то, как система будет работать при выполнении определенных действий пользователя. Например, как проходит регистрация в личном кабинете, покупка товара или оформление подписки.
Само слово «функционал» подводит к тому, что мы задаем вопрос: как работает этот сайт, какие у него будут функции. Сюда относится все, что касается логики работы.
Если заказчик хочет интернет-магазин, то сразу возникает куча вопросов: есть ли в магазине личный кабинет, есть ли в корзине возможность оплаты через эквайринг, существует ли какая-то система лояльности и еще множество нюансов.
Примеры того, как выглядят функциональные требования в техзадании
Кроме функциональных требований, есть еще нефункциональные. Это атрибуты сайта, которые нужны для его устойчивой работы, при этом не связанные с основным функционалом.
Нефункциональных требований очень много. Вот основные:
Нефункциональные требования могут касаться, например, визуальной части – красивых картинок, эффектов, шрифтов. Другими словами, всего того, что мы называем user interface (UI) – внешнего вида сайта. Также сюда относится user experience (UX) – удобство пользователя.
Чтобы объяснить отличие функциональных требований от нефункциональных, приведу такое сравнение. Функциональные требования – это авто или телега, у которых есть 4 колеса, место, где сидеть, и тягловая сила (двигатель или лошадь). А нефункциональные – это кузов мерседеса, с красивыми лампочками и шильдиками. Большинство людей покупают этот значок мерседеса на капоте, но это не отменяет и того, что под капотом все должно хорошо работать.
То же самое с сайтом. Функциональные требования касаются начинки, содержимого, которое не видно пользователю, это шестеренки внутреннего механизма, а нефункциональные пользователь видит сразу, как только заходит на сайт.
Что такое бизнес-требования
Бизнес-требования – это общие задачи, которые должен решать сайт. Ключевое отличие бизнес-требований от функциональных в том, что они должны быть понятны руководителю компании, который не знаком с техническими тонкостями веб-разработки.
Каждую задачу можно решить несколькими способами, важно расставить нужные акценты изначально. Например, если компания заказывает сайт и целью является подтвердить статусность, акцент при разработке будет делаться на эргономичность, фирменный стиль клиента и удобство коммуникации. Если в бизнес-требованиях стоит «получить прибыль» – в первую очередь важно будет показать заказчику возможности получения дополнительной прибыли с помощью сайта, хотя одно другому не мешает.
Зачем нужны функциональные и бизнес-требования
Функциональные и бизнес-требования решают такие задачи:
Кто занимается сбором требований
Когда заказчик до конца представляет себе, каким должен быть сайт на выходе, собирать требования должен именно он. Кроме владельца бизнеса никто не понимает, как нужно продавать услуги, какие инструменты нужны для продвижения, в чем заключаются боли клиентов.
Сбором функциональных требований занимаются, прежде всего, отдел маркетинга и IT-отдел. Для максимальной конверсии главная страница сайта должна содержать ответы на все потенциальные вопросы клиентов, снимать их возражения, страхи. Поэтому нелишним будет собрать такую информацию у отделов продаж и клиентского сервиса.
Если компания небольшая, где нет штатных маркетологов, аналитиков, программистов, стоит привлечь стороннее агентство для проведения конкурентного анализа и разработки digital-стратегии. Как вариант, можно доверить сбор требований компании, которая будет непосредственно разрабатывать сайт.
Заказчик может собирать требования в паре с маркетологом. Иногда подключается специалист от разработчика. Но все равно, продумывание логики работы сайта висит на заказчике. Это не тот вопрос, где можно откупиться деньгами.
Так что, если вы не знаете, каким должен быть ваш сайт, хотя бы в общих чертах, то, скорее всего, он вам и не нужен.
В нашем случае требования собирает менеджер, который выстроил диалог с клиентом и может полностью понять его.
Перед сбором требований менеджер просматривает сайты конкурентов, подробно изучает бизнес заказчика, чтобы при встрече задать ему наводящие вопросы и предложить сайт, который будет решать основные задачи.
При сборе функциональных требований заказчик начинает понимать, как будет выглядеть его сайт, как и что будет расположено, какие процессы будут происходить.
Мы часто заказываем сайты для региональных отделений.
В нашем случае все делали силами своих отделов, но подрядчик – маркетинговое агентство – вносил и свои предложения. Если компания совсем небольшая, рекомендую привлечь агентство, консультанта, маркетолога на аутсорсинге на время реализации проекта (это гораздо дешевле штатного сотрудника), но не надеяться, что подрядчик сделает все. Необходимо предоставить ему полную информацию о продукте, клиентах, задачах компании.
Необходимы хотя бы минимальные маркетинговые компетенции в рамках компании, чтобы можно было оценить результаты: возможностей для самообразования сейчас немало, есть курсы, вебинары, статьи, в том числе ориентированные на собственников бизнеса.
Как проходит сбор требований
Методы сбора функциональных и бизнес-требований:
Требования собираются в отдельный документ, на основе которого уже составляется техническое задание разработчику. Он выглядит в виде брифа и не содержит технической информации.
Для удобства документ обычно разбит на несколько разделов:
По нашей практике, функциональные требования чаще всего формулируются в процессе работы над проектом. Иногда заказчик приходит с примером «хочу как у них», иногда – рассказывает, как он хочет, чтобы сайт работал. Бывает, что заказчик не знает всех возможностей и просто описывает их своими словами.
Наши менеджеры в любом из случаев поймут, что из функционала поможет конкретным задачам и после одного-двух созвонов уже могут в резюме прописать приблизительный список возможностей.
Одно время для сбора требований мы пытались создать универсальную анкету, которую высылали потенциальным клиентам. Она делала свое дело, но в графе «Примечание» всегда была информация, которая отличалась. Так как ее было достаточно много, мы пришли к тому, что вместо анкеты при первом-втором звонке наши менеджеры задают некий список важных для нас вопросов.
Чаще всего данные, по которым составляется техническое задание, собираются именно в процессе разговора: менеджер слушает, фиксирует и прописывает итоги разговора. После согласия заказчика он формирует документ, который передается главному менеджеру проекта. Этот процесс кажется долгим, но разработка программных решений – непростая область, и так как мы выбрали для себя разрабатывать продукты по индивидуальным пожеланиям, этот способ кажется нам оптимальным.
Мы скидываем бриф на заполнение, где заказчик своими словами рассказывает, что у него должно быть на сайте и как это все будет работать, а также пожелания по внешнему виду. Если этого недостаточно, подключаются наши сотрудники: маркетологи и программисты.
Иногда в процессе работы выясняется, что заказчику вообще не нужен сайт, вся его аудитория обитает в социальных сетях. Ну не нужен девочке-маникюрщице продающий лендинг, все ее заказчицы сидят в Instagram.
Зачастую клиент очень поверхностно представляет, какой дизайн хочет увидеть. Поэтому на предварительной встрече мы подробно обсуждаем и предлагаем различные идеи, чтобы понять, какая стилистика больше подойдет и в какую сторону двигаться нашему дизайнеру.
Но для многих клиентов сложно визуализировать эти идеи. Поэтому приходится подбирать множество различных и разносторонних сайтов, примеров стилистики, концепции и дизайнерских решений, которые могут как-то определить вектор направления.
Если клиент затрудняется на встрече или просто не желает подробно расписывать бизнес-процессы в его компании, то менеджер пытается разговорить его и получить нужную информацию, например, предлагая те или иные решения на сайте, которые будут полезны пользователям.
Например, при разработке сайта по продаже напольных покрытий можно взглянуть на будущий продукт глазами покупателя и сказать: «Мне здесь было бы удобно рассчитать стоимость продукции, указав площадь моей комнаты, или получить комплексное предложение сразу с монтажом».
Для нашей компании сайт – ключевой канал продаж. Поэтому при формировании техзадания важно было учесть блоки для повышения доверия к компании, в том числе социальные доказательства, размещение различных CTA, форм захвата и т.д.
При подготовке ТЗ нового сайта мы изучали сайты конкурентов, анализировали данные метрики по поведенческим факторам, WebVisor, чтобы максимально устранить все препятствия в клиентском путешествии и сформировать воронку продаж.
Если вы рассматриваете продвижение сайта в поисковых системах, необходимо до подготовки техзадания собрать семантическое ядро, которое будет влиять как на структуру сайта (разделы), так и на контент.
Как правило, делают наоборот: сначала запускают сайт, затем начинают заниматься продвижением. Также сайт должен соответствовать техническим требованиям поисковиков, и эти моменты нужно прописать в ТЗ. Еще нужно учесть поведенческие факторы, например, включить элементы для удержания посетителей, чтобы увеличить время нахождения на сайте.
Пример брифа компании. Из него станет понятно, чем занимается предприниматель и в чем ключевые преимущества его продукта
Ошибки при сборе функциональных и бизнес-требований
Функциональные требования нужно указывать корректно: без непонятных формулировок и субъективных оценок, которые нельзя проверить, а значит использовать при разработке сайта. При этом важно соблюдать баланс между подробностью и избыточностью. Если слишком уходить в детали, техзадание получится перегруженным и разработчику потребуется много времени на его изучение.
Форма регистрации должна быть удобной и простой.
Форма регистрации должна содержать три поля: имя и электронную почту. Кроме это, пользователь может зарегистрироваться через соцсети.
Страница должна быстро загружаться.
Время загрузки сайта – 3 секунды. Сохранение работоспособности при посещаемости 100 тысяч человек в сутки.
Сайт не должен содержать уязвимостей. Копии ПО хранятся на внешнем носителе.
Обеспечение защиты от межсайтового скриптинга (XSS), SQL-инъекций, CSRF-уязвимостей. Хранение копии ПО и файла базы данных на внешнем носителе.
Окончательной версии требований не существует. Можно определиться с техническими требованиями и структурой, однако некоторые элементы необходимо постоянно тестировать и выбирать наиболее эффективные. Например, визуализацию первого экрана или формы заявок.
Если предположить ситуацию, что функциональные и бизнес-требования будут собираться после составления технического задания, итогом станет увеличение срока работы, так как от требований зависит, что будет в приложении/сайте, как это будет работать. Придется заново пересчитывать стоимость проекта с учетом новых вводных и снова согласовывать то, какие функции будут закрывать новые потребности заказчика. Сбор полной информации по запросу заказчика логически происходит до составления технического задания, и чем качественнее он пройдет, тем быстрее и лучше получится результат.
Какие ошибки чаще всего допускают при сборе ФТ и БТ?
Если менеджер не подготовился к очной встрече, не проанализировал другие сайты, не до конца понял специфику бизнеса, то впоследствии могут возникнуть трудности.
Бывает такое, что в процессе обсуждения не учли какую-нибудь роль пользователя, который будет взаимодействовать с сайтом.
Например, полностью обсудили все процессы и требования для интернет-магазина, но совсем забыли про бухгалтера, который должен просматривать отчет по продажам и формировать накладные и счета, в случае если клиент юридическое лицо. В дальнейшем делается дополнительное соглашение и продукт дорабатывается.
Макет будущего сайта на основе функциональных и бизнес-требований заказчика
Выводы
В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров