6. Личный контакт с заинтересованным лицом

Для методик сбора требований: оценивается наличие тесного взаимодействия со стейкхолдером во время сбора требований выбранным методом. При наличии взаимодействия ставится плюс, иначе - минус.

Для методик анализа требований: не применимо (не может являться отрицательной или положительной характеристикой исследуемого метода)

7. Применимость на опасных производствах

Для методик сбора требований: если выбранная методика сбора не несет опасности для здоровья и жизнедеятельности при применении её на опасных производствах, то ставится «+», иначе «-».

Для методик анализа требований: если методика не несет опасности для здоровья и жизнедеятельности при применении её на опасных производствах, то ставится плюс, иначе - минус.

8. Выявление пропущенных функций

Для методик сбора и анализа требований: если выбранная методика позволяет находить неточности и пропущенные шаги в функционале, ставится плюс, иначе - минус.

Ячейка заполняется значением «+/-» в случае, если на критерий влияет внешняя среда, в зависимости от который, результат может смениться как на плюс, так и на минус.

9. Отсутствие ограничений

Для методик сбора и анализа требований: если метод сбора или анализа требований подразумевает под собой использование специализированного ПО, привлечения специалистов другого профиля, то ставится «-», иначе «+».



Таблица 9 Сравнительный анализ методик сбора и анализа функциональных требований

	Методы сбора требований	Методы анализа
	Интервьюирование	Проведение семинаров	Анкетирование	Очное изучение работы персонала	Изучение записей работы персонала	Изучение документации	Прототипирование: Одноразовые прототипы	Прототипирование: Эволюционный прототип	Визуальное моделирование	Текстовое представление
Низкие временные затраты	-	+/-	+	-	+	+	-	-	-	+
Скорость получения результатов	-	+	+	-	+	+	+	+	+	-
Бюджетность	-	-	+	-	+	+	+	-	-	+
Фокус на функциональных требованиях	+	+	-	+	+	+	-	-	+/-	+
Достоверность и качественность получаемой информации	+	+	-	+	-	-	+	+	+	+
Личный контакт с заинтересованным лицом	+	+	-	+	-	-	+/-	+/-
Применимость на опасных производствах	-	-	+	-	+	+	+	+	+	+
Выявление пропущенных функций	+	+	-	+	+	-	+	+	+	+
Отсутствие ограничений	+	+	+	+	+	+	-	-	-	+

Согласно полученной матрице, можно сделать вывод, что, естественно, каждый метод разработки и анализа имеет свои плюсы и минусы. К сожалению, в сфере разработки функциональных требований не существует универсальной методики сбора, анализа, документирования, согласования и управления. Матрица наглядно показывает, что только при сочетании нескольких разных методик можно выработать эффективную стратегию. В зависимости от факторов, важных исследуемой организации, по данной таблице легко выявить теоретическую «стратегию успеха». Конечно же, на практике всё складывается не так удачно ввиду влияния многих внешних факторов. Именно поэтому для формирования стратегии, применимой к сфере ритейл при внедрении CRM системы будет недостаточно сравнительного анализа, основанного на чистой теории, и придется обратиться к исследовательской работе в данной области.



2. Практическое исследование

В целях формирования стратегии разработки функциональных требований применительно к сфере ритейл, необходимо провести исследование в этой области. В первую очередь, необходимо рассмотреть особенности проекта, на практике выявить методы, используемые организацией. Далее проанализировать все преимущества и недостатки, применяемой стратегии и на основании этого сделать вывод.

По причине наличия множества подходов к разработке требований, процессы отличаются от методики сбора требований до методики их согласования. Именно поэтому для определения наиболее подходящей стратегии формирования функциональных требований при внедрении системы лояльности в сфере розничной торговли мною была выбрана компания Техносерв Консалтинг. Данная компания имеет огромный опыт в сфере IT консалтинга:

· Входит в ТОП-10 крупнейших консалтинговых фирм в России

· Компанией реализовано более 300 проектов по внедрению ИТ -систем различного уровня

· Компания «Техносерв Консалтинг» сертифицирована по системе менеджмента качества на соответствие международному стандарту ISO 9001:2008

