Введение

При работе с требованиями возможно применение различных методов их организации: от метода полного хаоса, до интеграции требований с программным кодом (статья Пять уровней зрелости требований). Постепенно улучшая работу с требованиями, обычно, в процесс начинают внедрять различные новые методологии и инструменты. Одним из классов инструментов, призванных упростить работу с требованиями, являются специально обученные «зверьки»: Системы Управления Требованиями (СУТ). Основными возможностями таких систем являются:

• Создание более простой, чем целый документ, единицы управления проектом (требование). Прочитать и подтвердить одно требование намного проще, чем согласовывать целое Техническое задание.
• Указание связей между требованиями. Такая возможность позволяет отслеживать изменения в связанных требованиях. Т.е. если что-то изменилось, то далее система может выделять все элементы, связанные с измененным, как подозреваемые на изменение.
• Выбор представления набора взаимосвязанных требований. При большом количестве требований иногда необходимо представить всю картину их взаимосвязи. Кому-то удобнее просмотреть эту информацию в виде таблицы (матрицы трассировки), кому-то в виде иерархического дерева, кому-то в виде сетевых графиков (статья Системы управления требованиями: что и зачем?).

Среди данных программ есть известные «Монстро-звери», такие как: IBM Rational DOORS, Borland Caliber, Polarion Requirements и др. с большим количеством функциональных возможностей. Такие системы, как правило, являются хорошо зарекомендовавшими себя, но дорогостоящими. Однако среди данного перечня есть маленькие, бесплатные, малоизвестные, но очень полезные «зверьки» типа Axiom.

Цель статьи

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

Суть проблемы

Я столкнулась с проблемой управления требованиями, когда собирала потребности к готовому программному обеспечению, которое может настраиваться под нужды клиентов. Функциональные возможности этой программы определяют набор требований к ней. Объясню на абстрактном примере. Допустим есть готовая программа, в которой пользователь может:

• Ввести текст в текстовое поле;
• Сохранить введенный текст в форматах doc, xml и pdf;
• Распечатать введенный текст.

Первый Заказчик, покупая данное ПО, заявил, что ему нужны все перечисленные функции, но форматы xml и pdf он не знает, платить за эту возможность он не хочет, поэтому сохранять введенный текст он будет только в формате doc. Исходя из этого получаем следующий набор требований для этого Заказчика:

Все возможности ПО	Требования Заказчика 1
Введение текста в текстовое поле; Сохранение введенного текста в форматах doc, xml и pdf; Печать введенного текста.	Введение текста в текстовое поле; Сохранение введенного текста в форматах doc, xml и pdf; Печать введенного текста.

Второй заказчик сказал, что ему вообще не нужна функция печати текста. У него есть свое ПО, которое отлично распечатывает документы в форматах doc, xml и pdf. Для данного Заказчика перечень требований к ПО содержит:

Все возможности ПО	Требования Заказчика 2
Введение текста в текстовое поле; Сохранение введенного текста в форматах doc, xml и pdf; Печать введенного текста.	Введение текста в текстовое поле; Сохранение введенного текста в форматах doc, xml и pdf; Печать введенного текста.

А третий Заказчик купил ПО с полным набором функциональных возможностей.

Все возможности ПО	Требования Заказчика 3
Введение текста в текстовое поле; Сохранение введенного текста в форматах doc, xml и pdf; Печать введенного текста.	Введение текста в текстовое поле; Сохранение введенного текста в форматах doc, xml и pdf; Печать введенного текста.

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

В процессе совершенствования качества программы в разы увеличилось количество функциональных возможностей. Как следствие возросло и число требований. Документы технического задания (ТЗ) стали очень громоздкими. Вникать в них как техническим специалистам, так и клиентам, стало намного труднее. Плюс ко всему стало труднее держать такое большое количество возможностей в голове. Увеличилась вероятность упустить какую-либо реализованную функцию.

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

Попробовав различные СУТ (выбирались в основном бесплатные инструменты из статьи List of Requirements Management Tools), я остановилась на инструменте Axiom компании iConcur.

Axiom

Axiom – это бесплатное кросс-платформенное клиент-серверное приложение управления требованиями.
Необходимо также отметить, что у разработчика имеется и платная версия продукта, с дополнительными возможностями, но все же Axiom позиционируется как бесплатный продукт, так как функциональных возможностей бесплатной версии вполне достаточно для упрощения работы с требованиями.

