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

ü  Позволяют однозначно определить требования

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

Главный минус - фокус заинтересованных сторон не на том, что надо сделать, а как именно. На это могут уходить колоссальные временные ресурсы.

Таблица 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].