· Компания завоевала титул «Интегратор года» в национальном конкурсе программ лояльности Loyalty awards в 2014 г.

Именно опыт и компетенция компании в данной области помогли сделать выбор в пользу нее для исследования процесса сбора функциональных требований, их разработки и управления при внедрении системы лояльности. Исследование проводилось на проекте по внедрению CRM системы в одну из крупнейших компаний на рынке розничной торговли на этапе анализа.

2.1 Исходные данные проекта

Название проекта: Реализация единого Операционного CRM для 3 торговых сетей

Исполнитель работ: ООО «Техносерв Консалтинг»

На момент начала проекта у компании XXX существовала система лояльности, к которой были подключены две торговые сети из трех, которая перестала отвечать бизнес-требованиям заказчика, и была недостаточно гибкой, для того, чтобы подключить к системе лояльности одну из самых быстроразвивающихся сетей группы компаний.

Целью проекта является создание системы, удовлетворяющей функциональным и нефункциональным требованиям Заказчика, в срок.

Разрабатываемая CRM система является инструментом, обеспечивающим процессы клиентского обслуживания в части разработки и управления программами лояльности розничных сетей заказчика.

Реализация проекта производится для 3х торговых сетей, которыми управляет организация-заказчик.

Согласно уставу проекта в зону ответственности бизнес-аналитика входит:

· Выполнение работ по разработке и документированию бизнес и функциональных требований к проектным решениям;

· Разработка документации к системе;

· Участие в обучении пользователей работе с системой.

2.2 Сбор и систематизация информации о процессе разработки функциональных требований

Определение заинтересованных сторон

На этапе сбора требований очень тесно связаны интересы всех заинтересованных лиц с успехом проекта. Первостепенной задачей команды на начальном этапе проекта было выявление важных пользователей и прочих стейкхолдеров с целью выбора представителей каждого класса пользователей для дальнейшего взаимодействия в рамках проекта.

Список стейкхолдеров был определен на этапе предпроектного исследования и внесён в документ «Устав проекта». Список заинтересованных лиц проекта и их зоны ответственности см. Приложение А.

Методика сбора и анализа требований

Формирование функциональных требований - итеративный процесс. Требования фиксируются один за другим, детализируются и помещаются в общую структуру. Как уже упоминалось выше, требования могут формироваться из различных источников. В случае исследуемого проекта в рамках тендера заказчиком были предоставлены верхнеуровневые требования, из которых были выявлены бизнес-требования, схемы основных бизнес-процессов и сценарии AS IS (см. Приложение Б), касающихся сферы лояльности. Уже на основании этих источников формируются и анализируются функциональные требования к внедряемой системе лояльности. Функциональный охват исследуемого проекта приведен на схеме ниже (см. Рисунок 18):

Рисунок 18 Функциональный охват исследуемого проекта

В случае «Техносерв консалтинг» методиками сбора функциональных требований были определены:

· Проведение совместных семинаров (workshop) на протяжении всего этапа анализа

· Опыт работы с аналогичными системами

· Документации предшествующей системы

· Изучение видеозаписей работы персонала в аналогичной системе

На практике одним из самых действенных методов оказался метод проведения совместных семинаров. Эффективность проведения совместных семинаров определялась применением комбинации перечисленных выше методов. Дело в том, что перед каждым семинаром на начальных стадиях командой изучалась документация внедряемой системы Maxxing, документация заменяемой системы и инструкции пользователей касательно обсуждаемых процессов. Всё это позволяло сформировать концепцию и презентовать ее заинтересованным в проекте лицам. Более того, именно такая последовательность и сочетание методов позволяет максимально эффективно формировать представление о необходимой функциональности системы. Это так ввиду того, что чаще всего пользователям трудно определиться «с нуля» с тем, что именно они хотят видеть в системе, и, когда аналитики проводят встречу с заготовленными материалами, предложениями, стейкхолдерам проще донести своё видение продукта, подтвердить или опровергнуть детали разработанного требования, а также найти «дыры» в функциональности. Таким образом, данная стратегия частично покрывает два процесса: формирование и анализ функциональных требований. Далее перечислены некоторые факторы успешного проведения семинаров, выявленные в ходе проекта:

