Special issues of the requirements management process are discussed based on subject area specialties: from the most formalized (e.g., IT projects), to the least formalized areas (e.g., design projects). As is shown, the whole spectrum of apps, related to this subject, can be considered from an integrated perspective — that is, establishment of effective communication channel between Customer and Business Analyst (Designer). The features of communications related to the above-mentioned subject areas are considered as well as problems of creating such communication channels.
project management, requirements management, communications, effectiveness of communications.
Введение
Управление требованиями проекта как самостоятельная дисциплина развивается в рамках IT-проектов. Пока она находится на уровне корпоративной методологии. Например, в методологии RUP (Rational Unifed Process) управление требованиями является одним из этапов выполнения проектов [6]. Здесь дается следующее определение: «Управление требованиями — это систематический подход к выявлению, организации и документированию требований к системе, а также установка и поддержание соглашения между клиентом и группой разработки по поводу изменений требований к системе». Как само соглашение, так и исходные требования подлежит документальному оформлению. В настоящее время имеются программные продукты, которые поддерживают базу данных с требованиями и отслеживают сквозное их выполнение при разработке модулей. Также имеются принятые стандарты для формализации требований, например спецификация требований по стандарту IEEE 830-1998 [14]. Для управления требованиями разработаны формализованные языки, например, сценарии использования в UML 2.0 [2]. Но в стандартах по управлению проектами, таких как PMBOK, IPMA, управление требованиями не выделяется в самостоятельный раздел стандарта [9; 11]. Известны попытки ряда авторов создать методику для выявления и анализа требований [12].
Рассмотрим более подробно особенности процесса управления требованиями. В сравнении с другими этапами разработки системы установление требований в наименьшей степени касается технических сторон проекта. В действительности речь идет об успешном решении социальных, коммуникативных и управленческих вопросов. Недостаточно тщательное выполнение этого этапа может привести к более серьезным последствиям, чем в случае с другими стадиями проекта. В лучшем случае это приведет к лавинообразному росту расходов, вызванных не зафиксированными, упущенными или неверно понятыми требованиями заказчиков. В худшем случае — это вообще невозможность завершения проекта.
Специфика предметной области диктует специфику методик управления. Прежде всего это касается стратегии выполнения проекта, которая будет зависеть от того, насколько тщательно выявлены требования и предпочтения заказчика. Чаще всего необходима итерационная стратегия, связанная с последовательным выполнением одного или нескольких этапов. Причем сам руководитель проекта не всегда может гарантировать заранее, что все требования заказчика будут выполнены. Целью настоящей статьи является изучение специфики процесса управления требованиями для ряда предметных областей, выработка единой точки зрения на процесс управления требованиями и доказательство того, что предложенная точка зрения не противоречит существующим профессиональным стандартам.
1. Atabekova A.A. Lingvisticheskiy dizayn WEB-stranits: problemy «kommunikativnykh neudach». Materialy mezhdunarodnoy nauchno-prakticheskoy konferentsii «Kommunikatsiya: teoriya i praktika v razlichnykh sotsial'nykh kontekstakh» - «Kommunikatsiya-2002» («Communication Across Differences»). Ch. 1. Pyatigorsk: Izd-vo PGLU, 2002. S. 148-153.
2. Buch G., Rambo Dzh., Yakobson I. Yazyk UML. Rukovodstvo pol'zovatelya. 2-e izd. DMK Press, 2007.
3. Vigers K. Razrabotka trebovaniy k programmnomu obespecheniyu / Perev. s angl. M.: Russkaya redaktsiya, 2004.
4. GOST R 52807-2007 Rukovodstvo po otsenke kompetentnosti menedzherov proektov. NATsIONAL'NYY STANDART ROSSIYSKOY FEDERATsII. Data vvedeniya 2010-01-01.
5. Konetskaya V.P. Sotsiologiya kommunikatsii. M., 1997.
6. Kroll P., Krachten F. Rational Unified Process - eto legko. Rukovodstvo po RUP dlya praktikov. Kudits, 2004.
7. O´Konnor Dzh., Seymor D. Vvedenie v neyrolingvisticheskoe programmirovanie : Noveyshaya psikhologiya lichnogo masterstva / Predisl. R. Dilttsa, Dzh. Grinder; Perev. s angl. A.B. Brodskogo. Chelyabinsk: Versiya, 1997.
8. Razrabotka sayta: dizayn, upravlenie i prochie vazhnye momenty. Web-studiya Misteri-grupp. URL: http://mysterygroup.ru/articles/create_sites/2217/
9. Rukovodstvo k Svodu znaniy po upravleniyu proektami (Rukovodstvo PMBOK®). 4-e izd. M., 2010.
10. Skibkin Yu.V. Vvedenie v ergonomiku: Metodicheskie ukazaniya k izucheniyu distsipliny dlya studentov spetsial'nosti «Informatsionnye sistemy i tekhnologii» ochnoy i zaochnoy form obucheniya. Samara: SamGAPS, 2004.
11. Upravlenie Proektami. Osnovy Professional'nykh Znaniy. Natsional'nye Trebovaniya k Kompetentnosti (NTK) spetsialistov / Sertifikatsionnaya komissiyaSOVNET. M.: KUBS, 2001.
12. Khall E., Dzhekson K., Dik Dzh. Razrabotka i upravlenie trebovaniyami. Prakticheskoe rukovodstvo pol'zovatelya. 2-e izd. M.: Telelogic.
13. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide).Version 2.0 / International Institute of Business Analysis. Toronto, Ontario, Canada, 2009.
14. IEEE Recommended Practice for Software Requirements Specifications/ Software Engineering Standards Committee of the IEEE Computer Society. Approved 25 June 1998 IEEE-SA Standards Board.
15. IEEE Standard Glossary of Software Engineering Terminology / Software Engineering Standards Committee of the IEEE Computer Society. 610.12. 1990.
