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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

·        Сценарии использования (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 и т.д. Прототипы применяются для презентации пользователям и заинтересованным лицам интерфейса без привлечения для работы с ними. Соответственно, они могут быть описаны следующими характеристиками:

ü  Низкобюджетные

ü  Низкотехнологичные

ü  Быстроконструируемые

ü  Позволяют попробовать сделать шаг к разработке продукта, практически не рискуя