- всегда стоит придерживаться определенной структуры семинара;

- участники семинара должны быть уполномочены принимать решения по модификации требований и формирования новых;

- участники семинара всегда должны быть подготовлены к семинару и ознакомлены с повесткой встречи и прилагаемыми материалами;

- все участники семинара должны понимать предметную область и «говорить на одном языке». В этих целях обычно утверждается Глоссарий;

- все принятые решения должны быть зафиксированы и согласованы ответственными лицами со стороны заказчика в обязательном порядке;

Метод анализа и моделирования требований

Основные задачи аналитика на данном этапе - выявление конфликтующих требований и областей, требующих детализации, а также определение функциональных требований в соответствии с запросами разработчиков. Более того, на данном этапе разработки требований важно привести все требования в соответствии со следующими критериями:

1. Каждое требование должно быть уникально

2. Каждое требование должно быть представлено четко и ясно.

3. Каждое требование должно быть атомарным

4. Требования должны быть представлены последовательно

5. Каждое требование должно быть выполнимо

6. Каждое требование должно быть недвусмысленно

7. Каждое требование должно быть проверяемо

8. Каждое требование должно быть отслеживаемо

9. Отсутствие каких-либо неопределенных терминов, таких как «и т.д., и т.п., возможно, универсальный» из-за того, что из-за таких «лазеек» может быть очень сильно увеличен объем требования, а, следовательно, и скоуп работ по проекту.

При фиксировании новых требований к функциональности системы, компанией проводился GAP-анализ. Из-за того, что систему предоставляла французская компания Maxxing, необходимо было проверить все требования на выполнимость в системе. При нахождении различий между требованиями и возможностями функционала нашей компанией фиксировался GAP и его критичность, далее доработки такого плана обсуждались на собраниях управляющего комитета и предоставлялось решение относительно каждого разрыва в функциональности.

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

На этапе анализа на каждый процесс был выделен владелец со стороны исполнителя и ответственный со стороны заказчика по требованиям к определенному процессу (см. Рисунок 19). Таким образом, из-за большого объема информации для удобства согласования документа, по каждой группе процессов подготавливался отдельный СИС.

Рисунок 19 Матрица ответственных

Далее рассмотрим процесс разработки ФТ на примере процесса «Работа с обращениями», подпроцесса «Регистрация обращения/ задачи». Соответственно, для данного процесса также был подготовлен СИС. В общем и целом, структура этого документа представляет собой непосредственно описание самих сценариев, а также включает в себя:

- электронные одноразовые прототипы пользовательских интерфейсов (см. Приложение В);

- спецификации полей и кнопок используемых экранов (см. Приложение Г);

- схемы БП (см. Рисунок 20);

- диаграммы статусов (см. Рисунок 21);

- визуализация различных алгоритмов (см. Приложение Д)

На самой диаграмме не показаны детали выполняемых системой процессов, а только возможные изменения состояний. Этот метод позволяет проанализировать все ли необходимые состояния и переходы состояний корректно задокументированы и помогает разработчику понять предполагаемое поведение системы.

- визуализация алгоритмов выбора обращения и т.д.;

- другие различные вспомогающие средства визуализации.

Рисунок 20 Схема БП «Регистрация обращения / задачи»

Рисунок 21 Модель состояний работы с обращениями Клиентов (поле «Статус» для обращения)

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

Во время работы над сценариями использования системы были выделены несколько их преимуществ как анализа и моделирования требований:

· Позволяют находить пропущенные шаги

· Возможность построения хронологической последовательности

· Возможность для различных предложений со стороны представителей заинтересованных лиц вследствие более детального понимания взаимодействия с системой

· Позволяют избежать дублирования, двусмысленности, неактуальности требований

Путем совмещения методик, описанных в разделе «Методика сбора и анализа требований» и методик по написанию сценариев использования системы были выявлены, задокументированы и согласованы функциональные требования. Ниже приведена выдержка из ФТ, применительно к рассматриваемому процессу «Работа с обращениями» (см. Таблица 10).

