Вы находитесь на странице: 1из 9

ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ

УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ
ПРИ РЕАЛИЗАЦИИ ИТ-ПРОЕКТОВ
Т.К. Кравченко,
доктор экономических наук, профессор, заведующий кафедрой бизнес-аналитики
Национального исследовательского университета «Высшая школа экономики»
E-mail: tkravchenko@hse.ru
Адрес: г. Москва, ул. Кирпичная, д. 33/5

В статье предлагается подход к моделированию процесса управления требованиями


при реализации ИТ-проектов. Модель управления требованиями реализуется в три этапа.
На первом этапе отбираются бизнес-требования, которые фиксируются в проектном реше-
нии и являются рамками проекта. На втором этапе строится модель, связанная с принятием,
отклонением, уточнением или отнесением к дополнительным работам каждого поступающего
требования пользователей. На третьем этапе для принятых требований пользователей фор-
мируются приоритеты системных требований, на основе которых далее составляются планы
работ по проекту. При построении моделей принятия решений используются методы анализа
иерархий и аналитических сетей Т.Л. Саати и СППР SuperDecisions.

Ключевые слова: управление требованиями, моделирование процесса управления требованиями, метод


анализа иерархий, метод аналитических сетей, система поддержки принятия решений SuperDecisions.

1. Введение ми, поступающими от заказчика. Соответственно,


для того, чтобы цели проекта были достигнуты,

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

БИЗНЕС-ИНФОРМАТИКА №3(25)–2013 г. 63
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ

внедрение информационных систем, инфраструк- 3. документированное представление условий


турные и организационные проекты. или возможностей для пп. 1 и 2.
Для таких проектов характерна высокая интен- Первичные данные, поступающие от клиентов,
сивность и итерационность выполнения работ с характеризуются противоречивостью, неполнотой,
подробным составлением календарно-сетевых гра- нечеткостью, изменчивостью. Требования нужны,
фиков. Выработка требований и управление тре- в частности, для того, чтобы команда исполнителей
бованиями – важнейшие элементы успеха любого могла определить и согласовать с заказчиками вре-
ИТ-проекта. Более половины потерь времени ор- менные и финансовые перспективы проекта. Поэ-
ганизациями – разработчиками программного обе- тому значительная часть требований должна быть
спечения связаны с неэффективностью подхода к собрана и обработана на ранних этапах определе-
управлению требованиями. ния дизайна внедряемой системы.
Однако собрать на ранних стадиях все необходи-
2. Роль бизнес-аналитика мые данные удается только в исключительных слу-
при реализации ИТ-проектов чаях, так как заказчик не всегда способен оценить
все нюансы и особенности предстоящей работы в
Роль бизнес-аналитика в проекте внедрения ин-
новой системе. На практике процесс сбора, анали-
формационной системы заключается в разработке
за и обработки требований зачастую нетривиален,
непротиворечивой модели требований бизнеса в
растянут во времени на протяжении всего проекта
рамках и терминах внедряемой системы, коммуни-
и включает доработки функциональности, выве-
кация клиентских требований разработчикам и об-
денной на стадию поддержки продуктивной экс-
ратно, презентация клиентам реализованной функ-
плуатации.
циональности.
Бизнес аналитик, занимаясь управлением требо-
Эффективное управление требованиями подразу-
ваниями, должен быть способен предоставлять их
мевает как их учет на стадии поступления и отслежи-
в виде, необходимом для правильного восприятия
вание статуса выполнения, так и принятие решений
аудиторией. Следовательно, требования должны
о приоритетности, критичности и сроках выполне-
быть сформулированы на языке, понятном как
ния поступающих требований.
пользователям, так и разработчикам. Для каждого
Приведем определение процесса управления тре- требования необходимо контролировать его статус,
бованиями: это процесс, включающий идентифи- сохранять историю изменений, отслеживать смеж-
кацию, выявление, документацию, анализ, отсле- ные требования и использовать уже полученные
живание, приоритизацию требований, достижение наработки для реализации новых поступающих
соглашений по требованиям и затем управление из- требований.
менениями и уведомление заинтересованных лиц.
Таким образом, необходимо фиксировать посту-
Управление требованиями – непрерывный процесс
пающие требования с указанием таких атрибутов
на протяжении всего жизненного цикла продукта [1].
как дата получения, автор, а также направление, к
В качестве требования рассматривается любое которому это требование относится. Также необхо-
условие, которому должна соответствовать разраба- димо проверять, соответствует ли требование со-
тываемая система. Требованием может быть функ- гласованным рамкам проекта.
циональность системы или ограничение, которому
Формат, в котором фиксируются требования,
система должна удовлетворять.
должен быть понятен для всех заинтересованных
В рамках IEEE Standard Glossary of Software лиц (стейкхолдеров), которым необходимо озна-
Engineering Terminology [2] понятие требования трак- комиться со списком требований и подтвердить
туется шире: его. Поэтому в задачи бизнес аналитика входит до-
1. условия или возможности, необходимые пользо- кументирование требований в четком, понятном и
вателю для решения проблем или достижения целей; оправданно детализированном виде, чтобы обеспе-
2. условия или возможности, которыми должна чить понимание и эффективную коммуникацию
обладать система или системные компоненты, что- между членами команды [3].
бы выполнить контракт или удовлетворять стандар- Рассмотрим процесс управления требованиями
там, спецификациям или другим формальным доку- на примере проекта внедрения модуля «Казначей-
ментам; ство» системы SAP (SAP Treasury) [4].

