Фиксация требований с помощью инструментов Business Motivation Model, IBM Rational RequisitePro и IBM Rational Software Modeler

Эти инструменты помогают найти ответы на вопросы «кто?», «что?», «почему?» и «как?» применительно к бизнес-требованиям

Своевременное создание эффективных бизнес-решений начинается с понимания требований. Хороший анализ требований способен существенно повысить шансы на разработку решений, успешно преодолевающих имеющуюся проблему. Фиксация требований существенно облегчается посредством их четкого разделения на следующие категории: «кто?», «что?», «почему?» и «как?». Управление требованиями требует наличия адекватных связей со средствами, которые осуществляют их выполнение. Эта статья описывает расширения продуктов IBM® Rational® RequisitePro и IBM® Rational® Software Modeler, поддерживающих модель OMG BMM (Business Motivation Model), которая обеспечивает графическое представление бизнес-требований и отношений между ними, а также отношений со средствами, которые осуществляют их выполнение.

Джим Амсден, инженерно-технический работник, IBM

Джим Амсден (Jim Amsden) работает в IBM в качестве старшего инженерно-технического работника и имеет более чем 20-летний опыт работы в области проектирования и создания приложений и инструментов для разработки программного обеспечения. Он имеет степень магистра в области информационных технологий от Бостонского Университета (Boston University). Среди его профессиональных интересов - разработка на основе контрактов, программирование агентских компонентов, разработка, управляемая бизнесом, J2EE UML и сервис-ориентированная архитектура. Он является одним из авторов книги "Enterprise Java Programming with IBM WebSphere" (Программирование корпоративных решений на Java при помощи IBM WebSphere). В настоящее время Джим сосредоточен на поиске методов интеграции инструментов для поддержки процессов динамической разработки.



11.03.2010

Об этой статье

В статье описывается общая модель требований, реализованная как шаблон IBM® Rational® RequisitePro® с соответствующим профилем UML, который можно загрузить с IBM® developerWorks® (см. раздел Загрузка). Эта модель удовлетворяет минимальным требованиям по возможностям управления (описываются ниже) и обеспечивает основу для последующего создания новых возможностей. В статье рассматриваются следующие темы

  • Использование модели BMM (Business Motivation Model), разработанной организацией OMG (Object Management Group – Группа управления объектами), в качестве примера стандартной метамодели для управления требованиями.
  • BMM-шаблон RequisitePro, в том числе типы требований и применимые возможности отслеживания, а также атрибуты и древовидные представления для отслеживания отношений в модели BMM
  • Профиль BMM UML (Unified Modeling Language), соответствующий шаблону RequisitePro
  • Элементы, требования и связывающие отношения между профилем BMM UML и типами требований RequisitePro
  • Получение и установка профиля/шаблона
  • Примеры использования шаблона и профиля

BMM – это простая в освоении и применении «отправная точка» для перехода к метамодели управления требованиями, основанная на практически применяемом бизнес-стандарте. BMM позволяет использовать соответствующие инструменты для понимания смысла требований и их отношений с бизнес-процессами и с ИТ-решениями, которые реализуют эти требования. Эффективное решение этой задачи затруднено, если стандартная или совместимая метамодель требований отсутствует или если имеющаяся метамодель является настолько общей, что ее требования имеют мало семантического смысла.

Возможности модели BMM позволяют применять ее для фиксации бизнес-требований практически в любой области. Таким образом, модель BMM может быть с легкостью использована для фиксации бизнес-требований, требований руководства, требований разработки ИТ-приложений, нефункциональных требований и т.д. на всем протяжении жизненного цикла соответствующего приложения.

Определение требований и управление ими

Определение требований и управление ими – обширная тема, которая выходит за пределы данной статьи. Тем не менее отметим, что в этой области необходимы как минимум следующие возможности:

  • Моделирование семантически насыщенных требований и отношений между ними
  • Соединение требований с решениями, которые осуществляют их реализацию, таким способом, который позволяет использовать смысл этих требований и решений для улучшения верификации, валидации и управления изменениями. Просмотр и анализ требований для отслеживания отношений, управления изменениями, отчетности и оценки
  • Удобный доступ и обновление требований с помощью Web-браузера
  • Просмотр и редактирование требований в формате RTF (Rich-text-format)
  • Просмотр и редактирование графического представления требований и их отношений

