[БЕЗ СЛОВ] Есть воплощение системы. И это воплощение системы, мы всегда считаем, как-то определено. Как именно оно определено? Оно определено своими требованиями, то есть как «черный ящик», определено архитектурой, то есть важными решениями о том, как устроена эта система, и определено неархитектурной частью проекта в смысле дизайн, то есть теми описаниями, которые нужны для того, чтобы изготовить эту часть системы с соответствующей точностью. Итак, возьмем требования. Что такое требования как часть определения системы? Я сейчас не говорю о требованиях рабочих продуктов, всяких спецификациях, текстах стандартов, текстах технического регулирования, решениях вчерашнего совещания, где мы приняли решение, что будем делать систему вот с такими характеристиками. В рабочих продуктах могут требования называться как угодно. А мы сейчас говорим о теоретическом объекте требования. Требование — это нечто, что мы должны выполнить. Это такое вот вульгарное, простое понимание требования. Мы говорим, что x должен быть равен 10, это означает, что x в деонтической модальности долженствования должен быть 10. X разрешается, что он будет 10. X рекомендуется, чтобы он был дан 10. То есть мы берем любое нейтральное высказывание (x, 10) и просто приписываем какое-то долженствование, разрешение, дозволение, рекомендацию. Бывают и другие модальности. Например: я верю, что x = 10. Это докса, «я верю» – доксическая модальность. Бывает алетическая модальность: x = 10, существует такой x, который равен 10. Но в случае требований, мы говорим о деонтической модальности. Каждый раз, когда мы находим высказывание в такой модальности, то мы понимаем, что это требование. С другой стороны, если отбросить то, что мы любое описание называем требованиями, помним, что «косил косой косой косой» — каждый раз использование слова обозначает немножко разное, то мы понимаем, что мы можем сказать и архитектуры — требования, то есть, когда мы имеем архитектурные описания; и требования проекта; требования программы; требования чего угодно, которое не равно тому требованию, которое мы обсуждали в начале. То есть, это определение системы на границе системы как «черного ящика». Чаще всего это функциональное определение системы. Итак, мы понимаем, что есть два разных значения. Первое: это система на границе «черного ящика», и второе: это все, что угодно, любое высказывание в деонтической модальности. Мы считаем в целях нашего курса, что главным образом мы говорим о тех требованиях, которые означают описание системы на ее границе как «черного ящика», не залезая внутрь. Тем не менее, очень часто требования в паре идут с потребностями внешних стейкхолдеров. То есть внешние стейкхолдеры, не команда проекта. Требования идут в паре с потребностями. И иногда они идут в паре с ограничениями, то есть люди, которые указывают требования, часто указывают, что хочется иметь от использующейся системы и часто еще указывают, что они хотят иметь от каких-то подсистем, считая, что они ограничивают свободу проектировщиков, свободу конструкторов, свободу разработчиков данной конкретной целевой системы. Мы понимаем при этом, что требования у нас могут быть набором требований. То есть мы требования декомпозируем. Если мы описали какую-то функцию систему, мы эту функцию как-то можем, не погружаясь внутрь системы, даже как-то декомпозировать, описывая ее разными, например, фразами на русском или английском языке, или даже какими-то картинками. Еще мы понимаем, что очень хочется в производственном проекте не просто говорить, что у меня есть требование такое-то, чтобы система была красной. Смотрите: «чтобы была» — деонтическая модальность, система должна быть красной. Мы хотим, чтобы она красной была, например, к 15 мартобря. То есть мы описываем условия какие-то, которым должна удовлетворять система как требования, приписываем время и в этот момент требования становятся контрольной точкой. Контрольная точка состоит из времени и требования. Кроме того, мы понимаем, что если у нас система обеспечивающая, то есть мы говорим о людях, предприятиях, то очень странно сказать, что у меня требования к предприятию такие. Но некоторые языки архитектурные предприятия, например язык ArchiMate так и говорит: «Почему бы не быть требованиям к предприятию, вот можно прописать требования к этим 2 000 человек». Но чаще всего мы говорим не «требования», а используем другое слово — «стратегия». Ну и, в принципе, мы же понимаем, что в мышлении у нас все равно будут требования, мы будем мыслить про требования, а в реалии мы будем понимать, что это называется по-другому, документ может с требованиями называться «стратегия», или, как мы говорили, «опросный лист», или «спецификация», как-нибудь по-другому. Вот мы видим из стандарта, посвященного требованиям к системам, ISO/IEC 29148:2011 года, мы видим типичную картинку: вы видите стрелочки большие зеленые указывают, что на разных границах систем у нас разные требования. То есть у нас есть халархия (отношения часть-целое) между софтом, каким-то элементом системы, внутрь которого входит софт, какая-то система, возможно, целевая, система, которая эксплуатирует эту систему, использующая более широкую систему деятельности, куда входит эта система, какое-то организационное окружение операционное (помним всегда, что если вам встретилось слово Environment, это явное указание на использующую систему). И вот на разных границах вот этой халархии вы можете иметь разные наборы требований, и стандарт так и говорит, что когда вы работаете с требованиями, вы всегда должны помнимать, какую из структур системы вы описываете. Требования всегда относятся к какому-то объекту, к какой-то системе, подсистеме, надсистеме, к какому-то окружению. И заодно запомнили просто, это не прямо относится к нашему курсу, но на всякий случай, что слово «бизнес» (вы видите замечание в этом стандарте) — если вы видите бизнес-требования, или вы видите бизнес-процессы, то есть любое слово со словом «бизнес», очень часто айтишники этим словом называют организацию. То есть, вы смело можете заменять, особенно если это предприятия административные, или некоммерческие предприятия, вы смело можете заменять словом «организационные». То есть не бизнес-требования, а, например, организационные требования. И еще важный момент с требованиями, что требования всегда чьи-то. В 1995 году — это не так давно, замечу, 1995 год — было замечено австралийскими исследователями, что агенты, то есть те, кто принимает решения, у них есть намерения. И когда они чего-то хотят, чего-то требуют, чему-то назначают какое-то поведение (это и есть, собственно, требования, функциональные в большинстве своем требования), то это означает, что у них есть intent, у них есть «намерение». И это важно понимать: кто, что требует и почему требует. И эти люди сделали подход, назвали его I*, это имя собственное — I*, и они тем самым сформулировали новую дисциплину — Goal-Oriented Requirements Engineering. Оказывается, это требования для того, чтобы достичь чьих-то целей, чьих-то намерений. Goal-Oriented Requirements Engineering говорит о моделях требований. Моделями требований называются такие способы представления требований, в которых мы кроме самих требований, пишем еще и кто эти требования и почему эти требования сделал. Вот вы видите, что в этом подходе явно есть значки и для актора, и для агента, и для роли и для позиции. И совсем немножко для цели, задачи, ресурса, подцели... То есть мы видим, что с требованиями мы имеем чуть ли не половину значков, выражающих чьи-то требования. Помните мы говорили, что есть стейкхолдеры, исполнители ролей стейкхолдеров, есть вакансия организационная. Для людей обычно требуется много объектов для того, чтобы как-то о них говорить. Вот все они должны быть записаны в моделях требований. И есть стандартны инженерные. Стандарт международного союза телекоммуникаций. Вот вы видите этот стандарт Z.151, который вот этот фреймворк фактически выводит для телекоммуникационной отрасли в качестве важного. И вы видите, что там Goal-Oriented Requirements Language, где вы прописываете всех этих стейкхолдеров, и еще Use Case Maps. Поскольку мы говорим о функциях, мы говорим о поведениях, то мы говорим, что есть варианты использования, то есть есть некоторые «сценарии» использования. И есть множество таких специализированных языков в целеориентированной инженерии требований, и упоминание действующего лица и его действий — это норма для работы с требованием. Действие указывает на функции и вы видите, что когда мы рассматриваем Use Cases, «варианты использования», вы видите, что существенные требования ухватываются диаграмкой, в которой показаны человечки, то есть те, кто действуют, и их действия. И мы переходим в мир процессов, мир глаголов, мир назначений, и мы можем вот так говорить о функциях системы. В программе инженерии есть более простой вариант — User Story, и там применяется шаблон, который тоже каким-то образом является целеориентированной моделью для требования. Там нельзя говорить просто «формулировка требования». Там говорится так: «Я, как стейкхолдер, хочу, чтобы система...» и далее формулировка требования. «... для того, чтобы», и далее потребности для Using System, которые требуется удовлетворить, если мы делаем вот эту вот формулировку требований. То есть, стейкхолдерам запрещено говорить, что просто «хочу вот это» и не говорить кто сказал как стейкхолдер, то есть какая оценка потом будет интереса. И запрещается говорить просто так «хочу вот это», требуется говорить, какую свою потребность он реализует, если он требует вот это от целевой системы. Итак запомнили: у нас есть требования. Требования в деонтической модальности всегда, то есть всегда есть долженствование какое-то, если это требования. Требования описывают на внешней границе системы, прежде всего ее поведения. Бывают, конечно, требования качества: надежность, ремонтопригодность, но все равно это на внешней границе, мы не описываем как это делать внутри. Это не потребности, не архитектура, и мы понимаем, что вы не можете ничего сказать, что вы хотите от вашей целевой системы, если вы при этом не заявляете кто вы, какая у вас потребность, то есть какие свойства использующей системы будут на ее уже внешней границе, для того, чтобы вы требовали вот это от целевой системы.
