Рекомендация: Важные решения при адаптации требований

Выбор способа применения рабочих продуктов

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

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

Рабочий продукт	Назначение	Адаптация (Необязательный продукт, рекомендуется)
Рабочий продукт: Модель варианта использования (Рабочий продукт: Субъект, Рабочий продукт: Вариант использования, Рабочий продукт: Пакет вариантов использования)	Варианты использования применяются для определения функциональных требований.	Рекомендуется для большинства проектов. Варианты использования рекомендуются для фиксации функциональных требований.
Рабочий продукт: Раскадровка	Если некоторые поведенческие требования в проекте недостаточно ясны, можно использовать раскадровку, которая поможет получить четкое представление о сути этих требований.	Необязательный продукт Можно использовать и другие способы разъяснения требований.
Рабочий продукт: Глоссарий	Позволяет сохранять единую терминологию внутри проекта.	Рекомендуется для большинства проектов.
Рабочий продукт: Атрибуты требований	Это база данных атрибутов требований, позволяющая следить за последовательностью, уровнем выполнения и трассировкой требований.	Необязательный продукт В проектах с относительно небольшим количеством требований создавать базу данных атрибутов требований не обязательно.
Рабочий продукт: План управления требованиями	Содержит список подлежащих сбору данных и описание механизмов оценки, передачи и контроля изменений требований продукта. Нужно создать отдельный документ, если того требует заказчик или если работа с требованиями достаточно сложна.	Необязательный продукт В проектах с относительно небольшим количеством требований можно использовать простую схему управления ими, а план управления требованиями оформить как часть плана разработки программного обеспечения. В некоторых проектах проверки могут быть очень тщательными, но при этом официальное оформление выполняется только для немногих из них или совсем не выполняется. Например, список подлежащих сбору атрибутов требований может быть попутно составлен при создании конфигурации инструментов.
Рабочий продукт: Спецификация требований к программному обеспечению	Используется для составления официального документа с полным перечнем требований. Это документ передается заказчику.	Необязательный продукт В менее официальных проектах составление такого документа не обязательно.
Рабочий продукт: Запросы заинтересованных лиц	Фиксирует все полученные в ходе проекта запросы и содержит описание, каким способом они были направлены.	Рекомендуется для большинства проектов. Для того чтобы создать систему, отвечающую нуждам заинтересованных лиц, необходимо поощрять и анализировать их запросы. Во многих проектах запросы заинтересованных лиц рассматриваются как разновидность запросов изменений. В других проектах запросы заинтересованных лиц рассматриваются только неофициально.
Рабочий продукт: Дополнительные спецификации	Фиксируют нефункциональные требования.	Рекомендуется для большинства проектов.
Рабочий продукт: Видение	Фиксирует требования и ограничения проектирования самого высокого уровня, чтобы обеспечить читателя пониманием разрабатываемой системы.	Рекомендуется для большинства проектов.

Выбор отчетов

Выбор отчетов зависит от доступных инструментов составления отчетов. При наличии таких инструментов рекомендуется создавать отчеты для рабочих продуктов, основанных на моделях или базах данных, например, для вариантов использования или субъектов. Отчеты в конфигурации RUP находятся на страницах описания рабочих продуктов в навигаторе структуры для каждого рабочего продукта.

Выбор способа выполнения входных требований

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

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

Определите, будете ли вы следовать спецификации входных требований. Если выяснится, что некоторые правила неадекватны или ошибочны, будет ли возможность вернуться и отредактировать спецификацию входных требований? Выберите также способ ведения трассировки или способ установления взаимосвязи между спецификацией входных требований и Рабочим продуктом: Вариант использования.

Выберите одну или несколько из предложенных ниже стратегий:

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

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

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

Выбор способов утверждения вариантов использования

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

Выберите одну или несколько из перечисленных стратегий:

Все варианты использования проходят официальные внешние проверки с участием лиц, не входящих в группу проекта.
Некоторые второстепенные варианты использования проходят упрощенные проверки (неофициальные или внутренние официальные).

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

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

Примечание: Для решения проблемы можно вовлечь заказчика в процесс разработки требований. Представители заказчика смогут утверждать принятые решения и давать рекомендации другим заказчикам. Такая совместная работа позволяет наладить доверительные отношения при работе над проектом.

Дополнительная информация об уровнях проверки приведена в разделе Рекомендация: Уровни проверки.