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

Иван Криковцев
Кандидат экономических наук,
имеет четырёхлетний опыт участия в портальных проектах

Опыт, приобретенный в проектах по разработке корпоративных порталов для «Северсталь­групп», «АвтоВАЗа», Группы ЧТПЗ, ГМК «Норильский никель», золотодобывающей компании «Полюс» и других предприятий, позволил автору разработать комплексный подход к подготовке, сбору, анализу и формализации требований при такой работе. С учётом практических приемов и известных методик в этой области автор предлагает свой метод сбора и документирования требований к порталам — Requirements acqUisitions and Specification.

Рынок корпоративных порталов начал формироваться в 1998 году, его локомотивами были ведущие поставщики портальных платформ — BEA Systems, Oracle, IBM, Plumtree Software и SAP. Они предлагали технологии, которые системные интеграторы должны были рассматривать в разрезе информационных потребностей бизнеса. В ходе реализации портальных проектов формировались прецеденты успешного решения задач, накапливались знания и опыт проектирования корпоративных порталов и в результате создавались специальные приемы и методики их разработки.

Подходы к проектированию порталов как корпоративных систем могут быть заимствованы из общепринятых методов и методологий (RUP, SADT, AIM, VORD, ACRE, SSADM и др.). Тем не менее в портальном проекте возникают специфические задачи по обследованию, анализу и формированию требований, решение которых заставляет искать новые практичные подходы, отличные от общепринятых и теоретических.

В данной статье описывается метод сбора и документирования требований «Requirements acqUisitions and Specification» (далее RUS), который объединяет в себе рекомендации и мировую практику проектирования корпоративных порталов. Метод является авторской точкой зрения на процесс проектирования портала, включает 25 методик и описывает порядок их применения на этапах сбора и документирования требований.

Прирамида методик

Прежде всего надо сказать, что метод RUS опирается на широко известную классификацию типов требований, приведенную в таблице. Причем все эти типы связаны между собой, как показано на рис. 1. Требования различных типов являются фундаментом для проектирования портала: если исключить какой­либо тип требований, реализованное решение может стать неполным и ожидания заказчика будут обмануты.

Рис. 1. Трансформация требований (К.Вигерс, Разработка требований к программному обеспечению /Пер. с англ.-М.: "Русская редакция", 2004.)

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

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

Рис. 2. Пирамида методик

Поиск компромисса

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

С другой стороны, если использовать полный набор потоков и методик, как показано на рис. 4, то в таких условиях существует риск затягивания разработки и получения требований, излишне формализованных. Поэтому при формировании стратегии нужно искать золотую середину и ориентироваться на конкретную ситуацию и ожидания компании. Как правило, на практике используются следующие методики: описание образа и границ проекта, ГОСТ 34.602—89, экспресс­обследование, протоколирование, диаграммы вариантов использования, логическое деление функциональной архитектуры. Но для повышения качества можно использовать и более широкий набор методик, который рекомендуется методом RUS.

Рис. 3. Качество и длительность формализации требований, собранных не в полном объеме

Рис. 4. Качество требований и длительность их формализации на базе широкого набора методик

Фазы разработки требований

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

Рис. 5. Процесс сбора и документирования требований к порталу

1. Фаза «подготовка» позволяет ознакомиться c бизнесом и инфраструктурой компании для подготовки к сбору данных. Как правило, на этой фазе спонсоры проекта информируют о проекте в целом и бизнес­требованиях к порталу; здесь же выделяются заинтересованные лица.
   
2. Фаза «сбор» позволяет собрать требования к порталу от заинтересованных лиц и ключевых сотрудников компании. В ходе этого процесса выявляются ожидания пользователей, которые учитываются в дальнейшем.
   
3. Фаза «анализ» позволяет сформировать полный список ожидаемых функций портала и определить приоритеты между ними.
   
4. Фаза «формализация» позволяет трансформировать требования в текстовую или графическую форму, пригодную для подготовки технического задания на разработку портала.

Итак, с помощью предложенного метода RUS можно формализовать процесс сбора и документирования требований к порталу путём подбора необходимых потоков работ, выполнения соответствующих методик и описания требований всех типов на необходимом уровне детализации. Более подробную информацию можно найти на www.analytic­methods.com.