Требования -- это программа, метод, модель, интеракция
Познакомившись с огромным числом разнородных стандартов представления требований (http://ailev.livejournal.com/900086.html), продолжим тему построения предмета (дисциплины) инженерии требований (построение понятия требований), поднятую в марте 2010 в http://ailev.livejournal.com/805721.html). Повторюсь, слегка сократив и переформулировав: в моделеориентированной инженерии требований о предмете (дисциплине) нужно не только порождать байки и нарративы для облегчения воспринимания людьми, но и договариваться о формально определенных основных понятиях -- которые затем лягут в основу компьютерных моделей. Каждый предмет определяется в терминах их основных объектов, удобных для осуществления тех или иных (включая мыслительные) операций. Недостаточно определить язык для записи требований, ибо само понятие требований еще не определено.
Более того, нам нужно определить требования "конструктивно", т.е. речь идет о "химии требований" -- конструктивному их заданию, в том числе в развертке по времени жизненного цикла целевой системы.
Ниже -- несколько заходов на подобным образом строящееся понятие требований:
1. Требования -- это программа.
Требования -- это часть плана. И не смотрите в RDL ISO 15926 (http://193.212.132.108/apps/rdsclient.html, там открыт гостевой вход), в котором requirements типа document_definition, а plan типа class_of_information_object -- но это всё уже "помойка части 4"). Смотрите в книжку Matthew West с HQDM (онлайн схема HQDM тут: http://homepages.rya-online.net/matthew-west/hqdm_framework/, там требования попадают в базовые 229 понятий: http://homepages.rya-online.net/matthew-west/hqdm_framework/hqdm_framework/lexical/requirement.htm, a spatio_temporal_extent that is part_of_plan at least one plan and is defined_by exactly one requirement_specification. Да и не в HQDM даже дело, ибо я считаю, что требования (оставим в стороне выражение требований через спецификацию) и впрямь план в том же смысле, в каком хромосомы бабочки определяют и "являются spatio_temporal_part" и ее яиц, и ее гусеницы, и летающей особи.
План -- это программа получения одного из возможных миров. Требования -- это ее часть, т.е. такая специальная мультипарадигмальная программа получения одного из возможных миров, предназначенная для исполнения толпой живых людей с их инструментами и материалами и данная преимущественно в декларативном виде (тогда как план понимается большинством людей как императивная программа "с шагами"). У ISO 15926 большие проблемы с онтологией computer science, поэтому не меньшие проблемы с software engineering, а инженерия требований для меня часть информатики, включающей в себя и computer science, и software engineering и все остальные дисциплины компьютерного цикла.
Как и любая другая мультипарадигмальная программа ("план исполнения процессором/виртуальной машиной"), требования полны онтологических парадоксов: в них, например, несколько разных времён (Чтобы ненароком кого не обидеть, привожу англоязычные примеры):
1. Написания-редактирования, с инклюдами (например, стандартов и других требваний), макросами, комментариями и т.д.The Supplier is responsible to select and propose the most appropriate and consistent combination of Codes and Standards, in conformance with Chapter 2.5, to be used to design equipment, systems and structures of the plant. The codes and standards proposed by the Supplier shall be a consistent set and should be based on recent license experience.
The assessment methodology is defined in Chapter 2.18 Appendix B
Vendor -- Generally replaced either by Plant Designer or by Plant Constructor depending on the context.
2. Проектирования-компиляции, в т.ч. "переработки псевдокода в эффективную программу" путём последовательного уточнения, моделирования, "исполняемой архитектуры", перехода от декларативно-функционального описания к конструктивному-императивному и т.д. -- "проектант/компилятор должен использовать такие-то и сякие методы своей работы".The functions of each system under normal and abnormal plant operating conditions shall be clearly specified, as well as the assumed operational characteristics of the system. Especially, the fullfillment of the safety related functions listed in section 2.8.1.1 with the proper degree of redundancy shall be shown.
The Supplier* shall assess and implement, as far as possible, simplification in all areas of design, construction, operation and maintenance.
The safety approach adopted shall combine deterministic methods and probabilistic methods.
3. Воплощения-вычисления (результата выполнения требований) -- "система должна прыгать не ниже 1метра и бегать не медленней 30км/час". В том числе условные высказывания времени воплощения.The annual Forced Unavailability Factor shall be less than 1,4 % (less than 5 days per year).
Inner surfaces shall be as smooth as necessary to minimise crud deposition, and to facilitate decontamination. Equipment such as tanks, heat exchangers and valves, shall have no sharp corners, where crud may build up.
The primary control is not required during stretch-out operation.
Можно представить, как это всё (1. требования к требованиям и действия с ними, 2. требования к обеспечивающей системе и ее действиям, 3. требования к целевой системе и ее действиям) нетривиально должны выражаться в их взаимосвязи в 4D экстенсионализме (гляньте, например, на http://homepages.rya-online.net/matthew-west/hqdm_framework/hqdm_framework/lexical/requirement_specification.htm -- a class_of_spatio_temporal_extent that is the intersection_of one or more class_of_state. Понятно, что в этих определениях HDQM имеется ввиду только время воплощения. Но ведь это не так! У самих требований и обеспечивающей системы ведь тоже есть жизненные циклы!).
В этой связи к требованиям применимо всё, что обычно применимо к программам, со всей сопутствующей дискуссией и онтологической путаницей: моделирование, псевдокод как начальная стадия написания, доказательства правильности (завершимости), рефлексивность, используемые языки формулирования требований, аспектная инженерия требований, споры о сверхраннем связывании и сперхпозднем, "интерактивное проектирование" в котором изменения в конструкции могут быть обратно прослежены к функциям и т.д. и т.п.
Работа с требованиями в программной инженерии давно идет по этому пути "исполняемых требований --> исполняемой архитектуры --> исполняемой модели программы --> исполняемой программы-->верифицируемых результатов вычислений", но никак не придут в связи с чрезвычайной сложностью проблемы. В системной инженерии просто традиционный лаг и отставание в 10-15 лет от ситуации в программной инженерии.
Дальше традиционная дискуссия про языки программирования (в данном случае языки формулирования требований), необходимые DSL, парадигмы, поддержка инструментарием и language workbench, и т.д.
Ну, и чего в программировании почти не бывает: попытки отцитировать в тексте требований все и так перечисленные внешние документы (это как переписать в договор и без того действующий гражданский кодекс) и денормализовать текст (то есть прописывать одно и то же во всех местах, куда дотянется рука) с неизбежным в этих случаях расхождением копий и оригинала. Ибо "требования для людей, а не для машин", а "для людей и производительности денормализация полезна".
2. Требования -- это подкласс метода.
Легко заметить, что в требованиях-программе есть все основные компоненты метода:
-- определение того, какие должны быть выходные (а часто и промежуточные, а часто и вспомогательные) рабочие продукты
-- определение того, каким практикам должна следовать обеспечивающая система
-- определение того, какие профессиональные роли, и их инструменты используются
-- определение того, какие языки и нотации должны быть использованы, чтобы эксперты заказчика и/или регулятора могли разобраться в проекте
Поэтому очень легко считать, что требования соответствуют уникальному методу, которым должна быть получена целевая система, только этот метод очень неполно прописан. Полнота описания легко определяется метамоделью, описанной в ISO 24744 -- а дальше уже торговаться об уровне подробностей в описании каждого вида компонент.
Именно в этой парадигме становится возможным обсуждать сам объем требований: все эти "инжиниринги заказчика", возможности записывать процессные стандарты в требования, "вы нам скажите, что нужно, а уж как этого добиться мы сами придумаем", "user needs существенно отличаются от ограничений как конструкторских предложений, идущих от заказчика" и т.д.
Такой подход, в частности, интересен для понимания организационной модели (я тут прямо имею ввиду DEMO и VISI -- см. http://praxos.ru/index.php/DEMO) разработки: каждая трансакция соответствует передаче какого-то требования, и для уторговывания того, что вправе, а что не вправе определять тут "заказчик", нужно в явном виде обсуждать "выход в дискурс".
3. Модель требований у онтологов
Требования в онтологической инженерии -- это смесь документов и модели системы с указанием модальности. Указание модальность в ISO 15926 по факту не проработано, кроме указания на то, что модальности сами по себе сначала должны быть отмоделированы в терминах ISO 15926.
Наиболее подробно выражение модальностей проработано в работах по Gellish (http://sourceforge.net/apps/trac/gellish/wiki/Requirements%20Models и тесно связанное http://sourceforge.net/apps/trac/gellish/wiki/Standard%20Specification%20Models).
Самый простой пример с использованием модальностей -- это спецификации на покупное оборудование (datasheets, пример спецификации на насос -- http://www.freecalc.com/pumpds2.htm). Одни и те же данные можно рассматривать по-разному: в возращаемых опросных листах, которые рассылают поставщики каталогов производителям оборудования, и далее в самом каталоге эти данные означают одно (вовсе не требования, а как раз "предложение"). В запросе проектанта к каталогу (ровно то же самое) -- это уже требования, сопоставляемые с данными в опросных листах производителей на предмет их удовлетворения. То есть факт "предлагаемости" и "требовательности" -- в модальности, не в самих данных. Про модальности и требования чуть-чуть в начале постинга http://ailev.livejournal.com/900086.html.
Общий принцип -- использование для выражения модальностей в требованиях специальных отношений (например, не have, a shall have или should have) и использование при моделировании этих специальных отношений, а не отношений, используемых при моделировании проектных решений или результатов измерений.
4. Требования -- это не объект, а интеракция (т.е. текст, который пишется кем-то для кого-то), поэтому в нём модальности логические определяются модальными словами в языке и это сразу даёт другой тип анализа (http://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0), выход в лингвистическую прагматику (то, как контекст меняет значение речи: http://en.wikipedia.org/wiki/Pragmatics), разбирательства с речевыми актами и их иллокутивностью против перлокутивности (http://en.wikipedia.org/wiki/Speech_act -- про действия, которые делаются речевыми актами, куда попадают и обещания, и заказы).
Тут нужно заметить, что только что помянутое DEMO является хорошим примером моделирования в этой области, ибо тоже растёт из Language/Action перспективы -- теории коммуникативного действия Хабермаса, которая строится в русле теории речевых актов. Согласно теории речевых актов, словесное выражение (utterance) делится на описывающее мир суждение (propositional content) и побудительную силу (illocutionary force). Так, DEMO различает шесть иллокутивных видов выражений: вопрос, подтверждение, запрос, обещание, утверждение и приёмка. Понятно, что все эти иллокутивные виды из DEMO используются для работы с "требованиями" -- например, для обсуждения того, что происходит в момент обещания -- "подписания требований исполнителем" или "приёмкой работы согласно требованиям".
В этих исследованиях language action perspective (общепринятое сокращение -- LAP) language прямо указывает на лингвистику, а вот action прямо атрибутируется social action theory of Max Weber, и в конечном итоге оказывается, что праксеология с ее упором на деятельность весьма близка к этому подходу.
Сюда же относятся многочисленные исследования языкового консенсуса для разработки требований (обеспечение одинаковости понимания требований всеми участниками работы -- как минимум, сотрудниками заказчика и исполнителя), см. обзор http://www.ecis2009.it/papers/ecis2009-0638.pdf.
Хотя тут нужно быть крайне осторожными, скользя по этим новомодным лингвистическим трендам: слово illocutionary начало выходить из моды где-то в 1990г., а слово performative -- в 1996. Впрочем, это часть более широкого тренда, в котором сама лингвистика успешно выходит из моды с 1995 года, много быстрее, чем это делает слово performative, и очевидно отступая в пользу ontology -- http://ngrams.googlelabs.com/graph?content=illocutionary%2Cperformative%2Clinguistics%2C+ontology&year_start=1940&year_end=2008&corpus=0&smoothing=1. Не будем гадать, что на самом деле измеряет в этом случае Books Ngram Viewer (использование слов в половодье книг по тематике IT?), и подумаем сами -- более обстоятельно.
Пока же отметим, что "требования как интеракция, а не объект" -- это вполне рабочая постановка вопроса, и дальше можно выбирать, как именно это обсуждать.
Более того, нам нужно определить требования "конструктивно", т.е. речь идет о "химии требований" -- конструктивному их заданию, в том числе в развертке по времени жизненного цикла целевой системы.
Ниже -- несколько заходов на подобным образом строящееся понятие требований:
1. Требования -- это программа.
Требования -- это часть плана. И не смотрите в RDL ISO 15926 (http://193.212.132.108/apps/rdsclient.html, там открыт гостевой вход), в котором requirements типа document_definition, а plan типа class_of_information_object -- но это всё уже "помойка части 4"). Смотрите в книжку Matthew West с HQDM (онлайн схема HQDM тут: http://homepages.rya-online.net/matthew-west/hqdm_framework/, там требования попадают в базовые 229 понятий: http://homepages.rya-online.net/matthew-west/hqdm_framework/hqdm_framework/lexical/requirement.htm, a spatio_temporal_extent that is part_of_plan at least one plan and is defined_by exactly one requirement_specification. Да и не в HQDM даже дело, ибо я считаю, что требования (оставим в стороне выражение требований через спецификацию) и впрямь план в том же смысле, в каком хромосомы бабочки определяют и "являются spatio_temporal_part" и ее яиц, и ее гусеницы, и летающей особи.
План -- это программа получения одного из возможных миров. Требования -- это ее часть, т.е. такая специальная мультипарадигмальная программа получения одного из возможных миров, предназначенная для исполнения толпой живых людей с их инструментами и материалами и данная преимущественно в декларативном виде (тогда как план понимается большинством людей как императивная программа "с шагами"). У ISO 15926 большие проблемы с онтологией computer science, поэтому не меньшие проблемы с software engineering, а инженерия требований для меня часть информатики, включающей в себя и computer science, и software engineering и все остальные дисциплины компьютерного цикла.
Как и любая другая мультипарадигмальная программа ("план исполнения процессором/виртуальной машиной"), требования полны онтологических парадоксов: в них, например, несколько разных времён (Чтобы ненароком кого не обидеть, привожу англоязычные примеры):
1. Написания-редактирования, с инклюдами (например, стандартов и других требваний), макросами, комментариями и т.д.The Supplier is responsible to select and propose the most appropriate and consistent combination of Codes and Standards, in conformance with Chapter 2.5, to be used to design equipment, systems and structures of the plant. The codes and standards proposed by the Supplier shall be a consistent set and should be based on recent license experience.
The assessment methodology is defined in Chapter 2.18 Appendix B
Vendor -- Generally replaced either by Plant Designer or by Plant Constructor depending on the context.
2. Проектирования-компиляции, в т.ч. "переработки псевдокода в эффективную программу" путём последовательного уточнения, моделирования, "исполняемой архитектуры", перехода от декларативно-функционального описания к конструктивному-императивному и т.д. -- "проектант/компилятор должен использовать такие-то и сякие методы своей работы".The functions of each system under normal and abnormal plant operating conditions shall be clearly specified, as well as the assumed operational characteristics of the system. Especially, the fullfillment of the safety related functions listed in section 2.8.1.1 with the proper degree of redundancy shall be shown.
The Supplier* shall assess and implement, as far as possible, simplification in all areas of design, construction, operation and maintenance.
The safety approach adopted shall combine deterministic methods and probabilistic methods.
3. Воплощения-вычисления (результата выполнения требований) -- "система должна прыгать не ниже 1метра и бегать не медленней 30км/час". В том числе условные высказывания времени воплощения.The annual Forced Unavailability Factor shall be less than 1,4 % (less than 5 days per year).
Inner surfaces shall be as smooth as necessary to minimise crud deposition, and to facilitate decontamination. Equipment such as tanks, heat exchangers and valves, shall have no sharp corners, where crud may build up.
The primary control is not required during stretch-out operation.
Можно представить, как это всё (1. требования к требованиям и действия с ними, 2. требования к обеспечивающей системе и ее действиям, 3. требования к целевой системе и ее действиям) нетривиально должны выражаться в их взаимосвязи в 4D экстенсионализме (гляньте, например, на http://homepages.rya-online.net/matthew-west/hqdm_framework/hqdm_framework/lexical/requirement_specification.htm -- a class_of_spatio_temporal_extent that is the intersection_of one or more class_of_state. Понятно, что в этих определениях HDQM имеется ввиду только время воплощения. Но ведь это не так! У самих требований и обеспечивающей системы ведь тоже есть жизненные циклы!).
В этой связи к требованиям применимо всё, что обычно применимо к программам, со всей сопутствующей дискуссией и онтологической путаницей: моделирование, псевдокод как начальная стадия написания, доказательства правильности (завершимости), рефлексивность, используемые языки формулирования требований, аспектная инженерия требований, споры о сверхраннем связывании и сперхпозднем, "интерактивное проектирование" в котором изменения в конструкции могут быть обратно прослежены к функциям и т.д. и т.п.
Работа с требованиями в программной инженерии давно идет по этому пути "исполняемых требований --> исполняемой архитектуры --> исполняемой модели программы --> исполняемой программы-->верифицируемых результатов вычислений", но никак не придут в связи с чрезвычайной сложностью проблемы. В системной инженерии просто традиционный лаг и отставание в 10-15 лет от ситуации в программной инженерии.
Дальше традиционная дискуссия про языки программирования (в данном случае языки формулирования требований), необходимые DSL, парадигмы, поддержка инструментарием и language workbench, и т.д.
Ну, и чего в программировании почти не бывает: попытки отцитировать в тексте требований все и так перечисленные внешние документы (это как переписать в договор и без того действующий гражданский кодекс) и денормализовать текст (то есть прописывать одно и то же во всех местах, куда дотянется рука) с неизбежным в этих случаях расхождением копий и оригинала. Ибо "требования для людей, а не для машин", а "для людей и производительности денормализация полезна".
2. Требования -- это подкласс метода.
Легко заметить, что в требованиях-программе есть все основные компоненты метода:
-- определение того, какие должны быть выходные (а часто и промежуточные, а часто и вспомогательные) рабочие продукты
-- определение того, каким практикам должна следовать обеспечивающая система
-- определение того, какие профессиональные роли, и их инструменты используются
-- определение того, какие языки и нотации должны быть использованы, чтобы эксперты заказчика и/или регулятора могли разобраться в проекте
Поэтому очень легко считать, что требования соответствуют уникальному методу, которым должна быть получена целевая система, только этот метод очень неполно прописан. Полнота описания легко определяется метамоделью, описанной в ISO 24744 -- а дальше уже торговаться об уровне подробностей в описании каждого вида компонент.
Именно в этой парадигме становится возможным обсуждать сам объем требований: все эти "инжиниринги заказчика", возможности записывать процессные стандарты в требования, "вы нам скажите, что нужно, а уж как этого добиться мы сами придумаем", "user needs существенно отличаются от ограничений как конструкторских предложений, идущих от заказчика" и т.д.
Такой подход, в частности, интересен для понимания организационной модели (я тут прямо имею ввиду DEMO и VISI -- см. http://praxos.ru/index.php/DEMO) разработки: каждая трансакция соответствует передаче какого-то требования, и для уторговывания того, что вправе, а что не вправе определять тут "заказчик", нужно в явном виде обсуждать "выход в дискурс".
3. Модель требований у онтологов
Требования в онтологической инженерии -- это смесь документов и модели системы с указанием модальности. Указание модальность в ISO 15926 по факту не проработано, кроме указания на то, что модальности сами по себе сначала должны быть отмоделированы в терминах ISO 15926.
Наиболее подробно выражение модальностей проработано в работах по Gellish (http://sourceforge.net/apps/trac/gellish/wiki/Requirements%20Models и тесно связанное http://sourceforge.net/apps/trac/gellish/wiki/Standard%20Specification%20Models).
Самый простой пример с использованием модальностей -- это спецификации на покупное оборудование (datasheets, пример спецификации на насос -- http://www.freecalc.com/pumpds2.htm). Одни и те же данные можно рассматривать по-разному: в возращаемых опросных листах, которые рассылают поставщики каталогов производителям оборудования, и далее в самом каталоге эти данные означают одно (вовсе не требования, а как раз "предложение"). В запросе проектанта к каталогу (ровно то же самое) -- это уже требования, сопоставляемые с данными в опросных листах производителей на предмет их удовлетворения. То есть факт "предлагаемости" и "требовательности" -- в модальности, не в самих данных. Про модальности и требования чуть-чуть в начале постинга http://ailev.livejournal.com/900086.html.
Общий принцип -- использование для выражения модальностей в требованиях специальных отношений (например, не have, a shall have или should have) и использование при моделировании этих специальных отношений, а не отношений, используемых при моделировании проектных решений или результатов измерений.
4. Требования -- это не объект, а интеракция (т.е. текст, который пишется кем-то для кого-то), поэтому в нём модальности логические определяются модальными словами в языке и это сразу даёт другой тип анализа (http://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0), выход в лингвистическую прагматику (то, как контекст меняет значение речи: http://en.wikipedia.org/wiki/Pragmatics), разбирательства с речевыми актами и их иллокутивностью против перлокутивности (http://en.wikipedia.org/wiki/Speech_act -- про действия, которые делаются речевыми актами, куда попадают и обещания, и заказы).
Тут нужно заметить, что только что помянутое DEMO является хорошим примером моделирования в этой области, ибо тоже растёт из Language/Action перспективы -- теории коммуникативного действия Хабермаса, которая строится в русле теории речевых актов. Согласно теории речевых актов, словесное выражение (utterance) делится на описывающее мир суждение (propositional content) и побудительную силу (illocutionary force). Так, DEMO различает шесть иллокутивных видов выражений: вопрос, подтверждение, запрос, обещание, утверждение и приёмка. Понятно, что все эти иллокутивные виды из DEMO используются для работы с "требованиями" -- например, для обсуждения того, что происходит в момент обещания -- "подписания требований исполнителем" или "приёмкой работы согласно требованиям".
В этих исследованиях language action perspective (общепринятое сокращение -- LAP) language прямо указывает на лингвистику, а вот action прямо атрибутируется social action theory of Max Weber, и в конечном итоге оказывается, что праксеология с ее упором на деятельность весьма близка к этому подходу.
Сюда же относятся многочисленные исследования языкового консенсуса для разработки требований (обеспечение одинаковости понимания требований всеми участниками работы -- как минимум, сотрудниками заказчика и исполнителя), см. обзор http://www.ecis2009.it/papers/ecis2009-0638.pdf.
Хотя тут нужно быть крайне осторожными, скользя по этим новомодным лингвистическим трендам: слово illocutionary начало выходить из моды где-то в 1990г., а слово performative -- в 1996. Впрочем, это часть более широкого тренда, в котором сама лингвистика успешно выходит из моды с 1995 года, много быстрее, чем это делает слово performative, и очевидно отступая в пользу ontology -- http://ngrams.googlelabs.com/graph?content=illocutionary%2Cperformative%2Clinguistics%2C+ontology&year_start=1940&year_end=2008&corpus=0&smoothing=1. Не будем гадать, что на самом деле измеряет в этом случае Books Ngram Viewer (использование слов в половодье книг по тематике IT?), и подумаем сами -- более обстоятельно.
Пока же отметим, что "требования как интеракция, а не объект" -- это вполне рабочая постановка вопроса, и дальше можно выбирать, как именно это обсуждать.