Первое знакомство с CaliberRM Client.

Первое знакомство с CaliberRM Client.

После авторизации на экране появится основное окно CaliberRM Client, вид которого приведен на рисунке ниже.
Окно можно условно разделить на три части: Панель инструментов и меню (сверху), дерево требований (слева), окно с детальной информацией, зависящей от выбранного узла в дереве требований.
Рассмотрим более подробно дерево требований. Корневой элемент дерева соответствует активному проекту. Проект можно выбрать из выпадающего списка Project. Вложенные узлы первого уровня соответствуют типам требований. Внутри каждого вида требований располагаются ветки требований. В соответствии с выбранным узлом дерева меняется содержимое окна детальной информации. Для узла проекта окно детальной информации содержит две закладки: Project Info и Discussion. Закладка Project Info позволяет настроить проверку безопасности и возможность использования требований в других проектах.
Настройки безопасности представлены группой переключателей Security. Можно либо включить проверку безопасности (флажок Enforce), либо отключить (флажок Disabled). Настройка политик безопасности осуществляется в Framework administrator. На первом этапе, когда идет активная работа над требованиями и роли в проекте еще жестко не закреплены, рекомендуется отключить проверку безопасности, чтобы не создавать себе лишних проблем с настройкой. Включать проверку безопасности имеет смысл, после того как требования будут стабилизированы и роли в команде детально распределены.
Вторая группа флажков Share Requirements предназначена для настройки доступности требований вне рамок проекта. Рассмотрение совместного использования требований выходит за рамки статьи, поэтому мы не будем заострять наше внимание на данной группе настроек.
Вторая закладка Discussion позволяет организовать обсуждение проекта участниками проекта. Закладку Discussion имеют практически все узлы дерева. Внешний вид интерфейса организации дискуссий напоминает обычную доску сообщений и приведен на рисунке ниже.
Кнопка Post New позволяет создать новую тему обсуждения, кнопка Reply написать ответ на выбранное сообщение, а кнопка Refresh обновить список сообщений.
Формирование бизнес требований.
Узел дерева требований Business Requirements(WHY) предназначен для хранения бизнес требований. Если выбрать этот узел (как впрочем, и любой другой узел типов требований) окно детальной информации будет иметь вид представленный на рисунке ниже.
Поле ввода Requirement Type Name содержит имя типа требований. Поле Tag - краткое описание назначения типа. На закладке Description хранится краткое описание типа требований, закладка Custom Tabs содержит перечисление специфичных для данного вида требований закладок атрибутов. На закладке Summary можно делать пометки о ходе работы над данным видом требования. Отметим, что можно создавать собственные типы требований с помощью Framework Administrator.
Создать новое бизнес требование можно либо с помощью пункта меню Requirement | Create Requirement | Child, либо щелчком правой кнопкой мыши на узле Business Requirements из контекстного меню New| Child. При этом в узле бизнес требований создается дочерний узел требования. Ниже приведен внешний вид окна детальной информации для бизнес требования.
Большинство закладок являются общими для всех видов требований. К специфическим для бизнес требований является лишь закладка User Attributes.
Закладка Details содержит общую информацию о требовании:.
• Requirement Name. Имя требования. Имя отображается в узле дерева.
• Requirement Tag|Id. Идентификатор требования. Уникальный идентификатор, состоящий из имени тэга требования и его порядкового номера. Позволяет однозначно идентифицировать требование.
• Requirement Version. Версия требования. История изменений требования может быть отслежена с помощью версий. Формирование новой версии происходит автоматически при внесении изменений в требование.
• Status. Статус требования. В стандартной конфигурации требование может иметь следующие статусы:.
o Submitted -предложено к рассмотрению (статус по умолчанию) o Pending - ожидает рассмотрения o Accepted - принято.
o Draft - версия требования является черновой o Deferred - отложено.
o Review Complete - просмотр данного требования завершен.
• Priority. Приоритетность реализации требования. В стандартной конфигурации приоритетность может иметь следующие значения:.
o Unassigned - не присвоена (уровень по умолчанию) o Essential - обязательно реализовать o Useful - полезно реализовать o Desirable - реализовать по возможности.
• Owner. Владелец/создатель требования. Пользователь, владеющий требований.
Закладка Responsibilities содержит список пользователей и групп, отвечающих за разработку и реализацию данного требования.
Закладка References позволяет привязать к требованию внешние файлы, текстовые документы, Web документы.
Discussion - закладка дискуссий по требованию. Была описана в предыдущем разделе.
History - история создания версий требования.
Validation. Процедура проверки требования. На данной закладке можно описать общую процедуру тестирования и проверки правильности требования. В дальнейшем команда тестирования на основе данной информации создаст более детализированные процедуры тестирования.
Traceability - отслеживаемость. Данная закладка позволяет установить и настроить связи требования с другими требованиями. Информация о связях требований используется при анализе изменений.
Специфической закладкой для данного вида требований является закладка Custom Attributes, которая содержит следующие элементы управления:.
Owner Priority - приоритет, установленный владельцем требования Sponsor Name - имя организации или лица, финансирующего работу по данному требованию.
Source - источник требования. Описания источника возникновения требования.
Funded - выделены ли финансовые ресурсы для реализации требования в отдельную строку бюджета.
Notes - заметки и дополнительные сведения.
Due Date - дата сдачи заказчику реализации требования.
После того как мы разобрались с представлением бизнес требований в CaliberRM Client самое время организовать первое интервью с заказчиком. В ходе этого интервью необходимо уяснить детали наиболее важных бизнес процессов организации и ожидания заказчика от внедрения разрабатываемой системы в плане бизнеса. В случае когда планируется создание коробочного продукта формулированием бизнес требований занимается отдел маркетинга. Эффект от внедрения необходимо представить в виде измеряемых показателей, которые легко рассчитать и проконтролировать. На основе системы этих показателей вырабатываются критерии успешности проекта. Вехой данного этапа является создания документа о видении и рамках проекта и формирование базовой линии «Инициация проекта».
В ходе общения с заказчиком были выявлены следующие бизнес требования:.
• Снижение времени выдачи книг.
• Ведение электронной картотеки посетителей.
• Создание электронного каталога книг для посетителей.
• Создание отчета о неудовлетворенном спросе на книги.
Данные требования были задокументированы. В ходе работы над бизнес требованиями было внесено предложение об использовании штрих кодов для идентификации экземпляров книги.
В результате анализа бизнес требований был создан документ видения и рамок проекта. Шаблон данного документа и сам документ прилагаются к статье.
Обратите внимание, что при работе с требованиями в выпадающем списке Baseline по умолчанию выбран элемент Current baseline. После сбора и анализа бизнес требований нам необходимо создать базовую линию «Инициация проекта», чтобы зафиксировать срез бизнес требований для заинтересованных лиц.
Замечание 1. Для создания и модификации статуса базовой линии Вы должны обладать правами администратора.
Замечание 2. Фиксация базовых линий обычно совпадает с окончанием очередной итерации проекта или прохождением вехи.
Создание базовой линии производится с помощью Framework Administrator. На закладке Project Baselines проекта нажмите кнопку New. Вы увидите диалог создания новой базовой линии проекта, приведенный на рисунке ниже.
В поле ввода Name необходимо ввести имя базовой линии. В поле ввода Description опционально дополнительные сведения и описание содержания базовой линии. Флажок Send Baseline Maintenance Change Notification via Email указывает на необходимость рассылки уведомлений о создании базовой линии по электронной почте. Флажок Lock Baseline позволяет заблокировать любые изменения базовой линии. На первом этапе работы с.
базовой линией флажок сброшен, в линию нельзя добавлять новые требования, но можно модифицировать существующие требования. После того, как все вопросы к требованиям в линии разрешены, линия блокируется, после чего никакие изменения уже внести нельзя.
Закладка Signatories позволяет указать участников проекта, которые утверждают готовность базовой линии. Закладка Signatore Meaning содержит список возможных резолюций ответственных лиц.
После создания базовой линии нужно ее наполнить требованиями, другими словами инициализировать. В подавляющем большинстве в линию включают все существующие требования. Инициализация линии происходит при первом ее выборе в CaliberRM Client.