Деление практики системной инженерии на подпрактики -- это типичная архитектурная задача, если мы проектируем эту системную инженерию. Но это же вдруг может быть задачей реверс-инженерии, тогда это инженерия требований (для тех, кто потом будет изготавливать разные варианты реализации практик). Инженерия требований неявно включает в себя архитектурное мышление, если смотреть на него классически. Картинки многих уровней требований (Ryan в 2013 с иерархией потребностей и требований, https://www.sebokwiki.org/wiki/Life_Cycle_Processes_and_Enterprise_Need или матрёшка требований из ISO 29 148:2018) показывают хорошо известный факт: требования это описания системы, потребности -- это описание надсистемы, и одно к другому не сводится.

Далее приводится везде факт «анализа» как декомпозиции «потребности» нетривиальным образом в требования. Тут драконы: в реальности никакой «декомпозиции», а ровно наоборот -- происходит догадка, что какой-то конструктивный объект может выполнить какую-то функцию в надсистеме, архитектурная догадка. Анализ потом доказывает, что догадка хороша, проходит все тесты (полнота исполнения функции, учёт пространственной компоновки, тест на стоимость и для этого в том числе обязательный выход в оценку стоимости не только материалов, но и изготовления с нужными характеристиками -- в традиционные роли «аналитика» как главным образом инженера по требованиям, проверяющего результат синтеза и таки что-то «неформально» предъявляющего как рекомендации (мышление по синтезу как «умные догадки/мутации» есть, но оно эээ… неформально, не учтено, не обсуждается!).
Архитекторы рисуют ровно такие же картинки, только у них не требования, а архитектуры систем разного уровня. Какая-нибудь диаграмма гамбургера, GARM от Wim Gielingh, https://www.researchgate.net/publication/273 126 714_General_AEC_reference_model_GARM_an_aid_for_the_integration_of_application_specific_product_definition_models -- все эти деления на функциональные и конструктивные структуры на несколько архитектурных уровней, где функции одних уровней совмещаются с сервисами других уровней, и где-то это совпадает (увеличитель давления в виде насосного агрегата или напорной башни), а где-то не совпадает (ножницы) с границами конструктивных модулей. Тоже иерархия, требований там нет, но они вдруг упоминаются как передача информации для «элемента системы», когда его дальше не планируется дробить (и это необязательно деталь, это организационный критерий: «отдаём двигатель двигателистам, и не лезем внутрь. Но архитектурные требования -- вот такая тяга вот в таких размерах и при таком весе»). Тут мы понимаем, что есть требования архитектурные, и все. И есть описания архитектурные, и все (неархитектурные — это с точностью, достаточной для изготовления, «рабочка»).

Так что требования делятся на архитектурные и «рабочие», что пересекается с результатом архитектурной работы и подготовки к изготовлению (кроме инженеров по требованиям и архитекторов требуется вызвать дух заводского технолога, который скажет, достаточно ли описание для изготовления -- и тут же вспоминаешь, что во всех учебниках написано, что проектировщик и технолог (практика подготовки производства) сидят и проектируют рядом, как идеал, который в жизни никогда не происходит, поэтому проектировщик пытается быть немного и технологом, engineering for manufacturing, известная тема). С другой стороны -- как всё-таки связаны архитекторы и инженеры по требованиям, а потом ещё и остальные проектировщики, которые не инженеры по требованиям и не архитекторы?! Какие практики у них в мозгах, на что они тренированы? Вроде как инженеры по требованиям коммуницируют много, улаживают конфликты между высказывающими потребности. Но и архитекторы коммуницируют много, их в середину большой бригады проектировщиков пишут.

Всё окончательно запутывается, если привнести людей, бегающих вокруг надсистемы (если проект не очень инновационный, то надсистема есть, и мы просто делаем реверс-инжиниринг её -- это обычно высказывание архитектурной догадки и потом критика, включая проведение эксперимента, работа инженера по требованиям. Чёрт, «высказывание архитектурной догадки» -- это же архитектурная работа! А критика -- нормальный такой «системный анализ», ничего «требовательного». А потом вроде как архитектор предлагает, как задёшево сделать чёрный ящик, который описал архитектор выше. А если это «полная инновация», то есть новый продукт создаёт какую-то новую эко-систему, то это и подавно архитектурная задача (это не подобрать элементы конструкции, выполняющие функцию, а под новый элемент конструкции восстановить все нужные части новой системы. Под квантовый гейт на какой-то технологии восстановить всё эко-систему квантового компьютинга, включая маркетинг, выстроить новый рынок). Чисто архитектурный вопрос, изобретательство, прямая инженерия, только «снизу вверх» (известно, что есть арматурный бетон. Теперь придумываем очередной небоскрёб. Это не то же, что хотим небоскрёб, придумываем арматурный бетон). Предпринимательство и архитектура тоже перевязаны сильно, разноуровневая архитектура, как в учебнике. А требования где?! Запросто всё то же самое можно изложить диаграммой с движением требований, выкинув все эти «догадки» про функции-конструкции. Но нам же не картинки-иллюстрации отражать, а отражать что-то общее, происходящее в жизни. Нужно получить компактное описание.

Вон у Питера Друкера, как заметил Артур Саяпов, разделяются в предпринимателе инноватор и создатель (innovator and enabler, что enabler и создатель это одно, мы уже раньше догадались, с enabling system), https://spellbooks.ru/blog/management-of-xxi/. Кто смотрит на целевую систему (то ли архитектор, то ли инженер по требованиям), и кто смотрит на оргсистему-создателя, это ж «технолог»! Ну, или «визионер» (состояние мира, целевая и надсистема) и «миссионер» (что делать, создатель), как говорит сам Артур.

То есть «требования и потребности» получается обсуждают границы системных уровней на многих уровнях по линии функциональности и проверкой этой функциональности на целостность, архитектура занимается догадками как сборкой конструктива на базе сервисов, то есть поисками аффордансов в нише как догадками и потом проектированием интерфейсов, не «переводом функции в конструкцию», а «догадкой конструкции для попадания в функцию». Это оказывается не совсем «взаимодополняющей парой на каждом уровне». И ещё рядом есть кто-то, отвечающий за возможность производства, «технолог производства», архитектор создателя (грубо говоря, CTO создателя, отвечающий за «станочный парк и практики создания»). А в софте этого человека часто зовут DevOps, ибо он не столько девелопер или оператор, сколько «организатор изготовления», тот самый технолог станочков с ЧПУ и автоматических линий их загрузке, всех этих «докеров» и конвейеров/пайплайнов (а эксплуатация тут -- это ближе уже к helpdesk и прочему администрированию уже запущенного/изготовленного. То есть Dev и Ops отдельно, а DevOps это завод).

Как по норме решать такую архитектурную задачу? Как обычно, «творчеством в системном мышлении» (https://ailev.livejournal.com/1 425 331.html):
-- проблематизация. Как раз предыдущий текст про учёт в архитектуре времени эволюции https://ailev.livejournal.com/1 637 364.html и вот этот сегодняшний текст про непонятки с инженерией требований (в которой почему-то исчез элемент «догадок», а «выявление требований» очень напоминает архитектурную работу в части reverse-engineering, и плохой стык с предпринимательством) и ещё больше непоняток с архитектурной работой, все стандарты которой про форму, а что там содержательно делается, так бессмысленные и беспощадные «морфологические ящики», с которыми никто не работает!
-- распредмечивание. Уходим от традиционного обсуждения «инженерии требований» и «инженерии системной архитектуры» (и помним, что там ещё много каких практик, типа того же «системного анализа», который оказывается нужен и там и сям, ибо проверка догадок есть и там и сям, а в требованиях архитектура с её выдвижением догадок есть, но почему-то замаскирована)
-- дробление на более мелкие практики: поглядеть, какие там операции, и насколько они безмасштабны. Типа «формулирование требований» это вроде как безмасштабная операция, а вот «выявление требований» немного загадочно в этом плане. Какие общепринятые микропрактики в инженерии требований? Материалов тут хватает, хотя можно их и освежить (вот, например, доклад мой по трендам в инженерии требований 2015 года, это 7 лет назад), https://incose-ru.livejournal.com/53 170.html и уж точно добавить что-то про инженерию требований в DevOps и аналогичных практиках неинженерных отраслей (хотя все эти «партисипативные демократии» явно не источники лучших практик, тем не менее).
-- поглядеть на то, как устроены общие схемы мышления, чтобы пересобрать практики. Общие схемы это (уже консенсус) -- выдвижение догадок на базе порождающих моделей («галлюцинирование», «воображение») и потом проверка, насколько они совпадают с реальной ситуацией. Все эти фристоновские active inference и попперовские эпистемологии. Помянуть Дойля с его многими контурами управления и многочисленными обратными связями, ибо вся эта инженерия неуловимо напоминает ровно рисуемые им схемы «быстрых грубых архитектурных шагов» и «медленных точных в части всех остальных». Но по поводу Дойля это тоже дикая догадка, не более. Тем не менее, все эти «выявления требований» и всё сомнительное со спрятанным мышлением попробовать выразить вот так, «как в моделях мышления». Ход на рациональность (догадки и обоснования) в основе инженерии требований уже обсуждался, хотя и не в этой терминологии, см. «Интегрируем: целе-ориентированная инженерия требований и структурированные инженерные обоснования», https://ailev.livejournal.com/811 715.html, это аж 2010 год. А ещё «Поиск-ориентированая системная инженерия» 2014, https://ailev.livejournal.com/1 122 876.html. И она же 2019, https://ailev.livejournal.com/1 469 822.html (там тот же ход: от людей к AI, поэтому сегодня я и делаю вывод, что делить на практики нужно не по-старинке, а вдоль того, как устроено мышление: функция, которое должно как-то поделиться на агентов, у которых есть профессиональные роли. А агенты заботятся о своих системах, так что переходим к следующему пункту: нарезке практик по системной схеме проекта вокруг систем.
-- кластеризовать все эти практики проектного-создающего и реверс-инженерного как предпроектного мышления по возможности более точно вдоль системной схемы проекта, которая в текущем варианте нарезана вокруг надсистемы, целевой системы и цепочки создания. Это тоже догадка.
-- и проверить, как в полученном фреймворке (наборе объектов, в терминах которого удобно рассуждать про сложную новую предметную область) удобно говорить о безмасштабной системной инженерии, включая (обязательно!) и прихват эволюционного времени (времени изменения архитектурных паттернов), это обсуждалось во вчерашнем тексте https://ailev.livejournal.com/1 637 364.html

Это всё «мышление письмом», конечно. Пишу для себя, не особо заботясь о литературном оформлении, чай не в глянцевый журнал. Но не сомневаюсь, что много наших выпускников, которые прочли уже книги с третьим поколением системного мышления, меня с моими вопросами вполне поймут. А правильно поставленные вопросы -- это уже больше половины ответа. Как пошутил сегодня кто-то утром, «если правильно поставить вопрос, то ответ на него сегодня может дать и AI».

Картинка DALL-E MINI (https://huggingface.co/spaces/dalle-mini/dalle-mini) с промптом requirements engineer on fire, очень реалистично получилось: