Примеры бизнес требований для личного кабинета

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

Разработка личного кабинета клиента на вашем сайте

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

Вы решили разработать личный кабинет на своем сайте. Предлагаем Вам план наших совместных действий:

1. Составьте бизнес-требования к личному кабинету.
   • От Вас на данном этапе не требуется подробная и скурпулезная работа, важно в виде бизнес-требований определиться с целями и задачами личного кабинета. Опишите, каких целей достигает выполнение той или иной задачи пользователем личного кабинета. Не углубляйтесь в технологии, на данном этапе важна именно ценность личного кабинета для вашего бизнеса. Это может быть текст от нескольких абзацев до нескольких станиц. Это может быть просто сценарий работы клиента в личном кабинете. Для составления бизнес-требований нашим клиентам часто помогает наш калькулятор личного кабинета. Набор функционала, описанный в нем, поможет Вам подсказать цели и задачи вашего личного кабинета;
   • Установите в зависимости от целей и задач личного кабинета роли пользователей внутри личного кабинета. Добавьте в бизнес-требования, какие задачи решает пользователь с каждой ролью, что он будет видеть, пройдя авторизацию в личном кабинете. Если определиться этим сложно, позднее, на этапе создания технического задания (ТЗ), мы Вам поможем в этом;
   • Теперь подумаем о технологиях. Своими словами опишите видение, где и на каком устройстве (настольный компьютер, планшетный компьютер, смартфон) по вашему мнению, какую задачу должен решать пользователь с каждой ролью в личном кабинете. Мы разрабатываем адаптивные личные кабинеты в виде web-приложений и мобильные приложения. С учетом современного развития технологий и возможностей современных смартфонов, определенная задача в мобильном приложении может быть решена в разы быстрее, чем на компьютере;
   • В бизнес-требованиях обязательно надо указать, какая информация для личного кабинета где хранится. Для примера, когда речь заходит об отчетных документах, в большистве случаев они находтся в 1С компании и их нужно автоматически забирать для конкретного клиента и выдавать в личном кабинете в виде электронных копий. Или наоборот, нужно, чтобы заказ клиента в личном кабинете автоматически попадал в виде заказа клиента в 1С. На данном этапе важно знать, какие данные личный кабинет будет брать из вашей информационной системы, а какие данные автоматически передавать в вашу информационную систему. В примерах приведен программный продукт 1С , так как он чаще всего встречается в российском бизнесе. Но это может быть любая информационная система. Для бюджета и срока проекта важно, кто на стороне вашего программного обеспечения выполнит задачи обмена информацией с личным кабинетом. В крупных компаниях, имеющих собственное высокопрофессиональное IT-подразделение, наш доступ к внутренних информационным ресурсам заказчика ограничен. В этом случае мы составляем протокол обмена личного кабинета и информационной системы заказчика, в котором описываем, что должен делать каждый запрос.

   Очень советуем бизнес-требования создать. Без них сложно будет со всеми последующими этапами.

2. Готовые бизнес-требования пришлите нам. От того, насколько раньше мы подключимся к процессу создания личного кабинета, выиграют в будущем обе стороны. Конечно, у нас будет еще много вопросов, после получения ответов на которые мы сможем Вам сказать срок и бюджет проекта создания личного кабинета в виде коммерческого предложения.
3. После заключения договора мы пишем Техническое задание (ТЗ). На данном этапе мы рисуем прототипы интерфейсов личного кабинета (общая навигация, формы ввода, отчеты, списки, …). После принятия Вами прототипов мы описываем функционал интерфейсов и действия пользователя личного кабинета для каждой роли. Эти документы пишем мы, ваша задача понять и принять все в нем.
4. После утверждения ТЗ производится создание дизайна личного кабинета. На данном этапе Вы можете предоставить элементы вашего фирменного стиля при их наличии;
5. Вы принимаете макеты дизайна личного кабинета, мы выполняем статическую HTML-верстку каждого макета. После принятия Вами данного этапа мы приступаем к программированию web-приложения личного кабинета;
6. На тестовом сервере Вы можете видеть ваш будущий личный кабинет. Для клиентской части личного кабинета мы используем ReactJS. Обычно мы разбиваем проект на этапы по вводу в эксплуатацию функционала личного кабинета (спринты). Ваш клиент увидит наиболее важные и срочные функции личного кабинета в первую очередь. Также поможем определить минимально жизнеспособный продукт (MVP), когда личный кабинет можно запустить в реальную работу, а второстепенные функции дорабатывать в следующих версиях. Вам не нужно будет ждать весь срок проекта для тестирования и выявления недостающих функций личного кабинета, Вы сможете делать это по мере сдачи каждого этапа. Это уменьшает ваши риски по выполнению проекта.
7. Параллельно производтися программирование сервеной части личного кабинета. Именно сервер взаимодействует с вашим учетным ПО (1С и др.), хранит информацию в своей базе данных, выполняет задачи взаимодествия со сторонними сервисами (SMS-шлюзы, Контур.Фокус, ЕСИА, СМЭВ и др.). Выгодным фактом является то, что большинство запросов к серверу личного кабинета, которые мы программируем, могут работать и для мобильного приложения, в котором позднее можно реализовать функции личного кабинета. На этапе коммерческого предложения мы для Вас предложим программное обеспечение, на котором будет выполняться серверная часть проекта личного кабинета. Чаще всего мы использует в качестве системы управления личного кабинета 1С-Битрикс. Но это могут быть и фрейморки Laravel, Yii, и т.д.
8. Тестирование. На наши работы, как правило мы даем гарантию в полгода. В результате эксплуатации могут выявиться наши ошибки, которые мы исправляем бесплатно. Также мы всегда сопровождаем наши проекты, работая над дополнительным фунционалом личного кабинета. Сам факт ввода личного кабинета потребует от менеджеров вашей компании иногда не только дополнительной работы с клиентом в дополнительном информационном канале, но и модернизации и даже смены бизнес-процессов в вашей компании. Для этого потребуются справочные материалы. Это могут быть видеоинструкции по работе в личном кабинете для каждой роли пользователя.

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

