Анатолий Левенчук - Системное мышление

Тем самым детальное и в подробностях обсуждение огромных сложных систем принципиально (в силу самой сути системного подхода) может быть разбито на достаточно маленькие части, и ни одна часть этого обсуждения не будет забыта, ни одно описание не будет пропущено. Как съесть слона? По кусочку за раз!

Системное мышление по своей природе коллективно, оно позволяет разделить умственный (по проектированию) и физический (по изготовлению и эксплуатации) труд системы, задействовать множество разных исполнителей стейкхолдерских ролей – и при этом обеспечивается детальное продумывание всех частей системы (холархия!) со всех сторон (множественность частных описаний!).

Но как договориться о том, как склеивать все эти самые разные частные описания самых разных частей системы в одно целое? Как договориться всем этим людям? Это можно сделать на основании 4D экстенсионализма. Все эти описания можно совместить, если понимать, что они описывают одно и то же место в пространстве-времени, относятся к одному и тому же воплощению системы. Без системного подхода сложные проекты с задействованием большого количества разных специалистов выполнить в срок и вовремя невозможно.

Требования являются частью определения системы, и они в силу этого всегда есть: о них не принято говорить, что их разрабатывают (их не придумывают!), их обычно выявляют (discover) в разговорах с различными стейкхолдерами, а также в экспериментах. О требованиях хорошо думать примерно так же, как о цвете системы (который тоже может входить в требования, так что это не самый плохой пример).

Цвет – это не сама система, и это не часть описания системы (описанием для цвета был бы фрагмент текста с номером цвета из каталога цветов, или длиной волны для этого цвета, или названием цвета, или пятно краски нужного цвета, или значения интенсивностей красного-зелёного-голубого в составе цвета, и т.п.). Мы можем обсуждать цвет системы, можем выявлять пожелания к цвету у разных стейкхолдеров, а затем описывать выявленный цвет после выбора адекватного метода описания. Вот и самые разные требования как часть определения системы мы можем обсуждать, выявлять, а затем описывать после выбора метода описания.

Приключения требований на этом не заканчиваются: требования анализируют, затем их наборы делают непротиворечивыми, после чего обеспечивают к ним доступ самых разных стейкхолдеров (это обеспечение доступа и называется управление требованиями/requirements management). Всё вместе называют инженерия требований(requirements engineering). Обратите внимание, что как выявление требований входит в инженерию требований, так и управление требованиями. Управлять нельзя тем, чего ещё нет, а выявленные требования это только сырьё для дальнейшей работы.

В описаниях требования выражаются как спецификации требований, части технических заданий (технические задания обычно – это «задания на работы», требования в них маленькая часть), протоколы технических совещаний и т. п. Требования декомпозируемы: любое требование может быть разбито на множество более мелких, часто говорят о наборах требований.

Есть два понимания требований, которые нужно различать по контексту их употребления (помним, что люди вполне могут разбираться в высказываниях типа «косил косой с косой косой косой на косе» и понимают при этом, что у каждого слова может быть много значений):

1. Требования(requirements) – это часть определения системы, определяющая систему как «чёрный ящик», т.е. что делает система по отношению к её системному окружению, без описания внутренней структуры системы, происходящих внутри системы взаимодействий частей системы. Прежде всего тут важно поведение системы, выполнение ей своего назначения, функции в использующей системе. Поэтому основные требования называют функциональными требованиями. Нефункциональных требований не бывает, хотя в литературе этот термин регулярно встречается, но он считается некорректным: все требования описывают какое-то поведение системы, ожидания этого поведения. Но речь не всегда идёт о поведении в использующей системе. Требования качества в отличие от функциональных, относятся прежде всего к поведению в обеспечивающих системах, в том числе обслуживающих уже готовую систему: по-английски их иногда называют – ilities (reliab ility , accessab ility и т.п.), а по-русски – ости (надёжн ость , доступн ость , и т.п.).

Требованияотличают от потребностей(stakeholder needs, stakeholder requirments) как требований внешних стейкхолдеров к использующей системе. Если мы выходим за пределы инженерии, то у требований могут быть другие имена. Например, для организаций речь может идти о стратегии – но суть тут будет та же самая: описание того, что хотелось бы получить от организации. Требования, взятые вместе со временем их выполнения, называют контрольными точками(milestone). Если требование – это «помидор красный», то «помидор красный, 10 мартобря 2019 года» будет контрольной точкой. Очень часто на контроле стоят не сами требования, а контрольные точки: «дорога ложка к обеду».

2. Альтернативное понимание требования уже не имеет отношения к системному подходу, не связано с границами системы. Это просто любое утверждение, данное в деонтической модальности. Любое высказывание из описания системы (например, «X=10») невозможно как-то понять по отношению к деятельности без указания на модальность(modality) 134 134 https://en.wikipedia.org/wiki/Linguistic_modality : то, как нужно понимать значения высказывания. Скажем, «в системе [существует] X=10» это алетическая (aletic) модальность, модальность существования. «Я верю, что в системе X=10» – это модальность доксическая (doxastic), веры. Деонтическая (deontic) модальность говорит о долженствовании, разрешении, рекомендации 135 135 Ключевые слова для выражения деонтической модальности в требованиях: «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY», and «OPTIONAL» в RFC 2119 – https://www.ietf.org/rfc/rfc2119.txt : «Я требую, чтобы X=10». В этом втором понимании требований можно потребовать что угодно – и оно станет требованием, даже если речь идёт не о чёрном ящике. Например, «в автомобиле должен быть корпус из углепластика», «в смартфоне должны быть использованы отечественные микропроцессоры» относятся к «прозрачному ящику», но слова «должен» и «должны» указывают на деонтическую модальность.

Ограничения(constraints) свободы принятия решений по поводу «прозрачного ящика» связаны именно с таким пониманием: ограничения как высказывания в деонтической модальности по поводу устройства «прозрачного ящика» поступают вместе с функциональными требованиями и требованиями качества, но их часто тоже называют требованиями не по их системному пониманию, а по альтернативному, деонтическому. Поэтому «в автомобиле должен быть корпус из углепластика» является не требованием, а ограничением с точки зрения системного подхода, но «по бытовому» это тоже требование.