Инструмент Rational RequisitePro предоставляет возможности для фиксации требований, определения требований и управления требованиями. Инструмент IBM® Rational® Software Architect поддерживает моделирование на языке UML, что позволяет показать возможности для реализации этих требований. Инструмент RequisitePro интегрирован с инструментом Rational Software Modeler, что позволяет визуализировать требования и соединять элементы модели с требованиями, реализуемыми посредством этих элементов.

Продукт RequisitePro предоставляет несколько шаблонов требований, которые вы сможете использовать для конфигурирования баз данных требований с необходимыми типами требований в соответствии с потребностями конкретного проекта:

  • Blank
  • Composite template
  • Create from baseline
  • RUP® template (IBM® Rational Unified Process®)
  • Traditional template
  • Use case template

Хотя эти шаблоны весьма полезны, для некоторых пользователей они могут оказаться недостаточно ориентированными на бизнес или недостаточно общими, чтобы быть применимыми на протяжении всего жизненного цикла разработки. В результате требования могут оказаться сложны для их применения бизнес-аналитиками вследствие неподходящих типов требований и отношений между ними. Кроме того, это может привести к усложнению связей между базами данных RequisitePro, которые содержат разные типы требований для поддержки приложений на протяжении всего жизненного цикла.

Инструмент Rational Software Modeler способен создавать модели на основе применяемых профилей. Эти профили можно использовать в качестве UML-расширений для поддержки визуального моделирования требований. Этот инструмент также интегрирован с RequisitePro, что позволяет создавать и связывать требования с помощью различных инструментов. В состав Rational Software Modeler включены следующие профили:

  • Профиль Analysis
  • Профиль Business Modeling
  • Профиль Software Services

Профиль Business Modeling имеет стереотипы Business Goal (бизнес-цель) и Business Service (бизнес-сервис), которые соответствуют типам требований в RUP-шаблонах RequisitePro. Кроме того, существуют типы требований для моделирования разных стилей сценариев применения (use case), в том числе бизнес-сценариев и системных сценариев. Однако эти профили поддерживают моделирование ограниченного числа требований, особенно применительно к бизнес-требованиям.

Многие клиенты IBM для моделирования требований создают свои собственные шаблоны RequisitePro и профили UML. Однако это может привести к появлению нестандартных требований и несогласованных отношений между требованиями и средствами их реализации. Более стандартизованный подход к управлению требованиями упрощает интеграцию бизнес-сервисов.

Таким образом, можно ограничиться стандартным шаблоном RequisitePro и соответствующим профилем UML, который поддерживает возможности управления требованиями. Наличие такого стандарта не только расширяет возможности моделирования требований, но и позволяет разрабатывать инструменты, способные управлять требованиями более эффективно за счет способности интерпретировать смысл требований и их отношения с другими артефактами в процессе проектирования и создания решения.

Обзор модели Business Motivation Metamodel

OMG Business Motivation Metamodel (BMM) – это простая метамодель для фиксации бизнес- требований. Она ориентирована на фиксацию семантически насыщенных требований, которые полезны для таких областей, как бизнес-анализ, обработка запросов, анализ воздействий, управление изменениями и бизнес-обоснования. BMM – это один из нескольких перечисленных ниже стандартов OMG, разработанных рабочей группой по моделированию и интеграции бизнеса Business Modeling and Integration Task Force (BMI-TF).

  • Business Motivation Metamodel (BMM)
  • Semantics of Business Vocabulary and Rules (SBVR)
  • Organizational Structure Metamodel (OSM)
  • Business Process Definition Metamodel (BPDM)
  • Business Process Modeling Notation (BPMN)
  • Business Process Maturity Metamodel (BPMM)

Самые современные версии этих документов можно получить в каталоге Catalog of OMG Business Rules and Process Management Specifications (Бизнес-правила/спецификации управления процессами, организация OMG) (см. раздел Ресурсы).