Таблица 10 Выдержка из ФТ

Код	Процесс	Ссылка на номер БТ	Подпроцесс/ Детализация БП	Ограничения
5.4	Работа с обращениями	4,1Основной идентификатор участника - номер карты лояльности. Типы карт лояльности: основная, дополнительная.	Идентификация клиента ь Требуется возможность поиска счета в том числе по: · Номер карты · Тип карты · Статус карты · Номер транзакции · Телефону · Email · ФИО · Дата рождения · И т.д. ь Необходима возможность аутентификации клиента по кодовому слову, при этом проверка корректности аутентификации должна проводиться системой
		8.6.1 Тип коммуникации (sms/e-mail/слип-чек, колл-центр) 8.6.3 Дата и время коммуникации 8.6.2 Текст сообщения 8.6.4 Статус доставки сообщения (для sms и e-mail) 8.6.5 Статус прочтения сообщения (для e-mail) 8.6.6 Тип обращения 8.6.7 Дата и время обращения 8.6.8 Дата и время ответа на обращение 8.6.9 Текст ответа 8.6.10 Канал коммуникации ответа (sms/звонок/e-mail) 10.1.1 Регистрировать обращения клиентов 10.1.2 Работать с задачами по обработке обращений клиентов	ь Создание и работа с задачей: - Создание задачи - Выбор типа задачи - Выбор канала поступления обращения - Фиксация результата выполнения задачи в виде текстового описания - Изменение статуса выполнения задачи - Указание приоритета задач ь Требуется возможность поиска задачи в том числе по идентификатору клиента или ответственному за выполнение задачи ь Требуется возможность «быстрого» создания задач, которые не требуют передачи на 2 линию поддержки ь Требуется функционал фиксации контакта с клиентом, при этом к контакту может быть привязано несколько задач в рамках общения с клиентом ь Требуется индикация просроченных задач в списке «моих» задач пользователя ь Требуется возможность администрирования приоритетов и сроков выполнения задач в зависимости от типа задачи ь Необходимо возможность взятия задачи в работу из общей очереди для операторов 2 линии, при этом в работу должна выдаваться задача с самой ранней датой создания (из задач, находящихся в пуле 2 линии)	Не предполагается реализация возможности ручной отправки SMS пользователем посредством Решения. В системе не будет предусмотрено ограничение на выбор типа задачи при создании задачи.
		8.6 Необходимо хранение истории исходящей/входящей коммуникации с участником программы включая (глубина 2 года)	ь Требуется возможность просмотра всей истории обращений по клиенту по всем каналам коммуникаций
		10.1.16 Эскалировать обращения в различные отделы	ь Требуется возможность назначения задач на 2 и 3 линию. ь У сотрудников 2 и 3 линии должна быть возможность принять в работу обращение, назначенное на 2 и 3 линии соответственно	При невыходе сотрудника на работу задачи, закрепленные за ним, будет необходимо переназначить вручную.
		10.1.15 Просматривать справочную информацию, необходимую для обслуживания клиентов (список магазинов, каталогу промо-правил и проч.)	ь Требуется возможность просматривать справочную информацию, необходимую для обслуживания клиентов (список магазинов, каталогу промо-правил, базе знаний и проч.)

Специфика документирования требований

Все функциональные требования заносятся в единый, выявленный опытным путем, шаблон написания документа, фиксирующего функциональные требования к продукту (см. Таблица 10). На момент составления документа по ФТ, каждому бизнес требованию был присвоен уникальный идентификатор. В целях сохранения иерархии каждое детализированное требование было описано со ссылкой на соответствующее родительское БТ. Так же для поддержания процесса управления требованиями в структуре документа заполнялся раздел «История документа» с указанием следующих параметров:

- Версия документа

- Дата изменения

- Автор изменения

- Описание внесенных изменений

- Комментарий

Для каждой версии документа (0.1, 0.2, 1.1, 1,2….) используется последовательная нумерация. Актуальные версии документов ведутся в общей системе Confluence а все изменения в документах выполняются в режиме правки.

Специфика согласования требований

