👋 Продолжаем тему требований к ПО и сегодня поговорим про бизнес-требования.
Бизнес-требования — это описание бизнес-целей и возможностей, ради которых нужно создать или доработать существующий процесс.
Это достаточно верхнеуровневый тип требований, которые выдвигает заказчик для дальнейшей проработки. В свою очередь, получив такое требование, аналитик находит возможности для достижения обозначенного в требовании результата – то есть формирует требования к системе (функциональные и нефункциональные).
Рассмотрим на следующем примере:
🔸 Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.
В этом бизнес-требовании представлена информация об интересах бизнеса в решении. Иными словами, бизнес хочет, чтобы:
☝️ комьюинити аналитиков в сообществе расширялось;
✌️ узнаваемость бренда повышалась.
Для достижения этих целей можно придумать множество концепций решения.
Например:
🔹организовать масштабную конференцию для специалистов,
🔹раздавать мерч с логотипом компании
(ведь конференция и мерч – это тоже продукты компании),
🔹придумать сайт,
🔹приложение,
🔹бота в телеграм
и так далее.
Иными словами, бизнес-требования предоставляют информацию о результате, который необходимо достичь. А путь до этого результата (то есть концепцию решения) спроектирует проектная команда: аналитик, дизайнер и разработчик.
В некоторых случаях, помимо отображения ожидаемого результата, бизнес-требование содержит конкретную метрику этого результата.
Например:
🔸 повысить количество студентов на курсе на 13% засчёт увеличения узнаваемости бренда
🔸 увеличить количество положительных отзывов на 20% о бренде на популярных платформах
и так далее.
В этом случае результат внедряемых измерений можно измерить конкретным значением и достижение этого значения и будет фактом успешности решения.
Бизнес-требования — это описание бизнес-целей и возможностей, ради которых нужно создать или доработать существующий процесс.
Это достаточно верхнеуровневый тип требований, которые выдвигает заказчик для дальнейшей проработки. В свою очередь, получив такое требование, аналитик находит возможности для достижения обозначенного в требовании результата – то есть формирует требования к системе (функциональные и нефункциональные).
Рассмотрим на следующем примере:
🔸 Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.
В этом бизнес-требовании представлена информация об интересах бизнеса в решении. Иными словами, бизнес хочет, чтобы:
☝️ комьюинити аналитиков в сообществе расширялось;
✌️ узнаваемость бренда повышалась.
Для достижения этих целей можно придумать множество концепций решения.
Например:
🔹организовать масштабную конференцию для специалистов,
🔹раздавать мерч с логотипом компании
(ведь конференция и мерч – это тоже продукты компании),
🔹придумать сайт,
🔹приложение,
🔹бота в телеграм
и так далее.
Иными словами, бизнес-требования предоставляют информацию о результате, который необходимо достичь. А путь до этого результата (то есть концепцию решения) спроектирует проектная команда: аналитик, дизайнер и разработчик.
В некоторых случаях, помимо отображения ожидаемого результата, бизнес-требование содержит конкретную метрику этого результата.
Например:
🔸 повысить количество студентов на курсе на 13% засчёт увеличения узнаваемости бренда
🔸 увеличить количество положительных отзывов на 20% о бренде на популярных платформах
и так далее.
В этом случае результат внедряемых измерений можно измерить конкретным значением и достижение этого значения и будет фактом успешности решения.