BMM – применяемый на практике подход к фиксации бизнес-требований, который в октябре 2007 г. был оформлен как стандарт OMG. В настоящее время отмечается появление различных инструментов, поддерживающих этот стандарт, например, Xactium Business Motivation Solution. Это создает возможности, выходящие за рамки простых списков связанных элементов требований. Такие списки поддерживают лишь ограниченные возможности отслеживания и при этом не обладают достаточными семантическими возможностями, чтобы судить об отношениях между самими требованиями и элементами, которые предназначены для реализации этих требований.

Модель BMM регистрирует бизнес-требования по различным категориям, что позволяет точно зафиксировать и обосновать, почему бизнес хочет сделать что-либо, что он стремится получить в результате, как он планирует делать это и как будет оценивать результаты.

  • Ends (Конечные результаты): что бизнес хочет получить, а не как
  • Means (Средства): как бизнес намеревается достигнуть своих зафиксированных целей
  • Directives (Директивы): правила и политики, которые ограничивают доступные средства и/или руководят ими
  • Assessment (Оценка): как «средства» оцениваются на соответствие «целям», кто осуществляет эту оценку и как оценивается потенциальное воздействие расхождений
  • Influencers (Источники влияния): Кто или что осуществляет оценку или влияет на нее иным образом

Совет.
Для получения более подробной информации относительно BMM обратитесь к спецификации OMG BMM Specification (см. раздел Ресурсы).

На рис. 1 модель BMM представлена в общем виде. Не все метаклассы этой метамодели включены в шаблон RequisitePro и в профиль UML, поскольку некоторые из них являются абстрактными суперклассами.

Рисунок 1. Обзор BMM
Рисунок 1. Обзор BMM

Более крупное изображение рисунка 1.

Загрузка и установка профиля и шаблона BMM

При создании профиля BMM был использован новый инструмент для генерации профилей из состава продукта Rational Software Modeler 7.0.5, с помощью которого для профиля были созданы подключаемый модуль и интерфейс пользователя. Этот профиль является хорошим примером того, как использовать механизмы расширения продукта Rational Software Modeler для поддержки новых возможностей моделирования. Он также может быть использован для фиксации бизнес-требований и связывания их с остальными элементами модели, реализующими эти требования. Тем не менее, данный профиль и шаблон RequisitePro не относятся к числу поддерживаемых компонентов продуктов Rational Software Modeler и RequsitePro.

Для установки профиля BMM UML выполните следующие шаги:

  1. Загрузите и распакуйте файл Business Motivation Model Profile (см. раздел Загрузка).
  2. Запустите продукт Rational Software Architect версии 7.0.0.5 или выше, после чего выберите Help > Software Updates > Find and Install.
  3. Выберите опцию Search for new features to install.
  4. Нажмите на кнопку New Local Site, затем перейдите к местоположению распакованного вами ранее файла и выберите папку Business Motivation Model Profile (см. рис. 2).

В списке Sites to include in search list: появится новый сайт (см. рис. 2).

Рисунок 2. Новый сайт
Рисунок 2. Новый сайт
  1. Нажмите на кнопку Finish, чтобы увидеть опции, доступные для установки.
  2. В окне Updates/Search Result (рис. 3) выберите опцию Business Motivation Model profile.
Рисунок 3. Выбор опции Business Motivation Model Profile
Updates screen with BMM Profile selected as the feature to install
  1. Нажмите Next и примите лицензионное соглашение.
  2. Нажмите Next для демонстрации местоположения установки.
  3. Нажмите Finish, чтобы согласиться с местоположением по умолчанию и установить новую опцию.
  4. Инсталлятор предложит вам перезапустить инструментарий, чтобы приступить к использованию установленных опций.

Теперь вы можете создавать модели UML из шаблона BMM (рис. 4) или применять профиль BMM к существующей модели (рис. 5).

Рисунок 4. Создание модели UML из шаблона BMM
Рисунок 4. Создание модели UML из шаблона BMM
Рисунок 5. Применение профиля BMM к существующей модели
Рисунок 5. Применение профиля BMM к существующей модели

Теперь существующая модель имеет дополнительные возможности для создания и связывания элементов модели BMM (см. рис. 6).

Рисунок 6. Новые опции для создания и связывания элементов модели BMM
Рисунок 6. Новые опции для создания и связывания элементов модели BMM

Более крупное изображение рисунка 6.