Особенностью проекта является то, что согласование требований происходило не только со стороной заказчика, но и так же с вендорами. После этапа сбора требований и их разработки с представителями со стороны заказчика необходимо было провести валидацию требований с представителями компании внедряемой Системы Maxxing. На встрече проводился GAP анализ, результатом которого был список разрывов между функциональными требованиями и реальными возможностями системы, который был скорректирован в соответствии с временными рамками проекта.

Рисунок 22 Процесс согласования требований на проекте

Каждый подготовленный документ, кроме протоколов встречи проходил процесс согласования, схематически изображенный на Рисунке 22.

Специфика управления требованиями

Базовые версии требований неизбежно редактируются в процессе разработки требований. Поэтому для эффективного управления требованиями необходимо определить процесс изменения требований и оценки их влияния на проект в целом.

Ниже представлена утвержденная диаграмма процесса управления изменениями.

Рисунок 23 Диаграмма процесса управления рамками проекта

Все запросы на изменения должны быть адресованы Руководителю проекта, предпочтительно с помощью формы регистрации запроса на изменения (см. Таблица 11)



Таблица 11 Форма регистрации запроса на изменение

№ запроса на изменения	Дата запроса на изменение	Описание изменения	Орган, авторизовавший изменение	Статус

Руководитель проекта должен координировать все действия, связанные с запросом на изменения. По всем запросам на изменения должен осуществляться анализ влияния на проект, включая предварительное перепланирование проекта.

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

После утверждения изменений Руководитель проекта должен провести стандартные процедуры перепланирования проекта, а именно обеспечить внесение изменений:

*в календарный план проекта;

*реестр рисков и открытых вопросов/проблем;

*в проектную и пользовательскую документацию;

*все изменения вносятся по мере необходимости.

Все запросы на изменения, имеющие статус «В ожидании» на момент завершения проекта должны быть помещены в «План оптимизации/развития проекта», реализация которого осуществляется по завершении настоящего проекта. Информация о новых запросах на изменения или информация о смене статуса запроса на изменения помещается в еженедельный отчет по статусу проекта.

Что касается успешного контроля хода проекта, на проекте используется:

- Определение базовой версии документа

- Контроль версий документов

- Ведение атрибутов требований (владелец, приоритет, версия, дата изменения)

- Использование инструментария Attlasian Confluence + Attlasian Jira

Системы от Atlassian славятся своей гибкостью и легкостью в управлении и настройке. Сочетание Jira и Confluence помогает эффективно управлять требованиями и большим спектром задач. В ходе проекта вся документация хранится и актуализируется в Confluence, там ведется вся информация и атрибутика требований, журнал изменений (см. Рисунок 24). Более того, при создании протоколов в Confluence есть возможность привязки поручения/ задачи в рамках документа (см. Рисунок 20). Опытным путем было выявлено, что в данных системах эффективно происходит взаимодействие всей проектной команды, легко и удобно отслеживается ход работ в рамках разработки требований.

Рисунок 24 Контроль версий документов в пространстве Confluence

Рисунок 25 Привязка поручений/ задач в Jira

Во время исследования были сформировано новое видение разработки функциональных требований, а также выявлены новые эффективные сочетания методов разработки требований к функционалу внедряемой системы

На основании полученных данных, эффективной разработки и согласования документа «Функциональные требования к проекту» и успешного завершения стадии «Анализ», можно сделать вывод об эффективности примененной стратегии. Благодаря хорошему руководству и опыту ведения больших проектов по внедрении CRM систем, проектной команде удалось внедрить систему лояльности за короткий срок, не критично нарушая временные рамки, успешно перераспределяя ресурсы.



3. Формирование стратегии разработки функциональных требований

