2.1.2Процесс управления требованиями

Самое простое описание процесса управления требованиями содержит следующие основные пункты:

• формирование плана управления требованиями;

• сбор требований;

• разработка документа Концепции (Vision);

• создание сценариев использования (Use Cases);

• дополнительная спецификация;

• создание тестовых сценариев (Test Cases) из сценариев использования (Use Cases);

• создание тестовых сценариев (Test Cases) из дополнительной спецификации;

• проектирование системы.

Первый шаг (план управления требованиями) определяет пирамиду требований. На каждом из последующих семи шагов строится один элемент пирамиды. Таблица 1.1. описывает, какие типы требований и какая документация создаются на каждом шаге. Как Вы видите, процесс проходит через пирамиду сверху вниз и слева направо.

Таблица 1.1. Требования и документы, созданные на каждом шаге.

Шаг	Тип требований	Документы
Сбор требований	Потребности заинтересованного лица	Запросы заинтересованного лица
Разработка документа Концепции (Vision)	Функциональные особенности	Концепция
Создание сценариев использования (Use cases)	Сценарии использования, алгоритмы	Спецификация Сценариев Использования
Дополнительная спецификация	Дополнительные требования	Дополнительная спецификация
Создание тестовых сценариев (test cases) из сценариев использования (use cases)	Тестовые сценарии	Тестовые сценарии
Создание тестовых сценариев (test cases) из дополнительной спецификации	Тестовые сценарии	Тестовые сценарии
Проектирование системы	Диаграммы классов, диаграммы взаимодействий	UML-диаграммы

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

2.1.3Извлечение требований

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

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

• цели;

• знания предметной области;

• заинтересованных лиц;

• операционное окружение;

• организационную среду.

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

В качестве заинтересованного лица можно рассматривать:

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

• поставщиков знаний в систему (эксперты предметной области, авторы документов, которые были использованы для сбора требований, собственники веб-сайтов, ссылки на которые были предоставлены);

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

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

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

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

• недопонимание между аналитиком и заинтересованными лицами;

• упущение некоторых аспектов, изначально кажущихся второстепенными;

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

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

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

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

• создание прототипов – инструмент для постепенного перехода от «бумажных» моделей до пилотных подсистем, реализуемых как самостоятельные проекты или бета-версий продуктов, при этом прототипы могут постепенно трансформироваться в результаты проекта и использоваться для проверки и утверждения требований;

• разъясняющие встречи – мероприятия, в ходе которых заинтересованные лиц совместно с аналитиками ищут пути решения проблем, определения и предупреждения рисков и т.п.;

• наблюдение – непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов;

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