3.2 Решения, Которые Могут Быть Оформлены в Документе rmp

Глава 1 «Управление Требованиями» перечисляет решения, которые должны быть приняты при создании документа rmp. В следующих пунктах мы обсудим каждое решение и влияющие на него факторы.

Будет Использоваться Инструмент Управления Требованиями?

Использование инструмента управления требованиями (RM) значительно облегчает создание и хранение требований. Обычно инструмент предоставляет отслеживание трассировки (связи). Могут генерироваться различные отчеты. Как бы то ни было, часто требуются деньги на покупку такого инструмента, а также время на его изучение. Но обычно такие расходы стоят получаемых преимуществ.

В некоторых случаях даже не требуется дополнительных средств для приобретения инструмента. Одним из вариантов может быть использование бесплатного инструмента, например Tracer. У некоторых компаний такой инструмент может уже быть в наличии, если он был включен в пакет, купленный ранее для других целей. Например, некоторые компании покупают Rational Suite Enterprise, из-за Rational Rose (для проектирования системы) и Rational Robot (для тестирования). RequisitePro включен в этот набор, поэтому не требуется никаких дополнительных лицензий при использовании его в управлении требованиями.

Многие инструменты поддерживают процесс управления требованиями. Как можно раньше нужно решить будет ли использоваться такой инструмент, и какой именно инструмент был выбран для проекта. После принятия этого решения для первого проекта, этот же инструмент, как правило, используется и в последующих проектах. Сравнения различных инструментов для управления требованиями могут быть найдены на веб-сайте International Council on Systems Engineering (www.paper-review.com/tools/rms/read.php). Для данной книги мы выбрали RequisitePro – один из наиболее известных, мощных, удобных в использовании и приемлемых в цене инструментов для управления требованиями. Если из-за ограниченного бюджета нет возможности приобрести такое средство, для отслеживания требований могут использоваться Microsoft Word и Microsoft Excel. Отсутствие соответствующих инструментов не должно являться причиной для игнорирования надлежащего оформления требований и реализации трассировки (установления связи) между ними.

В остальной части главы полагается, что был выбран RequisitePro.

Какие Типы Требований Будут Присутствовать в Проекте?

Простые проекты могут нуждаться всего в одном или двух типах требований. Сложные программные продукты нуждаются в требованиях разного уровня. Пирамида требований, представленная на Рисунке 1.1. (и показанная на Рисунке 3.1), представляет собой типичный набор требований для большого корпоративного проекта. Однако эта пирамида может быть преобразована для конкретного отдельного проекта. Следующий список рассматривает область применения каждого типа требований:

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

• Функциональные особенности (Features): Обычно функциональные особенности являются одними из самых главных требований в проекте, но если пользователь может выразить все требования в форме сценариев использования (Use Cases - UC), то необходимость в функциональных особенностях отсутствует.

• Сценарии использования (Use Cases): Если не существует пользователей, постоянно взаимодействующих с системой, то в UC нет необходимости. Примером могут послужить некоторые пакетные программы, где пользователь только инициирует процесс.

• Дополнительные требования (Supplementary requirements): Каждый проект имеет несколько нефункциональных требований, которые должны быть отображены в Дополнительной Спецификации. Тем не менее, т.к. обычно не существует большой разницы между дополнительными и нефункциональными требованиями, мы можем хранить эти требования на уровне функциональных особенностей.

• Сценарии (Алгоритмы, Scenarios): Сценарии используются для определения верных путей сценариев использования (UC). Это очень нужный тип требований. Алгоритмы содействуют переходу между UC и тестовыми сценариями (test cases). В процессе проектирования мы создаем диаграммы последовательностей из алгоритмов, а не из целых UC. Они также очень важны для менеджера проектов, т.к. мы реализуем UC по алгоритму. Обычно мы выполняем не целый UC на конкретной итерации, а набор алгоритмов из нескольких UC, по деталям реализуя полные UC в конце стадии Construction (Построения). Чаще всего мы начинаем со сценария, состоящего из основного потока (basic flow), а далее добавляем сценарии с альтернативными потоками. Т.к. сами сценарии в RequisitePro не определены как стандартный тип требований, мы должны создать их сами. К сожалению, достаточно часто в целях экономии времени они так и не создаются явно в RequisitePro.

