Мне кажется, что вопрос технологии в том, кто выполняет роль архитектора решения. По моему опыту, если нет выделенного архитектора, а это во всех проектах, кроме достаточно крупных, — архитектуру определяет аналитик, как минимум верхнеуровнево. В таком случае технологический процесс описать нужно. Например, мы сегодня варим литр борща, но знаем, что завтра его надо будет сварить центнер. Для рубки овощей на литр подойдёт и тупой нож, а вот на центнер уже нужна овощерезка. Чтобы не тратить усилия на поиск/изготовление ножа, а завтра на поиск/изготовление овощерезки иногда имеет смысл задать требования к процессу: овощи надо рубить овощерезкой. Можно, конечно, написать "резка овощей должна быть масштабируемой по объёму", но это просто перекладывание функций архитектора на исполнителя, который, весьма вероятно, и не видит общей картины, не знает целей и не должен в это вникать — у него таких борщей и салатов в день по 10 штук от 5 аналитиков. Да и даже это — уже требование к технологии.

Коллеги, а это точно оффициально, чет их сайт оставляет желать лучшего, сори если кого то обидел

Подскажите, что не понравилось/было непонятно?

Не не, ну я в плане, что это точно от тинькоф?)

Да, я поняла, поэтому и спрашиваю, что конкретно смутило) можно в личку

Отвечала на poll (ответы 1 и 3), исходя из:
1) Борщ - новый объект в ИС, которому соответствует некоторая сущность предметной области. У сущности есть некие атрибуты, значимые для бизнеса/пользователя = требования к потребительским качествам борща
2) "Приготовить" - значит создать и/или довести до определенного состояния. За этим стоит некоторая последовательность технологических операций, которые соответствуют звеньям БП для данного объекта

а если будет задача «разработать мобильное приложение для хранения рецептов»?

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

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

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

"задание" тоже не звучит как что-то крупное, однако

теперь надо сходить к программистам, узнать, что у них

если постановка задачи включает в себя все это, то где и когда происходит проектирование?

если кому интересно покопать эту тему — пишите в личку, буду делать статью/вебинар

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

мдааа, залез специально покопаться, а что же всё-таки понимается под "постановка задачи", что-то чётко сформулированного определения, которое согласовывалось со смыслом фразы, не нашлось, Но тем не менее, что-то нарисовалось:

https://ozlib.com/823112/informatika/analiz_trebovaniy_postanovka_zadachi
https://ozlib.com/803683/ekonomika/postanovka_zadachi#746

вот две статьи, показавшиеся мне интересными по этому вопросу. Исходя из них получается, что постановка задачи - это описание контекста, вокруг непосредственно самой реализации бизнес-процесса. Хотя фраза "содержание функций обработки входной информации при решении задачи;" вроде как намекает, как раз на описание непосредственно самого тех.процесса.
ЗЫ: Понравился перевод на английский, оказывается Постановка задачи в английском варианте звучит, как problem definition, т.е. определение проблемы! Если бы назвали этот этап так, то, на мой взгляд, неопределённости понимания термина было бы гораздо меньше.

так что, Денис, если тебе удастся внести большую определённость в понимание этого этапа, а лучше даже на уровне его именования - коллеги-аналитики оценят и даже могут сказать спасибо!

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

Цель — это конечный желаемый результат.
Задача — проблемная ситуация с явно и заранее заданной целью.
говорится в https://www.marketch.ru/marketing_marginalia/tsel-i-zadacha-v-chem-otlichie/

Цель – это по сути результат (продукт), который мы хотим получить.
Задачи – те конкретные действия, которые необходимо выполнить для достижения цели.
говорится в ответах тут https://yandex.ru/q/question/computers/v_chiom_raznitsa_mezhdu_tseliami_i_d89e5db2/?utm_source=yandex&utm_medium=wizard&answer_id=2fc1202e-0c10-4048-87bf-a1c17c7774cf#2fc1202e-0c10-4048-87bf-a1c17c7774cf

то есть если с "целью" вроде определённость есть, то вот с "задачей" - увы.

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

UPD2: Что я вижу у Корнипаева в примере?

Цель: сократить операционные затраты на обработку и хранение документов на 10%.
Для достижения этой цели планируется решить следующие задачи:
* - снизить стоимость печати одной копии документа на 20%;
* - сократить среднее количество печатных копий документа до 2;
* - снизить затраты на хранение документов на 5%.

ну и в чём тут концептуальное различие между целью и задачами? Я лично вижу тут цель и подцели. Если в предложении заменить "решить следующие задачи" на "достичь следующие подцели" суть не изменится. Или изменится? Может в рамках аналитики "цель" - это лишь исключительно конечный результат, а задачи - промежуточные цели. Но тогда почему в "постановка задачи" слово "задача" имеет смысл проблемы? Многозначность слов, используемых в терминах - зло. :(

В моей реальности Задание ~ ТЗ ~ SRS (со всеми Vision, Scope, etc). Навевает что-то вотерфольно-госзакупочное. Тогда как "постановка задачи" - артефакт рутинного анализа требований в ходе проекта.

Не только к методическому, оно обычно описывается и в требованиях к ИиЛО, и к ПО, и к МатО (если уместно)