64 БИЗНЕС-ИНФОРМАТИКА №3(25)–2013 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ

3. Классификация требований заключительная подготовка, внедрение. В ходе пла-


при внедрении модуля нирования очередного этапа работ уточняются цели
«Казначейство» системы SAP этапа, состав и контролируемые результаты работ.
Приведем схему классификации требований по
Основной целью проекта внедрения модуля «Каз-
различным признакам: по уровням (бизнес тре-
начейство» системы SAP (полное название – «SAP
бования, требования пользователей, системные
Treasury and Risk Management, SAP TRM») являет-
требования), по содержанию (функциональные,
ся создание централизованной системы управле-
нефункциональные), по источникам (внутренние
ния казначейством, которая заменит собственные
или внешние относительно блока функциональ-
разработки и будет интегрирована с другими си-
ности) и по характеру (требования к доработке или
стемами, уже используемыми в компании. Для до-
сообщения об ошибках) (рис. 1). Данная классифи-
стижения данной цели необходима автоматизация
кация будет использоваться при построении моде-
казначейских операций.
лей управления требованиями проекта.
При помощи модуля SAP TRM осуществляется
управление финансовыми операциями и позиция- 4.1. Классификация
ми, а также отношениями с контрагентами (бизнес- по уровням требований
партнерами), от процессов ввода и расчета сделок до
учета деривативов, операций на денежном и валют- Рассматривая требования в разрезе этапов жиз-
ном рынках, сделок с кредитными инструментами, ненного цикла разработки системы, можно выде-
операций с ценными бумагами и (внутригрупповы- лить следующие уровни требований, поступающих
ми) займами, а также документарных операций. от заказчика.
В рамках проекта предусматриваются такие этапы Требования верхнего уровня, – бизнес требова-
работ, как запуск и проектирование, реализация и ния, – формулируются руководством компании-

УРОВНИ ТРЕБОВАНИЙ СОДЕРЖАНИЕ ТРЕБОВАНИЙ

Функциональные ИСТОЧНИК ТРЕБОВАНИЙ


Бизнес требования
требования
Алгоритмы обработки
Рамки проекта Функции системы
Внешние
Внутренние По смежному
функционалу
Удобство
Ненкциональные требования

использования Частные Общие


Требования Пользовательский интерфейс
пользователей Справочная информация

Функции
и характеристики Надежность ХАРАКТЕР ТРЕБОВАНИЙ
системы
Сбои
Точность вычислений

Производительность Требования ! Сообщения


к доработке об ошибке
Системные Скорость работы
требования Пропускная способность

Детальное
описание Поддерживаемость
с точки зрения
системы Сопровождение
Адаптация и расширение

Ограничения