Посчитать стоимость личного кабинета в калькуляторе

Стоимость типовых решений

Личный кабинет, как правило, предусматривает три роли: клиент, менеджер компании, руководитель компании.

Клиенту

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

• Хранит список текущих заказов клиента с отражением текущего состояния каждого заказа;
• Предоставляет архив заказов товаров клиентом с выводом истории изменения состояний заказов;
• Показывает взаиморасчеты клиента и компании.
• Предоставляет список отчетных документов: счетов, накладных и счетов-фактур с возможностью распечатать документ со сканированными подписями и печатями. Есть возможность выгрузки документа в формат PDF (Acrobat Reader);
• Позволяет хранить и скачивать документы, касающиеся только текущего клиента.
• Позволяет выписать счет на пополнение баланса клиента.

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

• Показывает список активных договоров компании с клиентом, их состояние и параметры;
• Предоставляет список текущих услуг, предоставляемых клиенту компанией, с возможностью просмотра услуги и текущего баланса отдельно по каждой услуге. Обычно услуги предоставляются этапами, поэтому клиент может видеть за какой период какое количество услуг оказано клиенту;
• Дает возможность оформить очередную заявку (запрос) на предоставление услуги.
• Показывает взаиморасчеты клиента и компании.
• Предоставляет список отчетных документов: счетов, актов приемки-сдачи и счетов-фактур с возможностью распечатать документ со сканированными подписями и печатями. Есть возможность выгрузки документа в формат PDF (Acrobat Reader);
• Позволяет хранить и скачивать документы, касающиеся только текущего клиента.
• Позволяет выписать счет на пополнение баланса клиента с возможностью дальнейшей онлайн оплаты счета на пополнение баланса.
• Предоставляет возможность оформить запрос своему менеджеру на выполнение той или иной работы: составление отчета для клиента, досрочное закрытие услуги и т.п.

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

Менеджеру

Менеджер из любого места на Земле, где есть доступ в интернет, может:

• Администрировать список своих клиентов.
• Для каждого клиента ведется список договоров с их параметрами и состоянием.
• Выписывать (или импортировать из учетного программного обеспечения, такого как 1С) и пересылать клиенту отчетные документы, давать клиенту ссылки на скачивание документов в формате PDF;
• Обрабатывать запросы клиентов;
• Видеть все взаиморасчеты с клиентом: отгрузки (оказание услуг) клиенту и оплаты от него.

Руководителю

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

Подробнее о функционале личного кабинета

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

• mod_client_manager — менеджер клиентов. Ведет список клиентов и их контактных лиц, договоров;
• mod_paysystem — платежная система. Отвечает за оплаты от клиентов, включая обеспечение шлюзов к электронным платежным системам. ФЗ-54;
• mod_finsystem — финансовая система. Отвечает за реализацию продукции и услуг. Учитывает акты оказания услуг и счета фактуры. Ведет учет средств на лицевых счетах клиентов. Мощный механизм импорта выписок популярных банк-клиентов позволяет автоматизировать большую часть операций;
• mod_contact_manager — менеджер контактов с клиентами. Фиксирует все контакты с клиентами вместе с уведомлением сотрудников компании и представителей клиента;
• mod_support_client_line — обработка запросов от клиентов на услуги;
• mod_filearchive — хранение документов на сайте с возможностью деления документов по каталогам, а также с назначением прав доступа к каждому документу;
• mod_news — новости. Позволяет разделять новости на группы и выводить в личном кабинете новости только для клиентов;
• mod_faq — частые вопросы и ответы клиентов. Позволяет делить вопросы-ответы по группам и выводить только внутренние вопросы-ответы;
• mod_forum — форум, может быть закрытым от внешних посетителей, может быть организован как форум только для общения менеджеров;
• mod_offer_manager — коммерческие предложения клиентам. Фиксация, отслеживание коммерческих предложений клиентам, смена состояний КП. Есть блок работы с «холодными» контактами;
• mod_jabber — отправка сообщений по протоколу jabber (qip, ya.ru, mail.ru, …);
• mod_sms_sender — отправка SMS сообщений клиентам, используя SMS-шлюзы;
• mod_docman — модуль хранения экземпляров документов с возможностью их экспорта в PDF-формат;
• mod_projects — модуль работы над проектами, с постановкой и отслеживанием задач сотрудниками;
• mod_corporation — модуль структуры компании с формированием штатного расписания;
• mod_list — модуль управления списками в личном кабинете. Мини база данных;
• mod_number_generator — модуль формирования номеров документов в личном кабинете;
• mod_notify — модуль системных онлайн уведомлений пользователю личного кабинета;
• mod_chat — модуль онлайн чатов клиентов с менеджерами;
• mod_account_manager — модуль управления пользователями в личном кабинете;
• mod_filials — модуль управления структурой филиалов компании;
• mod_location_manager — модуль управления геопозицией пользователя;
• mod_work_calendar — модуль управления рабочим календарем компании (праздники, выходные, рабочие дни);
• mod_time_tracker — модуль таймером в личном кабинете с возможностью отсчета периодов между событиями.

Здесь рассмотрены только наиболее общие модули. Конечно, для конкретного бизнеса иногда приходится писать такие модули, как заказ авиабилетов, управление пансионатом (санаторием, и т.д.), управление лизинговыми услугами, обработку заказов на семинары и т.д. Состав модулей выяснится на этапе формирования вами бизнес-требований, а позднее создания нами технического задания. Предлагаем более подробно ознакомиться с разработкой личных кабинетов клиента в нашей компании.