• Тестовые сценарии (Test cases): Считается хорошей практикой использование тестовых сценариев. К сожалению, это не делается для многих проектов. Самый простой подход к тестированию – это использование UC, а также использование «ad-hoc» тестирования (случайный выбор подходящих для тестирования значений). Этот подход сохраняет много времени, но он не гарантирует покрытие тестированием всей системы.

• Проблемы (Problems): Тип требований «проблемы» используется для фиксирования основных проблем, которые предполагает решить новая система, с существующими решениями этих проблем. Эти требования находятся наверху пирамиды, одним уровнем выше потребностей. Наш образец проекта не использует этот тип требований.

Наш образец проекта содержит типы требований, показанные на Рисунке 3.1.

Каковы Атрибуты Этих Требований?

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

Рисунок 3.1. Пирамида требований.

Начальные требования поступают в RequisitePro с уже предустановленным по умолчанию набором атрибутов. Этот набор может меняться в зависимости от того, какую версию инструмента Вы используете. Таблица 3.1. представляет включенные в шаблон Use Cases (Сценариев Использования) версии 2003.6.13 атрибуты и значения для следующих типов требований:

• Features (FEAT) – Функциональные особенности.

• Supplementary requirements (SUPL) - Дополнительные требования.

• Use cases (UC) - Сценарии использования.

• Stakeholder requests (STRQ) - Запросы заинтересованных лиц.

Таблица 3.1. Атрибуты и Их Значения, Установленные по Умолчанию для Требований: FEAT, SUPL, UC и STRQ.

Атрибут	Значения	FEAT	SUPL	UC	STRQ
Priority (Приоритет)	High (Высокий) Medium (Средний) Low (Низкий)	√	√	√
Type (Тип)	Functional (Функциональное) Usability (Удобство использования) Reliability (Надежность) Supportability (Возможность сопровождения) Design Constraint (Ограничение на Дизайн) Implementation Requirement (Требование Реализации) Physical Requirement (Требование к Аппаратному Обеспечению) Interface Requirement (Требование Интерфейса)	√
Status (Статус)	Proposed (Планируемый) Approved (Подтвержденный) Incorporated (Включенный) Validated (Проверенный)	√	√	√
Difficulty (Сложность)	High (Высокий) Medium (Средний) Low (Низкий)	√	√	√
Stability (Устойчивость)	High (Высокий) Medium (Средний) Low (Низкий)	√	√	√
Risk (Риск)	Schedule – High (График - Высокий ) Schedule – Medium (График - Средний) Schedule – Low (График - Низкий) Technology – High (Технологии - Высокий) Technology – Medium (Технологии - Средний) Technology – Low (Технологии - Низкий)	√	√	√
Planned Iteration (Планируемые Итерации)	Integer (Целое)	√		√
Actual Iteration (Фактические Итерации)	Integer (Целое)	√		√
Origin (Источник)	Help Desk (Справочная Служба) Partners (Партнеры) Competition (Конкуренция) Large Customers (Важные Заказчики) End Users (Конечные Пользователи)	√			√
Contact Name (Имя Контакта)	Text (Текст)	√	√	√
Enhancement Request (Запрос на Обновление)		√	√	√
Defect (Ошибки)		√	√	√
Obsolete (Недействительность)	True (Истина) False (Ложь)	√	√	√
Affects Architecture (Влияние на Архитектуру)	True (Истина) False (Ложь)			√
Stakeholder Priority (Приоритет Заинтересованного Лица)	High (Высокий) Medium (Средний) Low (Низкий)				√

