Глава 12 «Документация» содержит более детальное описание документов, которые, возможно, будет необходимо создать.

Какие Требования и Документы Будут Использоваться как Контракт с Заказчиком?

Обычно в качестве контракта используются Сценарии Использования (Use Cases) и Дополнительная Спецификация (Supplementary Specification), но мы также можем включить в контракт документ Концепции (Vision). Не имеет смысла утверждать у заказчика запросы заинтересованных лиц (Stakeholder Requests), т.к. эти требования обычно написаны на языке пользователей. В этом случае мы берем на себя ответственность, если вдруг требование будет интерпретировано неверно в процессе преобразования требований STRQ в FEAT, UC или SUPL.

Если Часть Проекта Разрабатывается Сторонними Исполнителями, Какие Требования и Документы Будут Использоваться как Контракт со Сторонними Разработчиками?

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

Нужно Следовать RUP или Какой-либо Другой Методологии?

Rational Unified Process (RUP) - это итеративный процесс разработки программного обеспечения, который становится все более и более популярным.

Некоторые преимущества использования RUP:

• Итеративный подход позволяет определять все риски на ранних стадиях.

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

• Интеграция с IBM RequisitePro и другими инструментами Rational.

RUP может успешно применяться как в краткосрочном проекте, так и в сложном многолетнем проекте [KRO03]. RUP можно приспособить под требования конкретного проекта. Представленный в данной книге подход к управлению требованиями синхронизирован с RUP. Однако он также может применяться в проектах, где RUP не используется.

Нужны Заказчику Особые Документы для Осуществления Разработки?

Некоторые компании создают свой внутренний Жизненный Цикл Разработки Программного Обеспечения (Software Development Lifecycle). Они могут требовать некоторые документы, специфичные для их организации. Возможно, нам потребуется включить эти документы в процесс.

Как Будет Осуществляться Управление Изменениями?

Могут быть использованы автоматические средства. Имеет смысл использовать ClearQuest, т.к. он является частью Rational Suite и предоставляет некоторую интеграцию с RequisitePro. Нам также необходимо детализировать процесс. Есть ли у нас центральное лицо, через которого мы будут назначаться запросы на изменения, или же есть группа авторизованных тестеров, бизнес-аналитиков и пользователей, кто может назначить запрос на изменение непосредственно в самой системе?

Будет ли Вся Система Храниться в Одном Проекте RequisitePro, или Будет Разделена на Несколько Проектов?

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

Какой Процесс Будет Гарантировать, Что Все Требования Будут Выполнены и Протестированы?

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

Какие Требования или Представления Необходимы для Генерации Отчетов?

Это зависит от специфики проекта. Однако, обычно необходимы следующие представления:

• Attribute Matrix: Stakeholder Requests (Матрица Атрибутов: Запросы Заинтересованных Лиц).

• Attribute Matrix: Features (Матрица Атрибутов: Функциональные Особенности).

• Attribute Matrix: Supplementary Requirements (Матрица Атрибутов: Дополнительные Требования).

• Attribute Matrix: Test Cases (Матрица Атрибутов: Тестовые Сценарии).

• Traceability Matrix: Stakeholder Requests to Features (Матрица Трассировки: из Запросов Заинтересованных Лиц в Функциональные Особенности).

• Traceability Matrix: Features to Use Cases (Матрица Трассировки: из Функциональных Особенностей в Сценарии Использования).

• Traceability Matrix: Features to Supplementary Requirements (Матрица Трассировки: из Функциональных Особенностей в Дополнительные Требования).

• Traceability Matrix: Supplementary Requirements to Test Cases (Матрица Трассировки: из Дополнительных Требований в Сценарии Использования).

• Traceability Matrix: Use Cases to Scenario and Test Cases (Матрица Трассировки: из Сценариев Использования в Алгоритмы (Сценарии) и Тестовые Сценарии).

3.3 Пример Плана Управления Требованиями

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