Бизнес требования что это

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

1. Бизнес-требования определяют смысл проекта и обосновывают его необходимость. Если мы в какой-то момент теряем фокус, то всегда можем возвращаться к бизнес-требованиям, как к исходной точке, и опираться на них.
2. Бизнес-требования – это удобный инструмент договоренности: они объективны, компактны и понятны стейкхолдерам. Если бизнес-требования хорошо определены, на них просто и эффективно строить контрактные отношения.
3. Из бизнес-требований вытекают критерии приемки проекта. К ним применяются те же критерии качества, что и к другим типам требований, включая тестируемость. Критерии выполнения бизнес-требований фактически являются готовыми критериями приемки и оценки результатов проекта.
4. Бизнес-требования используются для определения рамок проекта. В различных стандартах, либо определение рамок является частью бизнес-требований, либо наоборот.
5. Бизнес-требования помогают принимать решения о приоритетах. Например, как решить, какую особенность системы важно реализовать раньше, а какую – позже? Если мы понимаем, как функции связаны с теми или иными бизнес-требованиями, такое решение принять легко: при известном приоритете бизнес-требования будет понятен и приоритет связанных с ними функции. А если не понимаем, то спорить можно до бесконечности, и никогда так и не договориться.
6. И, наконец, в Scrum бизнес-требования являются (во всяком случае, так должно быть) основным инструментом владельца продукта для управления продуктовым бэклогом и для согласования его с другими стейкхолдерами.

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

Подписаться на рассылку
Подпишитесь на рассылку, чтобы получать от нас полезные материалы и оставаться на связи

«Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности»

Понятие требований в инженерных стандартах

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

Второе определение, напротив, говорит о требовании как о том, что требуется от чего-то (т. е. от решения).

Первое определение охватывает понятия «бизнес-требований» и «требований стейкхолдеров», а второе «требований к решению» (функциональных и нефункциональных).

Инженерный стандарт ISO/IEC/IEEE 29148 версии 2011 года упоминает, но не определяет понятия бизнес-требований. Он использует понятие «требования стейкхолдеров» (Stakeholder Requirements) и считает бизнес-требования разновидностью требований стейкхолдеров. (В версии 2018 года ISO/IEC/IEEE 29148 уже различает документы Business Requirements и Stakeholder Requirements)

Российский ГОСТ 34.601−90 (тоже очень технический, а не бизнес-ориентированный) вообще не использует понятие бизнес-требований, а упоминает только «требования пользователя».

Six Sigma — не инженерный стандарт, а организационно-управленческий подход, но на него ссылается стандарт ISO. Здесь появляется понятие бизнес-требований, которые определяются как «Критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от [конкретного] решения». В этом определении особо подчеркивается, что эти активности не должны быть привязаны к какому-то конкретному решению, то есть подразумевается, что решения, могут быть разными.

Six Sigma также вводит понятие Business Requirement Definition (BRD) — документа спецификации бизнес-требований, в который, в том числе, включаются потребности и ожидания клиента.

Подписаться на рассылку
Подпишитесь на рассылку, чтобы получать от нас полезные материалы и оставаться на связи

«Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c политикой конфиденциальности»

Понятие требований в бизнес-анализе

Руководство к своду знаний по бизнес-анализу (BABOK Guide) в предыдущих версиях использовал определение стандарта ISO, однако за несколько лет практики его применения стали очевидны проблемы, связанные с недостаточной бизнес-ориентированностью этого определения. Версия 3 BABOK Guide определяет требования с другого ракурса. Вот три самых важных момента в этом новом определении:

1. Если в инженерном стандарте требования — это «то, что нужно кому-то или что требуется от чего-то», то BABOK Guide определяет требование как «пригодное для использования представление потребности», то есть фокусируется на том, что нужно.
2. BABOK Guide подчеркивает, что требование любого уровня должно фокусироваться на понимании приносимой пользы: зачем нужно.
3. BABOK Guide уточняет, что форма представления может значительно варьироваться в зависимости от обстоятельств (не предписывает какую-либо форму представления или шаблон).

Дело в том, что формулировки потребностей как таковых звучат обычно очень тривиально. При виде формулировки потребности возникает вопрос: «Ну и что? Да, это так, это очевидно, но что с этим делать?»

Вот пример формулировки потребности:

«Люди испытывают ежедневную потребность в пище»

Но ведь это очевидно, верно? Казалось бы, с этим ничего невозможно сделать, так зачем об этом вообще говорить?

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