Ограничения проектирования
Организация реализации
Требования к интерфейсам
Физические ограничения
Рис. 1. Классификация требований

БИЗНЕС-ИНФОРМАТИКА №3(25)–2013 г. 65
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ

заказчика на стадии разработки проектного реше- системы; средствам поддержки различных язы-
ния для выбранной системы. Такие требования ков; инструментам создания и получения отчетов;
включают определение укрупненных функцио- средствам контроля доступа к определенным ин-
нальных модулей, которые должны поддерживать формационным ресурсам; средствам управления
ведение основных бизнес-процессов. Соответ- приложениями в распределенной среде; поддерж-
ственно, этап анализа бизнес требований заклады- ки документооборота.
вает фундамент для проектирования и реализации К нефункциональным требованиям относятся тре-
системы. бования к удобству использования, надежности и
Следующий уровень – это уровень требований производительности системы, возможности под-
пользователей. Требования пользователей отража- держки. К различным ограничениям относятся
ют их пожелания к функциям и характеристикам ограничения проектирования, реализации, разра-
создаваемой системы. Требования могут включать ботки, написания программного кода и др.
перечисления действий пользователя и откликов
системы в альтернативных сценариях, а также 4.3. Классификация
содержать характеристики, которым должна удо- по источникам требований
влетворять система для реализации этих сценари-
ев. Сюда входит организация удобных диалоговых В процессе реализации различных блоков про-
средств и доработка методов расчета. екта, поступающие требования можно разделять на
Требования, формулируемые пользователями, частные (полученные по доработкам, касающимся
часто бывают недостаточно структурированными, конкретного блока, и не влияющие на смежную
дублирующимися, противоречивыми. Поэтому за- функциональность) и общие (требования, которые
дача бизнес-аналитика состоит в том, чтобы пре- касаются обработки нескольких блоков функцио-
образовать их в требования к функциональности нальности системы). При выполнении общих тре-
системы, на основе которых будут производиться бований необходимо учитывать, насколько они
настройки стандарта и составляться технические совместимы с частными требованиями каждого из
задания для разработчиков. отдельных функциональных блоков, для которых
реализуется общее требование.
Для внедрения системы важен и третий уровень –
функциональный или системный, на котором осу- Подобное разделение можно также описать с
ществляется формализация требований пользо- точки зрения источника получения требования.
вателей. Каждое требование пользователя может Для отдельно взятого функционального блока тре-
стать основой для формулирования нескольких си- бования могут быть внутренними (они же частные),
стемных требований. полученными от пользователей в процессе разбора
вопросов касающихся данного блока. Также требо-
4.2. Классификация вания могли поступить из смежных блоков (внеш-
по содержанию требований ние), если в процессе работ по смежному блоку
было получено какое-либо общее требование.
Поступающие требования могут касаться как
алгоритмов работы системы, так и различных не- 4.4. Классификация
функциональных характеристик, которыми долж- по характеру требований
на обладать система. Таким образом, по содержа-
нию требования можно разделить на две основные Приоритет обработки требований зависит от
категории: функциональные и нефункциональные. того, является ли полученное требование замеча-
Функциональные требования относятся к основ- нием к доработке или сообщением об ошибке. Со-
ным свойствам / функциям системы. Ряд требо- общения об ошибках на этапах интеграционного
ваний касается поддержки работы пользователей, теста и поддержки продуктивной эксплуатации
это требования к инструментам отслеживания имеют наивысший приоритет и должны устранять-
действий пользователей и записи в журнал без- ся в максимально короткий срок.
опасности конкретных типов событий. К функ- Большое количество ошибок требует дополни-
циональным требованиям также относятся требо- тельного использования ресурсов и может задер-
вания к средствам отслеживания, приобретения, живать основной ход работ. Поэтому необходимо
установки и контроля использования лицензий учитывать потенциальные риски возникновения

66 БИЗНЕС-ИНФОРМАТИКА №3(25)–2013 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ

