Создание требований в RequisitePro из модели прецедентов Rose

Д. Лесин

Цель

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

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

Интегрированное использование Rose и RequisitePro позволяет решить 2 очень важные задачи:

облегчить процесс создания начального списка функциональных требований из модели прецедентов;
облегчить процесс синхронизации функциональных требований с прецедентами модели прецедентов.

Создание начального списка функциональных требований из модели прецедентов разбивается на следующие подзадачи:

создание необходимых групп (типов) требований и типов документов в проекте RequisitePro;
интеграция модели Rose и проекта RequisitePro;
экспорт прецедентов из модели Rose в группу "Прецеденты" проекта RequisitePro;
создание требований в группе "Функциональные требования" проекта RequisitePro на основании сценариев прецедентов;
создание трассировочной матрицы для синхронизации требований в группе "Прецеденты" и "Функциональные требования".

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

При составлении данного документа был использован Rational Suite AnalystStudio 2002. Общие принципы работы с Rational RequisitePro изложены в "Основы использования Rational RequisitePro".

Создание необходимых типов требований и типов документов

Прежде всего в проекте RequisitePro необходимо создать тип требований, который будет объединять прецеденты, экспортированные из модели прецедентов Rose. Преимущества дополнительного хранения этих прецедентов в виде требований RequisitePro:

возможность создания дополнительных метрик для прецедентов (например, дата ожидаемой реализации, приоритет, исполнитель и т.д.);
возможность сортировки и фильтрации прецедентов по названиям или атрибутам;
возможность связывания прецедентов с требованиями различных типов (с требованиями планирования, тестирования, нефункциональными и т.д.);
сохранение истории изменений прецедентов;
ведение дискуссий по отдельным прецедентам или по их группам.

Для создания указанного типа требований на дереве узлов открытого проекта RequisitePro необходимо активизировать самый верхний узел и в его контекстном меню выбрать пункт "Properties" (рис. 1).

Рис. 1

В открывшемся окне "Project Properties" следует активизировать страницу "Requirement Types". Она позволяет добавить в проект новые типы требований. После добавления типов требований "Прецеденты" и "Функциональные требования" окно "Project Properties" примет вид согласно рис. 2.

Рис. 2

На страничке "Attributes" окна "Project Properties" следует определить необходимые атрибуты для сформированных типов требований. Хотя, конечно же, можно использовать и те атрибуты, которые создаются по умолчанию для новых типов требований.

В нашем случае для каждого созданного типа требований удаляем существующие атрибуты и создаем следующие:

"Приоритет" (список значений; возможные значения: "Высочайший", "Высокий", "Средний", "Низкий") - приоритет реализации функционального требования или прецедента;
"Состояние" (список значений; возможные значения: "Предложено", "Одобрено", "Реализовано", "Протестировано") - состояние, в котором на данный момент находится процесс реализации функционального требования или прецедента;
"Трудность" (список значений; возможные значения: "Высокая", "Средняя", "Низкая") - оценочная сложность реализации функционального требования или прецедента;
"Ответственный" (строка) - указывается фамилия ответственного за реализацию функционального требования или прецедента.

Совместное использование Rose и RequisitePro позволяет связывать документы проекта RequisitePro с любыми прецедентами модели Rose. Процесс интеграции модели Rose с проектом RequisitePro требует предварительного создания хотя бы одного типа документа, который будет связан с требованиями типа "Прецеденты". Сформируем некоторый обобщенный тип документов "Общие документы" (рис. 3).

Рис. 3

Интеграция модели Rose и проекта RequisitePro

Для использования Rose совместно с RequisitePro необходимо, чтобы в первом был активизирован соответствующий "Add-In". Для этого необходимо выбрать пункт меню "Add-Ins/Add-In Manager...". Это приводит к появлению окна "Add-In Manager". Здесь следует проконтролировать, чтобы был активен пункт "RequisitePro" (рис. 4).

Рис. 4

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

Теперь следует связать текущий файл модели Rose с проектом RequisitePro. Для этого требуется выбрать пункт меню "Tools/Rational RequisitePro/Associate Model To Project". В открывшемся окне "Associate Model To RequisitePro Project" следует указать проект RequisitePro, в который будут экспортированы прецеденты (Рис. 5). Кроме того, необходимо указать тип требований и тип документов по умолчанию, с которыми автоматически будут связаны экспортированные прецеденты. В дальнейшем указанные типы могут быть заменены на любые другие с помощью этого же окна.

Рис. 5

Нажатие кнопки <OK> приведет к интеграции модели Rose и проекта RequisitePro.

Экспорт прецедентов из Rose в RequisitePro

Рассмотрим экспорт прецедента на простейшем примере. Пусть имеется некоторая модель прецедентов (рис. 6).

Рис. 6

Для экспорта прецедентов следует для каждого из них выбрать пункт контекстного меню "Requirement Properties/New...". При этом появляется форма добавления требований "Requirement Properties..." из RequisitePro (рис. 7).

Рис. 7

