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

Рисунок 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 Привязка пожеланий клиента к компонентам модели анализа