Для установки BMM-шаблона базы данных RequisitePro выполните следующие шаги:

  1. Перейдите к местоположению установки инструментария Rational Software Architect или Rational Software Modeler (как правило, D:\SDP70).
  2. Перейдите к шаблонам plugins\com.ibm.xtools.uml.profiles.bmm.ui\RequisitePro templates.
  3. Скопируйте папку BMM-шаблонов в папку шаблонов RequisitePro (как правило, она находится по адресу D:\Program Files\Rational\RequisitePro\templates).

Теперь при запуске продукта RequisitePro вы сможете создать новый проект RequisitePro с помощью шаблона BMM Template, как показано на рис. 7.

Рисунок 7. Начало создания нового проекта RequisitePro с помощью шаблона BMM Template
Рисунок 7. Начало создания нового проекта RequisitePro с помощью шаблона BMM Template

Обзор профиля и шаблона BMM

Модель BMM поддерживается профилем UML и соответствующим шаблоном проекта RequisitePro. Интеграция требований поддерживается в следующем виде: представления диаграмм, текст в формате RTF и представления запросов к базе данных. Представления типа «диаграмма» необходимы для поддержки высокоуровневых представлений взаимосвязанных требований, которые не могут быть отображены посредством простого списка или дерева. Представления в формате RTF обеспечивают способ для эффективного документирования деталей требования. Запросы к базе данных предоставляют возможность отыскания и отслеживания отношений между требованиями, а также помогают оценивать последствия изменений.

В следующих разделах представлен общий обзор профиля BMM и соответствующих типов требований RequisitePro.

Профиль BMM

Профиль BMM показан на следующих диаграммах (рисунки с 8 по 12). Описания стереотипов аналогичны описаниям соответствующих типов требований RequisitePro, представленных в таблице 1и в разделе Артефакты требований (см. далее).

Рисунок 8. Business Motivation Model
Рисунок 8. Business Motivation Model
Рисунок 9. Цели (Ends)
Рисунок 9. Цели (Ends)
Рисунок 10. Средства (Means)
Рисунок 10. Средства (Means)

Более крупное изображение рисунка 10.

Рисунок 11. Источники влияния (Influencers)
Рисунок 11. Источники влияния (Influencers)
Рисунок 12. Оценки (Assessments)
Рисунок 12. Оценки (Assessments)

Более крупное изображение рисунка 12.

Рисунок 13. Расширения UML
Рисунок 13. Расширения UML

Как можно видеть из рис. 13, все стереотипы BMM являются расширениями артефакта языка UML 2. Артефакт – это класс, специфицирующий определенную информацию, которая используется процессом разработки или производится посредством этого процесса. В связи с этим артефакт был выбран в качестве корневого элемента для стереотипов BMM, а также для использования его демонстрируемых по умолчанию свойств, в число которых не входят принадлежащие ему атрибуты и операции.

Артефакты требований

В этом разделе описываются типы документов и требований RequisitePro, которые соответствуют стереотипам из предыдущего раздела и поддерживают разработку моделей требований BMM с использованием RequisitePro.

Типы документов

В таблице 1 описаны типы документов по умолчанию, включенные в данный шаблон, а также ассоциированные с ними типы требований по умолчанию.

Таблица 1. Типы документов и ассоциированные с ними типы требований
Тип документаОписаниеТип требования по умолчанию
Vision (VIS)Vision (представление) описывает будущее состояние предприятия, безотносительно к тому, как это состояние должно быть достигнуто. Это полное изображение того, чем организация собирается быть или стать. Как правило, это состояние охватывает всю организацию, причем в долгосрочной перспективе. Vision (VIS)
Use-Case Specification (UCS)Описание и уточнение Use Case (сценарий применения).Use Case (UC)
Glossary (GLS)Данный тип используется для фиксации общих словарных терминов.Термин глоссария (TERM)
Mission (MIS)Тип Mission (задача) применяется для определения текущей операционной деятельности предприятия. Mission – это описание того, что бизнес делает или собирается делать на повседневной основе.

Mission (задача) приводит в действие Vision (представление), т.е. документ этого типа описывает текущую деятельность, направленную на достижение состояния, описанного в соответствующем документе типа Vision. Документ типа Mission планируется согласно стратегиям (Strategies).

