Стандарты представления требований
Еще раз об требования (интересно, сколько раз я уже обо всём этом тут писал?!). Традиционно требования понимаются как спецификация (т.е. точное формулирование) способности (capability) или условия (condition), которое должно или может быть удовлетворено (функция, которую нужно будет выполнить, или характеристика, которую нужно достигнуть и т.д.).
В требованиях есть тем самым модальные составляющие (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). Указывается также трассировка (зависимость от требования) и уточнения, а также производность требований друг от друга. Тем не менее, сами типы привязок существенны для системной инженерии: <>, <>, <>, <>, <>... -- и тут нужно отметить, что в остальных стандартах подобные связи по факту произвольны, и их выбор зависит от настройки.
Требования в 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)
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.
Набор требований нужно сопровождать в ходе жизненного цикла обязательно вместе со связанными обоснованиями, решениями (decisions) и предположениями (assumptions). Требования также привязываются к базисам.
С этим стандартом тесно связан 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/).
В требованиях есть тем самым модальные составляющие (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). Указывается также трассировка (зависимость от требования) и уточнения, а также производность требований друг от друга. Тем не менее, сами типы привязок существенны для системной инженерии: <>, <>, <>, <>, <>... -- и тут нужно отметить, что в остальных стандартах подобные связи по факту произвольны, и их выбор зависит от настройки.
Требования в 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)
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.
Набор требований нужно сопровождать в ходе жизненного цикла обязательно вместе со связанными обоснованиями, решениями (decisions) и предположениями (assumptions). Требования также привязываются к базисам.
С этим стандартом тесно связан 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/).