Конечно, общепринято всё это назвать "аналитик", но там синтеза навалом, а не только анализа. Оторванный от деятельностного синтеза анализ бесплоден! Это requirements engineer, инженер по требованиям, полноценный инженер. Он, кстати должен ещё и reverse engineering делать для using system, предлагать для неё какие-то изменения для согласования интерфейсов с целевой системой, а ещё принимать участие в conceptual analisys (границы ж там размыты, смотри диаграммки в предыдущем обсуждении того же вопроса -- "обучение робототехнике: для какого системного уровня", http://ailev.livejournal.com/1351873.html).
Я ему написал:
[на текст поста]
-- Ваш текст и намерения примерно отражают то, что у меня в голове было на 2012 год, когда я бодро пытался студентам-технологическим предпринимателям МФТИ за семестр донести foundations of systems engineering. Оказалось, что это не так просто.
-- Мы ровно этим на кафедре технологического предпринимательства занимались -- пытались давать разные практики инженерии требований (варианты использования|use cases, например), какой-то степени оптимального разбиения на модули (DSM, design structure matrix), и т.д.. Всё строго на рабочих проектах студентов. Но не случилось у студентов понимания, пока тупо не стали тратить семестр на системное мышление -- чтобы в мозгу начали проворачиваться какие-то мысли про системы. И уж тогда все эти "инженерии требований", "инженерия испытаний", "управление конфигурацией", "инженерия системной архитектуры" и т.д. у студентов как-то разлеглись по полочкам и они это стали осмысленно всё делать. Иначе возня с требованиями остаётся таким же частным специализированным умением, оторванным ото всей остальной деятельности, мыслительным обрубком, не пришитым к связным работам всего проекта. Мы пытались в прошлом году как-то срезать угол, побыстрее взять быка за рога, побыстрее начать "практическую работу руками" с теми же требованиями -- нет, пришлось отползти и дожевать работу с понятием система, хорошо что второй семестр ещё был на исправление ошибок, и мы уже к этому моменту сделали задачи (с задачами дело с пониманием материала идёт бодрее).
[на замечание про гипотезу, что "аналитик" это отдельная от "кодер" специализация]
-- Конечно, инженер требований это не инженер-архитектор и не программист! Эта специализация, например, должна включать некоторый тренинг по коммуникации и даже конфликтологии: ему ж со стейкхолдерами непрерывно нужно общаться и снимать возникающие противоречия-конфликты. Разделение труда углубляется и углубляется. И тут не "гипотеза", а реалии жизни.
[в ответ на вопрос, какие там гуманитарные знания нужно давать инженеру по требованиям и поминание UX]
-- Про гуманитарные знания -- лидерство (ибо представителей стейкхолдеров нужно убалтывать надёжно играть стейкхолдерские роли), коммуникация (ибо непрерывно нужно разговаривать), конфликтология (снимать конфликты стейкхолдеров) и т.д.. UX это просто специфическая штука, равно как и все эти "нейромаркетинговые исследования", это просто уж до кучи.
[про работу с инженерными данными]
-- "просто инженеров" учат работать с CAD, а вот PLM, все эти хитрости BIM и прочие "интегрирующие весь проект" инструменты -- это инструменты системных инженеров. А системных инженеров как раз и нет, только поставщики инструментов для них.
И так далее, читайте сами.
UPDATE: ещё обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10210451866307006