Введение
Управление требованиями проекта как самостоятельная дисциплина развивается в рамках IT-проектов. Пока она находится на уровне корпоративной методологии. Например, в методологии RUP (Rational Unifed Process) управление требованиями является одним из этапов выполнения проектов [6]. Здесь дается следующее определение: «Управление требованиями — это систематический подход к выявлению, организации и документированию требований к системе, а также установка и поддержание соглашения между клиентом и группой разработки по поводу изменений требований к системе». Как само соглашение, так и исходные требования подлежит документальному оформлению. В настоящее время имеются программные продукты, которые поддерживают базу данных с требованиями и отслеживают сквозное их выполнение при разработке модулей. Также имеются принятые стандарты для формализации требований, например спецификация требований по стандарту IEEE 830-1998 [14]. Для управления требованиями разработаны формализованные языки, например, сценарии использования в UML 2.0 [2]. Но в стандартах по управлению проектами, таких как PMBOK, IPMA, управление требованиями не выделяется в самостоятельный раздел стандарта [9; 11]. Известны попытки ряда авторов создать методику для выявления и анализа требований [12].
Рассмотрим более подробно особенности процесса управления требованиями. В сравнении с другими этапами разработки системы установление требований в наименьшей степени касается технических сторон проекта. В действительности речь идет об успешном решении социальных, коммуникативных и управленческих вопросов. Недостаточно тщательное выполнение этого этапа может привести к более серьезным последствиям, чем в случае с другими стадиями проекта. В лучшем случае это приведет к лавинообразному росту расходов, вызванных не зафиксированными, упущенными или неверно понятыми требованиями заказчиков. В худшем случае — это вообще невозможность завершения проекта.
Специфика предметной области диктует специфику методик управления. Прежде всего это касается стратегии выполнения проекта, которая будет зависеть от того, насколько тщательно выявлены требования и предпочтения заказчика. Чаще всего необходима итерационная стратегия, связанная с последовательным выполнением одного или нескольких этапов. Причем сам руководитель проекта не всегда может гарантировать заранее, что все требования заказчика будут выполнены. Целью настоящей статьи является изучение специфики процесса управления требованиями для ряда предметных областей, выработка единой точки зрения на процесс управления требованиями и доказательство того, что предложенная точка зрения не противоречит существующим профессиональным стандартам.