ошибок в работе, когда требование принимается к зуется метод анализа иерархий (МАИ) [5] и система
исполнению. Например, риск дальнейших ошибок SuperDecisions (www.superdecisions.com). Приведем
будет выше, если требование касается общих дора- пример построения модели для обработки бизнес
боток по нескольким функциональным блокам, по требования B2 «Расчет процентов в зависимости от
которым ведутся параллельные работы. Изменение среднемесячной суммы остатка» (рис. 2).
алгоритмов обработки имеет более высокий риск, В результате проведенных исследований бизнес
чем доработка пользовательских интерфейсов и требования B1, B2, B4 принимаются и должны быть
других нефункциональных требований. отражены в проектном решении, для того, чтобы
оценивать дальнейшие требования, поступающие
5. Разработка модели от пользователей С1, С2, С3, С4, С5, С6 (табл. 2).
управления требованиями
при реализации финансового инструмента Таблица 2.
«Депозит на расчетном счете» Список требований пользователей для инструмента
«Депозит на расчетном счете»
Модель управления требованиями реализуется в
три этапа. На первом этапе отбираются бизнес тре- № Формулировка
бования, которые фиксируются в проектном реше-
нии и являются рамками проекта (табл. 1). C1 СОЗДАНИЕ ТАБЛИЦЫ ПРОЦЕНТРЫХ СТАВОК /
ВОЗМОЖНОСТЬ ВЕДЕНИЯ ТАБЛИЦЫ ПОЛЬЗОВАТЕЛЯМИ
Решение о принятии или отклонении бизнес тре-
Необходимо вести соответствие значений среднемесяч-
бования необходимо принимать для каждого биз- ной суммы остатка и процентных ставок. Ведение данных
нес требования, поступающего на этапе запуска/ значений должно производиться пользователями системы.
Установленные значения процентных ставок могут
проектирования. Бизнес требование оценивается изменяться, необходимо указывать сроки действия.
с позиций следующих признаков: выполнимость
в рамках функциональности, гарантии успешного C2 РАЗДЕЛЕНИЕ ОБРАБОТКИ НА ДВЕ ПРОГРАММЫ
выполнения, критичность в бизнес-процессе за- В бизнес-процессе различаются депозиты на расчетных
счетах и депозиты на счетах СВИП. Так как остатки по счетам
казчика и соответствие стандартам организации. СВИП содержатся в банковской выписке, обработку сделок
Признаки для оценки бизнес требований не связа- СВИП необходимо проводить при разборе выписки.
Для депозитов на расчетных счетах в выписке содержится
ны между собой, поэтому на первом этапе исполь- только значение начисленных процентов в конце месяца,
поэтому ежедневная обработка сумм остатков должна
Таблица 1. проводиться отдельной программой.
Список бизнес требований для инструмента С3 ПОВТОРНАЯ ОБРАБОТКА ПОТОКОВ
«Депозит на расчетном счете» Значения остатков на расчетных счетах может изменяться.
Необходимо предусмотреть возможность запуска программы
Код Формулировка пользователями для изменения сумм потоков в сделках
депозитов на расчетных счетах, а также изменение сумм
потоков для депозитов СВИП при повторном разборе
B1 ВНЕСЕНИЕ ДЕПОЗИТА НА РАСЧЕТНЫЙ СЧЕТ В СПИСОК ОБЯЗА- позиций по выписке.
ТЕЛЬНЫХ ДЛЯ РЕАЛИЗАЦИИ ФИНАНСОВЫХ ИНСТРУМЕНТОВ
В целевой системе необходимо реализовать финансовый С4 АВТОМАТИЧЕСКОЕ СОЗДАНИЕ СДЕЛКИ
инструмент «Депозит на расчетном счете» как один из С УЧЕТОМ УСЛОВИЙ ДОГОВОРА
основных инструментов используемых казначейством. Даты начала и конца среднемесячных сделок фиксируются в
договоре с банком и могут быть разными для различных до-
B2 РАСЧЕТ ПРОЦЕНТОВ В ЗАВИСИМОСТИ говоров. Необходимо предусмотреть возможности
ОТ СРЕДНЕМЕСЯЧНОЙ СУММЫ ОСТАТКА настройки вариантов (начисление на последний/первый день
Расчет начисляемого процента осуществляется ежемесячно месяца или сдвиг на первый рабочий день) для договоров
на средний внутримесячный остаток на расчетном счете. депозитов на расчетных счетах. Создание новых сделок
Процентная ставка различается в зависимости от размера следует осуществлять путем добавления ежедневных сумм при
внутримесячного среднего остатка на расчетном счете. наступлении даты конца сделки по условиям договора.