Как Вы видите, требования FEAT, SUPL и UC имеют много общих атрибутов. У STRQ по умолчанию существует только два атрибута - Origin (Источник) и Stakeholder Priority (Приоритет Заинтересованного Лица).

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

Т.к. некоторые значения атрибутов довольно неточные, будет полезным указать в документе RMP, какие точно значения имеются в виду. Вот несколько примеров:

• Priority - High (Приоритет - Высокий): Может быть реализовано не позже, чем в первой итерации фазы Construction (Построение).

• Priority - Medium (Приоритет - Средний): Может быть реализовано не позже, чем в конце фазы Construction (Построения).

• Priority - Low (Приоритет - Низкий): Может быть реализовано, если позволяет время.

• Risk Technology – High (Риск Технологии - Высокий): Использование новой технологии, опыта работы с которой команда не имеет.

• Risk Technology – Low (Риск Технологии - Низкий): использование хорошо известной технологии, опыт работы с которой у команды очень большой.

Где Будут Создаваться Требования - в Базе Данных или в Документах?

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

• Легкий доступ к требованиям для членов команды, не имеющим доступа к RequisitePro.

• Возможность визуально группировать и структурировать требования.

• Представление требований в более читабельной форме.

• Простота добавления комментариев и пояснений.

Альтернативой управлению требований в документах является использование отчетов. Например, шаблоны Use Case Specification SoDA (Спецификации Сценариев Использования) могут быть созданы так, что когда нужно объединить сценарии использования, может быть сгенерирован отчет. Этот отчет будет иметь такую же структуру, что и шаблон Use Case Specification RequisitePro.

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

• Из-за своей наглядной природы, сценарии использования должны быть связаны с документами – один документ на отдельный сценарий использования (Use Case Specification - Спецификация Сценариев Использования).

• Функциональные особенности включены в документ Концепции (Vision).

• Дополнительные требования фиксируются в Дополнительной Спецификации (Supplementary Specification).

Требования типа «потребности заинтересованных лиц» обычно включаются в документы Запросов Заинтересованных Лиц (Stakeholder Requests). Но помимо этого, существует еще три основных подхода к оформлению потребностей. Требования данного типа могут храниться:

• В документах Запросов Заинтересованных Лиц

За: 1. Все потребности связаны с определенным заинтересованным лицом.

2. Существует место для дополнительных комментариев и для всех ответов заинтересованных лиц.

3. Не составляет труда дать весь документ заинтересованному лицу для рассмотрения.

Против: Увеличивается количество документов, которые требуют постоянного обновления.

• Только в базе данных

За: Уменьшается количество документов.

Против: Наименее читабельная форма, особенно если мы хотим выслушать мнение заинтересованного лица.

• В документе Концепции

За: Уменьшается количество документов.

Против: Концепция становится документом, который содержит требования как из области проблем (STRQ), так и из области решений (FEAT).

Между Какими Требованиями Должна Осуществляться Трассировка?

В зависимости от выбранного типы требований дерево трассировки (Traceability Tree – дерево связей) может выглядеть по-разному. Рисунок 3.2. показывает трассировку для типов требований, выбранных для нашего образца проекта.

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

Какие документы необходимы?

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

В большинстве проектов чаще всего используются следующие документы: Концепция (Vision), Сценарии Использования (Use Cases) и Дополнительная Спецификация (Supplementary Specification). Главной причиной является то, что эти документы содержат важные типы требований - FEAT, UC и SUPL. Эти документы могут также использоваться в качестве контракта между группой разработчиков и заказчиками.

Документ Запросов Заинтересованного Лица (Stakeholder Requests) используется в 50% проектов случаев. Справочник (Glossary) имеется практически во всех шаблонах проектов. Несмотря на этого, во многих проектах он не разрабатывается. План Управления Требованиями (RMP) – очень нужный документ, но он не подвергается сильным изменениям от проекта к проекту. Вы можете создать общий RMP для всех проектов организации и просто вносить некоторые мелкие изменения и исключения, специфичные для конкретного проекта.