Если наняли повара и работаем с ним давно, то хватит 1-го пункта

разве понимание "что включить в... " не исходит в данном вопросе из понимания значения "постановка задачи" из преамбулы вопроса?

Если повар несколько раз для нас готовил разное, то хватит Q (quality ,1-й пункт) и последних двух — Time и Price

так контекста не хватает же

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

есть на проектирование уникального

и тд

да, вижу из предыдущих твоих объяснений, что заковыка как раз таки в контексте :)

А почему рецепт не

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

А зачем тебе рецепт, если оговорен результат?

Иногда требования "из чего" тоже ставятся.
Например выбор той или иной библиотеки (из двух схожих по функционалу) или породы дерева если идет производство деревянных конструкций.

Это требования к составу, а не к технологии изготовления

Верно, это я перепутал )))

отвечу как ещё в недавнем прошлом разработчик и выбравший этот пункт ответа. Мне куда важнее последовательность бизнес-процесса, а не описание конечного результата, Так, например, можно описать требования пользователь вводя 2 и 2, должен на выходе получить 4 будет неверной постановкой мне задачи, так как не раскрывает сути ожидаемых операций в текущем процессе: пользователь вводимые числа складывает или умножает? Пример, гипотетический и взятый с потолка.

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

то, что выход = произведению входов, это как раз требования к результату

а перемножать можно по-разному — это и есть технология

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

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

Ну если бы я просила мужа сварить борщ, то рецепт там точно должен был бы быть) И рецепт тут действительно скорее как фреймворк выступает