В зависимости от текущего состояния вашего сайта существуют несколько реализаций личных кабинетов:

1. Ваш сайт изначально создан на популярных системах управления сайтом. таких как 1С-Битрикс. В этом случае легко все сделать, просто в отдельном подразделе с переходом на личный кабинет по адресу ваш_сайт/my/ с настройкой соответствующих прав доступа;
2. Ваш сайт создан без систем управления управления сайтом. Здесь два варианта:
   • сайт маленький и стандартный по функциям. В этом случае легко перенести ваш сайт на нашу систему управления InlifeCMS или 1С-Битрикс и далее см. п. 1;
   • сайт большой и у Вас нет желания переводить его на предложенную нами систему управления. Тогда мы делаем личный кабинет на домене третьего уровня my.yoursite.ru с соблюдением в шаблоне навигации основного сайта. Таким образом, клиент не заметит, что он переместился на другой сервер.

Заказ создания личного кабинета на вашем сайте

Если Вас заинтересовала данная услуга, Вы можете посчитать стоимость разработки личного кабинета,
или позвонить по телефону 8 (495) 661-62-27, или заполните форму:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не подойдет	Подойдет
Форма регистрации должна быть удобной и простой.	Форма регистрации должна содержать три поля: имя и электронную почту. Кроме это, пользователь может зарегистрироваться через соцсети.
Страница должна быстро загружаться.	Время загрузки сайта – 3 секунды. Сохранение работоспособности при посещаемости 100 тысяч человек в сутки.
Сайт не должен содержать уязвимостей. Копии ПО хранятся на внешнем носителе.	Обеспечение защиты от межсайтового скриптинга (XSS), SQL-инъекций, CSRF-уязвимостей. Хранение копии ПО и файла базы данных на внешнем носителе.

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

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

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

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

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

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

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

Выводы

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

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

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

Наименование департамента

[НАИМЕНОВАНИЕ ПРИЛОЖЕНИЯ ИЛИ СИСТЕМЫ]

Документ с бизнес-требованиями

Документ с бизнес-требованиями

Руководство по использованию шаблона требований

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

Назначение	Требование — это задокументированное условие или возможность продукта, сервиса или системы, которые должны соответствовать задачам проекта. Управление требованиями представляет собой семантический подход к выявлению, организации и документированию требований продукта, сервиса или системы. Документ с описанием бизнес-требований служит базовой линией проекта, которая поясняет, в бизнес-терминах, что необходимо сделать на этапе проектирования в проекте. Так как требования являются динамичными, то документ с бизнес-требованиями является постепенно изменяющимся документом, целью которого является записывать то, что известно на данный момент, а затем используя эти записи строить документ дальше по ходу развития проекта. Именно из этого документа появляется более конкретная проектная документация, которая формируется на основе потребностей проекта и других взаимодополняющих методологий.
Владение документом	Бизнес-анализ и руководители проекта работают с бизнес-спонсором и любыми другими необходимыми бизнес или техническими лидерами на проекте в рамках формирования документа с бизнес-требованиями.
Когда документ формируется	Формирование документ с описанием бизнес-требований запускается во время начальной стадии выполнения проекта, который предшествует стадии проектирования в жизненном цикле управления проектами. Определение бизнес-требований является обязательным этапом во всех проектах.
Template Completion Note:  Text within <  > brackets need to be replaced with project-specific information.	Сбор требований непростой процесс, как это может показаться изначально. Это достаточно сложная задача, поскольку требования: ·   не всегда очевидны; ·   могут поступать из многочисленных и разнообразных источников; ·   нуждаются в управлении кросс-функциональными группами людей; ·   могут вызывать сложности при формулировании в ходе написании документации; ·   могут формулироваться на разных уровнях детализации. Для проекта, который представляет собой усовершенствование существующего продукта, сервиса или системы, команда проекта проводит обзор существующих документов; поэтому документ с бизнес-требованиями, как правило, является более кратким. Тем не менее, проект, в ходе которого должен быть разработан новый продукт, услуга или система, как правило, будет содержать более детальный документ. 1.     Не включайте раздел руководства к шаблону в итоговый документ. Введите информацию о проекте в заголовке страницы, нижние колонтитулы, титульный лист, участников по разработке документа, а также заполните информацию по контролю версий. 2.     Заполните документ, используя вспомогательную информацию в <скобках>. 3.     Для небольших проектов можно объединить все разделы требований в одну таблицу, добавив столбец «Тип требования». 4.     Если некоторые требования не применяются в вашем проекте, то не удаляйте его, а пометьте его как «Не применяется» и укажите краткое пояснение, почему в текущем проекте данное требование не актуально. 5.     Если на проекте имеются дополнительные требования, то ими нужно дополнить раздел 5. Можно создать отдельную таблицу для помощи в выявлении, определении и отслеживании требований. Обратите внимание, что если новое требование идентифицируется после того, как утвержден документ с бизнес-требованиями, то новое требование необходимо внести в раздел 10.1 Дополнения (новые требования). 6.     После того, как были внесены изменения в документ, и вы готовы его завершить, убедитесь, что Вы обновили оглавление документа. 7.     Составьте карту рассмотрения документа и его утверждений теми лицами, которые были определены в разделе с заинтересованными сторонами. 8.     Из-за того, что документ с бизнес-требованиями является динамичным, после того, как менеджер проекта получает согласованный документ, все дополнительные, измененные или отмененные требования вносятся в 10 раздел. 9.     Если вносятся изменения в документ, то необходимо обновить раздел с историей обновлений документа. 10.  Документ с описанием бизнес-требований будет храниться вместе с другими документами проекта и поддерживаться в соответствии с политикой хранения документов.
Расширение прав и возможностей. Масштабируемость.	Данный шаблон предоставляется в качестве ориентира для сбора базовой информации, необходимой для успешного формирования документа с описанием бизнес-требований. Руководители проекта имеют право использовать этот шаблон по мере необходимости для сбора каких-либо конкретных требований предполагаемого проекта. Количество деталей, которые содержит документ, зависит от размера и сложности проекта. В зависимости от проекта или потребностей бизнеса, требования могут быть добавлены, но не могут быть удалены.