B3 ВЫДЕЛЕНИЕ ДЕПОЗИТА СВИП КАК ОТДЕЛЬНОГО ИНСТРУМЕНТА C5 ОТРАЖЕНИЕ ФАКТИЧЕСКИХ ВЫПЛАТ В ОТЧЕТЕ ПО
Выделение депозита СВИП как отдельного финансового ДЕПОЗИТАМ БЕЗ УЧЕТА РЕЗУЛЬТАТА РАЗБОРА ВЫПИСКИ
инструмента, поскольку суммы остатков по счетам СВИП, в от- Для отчета по доходности депозитов реализовать
личие от расчетных счетов, содержатся в банковской выписке. отражение суммы фактических выплат за период в соответ-
ствии с указанными в условиях сделок планами погашения
B4 АВТОМАТИЧЕСКИЙ РАЗБОР БАНКОВСКОЙ ВЫПИСКИ процентов, без учета результатов разбора банковской выписки.
Для инструментов депозитов, депозитов на расчетном счете,
депозитов СВИП должен быть реализован автоматический С6 УДАЛЕНИЕ СТОРНИРОВАННЫХ СДЕЛОК ИЗ ДОГОВОРА
разбор банковской выписки, как для основных использую- В случае сторнирования ошибочно созданных сделок
щихся казначейством инструментов. следует также удалять привязку сделок к договорам.

БИЗНЕС-ИНФОРМАТИКА №3(25)–2013 г. 67
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ

Рис. 2. Модель принятия решения относительно бизнес требования B2

На втором этапе строится модель, позволяю- успешного выполнения, критичность в бизнес-


щая принимать решения о принятии, отклонении, процессе, соответствие стандартам организации.
уточнении или отнесении требования к дополни- Данные приоритеты учитываются при обработке
тельным работам, для каждого поступающего тре- требования пользователя в соответствии со следую-
бования пользователей в отдельности. щими признаками: важность автора требования, дата
Следует отметить, что не все бизнес требования поступления, было ли требование заявлено пользова-
могут оказывать влияние на принятие решения от- телями при проектировании, критичность для работы
носительно конкретного требования пользователя. в системе, риск возникновения дальнейших ошибок.
Так требование 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 ПОВТОРНАЯ ОБРАБОТКА ПОТОКОВ S3.1 ОБНОВЛЕНИЕ ПОТОКОВ В СДЕЛКАХ, ПРИ ПОВТОРНОМ


ПРОГОНЕ ОБРАБОТКИ
Значения остатков на расчетных счетах может изме-
няться. Необходимо предусмотреть возможность за- При обработке сумм остатков необходимо анализировать сделку на
пуска программы ZTRM_CRT_DEAL_F_MEMO поль- наличие уже добавленных потоков на дату. Если поток размещения
зователями для изменения сумм потоков в сделке на дату обработки уже присутствует в сделке, необходимо обновлять
депозитов на Расчетный счет, а также предусмотреть сумму и не создавать новый поток
изменение сумм потоков для депозита Свип при
повторном разборе позиций по выписке

