🏎💨 Ну и последние два вопроса КВИЗа (финишная прямая, ребята! )
5️⃣ Укажите бизнес-требование в представленном перечне
Для этого давайте тезисно вспомним, что содержит бизнес-требование:
🔸 описание цели изменения с точки зрения бизнеса (выгода);
🔸 идеально, если содержит метрику успешности (с единицами измерения).
Проанализируем варианты ответов.
Первый вариант. Описание содержит конкретную функциональную возможность внутри решения и совсем не сообщает, какую цель преследует бизнес. Больше похоже на детализацию требования до функциональной возможности.
Второй вариант. Бизнес хочет увеличить количество участников сообщества (это цель), приведена даже метрика успеха – 20% (это мера ожидаемого результата). И даже рассказали про верхнеуровневую концепцию решения в конце. Класс, берём! ☑️
Третий вариант. Непонятно, для каких целей планируем создать платформу. А как мы уже знаем, для достижения бизнес-цели можно найти множество путей с различной стоимостью и затратами.
6️⃣ Укажите функциональное требование в представленном перечне
Начнём со второго варианта. Функциональное требование не должно содержать информацию о том, как именно нужно достичь поставленной цели. Никаких названий полей в требовании быть не должно – разработчик имеет бОльшую экспертизу в написании кода.
☝️ Очень важно, что мы говорим именно про формулировку требований к ПО. Если же мы описываем AS IS-работу системы (бэкенд логика, интеграционное взаимодействие и тд), то детализация до системного уровня зачастую необходима для чистого понимания текущих процессов.
Третий вариант содержит два сложноизмеримых термина: “хорошо” и “недолго”. Функциональные требования должны пониматься однозначно всеми участниками проектной команды, потому что для разных людей есть своё понимание хорошего и быстрого. Не подходит.
Ну а первый вариант достаточно понятно сообщает о том, что необходима функциональная возможность отправки код-пароля на привязанный номера телефона пользователя. Наверняка дальше аналитик опишет ограничения и правила, на основании которых сформируются требования к код-паролю и логике определения номера,но это уже совсем другая история.
Фух, ну и потрудились мы с вами в субботу! Спасибо вам за участие в КВИЗе и за общение в комментариях! 🖤
Мы же здесь не только мемы смотрим, а вообще-то общаемся с единомышленниками и развиваем экспертизу в системном и бизнес-анализе – ЭТО ЛИ НЕ ЧУДО?😊🎉
Отличных выходных, друзья!
5️⃣ Укажите бизнес-требование в представленном перечне
Для этого давайте тезисно вспомним, что содержит бизнес-требование:
🔸 описание цели изменения с точки зрения бизнеса (выгода);
🔸 идеально, если содержит метрику успешности (с единицами измерения).
Проанализируем варианты ответов.
Первый вариант. Описание содержит конкретную функциональную возможность внутри решения и совсем не сообщает, какую цель преследует бизнес. Больше похоже на детализацию требования до функциональной возможности.
Второй вариант. Бизнес хочет увеличить количество участников сообщества (это цель), приведена даже метрика успеха – 20% (это мера ожидаемого результата). И даже рассказали про верхнеуровневую концепцию решения в конце. Класс, берём! ☑️
Третий вариант. Непонятно, для каких целей планируем создать платформу. А как мы уже знаем, для достижения бизнес-цели можно найти множество путей с различной стоимостью и затратами.
6️⃣ Укажите функциональное требование в представленном перечне
Начнём со второго варианта. Функциональное требование не должно содержать информацию о том, как именно нужно достичь поставленной цели. Никаких названий полей в требовании быть не должно – разработчик имеет бОльшую экспертизу в написании кода.
☝️ Очень важно, что мы говорим именно про формулировку требований к ПО. Если же мы описываем AS IS-работу системы (бэкенд логика, интеграционное взаимодействие и тд), то детализация до системного уровня зачастую необходима для чистого понимания текущих процессов.
Третий вариант содержит два сложноизмеримых термина: “хорошо” и “недолго”. Функциональные требования должны пониматься однозначно всеми участниками проектной команды, потому что для разных людей есть своё понимание хорошего и быстрого. Не подходит.
Ну а первый вариант достаточно понятно сообщает о том, что необходима функциональная возможность отправки код-пароля на привязанный номера телефона пользователя. Наверняка дальше аналитик опишет ограничения и правила, на основании которых сформируются требования к код-паролю и логике определения номера,
Фух, ну и потрудились мы с вами в субботу! Спасибо вам за участие в КВИЗе и за общение в комментариях! 🖤
Мы же здесь не только мемы смотрим, а вообще-то общаемся с единомышленниками и развиваем экспертизу в системном и бизнес-анализе – ЭТО ЛИ НЕ ЧУДО?😊🎉
Отличных выходных, друзья!