Информация по документу и согласование документа

История версий
№ версии	Дата создания	Кем пересмотрена версия	Причина для изменений
1.0	9/17/09	Иванов Петр	Рассмотрение проектным офисом

Этот документ был утвержден в качестве официального документа с бизнес-требованиями для проекта «<имя проекта>», и точно отражает текущее понимание бизнес-требований. После утверждения этого документа, изменения требований будет регулироваться через процесс управления изменениями, включая анализ последствий (impact analysis), проходя стадии рассмотрения и согласования.

Согласование документа
Имя утверждающего	Проектная роль	Подпись/Электронная подпись	Дата

Оглавление документа

1. Назначение документа. 1
2. Ресурсы для создания документа. 1
3. Словарь терминов.. 1
4. Обзор проекта. 1

4.1 Обзор проекта и предпосылки. 1

4.2 Зависимости проекта. 1

4.3 Заинтересованные стороны.. 1

1. Основные допущения и ограничения. 2

5.1 Основные допущения и ограничения. 2

1. Сценарии использования/Варианты использования (Use Cases) 2

6.1 Диаграмма вариантов использования. 2

6.2 Изложение фактов по варианту использования. 3

1. Бизнес-требования. 5
2. Приложения. 7

8.1 Приложение A – Потоки бизнес-процессов. 7

8.1.1 Диаграммы «Как Есть» (As Is) 8

8.2 Приложение B – Каталог бизнес-правил. 10

8.3 Приложение C- Модели. 10

8.4 Матрица трассировки/отслеживания требований (Traceability Matrix) 10

8.5 Инструкция описания вариантов использования. 10

1. Назначение документа

Этот документ определяет высокоуровневые требования <введите имя бизнес-линии, внутренней организации, заинтересованной стороны> этого проекта. Документ будет использоваться в качестве основы для следующих видов деятельности:

• Создание дизайнов Решения;
• Разработка плана тестирования, скриптов тестирования и сценариев тестирования;
• Определение критериев завершенности проекта;
• Оценка успешности проекта.

1. Ресурсы для создания документа

Имя	Бизнес-подразделение	Роль
<Идентифицируйте все заинтересованные стороны и ресурсы, которые будут вовлечены в процесс сбора требований>

1. Словарь терминов

Термин / Сокращение	Определение
<Определите термины и сокращения, которые используются в данном документе >

1. Обзор проекта

4.1 Обзор проекта и предпосылки

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

4.2 Зависимости проекта

<Перечислите любые связанные проекты, которые затрагивают целиком или частично Ваш проект, или которые имеют зависимости от этого проекта.>

4.3 Заинтересованные стороны

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

	Заинтересованные стороны
1.
2.
3.

1. Основные допущения и ограничения

5.1 Основные допущения (предположения) и ограничения

#	Допущения (предположения)
	Перечислите любые допущения, на которых основаны требования
#	Ограничения
	Перечислите любые ограничения, на которых основаны требования

1. Сценарии использования/Варианты использования (Use Cases)

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

6.1 Диаграмма вариантов использования

6.2 Изложение фактов по варианту использования

<Каждый вариант использования должен быть задокументирован с помощью этого шаблона. Смотрите инструкцию для описания вариантов использования>

ID Варианта использования:
НаименованиеВарианта использования:
Кем создан:		Кем в последний раз изменен:
Дата создания:		Дата последнего изменения:

Акторы:
Описание:
Предварительные условия:
Постусловие:
Нормальный ход событий:
Альтернативный ход событий:
Исключения:
Содержит:
Приоритет:
Частота использования:
Бизнес-правила
Специальные требования:
Предпосылки (предположения):
Примечания и вопросы:
Графическое представление варианта использования

Пример заполненного варианта использования:

ID Варианта использования:	1
НаименованиеВарианта использования:	Просмотр интерактивной карты кампуса
Кем создан:	Иванов Петр	Кем в последний раз изменен:
Дата создания:	19/04/2015	Дата последнего изменения:

Акторы:	Пользователь
Описание:	Этот вариант использования описывает основной способ использования интерактивной карты кампуса. Пользователь через браузер получает доступ по соответствующему URL и взаимодействует с представленной функциональностью.
Предварительные условия:	Веб-браузер открыт и получен доступ к интерактивной карте кампуса через URL.
Постусловие:	Пользователь переходит с интерактивной карты кампуса на веб-сайт.
Нормальный ход событий:	1.     Открывается браузер; 2.     Переход по URL карты кампуса; 3.     Взаимодействие с картой кампуса при помощи доступной функциональности.
Альтернативный ход событий:	Отсутствует
Исключения:	Отсутствуют
Содержит:
Приоритет:	Высший
Частота использования:	Одно использование на одно посещение.
Бизнес-правила	TBD
Специальные требования:	·         Доступ 24/7 · Время отклика сопоставимо с общими картографическими решениями (например, карты Google)
Предпосылки (предположения):
Примечания и вопросы:
Графическое представление варианта использования

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

Следующие разделы документа представляют различные бизнес-требования данного проекта.