В связи с тем, что сфера розничной торговли характеризуется высокой конкуренцией, особенно среди крупных игроков рынка, внедрение CRM систем является большим преимуществом. Правильно выстроенный процесс формирования функциональных требований, а главное - управления ими, чаще всего определяют направление и успешность всего проекта. Следовательно, в связи с тем, что в условиях жесткой конкуренции скорость вывода продукта в эксплуатацию имеет довольно большой вес, организации необходимо разработать эффективную стратегию разработки функциональных требований. Фокус приходится на функциональные требования, так как именно данный тип требований определяет всю концепцию разрабатываемого продукта, соответствующую стратегическим целям организации. Эффективное формирование, анализ и управление функциональными требованиями позволяют минимизировать риск ошибок на этапе разработки, и, таким образом, также минимизировать риск разрастания границ проекта.

Итак, методом совмещения теоретических знаний и успешного опыта внедрения модуля лояльности CRM Системы в одну из крупнейших Российских ритейлинговых компаний, была сформирована эффективная стратегия, которая может быть применена на всех подобных проектах с каскадной моделью разработки ПО (см. Рисунок 26)

Итак, на разработанной модели ниже так же представлены процессы формирования требований на этапе предпроектного исследования для лучшего понимания входных данных. Первой ступенью стратегии на этапе анализа является изучение всех предоставленных материалов, в том числе видеозаписей работы персонала. Данные методики помогают сформировать видение продукта со стороны заказчика, т.к. предметом изучения является то, что они имеют сейчас и к чему привыкли, с какими проблемами сталкиваются, а также бизнес-цели, к которым стремится организация. На основании полученных данных проводится семинар, где выявляются и детализируются требования со всеми заинтересованными лицами. При выявлении требований, которые не были учтены в документе «Бизнес-требования» обновляется матрица приоритетов и фиксируется владелец и проводится GAP-анализ на наличие запрашиваемой функциональности в коробочном варианте устанавливаемой в организации CRM системы.

Главной особенностью данного процесса является то, что на заключительных стадиях формирования функциональных требований, в процесс включается такой метод структурирования и аналитики как написание сценариев использования системы. Данный метод помогает выявить пропущенные шаги, неполные требования и сократить временные рамки этапа. Единственное ограничение, что после согласования документа «Функциональные требование» все нововыявленные требования вносятся в документ только после запроса на изменение.

Далее представлен структурированный список методов, используемых при разработке функциональных требований в стратегии:

Методы сбора требований:

ѕ Изучение документации

ѕ Изучение записей работы пользователей

ѕ Обучение работе во внедряемой системе

ѕ Проведение семинаров

Методы анализа:

ѕ Написание Сценариев использования системы

ѕ GAP анализ

Управление требованиями:

ѕ Присвоение уникального номера каждому требованию

ѕ Фиксация приоритета и владельца требования

ѕ Использование инструментария управления требованиями

ѕ Определение базовой версии документов

ѕ Поддержание списка актуализированных версий документов

ѕ Наличие унифицированного процесса изменения требований

Документирование:

ѕ Использование структурированного шаблона

ѕ Фиксация всех принятых решений

ѕ Версионность документов

ѕ Ведение атрибутики: автор, дата изменения, описание изменения, и т.д.

Рисунок 26 Стратегия разработки ФТ при внедрении CRM системы в сфере ритейл

Заключение

Исходя из проделанной работы, можно сделать вывод, что существует большое количество различных методик по разработке функциональных требований к системе. Однако же для всестороннего исследования они все должны использоваться в сочетании друг с другом в зависимости от ресурсов, особенностей компании и методологии управления проектом в целом.

С помощью критического анализа литературы и практического исследования были выявлены эффективные способы выявления, анализа, документирования и управления требованиями.

В результате, все поставленные в ходе исследования задачи выполнены, результаты их выполнения предоставлены. Изучение литературы стало основой для теоретического анализа, а исследование позволило подтвердить или опровергнуть их непосредственную применимость. Результатом выполнения работы явилась разработанная стратегия по формированию функциональных требований при внедрении CRM системы. Данный подход был успешно применен на примере проекта с одной из крупнейших ритейлинговых сетей России. Таким образом, практическая ценность полученной стратегии заключается в её применимости ко всем подобным проектам.



Список использованной литературы

1 Вигерс К., Битти Дж. Разработка требований к программному обеспечению, 3-е изд., дополненное.-- М.: Издательство «Русская редакция», 2014. -- 736 с.

