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

К визуальным средствам представления информации так же относится и прототипирование, которое было описано выше как стратегия выявления требований стейкхолдеров. Действительно, данный метод универсален и используется и как метод выявления, и детализации, и анализа требований. Ниже (см. Рисунок 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 Процесс разработки требований в контексте изменений

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

-       определение структуры спецификаций

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

-       определение атрибутов каждого из требований (критичность, приоритет, владелец, статус и т.д.)

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

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

-       Обозначение основной версии требований

-       Управление и контроль всех версий требований

-       Оценка предлагаемого изменения до его принятия

-       Включение утвержденных изменений в проект согласно регламенту

-       Отслеживание статуса требований и их изменения в течение всего проекта

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