Тип требования	ID – Префикс	ID – Номер	Функция – Характеристика — Требование	Ссылка на вариант использования	??	??	??	??	Комментарии
	Требования бизнес-пользователей
	f	01-001
	f	01-002
	f	01-003
	f	01-004
	f	01-005
	f	01-006
	f	01-007
	f	01-008
	Требования к отчетности
	f	02-001
	f	02-002
	f	02-003
	f	02-004
	f	02-005
	f	02-006
	f	02-007
	f	02-008
	Требования к правам доступа пользователей и безопасности
	f	03-001
	f	03-002
	f	03-003
	f	03-004
	F	03-005
	f	03-006
	f	03-007
	f	03-008
	Требования к уровню сервиса и к производительности
	f	04-001
	f	04-002
	f	04-003
	f	04-004
	f	04-005
	f	04-006
	f	04-007
	f	04-008
	Требования к масштабируемости
	f	05-001
	f	05-002
	f	05-003
	f	05-004
	f	05-005
	f	05-006
	f	05-007
	f	05-008
	Требования к поддержке и техническому обслуживанию
	f	06-001
	f	06-002
	f	06-003
	f	06-004
	f	06-005
	f	06-006
	f	06-007
	f	06-008

1. Приложения

8.1 Приложение A – Потоки бизнес-процессов

<Опишите текущий существующий процесс документооборота используя диаграмму потоков (Visio Flowcharts) и дайте подробное описание>

8.1.1 Диаграммы «Как Есть» (As Is)

<Вставьте сюда диаграмму «Как Есть» (если это применимо к проекту)>

8.2.2 Диаграммы «Как Будет» (To Be)

< Вставьте сюда диаграмму «Как Будет» (если это применимо к проекту)>

8.2 Приложение B – Каталог бизнес-правил

<Инструкции: используйте следующий шаблон для каждого бизнес-правила>

Наименование бизнес-правила	<Имя должно дать вам хорошее представление о теме бизнес-правила>
Идентификатор	<Определите уникальный идентификатор.> Например: BR1
Описание	<Опишите детали бизнес-правила.> Например: «Весь труд рабочих отслеживается, составляется отчет и выставляется счет в 30 минутных интервалах»
Пример	<(Необязательное поле) Пример использования бизнес-правила>
Источник	<Источник правила. Например, заинтересованная сторона>
Связанные бизнес-правила	<Список связанных правил, для обеспечения процесса трассировки>

 

8.3 Приложение C- Модели

<Вставьте сюда модели>

8.4 Матрица трассировки/отслеживания требований (Traceability Matrix)

<Вставьте сюда матрицу трассировки требований>

8.5 Инструкция описания вариантов использования

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

Наименование поля Варианта использования	Определение
ID Варианта использования	Присвойте каждому варианту использования уникальный числовой идентификатор в иерархическом формате: X.Y. Связанные варианты использования могут быть сгруппированы в иерархию. Функциональные требования могут отслеживаться по меченным Вариантам использования.
Наименование Варианта использования	Ориентированное на результат имя в краткой форме для Варианта использования. Оно должно отражать задачи, которые пользователь может выполнить, используя систему. Включите в наименование глагол и существительное. Вот некоторые примеры: · Просмотреть информацию по номеру заказа. · Вручную пометить гипертекст источника и установить ссылку на целевой контекст. · Заказать компакт-диск с обновленной версией ПО.
Кем создан	Содержит имя человека, который изначально задокументировал этот Вариант использования
Дата создания	Введите дату, когда был задокументирован изначально Вариант использования
Дата последнего изменения	Введите дату последнего обновления Варианта использования
Кем в последний раз изменен	Содержит имя человека, который внес последние изменения.
Актор	Введите лицо или другие субъекты, которые являются внешними по отношению к системе ПО, и которые взаимодействуют с системой в соответствии с вариантом использования в рамках выполнения задач. Различные акторы часто соответствуют различным классам пользователей или ролям, идентифицируя их с группой пользователей заказчика, которые будут использовать продукт. Имя акторов, которые будут выполнять этот Вариант использования.
Описание	Дайте краткое описание причины и результатов этого Варианта использования, или приведите высокоуровневое описание последовательности действий и результата выполнения Варианта использования.
Предварительные условия	Перечислите мероприятия, которые должны состояться, или любые условия, которые должны выполниться до того, как вариант использования будет запущен. Количество предварительных условий. Примеры: · Идентификатор пользователя должен пройти проверку подлинности. · Компьютер пользователя имеет достаточное количество свободной памяти для запуска задачи.
Постусловие	Опишите состояние системы по завершении исполнения варианта использования. Количество постусловий. Примеры: · Документ содержит только допустимые теги в SGML. · Цена товара в базе данных была обновлена с новым значением.
Нормальный ход событий	Предоставьте подробное описание действий пользователя и реакции системы, которые будут проходить во время выполнения варианта использования в нормальных, ожидаемых условиях. Это последовательность действий внутри диалогового окна, в ходе которой будет достигнута цель, которая указана в названии варианта использования и в его описании. Это описание может быть написано как ответ на гипотетический вопрос: «Как мне выполнить задачу, которая указана в имени Варианта использования?». Лучше всего это делать в виде нумерованного списка действий, которые выполняет актор, чередуя их с реакциями системы на производимые действия.
Альтернативный ход событий	Задокументируйте другие, разумные сценарии использования, которые могут иметь место в пределах данного варианта использования. Обозначьте альтернативный ход событий и опишите какие-либо различия в последовательности шагов, которые могут потребоваться. Укажите номер каждого альтернативного хода, используя ID варианта использования в качестве префикса, а затем добавьте к номеру префикс «AC», чтобы обозначить «альтернативный ход событий». Например: X.Y.AC.1
Исключения	Опишите любые предполагаемые условия возникновения ошибок, которые могут возникнуть во время выполнения варианта использования, а также определите, как система должна отреагировать на эти условия. Также опишите, каким образом система должна реагиовать, если вариант использования завершится по какой-то непредвиденной причине. Номер каждого исключения формируется при помощи ID Варианта использования и специального префикса «EX». Пример: X.Y.EX.1
Содержит	Перечислите любые другие варианты использования, которые вызываются этим вариантом использования. Общие функциональные возможности, которые появляются в нескольких отдельных вариантах использования могут быть включены в отдельный вариант использования.
Приоритет	Укажите относительный приоритет реализации функциональности, которая необходима для того, чтобы этот вариант использования был выполнен. Используемая схема приоритетов должна быть такой же как та, которая используется в спецификации требований к программному обеспечению.
Частота использования	Оцените частоту использования данного Use Case за единицу времени.
Бизнес-правила	Перечислите любые бизнес-правила, которые влияют на этот вариант использования.
Специальные требования	Идентифицируйте любые дополнительные требования, такие как нефункциональные требования, для варианта использования, которые необходимо будет рассмотреть в ходе проектирования и реализации решения. Они могут включать в себя требования к производительности или атрибуты качества.
Предпосылки (предположения)	Перечислите какие-либо допущения, которые были сделаны при анализе, что привело к принятию данного варианта использования в описании продукта и написанию подробной информации по варианту использования.
Примечания и вопросы	Перечислите любые дополнительные комментарии по данному варианту использования или любые нерешенные вопросы, или TBD лист (то, что будет определено позднее). Определите, кто будет заниматься каждым отдельным вопросом или проблемой и к какому сроку все пункты должны быть разрешены.

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

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

