Важнейшим моментом в процессе проектирования является управление требованиями.

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

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

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

Отслеживаемость требования -документирование всего жизненного цикла требования.

3

Обычно под заинтересованным лицом (stakeholder) понимают личность, на которую оказывает влияние разрабатываемая система.

Два главных типа заинтересованных лиц – это пользователи и

заказчики.

Пользователи – это лица, которые будут пользоваться системой. Заказчики – лица, кто заказывает систему и отвечает в дальнейшем за

приемку системы.

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

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

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

4

Принято называть заинтересованным лицом любого, кто имеет отношение к системе (как в процессе разработки, так и после его завершения), а также любого, у кого могут быть какие-либо требования к системе.

В качестве заинтересованного лица можно рассматривать:Любого, участвующего в разработке системы (бизнес-аналитики,

дизайнеры, кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению, дизайнеры сценариев использования, графические дизайнеры).

Любого, кто привносит свои знания в систему (эксперты предметной области, авторы документов, которые были использованы для сбора требований, собственники веб-сайтов, ссылки на которые были предоставлены).

Руководство (президент компании, которого представляют заказчики, директор отдела информационных технологий компании, проектирующей и разрабатывающей систему).

Лица, вовлеченные в управление, настройку и сопровождение системы (например, хостинговая компания, справочная служба).

Поставщики стандартов и регламентов.

5

Пирамида Требований

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

Функциональная особенность: предоставляемая системой функциональность, обычно формулируемая бизнес-аналитиком; назначение особенности – удовлетворить потребности заказчика.Сценарий Использования (Use Case): описание поведения системы в терминах последовательности действий.

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

Тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов.

Сценарий (Алгоритм, Scenario): особая последовательность действий; определенный путь по сценариям использования.

6

Какой будет степень детализации требований на каждом уровне, зависит от

бизнес-аналитиков.

Главное отличие между потребностями и функциональными особенностями

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

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

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

8

Трассировка – это способ представления отношений между требованиями различного уровня в системе. Она помогает определить источник любого требования.

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

Функциональные особенности соответствуют сценариям использования в отношении «многие-ко-многим». Функциональные особенности также соответствуют дополнительным требованиям в отношении «многие-ко- многим».

Каждый сценарий использования соответствует одному или более сценарию (алгоритму), таким образом, их тип отношений – «один-ко- многим». Сценарии (алгоритмы) соответствуют тестовым сценариям в отношении «один-ко-многим».

9

Трассировка играет несколько важных ролей:

Подтверждение, что реализация удовлетворяет всем требованиям: Все, что требовал заказчик, было реализовано.

Подтверждение, что приложение делает только то, что было заказано: Не реализовывать то, что заказчик никогда не просил.

Анализ воздействия: Какие элементы будут затронуты при добавлении новых требований или изменении текущих?

Помощь в управлении изменениями: Когда некоторые требования изменяются, мы хотим знать, какие тестовые сценарии должны быть изменены, чтобы протестировать данное изменение.

Элемент трассировки – это элемент проекта, который должен быть получен (трассирован) из другого элемента. В терминах RequisitePro под ним понимается все, что принадлежит какому-либо типу требований.

Примеры типов требований в RequisitePro: потребности

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

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

10

Требование должно удовлетворять нескольким критериям для того, чтобы считаться «хорошим требованием» оно должно иметь следующие характеристики:

Помимо этих критериев для отдельных требованийреализациидля набора требований

(абстрактность)

применяются три критерия. Требования должны быть:Постоянными.

Немногословными.Завершенными.

11