2 Aybьke Aurum, Claes Wohlin Engineering and Managing Software Requirements, 2005

3 IEEE Standard Glossary of Software Engineering Terminology [Электронный ресурс]/ URL: http://www.mit.jyu.fi/ope/kurssit/TIES462/Materiaalit/IEEE_SoftwareEngGlossary.pdf

4 The Standish Group Report [Электронный ресурс]/ URL:https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

5 Анализ требований к автоматизированным информационным системам [Электронный ресурс]/ URL:http://www.intuit.ru/studies/courses/2188/174/info (дата обращения: 02.02.2017)

6 АНАЛИТИЧЕСКИЙ ОБЗОР СИСТЕМ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ [Электронный ресурс]/ URL: http://earchive.tpu.ru/bitstream/11683/17013/1/conference_tpu-2015-C04-v2-067.pdf

7 Алистер Коберн Современные методы описания функциональных требований к системам. -- М.: - Издательство: «Лори», 2011 - 288 с.

8 Леффингуэлл Д., Уидриг Д. Принципы работы с требованиями к ПО. -- М.: Издательство «Вильямс», 2002 - 448с.



Приложения

Приложение А

Список заинтересованных лиц проекта и зона их ответственности

Список стейкхолдеров

№ п/п	Наименование роли	Описание
1.	Директор проекта	Зона ответственности: • Принятие решений об изменениях рамок проекта • Разрешение конфликтов, эскалированных с уровня руководителя проекта • Выделение ресурсов на проект
2.	Руководитель проекта	Отвечает за планирование и исполнение проекта, включая подготовку управляющих документов проекта и отчетность по проекту. Обеспечивает контроль выполнения работ по проекту (процессов и результатов), планирует и контролирует ход выполнения Проекта в соответствии с Планом Проекта, включая назначения исполнителей на задачи. Выполняет постановку задач, устанавливает требования к результатам работ, организует согласование и приемку результатов работ, готовит/согласует запросы на изменение. Организует взаимодействие между участниками проектной команды. Принимает решения по вопросам, возникающим в процессе работы проектной команды, включая сдачу/приемку результатов.
3.	Администратор проекта	Фиксирует договоренности, организует встречи, рассылает протоколы на согласование. При необходимости переводит протоколы и прочие проектные материалы на английский или русский язык, переносит зафиксированные поручения в Jira и контролирует выполнение поручений, выкладывает проектные документы в Confluence и контролирует версионность документов.
4.	Функциональный архитектор (Product Owner)	Зона ответственности: • Разработка карты бизнес-процессов, реализуемых целевой системой, и согласование её с Заказчиком • Постановка задач бизнес-аналитикам на разработку функциональных и нефункциональных требований к целевой системе • Консолидация требований к целевой системе и контроль их выполнимости и непротиворечивости • Согласование с Заказчиком требований к целевой системе
5.	Интеграционный архитектор	Зона ответственности: • Постановка задач интеграционной группе на разработку интеграционных требований к целевой системе • Консолидация интеграционных требований к целевой системе и контроль их выполнимости и непротиворечивости • Разработка интеграционной архитектуры целевой системы • Согласование с Заказчиком интеграционных требований и архитектуры целевой системы
6.	Руководитель аналитической группы	Зона ответственности: • Разработка бизнес-требований, в том числе нефункциональных, определённых функциональным архитектором (Product Owner) • Разработка документации к целевой системе • Обучение пользователей работе с системой • Делегирование своих задач бизнес-аналитикам и управление ими • Оценка трудозатрат и сроков выполнения бизнес-анализа и документирования системы • Анализ и классификация запросов, поступающих от пользователей системы на этапах пилота, тиража и в ходе последующей гарантийной поддержки
7.	Бизнес-аналитик	Выполняет работы по разработке и документированию бизнес- и функциональных требований к проектным решениям, разработке документации к системе; участвует в обучении пользователей работе с системой.
8.	Руководитель интеграционной группы	Зона ответственности: • Разработка требований к интеграции, определённых интеграционным архитектором • Разработка программы и методики миграции данных • Делегирование своих задач аналитикам интеграции и управление ими • Оценка трудозатрат и сроков выполнения интеграционного анализа • Проведение миграции для этапа «Пилот» • Проведение миграции для этапа «Тираж»
9.	Интеграционный аналитик	Выполняет работы по разработке и документированию интеграционных решений, описанию интеграционных интерфейсов, тестированию результатов реализации и выполнению сопутствующих работ проекта.
10.	Руководитель группы разработки	Зона ответственности: • Оценка трудозатрат и сроков реализации функциональных и нефункциональных требований в коде и настройках целевой системы • Реализация функциональных и нефункциональных требований к целевой системе в исходном коде и настройках • Организация исправления дефектов, в том числе зарегистрированных на основе запросов, поступающих от пользователей системы на этапах пилота, тиража и в ходе последующей гарантийной поддержки • Делегирование своих задач разработчикам и управление ими
11.	Разработчик	Выполняет доработку и настройку целевой системы в соответствии с согласованными требованиями к ней.
12.	Руководитель группы QA	Зона ответственности: • Согласование системных и бизнес-требований с точки зрения их тестируемости и доступности необходимых для этого тестовых сред и данных • Оценка трудозатрат и сроков разработки тестов и проведения тестирования • Разработка сценариев функционального, интеграционного и нагрузочного тестирования, а также программы и методики испытаний на основе функциональных и нефункциональных требований к целевой системе • Проведение функционального, интеграционного и нагрузочного тестирования • Проведение тестовой миграции данных (на тестовой среде) в соответствии с программой и методикой миграции данных
13.	Тестировщик	Выполняет тестирование в соответствии со сценариями тестирования. Регистрирует обнаруженные при тестировании дефекты. Проводит повторное тестирование функционала системы после исправления дефектов в нём, в т.ч. на протяжении срока действия гарантийной поддержки.
14.	Ведущий инженер по инфраструктуре	Зона ответственности: • Согласование архитектуры целевой системы и системных требований к ней с точки зрения сложности развёртывания и поддержки целевой системы • Помощь Заказчику в определении оборудования и инфраструктуры, необходимых для работы целевой системы, и формулирование требований к ним с учётом сайзинга, предоставленного вендором Maxxing • Оценка трудозатрат и сроков развёртывания целевой системы