Источник материала: https://systems.education/biz-req и https://systems.education/biz-req-dev

Роль Бизнес-требований (БТ)

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

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

Версия 3 BABOK Guide определяет требования таким образом:

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

Для формулирования требования потребность нужно поместить в какой-то контекст. Например потребность «Люди испытывают ежедневную потребность в пище» слишком общая. Если ее поместить в контекст морского путешествия, то требование становится уже более осмысленным: «Продукты питания, используемые в рационе моряков, должны сохранять пригодность для употребления в пищу в течение, как минимум, 30 дней при температуре до +30оС и высокой влажности, поскольку моряки длительное время вынуждены обходиться без поставок продовольствия».

Способы выполнения требования могут быть разными и они называются решениями.

Потребности, требования, решения, контекст

• Голубой блок обозначает контекст проекта и его элементы.
• Красный блок в левой части — потребности бизнеса и стейкхолдеров.
• Желтый блок в центре — бизнес-требования, требования стейкхолдеров и требования к решению.
• Зеленый блок справа — решения, удовлетворяющие требования (бизнес-процессы и информационные системы).

Потребности бизнеса, подлежащие удовлетворению в конкретном контексте, отражаются в бизнес-требованиях.

Решением для бизнес-требования обычно является бизнес-процесс или организация, выполняющая множество бизнес-процессов.

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

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

Пример определения бизнес-требования на основе анализа потребности

Потребность — «Торговой компании необходимо постоянно иметь в наличии или оперативно получать нужные товары в нужном количестве.»

Если бизнес-модель компании предполагает поддержание товарных запасов на складе, то бизнес-требование можно сформулировать так:

Для поддержания нужных товарных запасов на складах компании, их необходимо регулярно (BR-INV-01) пополнять через формирование заказов поставщикам.

Размер поддерживаемого запаса каждого товара должен определяться, исходя из оптимизации затрат и минимизации рисков упущенной прибыли (BR-INV-02).»

В тексте этого требования есть две ссылки: BR-INV-01 и BR-INV-02. Здесь BR означает «бизнес-правило» (Business Rule), а INV — Inventory (запас). Это ссылки на бизнес-правила, определяющие то, с какой именно регулярностью нужно пополнять запасы, и каков алгоритм расчета оптимального товарного запаса.

Бизнес-правило — один из типичных артефактов, сопровождающих бизнес-требования.

Артефакты бизнес-анализа, сопровождающие бизнес-требования

По мере определения бизнес-требований появляются:

1. Доменные модели — высокоуровневые информационные модели предметной области.
2. Глоссарий предметной области.
3. Модели состояния объектов управления: на этом этапе мы определяем, какими объектами мы хотим управлять, и какие состояния нас интересуют (или какие состояния мы хотим отслеживать).
4. Метрики и показатели этой деятельности, которые говорят нам о том, что важно для бизнеса и как мы оцениваем то, насколько хорошо или плохо, лучше или хуже выполняется его деятельность.
5. Бизнес-правила: описания применяемых в данной компании алгоритмов, нормативов, ограничений, проверок, и политик.

 Немного слов про бизнес-правила

Как правильно описывать бизнес-правила?

1. Бизнес-правило должно быть сформулировано на языке бизнеса. В описании бизнес-правил не должны использоваться технические термины. Язык написания бизнес-правил должен быть понятным представителю бизнеса, не являющимся IT-специалистом. После описания бизнес-правил, постарайтесь абстрагироваться от своих технических знаний, поставьте себя на место представителя бизнеса, руководителя компании, для который вы разрабатываете продукт. Понятен ли вам написанный документ? Не содержит ли документ технических терминов, указания систем и языков программирования?
2. Бизнес-правило должно описывать правило бизнеса, а не работу системы. Описание бизнес-правил должно содержать те требования бизнеса, которые должна решить система, но без описания работы системы. Например, у бизнеса есть правило: «Отслеживать время прихода и ухода сотрудников на рабочее место». Бизнес-правило не должно содержать описания, как достичь соблюдения данного правила: будет ли сотрудник записываться в журнал прихода и ухода, или на входе будет стоять автоматическая пропускная система, которая будет фиксировать время.
3. Бизнес-правило должно описывать ограничения: какие операции не могут быть выполнены. Ограничительные бизнес-правила могут определять ограничения пользователей. Например: “В полис ОСАГО страховщик может вписать не более 5-ти водителей”; «Оформить заказ-онлайн может только клиент компании».
4. Бизнес-правило подчиняется бизнесу: принять, изменить, отменить. Представители бизнеса могут изменять бизнес-правила, вносить поправки или отменять.

