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