Предпринимательство и инженерия требований
Догадаться/guess о подходящей целевой системе, её месте в окружении (и потом прийти по цепочке обеспечения или системным уровням окружения к "нашей системе", совпадающей или не совпадающей с целевой) -- это задача прежде всего предпринимателя. Да, она в существенной мере пересекается с задачей инженера по требованиям, но инженер по требованиям всё-таки получает на входе от предпринимателя готовую идею/guess, которую критикует и дальше помогает улучшить (уточнить и дополнить, исправить возможные ошибки, документировать). Предпринимательство не алгоритмизируемо, оно базируется на диких догадках, и лучшие из них -- это взять какую-то конструкцию "сбоку" (из какой-то другой предметной области) и предложить её как основу для выполнения функции целевой системы (то есть предприниматель на выходе имеет грубую и недетализированную идею архитектурного решения, часто на паре уровней -- 1. целевая система в составе надсистемы и 2. архитектурное решение самой целевой системы: подсистемы в составе целевой).
Предпринимательство -- это догадки, изобретательство, риски, отсутствие алгоритма, удача как неотъемлемая часть деятельности. Поэтому нельзя задавать вопрос "как надо думать, чтобы определить целевую систему". Можно обсуждать, как покритиковать предлагаемые варианты, но откуда брать варианты -- из фантазии, нейронного шума, ассоциаций, случайных озарений, но не в результате систематической работы по какому-то алгоритму!
Можно ли тогда уйти от определения целевой системы? Нет, нельзя. Ибо если не делаете целевую систему (не принимаете участия в её создании), не меняете мир, то деятельность ваша не имеет смысла. Вы должны понимать, чем занимаетесь.
Есть самые разные предпринимательские стратегии, варианты этих стратегий можно обсуждать как раз на схеме системного мышления и схеме системных уровней (я это делаю в докладе "Большие предпринимательские программы: Дженсен Хуанг, Элон Маск и все-все-все", https://vimeo.com/553816090 (первый на этом видео, слайды https://yadi.sk/i/6UCRvQq51ngj5Q). Например, можно потихоньку идти вверх по системным уровням (стратегия NVIDIA: делать платы вокруг чипов, сервера вокруг плат, датацентры вокруг серверов) или вверх по цепочкам обеспечения (предоставлять спутники связи, для их запуска делать свой космофлот, для производства ракет в космофлоте строить уникальные заводы -- планируется выпуск огромных кораблей Starship каждые 72 часа).
Выбор целевых систем редко делается в рамках какого-то одиночного проекта, это часто часть какой-то предпринимательской стратегии. Опять же, всегда нужно проверять: вы хотите заняться проектом и он соответствует стратегии, или вам лучше бросить проект, или вам лучше поменять стратегию так, чтобы новый проект шёл уже в соответствии с новой стратегией?
Так что верхнеуровневые рассуждения по поводу целевой системы и нашей системы лучше всего делать, поглядывая на диаграмму сути системного мышления и с мыслями о стратегии и стратегировании:
Представьте себе целевую систему в физическом мире
Вы должны прямо как Тесла (который по легендам умел представить у себя в голове работающее физическое устройство) представить вашу целевую систему в момент эксплуатации, в физическом окружении. Вот небольшой список контрольных вопросов:
-- это точно время эксплуатации/run-time, а не дизайн-тайм? Это не момент "продажа как эксплуатация людьми из обеспечения"? Там бенефициары/эксплуатанты из run-time?
-- система "перед внутренним взором" работает (то есть вы видите как бы "кино", а не статическую картинку) и выделяется из своего окружения вниманием (а не разбирается на части!). Скажем, печень в человеке представляется работающей, а не вынутой отдельно из человека. Надсистема физически вокруг ("окружение"! молекулы окружения вокруг или рядом с целевой системой. Всякие информационные интерфейсы тоже можно обсуждать, но и тут представить физичность очень помогает -- например латентность на этих интерфейсах вы сразу заметите!). Учитывать надсистему, представлять её обязательно! Почитайте пост одного из наших студентов, как нервно получается, если этого не делать: https://blog.system-school.ru/2021/06/26/osoznanie-rokovyh-oshibok-s-pomoshhyu-sistemnogo-myshleniya/
-- не забывайте, что в учебнике на эту тему ещё много чего говорится (например, "если у вас софт, то посмотрите на людей вокруг плюс софт как один из кандидатов, на описываемую базами данных софта систему как другой кандидат")
-- выделяйте вниманием такие границы системы, которые никто до вас не заметил. Пример: мышечные ленты в теле как целевые для каких-то проектов работы с телом (эти ленты как особые объекты выделены в системном фитнесе).
Попробуйте заменить тип какой-то системы в цепочке или окружении
Попробуйте теперь заменять какие-то системы по цепочке: что изменится? Если ничего, то берите что-то поближе к вашей системе. Например, вы делаете систему операционного управления сооружением/стройкой на стадии проектирования строительства завода на базе Synchro (куплен Bentley) или Navisworks (будете прокручивать на экране видеоролики строящегося завода в поиске коллизий типа возведения крыши в тот момент, когда ещё нет стен и даже колонн для поддержки крыши). И утверждаете, что завод -- это и есть целевая система, обеспечение завода -- это стройка, а вы обеспечиваете стройку (график выхода подрядчиков/план организации строительства корректируется с использованием вашей системы). Вопрос: то, что будет выпускать завод -- не это ли ваша целевая система? Предположим, что это самолёты, или обогащённая руда, или полупроводниковые чипы. Что поменяется в вашей системе при таких заменах? Завод-то будет другим! Но в вашей системе не поменяется состав, не поменяются практики: ваша система операционного управления стройкой будет ровно той же самой, хотя данные в ней и будут каждый раз по другому набору заводских систем. А если завод заменяем на дачный домик или ракету? Вот тут резко меняются методы сооружения (строительства и монтажа), и могут потребоваться совсем другие решения по системе операционного управления сооружением, в том числе выбор другого софта (и это означает, что у вас будет другой проект, другая ваша система). То есть целевой системой лучше таки считать завод, а не продукцию завода.
Никогда нельзя забывать, что целевая система это не "объективно существующая", а привязанная к вашему проекту. Поэтому "пошевелить" возможный состав потенциальной целевой системы (контрфактульное мышление, о возможных мирах, в которых всё то же самое, что в нашем, но какой-то один момент отличается) -- это хороший мыслительный приём, позволяющий оценить "наш" проект от потенциально бесконечного количества всех возможных проектов, хороший ход против переобобщения. Конечно, тянуть цепочку обеспечения как можно дальше (думать о клиенте клиента) это правильно, но нужно ещё и экономить мыслительные/вычислительные ресурсы. Ход с "мысленной заменой" позволяет обрезать лишние звенья цепи. Что при таких заменах не меняется -- это ваше, а что меняется -- это уже проекты людей дальше по цепочке обеспечения, или дальше по уровням окружения.
UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10221319900841077