CC BY-NC-ND
318
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ ПРИ РЕАЛИЗАЦИИ ИТ-ПРОЕКТОВ
Т.К. Кравченко,
доктор экономических наук, профессор, заведующий кафедрой бизнес-аналитики Национального исследовательского университета «Высшая школа экономики»
E-mail: [email protected]
Адрес: г. Москва, ул. Кирпичная, д. 33/5
f
В статье предлагается подход к моделированию процесса управления требованиями при реализации ИТ-проектов. Модель управления требованиями реализуется в три этапа. На первом этапе отбираются бизнес-требования, которые фиксируются в проектном решении и являются рамками проекта. На втором этапе строится модель, связанная с принятием, отклонением, уточнением или отнесением к дополнительным работам каждого поступающего требования пользователей. На третьем этапе для принятых требований пользователей формируются приоритеты системных требований, на основе которых далее составляются планы работ по проекту. При построении моделей принятия решений используются методы анализа
!Ч
V
иерархий и аналитических сетей Т.Л. Саати и СППР SuperDecisions.
J
Ключевые слова: управление требованиями, моделирование процесса управления требованиями, метод анализа иерархий, метод аналитических сетей, система поддержки принятия решений SuperDecisions.
1. Введение
Во многих сферах бизнеса высоки риски убытков по причине прекращения либо приостановки проектов. В рамках проекта важно соблюдать баланс между качеством выполнения, сроками работ и их стоимостью, что ставит задачу поиска компромиссного решения для соблюдения баланса между данными характеристиками.
Аналитическая работа в проектной деятельности в сфере информационных технологий (ИТ) во многом связана с процессом управления требования-
ми, поступающими от заказчика. Соответственно, для того, чтобы цели проекта были достигнуты, стратегически важно правильно построить процесс управления требованиями, включая взаимодействие между членами проектной команды, а также согласовать процедуры отслеживания выполненных работ.
Наиболее характерные подходы в этом плане демонстрирует ИТ-сфера, для которой проектная деятельность является важнейшей составляющей бизнеса. Примерами ИТ-проектов являются: разработка и развитие программного обеспечения,
БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г.
63
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
внедрение информационных систем, инфраструктурные и организационные проекты.
Для таких проектов характерна высокая интенсивность и итерационность выполнения работ с подробным составлением календарно-сетевых графиков. Выработка требований и управление требованиями — важнейшие элементы успеха любого ИТ-проекта. Более половины потерь времени организациями — разработчиками программного обеспечения связаны с неэффективностью подхода к управлению требованиями.
2. Роль бизнес-аналитика при реализации ИТ-проектов
Роль бизнес-аналитика в проекте внедрения информационной системы заключается в разработке непротиворечивой модели требований бизнеса в рамках и терминах внедряемой системы, коммуникация клиентских требований разработчикам и обратно, презентация клиентам реализованной функциональности.
Эффективное управление требованиями подразумевает как их учет на стадии поступления и отслеживание статуса выполнения, так и принятие решений о приоритетности, критичности и сроках выполнения поступающих требований.
Приведем определение процесса управления требованиями: это процесс, включающий идентификацию, выявление, документацию, анализ, отслеживание, приоритизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего жизненного цикла продукта [1].
В качестве требования рассматривается любое условие, которому должна соответствовать разрабатываемая система. Требованием может быть функциональность системы или ограничение, которому система должна удовлетворять.
В рамках IEEE Standard Glossary of Software Engineering Terminology [2] понятие требования трактуется шире:
1. условия или возможности, необходимые пользователю для решения проблем или достижения целей;
2. условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам;
3. документированное представление условий или возможностей для пп. 1 и 2.
Первичные данные, поступающие от клиентов, характеризуются противоречивостью, неполнотой, нечеткостью, изменчивостью. Требования нужны, в частности, для того, чтобы команда исполнителей могла определить и согласовать с заказчиками временные и финансовые перспективы проекта. Поэтому значительная часть требований должна быть собрана и обработана на ранних этапах определения дизайна внедряемой системы.
Однако собрать на ранних стадиях все необходимые данные удается только в исключительных случаях, так как заказчик не всегда способен оценить все нюансы и особенности предстоящей работы в новой системе. На практике процесс сбора, анализа и обработки требований зачастую нетривиален, растянут во времени на протяжении всего проекта и включает доработки функциональности, выведенной на стадию поддержки продуктивной эксплуатации.
Бизнес аналитик, занимаясь управлением требованиями, должен быть способен предоставлять их в виде, необходимом для правильного восприятия аудиторией. Следовательно, требования должны быть сформулированы на языке, понятном как пользователям, так и разработчикам. Для каждого требования необходимо контролировать его статус, сохранять историю изменений, отслеживать смежные требования и использовать уже полученные наработки для реализации новых поступающих требований.
Таким образом, необходимо фиксировать поступающие требования с указанием таких атрибутов как дата получения, автор, а также направление, к которому это требование относится. Также необходимо проверять, соответствует ли требование согласованным рамкам проекта.
Формат, в котором фиксируются требования, должен быть понятен для всех заинтересованных лиц (стейкхолдеров), которым необходимо ознакомиться со списком требований и подтвердить его. Поэтому в задачи бизнес аналитика входит документирование требований в четком, понятном и оправданно детализированном виде, чтобы обеспечить понимание и эффективную коммуникацию между членами команды [3].
Рассмотрим процесс управления требованиями на примере проекта внедрения модуля «Казначейство» системы SAP (SAP Treasury) [4].
64
БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
3. Классификация требований при внедрении модуля «Казначейство» системы SAP
Основной целью проекта внедрения модуля «Казначейство» системы SAP (полное название — «SAP Treasury and Risk Management, SAP TRM») является создание централизованной системы управления казначейством, которая заменит собственные разработки и будет интегрирована с другими системами, уже используемыми в компании. Для достижения данной цели необходима автоматизация казначейских операций.
При помощи модуля SAP TRM осуществляется управление финансовыми операциями и позициями, а также отношениями с контрагентами (бизнес-партнерами), от процессов ввода и расчета сделок до учета деривативов, операций на денежном и валютном рынках, сделок с кредитными инструментами, операций с ценными бумагами и (внутригрупповыми) займами, а также документарных операций.
В рамках проекта предусматриваются такие этапы работ, как запуск и проектирование, реализация и
заключительная подготовка, внедрение. В ходе планирования очередного этапа работ уточняются цели этапа, состав и контролируемые результаты работ.
Приведем схему классификации требований по различным признакам: по уровням (бизнес требования, требования пользователей, системные требования), по содержанию (функциональные, нефункциональные), по источникам (внутренние или внешние относительно блока функциональности) и по характеру (требования к доработке или сообщения об ошибках) (рис. 1). Данная классификация будет использоваться при построении моделей управления требованиями проекта.
4.1. Классификация по уровням требований
Рассматривая требования в разрезе этапов жизненного цикла разработки системы, можно выделить следующие уровни требований, поступающих от заказчика.
Требования верхнего уровня, — бизнес требования, — формулируются руководством компании-
УРОВНИ ТРЕБОВАНИЙ СОДЕРЖАНИЕ ТРЕБОВАНИЙ
БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г. 65
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
заказчика на стадии разработки проектного решения для выбранной системы. Такие требования включают определение укрупненных функциональных модулей, которые должны поддерживать ведение основных бизнес-процессов. Соответственно, этап анализа бизнес требований закладывает фундамент для проектирования и реализации системы.
Следующий уровень — это уровень требований пользователей. Требования пользователей отражают их пожелания к функциям и характеристикам создаваемой системы. Требования могут включать перечисления действий пользователя и откликов системы в альтернативных сценариях, а также содержать характеристики, которым должна удовлетворять система для реализации этих сценариев. Сюда входит организация удобных диалоговых средств и доработка методов расчета.
Требования, формулируемые пользователями, часто бывают недостаточно структурированными, дублирующимися, противоречивыми. Поэтому задача бизнес-аналитика состоит в том, чтобы преобразовать их в требования к функциональности системы, на основе которых будут производиться настройки стандарта и составляться технические задания для разработчиков.
Для внедрения системы важен и третий уровень — функциональный или системный, на котором осуществляется формализация требований пользователей. Каждое требование пользователя может стать основой для формулирования нескольких системных требований.
4.2. Классификация по содержанию требований
Поступающие требования могут касаться как алгоритмов работы системы, так и различных нефункциональных характеристик, которыми должна обладать система. Таким образом, по содержанию требования можно разделить на две основные категории: функциональные и нефункциональные.
Функциональные требования относятся к основным свойствам / функциям системы. Ряд требований касается поддержки работы пользователей, это требования к инструментам отслеживания действий пользователей и записи в журнал безопасности конкретных типов событий. К функциональным требованиям также относятся требования к средствам отслеживания, приобретения, установки и контроля использования лицензий
системы; средствам поддержки различных языков; инструментам создания и получения отчетов; средствам контроля доступа к определенным информационным ресурсам; средствам управления приложениями в распределенной среде; поддержки документооборота.
К нефункциональным требованиям относятся требования к удобству использования, надежности и производительности системы, возможности поддержки. К различным ограничениям относятся ограничения проектирования, реализации, разработки, написания программного кода и др.
4.3. Классификация по источникам требований
В процессе реализации различных блоков проекта, поступающие требования можно разделять на частные (полученные по доработкам, касающимся конкретного блока, и не влияющие на смежную функциональность) и общие (требования, которые касаются обработки нескольких блоков функциональности системы). При выполнении общих требований необходимо учитывать, насколько они совместимы с частными требованиями каждого из отдельных функциональных блоков, для которых реализуется общее требование.
Подобное разделение можно также описать с точки зрения источника получения требования. Для отдельно взятого функционального блока требования могут быть внутренними (они же частные), полученными от пользователей в процессе разбора вопросов касающихся данного блока. Также требования могли поступить из смежных блоков (внешние), если в процессе работ по смежному блоку было получено какое-либо общее требование.
4.4. Классификация по характеру требований
Приоритет обработки требований зависит от того, является ли полученное требование замечанием к доработке или сообщением об ошибке. Сообщения об ошибках на этапах интеграционного теста и поддержки продуктивной эксплуатации имеют наивысший приоритет и должны устраняться в максимально короткий срок.
Большое количество ошибок требует дополнительного использования ресурсов и может задерживать основной ход работ. Поэтому необходимо учитывать потенциальные риски возникновения
66
БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
ошибок в работе, когда требование принимается к исполнению. Например, риск дальнейших ошибок будет выше, если требование касается общих доработок по нескольким функциональным блокам, по которым ведутся параллельные работы. Изменение алгоритмов обработки имеет более высокий риск, чем доработка пользовательских интерфейсов и других нефункциональных требований.
5. Разработка модели управления требованиями при реализации финансового инструмента «Депозит на расчетном счете»
Модель управления требованиями реализуется в три этапа. На первом этапе отбираются бизнес требования, которые фиксируются в проектном решении и являются рамками проекта (табл. 1).
Решение о принятии или отклонении бизнес требования необходимо принимать для каждого бизнес требования, поступающего на этапе запуска/ проектирования. Бизнес требование оценивается с позиций следующих признаков: выполнимость в рамках функциональности, гарантии успешного выполнения, критичность в бизнес-процессе заказчика и соответствие стандартам организации. Признаки для оценки бизнес требований не связаны между собой, поэтому на первом этапе исполь-
Таблица 1.
Список бизнес требований для инструмента «Депозит на расчетном счете»
Код Формулировка
B1 ВНЕСЕНИЕ ДЕПОЗИТА НА РАСЧЕТНЫЙ СЧЕТ В СПИСОК ОБЯЗАТЕЛЬНЫХ ДЛЯ РЕАЛИЗАЦИИ ФИНАНСОВЫХ ИНСТРУМЕНТОВ В целевой системе необходимо реализовать финансовый инструмент «Депозит на расчетном счете» как один из основных инструментов используемых казначейством.
B2 РАСЧЕТ ПРОЦЕНТОВ В ЗАВИСИМОСТИ ОТ СРЕДНЕМЕСЯЧНОЙ СУММЫ ОСТАТКА Расчет начисляемого процента осуществляется ежемесячно на средний внутримесячный остаток на расчетном счете. Процентная ставка различается в зависимости от размера внутримесячного среднего остатка на расчетном счете.
B3 ВЫДЕЛЕНИЕ ДЕПОЗИТА СВИП КАК ОТДЕЛЬНОГО ИНСТРУМЕНТА Выделение депозита СВИП как отдельного финансового инструмента, поскольку суммы остатков по счетам СВИП, в отличие от расчетных счетов, содержатся в банковской выписке.
B4 АВТОМАТИЧЕСКИЙ РАЗБОР БАНКОВСКОЙ ВЫПИСКИ Для инструментов депозитов, депозитов на расчетном счете, депозитов СВИП должен быть реализован автоматический разбор банковской выписки, как для основных использующихся казначейством инструментов.
зуется метод анализа иерархий (МАИ) [5] и система SuperDecisions (www.superdecisions.com). Приведем пример построения модели для обработки бизнес требования B2 «Расчет процентов в зависимости от среднемесячной суммы остатка» (рис. 2).
В результате проведенных исследований бизнес требования B1, B2, B4 принимаются и должны быть отражены в проектном решении, для того, чтобы оценивать дальнейшие требования, поступающие от пользователей С1, С2, С3, С4, С5, С6 (табл. 2).
Таблица 2.
Список требований пользователей для инструмента «Депозит на расчетном счете»
C1 СОЗДАНИЕ ТАБЛИЦЫ ПРОЦЕНТРЫХ СТАВОК / ВОЗМОЖНОСТЬ ВЕДЕНИЯ ТАБЛИЦЫ ПОЛЬЗОВАТЕЛЯМИ Необходимо вести соответствие значений среднемесячной суммы остатка и процентных ставок. Ведение данных значений должно производиться пользователями системы. Установленные значения процентных ставок могут изменяться, необходимо указывать сроки действия.
C2 РАЗДЕЛЕНИЕ ОБРАБОТКИ НА ДВЕ ПРОГРАММЫ В бизнес-процессе различаются депозиты на расчетных счетах и депозиты на счетах СВИП. Так как остатки по счетам СВИП содержатся в банковской выписке, обработку сделок СВИП необходимо проводить при разборе выписки. Для депозитов на расчетных счетах в выписке содержится только значение начисленных процентов в конце месяца, поэтому ежедневная обработка сумм остатков должна проводиться отдельной программой.
С3 ПОВТОРНАЯ ОБРАБОТКА ПОТОКОВ Значения остатков на расчетных счетах может изменяться. Необходимо предусмотреть возможность запуска программы пользователями для изменения сумм потоков в сделках депозитов на расчетных счетах, а также изменение сумм потоков для депозитов СВИП при повторном разборе позиций по выписке.
С4 АВТОМАТИЧЕСКОЕ СОЗДАНИЕ СДЕЛКИ С УЧЕТОМ УСЛОВИЙ ДОГОВОРА Даты начала и конца среднемесячных сделок фиксируются в договоре с банком и могут быть разными для различных договоров. Необходимо предусмотреть возможности настройки вариантов (начисление на последний/первый день месяца или сдвиг на первый рабочий день) для договоров депозитов на расчетных счетах. Создание новых сделок следует осуществлять путем добавления ежедневных сумм при наступлении даты конца сделки по условиям договора.
C5 ОТРАЖЕНИЕ ФАКТИЧЕСКИХ ВЫПЛАТ В ОТЧЕТЕ ПО ДЕПОЗИТАМ БЕЗ УЧЕТА РЕЗУЛЬТАТА РАЗБОРА ВЫПИСКИ Для отчета по доходности депозитов реализовать отражение суммы фактических выплат за период в соответствии с указанными в условиях сделок планами погашения процентов, без учета результатов разбора банковской выписки.
С6 УДАЛЕНИЕ СТОРНИРОВАННЫХ СДЕЛОК ИЗ ДОГОВОРА В случае сторнирования ошибочно созданных сделок следует также удалять привязку сделок к договорам.
№
Формулировка
БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г
67
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
На втором этапе строится модель, позволяющая принимать решения о принятии, отклонении, уточнении или отнесении требования к дополнительным работам, для каждого поступающего требования пользователей в отдельности.
Следует отметить, что не все бизнес требования могут оказывать влияние на принятие решения относительно конкретного требования пользователя. Так требование C5 «Отражение фактических выплат в отчете без учета разбора выписки» связано лишь с бизнес требованиями B2 и B4. Поэтому на данном этапе учитывается взаимосвязь требования пользователя C5 с соответствующими бизнес требованиями. Аналогично устанавливаются связи всех остальных требований пользователей с теми или иными бизнес требованиями.
В процессе принятия решения относительно каждого конкретного требования пользователя находятся приоритеты соответствующих бизнес требований с учетом следующих признаков: выполнимость в рамках функциональности, гарантии
успешного выполнения, критичность в бизнес -процессе, соответствие стандартам организации.
Данные приоритеты учитываются при обработке требования пользователя в соответствии со следую -щими признаками: важность автора требования, дата поступления, было ли требование заявлено пользователями при проектировании, критичность для работы в системе, риск возникновения дальнейших ошибок.
Признаки для оценки бизнес требований связаны с признаками требований пользователей, последние также связаны между собой. Поэтому для построения модели принятия решения на втором этапе в системе SuperDecisions используется метод аналитических сетей (МАС) [6]. Приведем пример построения модели для обработки требования пользователя C5 «Отражение фактических выплат в отчете без учета разбора выписки» (рис. 3).
Таким образом, в результате проведенного исследования требования пользователей C1, C3, C4 принимаются. На их основе будут сформулированы системные требования.
68
БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
Рис. 3. Модель принятия решения относительно требования пользователя C5
Рис. 4. Модель принятия решения относительно системных требований
БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г.
69
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
Таблица 3.
Список возможных системных требований для принятых требований пользователей для инструмента «Депозит на расчетном счете»
№ Формулировка требования пользователя № Формулировка системного требования
C1 СОЗДАНИЕ ТАБЛИЦЫ % СТАВОК/ВОЗМОЖНОСТЬ ВЕДЕНИЯ ТАБЛИЦЫ ПОЛЬЗОВАТЕЛЯМИ Необходимо вести соответствие значений среднемесячной суммы остатка и процентных ставок. Ведение данных значений должно производиться S1.1 СОЗДАНИЕ ТАБЛИЦЫ В СИСТЕМЕ Создать таблицу ZTTD_EXT_008_PRC для хранения значения % ставок в разрезе БЕ, ID карточки договора, срока действия и границ среднемесячной суммы
пользователями системы. Установленные значения % ставок могут изменяться, необходимо указывать сроки действия S1.2 СОЗДАНИЕ ВЫЗОВА ТАБЛИЦЫ ИЗ КАРТОЧКИ ДОГОВОРА Таблицу ZTTD_EXT_008_PRC раскрывать, основываясь на карточке договора Депозита на Расчетный счет с позиционированием на строках, относящихся к текущей карточке и настоящему промежутку времени
С3 ПОВТОРНАЯ ОБРАБОТКА ПОТОКОВ Значения остатков на расчетных счетах может изменяться. Необходимо предусмотреть возможность запуска программы ZTRM_CRT_DEAL_F_MEMO пользователями для изменения сумм потоков в сделке депозитов на Расчетный счет, а также предусмотреть изменение сумм потоков для депозита Свип при повторном разборе позиций по выписке S3.1 ОБНОВЛЕНИЕ ПОТОКОВ В СДЕЛКАХ, ПРИ ПОВТОРНОМ ПРОГОНЕ ОБРАБОТКИ При обработке сумм остатков необходимо анализировать сделку на наличие уже добавленных потоков на дату. Если поток размещения на дату обработки уже присутствует в сделке, необходимо обновлять сумму и не создавать новый поток
С4 АВТОМАТИЧЕСКОЕ СОЗДАНИЕ СДЕЛКИ С УЧЕТОМ УСЛОВИЙ ДОГОВОРА S4.1 ДОБАВЛЕНИЕ ПАРАМЕТРОВ СМЕЩЕНИЯ ДАТ НАЧАЛА (КОНЦА) СДЕЛОК НА КАРТОЧКУ ДОГОВОРА
Даты начала и конца среднемесячных сделок прописываются в договоре с банком и могут быть разными для различных договоров. Необходимо предусмотреть возможности настройки вариантов (начисление на последний/первый день месяца/ сдвиг на первый рабочий день) для договоров Депозитов на Расчетный счет. Создание новых сделок производить обработкой добавления ежедневных сумм при наступлении даты конца сделки по условиям договора. Для вида договора Депозит на Расчетный счет и Депозит Свип необходимо добавить параметры запуска: смещение даты окончания сделки (1 - нет смещения/ 2 - на следующий рабочий/ 3 - на предыдущий рабочий день)
S4.2 СОЗДАНИЕ НОВОЙ СДЕЛКИ ПРИ ОБРАБОТКЕ ПОСЛЕДНЕГО ДНЯ СДЕЛКИ ТЕКУЩЕГО МЕСЯЦА При обработке сумм остатков необходимо анализировать дату обработки - если она приходится на дату окончания сделки, в соответствии с параметрами смещения, указанными в карточке договора необходимо создавать сделку на следующий месяц в привязке к карточке договора. Также при создании новой сделки должна происходить фиксация процента - т.е. расчет среднемесячной суммы и добавления значения процента в структуру
Рассмотрим системные требования, сформулированные на основе принятых требований пользователей (см. табл. 3). Для одного требования пользователя может быть сформулировано одно и более системных требований.
Ранжироваться будут все сформулированные системные требования, полученные из принятых на данный момент требований пользователей, они же будут выступать в роли альтернатив на третьем этапе решения задачи, в данном случае S1.1, S1.2, S3.1, S4.1, S4.2.
При ранжировании системных требований (рис. 4) учитывается относительная значимость требований пользователей, на основе которых они были сформулированы. Поэтому на данном этапе находятся приоритеты требований пользователей с использованием указанных выше признаков их сравнения. Для нахождения приоритетов системных требований
70
учитываются следующие признаки: затраты ресурсов, необходимых для реализации; наличие наработок в смежных функциональных блоках; риск возникновения ошибок в работе системы; были ли смещены сроки реализации, относительно изначальных, если какое либо требование рассматривается повторно.
Признаки для оценки требований пользователей и системных требований связаны друг с другом и между собой, поэтому для построения модели принятия решения на третьем этапе также используется метод аналитических сетей (МАС).
В результате получается следующее ранжирование системных требований S1.1>S4.1>S1.2> S4.2>S3.1.
Таким образом, модели принятия решений строятся с уровня бизнес требований и далее детализируются для следующих уровней. При этом наряду
=БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ
с признаками для оценки альтернатив рассматриваемого уровня, учитывается относительная значимость требований, находящихся выше в иерархии. В результате получаются приоритеты системных требований (нижнего уровня в иерархии), на основе которых далее составляются планы работ.
В данном примере рассмотрены требования, касающиеся реализации одного из функциональных блоков — «Депозит на расчетном счете». Полученные приоритеты системных требований используются при составлении плана работ по реализации в системе данного финансового инструмента, выделении ресурсов и определении сроков завершения доработок.
6. Заключение
Таким образом, процесс управления требованиями является одной из ведущих функций бизнес-аналитика при внедрении ИТ-проектов. Для достижения целей проекта стратегически важно
правильно построить процесс управления требованиями между членами проектной команды, согласовать с клиентом рамки релевантности поступающих требований и процедуру отслеживания выполненных работ.
В статье рассмотрены требования, касающиеся реализации одного из функциональных блоков — «Депозит на расчетном счете» при внедрении модуля «Казначейство» системы SAP. В результате полученные приоритеты системных требований можно использовать при составлении плана работ по реализации в системе данного финансового инструмента, выделять ресурсы и определять сроки завершения доработок.
Если таким же образом рассматривать все требования, полученные при реализации различных функциональных блоков проекта, то полученную информацию можно использовать для составления плана работ по проекту в целом. ■
Литература
1. Технология Rational Unified Process (IBM Rational Software). http://citfomm.ru/programming/applica-tion/program/3.shtml
2. IEEE Standard Glossary of Software Engineering Terminology, http://web.ecs.baylor.edu/faculty/grabow/ Fall2011/csi3374/secure/Standards/IEEE610.12.pdf
3. A Guide to the Business Analysis Body of Knowledge (BABOK Guide). Version 2.0. — Toronto: International Institute of Business Analysis, 2009.
4. SAP Treasury and Risk Management (TRM). http://help.sap.com/saphelp_erp60_sp/helpdata/en/08/ a9e139709ba63be10000000a114084/content.htm
5. Саати Т.Л. Принятие решений: Метод анализа иерархий. — М.: Радио и Связь, 1993.
6. Саати Т.Л. Принятие решений при зависимостях и обратных связях. Аналитические сети. — М.: Изд. ЛКИ., 2008.
БИЗНЕС-ИНФОРМАТИКА №3(25)-2013 г
71