Потребность людей в пище, конечно, очевидна всем.

Но в контексте морских путешествий эту потребность уже можно сформулировать в виде требования, например, такого:

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

Можно поразмышлять для тренировки над тем, в какие требования могла бы преобразоваться потребность в пище, если бы мы поместили её в другие контексты: школьного питания; работы на заводе или в офисе; постовой службы; пограничной службы; космических полетов. Очевидно, что требования будут совершенно разные, хотя потребность — одна и та же. Различие только в контексте.

Вернемся к нашему примеру с требованием о продуктах питания для моряков. Это требование уже можно выполнить, и его выполнение можно проверить.

Выполнить это требование можно разными способами. Можно, например:

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

Бизнес-требования в бизнес-анализе

«Пригодное для использования представление потребности» — это определение требования вообще. Бизнес-требования BABOK Guide определяет как «Представление целей, задач и результатов, объясняющих зачем было инициировано изменение и как будет оцениваться успех». То есть бизнес-требования отвечают на вопрос «почему мы вообще хотим что-то менять, зачем это надо, и что это даст».

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

Есть ещё одно важное свойство бизнес-требований, о котором BABOK Guide не говорит явно, но которое нужно читать между строк и понимать: бизнес-требования не зависят ни от каких стейкхолдеров.

Иногда у аналитиков возникают трудности с различением того, является ли требование бизнес-требованием или нет. Встречается также упрощенное понимание, что всё, что сообщают представители бизнеса — это и есть бизнес-требования. Это не так.

Для проверки того, является ли некое требование бизнес-требованием, нужно задать себе такие вопросы: Может ли требование измениться, если завтра на месте того, кто сообщил это требование будет работать другой человек? Изменится ли требование если изменится бизнес-процесс? Если вы ответили «нет» на оба вопроса, то проверка пройдена успешно.

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

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

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

Программа переподготовки

«Business Analyst Bootcamp»

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

Источник: systems.education

Как оформить функциональные и бизнес-требования к сайту электронной коммерции?

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

3785 просмотров

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

Что такое бизнес-требования

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

Что входит в бизнес-требования

• Данные компании. Область бизнеса, продукт, портрет покупателя, конкурентные преимущества.
• Целевая аудитория. Местоположение, пол, возраст, хобби потенциальных посетителей магазина. Важно осознавать, зачем люди посещают магазин. К примеру, приобрести продукт, узнать стоимость услуги или ознакомиться с новостями.
• Анализ конкурентов
• Цель запуска проекта. Выйти на новый рынок. Стать монополистом в нише. Перевести бизнес в онлайн.
• Конкретизированная цель. Например, система должна обеспечить доставку в Израиль. Увеличить товарооборот (в цифрах) . Ускорить обработку заказов через автоматизацию работы менеджеров.
• Планируемые метрики. Увеличить трафик вдвое за первый год запуска проекта. Увеличить коэффициент конверсии трафика с 0,8% до 1,1%. Втрое увеличить количество вендоров. Поднять прямые онлайн-продажи без похода в магазин на 30% за полгода.
• Пользовательские требования, то есть какую задачу должен решить пользователь на сайте. Купить шампунь, если речь идет о покупателе на сайте. Организовать доставку в другую страну, если пользователь — другая компания. Увеличить заработок для вендора. Иметь доступ только к заказам для менеджера по продажам и так далее.

Как бизнес-требования влияют на итоговый продукт?

Часто бизнес-требования влияют на способ реализации продукта. Рассмотрим несколько примеров.

• Требование А. Чтобы привлечь вендоров, владелец маркетплейса может предложить продавцам продолжать работать в собственных системах, интегрировав эти системы в маркетплейс. Вендорам не придется изучать интерфейс новой для себя системы, а владелец будет иметь все необходимые данные на своей платформе. Таким образом, способом реализации продукта станет интеграция с сервисами вендора по API.
• Требование Б. По условию франшизы за определённой территорией может быть закреплен только один продавец / территориальный представитель, который будет работать с заказами покупателей из данного региона. Продажа товаров на данной территории другими представителями бренда запрещена по условиям договора. Способ реализации: определение геолокации покупателя, сортировка товаров и отображение актуальных остатков для конкретной локации, привязка покупателя к продавцу для дальнейших заказов.
• Требование В. Владелец сайта-каталога (где можно просматривать товары, но нельзя покупать их) хочет создать интернет-магазин без перехода на новую платформу. В связи с этим, требуется внедрить функционал оформления заказа из платформы CS-Cart таким образом, чтобы для покупателя это выглядело «бесшовно», как будто он и не покидал существующий сайт. Способ реализации: интеграция технологии единого входа — SSO — при которой пользователь переходит из одной системы в другую без повторной аутентификации.