Рассмотрим несколько примеров бизнес-правил и требований к системе

Бизнес-правило	Требование к системе
Постоянный посетитель библиотеки может отложить для себя до 10 книг.	Посетитель, имеющий карточку в библиотеке; посещающий библиотеку не менее 1 раза в месяц является постоянным. Постоянный посетитель должен иметь возможность отложить для себя 10 книг.
Клиент компании может оформить заказ с оплатой курьеру.	Клиент компании-пользователь, имеющий учетную запись в интернет-магазине компании. Для оформления заказа, пользователь должен быть авторизован в системе. Пользователь, должен иметь возможность оформить заказ. Заказ может быть оформлен: с доставкой по указанному адресу; с оплатой наличными при получении; с оплатой банковской картой при получении.

Требования стейкхолдеров

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

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

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

1. Автоматически рассчитывать заказ по каждому товару с использованием определенного алгоритма (здесь прозвучит то же самое бизнес-правило, которое упоминалось в бизнес-требовании). Почему автоматически? Потому что мне надо на 4 складах поддерживать 3000 товарных позиций, поступающих от 100 поставщиков — это невозможно или крайне сложно обрабатывать вручную.
2. По любой позиции автоматически рассчитанного заказа видеть то, как именно была посчитано это значение и почему оно именно такое — алгоритм может не учитывает какие-то известные мне нюансы. Например, ожидаемое значительное повышение или снижение продаж.
3. Менять количество в автоматически рассчитанном заказе — в конечном счете за заказ отвечаю я, а не система. Система не может учесть всё, и если я считаю нужным поменять заказанное количество, у меня должна быть возможность это сделать.
4. Смотреть для проверки не на все 3000 позиций, а только на те, где расчеты системы могут быть вызвать сомнения. Например, недостаточная история продаж, высокая волатильность продаж или другие подобные факторы.

Примерно так будет рассказывать нам живой человек. «Пользовательская история» (User Story) — естественная форма представления требований стейкхолдеров, имеющая формат <роль> <задача> <нужная возможность>.

Например:

Как специалисту, отвечающему за поддержание запасов, для формирования заказов поставщикам мне нужно:

1. Автоматически рассчитывать заказ по каждому товару с использованием BR-INV-02;
2. по любой позиции заказа иметь возможность посмотреть детали расчета и
3. вручную изменить заказываемое количество,
4. видеть отдельно те позиции заказа, по которым, возможно, требуется моя корректировка (BR-INV-03)

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

• Карты стейкхолдеров (показывают, кто участвует в процессах)
• Модели и другие описания процессов
• Варианты использования (Use Cases)
• Образцы данных, с которыми работают стейкхолдеры (помогают понять ситуацию и потребности стейкхолдеров)

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

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

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

В наглядном виде модель выявления требований представлена на схеме:

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

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

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

Из БТ вытекают критерии приемки и именно на их основе производится оценка результатов разработки ИТ-решения.

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

Кроме того, бизнес-требования в Agile — это ключевой инструмент Product Owner для управления бэклогом продукта и ведения переговоров со стейкхолдерами.

Какие бывают бизнес-требования?

Согласно концепции Six Sigma, бизнес-требования — это критичные активности предприятия, подлежащие выполнению для достижения целей организации, вне зависимости от конкретного решения.

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

