Дипломная (вкр): Формирование функциональных требований к CRM системе в сфере retail

Формирование функциональных требований к CRM системе в сфере retail

Оглавление

Введение

. Теоретические основы исследования

.1 Ключевые термины

.2 Основные методы разработки и управление требованиями

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

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

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

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

Заключение

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

Приложения

Введение

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

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

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

Процесс разработки требований подразумевает под собой основу для планирования проекта, управления рисками, приемочного тестирования, согласований и управления изменениями, а также влияет на все остальные этапы жизненного цикла ПО (программного обеспечения). Следовательно, плохо организованные, несогласованные с потребностями заинтересованных сторон, плохо написанные требования в большинстве случаев являются причиной «смерти» проектов. Действительно, ошибки, допущенные на стадии формирования требований, составляют от 40 до 60% всех дефектов проекта, и обходятся гораздо дороже, чем если бы были тщательно проработаны на стадии анализа [1]. Во избежание описанных выше проблем, очень важно использовать эффективные методы разработки требований.

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

Объектом данного исследования является процесс формирования функциональных требований к CRM системе в сфере retail, предметом изучения - разнообразные методы разработки требований.

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

.Изучение понятия и сущности функциональных требований;

.Изучение процесса разработки функциональных требований;

.Проведение исследования основных методов разработки требований;

.Проведение сравнительного анализа методов разработки требований;

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

.Формирование практических рекомендаций по разработке функциональных требований при внедрении CRM системы в сфере retail.

В качестве методов проведения исследования были выбраны:

·        Анализ существующей научной литературы, освещающей данную проблематику

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

·        Определение наиболее эффективной стратегии на примере организации в ритейл сфере

·        Формализация и анализ полученных данных

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

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

·        Сбор требований

·        Анализ требований

·        Моделирование требований

·        Детализация требований

·        Моделирование требований

·        Согласование требований

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

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

1. Теоретические основы исследования

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

1.1 Ключевые термины

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

•Бизнес-требования

•Требования пользователей

•Функциональные требования

•Системные требования

•Нефункциональные требования

Например, К. Вигерс разделяет требования к ПО на три уровня: Бизнес-требования, требования пользователей, функциональные требования. А также обозначает нефункциональные[1]. На Рисунке 1 схематично проиллюстрирован способ представления перечисленных выше видов требований, где овалы - тип информации для требований (функциональных и не функциональных), а прямоугольники - способ хранения информации.

Рисунок 1 Взаимосвязь нескольких типов информации для требований

Однако А. Аурум и К. Уохлин [2] определяют следующие типы требований:

Таблица 1 Классификация требований

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

Согласно международному стандарту IEEE [3] функциональные требования - это требования, которые определяют функцию, которую система или системный компонент должны иметь возможность выполнить[1]. Таким образом, функциональные требования предоставляют ответ на вопрос «Что должна делать система?», но при этом не отвечают на вопрос «Как именно это должна делать система?». Другими словами, определяют функциональность программного обеспечения, которую необходимо построить разработчикам для возможности реализации пользователями своих задач в рамках бизнес-правил.

Важность функциональных требований в жизненном цикле ПО описал Ф.Брукс еще в далеком 1987 году в своем эссе «No silver Bullet: Essense and Accidents of Software Engineering»: «…Строжайшее и единственное правило построения систем ПО - решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей требований, в том числе и взаимодействие с людьми, механизмами и с иными системами ПО. Никакая другая часть работы не портит результат, если она выполнена плохо…». Действительно, согласно статистике [4] одними из основных причин неуспешности проектов являются плохо организованные требования, не отвечающие запросам стейкхолдеров и неконтролируемый процесс изменения требований (см. Таблица 2).

Таблица 2. Причины провалов проектов

Ошибки в требованиях подвергают риску успешность всего проекта (Под успешностью понимается выпуск ПО, полностью удовлетворяющего требованиям стейкхолдеров и пользователей в функциональности и качестве). Анализируя всю вышеперечисленную информацию, становится очевидным, что неотъемлемым фактором успеха проекта является грамотная разработка функциональных требований и правильно выстроенный процесс управления их изменениями. ритейл программный информация

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

·        Процесс определения заинтересованных сторон (стейкхолдеров)

·        Сбор требований

·        Анализ требований

o   Проверка требований на полноту, корректность, осуществимость, необходимость, недвусмысленность, атомарность, проверяемость, согласованность, трассируемость;

o   Детализация требований;

o   Моделирование требований

o   Приоритизация собранных требований

·        Документирование требований

·        Согласование требований

На протяжении всего проекта процесс управления требованиями носит непрерывный характер. Данный этап определяется как «выработка и поддержание взаимного согласия с заказчиками по поводу требований к разрабатываемому ПО» [1] и включает в себя следующие подэтапы:

·        Назначение основной версии документа

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

·        Оценка предлагаемых изменений

o   Процесс принятия одобренных изменений согласно установленному регламенту

o   Корректировка плана проекта в соответствии с оценкой предлагаемых изменений

·        Отслеживание статусов требований

Очевидно, что описанные выше процессы разработки и управления требованиями тесно связаны друг с другом, но все-таки необходимо понимать области их разделения (см. Рисунок 2). Как видно из схемы, оба документа отвечают за основную версию функциональных требований. Только целью процесса разработки является предоставление корректно задокументированных требований к разрабатываемому программному продукту, тогда когда процесс управления требованиями отслеживает изменения относительно основной версии документа, запускает регламентированный процесс управления ими и предоставляет гарант заинтересованным лицам в документации, проверке и соответствии их функциональным требованиям к продукту.

Рисунок 2 Разделение областей разработки требований и управления ими

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

1.2 Основные методы разработки и управление требованиями

Методы разработки

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

.        Определение заинтересованных сторон (стейкхолдеров)

.        Сбор требований

.        Анализ требований

.        Документирование требований

.        Верификация требований

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

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

Сбор требований

После того, как определен список стейкхолдеров запускается процесс сбора требований.

Пошаговый план выявления требований:

.        Определить цель выявления требований

.        Определить стратегию выявления требований

.        Результаты выявления требования (варианты использования, сценарии использования, анализ результатов опроса и т.д.)

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

·        Проведение интервью

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

·        Анкетирование

·        Изучение работы персонала

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

·        Способы решения проблем в существующих системах

·        Сценарии использования (Use Case) (см. Рисунок 3)

·        Изучение существующей описательной документации

В первую очередь рассмотрим такой метод выявления требований, как проведение интервью. Интервью - это исключительно психологическая задача, не имеющая ничего общего с организационными или техническими аспектами разработки систем[2]. Очень важно, чтобы интервьюер разбирался в предметной области и относился к своей работе серьезно и как можно чаще задавал наводящие вопросы. В течение самого диалога эффективным методом сбора требований будет пошаговое описание процесса работы опрашиваемого представителя заинтересованной стороны. Все обсужденные моменты необходимо зафиксировать, и представить для рецензирования либо в виде протокола, либо в виде диаграммы вариантов использования и т.д. Процесс проведения интервью см. Рисунок 4.