Почему нужно конкретно и четко оформить бизнес-требования?

Четкое формулирование бизнес-требований:

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

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

• Опишите ваш продукт / услугу. Что будет являться товаром? Какие его характеристики? Как будет считаться его стоимость?
• Роли пользователей (администратор, продавец покупатель) и какие действия может выполнять каждый из них? Есть ли какие-либо зависимости / ограничения?
• CJM (путь покупателя по сайту) : какими будут действия покупателя по приобретению вашего продукта? Какие соответствующие действия должен будет выполнять продавец / администратор?
• Регистрация пользователей: какие данные должны предоставить пользователи для регистрации?
• Как будет выглядеть личный кабинет (профиль) покупателя для пользования услугой? Какие действия он сможет выполнять?
• Понадобится ли интеграция со сторонними системами? Какими?

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

Что такое функциональные требования?
Примеры функциональных требований:

• Вендор регистрируется в системе: система регистрирует данные вендора на входе и на выходе отображает их на странице всех вендоров.
• Присвоение уникального номера заказу: система обрабатывает заявки на заказы. Приходит заказ, система присваивает ему номер и на выходе выдает список заказов.
• Расчет доставки: система по API запрашивает данные у сервиса доставки и выдает рассчитанную стоимость доставки на странице заказа.
• Поддержка мобильных кошельков: в странах Среднего Востока и Северной Африки система принимает оплату с мобильного телефона.

Нефункциональные требования. Важные особенности

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

Нефункциональных требований очень много. Вот некоторые из них.

• Дизайн, UX/UI. Добавить дополнительную кнопку на чекауте. При переходе на страницу продукта пользователь видит все вариации продукта.

• Требования к коду: cделать модификацию на JS, работа в репозитории клиента, использовать указанные заказчиком библиотеки при реализации модификации.

• Настройка процессов непрерывной доставки и улучшения кода. CI и CD процессы призваны автоматизировать проверку и доставку разработанного ПО заинтересованным лицам.

• Адаптация готовых решений. Вы можете выбрать готовые модули на маркетплейсе и с его помощью быстро закрыть какое-то функциональное требование, например, с помощью модуля Google Analytics Enhanced Ecommerce следить за событиями покупки на сайте прямо в админке платформы. Но бывают случаи, когда модули приходится дорабатывать под нужды конкретного проекта.

• Контент. На продуктовые страницы добавить ссылки на юридические документы. Такое требование часто озвучивают владельцы немецких маркетплейсов.

• Производительность сайта. Магазин должен выдерживать нагрузку в 1000 посетителей онлайн одновременно.

Кто собирает требования?

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

✔ Стороннее агентство, нанятое заказчиком

✔ Штатный аналитик заказчика

✔ Наша команда в рамках услуги “Проектирование”

Как происходит сбор требований?

Обычно сбор требований происходит через интервью, переписку или в специальных системах типа Notion, Trello и т. д. Приведем алгоритм сбора требований:

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

Кто участвует в сборе требований?

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

• Вендоры и отдел привлечения вендоров (для маркетплейсов)
• Бухгалтерия (чтобы понимать, какие отчеты нужны, как проводить платежи)
• Юридический отдел (если есть юридические ограничения, которые нужно учесть при создании интернет-магазина) .
• Маркетинг (для реализации механики промо акций)
• IT-отдел (при наличии, поскольку ему придется поддерживать готовую систему после сдачи работ)
• Специалисты по безопасности
• Сторонние эксперты

Вспомогательные материалы, предоставляемые заказчиком

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

• Примеры конкурентов и реализации желаемого функционала
• Блок-схема с описанием бизнес-процессов, функциональности
• CJM-карта
• Архитектурная диаграмма
• Документ с описанием проекта (общее описание того, что будет представлено на панелях администратора, вендора и пользователя)
• Дизайн-макеты
• План развития проекта, например, нагрузка на сайт, способы монетизации проекта, планы по ROI и т. п.
• Список ролей участников проекта и схема принятия решения
• User-cases (описание сценариев работы при определенной ситуации, например, что происходит при регистрации пользователя) .

Какие ошибки допускают заказчики в ходе сбора информации?