• Определением значимых характеристик продуктов или услуг.
• Распознаванием и обработкой событий.
• Принятием решений (своевременность, правильность).
• Сбором, обработкой, хранением и предоставлением информации.
• Обеспечением возможности выполнения действий (субъект, действие, объект, время, условия, способ).
• Предотвращением возможности выполнения действий (субъект, действие, объект, время, условия, способ

Ниже приведены примеры бизнес-требований по видам критичных активностей.

Вид БТ: Значимые характеристики продуктов или услуг

Примеры БТ:

• Скорость обслуживания — очередь на кассе должна быть не длиннее 4 покупателей.
• Своевременность доставки — клиент должен получить пиццу горячей и не умереть ожидая ее.
• Простота получения услуги — оформление предварительно одобренного кредита должно завершаться за одно посещение клиента.

Вид БТ: Распознавание и обработка событий

Примеры БТ:

• Банк должен своевременно получать оповещения о сбоях в работе банкоматов.
• К моменту начала этапа работ, все нужные материалы и оборудование должны находиться на объекте строительства и быть готовыми к использованию.
• Сотрудники должны быть своевременно проинформированы о назначенных им задачах.

Вид БТ: Принятие решений

Примеры БТ:

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

Вид БТ: Сбор, обработка, хранение и предоставление информации

Примеры БТ:

• С момента обнаружения дефекта и до его полного устранения должна регистрироваться и храниться следующая информация.
• Инвестиционный банк в конце каждого рабочего дня должен направлять Регулятору информацию о…
• Для принятия решений об участии в тендере необходимы результаты предварительной оценки себестоимости проекта.

Вид БТ: Обеспечение возможности выполнения действий

Примеры БТ:

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

Вид БТ: Предотвращение возможности выполнения действий

Пример БТ:

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

 Проблемы в бизнес-требованиях

Можно выделить несколько типичных признаков проблем с бизнес-требованиями.

• Неконкретность (слишком абстрактная формулировка)
• Невозможность проверки (нет понимания, что является индикатором выполнения требования)
• «Магические» числа (приведены какие-то необоснованные данные: «время обработки заявки 14 минут»)
• Непонятная польза (не написано, для чего делаем то, что делаем; действительно ли это необходимо)
• Избыточная детализация (зачастую делает требование слишком жестким и нечитаемым)
• Невыполнимость (например, требование «обеспечить 100%-ую достоверность данных». Для чего это требование? Почему возникают недостоверности? С этой проблемой можно как-то бороться или это просто факт?)
• Несогласованность (противоречивость; с одной стороны Покупатель хочет найти продукт с наилучшими качествами по наименьшей цене, а с другой — Продавец хочет стимулировать покупку продуктов, приносящих наибольшую прибыль)
• Нерелевантность (приведено требование, которое вообще не понятно, какое отношение имеет к данному проекту)
• Привязка к конкретному решению, в том числе — конкретный бизнес-процесс

Примеры некорректных бизнес-требований

Обеспечить высокое качество обслуживания — Как проверить, что качество обслуживания высокое?

1. Сократить среднее время обработки заказа до 14 минут — Почему до 14 минут, чем это обосновано? А почему не до 1 минуты? Какую пользу принесет сокращение времени обработки заказа?
2. Обеспечить 100% достоверность учетных данных — Как мы узнаем какая достоверность? Как можно определить, что данные достоверны? В результате чего возникает недостоверность? С этим реально можно что-то сделать? Выполнимо ли данное требование?
3. Гарантировать правильность принимаемых решений — Что выступает гарантом? Это выполнимо?
4. Внедрить ERP — Кому и зачем это нужно? В чем проблема?

Типовые ловушки аналитика

Проблемы с требованиями, как правило, возникают, когда аналитик попадает в одни и те же типовые ловушки. Вот основные ловушки аналитика при работе с бизнес-требованиями:

• Формальность — «пишу, потому что надо здесь что-то написать».
• Узкие рамки анализа — не рассматриваем ничего, что выходит за рамки проекта.
• Превращение в аудит — выясняем все обо всем «на всякий случай».
• Превращение метода в цель — строгое следование определенному шаблону с превращением средств в цель и потерей основной цели проекта.

Что можно сделать с каждой из этих ловушек?

Ловушка	Описание	Решение
Формальность	«Пишу, потому что надо здесь что-то написать»	Ставить себя на место читателя (необходимо понимать, что и для кого мы пишем).
Узкие рамки анализа	Фокусировка только на том, что относится к проекту, т.е. не рассматриваем ничего, что выходит за рамки проекта	Анализировать область шире, чем те рамки, которые хотим установить для проекта.
Превращение в аудит	«На всякий случай» выясняем все обо всем	Постоянно спрашивать себя: «как это связано с проектом?»
Превращение метода в цель	Строгое следование определенному шаблону с превращением средств (канва бизнеса, бизнес-процессы, стейкхолдеры) в цель и потерей основной цели проекта	Задать себе вопрос: «можно ли обойтись без э

Документирование бизнес-требований

В практике бизнес-аналитика присутствует два основных подхода документирования требований:
1. Монолитно

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

2. Дробно

• Каждое требование описывается отдельно.
• Каждому требованию присваивается уникальный идентификатор.
• Возможна трассировка к конкретному бизнес-требованию.

Шаблон монолитного описания БТ

Карл Вигерс в своей книге «Разработка требований к программному обеспечению. Руководство» предлагает хороший шаблон описания БТ монолитом в рамках документа Scope and Vision (рамки и видение). В этом документе выделяется раздел Бизнес-требования, который включает в себя:

• Контекст.
• Описание возможности.
• Бизнес-цели.
• Метрики успешности.
• Образ результата (Vision).
• Деловые риски.
• Предположения и зависимости бизнеса.

Советы Вигерса по описанию БТ

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

Шаблон дробного описания БТ

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

• Уникальный идентификатор.
• Краткое описание.

2. Определение, развернутое объяснение, что из себя представляет БТ.
3. Источник, откуда это требование взялось.
4. Зависимости, если они есть между другими требованиями.
5. Обоснование, краткое пояснение мотивации.
6. Комментарий, любые пояснения. В приведенном ниже примере представлено описание диаграммы состояний.

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

Определение

Путаница в терминологии возникает по трем основным причинам:

1. Обычной практикой является обозначение целей или ожидаемых выгод как бизнес-требований.
2. Люди, как правило, используют данный термин для обозначения характеристик продукта, системы, программного обеспечения, которые предполагается создать.
3. Широко распространенная модель утверждает, что эти два типа заявок отличаются только уровнем детализации или абстракции — где бизнес-требования являются высокоуровневыми, часто расплывчатыми и разлагаются на подробные заявки к компоненту.

Такого недоразумения можно избежать, если признать, что данное понятие не является целями, а скорее отвечает им (то есть обеспечивает ценность) при их удовлетворении. Бизнес-требования не разлагаются в продукт, системы и программное обеспечение. Скорее, все происходит наоборот. Продукты и их заявки представляют собой ответ на бизнес-требования — предположительно, чтобы удовлетворить их. Данное понятие существует в производственной среде и должно быть обнаружено, тогда как спросы к продукту определены человеком. Требования к бизнес-плану не ограничиваются существованием высокого уровня, а должны быть сведены к деталям. Независимо от величины детализации, заявки всегда обеспечивают ценность, когда удовлетворены.

Обновление продукта

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

Акценты процесса

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

Обзор

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

Состав заявок

Требования бизнес-процесса часто включают в себя:

1. Контекст, область и фон, в том числе и причины изменений.
2. Ключевые заинтересованные стороны, у которых есть требования.
3. Факторы успеха для будущего или целевого состояния.
4. Ограничения, налагаемые бизнесом или другими системами.
5. Модели и анализ процессов, часто использующие блок-схемы для представления всего «как есть».
6. Логическая модель данных и ссылки на словарь.
7. Глоссарии деловых терминов и местный жаргон.
8. Диаграммы потоков данных для иллюстрации того, как они проходят через информационные системы (в отличие от блок-схем, изображающих алгоритмический поток бизнес-операций).

Роли

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

Полнота

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

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

Прообраз

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

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

Разработка

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

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

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

Примеры оформления

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

Трудности

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

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

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