Итак, почему именно Axiom? Я выбрала данный инструмент, по следующим причинам:

• Бесплатное ПО;
• Гибкость инструмента (возможность настроить работу с инструментом в зависимости от особенностей конкретной компании или проекта);
• Простота инструмента;
• Возможность генерировать документы на основе данных, хранящихся в инструменте.

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

Первое знакомство с Axiom

После авторизации пользователя открывается главное окно инструмента.

Его можно разделить на следующие логические части:

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

Итак, что такое артефакт? Артефакт – это продукт проекта, порождаемый и/или используемый в нем при работе над программным обеспечением, например, требование, тест кейс и пр. В Axiom данный термин применяется очень активно.

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

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

Создание шаблонов артефактов

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

Что такое шаблон? Шаблон – это набор атрибутов по которому выполняется описание артефакта. Например, для работы нам нужен артефакт Функциональное требование. Функционально требование должно содержать следующие сведения:

• Название («Сохранение документа», «Добавление кнопки в интерфейс», «Передача данных»);
• Описание (например: Система должна сохранять документ при нажатии кнопки «OK»);
• Источник требования, т.е. человек, который его озвучил;
• Вопросы, возникающие при обсуждении данного требования;
• Статус требования, например, «Утверждено», «Согласовано», «Просмотрено», «Отклонено» и пр.
• Приоритет, т.е. насколько важно реализовать данное требование.
• Информация о том, будет ли данное требование реализовано в первой версии продукта.

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

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

Из описанных выше атрибутов Функционального требования логично предположить, что атрибуты «Источник» и «Вопросы» должны быть текстовыми полями, «Статус» и «Приоритет» – выпадающими списками, а информацию о вхождении требования в первую версию продукта можно реализовать флагом. На рисунке ниже представлен пример с реализованным шаблоном Функциональных требований, который назван «Требования».

На основе созданного шаблона можно будет сформировать неограниченное количество артефактов.

Создание артефакта

Создание самого артефакта происходит следующим образом:

1. В дереве артефактов, вы выбираете тот узел (группу артефактов), к которому относится данный артефакт;
2. Затем необходимо выбрать шаблон, на основании которого будет создан артефакт;
   
3. Задать имя артефакта (Name);
4. И отредактировать его атрибуты и описание.

На рисунке ниже представлен результат создания артефакта функционального требования «Ввод текста» на основе шаблона «Требования».

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

Взаимосвязи между артефактами

Для определения связей между артефактами в Axiom имеется специальный раздел «Linking Surface». В Axiom реализован стандартный шаблон взаимосвязей, на основе которого можно создавать различные типы связей, например, «Связан с», «Невозможно реализовать без», «Родительский элемент для» и пр. Взаимосвязи устанавливаются пользователем вручную в разделе «Linking Surface», путем соединением артефактов выбранным типом связи. На рисунке ниже представлена созданная взаимосвязь функциональных требований и настроек с помощью нового типа связи «Необходимо выполнить».

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

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

Интеграция с MS Word

В Axiom реализована интеграция с MS Word, что позволяет формировать документы, содержащие информацию по созданным артефактам. Данная функциональная возможность предназначена для упрощения формирования таких документов, как Техническое задание (Software Requirements Specification), Видение (Vision) и других проектных документов. Необходимая информация по артефактам уже хранится в Axiom, и пользователю не нужно повторно вводить эти сведения вручную.

После установки Axiom на компьютер в MS Word появляется специальная вкладка «Axiom», с помощью которой пользователь может сформировать шаблон документа. Для этого пользователю необходимо расставить в нужных местах документа ссылки на атрибуты выбранных артефактов. На рисунке ниже создается шаблон документа, содержащего следующие сведения об артефактах:

• Имя (Name);
• Идентификационный номер (ID);
• Описание нефункционального требования (Content).

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

Необходимо отметить, что мной была проверена интеграции Axiom только с MS Word версии 2007, 2010. 2013 версия также проверялась, но с ней интеграция не работает.

Таблица артефактов

Таблица артефактов (Artifact Table) – это специальный раздел Axiom для представления набора артефактов в удобном табличном виде.

Одной из удобных функциональных возможностей данного раздела, я считаю изменение атрибута сразу нескольких артефактов. Например, нужно изменить статус сразу у нескольких требований на «Complete».