Дополнительное требование (SUPL)
Requirements Management Plan (RMP)Этот тип документов описывает специфические требования и стратегии для управления проектом.Тип по умолчанию для документов без требований (NONE)

Типы требований

В таблице 2 описаны типы требований по умолчанию, включенные в данный шаблон.

Таблица 2. Типы требований по умолчанию, включенные в данный шаблон
Тип требованияОписаниеАтрибуты
Assessment (ASMT)Assessment (оценка) – это суждение о некотором «источнике влияния» (Influencer), который воздействует на возможности организации по использованию ее «средств» (Means) или по достижению «конечных целей» (Ends). Другими словами, Assessment выражает логическую связь (фактологического типа) между «источниками влияния» и «конечными целями» и/или «средствами». Priority, Type, Status, Difficulty, Stability, Risk, Planned Iteration, Actual Iteration, Origin, Contact Name, Enhancement Request, Defect, Obsolete
BusinessPolicy (BPOL)Business Policy (бизнес-политика) – это директива непрямого действия, предназначенная для руководства предприятием. Бизнес-политика обеспечивает основу для бизнес-правил (Business Rule). Кроме того, бизнес-политика руководит бизнес-процессами.
BusinessRule (BRULE)Business Rule (бизнес-правило) – это директива, предназначенная для руководства поведением бизнеса в соответствии с установленной бизнес-политикой в ответ на воздействие таких факторов, как Opportunity (возможность), Threat (угроза), Strength (сила) или Weakness (слабость). Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Business Use Case (BUC)Сценарий применения, фиксирующий требования со стороны ключевых внешних заинтересованных сторон, способных участвовать в обмене ценностями.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Glossary Item (TERM) Термин, используемый в общем словаре проекта, становится частью глоссария. (Not applicable)
Goal (GOAL)Goal (цель) – это утверждение о состоянии или статусе предприятия, которое должно быть достигнуто или должно поддерживаться соответствующими «средствами» (Means). Goal (Цель) усиливает Vision (представление). Другими словами, Goal указывает, какие условия должны непрерывно соблюдаться для эффективного достижения представления, описанного в Vision.Priority, Status, Difficulty, Stability, Risk, Enhancement Request, Defect, Contact Name, Obsolete
Influencer (INFL)Influencer – это «источник», способный влиять на то, как предприятие применяет свои «средства» или достигает своих «конечных целей» (End). Последствия этого воздействия оцениваются с помощью Assessment. Mission (задача) описывает текущую операционную деятельность предприятия, а именно, что бизнес делает или собирается делать на повседневной основе. Mission (задача) приводит в действие Vision (представление).
Mission (MIS)Objective (целевой показатель) – это описание достижимого, привязанного к определенному времени и измеримого целевого показателя, который предприятие стремится выполнить для достижения состояния Goal (цель). Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Objective (OBJ) Potential Reward – это разновидность воздействия, указывающая на возможный положительный эффект. Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
PotentialReward (RWRD) Process – это средство для реализации образа действий (Course of Action) или для достижения желаемых результатов.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Process (PROC) Директива (Directive) может действовать как закон (Regulation) для некоторого другого подразделения организации. Бизнес-правила и бизнес-политики, определенные на каком-либо уровне организации, могут иметь силу закона (Regulation) для нижестоящих уровней организации.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Regulation (REG)Risk – это разновидность «воздействия» (Impact), которая указывает на силу определенного воздействия и на вероятность сопутствующих потерь.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Risk (RISK)Strategy (стратегия) – это один из компонентов плана по выполнению «задачи» (Mission). Описывает «образ действий» (Course of Action), необходимый, в частности, для достижения «целевых показателей» (Goal), соответствующих «конечной цели» (End). Как правило, «стратегия» (Strategy) канализирует усилия в направлении к упомянутым выше «целевым показателям» (Goal). Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Strategy (STRAT)Strategy (стратегия) – это один из компонентов плана по выполнению «задачи» (Mission). Описывает «образ действий» (Course of Action), необходимый, в частности, для достижения «целевых показателей» (Goal), соответствующих «конечной цели» (End). Как правило, «стратегия» (Strategy) канализирует усилия в направлении к упомянутым выше «целевым показателям» (Goal). Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Tactic (TACT)Tactic (тактика) – это «образ действий» (Course of Action), представляющий собой детализацию «стратегии» (Strategy). «Тактика» реализует «стратегию». Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Use Case (UC)Use Case (сценарий применения) – это описание поведения системы в виде последовательности действий. Сценарий применения должен приводить к наблюдаемому результату в виде определенной «ценности» для действующего субъекта (Actor).Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Vision (VIS)Vision (представление) описывает будущее состояние предприятия, безотносительно к тому, как это состояние должно быть достигнуто.Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete

