Формирование функциональных требований к 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. Причины провалов проектов
|
Недостаточное привлечение пользователей
|
12,8%
|
|
Неполнота требований
|
12,3%
|
|
Изменение требований
|
11,8%
|
|
Недостаток поддержки руководства
|
7,5%
|
|
Технологическая некомпетентность
|
7,0%
|
|
Недостаток в ресурсах
|
6,4%
|
|
Нереалистические ожидания
|
5,9%
|
|
Нечеткие цели
|
5,3%
|
|
Нереальные плановые сроки
|
4,3%
|
|
Появление новой технологии
|
3,7%
|
|
Другое
|
23%
|
Ошибки в требованиях подвергают риску успешность всего проекта (Под
успешностью понимается выпуск ПО, полностью удовлетворяющего требованиям
стейкхолдеров и пользователей в функциональности и качестве). Анализируя всю
вышеперечисленную информацию, становится очевидным, что неотъемлемым фактором
успеха проекта является грамотная разработка функциональных требований и
правильно выстроенный процесс управления их изменениями. ритейл программный информация
Остановимся подробнее на процессе разработки функциональных требований.
Данный этап проекта представляет собой процесс их сбора, анализа,
документирования и проверки. По результатам анализа научной литературы,
несмотря на то, что, опять же, различные авторы по-разному определяют и
детализируют данные подэтапы, их можно обобщить следующим образом:
· Процесс определения заинтересованных сторон (стейкхолдеров)
· Сбор требований
· Анализ требований
o Проверка требований на полноту, корректность, осуществимость,
необходимость, недвусмысленность, атомарность, проверяемость, согласованность,
трассируемость;
o Детализация требований;
o Моделирование требований
o Приоритизация собранных требований
· Документирование требований
· Согласование требований
На протяжении всего проекта процесс управления требованиями носит
непрерывный характер. Данный этап определяется как «выработка и поддержание
взаимного согласия с заказчиками по поводу требований к разрабатываемому ПО»
[1] и включает в себя следующие подэтапы:
· Назначение основной версии документа
· Поддержка актуальных версий требований у всей проектной
команды
· Оценка предлагаемых изменений
o Процесс принятия одобренных изменений согласно установленному
регламенту
o Корректировка плана проекта в соответствии с оценкой
предлагаемых изменений
· Отслеживание статусов требований
Очевидно, что описанные выше процессы разработки и управления
требованиями тесно связаны друг с другом, но все-таки необходимо понимать
области их разделения (см. Рисунок 2). Как видно из схемы, оба документа
отвечают за основную версию функциональных требований. Только целью процесса
разработки является предоставление корректно задокументированных требований к
разрабатываемому программному продукту, тогда когда процесс управления
требованиями отслеживает изменения относительно основной версии документа,
запускает регламентированный процесс управления ими и предоставляет гарант
заинтересованным лицам в документации, проверке и соответствии их
функциональным требованиям к продукту.
Рисунок 2 Разделение областей разработки требований и управления
ими
Рассмотрев теоретические основы и предпосылки исследования, становится
очевидным важность такого этапа как разработка функциональных требований в
процессе внедрения любой системы и, как следствие, важность применения
эффективных методик.
1.2
Основные методы разработки и управление требованиями
Методы
разработки
Как уже было отмечено выше, в теории различается большое количество типов
требований к программному обеспечению, которые различаются по степени
детализации, назначению и т.д. Ниже будут приведено описание разработки
функциональных требований со следующей степенью детализации по этапам:
. Определение заинтересованных сторон (стейкхолдеров)
. Сбор требований
. Анализ требований
. Документирование требований
. Верификация требований
Определение
заинтересованных сторон
Выявление заинтересованных сторон - отправная точка при разработке
требований ввиду того, что первым возникает вопрос «Кого необходимо опрашивать
для того, чтобы собрать требования?». Целью данного процесса считается формирование
списка лиц (или организаций), активно участвующих в проекте или интересы
которых неразрывно с ним связаны. Ими могут являться заказчики, спонсоры,
пользователи ПО, команда проекта, менеджер портфеля, менеджер проекта,
функциональные руководители и т.д.
Сбор
требований
После того, как определен список стейкхолдеров запускается процесс сбора
требований.
Пошаговый план выявления требований:
. Определить цель выявления требований
. Определить стратегию выявления требований
. Результаты выявления требования (варианты использования,
сценарии использования, анализ результатов опроса и т.д.)
Безусловно, этот этап разработки требований является одним из
основополагающих и важных. Он подразумевает под собой тесное сотрудничество
всех выявленных заинтересованных сторон, аналитиков и разработчиков. В целях
облегчения диалога, необходимо разработать словарь терминов предметной области,
чтобы разговаривать с клиентами на «одном языке». Итак, существует несколько
стратегий сбора функциональных требований к программному продукту, которые
варьируются в зависимости от типа проекта. Среди них выделяют:
· Проведение интервью
· Проведение семинаров
· Анкетирование
· Изучение работы персонала
· Опыт работы с аналогичными системами
· Способы решения проблем в существующих системах
· Сценарии использования (Use Case) (см. Рисунок 3)
· Изучение существующей описательной документации
В первую очередь рассмотрим такой метод выявления требований, как проведение
интервью. Интервью - это исключительно психологическая задача, не имеющая
ничего общего с организационными или техническими аспектами разработки
систем[2]. Очень важно, чтобы интервьюер разбирался в предметной области и
относился к своей работе серьезно и как можно чаще задавал наводящие вопросы. В
течение самого диалога эффективным методом сбора требований будет пошаговое
описание процесса работы опрашиваемого представителя заинтересованной стороны.
Все обсужденные моменты необходимо зафиксировать, и представить для
рецензирования либо в виде протокола, либо в виде диаграммы вариантов
использования и т.д. Процесс проведения интервью см. Рисунок 4.
Рисунок 3 Пример диаграммы вариантов использования «Заказ
товара»
Обсуждение таких сценариев во многом облегчает задачу по выявлению
требований и в понимании пользователями своих желаний относительно
функциональности системы. В ходе критического анализа литературы были выявлены
основные факторы успешного интервью:
· Интервью проводится с представителем каждой из
заинтересованных сторон
· Интервью всегда должно быть задокументировано и предоставлено
на проверку
· Интервьюер должен стимулировать собеседника к обсуждению
требований
· Интервьюер должен попытаться выяснить степень важности
обсуждаемых требований
· Обсуждение должно быть построено по принципу «От общего к
частному»
· Интервьюер должен четко определять «владельцев» требований
· Во время обсуждения интервьюер не должен погружаться в
специфику непосредственной разработки пользовательских требований
Рисунок 4 Процесс «Проведение интервью»
Результатом данного этапа должно стать согласованное представление о
функциональных потребностях стейкхолдеров.
Следующая эффективная стратегия по сбору требований - проведение
семинаров. Его отличительная черта от той же стратегии интервьюирования -
относительная быстрота выявления требований.
Рисунок 5 Процесс получения пользовательский требований
посредством проведения семинаров
Несмотря на то, на каком этапе разработки функциональных требований
проводится данный семинар, все его участники должны быть к нему подготовлены. В
случае если существует предварительная версия функциональных требований, над
которой вы будете работать, она должна быть выслана за день до назначенной
встречи. Если же таковой версии нет, то необходимо начать с того, что все
участники встречи как представители заинтересованных сторон должны подготовить
для будущей системы свои требования/ варианты использования/ сценарии и т.д.
Процесс получения функциональных требований схематически изображен на рис. 5.
Эффективность данного процесса определяется взаимодействием различных
групп заинтересованных пользователей. Оно может быть организовано различными
способами:
. В режиме online
фиксации и рецензирования (при наличии проектора) с привлечением всех
участников семинара
. Разделением всех участников на небольшие группы и
предоставлением им части набора требований для дальнейшего анализа и
рецензирования. Далее уточненный каждой группой набор требований
предоставляется для ознакомления, анализа и рецензирования всему коллективу.
При использовании этого подхода к организации семинара работа над требованиями
к проекту может продолжаться 3-4 дня [2].
Таблица 3 Преимущества и недостатки проведения семинаров
|
Плюсы проведения семинаров
|
Минусы проведения семинаров
|
|
Позволяет развить и детализировать требования
|
Сложности в организации встречи, если команда географически
разделена
|
|
Позволяет определить приоритеты
|
Большое количество людей на семинарах затрудняет принятие
решений
|
Следующим методом выявления требований выделяют анкетирование.
Главным его достоинством является бюджетность. Действительно, анкетирование -
самый малозатратный способ получения информация от стейкхолдеров и в то же
время не самый эффективный. Неэффективность обуславливается в первую очередь
недостаточной мотивацией или неспособностью рецензентов предоставить
качественную и правдивую информацию. В литературе выделяют следующие
рекомендации по формулированию опросов:
. Формулировка многоальтернативных вопросов - Подразумевают под
собой опрос свободной формы, который может расширяться комментариями
анкетируемого
. Формулировка рейтинговых вопросов - Подразумевают под собой
опросы с преопределенными ответами как «абсолютно согласен», «не согласен»,
«абсолютно не согласен», «не знаю» и т.д.
. Формулировка вопросов с ранжированием - Подразумевают под собой
предоставление ответов как упорядоченного списка путем присваивания каждому
пункту своего порядкового номера
Таблица 4 Преимущества и недостатки проведения анкетирования
|
Плюсы анкетирования
|
Минусы анкетирования
|
|
Высокая скорость получения результатов
|
Методика не подходит для выявления неясных требований
|
|
Бюджетность
|
Сложность выявления всех необходимых вопросов при
составлении анкеты
|
Метод изучения существующей описательной документации может быть
использована организацией только при наличии в компании Заказчика актуальных
версий, которые могут так или иначе помочь в определении функциональных
требований заказчика. Например, могут использоваться такие документы как
регламенты описания процессов, структура организации, процессы as is, процессы to be, стандарты организации, различного
рода инструкции, шаблоны документов и т.д. Данная методика может быть
эффективна при автоматизации устоявшихся регламентированных БП (бизнес
процессов).
Таблица 5 Преимущества и недостатки процесса изучения
документации
|
Плюсы изучения документации
|
Минусы изучения документации
|
|
Быстрое получение информации
|
Данный способ не применим при наличии в компании Заказчика
только базовых документов (или их полном отсутствии), а так же при отсутствии
актуальных версий документов
|
Метод изучения работы персонала - довольно полезная стратегия получения
информации по функциональным требованиям пользователей. Независимо от вида
наблюдения: пассивный или активный, участники получают информацию о необходимом
функционале системы из первых рук. В результате наблюдения, у аналитиков
возникают вопросы, которые могли бы никогда не возникнуть при проведении того
же интервью, анкетирования и т.д. Единственным недостатком этой стратегии
является то, что процесс наблюдения вносит некую «сумятицу» в работу
сотрудников, которые могут под пристальным присмотром начать вести себя не так
как обычно.
Таблица 6 Преимущества и недостатки процесса изучения работы
персонала
|
Плюсы изучения работы персонала
|
Минусы изучения работы персонала
|
|
Быстрое получение информации
|
В процессе наблюдения могут быть упущены некоторые
альтернативные сценарии бизнес процесса.
|
|
Позволяет наглядно увидеть проблему и разработать наиболее
оптимальный вариант ее решения.
|
Трудно применим на секретных предприятиях или опасных
(вредных) производствах.
|
|
Помогает наиболее точно собрать требования, наблюдая за
работой сотрудников.
|
|
Прототипирование традиционно выделяется как один из самых эффективных методов
выявления требований. Это так, потому что образное мышление позволяет
большинству людей быстрее воспринимать информацию. Целями данной стратегии
являются:
. Устранение неясных требований на ранних стадиях разработки -
Наглядная версия системы позволяет заинтересованным сторонам прояснить и
завершить процесс формулирования функциональных требований.
. Выбор единственного решения из многих концепутальных - Макет
системы позволяет заинтересованным сторонам исследовать альтернативные варианты
реализации требований, оптимизировать удобство взаимодействия пользователя с
системой.
На данный момент существует значительное количество видов прототипов, но
все их объединяет то, что все они только часть или вообще образец
разрабатываемого продукта. Прототипы могут быть как действующими моделями или
статичными образцами, детализированным изображением экрана или эскиз
интерфейса, имитацией или подражанием. Далее рассмотрим классификации
прототипов, подходящие для выявления функциональных требований. Итак, горизонтальный
(поведенческий) прототип - он позволяет смоделировать интерфейс пользователя, и
при этом не затрагивает ни логику обработки, ни базу данных. Данный вид
прототипа демонстрирует пользователю функциональные возможности системы,
особенности пользовательского интерфейса (элементы управления, цветовая гамма,
расположение форм) и структуру навигации. Следующий вид прототипа, применимый к
разработке функциональных требований - одноразовый (исследовательский). Главной
его особенностью является быстрота макетирования тех или иных аспектов системы,
но при этом необходимо следить за тем, чтобы «сырой код» не стал частью целевой
системы. К. Вигерс определяет следующую схему перехода от исследовательского
прототипа к детализированному дизайну пользовательского интерфейса (см. Рисунок
6). Данный вид эффективен в случае неясности, двусмысленности, неполноты
и неопределенности функциональных требований. Более того, такой метод анализа
требований позволяет сэкономить денежные ресурсы в связи с итерационным методом
уточнения пользовательского интерфейса, так как при резком переходе от описания
вариантов использования к финальному детализированному дизайну может возникнуть
достаточно большое количество ошибок, которое повлечет за собой выявление
ошибок в требованиях и, как следствие, переделки продукта.
Рисунок 6 Схема перехода от исследовательского прототипа к
детализированному дизайну
Следующими исследуемыми в контексте данной работы прототипами будут
бумажные или электронные. Для удобства создания последних применяются различные
инструменты, как Microsoft Visio, ConceptDrawPro, Pidoco, Draw.io и т.д. Прототипы применяются для
презентации пользователям и заинтересованным лицам интерфейса без привлечения
для работы с ними. Соответственно, они могут быть описаны следующими
характеристиками:
ü Низкобюджетные
ü Низкотехнологичные
ü Быстроконструируемые
ü Позволяют попробовать сделать шаг к разработке продукта,
практически не рискуя
ü Позволяют однозначно определить требования
Действительно, хоть данные виды прототипов и считаются
«низкокачественными», в плане разработки функциональных требований - это
отличный вариант. Ввиду того, что прототипирование на бумаге или при помощи
компьютера ускоряет каждый цикл выявления/ детализации требований, эти способы
в принципе являются ключевым фактором успеха рассматриваемого этапа разработки.
Главный минус - фокус заинтересованных сторон не на том, что надо
сделать, а как именно. На это могут уходить колоссальные временные ресурсы.
Таблица 7 Преимущества и недостатки процесса прототипирования
|
Плюсы прототипированияМинусы прототипирования
|
|
|
Быстрая обратная связь
|
Фокус на нефункциональных требованиях
|
|
Вовлечение заказчика
|
Фокус на дизайне
|
|
Позволяет наглядно увидеть проблему и разработать наиболее
оптимальный вариант ее решения.
|
При разработке эволюционного прототипа - большие временные
затраты
|
|
В перспективе помогает разработчикам
|
Недостаточный анализ
|
|
Уменьшение рисков
|
|
Самая последняя рассматриваемая в данной работе стратегия сбора
функциональных требований - это Use case или варианты использования. В плане разработки именно функциональных требований является
универсальным средством. Варианты использования позволяет эффективно
взаимодействовать со всеми стейхолдерами и сформировывать их требования к
функциональности системы. Диаграммы вариантов использования (см. Рисунок 7)
показывают связи с внешними системами и пользователями, а так же определяют
границы решения.
Рисунок 7 Пример варианта использования
Анализ
требований
После выявления функциональных требований начинается этап их анализа.
Данная фаза разработки включает в себя детализацию требований и исследование их
на предмет ошибок и недочетов.
Цель данного процесса - гарантия понимания требований со стороны
стейкхолдеров, а также качественное и подробное описание функционала будущей
системы. Всё это является основой для реалистичной оценки затрат на проект.
Согласно К. Вигерсу анализ требований включает в себя
следующие процессы: их детализацию, визуальное моделирование, создание
пользовательского интерфейса, определение приоритетов требований, анализ
осуществимости, создание сценариев использования.
Создание сценариев использование является общепризнанным универсальным
способом анализа требований. Сценарии использования системы представляют собой
совокупность последовательных результатов (или достигнутых состояний),
полученных в хронологическом порядке. Данная последовательность получения
сценария использования системы в будущем позволяет стейкхолдерам проигрывать
всевозможные варианты развития событий, проверять функционал, находить «дыры» в
функционале ПО.
Часто для лучшего понимания требований информацию лучше преподносить
несколькими способами, к примеру, в текстовой и графической форме. Комбинация
видов представления функциональных требований позволяет не только увидеть
полную картину создаваемой системы и гарантировать понимание со стороны
заинтересованных лиц, но и выявить ошибки и особенности, не заметные при
представлении только одним способом.
К моделям визуального представления данных в контексте функциональных
требований относят:
· Диаграммы перехода состояний (STD)
· Диаграммы вариантов использования
· Диаграммы взаимодействия
· Блок-схемы
· Модель бизнес-процессов (IDEF0, IDEF3,
BPMN и т.д.)
· Дерево решений
· Нестандартные приемы моделирования
Для оптимизации процесса разработки моделей анализа используются
коммерческие инструменты автоматизированного проектирования ПО. Так называемые CASE средства верхнего уровня включают в
себя такие программы как Visio,
Enterprise architect, ARIS и множество других. Базовым фактором выбора
инструментария организацией являются:
. Цели моделирования
. Удобство использования
. Применение стандартных методологий
. Удобство эксплуатации
. Трудоемкость (Фактор определяет трудоемкость освоения CASE средства)
На основе требований можно составить таблицу соответствия пожеланий
стейкхолдеров и визуального средства моделирования (см. Таблица 8)
Таблица 8 Привязка пожеланий клиента к компонентам модели
анализа
|
Тип слова
|
Примеры
|
Модели анализа
|
|
Существительные
|
Люди, организации
|
Действующие лица (диаграммы вариантов использования) Модель
состояний
|
|
Глаголы
|
Действия, задачи, которые пользователь может выполнить или
события, которые могут произойти
|
Варианты использования Диаграммы перехода состояний Схема
БП
|
К визуальным средствам представления информации так же относится и
прототипирование, которое было описано выше как стратегия выявления требований
стейкхолдеров. Действительно, данный метод универсален и используется и как
метод выявления, и детализации, и анализа требований. Ниже (см. Рисунок 8) схематично
демонстрируется ценность созданных прототипов в процессе разработки требований
в общем процессе разработки ПО.
Рисунок 8 Несколько возможных способов использования
прототипов в процессе разработки ПО
При описании процессов детализации, определения и сбора требований нельзя
пропустить такой метод анализа как их приоритезация. Очень часто при разработке
продукта не обращают внимания на этот важный процесс, а ведь в условиях жестких
сроков и нехватки ресурсов менеджеры проектов сталкиваются с необходимостью
исключить какие-то требования из первой версии продукта. С целью минимизации
рисков и поддержании высокого уровня удовлетворенности заказчиков необходимо
определиться с приоритетом требований еще «на берегу». В литературе приводится
огромное количество методов определения приоритетов для функциональных
требований к системе, но всех их объединяет одно: цель данного процесса -
отфильтровать существенные требования от несущественных. В основном все методы
приоритезации основываются на следующих факторах:
. Финансовая отдача от реализации того или иного требования (Но
существует проблема в размытости оценки доходности от каждого реализованного
требования)
. Польза для клиентов
. Стратегические цели компании
В общем и целом, можно сделать вывод, что приоритеты и ценности
требований для каждой компании могут быть совершенно разными, сам процесс
приоритезации - довольно сложный и «муторный», но необходимый в условиях
жестких сроков.
Итак, остановимся поподробнее на такой технике расстановки приоритетов
требований как матрица Эйзенхауэра. Внешне матрица представляет собой четыре
квадрата, которые получаются при пересечении оси «Важно - Не важно» с осью
«Срочно - Не срочно» (см. Рисунок 9).
|
СРОЧНО И ВАЖНО
|
ВАЖНО И НЕ СРОЧНО
|
|
СРОЧНО И НЕ ВЖНО
|
НЕ СРОЧНО И НЕ ВАЖНО
|
Рисунок 9 Матрица Эйзенхаура
Те требования, которые попадают в левую верхнюю область «Срочно и важно»
- Это требования первостепенной важности, которые необходимо реализовать в
первой версии продукта. Без них пропадет вся ценность продукта, и реализация
данных требований не предполагается на более поздних стадиях.
В правом верхнем углу располагаются требования, с реализацией которых
можно повременить, но, тем не менее, реализация их не подвергается сомнениям.
Со стороны менеджмента, необходимо особое внимание именно за этим приоритетом
требований, т.к. есть риск того, что они попадут в категорию «Срочных и
важных», что, в свою очередь, может привести к срыву сроков проекта.
«Срочные и не важные» характеризуют собой тот тип требований, который
никак не приближает к достижению необходимого результата, и их реализация
обосновывается фразой «делать, ради того, чтобы делать».
«Не срочные и не важные» - те требования, реализация которых никак не
влияет на ход проекта или ценность получаемого продукта, могут быть реализованы
в последней версии продукта, либо же не реализованы вообще.
Далее рассмотрим Модель Кано, так же применяемую в целях приоритезации
требований. Главной целью метода является выделение и распределение полного
спектра требований потребителей по приоритетам.
Кано смог выделить пять типов реакций - от неприязни до восторга, и создал
графические модели. На ось Y Кано выводит эмоциональную составляющую
потребителя, а по оси X Кано представил степень сложности продукта. Таким
образом, эмоциональная реакция потребителя напрямую зависит от того, насколько
сложна и в какой степени представлена характеристика.
Рассмотрим пять типов эмоциональной реакции Кано:
1. «Привлекательные характеристики». Привлекательные характеристики чаще
всего вызывают у потребителя чувства удовлетворения и восхищения. В худшем
случае, если таких характеристик нет, то пользователь остается нейтральным во
мнении. Для того чтобы выявить характеристики подобного типа - необходимо
провести исследования.
Рисунок 10
2. «Одномерные характеристики». Подобные характеристики чаще всего
вызывают удовлетворение, если они есть, и полное неудовлетворение, если их нет.
Линейная зависимость применяется для базовых характеристик, таких как: простота
использования, цена, безопасность.
Рисунок 11
3. «Обязательные характеристики». Проще говоря, это характеристики,
которые обязательно должны быть в продукте, по мнению пользователей. Естественно,
если делать акцент на подобных характеристиках, то это приведет к замедлению
эмоциональной составляющей потребителя.
Рисунок 12
4. «Неважные характеристики». Наличие неважных характеристик, чаще
всего, никак не влияет на потребителя. Уровень удовлетворенности - нейтрален, а
отдача от таких вложений - низкая.
Рисунок 13
5. «Нежелательные характеристики». Если в продукте присутствуют
нежелательные характеристики, то сводится на «Нет» положительное влияние
привлекательных характеристик.
Рисунок 14
Безусловно, все люди по-разному реагируют на характеристики продукции.
Однако поиск закономерности в различных реакциях может дать полезную информацию
при разработке требований.
Анализ данных Кано проводят выявления различных типажей. Подобное
выделение типажей по группам поможет создать профили реакции для каждого из
них. Дальше необходимо рассмотреть различия в реакциях на каждую характеристику
продукта.
Для итогового определения, какие характеристики включать в продукт, есть
три оптимальных метода:
. Анкетирование.
После демонстрации характеристики продукта, пользователя
просят указать, насколько ему важна данная характеристика по 9-бальной шкале от
«совсем не важно» до «крайне важно»;
. Статистический анализ Кано.
Сравнение результатов для данных характеристик;
3. Визуализация. Воссоздание диаграммы результатов анализа при
рассмотрении набора характеристик.
Подводя итог, графики Кано наглядно показывают: «привлекательные» и
«одномерные» характеристики - те две категории, которые должны вызвать
восхищение и обеспечить удовлетворение клиента. Именно на этих характеристиках
сегодня сделан акцент у наиболее успешных продуктов.
Документирование
Каждый из процессов разработки нуждается в документации, т.к. цель
каждого из них - выявление, детализация и анализ требований. Соответственно
ожидаемым результатом всегда будут являться правильно задокументированные
решения.
Изначально необходимо определиться с используемой структурой описания
функциональных требований. Обычно используются стандартные шаблоны организаций.
Шаблоны - согласованная структура, которая позволяет фиксировать описания
необходимой функциональности, а также остальную информацию, связанную с
требованиями [1].
Теория выделяет следующие способы представления требований:
· Документирование требований при помощи структурированного
естественного языка
· Графические модели
· Формальные спецификации, в которых требования определены с
помощью формул и математического языка
Стандартно в разработке требований применяется комбинация первого и
второго типов документирования. Описание функциональных требований чаще всего
приводится в документах: сценарии использования системы, функциональные
требования к системе или функциональная спецификация. Данные документы играют
важную роль ввиду следующих характеристик:
- дают различным участникам проекта представление о
разрабатываемом продукте;
- помогают при создании сценариев тестирования;
- являются основой для написания инструкций пользователей
системы;
- являются основой для написания обучаемых материалов;
- позволяют юристам провести проверку требования на
соответствие существующим законам и постановлениям.
К. Вигерс выделяет следующий универсальный набор требований к
функциональной спецификации:
. Полнота - Ни одно требование не должно быть упущено
. Согласованность - Отсутствие конфликтов между
задокументированными требованиями
. Способность к модификации - Каждое требование должно иметь свой
уникальный идентификатор в целях управления изменениями требований
. Трассируемость или возможность для анализа
Конечно, очень сложно создать документ, отвечающий всем этим требованиям,
но, если помнить о них при написании требований, велика вероятность того, что
документ получится более качественным. Конечная версия задокументированных
требований должна быть ясной и понятной для разработчиков и заинтересованных
лиц. Независимо от способов написания спецификации, все требования должны иметь
свой уникальный идентификатор и источник требований (Варианты использования,
бизнес-требование и т.д.). Наличие источников требований поможет в их
прояснении и оптимизации процесса управления, а уникальное наименование - в
отслеживании и фиксации необходимых изменений.
Согласование
требований
Далее детально рассмотрим процесс верификации требований. Следует
отметить, что это не отдельный заключительный этап после сбора, анализа и
документирования, а итерационный, который может повторяться после каждого из
перечисленных выше этапов. Целью утверждения требований является:
· Гарантия верно описанных требований к продукту
· Достоверность того что, задокументированные требования
являются однозначными, полными, корректными, приоритетными, ясными и не
противоречат друг другу
· Обеспечение качественной основы для дизайна пользовательского
интерфейса и сборки программного обеспечения
Способами утверждения можно выделить:
- Экспертная оценка
o Оценка «за столом» - проверкой занимается один коллега
o Коллективная проверка - проверкой параллельно занимаются
несколько коллег
o Критический анализ - официальное представление комментариев
по предоставленному автору продукту.
- Тестирование требований
o Создание тестов, испытаний и демонстрация возможностей могут
являться частью стратегии проверки функциональных требований, т.к. их главным
критерием все-таки является выполнимость. Действительно, если требование нельзя
проверить тем или иным путем, то как это можно назвать требованием? Оно должно
быть легким для понимания и его выполнение должно быть легко демонстрируемо.
При написании вариантов тестирования на основании задокументированных
требований вы не сможете описать ожидаемую реакцию системы при нечетких и
двусмысленных функциональных требованиях.
По результатам утверждения обычно определяется базовая версия требований.
В контексте данного исследования базовой версией считается принятая базовая
версия требования (т.е. документ уже прошел официальную экспертизу и
согласован). Она определяет набор функциональных требований, которые
разработчики обязуются разработать к выбранному релизу.
Управление
требованиями
Этап управления требованиями сопровождает весь этап разработки
программного продукта. Согласно RUP, управление требованиями - это
систематический подход к выявлению, организации и документированию требований к
системе, а также установка и поддержание соглашения между клиентом и группой
разработки по поводу изменений требований к системе [5]. Управление
требованиями - это в первую очередь управление изменениями. Одно изменение, как
правило, влияет на изменение одного или нескольких требований. Однако влияние
любого изменения сложно оценить, а без оценки невозможно предсказать каким
образом оно повлияет на рамки проекта.
Основные проблемы, возникающие при управлении требованиями:
- Проблемы с контролем изменений
- Проблемы с контролем хода работ
На этапе разработки функциональных требований всегда присутствует период
интенсивных изменений, который обычно приходится на начало проекта. Очевидно,
что в этот временной отрезок чаще всего не применяется формальная процедура
управления изменениями. Однако главное - это не пропустить момент, когда
требования становятся более стабильными. После того, как определена базовая
версия требований, процесс изменения должен происходить по установленному
регламенту. Это сделано для того, чтобы не подвергать требования хаотическим
изменениям просто из-за мнения какого-либо из участников проекта. В этих целях
предусмотрена формальная процедура, когда изменения вначале предлагаются, затем
происходит оценка его влияния и принимается решение по поводу принятия или
отказа от данного изменения. Диаграмма состояний статуса согласования изменений
приведена на рисунке ниже (см. Рисунок 15).
Рисунок 15 Диаграмма состояний статуса согласования
После формирования официального запроса на изменение, процесс оформления
решения относительно него чаще всего требует участия группы по контролю
изменений или руководителя проекта. Чаще всего сам регламент изменения
требований рознится от проекта к проекту и представлен в документе «Устав
проекта». Унифицированная модель процесса разработки требований в контексте
изменений приведена на Рисунке 16.
Рисунок 16 Процесс разработки требований в контексте
изменений
Для успешного мониторинга процесса разработки управлением требованиями на
ранних стадиях, связанных с анкетированием, проведением интервью, семинаров, а
также документированием их результатов достаточно просто контролировать данные
задачи в процессе их выполнения. Для остальных же задач в рамках разработки
требований можно определить следующие контрольные точки:
- определение структуры спецификаций
При сформированной структуре спецификации визуально достаточно легко
проследить, как требования уже определены, а какие разделы в структуре все еще
пустуют.
- определение атрибутов каждого из требований (критичность,
приоритет, владелец, статус и т.д.)
Использование атрибутов делает процесс разработки требованиями более
удобным и управляемым.
Процесс управления требованиями базируется на таких процедурах, как:
- Обозначение основной версии требований
- Управление и контроль всех версий требований
- Оценка предлагаемого изменения до его принятия
- Включение утвержденных изменений в проект согласно регламенту
- Отслеживание статуса требований и их изменения в течение
всего проекта
- Использование средств управления требованиями
В предыдущем разделе достаточно подробно были описаны перечни задач в
рамках разработки требований, которые, очевидно, являются основополагающими для
процесса управления требованиями. Второй фактор, от которого зависит этот
процесс - тип организации-заказчика. В теории выделяют 3 основных типа[2]:
. Организация-покупатель - Система приобретается и используется
для собственных нужд. Главная задача организаций данного типа - разработка и
управление пользовательскими требованиями, которые впоследствии используются
для приемки системы
. Организация-поставщик - Отвечает запросам организации-покупателя
или вышестоящей организации-поставщика. Организации такого типа обычно получают
входящие требования и на их основе разрабатывают системные требования
. Организация-производитель - Организация, которая разрабатывает и
продает продукт. Требования к продукту в организации данного типа формируются
под влиянием рынка, а сбором требований чаще всего занимается отдел маркетинга.
В связи со спецификой данного исследования, в контексте управления
требованиями будет рассмотрен второй тип организации. Итак, применительно к
организации-поставщику выделяются главные особенности процесса управления
требованиями:
- Контроль хода выполнения работ направлен в основном на оценку
объема и качества производимого продукта. Это позволяет своевременно принимать
корректирующие действия в случае отставания по запланированным срокам.
Например, в таком случае руководитель может изменить срок выполнения
промежуточных задач или перераспределить ресурсы между задачами. Еще одним
важным процессом контроля является актуализация всей проектной документации.
- Процесс изменения требований не особо отличается от
стандартного, описанного выше. После оценки влияния изменения, принимается
решения на уровне управляющего комитета о принятии или отклонении предложенного
требования. Принятие решения о возможности включения дополнительных затрат на
реализацию проводится совместно усилиями Заказчика и Поставщика.
Сегодня для эффективного управления требованиями проектной команде
необходимо иметь хороший инструментарий. На данный момент на рынке существует
множество решений. Отметим наиболее распространенные из них: IBM Rational Requisite Pro, Telelogic DOORS, Borland Caliber RM, Redmine. Ниже
приведена сравнительная таблица инструментов управления требованиями (см.
Рисунок 17)
Рисунок 17 Сравнительная таблица инструментов управления
требованиями
Из таблицы видно, что каждая система обладает определенными достоинствами
и недостатками. Для использования в крупных и сложных проектах становится рациональным
использование коммерческих СУТ. При грамотном использовании они позволяют легче
обнаруживать ошибки на ранних этапах проектирования и оценивать влияние
изменений на систему, возможность их реализации, сроки и стоимость. Однако в
небольших или некоммерческих проектах бывает удобнее и выгоднее использовать
бесплатные и легковесные системы, такие как Redmine.
Суммируя все вышеперечисленное, можно отметить следующие основные
факторы, обеспечивающие эффективность процесса управления требованиями:
. Наличие связей (трассируемость) между требованиями
. Актуальность проектной документации
. Хороший инструментарий
Сравнительный
анализ методов разработки функциональных требований
Подводя итоги касаемо выявленных методов разработки, стоит отметить, что
методы разработки могут различаться от проекта к проекту и эффективность их
оценивается исходя из разнообразных характеристик. Основным циклом разработки
требований можно считать процесс выявления и анализа требований. Методы
документирования и управления требованиями можно считать сопровождающими
процессами. Именно для того, чтобы в зависимости от необходимых характеристик:
уровня бюджета, временных ресурсов и т.д. можно было выбрать подходящую
стратегию разработки требований, был осуществлен сравнительный анализ методик.
Сравнительный анализ представляет собой матрицу (см. Таблица 9), в
которой указаны методики сбора требований, методики анализа требований и
аспекты, по которым можно их сравнить. Оценка проведена исключительно в разрезе
теоретической знаний применимо к каскадной модели управления проектами. Вся
таблица будет заполнена значениями «+», «-», «+/-». Далее представлены критерии
разбалловки.
Ключевые показатели, по которым будет производиться оценка, следующие:
Для методик сбора требований: оценивается относительная затрата временных
ресурсов на применение выбранной модели. Значение будет заполнено на основании
критического анализа литературы, при временных затратах больше недели, ставится
минус, иначе - плюс.
Для методик анализа требований: оценивается относительная затрата
временных ресурсов на проведение данного метода анализа. Значение заполняется
на основании теоритических данных. При относительно небольших временных
затратах на применение методики ставится «+», иначе «-».
2. Скорость получения результатов
Для методик сбора требований: оценивается скорость получения обратной
связи от заинтересованного лица. При наличии личного контакта со стейкхолдером
или наличии быстрого способа получения результатов, ставится «+», иначе «-».
Для методик анализа требований: оценивается скорость понимания методик
анализа со стороны заказчика и предоставление замечаний/ комментариев/ обратной
связи по ним. В случае относительной скорости описанного процесса ставится
плюс, иначе - минус.
3. Бюджетность
Для методик сбора требований: оценивается затрата денежных ресурсов на
применение выбранного метода. Так как этот критерий довольно относителен, для
его оценки будет применяться его теоретическая оценка и затраты временных
ресурсов. При высоких затратах временных ресурсов и теоретическим
подтверждением больших денежных затрат ставится «-», при относительно низких
затратах временных ресурсов и теоретическим подтверждением низкого уровня
денежных затрат, ставится «+».
Для методик анализа требований: для оценки применяется теоритическое
обоснование относительной затратности того или иного метода анализа. При
высоких затратах временных ресурсов и теоретическим подтверждением больших
денежных затрат ставится «-», при относительно низких затратах временных
ресурсов и теоретическим подтверждением низкого уровня денежных затрат,
ставится «+».
4. Фокус на функциональных требованиях
Для методик сбора требований: оценивается применимость выбранного метода
для прояснения функциональных требований. Если метод применим, ставится плюс,
если же нет - минус.
Для методик анализа требований: если выбранный метод зарекомендовал себя
как хороший способ анализа функциональности системы, ставится плюс, иначе -
минус.
5. Достоверность и качественность получаемой информации
Для методик сбора требований: оценивается качество предоставляемой
информации. Если предоставляемая информация является недостаточной для
прояснения функциональных требований, или недостоверной ввиду отсутствия
мотивация заинтересованных сторон - ставится «-», иначе «+».
Для методик анализа требований: Если предоставляемая информация является
недостаточной для прояснения функциональных требований, или недостоверной ввиду
отсутствия мотивация заинтересованных сторон - ставится «-», иначе «+».
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,
документация заменяемой системы и инструкции пользователей касательно
обсуждаемых процессов. Всё это позволяло сформировать концепцию и презентовать
ее заинтересованным в проекте лицам. Более того, именно такая
последовательность и сочетание методов позволяет максимально эффективно
формировать представление о необходимой функциональности системы. Это так ввиду
того, что чаще всего пользователям трудно определиться «с нуля» с тем, что
именно они хотят видеть в системе, и, когда аналитики проводят встречу с
заготовленными материалами, предложениями, стейкхолдерам проще донести своё
видение продукта, подтвердить или опровергнуть детали разработанного
требования, а также найти «дыры» в функциональности. Таким образом, данная
стратегия частично покрывает два процесса: формирование и анализ функциональных
требований. Далее перечислены некоторые факторы успешного проведения семинаров,
выявленные в ходе проекта:
- всегда стоит придерживаться определенной структуры семинара;
- участники семинара должны быть уполномочены принимать решения
по модификации требований и формирования новых;
- участники семинара всегда должны быть подготовлены к семинару
и ознакомлены с повесткой встречи и прилагаемыми материалами;
- все участники семинара должны понимать предметную область и
«говорить на одном языке». В этих целях обычно утверждается Глоссарий;
- все принятые решения должны быть зафиксированы и согласованы
ответственными лицами со стороны заказчика в обязательном порядке;
Метод
анализа и моделирования требований
Основные задачи аналитика на данном этапе - выявление конфликтующих
требований и областей, требующих детализации, а также определение
функциональных требований в соответствии с запросами разработчиков. Более того,
на данном этапе разработки требований важно привести все требования в
соответствии со следующими критериями:
. Каждое требование должно быть уникально
. Каждое требование должно быть представлено четко и ясно.
. Каждое требование должно быть атомарным
. Требования должны быть представлены последовательно
. Каждое требование должно быть выполнимо
. Каждое требование должно быть недвусмысленно
. Каждое требование должно быть проверяемо
. Каждое требование должно быть отслеживаемо
. Отсутствие каких-либо неопределенных терминов, таких как «и
т.д., и т.п., возможно, универсальный» из-за того, что из-за таких «лазеек»
может быть очень сильно увеличен объем требования, а, следовательно, и скоуп
работ по проекту.
При фиксировании новых требований к функциональности системы, компанией
проводился 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: #"897622.files/image026.gif">
Экран «Mx Loyalty - Клиент > Обращения > Мои Обращения»
Приложение
Г
Макеты
спецификации полей экранов и используемых кнопок
Шаблон спецификации полей экрана
|
Название поля (рус)
|
Тип
|
Режим доступа (условие)
|
Обяз-ть
|
Комментарий
|
По умолч. Отобр-ся
|
|
ID обращения Maxxing
|
Строка
|
RO
|
Да
|
Служебный идентификатор обращения в системе Maxxing
|
Да
|
Спецификация используемых кнопок экрана
|
Кнопка / Триггер процедуры
|
Доступность
|
Тип реакции
|
Логика исполнения
|
Результат / текст сообщения в случае ошибки
|
|
Кнопки
|
|
|
Всегда
|
Открытие окна
|
Открыть форму выбранной карточки обращения
|
Открыта форма «Карточка обращения»
|
Приложение
Д
Алгоритм выбора обращения для назначения