Никаких требований в 2022

До сих пор не приступил к главам по требованиям и архитектурному проектированию, ибо так и не разобрался окончательно с вопросом об исчезновении требований как важного артефакта, это было где-то в 2016-2017 году. Книги по requirements engineering в софте как отрезало, а в хардверной инженерии при обсуждении жизненного цикла на эту тему говорят уклончиво, при этом ещё и размазывают тему -- поминают требования, интересы и use cases через запятую, и избегают обсуждать какой-то "процесс" и его результаты. Моделирование того, что говорят внешние проектные роли, моделирование целевой системы и её окружения, но вот чтобы "разработать требования" -- уже нету такого. Есть "разработка" в целом, в софте идут чуть дальше и отдельно от "разработки" вводят архитектуру (с чем полностью несогласны железные системные инженеры, но у них свои тараканы: архитекторы там и концепт использования делают, и проектные решения), и ещё отдельно DevOps с continuous release (и delivery, и integration там внутри), плюс ещё сбоку безопасники. Ход на "модели требований" (помним, что это ход на обсуждение intents внешних проектных ролей) доведён до конца, и серьёзно обсуждаются concerns, а не "выявляются потребности и требования". И дальше принимаются архитектурные и проектные (ох, тут в литературе разночтения что есть что!) решения, а всё выявленное записывается в обоснование этих решений в виде тестов. Требований поэтому вроде как нет, но тесты по учёту этих всех concerns (по факту -- тесты выполнения требований) есть. Если "просто гуглить", то приходит куча старой литературы и цитирования старой литературы, сплошной классический жизненный цикл со "стадиями", которые жёстко критикуются в новой литературе. В новой литературе это называют "испорченный телефон" (что хочет клиент узнаётся аналитиками в каких-то моделях, затем переводится в требования, потом как-то отражается в проектных решениях, потом воплощается в коде/чертежах -- и в этот момент хорошо заметно, что мысль клиента за время этого путешествия исказилась до неузнаваемости), а ещё в новой литературе обязательно есть раздел не только про "методологию", но и "культуру" -- и там замечается, что "в нашу больницу с чужими анализами не берут", отношение разработчиков к реализации требований, когда эти разработчики сами клиента в глаза не видели, более чем прохладное. А если они клиента видят, то они сами принимают решение, что для него сделать -- и пишут это сразу в виде проверяемых требований, то есть тестов. Архитектурная работа у софтверщиков выделяется как отдельная от разработки: там 1. обеспечение -ilities (которые concerns, их архитекторы сами вынимают из понимания ситуации, но вот дальше из этих предметов интереса берут реальные интересы, путём выбора самых важных -- и дальше требования даже не пишутся, но пишется функция мониторинга метрики для интереса. Часть литературы продолжает называть это всё non-functional requirements, но даже в этой части литературы вы не найдёте functional requirements! Ибо это не для архитекторов, а для разработчиков), 2. По-крупному система нарезается на куски, и эти куски даются разработчикам. Фишка в том, что команд разработчиков по определению будет несколько, и вот это объединение командной разработки под контролем архитекторов. Это определяется через архитектурные решения как принципы (и меньше через модели). У железячников всё хуже, ибо архитекторы 3. разрабатывают концепцию/concept как "что из конструкции по какому механизму будет выполнять функцию", и это происходит послойно внарезку с требованиями (модель сэндвича, не путать с моделью гамбургера, хотя они похожи -- слой требований, потом архитектурная модель, потом слой требований, потом архитектурная модель и так до самого дна), ибо это всё рекурсивно. В любом случае, после "3. Изобретение" делается заметка, что "работа нарезается на большие куски, чтобы учесть ilities" и отдаётся разработчикам-прикладникам. Вот это "3. Изобретение" существенно связано с бизнес-архитектурой (можем ли мы обойти конкурентов) и функциональностью системы, а у софтовиков этого "изобретения" у архитекторов нет, ибо с функциональностью работают разработчики, которые не архитекторы. У железячников с функциональностью работает архитектор, но вот где инженер по требованиям?! А нету. Всё теперь разные модели, и отдельно "требований" как модели чёрного ящика нет. Есть тексты, где объясняется, что "чёрного ящика" не бывает: как только ты выбираешь, что там внутри, появляются новые требования именно из-за того, что там что-то внутри! Типа "прибор должен быть чёрный", а ты внутрь ставишь печку для непрерывной покраски в чёрный цвет", и тут же "прибор должен быть чёрный и с температурой не выше сорока градусов цельсия в любой точке корпуса". Поэтому требования и проектные решения меняются вместе, а не "сначала требования, а потом проектные решения". Ещё в литературе часто встречается утверждение, что "архитектура это не должность в команде, а мастерство" -- типа как каждый человек архитектор, ибо что-то там режет на части, учитывает ilities и придумывает тот самый концепт. И там же рядом идут главы про как развивать себя не столько как мастера в архитектуре, сколько как человека на должности архитектора. Но ход хорош, это ход от отдельной "стадии архитектуры" к "практике архитектуры как подпрактике разработке и как минимум, практике проектирования". И можно думать, что с требованиями тоже что-то такое же произошло, только это уже "требования", а customer feedback, business problem и самые разные эвфемизмы. Слово требования в современных текстах встречаются только как 1. Требования стандартов, безопасности и регуляторов, 2. в абсолютно бытовом понимании "Вася потребовал открыть окно", 3. те самые "non-functional requirements" с обязательным пояснением, что там не столько "требования" в классическом смысле слова, сколько "учёт архитектурных предметов интересов" (ибо все эти -ilities обзываются архитектурными характеристиками/предметами интереса -- формулировки там не похожи на формулировки требований. А вот ADR/architectural decision record похоже на требование к разработчикам, да ещё там обоснование указано -- чтобы разработчик уж точно понимал, зачем и почему это всё нужно соблюсти). Удивительно, сколько в литературе отсылок "всё, что мы тут пишем про информационные системы, верно для систем из людей" (и далее много говорят о том, как настроить системы людей, чтобы не мешали софтовой разработке), но про железо молчат. Организации -- это с точки зрения айтишников такие большие вычислители из людей и машин, а внешний мир они не меняют. Железо айтишники вспоминают только в тех случаях, когда говорят, что "нам нужно учиться у железных инженеров настоящей инженерии на базе научного подхода, математики и моделирования, а ещё там системное мышление". Железные инженеры пишут про софтверщиков, что "вот у них там всё гибко/agile, нам тоже так надо". Очень забавно читать про эту взаимную зависть. Дальше у меня ещё и методическая задача: как всё это отразить в учебнике, нарезать изложение на главы и как-то изложить безмасштабно. Ссылок не даю, там десяток относительно свежих книжек, а в них отсылки главным образом на посты в блогах (и другие книжки, а вот на статьи -- очень редко, в статьях почему-то пересказ классики со ссылками исключительно на госпроекты. Видимо старенькие научные руководители другого не приемлют. В новых книжках примеры неакадемические, что-то типа "вот когда у нас вырубилось на 13 часов две трети инфраструктуры Netflix, хлебнули мы горя, но сделали выводы"). UPDATE: обсуждение в чате блога -- с https://t.me/ailev_blog_discussion/16232, в фейсбуке -- с https://www.facebook.com/ailevenchuk/posts/pfbid0dj2MtpWnjjGqPLFHKLoLFvFAkeniZjDv4iZ9H6PnVg3WLJAmBF7TYZTUqHkNws9nl, фрифиде -- https://freefeed.net/ailev/4dac888a-d060-4205-a5b0-e952fdfd7d14 и ещё в закрытых чатах были получены подтверждения от работающих архитекторов IT-компаний.