Парето говорит, что не любое

Поэтому то, что во многих проектах описываемые на бумаге требования в принципе не выходят за рамки потребностей (хотелок) - тоже зачастую обоснованно.

давай не путать потребности и хотелки)

потребность — это объективно существующая устойчивая нужда

хотелка — это зачастую фантазия о возможном решении, часто неправильном и ненужном

Мы с тобой расходимся в определении хотелок. Но это не принципиально, чтобы на них останавливаться)

так от них же целиком строятся проекты)

если клиент приходит с хотелками = потребностями, то это даёт отличную основу для успешной аналитической работы

если клиент приходит с хотелками = готовыми решениями, то это выхолащивает роль аналитика до секретаря-референта

проблема же в том, что он хочет не то, что ему нужно)

иначе не было бы этого чата

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

1.  Две головы проверяют друг друга лучше чем одна - саму себя. Вся история "контроля" как дисциплины строится на разделении ролей.
2. Контролер - это более въедливый тип мышления. Если от аналитика нужны нестандартные "творческие" решения, лучше выделять контролера отдельным человеком.

Я, конечно, имел ввиду то, что ты называешь потребностями. Грубо говоря, чем ниже требование тем более оно верифицируемо. Самое верифицируемое требование - это готовое решение (например добавь столбец Description в таблицу Order). Но я часто вижу в проектах, когда есть дока с функциональными требованиями (в стиле "должее быть реализован функционал управления описаниями заказов"), а итоговое решение, если и описывается на бумаге, то может процентов на 20-30 отличаться от реальной реализации.

«Грубо говоря, чем ниже требование тем более оно верифицируемо.»

в силу своей природы или статистически?

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

есть устойчивое представление, что в силу природы

Видимо это и есть твой вариант ответа про природу

например, часто говорят, что высокоуровневые требования более абстрактны

Ну тут проверить можно, но будет это выглядеть примерно так:
1) Ребенку исполнилось 18? Тогда условие выполнено, то есть из состояния "ребенок" человек перешел в состояние "взрослый"
2) проводить мед осмотр после рождения (для фиксации начального состояния) и по итогам достижения 18  лет провести медосмотр и по итогам сделать заключение сохранилось здоровье или нет

В п.1 при таком уровне формализации,  нужно определение "ребенок" заменить на "субьект".
п.2 не сработает для наследственных заболеваний.

Так и есть. Вообще мышление - верхнеуровнево. Мы просто думаем "хочу сделать шаг вправо", а не думаем как движутся ноги, как на это влияет сила притяжения, какой именно угол считается направлением вправо и т.д.

1) нужно ещё  проверить критерии: жив-не жив, член-не член семьи.
2) нужно определить критерий "здоровья" он должен быть интервальным, так как состояние сразу после рождения и сразу после 18 лет будут однозначно отличаться. Правда это уже вопрос описания кейса, этот критерий должен быть определён там.

Таким образом требования уточняются, на сколько я понимаю.

Здравствуйте! Хотела бы попросить совета по текущей рабочей ситуации: я устроилась в августе в компанию системным аналитиком, это мой первый опыт работы. За все это время я почти не сделала никаких задач, так как меня отправили к одному РП, потом к другому, потом все были перегружены перед праздниками. Сейчас мне поставили задачу: предварительный анализ интеграции систем X и Y. У меня абсолютно нет понимания как должен выглядеть результат этой задачи. Какие шаги должны быть сделаны? Какую документацию нужно запросить и изучить? Я задаю уточняющие вопросы РП, но она очень занята, отвечает размыто, мне это никак не помогает. Пыталась связаться с другим аналитиком для получения помощи, но она 3 дня подряд переносила встречи, а потом перестала отвечать. Я в растерянности.