Пример

Следующий пример (не включенный в материалы для загрузки) был создан с помощью продуктов Rational RequisitePro 7 и Rational Software Modeler 7.0.5. В этом примере BMM-шаблон и BMM-профиль RequisitePro, а также Eclipse-клиент RequisitePro и перспектива Requirements используются для создания простой BMM-модели. В примере показано, как создаются и интегрируются различные представления требований, а также как требования связываются с реализующими их элементами.

Сценарий

JK Enterprises – вымышленная глобальная финансовая организация, осуществляющая программу оптимизации своего бизнеса с целью улучшения процесса открытия клиентских счетов. В процессе проведения инициативы под названием Project Enterprise, посвященной оптимизации бизнес-процессов, организация JK Enterprise установила, что открытие клиентских счетов является одним из ключевых бизнес-процессов, нуждающихся в совершенствовании и автоматизации. Открытие счета включает такие этапы, как приобретение, обращение, верификация и активация.

Цели. Компания JK Enterprises желает усовершенствовать свой процесс ведения счетов, чтобы увеличить эффективность, уменьшить затраты, сократить время ожидания и повысить удовлетворенность клиентов.

Для достижения этих целей руководитель проекта Патрисия инициировала проект AMS Prime, призванный улучшить и автоматизировать некоторые этапы процесса открытия счета. Обязанности бизнес-аналитика Боба состоят в том, чтобы зафиксировать и проанализировать требования для этого проекта, а затем предоставить исходные бизнес-сценарии применения, в которых описывалось бы, что должен делать новый процесс управления счетами.

Итак, первая задача Боба состоит в том, чтобы сформулировать бизнес-требования для проекта AMS Prime. Сначала Боб определяет «представление» (Vision) с точки зрения руководителей бизнеса. Затем он определяет конкретные цели (Goals) и измеримые количественно целевые показатели (Objectives), которые «усиливают» (детализируют) представление Vision, а затем определяет «стратегии» и «тактики», которые поддерживают достижение соответствующих целевых показателей (Objectives).

Бизнес-требования типов Vision и Mission фиксируются в виде проекта RequisitePro, в виде диаграммы и в виде документа в формате RTF.

На рис. 14 в проводнике Requirements Explorer показаны проект требований Account Management (ведение счетов), распределение требований по папкам и RTF-документ Account Management Services Vision.

Рисунок 14. Требования Account Management
Рисунок 14. Требования Account Management

На рис. 15 показаны отношения между документированными требованиями Account Management Services Vision и Mission-утверждением проекта AMS Prime, которое приводит эти требования в действие (makesOperative).

Рисунок 15. Отношения между представлением Account Management Services Vision и проектом AMS Prime
Рисунок 15. Отношения между представлением Account Management Services Vision и проектом AMS Prime

Подробности требований Account Management Services Vision зафиксированы в виде документа в формате RTF (рис. 16). Элемент в базе данных требований, элементы модели в диаграмме и документ с требованиями – все эти элементы соединены между собой, что позволяет представлять одну и ту же базовую информацию о требованиях в различных видах с возможностью навигации между этими представлениями.

Рисунок 16. Документ Account Management Services Vision, обобщающий требования
Рисунок 16. Документ Account Management Services Vision, обобщающий требования

Указанные требования могут быть созданы из модели или из обозревателя RequisitePro Requirement Explorer. Для создания требований из модели можно воспользоваться инструментами из палитры BMM или пунктами всплывающего меню Add BMM. Требование RequisitePro можно связать с нужным элементом модели посредством «перетаскивания» (drag) этого требования из обозревателя Requirements Explorer на соответствующий элемент в модели. В настоящее время продукт RequisitePro не поддерживает политик создания элементов и требований, которые распознавали бы стереотипы UML. Поэтому, если вы будете использовать требование RequisitePro для создания нового элемента модели UML, вам придется выбрать созданный Артефакт (Artifact) и настроить его стереотип согласно типу соответствующего требования. Аналогично, если вы создаете требование RequisitePro из элемента модели BMM, вы должны установить для этого требования RequisitePro тип, соответствующий стереотипу указанного элемента.