• Выбор изначально неподходящего стороннего сервиса. Так происходит, когда заказчик не оговаривает цель, а просит подключить сервис на свой выбор. После интеграции сервиса, оказывается, что отсутствует дополнительный функционал, необходимый магазину. Опыт разработчика может помочь при выборе оптимального решения для интеграции, отвечающего процессам и целям магазина.
• Выбор неподходящей платформы. Клиент сам выбирает вариант платформы без понимания ее особенностей. Например, бизнес ведется по модели маркетплейса (Multi-Vendor) , но клиент покупает лицензию однопользовательского интернет-магазина (CS-Cart) . До покупки лицензии лучше обратиться к исполнителю и дать описание бизнес-модели и бизнес-процессов компании. Так, исполнитель сможет подсказать, какой вариант платформы подходит лучше всего.
• Неверно сформированный запрос. Например, заказчик просит исправить код для улучшения показателей SEO, но на самом деле проблема не в коде, а в сервере, который плохо выдерживает нагрузку. Здесь помогло бы четкое описание проблемы и желаемого результата. Исполнитель сможет подобрать комплексное решение, помогающее оптимально достичь цели.

Насколько детализированными должны быть требования?

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

• Пример 1. Форма для регистрации интуитивно понятна.

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

• Пример 2. Магазин не должен тормозить.

Как нужно: Скорость загрузки страницы составляет 2 секунды. Магазин остается производительным при нагрузке в 150 тысяч посетителей в день.

Рекомендации заказчику, пишущему требования

Желательно, чтобы заказчик, формирующий требования, писал максимально просто с четким наименование объектов (покупатель, вендор, администратор сайта) и результата. Лучше всего, в формате пользовательских сценариев. При этом, функциональные требования будут выглядеть как совокупность функций, объединенных по смыслу. Например, кейс «Зарегистрировать визит пациента в зубной кабинет» будет состоять из совокупности функций:

• Просмотр истории визитов;
• Добавление еще одного визита;
• Выбор посещения зубного кабинета;
• Просмотр деталей визита (число, время, кабинет, лечащий врач) ;
• Редактирование информации о визите;
• Удаление визита.

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

• Анкетирование. Сюда можно отнести “Бриф на разработку сайта”. Это анкета со списком основных требований к сайту.
• Интервью. Такой способ используется в основном для получения уточнений по конкретному вопросу или требованию.
• Мозговой штурм. Участники генерируют множество идей и вариантов решений, развивая.
• Запустить голосование
• Привлечь эксперта

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

Источник: vc.ru

Как собрать функциональные требования к будущему сайту

Александр Майфет Редакция «Текстерры»

Перед постановкой технического задания (ТЗ) на разработку заказчик должен четко понимать, какие задачи будет решать его сайт и как взаимодействовать с посетителями. На языке разработчиков это называется «собрать функциональные и бизнес-требования». В таком случае заказчик сможет точно оценить бюджет и время выполнения, а разработчику не придется переделывать свою работу.

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

Оглавление:
Оглавление:

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

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

Само слово «функционал» подводит к тому, что мы задаем вопрос: как работает этот сайт, какие у него будут функции. Сюда относится все, что касается логики работы.

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

Пример того, как выглядят функциональные требования в техзадании

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

Нефункциональных требований очень много. Вот основные:

• Производительность. Например, скорость загрузки страницы или время реакции на определенные действия.
• Удобство для пользователя. Насколько интуитивное меню, сколько времени уходит у пользователя на поиск нужной информации.
• Безопасность. Персональные данные должны быть защищены от взломов, хакерских атак, вирусов.
• Совместимость. Как сайт смотрится на различных браузерах и устройствах. Возможно, с экрана телефона часть картинки не видно.
• Локализация. Если компания сотрудничает с иностранными клиентами, нужно адаптировать сайт под их запросы. Например, перевести контент на английский язык, добавить другую валюту или часовые пояса.

Нефункциональные требования могут касаться, например, визуальной части – красивых картинок, эффектов, шрифтов. Другими словами, всего того, что мы называем user interface (UI) – внешнего вида сайта. Также сюда относится user experience (UX) – удобство пользователя.

Чтобы объяснить отличие функциональных требований от нефункциональных, приведу такое сравнение. Функциональные требования – это авто или телега, у которых есть 4 колеса, место, где сидеть, и тягловая сила (двигатель или лошадь). А нефункциональные – это кузов мерседеса, с красивыми лампочками и шильдиками. Большинство людей покупают этот значок мерседеса на капоте, но это не отменяет и того, что под капотом все должно хорошо работать.

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