Приложение Б

Пример предоставленных сценариев AS IS

Клиент хочет перенести баллы с одной карты одного счета на другую карту на другом счете и обратился в Call-центр. (Клиент хочет перенести баллы на карту родственника):

· Сотрудник Call-центр проводит идентификацию по данным клиента по карте-источнику;

· Сотрудник блокирует карту-источник;

· Сотрудник по карте Клиента создает задачу «Перевод баллов на другую карту»;

· Сотрудник выбирает карту-приемник и оставляет комментарий с причиной переноса баллов. Нажимает кнопку «Перенести»;

· Сотрудник проверяет, что баланс по карте-приемнику изменен;

· Сотрудник проверят, что в истории изменений по карте-источнику отражена операция списания баллов, а по карте-приемнику операция начисления.

При переносе баллов на новый счет переносятся следующие данные:

o Баллы по карте.

По счету источнику очищаются следующие данные:

o Баланс по карте-источнику.

Остальные данные остаются без изменений. В истории фиксируется факт переноса баллов.



Приложение В

Экран «Mx Loyalty - Клиент > Обращения > Мои Обращения»



Приложение Г

Макеты спецификации полей экранов и используемых кнопок

Шаблон спецификации полей экрана

Название поля (рус)	Тип	Режим доступа (условие)	Обяз-ть	Комментарий	По умолч. Отобр-ся
ID обращения Maxxing	Строка	RO	Да	Служебный идентификатор обращения в системе Maxxing	Да

Спецификация используемых кнопок экрана

Кнопка / Триггер процедуры	Доступность	Тип реакции	Логика исполнения	Результат / текст сообщения в случае ошибки
Кнопки
	Всегда	Открытие окна	Открыть форму выбранной карточки обращения	Открыта форма «Карточка обращения»



Приложение Д

Алгоритм выбора обращения для назначения

Размещено на Allbest.ru