Знание о существовании различных видов систем в их относительном положении от целевой системы в системном разбиении позволяет более строго ввести всем знакомые понятия потребностей, требований и ограничений. Но перед этим нам нужно ввести понятие «чёрного ящика» (black box): это какая-то система, которую мы представляем без знаний о внутреннем её устройстве – мы только можем описывать внешнюю границу этой системы (границу занимаемого ей объёма в физическом мире). То есть мы, говоря о «чёрном ящике», описываем только занимаемое место в пространстве-времени, свойства этой системы (не заглядывая в свойства её частей!), ролевое поведение/функцию. Но ничего не знаем о внутреннем устройстве, о подсистемах.
Определение целевой системы как чёрного ящика называют системными требованиями (system requirements). Требования прежде всего содержат информацию о ролевом поведении/функциях системы по отношению к её рабочему/целевому/операционному/функциональному окружению, поэтому часто говорят о функциональных требованиях. «Нефункциональных требований» не бывает (хотя такой термин часто встречается в литературе, но его использовать неправильно), чаще говорят просто о других видах требований – например, требованиях качества, которые интересны не условному «пользователю», а другим ролям в проекте. Требования качества обычно – описание поведения системы при работе в необычных условиях или не в момент эксплуатации: способность работать под высокой нагрузкой, ремонтопригодность, доступность по цене, лёгкость монтажа.
Конечно, терминология может меняться. Например, требования для предприятия вряд ли будут называть именно «требованиями», чаще их называют стратегия (strategy) – какое-то ожидаемое поведение или свойство предприятия как целого, как чёрного ящика (например, стратегия – это на какой рынок будет выходить предприятие, как оно будет себя там вести). Часто слово «системные» опускают и говорят о просто «требованиях».
Требования – это описания системы, они абстрактны и не явлены никак в физическом мире. Чтобы на них посмотреть, или кому-нибудь переслать, нужно иметь их на носителе (неважно, бумажном, электронном или оптическом), то есть иметь документацию требований. Документация требований может быть в самом разном виде: документы стандартов, технические задания, спецификация требований, фрагменты базы данных с информационной моделью. Если во всех этих документах содержится описание целевой системы как «чёрного ящика», то в них тем самым содержатся требования к системе.
Очень часто те люди, которые формулируют требования или стратегию, хотят заодно указать не только внешние свойства системы, описать не только границы системы и её поведение как чёрного ящика, но и указать какие-то детали внутреннего устройства системы: определить (define) части системы (подсистемы), указать на процесс взаимодействия подсистем. В этом случае о системе говорят как о «прозрачном ящике», в нём можно считать известными какие-то подсистемы, свойства и поведение этих подсистем. Если в какой-нибудь «спецификации» или «требованиях технического задания» среди требований встречаются описания прозрачного ящика (описания подсистем, и даже под-подсистем), то их называют ограничениями (constraints). Эти ограничения нужно понимать как ограничения конструкторской свободы команды, которая должна разработать и изготовить систему.
Обычно команда проекта согласовывает с внешним заказчиком системы функции/поведение, которые должна выполнять система как чёрный ящик, свойства этого чёрного ящика, т.е. согласовывает требования, а уж как устроена система внутри, какая у неё конструкция и как она работает, т.е. что там с подсистемами, команда проекта определяет самостоятельно. Важнейшие из этих решений по устройству системы, т.е. решения «прозрачного ящика» называют архитектурой. Но очень часто различные роли в команде заказчика/клиента пытаются принять такие решения за команду проекта (например, кто-то из команды клиента считает, что он в роли инженера лучше, чем исполнители инженерных ролей в команде проекта, или решение принимается из политических или экономических соображений/предпочтений, неизвестных команде проекта), и тогда эти архитектурные решения, поступающие вместе с требованиями, называют ограничениями. Общая рекомендация в таких случаях – согласовывать требования, но торговаться по поводу ограничений (вполне уместно предлагать свои варианты – вполне возможно, что клиент просто не знает о существовании альтернатив и будет вполне согласен с предложениями).
Если рассмотреть надсистему нашей целевой системы как чёрный ящик, то она будет целевой для команды важнейших внешних ролей проекта. И её описание будет требованиями для этих внешних ролей. И это описание часто так и называют: требования стейкхолдеров (stakeholder requirements), а чтобы меньше путать это описание надсистемы-как-чёрного-ящика с описаниями целевой системы, чаще называют потребностями стейкхолдеров (stakeholder needs, нужды стейкхолдеров), или ещё короче – потребностями. Как чёрный ящик описывается надсистема потребностями (стейкхолдеров), целевая система (системными) требованиями.
А что будет, когда разработчики целевой системы создадут архитектуру, описав важнейшие решения по устройству целевой системы как прозрачного ящика? Они ведь опишут подсистемы! Да, и эти описания будут требованиями к подсистемам. Если эти подсистемы станут целевыми системами для команды каких-нибудь контракторов, разрабатывающих и/или изготавливающих эту подсистему, то они будут называть эти «требования к подсистеме» своими «системными требованиями». А как они будут называть системные требования для целевой системы нашей начальной команды, для которой они контракторы? Они их будут называть потребностями, ибо наша исходная целевая система для них – надсистема. Системное мышление рекурсивно, оно применяется одинаково на каждом системном уровне, каждой командой. И каждая команда имеет свои «системные координаты» вокруг своей целевой системы, поэтому самое важное – это договориться, что же это за система.
Исполнители ролей, которые замышляют, проектируют, изготавливают, ликвидируют целевую систему – это команда проекта, эти исполнители играют внутренние проектные роли (команда определяется её подчинённостью, как она сотрудничает и работает совместно, но в ней важны роли, которые она может играть. Команда проекта плюс вверенное ей оборудование/средства производства – это оргзвено). А внешние роли/стейкхолдеры? Это те, кто напрямую не подчиняются в выполнении своих ролей исполнителям ролей в команде проекта. Есть и промежуточные ситуации: команда подрядчиков из другой фирмы, занятая нашей целевой системой, считается исполнителями внутренних ролей, поскольку формально она работает над нашей целевой системой (например, делает какую-то подсистему для этой целевой системы, или оказывает какой-то сервис, помогающий сделать целевую систему), а не над нашей надсистемой. Но она же считается внешней, ибо подчинение исполнителей ролей в рамках контракта будет только частичное. Так что роли в команде клиента – внешние, роли в команде проекта по обеспечению целевой системы— внутренние, а роли в команде подрядчика – серая зона, разные люди считают их разными (хороший тон считать их внутренними, но жизнь часто заставляет просчитывать ролевые интересы и предпочтения, и особенно намерения этих людей примерно так же тщательно, как для внешних ролей – «на Аллаха надейся, а верблюда привязывай»).
В предыдущем абзаце явно связывались отношения подчинения исполнителей ролей определяемое им деление на внутренние и внешние роли с системным мышлением. Да, современное системное мышление не только про сложные технические системы. Оно и про людей, которые эти системы обеспечивают (т.е. замышляют, разрабатывают, изготавливают, владеют и обслуживают в ходе эксплуатации, а затем ликвидируют). Тем самым системное мышление не только применимо в инженерных рассуждениях, оно применимо и в менеджерских рассуждениях, и в предпринимательских рассуждениях. Оно трансдисциплинарно: оно позволяет в том числе объединить рассуждения инженеров, менеджеров, предпринимателей и ролей из других сфер деятельности, договорить их всех друг с другом в рамках коллективного мышления, коллективной деятельности по обеспечению систем.
Источник: учебник А.Левенчука «Системное мышление 2019»