После рассмотрения представления (Vision) своего проекта Боб детализирует («усиливает») это представление с помощью более конкретных бизнес-целей (Goals), а затем количественно определяет каждую из этих целей с помощью еще более конкретных, измеримых, достижимых, реалистичных и привязанных ко времени целевых показателей (Objectives).

На рис. 17 показаны цели проекта (Goals) в репозитарии требований.

Рисунок 17. Сохраненные цели проекта (Goals)
Рисунок 17. Сохраненные цели проекта (Goals)

Совет.
Вы можете нажать мышью на пункт Goals (цели), подсвеченный на рис. 17. Это приведет к выполнению запроса, который покажет более детализированную информацию в представлении Requirements Query (Запрос требований). Результаты этого запроса показаны на рис. 18.

Рисунок 18. Детальная информация пункта Goals
Рисунок 18. Детальная информация пункта Goals

Цели (Goals) и целевые показатели (Objectives) можно также представить в виде диаграммы (см. рис. 19). Это облегчает понимание того, какие цели (Goals) «усиливают» представление (Vision) и какие целевые показатели (Objectives) определяют эти цели количественно.

Рисунок 19. Как целевые показатели (Objectives) определяют представление (Vision) количественно
Рисунок 19. Как целевые показатели (Objectives) определяют представление (Vision) количественно

Каждый элемент на диаграмме связан с соответствующим ему требованием в обозревателе Requirements Explorer (см. связующие стрелки в представлении обозревателя Explorer на рис. 18) и в разделе Word-документа. Это упрощает навигацию между различными представлениями.

К настоящему моменту Боб уже знает, «что» хочет достигнуть бизнес и «почему». Теперь Боб должен определить стратегии (Strategies) и тактики (Tactics) для достижения вышеуказанных целей (Goals) и целевых показателей (Objectives).

На рис. 20 используемая база данных требований развернута, чтобы показать соответствующие стратегии и тактики.

Рисунок 20. Стратегии (Strategies) и тактики (Tactics) в секции Courses of Action
Рисунок 20. Стратегии (Strategies) и тактики (Tactics) в секции Courses of Action

При выборе пункта Tactics (рис. 21) будет инициирован запрос, который предоставит дополнительные сведения по каждой «тактике».

Рисунок 21. Результаты запроса с детальными сведениями по тактикам
Рисунок 21. Результаты запроса с детальными сведениями по тактикам

Более крупное изображение рисунка 21.

Как и в случае с конечными целями бизнеса, вы также можете визуализировать отношения между «средствами» (Means) и «образами действий» (Courses of action). На следующей диаграмме (рис. 22) показаны планируемые стратегии AMS Prime и тактики, реализующие эти стратегии.

Рисунок 22. Стратегии и тактики в виде диаграммы
Рисунок 22. Стратегии и тактики в виде диаграммы

Боб также связывает бизнес-средства (Means) с конечными целями (Ends), которые достигаются посредством применения этих средств (см. рис. 23).

Рисунок 23. Отношения между средствами (Means) и конечными целями (Ends)
Рисунок 23. Отношения между средствами (Means) и конечными целями (Ends)

Затем Боб компонует бизнес-политики и бизнес-правила, которые руководят образами действия (рис. 24).

Рисунок 24. Графическое представление соответствующих политик и правил
Рисунок 24. Графическое представление соответствующих политик и правил

К настоящему моменту Боб зафиксировал бизнес-требования, которые выражают желаемый бизнес-результат, образы действий, которые обеспечивают достижение этих результатов, и директивы, которые руководят этими действиями. Теперь Боб готов к фиксации более детальных требований для того, чтобы реализовать эти образы действий в виде бизнес-решения и в виде ИТ-решения. Боб создает бизнес-сценарии применения, фиксирующие детальные требования со стороны ключевых внешних заинтересованных сторон (рис. 25).

