Инженерия требований: тезисы к построению предмета (построению понятия требований)
Это продолжение работы из постинга http://ailev.livejournal.com/802929.html (и там ссылки на предыдущие постинги этой требовательной серии).
1. Различим потенциальные инженерные (учебные, научные) предметы (их может быть много больше, но для наших нынешних целей пока достаточно):
-- инженерия требований
-- инженерия системной архитектуры
-- инженерия физической модели (рабочей документации, specialty engineering) -- в собственно системную инженерию не входит.
-- инженерия обоснований (и испытания, верификация, валидация, квалификация, оценка -- все тут).
Все предметы существенно пересекаются, а в моделеориентированной системной инженерии они еще и по-новому определяются (я бы сказал, что впервые определяются как предметы -- для создания моделей требуется уже не размахивать руками для убедительности и порождать байки и нарративы для облегчения восприятия людьми, но и договариваться об основных понятиях -- эти понятия затем лягут в основу компьютерных моделей).
Каждый предмет определяется в терминах их основных объектов, удобных для осуществления тех или иных (в том числе мыслительных) операций. Такое определение (инженерного, научного, учебного) предмета позволяет отделиться от тех, кто только делает разные языки для уже определенных предметов. Для тех, кто делает только языки, предмет (объекты и операции) уже даны. В случае инженерии требований мы считаем само понятие "требование" и "спецификация" пока не построенными (т.е. неопределенными), и даже осторожно высказываем гипотезу, что в инженерии требований базовыми объектами могут быть не они (они могут оказаться понятиями производными).
2. каждый из этих инженерных (учебных, научных) предметов имеет свои особенные
-- в онтологической парадигме (варианта ISO 15926) -- OIM (object information model, набор основных понятий предметной области и связей между ними).
-- в модельной парадигме (варианта OMG MDA) -- метамодель (набор информационных объектов и их атрибутов).
-- в программистской парадигме (варианта language workbenches) -- набор DSL (domain-specific languages), которые репрезентируют эти понятия в удобных нотациях.
Все эти парадигмы пока еще не равномощны по выразительной силе (повторю ссылку на Конрада Бока http://www.nist.gov/cgi-bin//get_pdf.cgi?pub_id=904119), поэтому приходится рассматривать их всех.
3. "Конструирование" против "динамики" (раньше я неправильно это трактовал как "динамика динамики"). При построении инженерного (конструкторского по определению!) предмета нужно учитывать, что речь идет о "химии" (конструировании объектов в развертке по времени), а не только "динамике" (потоках объектов во времени) -- см. http://tuvalu.santafe.edu/~walter/Papers/barrier.pdf и далее http://tuvalu.santafe.edu/~walter/Pages/publications.html. Строим предмет о "конструировании" (инженерии) требований, а не просто об "управлении требованиями" (т.е управлении потоками требований, aka маршрутизации требований). Управление требованиями входит как часть в инженерию требований, это одна из групп описаний.
4. Построенные {OIM, метамодель, набор DSL} инженерии требований являются методами описания требований (viewpoints), поддерживающими группы описаний требований (views), адресующими интересы определенных заинтересованных лиц (т.е. мы используем подход ISO 42010).
Предмет инженерии требований (в отличие от инженерии системной архитектуры, инженерии физической модели aka рабочей документации, specialty engineering) обслуживает следующие мыслительные операции, требуемые для адресации специфических для требований интересов заинтересованных сторон, и имеющие для этой цели разные группы описаний:
-- деонтические операторы (операторы долженствования) для других (архитектурных, физических) моделей системы. Именно эти операторы дают "требование" (см. http://sourceforge.net/apps/trac/gellish/wiki/Requirements%20Models -- иллюстрация этого на примере Gellish Requirements Model). Такое ощущение, что это основное в понятии требования. "Должно быть X" -- и дальше все вопросы не столько про X, сколько про "должно быть": кто настаивает? зачем настаивает? кто будет выполнять, для кого это высказывание авторитетно? что будет, если не будет как должно? противоречит ли это долженствование каким-то другим? Что делать, если противоречит? Вот всех этих вопросах X может обсуждаться как фрагмент других моделей, "содержание". Часть же "требования" тут -- безусловно, форма (сама являющаяся содержанием именно в инженерии требований). Сюда же деонтическая часть OMG SBVR -- в той части, в которой rules содержат деонтическую составляющую, т.е. являются требованиями. В SBVR не говорится, чьи это требования, хотя в стандарте есть "словарик про организацию" (http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules), но это уже будет другая группа описаний. Зато говорится, как "общая онтологическая модель связана с деонтическими операторами".
-- переговоры и коммуникация между заинтересованными сторонами (к которой сейчас условно отнесу и компьютер: перевод с человечьего на компьютерный), учет их решений (в части решений, а не в части содержания -- содержание, скорее всего, это часть архитектурной и физической модели. Тут прямая отсылка к НЛП (1. Одна из немногих фирм, работающая с теорией в этой группе описаний инженерии требований, использует именно НЛП в качестве теории: http://www.sophist.de/en/start.html, и их материалы типа http://www.iscn.at/select_newspaper/requirements/sophist.html, краткое обсуждение -- в комментах к http://ailev.livejournal.com/694074.html. Кстати, я бы из "коммуникационного НЛП" в инженерию требований брал еще и умение работать "по процессу", или "с формой" в отличие от работы "по содержанию" -- т.е. умение различать тесно связанные содержания и форму, которое может пригодиться при различении модели требований (по содержанию предмета "инженерия требований") и архитектурных и физических моделей (по содержанию предметов инженерии системной архитектуры и specialty engineering).
-- организационная модель "кто кому что может поручить, кто какие требования кому может предъявить, и когда ожидать ответа, что такое ТЗ к контракту", тут можно обратиться к DEMO (http://demo.nl, по-русски http://ailev.livejournal.com/644440.html).
-- модель технического регулирования (compliance), вплотную примыкающая к организационной модели, но говорящая в терминах прав и обязанностей "из закона", а не "из контрактов" с соответствующей заменой понятийного аппарата -- например, модель NOMOS http://ailev.livejournal.com/801489.html
-- цели и интересы заинтересованных сторон, критерии их достижения (KPI) -- примером такого viewpoint может быть GRL из URN (а вот UCM из URN -- это больше напоминает один из архитектурных языков описания/моделирования поведения, типа BPMN 2, к которому "по вкусу" добавили деонтические операторы) -- http://ailev.livejournal.com/800769.html. Сюда же в какой то мере -- OMG BMM (Business Motivation Model, это ведь тоже про цели=требования!). Не говорится, чьи требования -- фиксируется уже согласованный итог обсуждения всеми заинтересованными сторонами. "Требования акционеров/менеджеров/потребителей/регуляторов предприятия" -- это та же инженерия требований, где "целевая система -- предприятие". Не путать тут с организационной моделью ("кто что кому когда обещал/должен").
-- утверждение базисов требований (baselining), управление конфигурацией -- в специфике "конструирования требований" (инкрементального поступления требований, требований как "запросов на изменения", "изменившегося в ходе разработки мнения заинтересованного лица" и т.д.). Требования как поток запросов на изменения, issue tracking, "контроль поручений", workflow требований и порождаемых ими содержательных архитектурных и проектировочных работ.
5. SysML и прочие с целью дальнейшей трансформации/генерации (порождения) -- заход "требования как исполнимая спецификация, Modelica, и UML профиль для нее -- ModelicaML с хорошо выполнимой мультифизической моделью, Matlab и Simulink, прочие мультимодельные среды (включая среды для системной динамики) относятся не к предмету инженерии требований, а к инженерии системной архитектуры (и -- в силу "непосредственной вычислимости в смысле порождения" -- к specialty engineering, ибо "исполнение в специальном смысле" этих моделей может приводить к порождению рабочих чертежей, планов производства работ и т.д.). Поэтому в инженерии требований эти все языки, группы описаний, онтологии и т.д. рассматриваются как внешние по отношению к собственно к модели/метамодели/онтологии/языку требований.
Основная претензия к SysML, Modelica, редакторам 3D моделей, программам управления проектами и прочим моделирующим средам -- они не работают с собственно требованиями (в смысле инженерии требований), там не предусмотрено развитых групп описаний предмета инженерии требований.
Основная претензия к DOORS, IRqA, а также ко всевозможным issue trackers и прочим программам, в которых есть развитые группы описаний требований (в смысле инженерии требований: кто что кого когда зачем попросил, и кто что когда и как по этому поводу выполнил) -- это отсутствие семантической связи модели требований с архитектурными моделями и "рабочей документацией" (физическими моделями, достаточными для изготовления по ним системы). Ибо операции с требованиями (запросы о том, кто что когда кому зачем заказал) выполняются, а содержание запроса (которое часть архитектурных или рабочих описаний) представляется в текстовом виде: т.е. дублируется, плохо проверяется компьютером, плохо структурируется и т.д.
6. Опять все упирается в "универсальный моделер", но теперь акцент ставится на
-- онтологию требований (не архитектурного, реализационного, интеграционного, квалификационного содержания, а "требовательной формы")
-- средствам интеграции знаний и фактов о требованиях со знаниями и фактами об архитектуре, рабочей документации и т.д. (в плане хранения: репозитории, обмены информацией; в плане выражения: языки "требовательной формы", или добавки к архитектурным и другим "содержательным" языкам).
7. Все вышесказанное должно рассматриваться не столько как описание требований ("требовательной формы" к "архитектурному и другому продуктному/сервисному содержанию") как продукта, но и к процессной (практикам жизненного цикла требований) части: речь идет о ситуационной инженерии требований, обсуждаются методы работы с требованиями, методология. Ибо (повторюсь), см. пункт 1: "Каждый предмет определяется в терминах их основных объектов, удобных для осуществления тех или иных (в том числе мыслительных) операций". Инженерия требований -- это про работу с требованиями, а не про любование их структурным совершенством.
1. Различим потенциальные инженерные (учебные, научные) предметы (их может быть много больше, но для наших нынешних целей пока достаточно):
-- инженерия требований
-- инженерия системной архитектуры
-- инженерия физической модели (рабочей документации, specialty engineering) -- в собственно системную инженерию не входит.
-- инженерия обоснований (и испытания, верификация, валидация, квалификация, оценка -- все тут).
Все предметы существенно пересекаются, а в моделеориентированной системной инженерии они еще и по-новому определяются (я бы сказал, что впервые определяются как предметы -- для создания моделей требуется уже не размахивать руками для убедительности и порождать байки и нарративы для облегчения восприятия людьми, но и договариваться об основных понятиях -- эти понятия затем лягут в основу компьютерных моделей).
Каждый предмет определяется в терминах их основных объектов, удобных для осуществления тех или иных (в том числе мыслительных) операций. Такое определение (инженерного, научного, учебного) предмета позволяет отделиться от тех, кто только делает разные языки для уже определенных предметов. Для тех, кто делает только языки, предмет (объекты и операции) уже даны. В случае инженерии требований мы считаем само понятие "требование" и "спецификация" пока не построенными (т.е. неопределенными), и даже осторожно высказываем гипотезу, что в инженерии требований базовыми объектами могут быть не они (они могут оказаться понятиями производными).
2. каждый из этих инженерных (учебных, научных) предметов имеет свои особенные
-- в онтологической парадигме (варианта ISO 15926) -- OIM (object information model, набор основных понятий предметной области и связей между ними).
-- в модельной парадигме (варианта OMG MDA) -- метамодель (набор информационных объектов и их атрибутов).
-- в программистской парадигме (варианта language workbenches) -- набор DSL (domain-specific languages), которые репрезентируют эти понятия в удобных нотациях.
Все эти парадигмы пока еще не равномощны по выразительной силе (повторю ссылку на Конрада Бока http://www.nist.gov/cgi-bin//get_pdf.cgi?pub_id=904119), поэтому приходится рассматривать их всех.
3. "Конструирование" против "динамики" (раньше я неправильно это трактовал как "динамика динамики"). При построении инженерного (конструкторского по определению!) предмета нужно учитывать, что речь идет о "химии" (конструировании объектов в развертке по времени), а не только "динамике" (потоках объектов во времени) -- см. http://tuvalu.santafe.edu/~walter/Papers/barrier.pdf и далее http://tuvalu.santafe.edu/~walter/Pages/publications.html. Строим предмет о "конструировании" (инженерии) требований, а не просто об "управлении требованиями" (т.е управлении потоками требований, aka маршрутизации требований). Управление требованиями входит как часть в инженерию требований, это одна из групп описаний.
4. Построенные {OIM, метамодель, набор DSL} инженерии требований являются методами описания требований (viewpoints), поддерживающими группы описаний требований (views), адресующими интересы определенных заинтересованных лиц (т.е. мы используем подход ISO 42010).
Предмет инженерии требований (в отличие от инженерии системной архитектуры, инженерии физической модели aka рабочей документации, specialty engineering) обслуживает следующие мыслительные операции, требуемые для адресации специфических для требований интересов заинтересованных сторон, и имеющие для этой цели разные группы описаний:
-- деонтические операторы (операторы долженствования) для других (архитектурных, физических) моделей системы. Именно эти операторы дают "требование" (см. http://sourceforge.net/apps/trac/gellish/wiki/Requirements%20Models -- иллюстрация этого на примере Gellish Requirements Model). Такое ощущение, что это основное в понятии требования. "Должно быть X" -- и дальше все вопросы не столько про X, сколько про "должно быть": кто настаивает? зачем настаивает? кто будет выполнять, для кого это высказывание авторитетно? что будет, если не будет как должно? противоречит ли это долженствование каким-то другим? Что делать, если противоречит? Вот всех этих вопросах X может обсуждаться как фрагмент других моделей, "содержание". Часть же "требования" тут -- безусловно, форма (сама являющаяся содержанием именно в инженерии требований). Сюда же деонтическая часть OMG SBVR -- в той части, в которой rules содержат деонтическую составляющую, т.е. являются требованиями. В SBVR не говорится, чьи это требования, хотя в стандарте есть "словарик про организацию" (http://en.wikipedia.org/wiki/Semantics_of_Business_Vocabulary_and_Business_Rules), но это уже будет другая группа описаний. Зато говорится, как "общая онтологическая модель связана с деонтическими операторами".
-- переговоры и коммуникация между заинтересованными сторонами (к которой сейчас условно отнесу и компьютер: перевод с человечьего на компьютерный), учет их решений (в части решений, а не в части содержания -- содержание, скорее всего, это часть архитектурной и физической модели. Тут прямая отсылка к НЛП (1. Одна из немногих фирм, работающая с теорией в этой группе описаний инженерии требований, использует именно НЛП в качестве теории: http://www.sophist.de/en/start.html, и их материалы типа http://www.iscn.at/select_newspaper/requirements/sophist.html, краткое обсуждение -- в комментах к http://ailev.livejournal.com/694074.html. Кстати, я бы из "коммуникационного НЛП" в инженерию требований брал еще и умение работать "по процессу", или "с формой" в отличие от работы "по содержанию" -- т.е. умение различать тесно связанные содержания и форму, которое может пригодиться при различении модели требований (по содержанию предмета "инженерия требований") и архитектурных и физических моделей (по содержанию предметов инженерии системной архитектуры и specialty engineering).
-- организационная модель "кто кому что может поручить, кто какие требования кому может предъявить, и когда ожидать ответа, что такое ТЗ к контракту", тут можно обратиться к DEMO (http://demo.nl, по-русски http://ailev.livejournal.com/644440.html).
-- модель технического регулирования (compliance), вплотную примыкающая к организационной модели, но говорящая в терминах прав и обязанностей "из закона", а не "из контрактов" с соответствующей заменой понятийного аппарата -- например, модель NOMOS http://ailev.livejournal.com/801489.html
-- цели и интересы заинтересованных сторон, критерии их достижения (KPI) -- примером такого viewpoint может быть GRL из URN (а вот UCM из URN -- это больше напоминает один из архитектурных языков описания/моделирования поведения, типа BPMN 2, к которому "по вкусу" добавили деонтические операторы) -- http://ailev.livejournal.com/800769.html. Сюда же в какой то мере -- OMG BMM (Business Motivation Model, это ведь тоже про цели=требования!). Не говорится, чьи требования -- фиксируется уже согласованный итог обсуждения всеми заинтересованными сторонами. "Требования акционеров/менеджеров/потребителей/регуляторов предприятия" -- это та же инженерия требований, где "целевая система -- предприятие". Не путать тут с организационной моделью ("кто что кому когда обещал/должен").
-- утверждение базисов требований (baselining), управление конфигурацией -- в специфике "конструирования требований" (инкрементального поступления требований, требований как "запросов на изменения", "изменившегося в ходе разработки мнения заинтересованного лица" и т.д.). Требования как поток запросов на изменения, issue tracking, "контроль поручений", workflow требований и порождаемых ими содержательных архитектурных и проектировочных работ.
5. SysML и прочие с целью дальнейшей трансформации/генерации (порождения) -- заход "требования как исполнимая спецификация, Modelica, и UML профиль для нее -- ModelicaML с хорошо выполнимой мультифизической моделью, Matlab и Simulink, прочие мультимодельные среды (включая среды для системной динамики) относятся не к предмету инженерии требований, а к инженерии системной архитектуры (и -- в силу "непосредственной вычислимости в смысле порождения" -- к specialty engineering, ибо "исполнение в специальном смысле" этих моделей может приводить к порождению рабочих чертежей, планов производства работ и т.д.). Поэтому в инженерии требований эти все языки, группы описаний, онтологии и т.д. рассматриваются как внешние по отношению к собственно к модели/метамодели/онтологии/языку требований.
Основная претензия к SysML, Modelica, редакторам 3D моделей, программам управления проектами и прочим моделирующим средам -- они не работают с собственно требованиями (в смысле инженерии требований), там не предусмотрено развитых групп описаний предмета инженерии требований.
Основная претензия к DOORS, IRqA, а также ко всевозможным issue trackers и прочим программам, в которых есть развитые группы описаний требований (в смысле инженерии требований: кто что кого когда зачем попросил, и кто что когда и как по этому поводу выполнил) -- это отсутствие семантической связи модели требований с архитектурными моделями и "рабочей документацией" (физическими моделями, достаточными для изготовления по ним системы). Ибо операции с требованиями (запросы о том, кто что когда кому зачем заказал) выполняются, а содержание запроса (которое часть архитектурных или рабочих описаний) представляется в текстовом виде: т.е. дублируется, плохо проверяется компьютером, плохо структурируется и т.д.
6. Опять все упирается в "универсальный моделер", но теперь акцент ставится на
-- онтологию требований (не архитектурного, реализационного, интеграционного, квалификационного содержания, а "требовательной формы")
-- средствам интеграции знаний и фактов о требованиях со знаниями и фактами об архитектуре, рабочей документации и т.д. (в плане хранения: репозитории, обмены информацией; в плане выражения: языки "требовательной формы", или добавки к архитектурным и другим "содержательным" языкам).
7. Все вышесказанное должно рассматриваться не столько как описание требований ("требовательной формы" к "архитектурному и другому продуктному/сервисному содержанию") как продукта, но и к процессной (практикам жизненного цикла требований) части: речь идет о ситуационной инженерии требований, обсуждаются методы работы с требованиями, методология. Ибо (повторюсь), см. пункт 1: "Каждый предмет определяется в терминах их основных объектов, удобных для осуществления тех или иных (в том числе мыслительных) операций". Инженерия требований -- это про работу с требованиями, а не про любование их структурным совершенством.