С4 АВТОМАТИЧЕСКОЕ СОЗДАНИЕ СДЕЛКИ С УЧЕТОМ S4.1 ДОБАВЛЕНИЕ ПАРАМЕТРОВ СМЕЩЕНИЯ ДАТ НАЧАЛА (КОНЦА)
УСЛОВИЙ ДОГОВОРА СДЕЛОК НА КАРТОЧКУ ДОГОВОРА
Даты начала и конца среднемесячных сделок Для вида договора Депозит на Расчетный счет и Депозит Свип необхо-
прописываются в договоре с банком и могут быть димо добавить параметры запуска: смещение даты окончания сделки
разными для различных договоров. Необходимо (1 – нет смещения/ 2 – на следующий рабочий/ 3 – на предыдущий
предусмотреть возможности настройки вариантов рабочий день)
(начисление на последний/первый день месяца/
сдвиг на первый рабочий день) для договоров S4.2 СОЗДАНИЕ НОВОЙ СДЕЛКИ ПРИ ОБРАБОТКЕ ПОСЛЕДНЕГО
Депозитов на Расчетный счет. Создание новых ДНЯ СДЕЛКИ ТЕКУЩЕГО МЕСЯЦА
сделок производить обработкой добавления еже-
дневных сумм при наступлении даты конца сделки При обработке сумм остатков необходимо анализировать дату обработ-
по условиям договора. ки - если она приходится на дату окончания сделки, в соответствии с
параметрами смещения, указанными в карточке договора необходимо
создавать сделку на следующий месяц в привязке к карточке договора.
Также при создании новой сделки должна происходить фиксация
процента - т.е. расчет среднемесячной суммы и добавления значения
процента в структуру

Рассмотрим системные требования, сформулиро- учитываются следующие признаки: затраты ресурсов,


ванные на основе принятых требований пользовате- необходимых для реализации; наличие наработок в
лей (см. табл. 3). Для одного требования пользователя смежных функциональных блоках; риск возникно-
может быть сформулировано одно и более системных вения ошибок в работе системы; были ли смещены
требований. сроки реализации, относительно изначальных, если
Ранжироваться будут все сформулированные си- какое либо требование рассматривается повторно.
стемные требования, полученные из принятых на дан-
Признаки для оценки требований пользователей
ный момент требований пользователей, они же будут
и системных требований связаны друг с другом и
выступать в роли альтернатив на третьем этапе реше-
между собой, поэтому для построения модели при-
ния задачи, в данном случае S1.1, S1.2, S3.1, S4.1, S4.2.
нятия решения на третьем этапе также использует-
При ранжировании системных требований (рис. 4) ся метод аналитических сетей (МАС).
учитывается относительная значимость требований
В результате получается следующее ранжирование
пользователей, на основе которых они были сфор-
мулированы. Поэтому на данном этапе находятся системных требований S1.1>S4.1>S1.2> S4.2>S3.1.
приоритеты требований пользователей с использо- Таким образом, модели принятия решений стро-
ванием указанных выше признаков их сравнения. ятся с уровня бизнес требований и далее детализи-
Для нахождения приоритетов системных требований руются для следующих уровней. При этом наряду

70 БИЗНЕС-ИНФОРМАТИКА №3(25)–2013 г.
ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В БИЗНЕСЕ

с признаками для оценки альтернатив рассматри- правильно построить процесс управления требо-
ваемого уровня, учитывается относительная значи- ваниями между членами проектной команды, со-
мость требований, находящихся выше в иерархии. гласовать с клиентом рамки релевантности посту-
В результате получаются приоритеты системных пающих требований и процедуру отслеживания
требований (нижнего уровня в иерархии), на осно- выполненных работ.
ве которых далее составляются планы работ. В статье рассмотрены требования, касающиеся
В данном примере рассмотрены требования, ка- реализации одного из функциональных блоков –
сающиеся реализации одного из функциональных «Депозит на расчетном счете» при внедрении мо-
блоков – «Депозит на расчетном счете». Полученные дуля «Казначейство» системы SAP. В результате
приоритеты системных требований используются полученные приоритеты системных требований
при составлении плана работ по реализации в систе- можно использовать при составлении плана работ
ме данного финансового инструмента, выделении ре- по реализации в системе данного финансового ин-
сурсов и определении сроков завершения доработок. струмента, выделять ресурсы и определять сроки
завершения доработок.
6. Заключение
Если таким же образом рассматривать все тре-
Таким образом, процесс управления требования- бования, полученные при реализации различных
ми является одной из ведущих функций бизнес- функциональных блоков проекта, то полученную
аналитика при внедрении ИТ-проектов. Для до- информацию можно использовать для составления
стижения целей проекта стратегически важно плана работ по проекту в целом.

Литература

1. Технология Rational Unified Process (IBM Rational Software). http://citforum.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

Оценить