Данная форма позволяет установить значения дополнительных атрибутов прецедентов (страничка "Attributes"), создать связи с существующими требованиями любых типов ("Traceability") и сформировать иерархию прецедентов ("Hierarchy"). Нажатие <OK> приведет к физическому созданию требования типа "Прецеденты" в базе RequisitePro.

Таким образом экспортируем все прецеденты в проект RequisitePro. Созданные требования в RequisitePro следует перенести в папку, предназначенную для их хранения. После этого требуется создать матрицу атрибутов (Attribute Matrix) для работы с ними (рис. 8).

Рис. 8

Создание функциональных требований

Функциональные требования создаются аналитиком на основе анализа сценариев прецедентов в модели Rose. Как и прежде, рассмотрим этот процесс на кратком примере. Пусть упрощенный сценарий прецедента "Заказать товар" выглядит следующим образом:

1. Резюме

Прецедент позволяет осуществить предварительный заказ товара на официальном сайте компании. Это гарантирует покупателю получение товара в тот момент, когда он сможет посетить магазин компании и оплатить стоимость товара.

2. Цель

Выполнить заказ необходимого товара на официальном сайте компании.

3. Главный сценарий
3.1. Предусловия:

покупатель должен быть авторизован в системе (ему следует зарегистрироваться на сайте, указав свои логин и пароль).

3.2. Триггер:

покупатель активизирует элемент интерфейса "Заказать товар" на официальном сайте компании.

3.3. Постусловия:

покупатель выбрал товар и указал требуемое количество этого товара;
выбранный товар добавлен в корзину покупателя в указанном количестве.

3.4. Действия:

система отображает список категорий товаров;
покупатель выбирает необходимую категорию товаров;
система отображает список товаров выбранной категории;
покупатель выделяет необходимые товары в данной категории;
покупатель указывает необходимое количество каждого из выбранных товаров;
покупатель активизирует элемент интерфейса "Положить в корзину" для добавления выбранных товаров в свою личную корзину;
система добавляет выбранные товары в корзину покупателя;
система отображает общую сумму товаров в корзине."

Этот сценарий является максимально упрощенным. В нем рассматриваются только действия главного сценария, а альтернативные пути исключаются из рассмотрения.

Для добавления функциональных требований создадим матрицу атрибутов (Attribute Matrix) "Функциональные требования". После внимательной проработки указанного сценария прецедента сформируем список функциональных требований, используя эту матрицу (рис. 9). При выявлении функциональных требований следует особенно акцентироваться на разделах "Предусловия" и "Постусловия" главного сценария [3].

Рис. 9

На приведенном выше рисунке показан внешний вид проекта RequisitePro после создания необходимых требований и матриц атрибутов. Для удобства работы требования и матрицы атрибутов находятся в своих папках.

Нами определены следующие требования для прецедента "Реализовать прецедент 'Заказать товар'":

Выполнять авторизацию в системе перед процедурой заказа товара.
Запускать процедуру заказа товара с помощью элемента интерфейса "Заказать товар" на официальном сайте компании.
Реализовать процедуру выбора категории товара.
Реализовать процедуру выбора товаров в указанной категории и их количества.
Добавлять выбранные покупателем товары в корзину покупателя.

Создание трассировочной матрицы и отслеживание изменений в модели прецедентов

Далее следует позаботиться об удобстве отслеживания изменений в функциональных требованиях после возникновения изменений в модели прецедентов. Для этого в папке "Трассировочные матрицы" создадим трассировочную матрицу (Traceability Matrix) "Функциональные-прецеденты". С помощью нее будет легко определить, какие функциональные требования необходимо просмотреть на предмет возможных изменений, если изменились любые прецеденты модели прецедентов (рис. 10).

Рис. 10

Теперь изменим в модели Rose прецедент "Продать товар" на "Доставить товар", что предполагает реализацию в рамках одного прецедента функциональности продажи товара и его доставки покупателю. Для синхронизации с прецедентом в RequisitePro выберем в модели Rose пункт контекстного меню измененного прецедента "Requirement Properties/Open..." (рис. 11).

Рис. 11

После подтверждения открывшегося диалога "Requirement Properties: USC1 Доставить товар" в проекте RequisitePro одно из требований группы "Прецеденты" будет также изменено (рис. 12).

Рис. 12

Перечеркнутый значок трассировки показывает, что нам необходимо внимательно просмотреть требование "Реализовать прецедент 'Продать товар'" и все его дочерние требования. Очевидно, что после изменения названия прецедента, как минимум, требуется изменить формулировку родительского требования. Т.е требование "Реализовать прецедент 'Продать товар'" должно быть сформулировано как "Реализовать прецедент 'Доставить товар'".

Кроме того, изменение сценария прецедента может привести к изменению дочерних требований для "Реализовать прецедент 'Доставить товар'". Для этого необходимо снова проанализировать сценарий прецедента и согласовать с ним список функциональных требований.

После внесения изменений в функциональные требования требуется вручную убрать значок перечеркивания с помощью выбора соответствующего пункта контекстного меню "Clear Suspect" на перечеркнутом поле (рис. 13).

Рис. 13

Заключение

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

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

Ссылки по теме