В требованиях есть тем самым модальные составляющие (http://en.wikipedia.org/wiki/Modal_logic):
-- нейтральные высказывания о мире, суть которых непонятна без указания модальности. Например, "длина дана как 16".
-- алетическая (alethic) модальность, относящаяся к возможности существования (помним, что "архитектура -- это ограничение возможностей проектировщика", а инкрементальное проектирование -- это пошаговое ограничение свободы принимаемых при проектировании решений, пока свобода решений не становится равной нулю, и остаётся только воплотить проект "в металле" или "в коде"). Обычно с алетической модальностью связаны рассуждения про возможные миры (possible worlds). В этом плане каждый более общий дизайн -- это требование к следующей более подробной версии, а рабочая документация -- требования к изготовителям. Например, "длина пусть будет 16" ("положим длину равную 16").
-- деонтическая (deontic) модальность, относящаяся к обязыванию и дозволению (принципал поручает транзакцию агенту, говоря, что он ДОЛЖЕН делать, что РЕКОМЕНДУЕТСЯ, но позволяется под давлением обстоятельств не делать, а что МОЖНО делать, хотя и совершенно необязательно). Например, "длина должна быть 16".
-- темпоральная (temporal) модальность, связанная со временем. Например, "длина была 16 три года назад".
-- доксическая (doxastic) модальность, связанная с ожиданиями агента. "Я верю, что длина дана как 16" -- ежели агент прикинул длину на местности и сообщает ее уже в качестве требований.
Более того, доксическая модальность важна для квалификации. Требование переформулируется, как "декларация" (claim) разработчиков о соответствии -- т.е. "я верю, что длина равна 16", а затем это высказывание доказывается по логическим правилам (причем логические правила явно предъявляются как argument -- "доказательство от противного", "доказательство путем перечисления всех возможных частных случаев" и т.д.. Поэтому структурированная (целеориентированная) инженерия требований и структутированные инженерные обоснования по факту оказываются аналогично структурированными -- http://ailev.livejournal.com/811715.html (именно в этом тексте я еще в марте 2010 года написал "это просто логика, сынок"). Требования и их обоснования должны быть отмоделированы как какая-то логика, и можно дальше договариваться, как именно моделируются логики, и что в эту логику должно войти и как в современном инструментарии можно онтологически моделировать разные логики (сложность вопроса можно оценить по базовой статье, только не в попсовой википедии, а в серьезной философской энциклопедии: http://plato.stanford.edu/entries/logic-modal/).
Ужас в том, что сейчас требования понимаются исключительно как текстовые описания, которые каким-то чудесным образом привязываются к каким-то частям описания системы (будучи сами частными описаниями, в которых тщательно перемешаны все возможные модальности). Разбираться с этими модальностями приходится людям, формальное моделирование высказываний для требований в текущей практике отсутствует (иначе сразу пришлось бы столкнуться с дикими мета-мета-мета-мета нагромождениями, а заодно разбираться с модальностями. Поэтому требования сегодня -- это сложные конструции из обрывков текстов).
Этой тенденции немного противостоят люди из сообщества целеориентированной инженерии требований, но они за последние двадцать лет не достигли каких-то успехов. Мне кажется, этот относительный неуспех случился именно потому, что не разбирались тщательно с собственно "требующей" стороной вопроса, модальностями с сопутствующими им "возможными мирами" альтернативных дизайнов и т.д.. Хотя контринтуитивность онтологии компактного и элегантного описания моделей именно требований и доказательства им соответствия надёжно удалила бы эти решения из мейнстрима, если, конечно, эта контринтуитивность не будет скрыта программными инструментами, работающими непосредственно с промышленными САПР и PLM. Как и в любых других подобных случаях, побеждает наличие или отсутствие хороших инструментов, а не наличие или отсутствие хороших идей.
Так что сегодняшние "требования" -- это исключительно текстовые описания, к которым какие-то структурные представления приклеиваются в виде исключения, а не правила.
Над требованиями-текстами, тем не менее, разводят мереологию, "разбиения". Разбиения бывают двух уровней: коллекции и декомпозиции. Так, "спецификация" -- это некоторый набор/коллекция одиночных требований, которые понимаются как элементарные текстовые неиерархически в плане детализации зависимые или независимые друг от друга высказывания "одного уровня". Декомпозиция идет по иерархии (когда одно текстовое высказывание "детализируется" рядом других, более подробных -- и так на несколько уровней), или трассировка (привязывание текстовых описаний-требований к тем элементам описаний проекта, которые поминаются в этих описаниях-требованиях). Альтернативное понимание "спецификации" -- это документ, в котором присутствует одна или несколько таких иерархий. Конечно, есть и варианты табличного представления требований, и много других типов представлений. Все эти варианты сводятся к тому, что обсуждается форма описания свойств продукта, процесса, описания продукта и всего остального, что может быть описано.
Увы, поскольку в требованиях есть модальный винегрет, они явно частичны и обычно даются безо всякого анализа и их привязки друг ко другу, то "описание продукта" в терминах требований -- это просто "нарезанный текст", существенно непохожий на архитектурные описания с их хоть какой-то формальностью.
По факту все стандарты работы с требованиями поэтому касаются только формы -- ибо содержание "уходит в текст" и отчасти "определяется связями". По факту это означает, что стандарты эти по минимуму затрагивают инженерию требований в ее содержательных аспектах, а имеют дело в основном с управлением требованиями (т.е. сбором требований, их хранением и предоставлением выписок из хранимого всем заинтересованным сторонам -- без малейшего интереса к содержанию собираемого и хранимого).
Более того, требования высокого уровня (например, требования регулятора) часто посвящены не собственго требованиям к системе, а требованиям к форме описания системы -- например, составу документов проекта, о чем тематически писать в этих документах (но не что именно писать -- система-то на момент появления требования еще неизвестна, и содержание документов поэтому понятно только как "тема"), какие работы тематически выполнить (опять же -- на уровне общности, не предусматривающем часто даже понимание конкретных шагов работы, только "тематика").
Соответственно, все инструменты работы с требованиями (DOORS, Clollabra, IRqA и т.д.) -- они про управление требованиями (управление конфигурацией каких-то иерархий обрывков текста), в них нет и намёка на модели требований в смысле GORE или любой другой методологии работы с требованиями, нет и намёка на "модель продукта" в понимании инженеров (для которых "модель продукта" -- это набор диаграмм, чертежей, принципиальных схем и т.д.). Нет, только порезанный на отдельные фразы текст, и (в лучшем случае) -- указатели, к чему в реальной модели продукта и процесса эти огрызки текста относятся.
Ниже приведу краткую характеристику нескольких стандартов управления требованиями. Не ищите там каких-то сортировок на "функциональные требования" в противовес "требований к конструкции", или "цели" в противопоставление "средствам" -- это вам не GORE. Тут всё просто и промышленно: взял не глядя у одного, верни не глядя другому, а таки третий глянет -- при приёмке-сдаче.
1. SysML (спецификация SysML 1.2 от 1 июня 2010: http://www.omg.org/spec/SysML/1.2/).
В SysML есть специальный тип диаграмм: требования. Основное назначение -- привязать текстовые описания требований к элементам архитектурных описаний, интегрировать требования в архитектурную модель.
Привязки этих текстов вполне определенные: verify (например, к тестовому сценарию или другому элементу, что может определить соответствие), satisfy (к элементу, который уже определяет соответствие). У этих привязок-отношений может быть указано обоснование (rationale). Указывается также трассировка (зависимость от требования) и уточнения, а также производность требований друг от друга. Тем не менее, сами типы привязок существенны для системной инженерии: <<SATISFY>>, <<VERIFY>>, <<REFINE>>, <<TRACE>>, <<copy>>... -- и тут нужно отметить, что в остальных стандартах подобные связи по факту произвольны, и их выбор зависит от настройки.
Требования в SysML могут быть собраны в таблицы -- главным образом для удобства восприятия.
Важна идея повторноиспользуемости требований: поэтому вводится отношение копирования -- требования-хозяева (master, т.е. "оригиналы") и требования-рабы (slave, т.е. "копии"), которые суть случаи повторного использования требований-хозяев.
Главное использование требований в SysML -- это аннотация требованиями архитектуры, выраженной в SysML. Конечно, при этом есть опыт мэппинга требований SysML в RIF (http://www.erts2010.org/Site/0ANDGY78/Fichier/PAPIERS%20ERTS%202010%202/ERTS2010_0087_final.pdf), ибо мало кого устраивает иметь требования привязанными именно к SysML-представлению всех остальных архитектурных, дизайнерских, тестировочных артефактов. Впрочем, OMG ведет активные согласования RIF (старое название ReqIF), SysML и AP233 --и при этом приходится дополнять SysML, чтобы удовлетворить RIF (о чем и рассказывается в статье по ссылке). Все это одно и то же по большому счёту: аннотация архитектуры обрывками текста и контроль конфигурации этих обрывков.
То, что USE CASE диаграммы тоже задают требования, опустим.
Также опустим многочисленные инициативы иметь специализированный UML-профиль для управления требованиями (часто на базе SysML), желающие могут поинтересоваться DARWIN4Req.
2. AP233 (aka ISO 10303-233 "systems engineering", обзор схемы тут: http://homepages.nildram.co.uk/~esukpc20/exff2005_05/ap233/ap233/index.html, а формально тут: http://ap233.org/)
Тесно связан с PLCS (product life cycle supprort, который в миру известен также как AP239, http://www.plcs-resources.org/), его роль -- описывать продукты в их связи с практиками жизненного цикла.
Основное при описании требований для этого стандарта -- это обозначить требования как первоклассный продукт в инженерной практике, чтобы "описания процессов" могли с ними работать. Поэтому тут требования -- это подкласс класса продукта, наследующий все особенности продукта (управление конфигурацией/версионность, разбиения по разным принципам, различные группы описаний одного и того же продукта).
На этом счастье кончается, и приходится довольствоваться обычной даталогией: определять view_definition_relationship и классификацию для всего того, что хочется содержательного сказать про требования. Прямо можно сказать разве что Requirement_satisfied_by.
Тут нужно отметить, что AP233 -- это такой же язык описания архитектуры, как и SysML, только архитектура описывается в других терминах: система, интерфейсы/порты и прочие "системноинженерные" понятия.
Мэппинг между SysML и AP233 идет тут: http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-ap233:mapping_between_sysml_and_ap233 -- для отражения необходимых конструкций в SysML, а не для изменения самого AP233.
Беда с AP233 та же, что со всеми другими стандартами STEP: инструментальная его поддержка крайне мала, стандарт этот по необходимости обо всём, и тем самым ни о чём, но недостаточно всеохватен, чтобы положиться на него во всех задачах. Та же беда, что с SysML: ежели всё остальное моделирование (не только требований, но и архитектуры) в STEP, то его можно использовать.
3. RIF (он же ReqIF, он же IntRIF, свежая версия -- 1.2 от октября 2008г. вот тут: http://www.prostep.org/en/project-groups/internationalization-of-the-requirements-interchange-format-intrif.html).
Придуман для того, чтобы облегчить обмен данными между инструментами работы с требованиями в автомобильной промышленности, но вышел далеко за пределы автомобилестроительства, и сейчас стандартизуется уже OMG (это третья организация, куда перемещается этот стандарт по мере возрастания его важности).
Даталогичен, семантика требований из него намеренно выкошена по максимуму -- определяет "элементы данных", которые передаются между программами. По факту, это просто сериализация какой-то явно описанной структуры требований, причем в отличие от других стандартов, эти требования могут быть не только текстовые на естественном языке, но и XML-текстом, и даже binary данными.
Требования тут -- это SpecObjects, которые подкласс абстрактного "элемента спецификации с определяемым пользователем атрибутами" с минимально двумя атрибутами: ID и текстом требования на естественном языке.
Важно, что это единственный стандарт, который активно развивается по инициативе снизу, и который ориентирован на абсолютно практическую задачу обмена требованиями между реальными, а не идеальными инструментами. Крупные фирмы разворачиваются именно на этот стандарт (см. пример: http://www.atego.com/downloads/support/data-sheets/AtegoExerptSynchronizer.pdf).
В этом стандарте самое интересное -- это долго разглядывать таблицу с примером мэппинга основных инструментов разработки требований (и при этом разглядывании понимать, что нет никакого унифицированного "управления требованиями"): http://www.prostep.org/fileadmin/freie_downloads/Empfehlungen-Standards/ProSTEP_iViP/PSI6_RIF_1.2_Mapping-Table.pdf
Итого: ежели вы хотите, чтобы ваши требования могли перемещаться между разными приложениями, нужно выбирать RIF 1.2, поддержанный инструментами стандарт де-факто.
4. ISO 29148 (в Сети недоступен)
Это стандарт описания практик инженерии требований, который только мимоходом описываеттребования к артефактам-требованиям и их группам -- например, приводит рекомендации по формулированию текстовых огрызков, из которых состоят требования (типа "обязательность выражайте как shall, а will избегайте", "синтаксис треования -- [условие] [предмет] [действие] [объект] [ограничение] или [условие] - [действие] -[значение]"), и агрегирование этих огрызков в списки-"спецификации".
Стандарт считает требования объектом и приводит пример атрибутов: идентификацию, приоритет, критичность, риск, источник, обоснование, трудность, тип (например, требования функциональные, эксплуатационные характеристики, интерфейсные, ограничения проекта, нефункциональные (в том числе требования качества и требования со стороны человеческого фактора), процессные). Опять же, это всё примеры, а не жесткие требования по составу атрибутов.
Требования делятся на (в соответствии с ISO 15288) заинтересованных сторон и системные. Системные требования, в частности, включают функциональную границу системы в терминах обеспечиваемого системой поведения и свойств, определение каждой функции, реализационных ограничений, технических мер и мер качества. Но это всё вытаскивается из текста и явно не похоже на вменяемую стандартом классификацию. Похоже, что авторы стандарта хотели бы проверять не результаты этих работ (артефакты), а то, что велись сами работы (выполнялись практики). В принципе, ежели хочется максимизировать состав артефактов и их возможных состояний (до и после проверок целостности, рассмотрения независимыми экспертами и заинтересованными сторонами, разных анализов и уточнений, обоснований и т.д.), то этот стандарт поможет открыть практически неограниченный фронт работ.
Делаются странные заявления: Requirements validation ensures that stakeholder requirements have been correctly transformed into system requirements. Various techniques may be used, including stakeholder reviews, prototyping, modeling and simulation, conceptual modeling, and formal modeling. -- такое впечатление, что моделирование требований делается только для их валидации, а сами валидированные требования затем остаются в их исходной текстовой форме, модели затем не используются. Очень странно.
Вводятся и другие понятия: база данных требований, документы требований (которые могут быть спецификация требований заинтересованных сторон, concept of operations и operational concept -- последние два в проекте стандарта определены по-разному) и требования к содержанию этих документов (как я понял, если именно они будут сочтены необходимыми, а не только рекомендуемыми), а по форме документов -- только рекомендации в форме возможной нумерации секций документа, отраженных в содержании. Из чего можно сделать вывод, что документы эти -- исключительно тексты, возможно с немногими картинками-иллюстрациями, но уж никак не формальные модели. Выглядит это так (SyRS -- system requirements specification):
7.4.2.5 Major system constraints (section 2.5 of the SyRS)Набор требований нужно сопровождать в ходе жизненного цикла обязательно вместе со связанными обоснованиями, решениями (decisions) и предположениями (assumptions). Требования также привязываются к базисам.
The major system constraints clause of the SyRS shall define any constraints under which the system must operate, and any constraints on the system design.
С этим стандартом тесно связан ISO 24766:2009 -- руководство по [желаемым] возможностям инструментов инженерии требований (Guide for requirements engineering tool capabilities).
5. ITU Z.151 (URN -- user requirements notation) -- GRL+UCM (goal-orientend requirements language, use case maps -- http://jucmnav.softwareengineering.ca/ucm/bin/view/UCM/WebHome).
Пара языков, описывающих соответственно цели/намерения (goals/intentions) систем и заинтересованные стороны в GRL, а также пользовательские сценарии в UCM, плюс связи между элементами этих языков.
Содержит понятия актора (у которого есть намерения), эти намерения (измеримые и туманные цели, задачи, ресурсы и убеждения), и разные связи (например, "вклад осуществления одного намерения в осуществление другого"), а также стратегии оценки выбранного сочетания намерений и их вкладов друг в друга.
Очень интересна другая рекомендация: требования к языку требований, стандарт ITU Z.150 (http://www.itu.int/rec/T-REC-Z.150-200302-I/en), клауза 6 (пятнадцать требований -- от возможности записывать трудноформализуемые требования в самом начале работы до обеспечения повторной используемости частей отмоделированных спецификаций).
6. Другие языки из подхода GORE (goal-oriented requirements engineering).
Все эти стандарты пытаются явно залезть в отношение "цели/требования -- средства/архитектурные решения". К числу таковых можно отнести:
а) RFLP в ENOVIA V6 (Requirements, Functions, Logical components, Physical components, http://www.3ds.com/fileadmin/PRODUCTS/ENOVIA/PDF/Datasheets/V62010/DFL2010-0906.pdf) -- текстовые требования аннотируют элементы архитектурного функционального и модельного (логического) описания.
Вообще-то это не из подхода GORE, и даже не стандарт -- но явно можно отнести к аналогам SysML и AP233.
б) ArchiMate -- http://www.opengroup.org/archimate/doc/ts_archimate/ (в которой требования моделируются по идеям из *i). Трудность та же, что в SysML: основная цель -- это иметь связное описание архитектуры и требований. Бессмысленно использовать только фрагмент, связанный с требованиями.
в) MBRD -- model-based requirements discovery (от Яна Александера): см. метамодель для MBRD -- http://easyweb.easynet.co.uk/~iany/consultancy/mbrd/Model-Based%20Requirements%20Discovery%20Talks%20at%20RuSEC.htm. Стоит взглянуть не только на эту метамодель, но и на полный текст презентации Яна Александера.
г) OMG BMM (Business Motivation model, свежая версия 1.1, май 2010 ) -- но это больше подходит к анализу организаций (хотя, по большому счёту совершенно не ограничивается организацией. Та же многоуровневая оппозиция "цели-средства", и даже встроенный в эту метамодель SWOT-анализ можно применить к железякам). С другой стороны, этот стандарт для формулирования "стратегий" (именуемых там "бизнес-планами"), и поэтому к его использованию в общем случае нужно подходить с осторожностью. Объекты-элементы не содержат много атрибутов: для большинства доступны только идентификатор и текстовое описание.
д) Planguage (http://gilb.com/FileGalleries) -- что-то типа псевдокода для записи архитектуры и требований. Включает принципы хорошего определения требований.
В этой серии стандартов особое внимание обращается как раз на сам предмет требований: выражение чьей-то интенции, задание последующих действий и решений.
Рекомендуется также проглядеть предыдущий обзор http://ailev.livejournal.com/811715.html -- он почти целиком уходит в этот пункт.
Работы по моделированию регулирования/законодательства (например, NOMOS) пока исключаем.
7. ISO 15926 (http://193.212.132.108/apps/rdsclient.html).
Понятие требования есть -- REQUIREMENT (RDS11703698) типа DOCUMENT_DEFINITION с определением "спецификация чего-то, что должно быть поставлено" (a specification of something to be delivered). Дальше непаханная целина, ибо уже подклассы в помойке текущего "главного RDL мира" (http://193.212.132.108/apps/rdsclient.html) представляют собой пример китайской классификации по Борхесу: требования компании, собственника, регуляторные требования (и даже не "требования регулятора"), дальше в том же ряду функциональные, трассирующие, доступности, функциональные...
Модальности не предусмотрены, но их можно явно моделировать (чем, как я понял, еще никто не занимался -- хотя алетическая модальность может задаваться кардинальностью и прочими хитрыми вывертами). С другой стороны, для алетической модальности указан формализм: модальный реализм (среди критики которого первой идет "катастрофическая контринтуитивность", а среди достоинств -- совместимость с 4D экстенсионализмом, концепцией возможных миров и краткость выражения собственно модальности за счет признания множественности и "настоящести" этих множественных возможных миров -- http://en.wikipedia.org/wiki/Modal_realism).
Есть тенденция всё то, что указано классами-описаниями, рассматривать как требования к (будущим с точки зрения хода проекта) экземплярам-железкам, но это лишь "приговаривается" к схемам, а в них самих не содержится.
Собственно, это стандарт такого же сорта, как SysML или ArchiMate, только предназначен не только для высокоуровневого, но и для полного обмена информацией между любыми вычислительными системами в ходе инжинирингового проекта по всему жизненному циклу -- в том числе и обмену требованиями.
Тем самым задача -- явно отмоделировать в этом стандарте требования, и для этого есть все возможности. Штатный для этого способ в ISO 15926: отмоделировать какой-то "стандарт для требований", а далее требования представлять в соответствии с этим стандартом, но уже в формате ISO 15926.
* * *
Итого: есть два основных типа работы с требованиями (если касаться структуры артефакта требований, а не практик жизненного цикла):
-- поддержка огрызков текстов без акцента на "намерение" с привязкой к разным элементам проекта. Лидером тут является RIF в его версии 1.2
-- поддержка какой-то квазилогической структуры разноуровневых намерений (в духе GORE), с документированием выборов и промежуточных целей-требований. Явного лидера нет, но правильно правильно ориентироваться на ITU Z.150 и Z.151.
Ян Александер демонстрирует попытки совмещения обоих подходов: GORE-плагины к DOORS (http://www.scenarioplus.org.uk/tools_rd.htm).
ISO 29148 -- важный, но неохватный, в него нужно внимательно смотреть, тяжело вздыхать, а потом делать "по мотивам" что-то облегчённое -- всего в нём написанного в требованиях не представишь (или к каждому требованию и узлу иерархии требований нужно будет крепить огромный чеклист, никогда не заполняемый).
Это у меня крайне неполный обзор, ибо улучшением/упорядочиванием представления требований в мире последние пять лет не занимались только самые ленивые. Но нельзя объять необъятное, поэтому заканчиваю с использованием метода closed time box (пункт 4 из http://litemind.com/time-boxing/).