Продвинем ваш бизнес

В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров

Что такое бизнес-требования

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

• Информацию о компании: название, год основания, сфера деятельности, товарный знак, список клиентов, преимущества перед конкурентами.
• Данные о целевой аудитории. Нужно примерно представлять, кто будет посетителем сайта: его пол, возраст, регион проживания, привычки и увлечения. Еще нужно понимать, зачем людям вообще приходить к вам на сайт. Например, купить товары, узнать стоимость дизайн-проекта или почитать новости.
• Цель создания сайта: что вы хотите получить в итоге. Например, увеличить количество продаж или повысить узнаваемость бренда.

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

Бизнес-требования от заказчика сайта

Зачем нужны функциональные и бизнес-требования

Функциональные и бизнес-требования решают такие задачи:

1. Упрощают взаимодействие между заказчиком и разработчиком. Они помогают избежать недопонимания, определяют общие термины и роли.
2. Сокращают срок реализации проекта. Благодаря четким требованиям разработка сайта займет меньше времени.
3. Экономят бюджет. Когда заказчик понимает что ему нужно, он может более точно спланировать бюджет. Размытые требования приводят к неопределенной стоимости разработки, которая впоследствии может вырасти.
4. Выявляют возможные ошибки. Выявление ошибок на начальном этапе поможет сократить время и деньги на их исправление.
5. Помогают предвидеть итоговый результат. С помощью требований разработчик понимает, что двигается в правильном направлении. Они не дают увлечься и отойти от первоначальной идеи, выступая некими границами проекта.

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

Техзадание на разработку сайта: запрещенные слова и выражения

Кто занимается сбором требований

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

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

Если компания небольшая, где нет штатных маркетологов, аналитиков, программистов, стоит привлечь стороннее агентство для проведения конкурентного анализа и разработки digital-стратегии. Как вариант, можно доверить сбор требований компании, которая будет непосредственно разрабатывать сайт.

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

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

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

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

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

Ваша заявка принята.
Мы свяжемся с вами в ближайшее время.

Как проходит сбор требований

Методы сбора функциональных и бизнес-требований:

• бриф на разработку сайта;
• личное интервью;
• изучение документации компании (например, регламентов, спецификаций продукта, инструкций);
• участие представителя от компании-заказчика;
• мозговой штурм;
• общее совещание.

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

Для удобства документ обычно разбит на несколько разделов:

• Бизнес-требования. Это самые приоритетные требования, которые определяют цель создания сайта и задачи.
• Дизайнерские требования. Здесь описаны цвета, шрифты, стилистика будущего сайта. Они должны совпадать с идеей или фирменным стилем заказчика.
• Требования пользователей сайта. В данном блоке прописано, какую информацию может просматривать/добавлять/редактировать пользователи сайта. Например, менеджеру по продажам в интернет-магазине нужен только доступ к заказам, а бухгалтеру – к счетам и отчетам.
• Требования посетителей сайта. Здесь описан путь посетителя на сайте. Если проект очень крупный, составляется полноценная концепция поведения аудитории – Customer Journey Map.

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

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

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

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

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

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

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

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

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

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

Ошибки при сборе функциональных и бизнес-требований

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

Форма регистрации должна быть удобной и простой.

Форма регистрации должна содержать три поля: имя и электронную почту. Кроме это, пользователь может зарегистрироваться через соцсети.

Страница должна быстро загружаться.

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

Сайт не должен содержать уязвимостей. Копии ПО хранятся на внешнем носителе.

Обеспечение защиты от межсайтового скриптинга (XSS), SQL-инъекций, CSRF-уязвимостей. Хранение копии ПО и файла базы данных на внешнем носителе.

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

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

Какие ошибки чаще всего допускают при сборе ФТ и БТ?

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

Бывает такое, что в процессе обсуждения не учли какую-нибудь роль пользователя, который будет взаимодействовать с сайтом.

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

Макет будущего сайта на основе функциональных и бизнес-требований заказчика

Выводы

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

Мы в TexTerra тоже начинаем разработку сайта со сбора функциональных и бизнес-требований. Это помогает нам выполнить работу в точности так, как это необходимо клиенту. При этом заказчик во время проработки требований сам лучше понимает, что получит на выходе. Если вашему бизнесу нужен сайт – обращайтесь за разработкой в TexTerra.

Шаблон или уникальный дизайн: что выбрать для сайта

Источник: texterra.ru