Рисунок 25. Бизнес-сценарии применения
Рисунок 25. Бизнес-сценарии применения

Боб также может соединить свои требования с бизнес-компонентами, с системными сценариями применения, с процессами, с взаимодействующими сервисами и с любым другим элементом модели, который описывает, как эти требования могут быть реализованы в рамках ИТ-решения (см. рис. 26).

Рисунок 26. Всеобъемлющее графическое представление элементов модели
Рисунок 26. Всеобъемлющее графическое представление элементов модели

Теперь модель требований Боба приобрела завершенный вид. Использование этой модели предоставляет ему отличные возможности для ответа следующие вопросы, когда они неизбежно возникнут впоследствии:

  • Достижение каких целевых показателей обеспечивает этот сервис?
  • Какие стратегии реализует этот бизнес-процесс?
  • Насколько хорошо этот процесс удовлетворяет своим целям?
  • Если процесс будет изменен, какое влияние это окажет на цели, для достижения которых он предназначен?
  • Насколько изменения этого процесса будут совместимы с бизнес-политикой и с бизнес-правилами?
  • Какие цели не имеют целевых показателей, определяемых количественно?
  • Какие цели не поддерживаются никакой стратегией?
  • Какие сервисы реализуют эту тактику?
  • Какие целевые показатели, стратегии, тактики, бизнес-процессы и сервисы будут затронуты в случае изменения этой цели?
  • В чем заключается ценность этого сервиса для бизнеса?
  • Почему мы предприняли эту реализацию? Для чего она нужна?

Возможность отслеживания связей между требованиями и реализующими их средствами предоставляет информацию, необходимую для ответа на эти и на другие не менее важные бизнес-вопросы.

Сводка преимуществ

Типовые профили UML и шаблоны RequisitePro используют механизмы расширяемости инструмента Rational, что позволяет моделировать бизнес-требования в соответствии со стандартом OMG BMM (Business Motivation Model). Этот подход обеспечивает эффективный способ фиксации, валидации и анализа требований, а также управления их изменениями. Использование этих инструментов и методов позволит вам получить исчерпывающие ответы на вопросы «кто?», «что?», «почему?» и «как?» применительно к своим бизнес-требованиям.


Загрузка

ОписаниеИмяРазмер
BMM-профиль (Business Motivation Model Profile)BusinessMotivationModelProfile.zip1274Кб

Ресурсы

Научиться

  • Оригинал статьи "Capturing requirements with Business Motivation Model, IBM Rational RequisitePro, and IBM Rational Software Modeler" (EN).
  • В каталоге OMG приводятся актуальные версии спецификаций OMG Business Rules and Process Management Specifications, которые входят в число стандартов OMG, разработанных рабочей группой по моделированию интеграции бизнеса BMI-TF (Business Modeling and Integration Task Force).
  • Посетите раздел Rational на ресурсе developerWorks и ознакомьтесь с техническими материалами и рекомендованными методиками для продуктов Rational Software Delivery Platform.
  • Ознакомьтесь с каталогом курсов по продуктам Rational (которые предусматривают самостоятельное компьютеризированное обучение, самостоятельное обучение в онлайновом режиме и обучение под руководством инструктора в онлайновом режиме). Эти курсы, различающиеся по сложности от начального до высшего уровня, позволят вам усовершенствовать свои навыки и углубить свои знания об инструментах Rational. Курсы, представленные в этом каталоге, можно приобрести в варианте для самостоятельного компьютеризированного обучения и в варианте для обучения в Интернет-режиме. Кроме того, некоторые курсы серии Getting Started (Первое знакомство) предоставляются бесплатно.
  • Подпишитесь на информационный бюллетень Rational Edge, содержащий статьи по концепциям эффективной разработки программного обеспечения.
  • Подпишитесь на информационный бюллетень IBM developerWorks – еженедельный обзор по лучшим материалам на ресурсе developerWorks (учебным пособиям, статьям, материалам для загрузки, мероприятиям сообщества, Web-трансляциям и событиям).
  • Дополнительная техническая литература по этой и другим техническим темам.

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=473932
ArticleTitle=Фиксация требований с помощью инструментов Business Motivation Model, IBM Rational RequisitePro и IBM Rational Software Modeler
publish-date=03112010