Функции, capabilities, services, требования в разных подходах к архитектурным описаниям
1. Архитектура (ISO 42010 --architecture (of a system): fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution) у системы всегда есть, это архитектурных описаний (ISO 42010 --architecture description: work product used to express an architecture) иногда нет, а иногда есть и несколько разных для одной и той же системы.
2. Архитектура -- это архитектура системы. Систему нужно как-то выделить из окружающего мира и назвать. В системном подходе система определяется/задаётся её функцией в надсистеме. Задание системы через её конструкцию, внутреннюю организацию, механизм, материал, структуру и т.д. (т.е. задание системы через перечисление элементов и их взаимодействие, "вовнутрь системы", "белый ящик") является ошибкой и ложным пониманием системного подхода -- система всегда задается "снаружи", как "чёрный ящик". Тем самым в каждый подход к архитектурному описанию (ISO 42010 -- architecture framework: conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders) так или иначе включает в себя:
а) описание функций системы как отдельную тематическую группу описаний (ISO 42010 -- architecture view: work product expressing the architecture of a system from the perspective of specific system concerns), отражающую необходимость целевой системы для объемлющей надсистемы
б) если подход к архитектурному описанию содержит какие-то указания на метод архитектурной работы (из ISO 42010: architecting -- process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle), то описание функций системы обычно становится первым же разрабатываемым артефактом.
3. В разных подходах к архитектурному описанию (architecture framworks) системозадающая функциональная группа описаний называется по-разному:
-- DoDAF 2.02 (http://cio-nii.defense.gov/sites/dodaf20/capability.html): capability (с отдельными моделями Vision, Capability Taxonomy, Capability Phasing, Capability Dependencies, Capability to Organizational Development Mapping, Capability to Operational Activities Mapping, Capability to Services Mapping) --
-- TOGAF (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html): business functional decomposition diagram, data entity/business function matrix, business service/function catalog, application system/function matrix
-- RM-ODP (http://rcurinf01.uco.es/rmodpwiki/index.php/Resources): computational viewpoint (which enables distribution through functional decomposition on the system into objects which interact at interfaces. It describes the functionality provided by the system and its functional decomposition).
-- традиционный диаграммные техники системной инженерии: фукнциональная группа описаний и функциональная архитектура (например, в главе 6 тут -- https://sites.google.com/site/themanagersguide/system-engineering, фукнциональная архитектура -- это FFBD, functional flow block diagram и отнесённые/allocated требования)
-- ARIS (http://www.google.com/search?q=ARIS+function+tree): function tree
-- DEMO (http://www.demo.nl/publications): organization construction model (хотя тут не всё так просто, и чистых "функций" или "capabilities" нет, но акторы называются по их функциям, включая представление всей организации как актора, а трансакции -- это интерфейсы между функциями). Более точно функции тут связаны с production -- продукты или сервисы, которые оргсистема поставляет окружению. Еще более точто -- это business, слово в DEMO почти синонимично function (в то время как organization, information и IT -- это construction в DEMO, противопоставляемое function во всех архитектурных диаграммах).
-- ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/chap4.html): business function.
-- UML/SysML -- впрямую функциональное описание выразить нельзя! Но UML/SysML не подход к архитектурному описанию, это только лишь язык, причём убогий (пардон май френч).
Проблема только в том, что определенность и осмысленность функциональных описаний во всех этих подходах мнимая:
-- терминология используется более чем произвольно, и даже слово "функция" свободно используется сразу в нескольких значениях;
-- большинство подходов не основаны на парадигме системного подхода (хотя все они свободно употребляют слово "система", но больше в бытовом его значении, а не осмысленно), поэтому не имеют дуализма функция-"чёрный ящик" vs конструкция-"белый ящик".
4. Конечно, в онтологическом подходе к мэппингу функциональной группы описаний одних подходов к архитектурному описанию к аналогичной группе других подходов нужно не обращать внимания на "языковые метки", чтобы от спора о бытовых и специальных значениях использованных в качестве терминов слов перейти к онтологическим (связанным с реальным миром, а не лингвистическими особенностями использованных для именования слов) ответам на вопрос "что это". Тем не менее, полностью исключить влияние "лингвистического фактора" и абстрагироваться от используемых слов не удастся.
Работа по созданию онтологии Gellish показала, что у слова "функция" есть минимально пять разных значений: 1. подтипа активности -- процесса или события, 2. какой-то сущности в определенной роли или сделанной для определенной роли, 3. самой роли сущности, обычно в физической вещи, которую эта вещь играет в активности, 4. указания на связь, например корреляция между какими-то аспектами -- ежели высота растёт, то давление падает, 5. математическое отношение между числовыми объектами, определяющее их соотнесение/mapping. Конечно, путаница неизбежна.
Ключевой ход -- это рассмотрение функций в связи с модуляризацией системы. Целевая система -- это модуль (заменяемый!) в надсистеме, а ее функциональные определения подсистем связаны также с их модульностью (заменяемостью). Так что ключевым является рассмотрение "функциональности" в строгом соответствии с системным подходом: если есть какая-то "функция", то можно выделить какую-то систему, выполняющую эту функцию, и надсистему, в которой эта функция определена/осмыслена. Тем самым получается не произвольно дробное выделение функций, а хоть как-то соотнесенное с дробностью самой системы в её физическом (или программотехническом, информационном) воплощении. Подробнее про "гамбургер-диаграмму", выражающую такой мыслительный ход на совмещение уровней модульности системы и уровней определения функций, см. в http://ailev.livejournal.com/920248.html
Если все эти функционально определенные подсистемы имеют независимое администрирование, то мы получаем систему систем во всей её красе -- где архитекторам можно только "влиять", но не "командовать".
Диаграмма "гамбургера", в том числе в заимствованном в онтологии ISO 15926 виде (см. http://ailev.livejournal.com/920248.html), критика "несистемноподходности" TOGAF со стороны DEMO (http://www.sapio.nl/sapio2010/pdf/jd236_togaf.pdf), а также множество других работ сводятся к одному: в большинстве подходов к архитектурному описанию нет системноподходности (двойственного рассмотрения каждой системы как задаваемой снаружи модуля-функции, поддерживаемой изнутри модульной же конструкцией-механизмом-материалом-организацией-и-т.д.), и тем самым эти подходы не являются в полной мере архитектурными подходами к описанию систем. Они (включая даже TOGAF) описывают что-то, не являющееся системами.
5. Современные архитектуры рассматриваются как сервис-ориентированные (SOA). Это просто отражение того факта, что любая функция системы может быть представлена как интерфейс, а взаимодействие систем (определяемое как взаимодействие функций через их интерфейсы) представлено через протокол, описываемый сервис-контрактом. Это прямое отражение замечания по связи функциональности (возможности выполнения функции, capabilities) и модульности (т.е. привязки capabilities/function к физической нарезке мира, "приложениям" или "оборудованию"). Вместо прямой трассировки функций к (под)организации, бетону, железу или софту мы получаем еще один уровень косвенности: функции привязываются к сервисам, а уже сервисы реализуются железом или софтом. Если теперь подменить реализацию сервиса, система не изменится. Функция -- это спрос на систему, сервис --"черный ящик" отвечающего на этот спрос предложения, поддержанного системой.
Сервис в заходе "чёрного ящика" как бы реифицирует отношение функции/требуемой возможности и (железной) подсистемы, представляющей эти возможности.
В последнее время появился новый тренд: рассмотрение сервиса не как "чёрного ящика", а "белого ящика", который позволяет связать функцию с поведением обеспечивающей её системы. Онтологически сервис сервис определяется как событие, существующее в течение интервала времени t, напротяжении которого поставщик сервиса явно обязуется выполнять работы в соответствии с зафиксированным описанием и в интересах клиента (http://www.loa-cnr.it/Papers/FerrarioGuarinoFIS08Proceedings.pdf). Выделение сервиса как особого онтологического объекта, позволяет подробно описать это сложное отношение между требуемой функцией и поведением системы, реализующей эту функцию. Сервисы позволяют перейти к языку акторов, ответственных за рабочие трансакции, в том числе задав ход на работу с правами по использованию сервисов (legal perspective -- http://www.loa-cnr.it/Papers/FerrGuarFern.pdf). Самая свежая статья этой серии, описывающей подобный подход к онтологическому описанию сервисов -- http://www.loa-cnr.it/Papers/WI_2011_service_ontology_final.pdf
6. "Требования" в моделе-ориентированном подходе перестают быть как отдельным артефактом, а определяются как указание на деонтическую модальность каких-то определяющих систему артефактов (http://ailev.livejournal.com/900086.html), например, указание "должны быть реализованы" для архитектурных описаний (т.е. для функций, capabilities, сервисов и т.д.). Особо отметим, что в таком подходе нет "нефункциональных требований", ибо все требования так или иначе сводятся к функциям/capabilities/удовлетворению сервисных контрактов и т.д.
Нужно особо оговорить, что практики инженерии требований и инженерии системной архитектуры, тем не менее, остаются разными практиками, ибо требуют разного тренинга. Инженер по требованиям работает с заинтересованными сторонами и обеспечивает их выявление, и их переговоры, а инженер-архитектор предлагает системную архитектуру (http://ailev.livejournal.com/805721.html, и боле раннее описание работы инженера по требованиям в http://ailev.livejournal.com/810548.html).
В любом случае, использование понятия "требования" весьма запутанно (см., например, http://ailev.livejournal.com/901202.html -- требования как программа, метод, модель, интеракция) и связывается всё более со старинным немоделеориентированным и недатацентрическим документарным подходом с полнотекстовыми бумажными документами. Современная моделеориентированная и датацентрическая системная инженерия предусматривает фиксацию всей необходимой информации о нуждах заинтересованных сторон в инженерных информационных системах с моделеориентированной и датацентричной архитектурой (http://ailev.livejournal.com/934700.html). Дальше каждый предыдущий базис (baseline) информационной модели становится требованиями для разработки следующего -- см., например, ряд: 1. user needs, 2. ConOp, 3. architecture, 4. design, 5. as built.
Тем не менее, наиболее близко к "требованиям" стоит функциональная группа описаний (или группа описаний "возможностей", capabilities). Более того, в некоторых учебниках деонтический статус, придаваемый описаниям из других групп предлагают называть не "требования", а "ограничения" (constraints), и часто отмечают при этом их как "нефункциональные требования". С другой стороны, есть традиция считать любые требования функциональными (например, Donald Firesmith выступает против термина "нефункциональные требования" -- любые требования функциональны, они описывают функцию системы для какой-то заинтересованной стороны, вписывают целевую систему в важную для этой заинтересованной стороны надсистему). Постоянная дискуссия о разнице между "требованиями" и "ограничениями" приводит к тому, что "чистые требования" в конце концов становятся функциональной группой описаний системной архитектуры, а "ограничения" входят в другие описания. Jan Dietz продолжает эту линию в противоположную от "требований" сторону и определяет уже всю архитектуру как "ограничение" (а не "требование" -- чисто уже лингвистическая разница) для принимаемых проектных (design) решений.
В любом случае, в GORE (goal-oriented requirement engineering) видно, что "цели" (требования) в моделях связаны с какими-то архитектурными идеями -- т.е. не существуют сами по себе. Вместо традиционного языка полнотекстовых требований используется язык "цели -- средства", или "функции/capabilities -- конструкция (в том числе механизм, материал, структура, организация, технология и т.д.)".
7. Разработка функционального описания может вестись самыми разными методами. Чаще всего предлагается определить сценарии (use cases), по факту являющиеся процессами (развертками во времени) надсистемы, и использовать их для формулирования функций/capabilities. Эти процессы-use cases нельзя путать с внутренними процессами (механизмом работы системы), ибо эти механизмы-процессы формулируются уже как реализационные, т.е. архитектурные/проектные решения -- и они дальше определяют сервисы, а уже сервисы определяют потребных акторов (человечьих и нечеловечьих). Хотя этот пункт сформулирован исходя из "сервиса как черного ящика", подход "белого ящика" может потребовать и других рассмотрений.
8. Итого:
-- требования и архитектурное описание сегодня уже не так хорошо различимы, как еще десяток лет назад
-- под любыми словами (функции, capabilities, services, требования и т.д.) разные подходы имеют ввиду совершенно разные вещи (часто эти разные вещи имеются ввиду и в рамках одного и того же подхода, ибо для них не выполняется онтологическое моделирование).
-- архитектурные описания могут быть разработаны в рамках системного подхода и учитывать необходимость модульности в конструкции системы, а могут быть разработаны не в рамках системного подхода. Громкие трейдмарки типа TOGAF или ARIS тут не являются гарантами, скорее уж наоборот.
-- переход от функций к capabilities, и разбирательство с обязанностями одних частей системы выполнять процессы для других частей системы (т.е. разбирательство с сервисами и организацией-по-DEMO) приводят к существенным изменениям в методах архитектурного описания. Этот переход активно идёт последние пять лет. Поэтому книжки по архитектурным описаниям, выпущенные ранее 2006 года я бы вообще не рекомендовал читать, и древними подходами к архитектурным описаниям я бы тоже не рекомендовал пользоваться.
-- существующие подходы к архитектурным описаниям следуют современным трендам в самой разной степени и чаще всего представляют собой эклектику, проштампованную бюрократией организаций по стандартизации. Из наиболее перспективных для описания enterprise architecture нужно выделить подходы DEMO и ArchiMate (кстати, в ArhiMate пытались учитывать в том числе и DEMO), а в части разбирательства с сервисами -- general service model на базе онтологии DOLCE.
-- в области методов архитектурных описаний нужно выполнять практику управления технологией (http://ailev.livejournal.com/936356.html): со старых, двадцатилетней давности методов архитектурной работы нужно вовремя соскакивать, и осваивать новые. Для моделеориентированной системной инженерии подойдёт отнюдь не любой подход к архитектурному описанию -- и, скорее всего, такой подход (например, praxos) только предстоит создать.
2. Архитектура -- это архитектура системы. Систему нужно как-то выделить из окружающего мира и назвать. В системном подходе система определяется/задаётся её функцией в надсистеме. Задание системы через её конструкцию, внутреннюю организацию, механизм, материал, структуру и т.д. (т.е. задание системы через перечисление элементов и их взаимодействие, "вовнутрь системы", "белый ящик") является ошибкой и ложным пониманием системного подхода -- система всегда задается "снаружи", как "чёрный ящик". Тем самым в каждый подход к архитектурному описанию (ISO 42010 -- architecture framework: conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders) так или иначе включает в себя:
а) описание функций системы как отдельную тематическую группу описаний (ISO 42010 -- architecture view: work product expressing the architecture of a system from the perspective of specific system concerns), отражающую необходимость целевой системы для объемлющей надсистемы
б) если подход к архитектурному описанию содержит какие-то указания на метод архитектурной работы (из ISO 42010: architecting -- process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle), то описание функций системы обычно становится первым же разрабатываемым артефактом.
3. В разных подходах к архитектурному описанию (architecture framworks) системозадающая функциональная группа описаний называется по-разному:
-- DoDAF 2.02 (http://cio-nii.defense.gov/sites/dodaf20/capability.html): capability (с отдельными моделями Vision, Capability Taxonomy, Capability Phasing, Capability Dependencies, Capability to Organizational Development Mapping, Capability to Operational Activities Mapping, Capability to Services Mapping) --
-- TOGAF (http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap35.html): business functional decomposition diagram, data entity/business function matrix, business service/function catalog, application system/function matrix
-- RM-ODP (http://rcurinf01.uco.es/rmodpwiki/index.php/Resources): computational viewpoint (which enables distribution through functional decomposition on the system into objects which interact at interfaces. It describes the functionality provided by the system and its functional decomposition).
-- традиционный диаграммные техники системной инженерии: фукнциональная группа описаний и функциональная архитектура (например, в главе 6 тут -- https://sites.google.com/site/themanagersguide/system-engineering, фукнциональная архитектура -- это FFBD, functional flow block diagram и отнесённые/allocated требования)
-- ARIS (http://www.google.com/search?q=ARIS+function+tree): function tree
-- DEMO (http://www.demo.nl/publications): organization construction model (хотя тут не всё так просто, и чистых "функций" или "capabilities" нет, но акторы называются по их функциям, включая представление всей организации как актора, а трансакции -- это интерфейсы между функциями). Более точно функции тут связаны с production -- продукты или сервисы, которые оргсистема поставляет окружению. Еще более точто -- это business, слово в DEMO почти синонимично function (в то время как organization, information и IT -- это construction в DEMO, противопоставляемое function во всех архитектурных диаграммах).
-- ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/chap4.html): business function.
-- UML/SysML -- впрямую функциональное описание выразить нельзя! Но UML/SysML не подход к архитектурному описанию, это только лишь язык, причём убогий (пардон май френч).
Проблема только в том, что определенность и осмысленность функциональных описаний во всех этих подходах мнимая:
-- терминология используется более чем произвольно, и даже слово "функция" свободно используется сразу в нескольких значениях;
-- большинство подходов не основаны на парадигме системного подхода (хотя все они свободно употребляют слово "система", но больше в бытовом его значении, а не осмысленно), поэтому не имеют дуализма функция-"чёрный ящик" vs конструкция-"белый ящик".
4. Конечно, в онтологическом подходе к мэппингу функциональной группы описаний одних подходов к архитектурному описанию к аналогичной группе других подходов нужно не обращать внимания на "языковые метки", чтобы от спора о бытовых и специальных значениях использованных в качестве терминов слов перейти к онтологическим (связанным с реальным миром, а не лингвистическими особенностями использованных для именования слов) ответам на вопрос "что это". Тем не менее, полностью исключить влияние "лингвистического фактора" и абстрагироваться от используемых слов не удастся.
Работа по созданию онтологии Gellish показала, что у слова "функция" есть минимально пять разных значений: 1. подтипа активности -- процесса или события, 2. какой-то сущности в определенной роли или сделанной для определенной роли, 3. самой роли сущности, обычно в физической вещи, которую эта вещь играет в активности, 4. указания на связь, например корреляция между какими-то аспектами -- ежели высота растёт, то давление падает, 5. математическое отношение между числовыми объектами, определяющее их соотнесение/mapping. Конечно, путаница неизбежна.
Ключевой ход -- это рассмотрение функций в связи с модуляризацией системы. Целевая система -- это модуль (заменяемый!) в надсистеме, а ее функциональные определения подсистем связаны также с их модульностью (заменяемостью). Так что ключевым является рассмотрение "функциональности" в строгом соответствии с системным подходом: если есть какая-то "функция", то можно выделить какую-то систему, выполняющую эту функцию, и надсистему, в которой эта функция определена/осмыслена. Тем самым получается не произвольно дробное выделение функций, а хоть как-то соотнесенное с дробностью самой системы в её физическом (или программотехническом, информационном) воплощении. Подробнее про "гамбургер-диаграмму", выражающую такой мыслительный ход на совмещение уровней модульности системы и уровней определения функций, см. в http://ailev.livejournal.com/920248.html
Если все эти функционально определенные подсистемы имеют независимое администрирование, то мы получаем систему систем во всей её красе -- где архитекторам можно только "влиять", но не "командовать".
Диаграмма "гамбургера", в том числе в заимствованном в онтологии ISO 15926 виде (см. http://ailev.livejournal.com/920248.html), критика "несистемноподходности" TOGAF со стороны DEMO (http://www.sapio.nl/sapio2010/pdf/jd236_togaf.pdf), а также множество других работ сводятся к одному: в большинстве подходов к архитектурному описанию нет системноподходности (двойственного рассмотрения каждой системы как задаваемой снаружи модуля-функции, поддерживаемой изнутри модульной же конструкцией-механизмом-материалом-организацией-и-т.д.), и тем самым эти подходы не являются в полной мере архитектурными подходами к описанию систем. Они (включая даже TOGAF) описывают что-то, не являющееся системами.
5. Современные архитектуры рассматриваются как сервис-ориентированные (SOA). Это просто отражение того факта, что любая функция системы может быть представлена как интерфейс, а взаимодействие систем (определяемое как взаимодействие функций через их интерфейсы) представлено через протокол, описываемый сервис-контрактом. Это прямое отражение замечания по связи функциональности (возможности выполнения функции, capabilities) и модульности (т.е. привязки capabilities/function к физической нарезке мира, "приложениям" или "оборудованию"). Вместо прямой трассировки функций к (под)организации, бетону, железу или софту мы получаем еще один уровень косвенности: функции привязываются к сервисам, а уже сервисы реализуются железом или софтом. Если теперь подменить реализацию сервиса, система не изменится. Функция -- это спрос на систему, сервис --"черный ящик" отвечающего на этот спрос предложения, поддержанного системой.
Сервис в заходе "чёрного ящика" как бы реифицирует отношение функции/требуемой возможности и (железной) подсистемы, представляющей эти возможности.
В последнее время появился новый тренд: рассмотрение сервиса не как "чёрного ящика", а "белого ящика", который позволяет связать функцию с поведением обеспечивающей её системы. Онтологически сервис сервис определяется как событие, существующее в течение интервала времени t, напротяжении которого поставщик сервиса явно обязуется выполнять работы в соответствии с зафиксированным описанием и в интересах клиента (http://www.loa-cnr.it/Papers/FerrarioGuarinoFIS08Proceedings.pdf). Выделение сервиса как особого онтологического объекта, позволяет подробно описать это сложное отношение между требуемой функцией и поведением системы, реализующей эту функцию. Сервисы позволяют перейти к языку акторов, ответственных за рабочие трансакции, в том числе задав ход на работу с правами по использованию сервисов (legal perspective -- http://www.loa-cnr.it/Papers/FerrGuarFern.pdf). Самая свежая статья этой серии, описывающей подобный подход к онтологическому описанию сервисов -- http://www.loa-cnr.it/Papers/WI_2011_service_ontology_final.pdf
6. "Требования" в моделе-ориентированном подходе перестают быть как отдельным артефактом, а определяются как указание на деонтическую модальность каких-то определяющих систему артефактов (http://ailev.livejournal.com/900086.html), например, указание "должны быть реализованы" для архитектурных описаний (т.е. для функций, capabilities, сервисов и т.д.). Особо отметим, что в таком подходе нет "нефункциональных требований", ибо все требования так или иначе сводятся к функциям/capabilities/удовлетворению сервисных контрактов и т.д.
Нужно особо оговорить, что практики инженерии требований и инженерии системной архитектуры, тем не менее, остаются разными практиками, ибо требуют разного тренинга. Инженер по требованиям работает с заинтересованными сторонами и обеспечивает их выявление, и их переговоры, а инженер-архитектор предлагает системную архитектуру (http://ailev.livejournal.com/805721.html, и боле раннее описание работы инженера по требованиям в http://ailev.livejournal.com/810548.html).
В любом случае, использование понятия "требования" весьма запутанно (см., например, http://ailev.livejournal.com/901202.html -- требования как программа, метод, модель, интеракция) и связывается всё более со старинным немоделеориентированным и недатацентрическим документарным подходом с полнотекстовыми бумажными документами. Современная моделеориентированная и датацентрическая системная инженерия предусматривает фиксацию всей необходимой информации о нуждах заинтересованных сторон в инженерных информационных системах с моделеориентированной и датацентричной архитектурой (http://ailev.livejournal.com/934700.html). Дальше каждый предыдущий базис (baseline) информационной модели становится требованиями для разработки следующего -- см., например, ряд: 1. user needs, 2. ConOp, 3. architecture, 4. design, 5. as built.
Тем не менее, наиболее близко к "требованиям" стоит функциональная группа описаний (или группа описаний "возможностей", capabilities). Более того, в некоторых учебниках деонтический статус, придаваемый описаниям из других групп предлагают называть не "требования", а "ограничения" (constraints), и часто отмечают при этом их как "нефункциональные требования". С другой стороны, есть традиция считать любые требования функциональными (например, Donald Firesmith выступает против термина "нефункциональные требования" -- любые требования функциональны, они описывают функцию системы для какой-то заинтересованной стороны, вписывают целевую систему в важную для этой заинтересованной стороны надсистему). Постоянная дискуссия о разнице между "требованиями" и "ограничениями" приводит к тому, что "чистые требования" в конце концов становятся функциональной группой описаний системной архитектуры, а "ограничения" входят в другие описания. Jan Dietz продолжает эту линию в противоположную от "требований" сторону и определяет уже всю архитектуру как "ограничение" (а не "требование" -- чисто уже лингвистическая разница) для принимаемых проектных (design) решений.
В любом случае, в GORE (goal-oriented requirement engineering) видно, что "цели" (требования) в моделях связаны с какими-то архитектурными идеями -- т.е. не существуют сами по себе. Вместо традиционного языка полнотекстовых требований используется язык "цели -- средства", или "функции/capabilities -- конструкция (в том числе механизм, материал, структура, организация, технология и т.д.)".
7. Разработка функционального описания может вестись самыми разными методами. Чаще всего предлагается определить сценарии (use cases), по факту являющиеся процессами (развертками во времени) надсистемы, и использовать их для формулирования функций/capabilities. Эти процессы-use cases нельзя путать с внутренними процессами (механизмом работы системы), ибо эти механизмы-процессы формулируются уже как реализационные, т.е. архитектурные/проектные решения -- и они дальше определяют сервисы, а уже сервисы определяют потребных акторов (человечьих и нечеловечьих). Хотя этот пункт сформулирован исходя из "сервиса как черного ящика", подход "белого ящика" может потребовать и других рассмотрений.
8. Итого:
-- требования и архитектурное описание сегодня уже не так хорошо различимы, как еще десяток лет назад
-- под любыми словами (функции, capabilities, services, требования и т.д.) разные подходы имеют ввиду совершенно разные вещи (часто эти разные вещи имеются ввиду и в рамках одного и того же подхода, ибо для них не выполняется онтологическое моделирование).
-- архитектурные описания могут быть разработаны в рамках системного подхода и учитывать необходимость модульности в конструкции системы, а могут быть разработаны не в рамках системного подхода. Громкие трейдмарки типа TOGAF или ARIS тут не являются гарантами, скорее уж наоборот.
-- переход от функций к capabilities, и разбирательство с обязанностями одних частей системы выполнять процессы для других частей системы (т.е. разбирательство с сервисами и организацией-по-DEMO) приводят к существенным изменениям в методах архитектурного описания. Этот переход активно идёт последние пять лет. Поэтому книжки по архитектурным описаниям, выпущенные ранее 2006 года я бы вообще не рекомендовал читать, и древними подходами к архитектурным описаниям я бы тоже не рекомендовал пользоваться.
-- существующие подходы к архитектурным описаниям следуют современным трендам в самой разной степени и чаще всего представляют собой эклектику, проштампованную бюрократией организаций по стандартизации. Из наиболее перспективных для описания enterprise architecture нужно выделить подходы DEMO и ArchiMate (кстати, в ArhiMate пытались учитывать в том числе и DEMO), а в части разбирательства с сервисами -- general service model на базе онтологии DOLCE.
-- в области методов архитектурных описаний нужно выполнять практику управления технологией (http://ailev.livejournal.com/936356.html): со старых, двадцатилетней давности методов архитектурной работы нужно вовремя соскакивать, и осваивать новые. Для моделеориентированной системной инженерии подойдёт отнюдь не любой подход к архитектурному описанию -- и, скорее всего, такой подход (например, praxos) только предстоит создать.