На мой взгляд, эта возможность значительно ускоряет редактирование артефактов.

Кроме того

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

• Обсуждения. Пользователи могут обсудить артефакты и получить обратную связь с помощью специального раздела Обсуждения (Discussion);
• Администрирование пользователей. Эта возможность позволяет создавать нового пользователя и определять его логин и пароль. К сожалению, в текущей версии продукта реализовано всего 2 роли пользователей: администратор, который может все, и простой «смертный» пользователь, которому доступен лишь просмотр артефактов.
• Просмотр истории версий артефактов и атрибутов разных версий с помощью раздела История (History).
• Экспорт сформированных данных в формат xml, xls.

Для платной версии также доступны:

• Axiom Rules Language. Функциональная возможность, которую лично мне было бы интересно попробовать. В чем заключается ее суть? Компания iConcur создала свой язык описания требований для исключения неоднозначности их понимания. Кроме того, был создан редактор, который проверяет корректность написанного требования. На рисунке ниже представлен наглядный пример требования, написанного на данном языке.
• Создание прототипов интерфейса. В платной версии Axiom имеется встроенный редактор прототипов. Созданные интерфейсы так же считаются артефактами и могут быть связаны с другими артефактами.
  
• Просмотр матрицы трассировки требований с помощью специального раздела Матрица Взаимосвязей (Linking Matrix). Это раздел позволяет просматривать взаимосвязи между артефактами в табличном виде, как представлено на рисунке ниже.
  
• Просмотр иерархического дерева связей артефактов (Linking Tree).
  

Примечание: функциональные возможности платной версии инструмента описаны на основании Руководства пользователя Axiom и не были мной опробованы.

Итого

Подводя итоги, хотелось бы перечислить выявленные достоинства и недостатки данного продукта.

Плюсы

БЕСПЛАТНЫЙ. Из опробованных мною бесплатных инструментов данная система самая «приличная». Приятный сайт компании разработчика, простая установка, удобный пользовательский интерфейс. Плюс ко всему для бесплатного инструмента у программы реализовано достаточное количество функциональных возможностей, по крайней мере, для того, чтобы решить мою задачу.

Гибкость инструмента. Благодаря возможности создания самими пользователями шаблонов тех артефактов, которые используются ими при работе, данный инструмент может быть применен в различных проектах.

Простота работы. Во-первых, это интуитивно понятный интерфейс. Во-вторых, у инструмента нет мудреных настроек работы и каких-то дополнительных параметров, как, например, у MS Word раздел меню «Параметры», определяющий важные, но иногда неочевидные аспекты работы с ПО. Дополнительно, Axiom обладает набором бесплатных видео-туториалов, которые доступным образом обучают (именно обучают, а не объясняют) пользователя основным возможностям инструмента и дополнительными «фичам», которые могут значительно упростить работу с инструментом.

Кроссплатформенность. Версия 4.0 была доступна для установки только для Windows OS и Linux. В новой версии 4.1 стала доступна установка продукта на Mac OS.

Минусы

Странная компания. Впервые я встретила упоминание об этой программе на Stack Overflow, где «CEO of iConcur Software» Брент Вилсон рекламировал данный продукт. Комментарии к ответу Брента, особенно вот этот: «I tried this product recently and couldn’t even log in as the admin. I tried calling, emailing, and opening a support ticket but no response after a week. Is iConcur still alive?» меня удивили. Ну и плюс ко всему техническая поддержка работает действительно странно: иногда отвечает в тот же день, иногда неделями не отвечает, а бывает, что и вовсе молчит. В оправдание компании могу заметить, что недавно вышла новая версия ПО, так что «пациент скорее жив, чем мертв».

Ошибки ПО. Таких ошибок, которые делали бы невозможным работу с продуктом или, например, удаляли результаты часовой работы, я не обнаружила. Были баги связанные с установкой ПО, запуском клиентской части (перед этим нужно перезапустить сервер) или не отображались значки в интерфейсе… Но все же это не очень приятно. С другой стороны, многие из нас работают с MS Word…

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

P.S.

Лично мне данный инструмент действительно нравится. К сожалению, я не могу описать итоговые результаты его внедрения, так как это, по различным причинам, процесс небыстрый. В любом случае, я считаю, что Axiom может быть полезен даже для простого ознакомления с такими «зверьками» как системы управления требованиями.

Автор: teterevkova

Источник