Проблемы инженерии требований
Вчера прошёл семинар "Об инженерии требований", но я бы его назвал "об инженерию требований" ("об об", https://ailev.livejournal.com/982750.html). На семинаре Кирил Гайдамака представил самые разные имеющиеся в литературе подходы к описанию инженерии требований. Увы, не получилось ни трансляции организовать, ни видео записать. Вот тут о семинаре написал Церен Церенов -- https://www.facebook.com/tseren.tserenov/posts/1565419446889339, а я сделаю несколько заметок по сути дела.
Последний раз я затрагивал тренды в инженерии требований в докладе 2015 года http://incose-ru.livejournal.com/53170.html, но там было главным образом про тренды. И я понимаю, что с тех по ничего не изменилось в ситуации, когда на предприятиях не обнаруживаются стейкхолдеры, заинтересованные в инженерии требований -- https://ailev.livejournal.com/1217302.html. Во времена тотального имкрыша и импортзамещения людям в массе своей не до инженерии требований, за три года ничего с этим не изменилось.
Но мы в Русском отделении INCOSE, Международной ассоциации ТРИЗ, Школе системного менеджмента (по факту семинар получился совместным для всех них) это печальное положение дел с массовым отсутствием в русскоязычном мире стейкхолдеров игнорируем, мы тут сами себе стейкхолдеры: нас мало, но мы системны и поэтому можем сделать что-то интересное и без скопления больших толп. Так, мы за последний десяток лет сделали несколько шагов по улучшению изложения материала системного мышления, добавили материалы по онтологике, прояснили связь ТРИЗ и системной инженерии. И у нас есть формальная и неформальная связь с мировой системной инженерией, мировым движением ТРИЗ. Не боги горшки обжигают. Так что я позволю себе ряд проблематизаций по итогам семинара.
Системная инженерия требований vs. инженерия требований к системе
Это различие я ввёл по типу systems engineering vs. engineering of systems -- инженерия с системным подходом в голове, или инженерия "систем", где система это просто какой-то технический объект (подробней это противопоставление см. в https://ailev.livejournal.com/1146200.html и там ссылка на материал профессора Derek Hitchins http://www.hitchins.net/profs-stuff/profs-blog/systems-engineering-vs.html.
При рассмотрении самых популярных методологий (помним: методология -- это более-менее связный набор практик, достаточный для достижения какого-то результата) инженерии требований оказывается, что большинство из них не опираются на системный подход. Требования в этих материалах -- это любые деонтические (со словами "должен", "обязан", "разрешён", "рекомендуется" и т.п.) высказывания. Понятно, что без последовательно применяемого системного подхода никакого чёткого выделения связанных с границей целевой и использующей систем, понятиями прозрачного и чёрного ящика потребностей, требований, ограничений нет. Без системного подхода нельзя сказать, что "описание подсистем в нашей архитектуре использующей системы -- это требования для вашей целевой системы", ибо нет чётких различений архитектуры как описание прозрачного ящика против требований как описаний чёрного ящика и понимания того, что архитектура и требования относительны, они на каждом уровне холархии меняются в зависимости от того, какой стейкхолдер ведёт рассуждения для какой команды. А если требования не привязываются к границам систем, то не учитываются и переходы между системными уровнями, не идёт и речи о рекурсивном применении практик инженерии требований, коллективная работа оказывается работой единственного коллектива инженеров.
Нужно понимать, что наши курсы инженерии требований должны быть курсами системной инженерии требований, и базироваться на современной системной онтологике. Это даст и компактное изложение самих практик инженерии требований, и позволит избежать многих ошибок и заблуждений от дребезга в терминологии, и позволит проще управлять конфигурацией и изменениями требований, и заодно проще договариваться о работе с требованиями на всём жизненном цикле с самыми разными внутренними и внешними стейкхолдерами -- каждый раз будет понятно, о чём идёт речь и как практики инженерим требований вписываются в общий жизненный цикл с участием всех практик инженерного проекта.
Инженерия требований для IT vs. инженерия требований для "железа"
Практики инженерии требований для больших и маленьких "железных" систем существенно отличаются от практик инженерии требований для больших и маленьких систем с IT-микросервисами. И тут легко запутаться: литература по инженерии требований на 90% относится к IT-проектам, и только на 10% к "железным". Многие книжки даже не упоминают разницы, и вроде как "общие", пригодные как для IT, так и для "железных" проектов. Но по факту они содержат опять таки 90% отличного материала для IT-проектов и 10% для проектов "железных". Уж так случилось. Конечно лет через десять-пятнадцать мы увидим многие адаптированные для "железа" практики сегодняшней айтишной инженерии требований, но на сегодняшний день эти практики не адаптированы, и вычленить из них что-то заведомо работающее для "железа" трудно.
В программной инженерии архитектурный подход менее развит, чем в железной (кроме архитектуры предприятия, которая тем не менее не эквивалентна программной архитектуре, хоть и с креном в архитектуру IT-решения). Архитектурная деятельность практически не выделяется во многих проектах -- но выделяется инженерия требований. В "железных" системах центральная дисциплина -- это как раз архитектура, изобретение, модульный синтез. Это означает, что в айтишных методологиях инженерии требований очень плохо прописан стык между практиками инженерии требований и практиками инженерии системной архитектуры. Главными потребителями софтверных требований оказываются не архитекторы, а совсем другие стейкхолдеры, поэтому артефакты инженерии требований получаются более удобными для этих других стейкхолдеров, а не для работы архитекторов. Требования трассируются не к архитектуре, а... и тут понимаешь, что требования совсем необязательно трассируются, с ними в айтишных проектах работают по-другому. Как? По-всякому, но "железные" проекты с их длительными циклами изготовления и дорогими испытаниями могут и не выжить от подобной "всякой" работы с требованиями. Что птичкам хорошо, то рыбкам смерть.
Автоматизация тестирования, откатки-накатки в ходе DevOps в существенной мере влияют на практики жизненного цикла требований. Даже время одной итерации от формулирования требования до верификации (для этого нужно пройти до продукта "в металле" или "в бетоне" по жизненному циклу неайтишного проекта) имеет значение. Если в IT можно за пару часов сформулировать требование, попробовать изменить систему, провести не только верификацию, но и валидацию, а в случае неудачки успеть откатиться назад, то в "железных" системах цена этого (иногда и многолетнего -- в случае самолётов или АЭС) цикла будет запредельно велика, а скорость низка. В айтишных проектах можно подумать -- внести изменения в систему по небрежно сформулированному требованию и тут же понять, что это было неправильное изменение, или провести побольше времени, размышляя над требованиями, а потом только ввязываться в архитектуру и уж тем более в изготовление и испытания. Автоматизация тестирования в IT и "железных" проектах, способы работы с юнит-тестами отличаются существенно. И поэтому чисто экономический расчёт по выгодности lightweight инженерии требований или наоборот, необходимости использования самых тяжёлых вариантов может быть очень разным.
Водопад vs. спираль
Классические "железные" методологии инженерии требований подталкивают к analysis paralysis и оправдывают его. Чем больше денег налогоплательщиков удаётся оправдать "надёжной методологией, без которой нельзя", тем лучше. Когда тебя не давят конкуренты (а в госсекторе той же военной системной инженерии конкуренции нет, деньги получают в ходе политического процесса и интриг, а не выигрышем на рынке), жизнь волшебным образом меняется, и бюрократия побеждает. Если можно обосновать не одну трассировку требований, а четыер -- вы их получите, и на эту тему напишете учебник (который пойдёт в обоснвание следующих подобных проектов). Финансируемые государством инженерные проекты водопадом не испортишь, на попытках реализовать водопад за-ра-ба-ты-ва-ют!
Так что при работе с тяжёлыми методологиями:
-- помним, что agile в айтишных проектах появился когда-то как попытка преодолеть лишнюю бюрократию, убрать непроизводительную работу. В "железных" проектах не нужно пугать людей словом agile (хотя многие уже не пугаются), но слова "concurrent engineering" произносить обязательно. Если методология инженерии требований не поддерживает concurrent engineering, а рассчитана на классический водопад, то лучше её выкинуть сразу, она будет хороша только для госпроектов.
-- разбираем методологии на отдельные практики и используем из этих практик только самое необходимое, и ни в коем случае не используем методологии целиком.
-- чётко понимаем, что делается "на всякий случай", а что реально важно и критично. Борьба с рисками съедает все ресурсы, и ещё чуть-чуть. Поэтому в рассмотрение того, что важно, и что неважно в инженерии требований нужно внести какие-то оценки ресурсов и при большом потреблении ресурсов той или иной практикой вводить аппроксимирующие практики: которые дают результат похуже, но зато кушают меньше ресурсов. Этот аспект эффективности инженерии требований, аспект "экономической оценки" нужно обязательно ввести. Ибо дай волю и деньги инженерам по требованиям, и центральной дисциплиной станет не архитектура с её изобретениями как главной практикой, а инженерия требований. Это отчасти уже произошло в software engineering с резко уменьшившейся долей архитектурных размышлений и выпячиванием инженерии требований. Результат -- точно соответствующие безумным требованиям убогие перераздутые и плохо спроектированные системы. Инженерия требований должна быть "достаточной", а не избыточной.
GORE разделить с MBCD
Мы должны работать прежде всего с GORE (goal oriented requirements engineering) в инженерии требований, а это появилось всего-навсего в 1995 году. В требованиях к "железу" (к какой-нибудь АЭС или самолёту) всё идёт по накатанной колее работы с текстовыми требованиями, но без моделей требований. Помним, что модели требований -- это когда не только требования трассируются к стейкхолдерам, но и показываются взаимоотношения между стейкхолдерами (например, что у какой-то пары стейкхолдеров оценки какого-то интереса противоположны).
Следующий вопрос тут -- насколько модели требований должны быть "формальными моделями" (быть схемами), а насколько находиться в левой части спектра мышления (быть схемоидами, или даже просто вдохновляющими текстами). Тот же вопрос задавался для архитектуры: насколько архитектура должна быть представлена формальными моделями -- и Donald Firesmith приходилось защищать наличие текстов в архитектурных артефактах, например, архитектурного эссе. Тут может быть "стена текста" из неатомарных текстовых требований; из атомарных текстовых требований; из атомарных требований, разобранных в таблички или деревья и т.д. -- заканчивая формальными языками представления требований (большинство архитектурных языков и языков моделирования, даже Modelica и даже Julia имеют уже какие-то метамодели для представления требований в формальном виде, при этом формальность достаточна для исполнения требований. Например, требования описывают систему как чёрный ящик, поэтому исполняемые требования просто будут вести себя как система -- и можно будет сравнивать реакции воплощения целевой системы на внешние воздействия с реакцией имитационно моделируемой системы, описанной требованиями. Об этом я говорил в докладе http://incose-ru.livejournal.com/53170.html на примере исполняемых спецификаций требований к системе предотвращения авиационных коллизий, написанных на Julia.
Конечно, тексты нужно оставлять. В мышлении задействуется весь спектр мышления, и если что-то нельзя или наоборот, намеренно не нужно формализовывать, в требованиях это "что-то" нужно иметь возможность выразить -- например, текстом на естественном языке. Любая формализация этого текста -- это сжатие информации. Нужно чётко понимать, когда и в какой момент сжимать информацию. С несжатой информацией невозможно работать, внимание должно быть приковано к очень небольшому числу объектов. Но и с отжатой информацией нельзя работать: можно потерять что-то реально важное. Так что в инженерии требований должно быть сформулировано отношение к работе со спектром мышления ("жми, господь!", https://ailev.livejournal.com/1414038.html). При подготовке курсов системной инженерии требований нужно уделить особое внимание работе инженера по требованиям с полным спектром мышления ("фундаментальное образование: системное развитие мышления", https://ailev.livejournal.com/1425003.html).
А ещё граница между моделями требований и концепцией использования (ConOp) определена очень нечётко, много менее чётко, чем граница между такими описаниями системы, как требования и архитектура. Когда практики model-based concept design (MBCD, иногда не concept, а conceptual), центрирующиеся на разработке концепции использования и mission and business analysis, вдруг переходят в практики системной инженерии, непонятно. Системные инженеры более-менее согласны, что они откуда-то получают задание на разработку системы, а не придумывают проект самостоятельно. Можно вспомнить тут известную картинку из Steven J. Saunders "Return on Investment Using Model-Based Concept Design", INCOSE INSIGHT том 17 выпуск 4, декабрь 2014:
Как именно MBCD граничит с GORE в системной инженерии -- это непонятно, но нужно сформулировать.
Системная методология инноваций aka ТРИЗ+
Развитие ТРИЗ в его "иностранный период" (после перестройки, когда эмигрировало много ТРИЗ-мастеров -- и в СНГ ТРИЗ по факту заглох, а за рубежом наоборот, вдруг набрал силу) почти неизвестно русскоязычной публике. А ведь ТРИЗ по факту это некоторая специализация практик системной инженерии -- классический ТРИЗ тут специализация главным образом практик разработки системной архитектуры. Результат успешного модульного синтеза это и есть обычно искомое архитекторами "изобретение". ТРИЗ+ прирастал в 21 веке главным образом практиками conceptual development (получение идеи продукта) и инженерии требований. В ТРИЗ+ строится некоторый набор моделей требований, в которых затем находится противоречие, решаемое в ходе архитектурной работы (см. часть про ТРИЗ в "творчество в системном мышлении", https://ailev.livejournal.com/1425331.html).
Так что нужно обязательно включить в рассмотрение практики MPV (main parameters of value, https://www.gen-triz.com/main-parameters-of-value/, https://www.metodolog.ru/01472/01472.html) и другие практики инженерии требований из ТРИЗ+.
При этом помнить, что в ТРИЗ по старой традиции принято переформализовывать и в какой-то момент переходить к численным оценкам. Методология численных оценок в ТРИЗ старая, и нужно просто заменить эту практику на более современную (на основе байесовских вероятностей), проще всего её брать из книжки Хаббарда Дугласа "Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе" (http://b-ok.org/book/2315676/1b9807, но есть и обновлённое английское издание, существенно дополненное).
Современная онтологика в инженерии требований
Байесовские оценки нужно провести красной нитью через всю инженерию требований. Требования должны быть существенны. Если нас не слишком удивляет невыполнение какого-то требования, то этого требования, может, вообще не должно было бы быть: оно только отвлекает внимание и забирает на себя драгоценное время команды проекта и стейкхолдеров. Так что на каком уровне неопределённости описывать систему -- это важный вопрос.
Но оценки должны делаться для как-то описанной системы. Как описывать систему? Как совмещать рассказы о системе от самых разных стейкхолдеров? Как узнать предметную область системы, существенные её свойства? Почему вдруг сценарии оказались так хороши для описания функций -- можем ли мы как-то усилить, если будем знать причину? Это та же причина, из-за которой оказался успешен behavior driven development (BDD, https://www.infoq.com/news/2018/04/cucumber-bdd-ten-years)? И как находят требования в domain driven design (DDD, https://habr.com/post/334126/, https://en.wikipedia.org/wiki/Domain-driven_design) с его event storm (http://www.russmiles.com/essais/going-events-first-for-microservices-with-event-storming-and-ddd). Онтика/дисциплина (и даже набор дисциплин), в которых требования описывают систему -- это важный вопрос, его не нужно отдавать на самотёк.
Последний вопрос мы уже затрагивали при рассмотрении формальности моделей, и тут тоже не обойтись без онтологики: на каком уровне формальности описывать систему?
Как организовать работу по подготовке "мировоззренческого" курса инженерии требований
Все описанные в данном тексте проблемы требуют исследований. Результаты исследований предлагается сразу формулировать в виде учебного курса по инженерии требований: ибо для чего ещё эти результаты исследований могут быть использованы? Исследования бесполезны, если об их результатах никто не узнает, если они нигде не будут использованы. А чтобы кто-то узнал об этих результатах и использовал их, нужно просто оформить результаты в виде учебного курса.
Понятно, что для каждого отдельного инженерного проекта в зависимости от его условий (предметной области, размеров проекта, опыта команды, наличия инструментария -- моделеров, PLM и т.д.) нужно тщательно выбирать подходящий набор практик инженерии требований -- и даже для похожего проекта с той же командой этот набор практик может меняться, поскольку будет получен какой-то опыт и жизненный цикл опять поменяется. Но это не значит, что инженерии требований нельзя учить. Наоборот, для компетентной работы по выбору подобных практик нужно дать какой-то общий фреймворк/онтику/подход/обобщённую дисциплину/мировоззрение инженерии требований, позволяющую как-то обсуждать и сравнивать различные конкретные практики инженерии требований, берущиеся из разных "больших методологий". Ну, и при необходимости порождать новые практики инженерии требований. Все ведь сегодняшние практики инженерии требований были когда-то придуманы и использованы впервые. Непонятно, почему бы порождение новых практик, тем более при получении новых инструментов с использованием искусственного интеллекта, не продолжалось и сегодня.
Рабочий способ, которым можно было бы получить "мировоззрение" инженерии требований -- это выполнить ходы, описанные для получения "мировоззрений" в "откуда берутся полезные мировоззрения" https://ailev.livejournal.com/1425003.html.
Нужно посмотреть, есть ли в литературе какие-то ответы на вопросы из текущего поста, не хотелось бы изобретать велосипеды самостоятельно. Нужно посмотреть, какие современные подходы/методологии/мировоззрения на инженерию требований хоть как-то отвечают на вопросы из текущего поста.
А далее нужно "распредметиться", сдвинуться по спектру мышления влево и получить догадки о том, какие концепты являются базовыми, общими для всех этих разных дисциплин инженерии требований. Из этих концептов нужно создать новые схемоиды, возможно, предложив при этом решения для различных противоречий, проявящихся при объединении онтик рассматривающихся вариантов практик инженерии требований. Результирующее после преодоления противоречий "мировоззрение инженерии требований" будет "конфигуратором" (см. "творчество в системном мышлении" -- https://ailev.livejournal.com/1425331.html).
Вот этому "мировоззрению инженерии требований" aka "мышлению о требованиях" и нужно будет учить в первую голову, как учим сейчас системному мышлению до знакомства с конкретными практиками системной инженерии. А конкретные практики инженерии требований уже давать вторым проходом после курса мышления о требованиях, и они будут осваиваться легко, будут хорошо согласованы с контекстом других практик инженерного проекта (прежде всего MBCD и архитектурой, а ещё обязательно V&V), а полученное мышление будет сохраняться при переходе от проекта к проекту -- независимо от принятых там решений по использованию конкретных практик инженерии требований. Выпускники курса станут осознанными в своей работе по инженерии требований, и работа эта будет системной.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10212884260315336
Последний раз я затрагивал тренды в инженерии требований в докладе 2015 года http://incose-ru.livejournal.com/53170.html, но там было главным образом про тренды. И я понимаю, что с тех по ничего не изменилось в ситуации, когда на предприятиях не обнаруживаются стейкхолдеры, заинтересованные в инженерии требований -- https://ailev.livejournal.com/1217302.html. Во времена тотального имкрыша и импортзамещения людям в массе своей не до инженерии требований, за три года ничего с этим не изменилось.
Но мы в Русском отделении INCOSE, Международной ассоциации ТРИЗ, Школе системного менеджмента (по факту семинар получился совместным для всех них) это печальное положение дел с массовым отсутствием в русскоязычном мире стейкхолдеров игнорируем, мы тут сами себе стейкхолдеры: нас мало, но мы системны и поэтому можем сделать что-то интересное и без скопления больших толп. Так, мы за последний десяток лет сделали несколько шагов по улучшению изложения материала системного мышления, добавили материалы по онтологике, прояснили связь ТРИЗ и системной инженерии. И у нас есть формальная и неформальная связь с мировой системной инженерией, мировым движением ТРИЗ. Не боги горшки обжигают. Так что я позволю себе ряд проблематизаций по итогам семинара.
Системная инженерия требований vs. инженерия требований к системе
Это различие я ввёл по типу systems engineering vs. engineering of systems -- инженерия с системным подходом в голове, или инженерия "систем", где система это просто какой-то технический объект (подробней это противопоставление см. в https://ailev.livejournal.com/1146200.html и там ссылка на материал профессора Derek Hitchins http://www.hitchins.net/profs-stuff/profs-blog/systems-engineering-vs.html.
При рассмотрении самых популярных методологий (помним: методология -- это более-менее связный набор практик, достаточный для достижения какого-то результата) инженерии требований оказывается, что большинство из них не опираются на системный подход. Требования в этих материалах -- это любые деонтические (со словами "должен", "обязан", "разрешён", "рекомендуется" и т.п.) высказывания. Понятно, что без последовательно применяемого системного подхода никакого чёткого выделения связанных с границей целевой и использующей систем, понятиями прозрачного и чёрного ящика потребностей, требований, ограничений нет. Без системного подхода нельзя сказать, что "описание подсистем в нашей архитектуре использующей системы -- это требования для вашей целевой системы", ибо нет чётких различений архитектуры как описание прозрачного ящика против требований как описаний чёрного ящика и понимания того, что архитектура и требования относительны, они на каждом уровне холархии меняются в зависимости от того, какой стейкхолдер ведёт рассуждения для какой команды. А если требования не привязываются к границам систем, то не учитываются и переходы между системными уровнями, не идёт и речи о рекурсивном применении практик инженерии требований, коллективная работа оказывается работой единственного коллектива инженеров.
Нужно понимать, что наши курсы инженерии требований должны быть курсами системной инженерии требований, и базироваться на современной системной онтологике. Это даст и компактное изложение самих практик инженерии требований, и позволит избежать многих ошибок и заблуждений от дребезга в терминологии, и позволит проще управлять конфигурацией и изменениями требований, и заодно проще договариваться о работе с требованиями на всём жизненном цикле с самыми разными внутренними и внешними стейкхолдерами -- каждый раз будет понятно, о чём идёт речь и как практики инженерим требований вписываются в общий жизненный цикл с участием всех практик инженерного проекта.
Инженерия требований для IT vs. инженерия требований для "железа"
Практики инженерии требований для больших и маленьких "железных" систем существенно отличаются от практик инженерии требований для больших и маленьких систем с IT-микросервисами. И тут легко запутаться: литература по инженерии требований на 90% относится к IT-проектам, и только на 10% к "железным". Многие книжки даже не упоминают разницы, и вроде как "общие", пригодные как для IT, так и для "железных" проектов. Но по факту они содержат опять таки 90% отличного материала для IT-проектов и 10% для проектов "железных". Уж так случилось. Конечно лет через десять-пятнадцать мы увидим многие адаптированные для "железа" практики сегодняшней айтишной инженерии требований, но на сегодняшний день эти практики не адаптированы, и вычленить из них что-то заведомо работающее для "железа" трудно.
В программной инженерии архитектурный подход менее развит, чем в железной (кроме архитектуры предприятия, которая тем не менее не эквивалентна программной архитектуре, хоть и с креном в архитектуру IT-решения). Архитектурная деятельность практически не выделяется во многих проектах -- но выделяется инженерия требований. В "железных" системах центральная дисциплина -- это как раз архитектура, изобретение, модульный синтез. Это означает, что в айтишных методологиях инженерии требований очень плохо прописан стык между практиками инженерии требований и практиками инженерии системной архитектуры. Главными потребителями софтверных требований оказываются не архитекторы, а совсем другие стейкхолдеры, поэтому артефакты инженерии требований получаются более удобными для этих других стейкхолдеров, а не для работы архитекторов. Требования трассируются не к архитектуре, а... и тут понимаешь, что требования совсем необязательно трассируются, с ними в айтишных проектах работают по-другому. Как? По-всякому, но "железные" проекты с их длительными циклами изготовления и дорогими испытаниями могут и не выжить от подобной "всякой" работы с требованиями. Что птичкам хорошо, то рыбкам смерть.
Автоматизация тестирования, откатки-накатки в ходе DevOps в существенной мере влияют на практики жизненного цикла требований. Даже время одной итерации от формулирования требования до верификации (для этого нужно пройти до продукта "в металле" или "в бетоне" по жизненному циклу неайтишного проекта) имеет значение. Если в IT можно за пару часов сформулировать требование, попробовать изменить систему, провести не только верификацию, но и валидацию, а в случае неудачки успеть откатиться назад, то в "железных" системах цена этого (иногда и многолетнего -- в случае самолётов или АЭС) цикла будет запредельно велика, а скорость низка. В айтишных проектах можно подумать -- внести изменения в систему по небрежно сформулированному требованию и тут же понять, что это было неправильное изменение, или провести побольше времени, размышляя над требованиями, а потом только ввязываться в архитектуру и уж тем более в изготовление и испытания. Автоматизация тестирования в IT и "железных" проектах, способы работы с юнит-тестами отличаются существенно. И поэтому чисто экономический расчёт по выгодности lightweight инженерии требований или наоборот, необходимости использования самых тяжёлых вариантов может быть очень разным.
Водопад vs. спираль
Классические "железные" методологии инженерии требований подталкивают к analysis paralysis и оправдывают его. Чем больше денег налогоплательщиков удаётся оправдать "надёжной методологией, без которой нельзя", тем лучше. Когда тебя не давят конкуренты (а в госсекторе той же военной системной инженерии конкуренции нет, деньги получают в ходе политического процесса и интриг, а не выигрышем на рынке), жизнь волшебным образом меняется, и бюрократия побеждает. Если можно обосновать не одну трассировку требований, а четыер -- вы их получите, и на эту тему напишете учебник (который пойдёт в обоснвание следующих подобных проектов). Финансируемые государством инженерные проекты водопадом не испортишь, на попытках реализовать водопад за-ра-ба-ты-ва-ют!
Так что при работе с тяжёлыми методологиями:
-- помним, что agile в айтишных проектах появился когда-то как попытка преодолеть лишнюю бюрократию, убрать непроизводительную работу. В "железных" проектах не нужно пугать людей словом agile (хотя многие уже не пугаются), но слова "concurrent engineering" произносить обязательно. Если методология инженерии требований не поддерживает concurrent engineering, а рассчитана на классический водопад, то лучше её выкинуть сразу, она будет хороша только для госпроектов.
-- разбираем методологии на отдельные практики и используем из этих практик только самое необходимое, и ни в коем случае не используем методологии целиком.
-- чётко понимаем, что делается "на всякий случай", а что реально важно и критично. Борьба с рисками съедает все ресурсы, и ещё чуть-чуть. Поэтому в рассмотрение того, что важно, и что неважно в инженерии требований нужно внести какие-то оценки ресурсов и при большом потреблении ресурсов той или иной практикой вводить аппроксимирующие практики: которые дают результат похуже, но зато кушают меньше ресурсов. Этот аспект эффективности инженерии требований, аспект "экономической оценки" нужно обязательно ввести. Ибо дай волю и деньги инженерам по требованиям, и центральной дисциплиной станет не архитектура с её изобретениями как главной практикой, а инженерия требований. Это отчасти уже произошло в software engineering с резко уменьшившейся долей архитектурных размышлений и выпячиванием инженерии требований. Результат -- точно соответствующие безумным требованиям убогие перераздутые и плохо спроектированные системы. Инженерия требований должна быть "достаточной", а не избыточной.
GORE разделить с MBCD
Мы должны работать прежде всего с GORE (goal oriented requirements engineering) в инженерии требований, а это появилось всего-навсего в 1995 году. В требованиях к "железу" (к какой-нибудь АЭС или самолёту) всё идёт по накатанной колее работы с текстовыми требованиями, но без моделей требований. Помним, что модели требований -- это когда не только требования трассируются к стейкхолдерам, но и показываются взаимоотношения между стейкхолдерами (например, что у какой-то пары стейкхолдеров оценки какого-то интереса противоположны).
Следующий вопрос тут -- насколько модели требований должны быть "формальными моделями" (быть схемами), а насколько находиться в левой части спектра мышления (быть схемоидами, или даже просто вдохновляющими текстами). Тот же вопрос задавался для архитектуры: насколько архитектура должна быть представлена формальными моделями -- и Donald Firesmith приходилось защищать наличие текстов в архитектурных артефактах, например, архитектурного эссе. Тут может быть "стена текста" из неатомарных текстовых требований; из атомарных текстовых требований; из атомарных требований, разобранных в таблички или деревья и т.д. -- заканчивая формальными языками представления требований (большинство архитектурных языков и языков моделирования, даже Modelica и даже Julia имеют уже какие-то метамодели для представления требований в формальном виде, при этом формальность достаточна для исполнения требований. Например, требования описывают систему как чёрный ящик, поэтому исполняемые требования просто будут вести себя как система -- и можно будет сравнивать реакции воплощения целевой системы на внешние воздействия с реакцией имитационно моделируемой системы, описанной требованиями. Об этом я говорил в докладе http://incose-ru.livejournal.com/53170.html на примере исполняемых спецификаций требований к системе предотвращения авиационных коллизий, написанных на Julia.
Конечно, тексты нужно оставлять. В мышлении задействуется весь спектр мышления, и если что-то нельзя или наоборот, намеренно не нужно формализовывать, в требованиях это "что-то" нужно иметь возможность выразить -- например, текстом на естественном языке. Любая формализация этого текста -- это сжатие информации. Нужно чётко понимать, когда и в какой момент сжимать информацию. С несжатой информацией невозможно работать, внимание должно быть приковано к очень небольшому числу объектов. Но и с отжатой информацией нельзя работать: можно потерять что-то реально важное. Так что в инженерии требований должно быть сформулировано отношение к работе со спектром мышления ("жми, господь!", https://ailev.livejournal.com/1414038.html). При подготовке курсов системной инженерии требований нужно уделить особое внимание работе инженера по требованиям с полным спектром мышления ("фундаментальное образование: системное развитие мышления", https://ailev.livejournal.com/1425003.html).
А ещё граница между моделями требований и концепцией использования (ConOp) определена очень нечётко, много менее чётко, чем граница между такими описаниями системы, как требования и архитектура. Когда практики model-based concept design (MBCD, иногда не concept, а conceptual), центрирующиеся на разработке концепции использования и mission and business analysis, вдруг переходят в практики системной инженерии, непонятно. Системные инженеры более-менее согласны, что они откуда-то получают задание на разработку системы, а не придумывают проект самостоятельно. Можно вспомнить тут известную картинку из Steven J. Saunders "Return on Investment Using Model-Based Concept Design", INCOSE INSIGHT том 17 выпуск 4, декабрь 2014:
Как именно MBCD граничит с GORE в системной инженерии -- это непонятно, но нужно сформулировать.
Системная методология инноваций aka ТРИЗ+
Развитие ТРИЗ в его "иностранный период" (после перестройки, когда эмигрировало много ТРИЗ-мастеров -- и в СНГ ТРИЗ по факту заглох, а за рубежом наоборот, вдруг набрал силу) почти неизвестно русскоязычной публике. А ведь ТРИЗ по факту это некоторая специализация практик системной инженерии -- классический ТРИЗ тут специализация главным образом практик разработки системной архитектуры. Результат успешного модульного синтеза это и есть обычно искомое архитекторами "изобретение". ТРИЗ+ прирастал в 21 веке главным образом практиками conceptual development (получение идеи продукта) и инженерии требований. В ТРИЗ+ строится некоторый набор моделей требований, в которых затем находится противоречие, решаемое в ходе архитектурной работы (см. часть про ТРИЗ в "творчество в системном мышлении", https://ailev.livejournal.com/1425331.html).
Так что нужно обязательно включить в рассмотрение практики MPV (main parameters of value, https://www.gen-triz.com/main-parameters-of-value/, https://www.metodolog.ru/01472/01472.html) и другие практики инженерии требований из ТРИЗ+.
При этом помнить, что в ТРИЗ по старой традиции принято переформализовывать и в какой-то момент переходить к численным оценкам. Методология численных оценок в ТРИЗ старая, и нужно просто заменить эту практику на более современную (на основе байесовских вероятностей), проще всего её брать из книжки Хаббарда Дугласа "Как измерить все, что угодно. Оценка стоимости нематериального в бизнесе" (http://b-ok.org/book/2315676/1b9807, но есть и обновлённое английское издание, существенно дополненное).
Современная онтологика в инженерии требований
Байесовские оценки нужно провести красной нитью через всю инженерию требований. Требования должны быть существенны. Если нас не слишком удивляет невыполнение какого-то требования, то этого требования, может, вообще не должно было бы быть: оно только отвлекает внимание и забирает на себя драгоценное время команды проекта и стейкхолдеров. Так что на каком уровне неопределённости описывать систему -- это важный вопрос.
Но оценки должны делаться для как-то описанной системы. Как описывать систему? Как совмещать рассказы о системе от самых разных стейкхолдеров? Как узнать предметную область системы, существенные её свойства? Почему вдруг сценарии оказались так хороши для описания функций -- можем ли мы как-то усилить, если будем знать причину? Это та же причина, из-за которой оказался успешен behavior driven development (BDD, https://www.infoq.com/news/2018/04/cucumber-bdd-ten-years)? И как находят требования в domain driven design (DDD, https://habr.com/post/334126/, https://en.wikipedia.org/wiki/Domain-driven_design) с его event storm (http://www.russmiles.com/essais/going-events-first-for-microservices-with-event-storming-and-ddd). Онтика/дисциплина (и даже набор дисциплин), в которых требования описывают систему -- это важный вопрос, его не нужно отдавать на самотёк.
Последний вопрос мы уже затрагивали при рассмотрении формальности моделей, и тут тоже не обойтись без онтологики: на каком уровне формальности описывать систему?
Как организовать работу по подготовке "мировоззренческого" курса инженерии требований
Все описанные в данном тексте проблемы требуют исследований. Результаты исследований предлагается сразу формулировать в виде учебного курса по инженерии требований: ибо для чего ещё эти результаты исследований могут быть использованы? Исследования бесполезны, если об их результатах никто не узнает, если они нигде не будут использованы. А чтобы кто-то узнал об этих результатах и использовал их, нужно просто оформить результаты в виде учебного курса.
Понятно, что для каждого отдельного инженерного проекта в зависимости от его условий (предметной области, размеров проекта, опыта команды, наличия инструментария -- моделеров, PLM и т.д.) нужно тщательно выбирать подходящий набор практик инженерии требований -- и даже для похожего проекта с той же командой этот набор практик может меняться, поскольку будет получен какой-то опыт и жизненный цикл опять поменяется. Но это не значит, что инженерии требований нельзя учить. Наоборот, для компетентной работы по выбору подобных практик нужно дать какой-то общий фреймворк/онтику/подход/обобщённую дисциплину/мировоззрение инженерии требований, позволяющую как-то обсуждать и сравнивать различные конкретные практики инженерии требований, берущиеся из разных "больших методологий". Ну, и при необходимости порождать новые практики инженерии требований. Все ведь сегодняшние практики инженерии требований были когда-то придуманы и использованы впервые. Непонятно, почему бы порождение новых практик, тем более при получении новых инструментов с использованием искусственного интеллекта, не продолжалось и сегодня.
Рабочий способ, которым можно было бы получить "мировоззрение" инженерии требований -- это выполнить ходы, описанные для получения "мировоззрений" в "откуда берутся полезные мировоззрения" https://ailev.livejournal.com/1425003.html.
Нужно посмотреть, есть ли в литературе какие-то ответы на вопросы из текущего поста, не хотелось бы изобретать велосипеды самостоятельно. Нужно посмотреть, какие современные подходы/методологии/мировоззрения на инженерию требований хоть как-то отвечают на вопросы из текущего поста.
А далее нужно "распредметиться", сдвинуться по спектру мышления влево и получить догадки о том, какие концепты являются базовыми, общими для всех этих разных дисциплин инженерии требований. Из этих концептов нужно создать новые схемоиды, возможно, предложив при этом решения для различных противоречий, проявящихся при объединении онтик рассматривающихся вариантов практик инженерии требований. Результирующее после преодоления противоречий "мировоззрение инженерии требований" будет "конфигуратором" (см. "творчество в системном мышлении" -- https://ailev.livejournal.com/1425331.html).
Вот этому "мировоззрению инженерии требований" aka "мышлению о требованиях" и нужно будет учить в первую голову, как учим сейчас системному мышлению до знакомства с конкретными практиками системной инженерии. А конкретные практики инженерии требований уже давать вторым проходом после курса мышления о требованиях, и они будут осваиваться легко, будут хорошо согласованы с контекстом других практик инженерного проекта (прежде всего MBCD и архитектурой, а ещё обязательно V&V), а полученное мышление будет сохраняться при переходе от проекта к проекту -- независимо от принятых там решений по использованию конкретных практик инженерии требований. Выпускники курса станут осознанными в своей работе по инженерии требований, и работа эта будет системной.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10212884260315336