Размещено на http://www.allbest.ru/

• Оглавление
• Введение
• 1. Теоретические основы исследования
• 1.1 Ключевые термины
• 1.2 Основные методы разработки и управление требованиями
• 2. Практическое исследование
• 2.1 Исходные данные проекта
• 2.2 Сбор и систематизация информации о процессе разработки функциональных требований
• 3. Формирование стратегии разработки функциональных требований
• Заключение
• Список использованной литературы
• Приложения


Введение

На сегодняшний день сфера розничной торговли остается одной из динамично развивающихся. Сейчас уже стало очевидно, что информационные технологии - это не просто приложение к потребительскому опыту, а его неотъемлемая часть.

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

Актуальность данной работы определяется неугасающей потребностью организаций в успешном исходе проекта, минимизации рисков и соблюдении сроков при внедрении программного продукта. Более того, при детальном рассмотрении процесса внедрения любой систем, в том числе и CRM, становится очевидным, что самым важным и основополагающим шагом является формирование функциональных требований к программному продукту. Корректно сформулированные, качественно задокументированные требования - основополагающий фактор успеха всего проекта.

Процесс разработки требований подразумевает под собой основу для планирования проекта, управления рисками, приемочного тестирования, согласований и управления изменениями, а также влияет на все остальные этапы жизненного цикла ПО (программного обеспечения). Следовательно, плохо организованные, несогласованные с потребностями заинтересованных сторон, плохо написанные требования в большинстве случаев являются причиной «смерти» проектов. Действительно, ошибки, допущенные на стадии формирования требований, составляют от 40 до 60% всех дефектов проекта, и обходятся гораздо дороже, чем если бы были тщательно проработаны на стадии анализа [1]. Во избежание описанных выше проблем, очень важно использовать эффективные методы разработки требований.

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

Объектом данного исследования является процесс формирования функциональных требований к CRM системе в сфере retail, предметом изучения - разнообразные методы разработки требований.

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

1.Изучение понятия и сущности функциональных требований;

2.Изучение процесса разработки функциональных требований;

3.Проведение исследования основных методов разработки требований;

4.Проведение сравнительного анализа методов разработки требований;

5.Выявление существующих методов разработки функциональных требований на примере Организации;

6.Формирование практических рекомендаций по разработке функциональных требований при внедрении 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 Основные методы разработки и управление требованиями

Методы разработки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Сценарии использования (Use Case) (см. Рисунок 3)

· Изучение существующей описательной документации

В первую очередь рассмотрим такой метод выявления требований, как проведение интервью. Интервью - это исключительно психологическая задача, не имеющая ничего общего с организационными или техническими аспектами разработки систем[2]. Очень важно, чтобы интервьюер разбирался в предметной области и относился к своей работе серьезно и как можно чаще задавал наводящие вопросы. В течение самого диалога эффективным методом сбора требований будет пошаговое описание процесса работы опрашиваемого представителя заинтересованной стороны. Все обсужденные моменты необходимо зафиксировать, и представить для рецензирования либо в виде протокола, либо в виде диаграммы вариантов использования и т.д. Процесс проведения интервью см. Рисунок 4.



Рисунок 3 Пример диаграммы вариантов использования «Заказ товара»

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

· Интервью проводится с представителем каждой из заинтересованных сторон

· Интервью всегда должно быть задокументировано и предоставлено на проверку

· Интервьюер должен стимулировать собеседника к обсуждению требований

· Интервьюер должен попытаться выяснить степень важности обсуждаемых требований

· Обсуждение должно быть построено по принципу «От общего к частному»

· Интервьюер должен четко определять «владельцев» требований

· Во время обсуждения интервьюер не должен погружаться в специфику непосредственной разработки пользовательских требований

Рисунок 4 Процесс «Проведение интервью»

Результатом данного этапа должно стать согласованное представление о функциональных потребностях стейкхолдеров.

Следующая эффективная стратегия по сбору требований - проведение семинаров. Его отличительная черта от той же стратегии интервьюирования - относительная быстрота выявления требований.

Рисунок 5 Процесс получения пользовательский требований посредством проведения семинаров

Несмотря на то, на каком этапе разработки функциональных требований проводится данный семинар, все его участники должны быть к нему подготовлены. В случае если существует предварительная версия функциональных требований, над которой вы будете работать, она должна быть выслана за день до назначенной встречи. Если же таковой версии нет, то необходимо начать с того, что все участники встречи как представители заинтересованных сторон должны подготовить для будущей системы свои требования/ варианты использования/ сценарии и т.д. Процесс получения функциональных требований схематически изображен на рис. 5.

Эффективность данного процесса определяется взаимодействием различных групп заинтересованных пользователей. Оно может быть организовано различными способами:

1. В режиме online фиксации и рецензирования (при наличии проектора) с привлечением всех участников семинара

2. Разделением всех участников на небольшие группы и предоставлением им части набора требований для дальнейшего анализа и рецензирования. Далее уточненный каждой группой набор требований предоставляется для ознакомления, анализа и рецензирования всему коллективу. При использовании этого подхода к организации семинара работа над требованиями к проекту может продолжаться 3-4 дня [2].

Таблица 3 Преимущества и недостатки проведения семинаров

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

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

1. Формулировка многоальтернативных вопросов - Подразумевают под собой опрос свободной формы, который может расширяться комментариями анкетируемого

2. Формулировка рейтинговых вопросов - Подразумевают под собой опросы с преопределенными ответами как «абсолютно согласен», «не согласен», «абсолютно не согласен», «не знаю» и т.д.

3. Формулировка вопросов с ранжированием - Подразумевают под собой предоставление ответов как упорядоченного списка путем присваивания каждому пункту своего порядкового номера

Таблица 4 Преимущества и недостатки проведения анкетирования

Плюсы анкетирования	Минусы анкетирования
Высокая скорость получения результатов	Методика не подходит для выявления неясных требований
Бюджетность	Сложность выявления всех необходимых вопросов при составлении анкеты

Метод изучения существующей описательной документации может быть использована организацией только при наличии в компании Заказчика актуальных версий, которые могут так или иначе помочь в определении функциональных требований заказчика. Например, могут использоваться такие документы как регламенты описания процессов, структура организации, процессы as is, процессы to be, стандарты организации, различного рода инструкции, шаблоны документов и т.д. Данная методика может быть эффективна при автоматизации устоявшихся регламентированных БП (бизнес процессов).

Таблица 5 Преимущества и недостатки процесса изучения документации

Плюсы изучения документации	Минусы изучения документации
Быстрое получение информации	Данный способ не применим при наличии в компании Заказчика только базовых документов (или их полном отсутствии), а так же при отсутствии актуальных версий документов

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

Таблица 6 Преимущества и недостатки процесса изучения работы персонала

Плюсы изучения работы персонала	Минусы изучения работы персонала
Быстрое получение информации	В процессе наблюдения могут быть упущены некоторые альтернативные сценарии бизнес процесса.
Позволяет наглядно увидеть проблему и разработать наиболее оптимальный вариант ее решения.	Трудно применим на секретных предприятиях или опасных (вредных) производствах.
Помогает наиболее точно собрать требования, наблюдая за работой сотрудников.

Прототипирование традиционно выделяется как один из самых эффективных методов выявления требований. Это так, потому что образное мышление позволяет большинству людей быстрее воспринимать информацию. Целями данной стратегии являются:

1. Устранение неясных требований на ранних стадиях разработки - Наглядная версия системы позволяет заинтересованным сторонам прояснить и завершить процесс формулирования функциональных требований.

2. Выбор единственного решения из многих концепутальных - Макет системы позволяет заинтересованным сторонам исследовать альтернативные варианты реализации требований, оптимизировать удобство взаимодействия пользователя с системой.

На данный момент существует значительное количество видов прототипов, но все их объединяет то, что все они только часть или вообще образец разрабатываемого продукта. Прототипы могут быть как действующими моделями или статичными образцами, детализированным изображением экрана или эскиз интерфейса, имитацией или подражанием. Далее рассмотрим классификации прототипов, подходящие для выявления функциональных требований. Итак, горизонтальный (поведенческий) прототип - он позволяет смоделировать интерфейс пользователя, и при этом не затрагивает ни логику обработки, ни базу данных. Данный вид прототипа демонстрирует пользователю функциональные возможности системы, особенности пользовательского интерфейса (элементы управления, цветовая гамма, расположение форм) и структуру навигации. Следующий вид прототипа, применимый к разработке функциональных требований - одноразовый (исследовательский). Главной его особенностью является быстрота макетирования тех или иных аспектов системы, но при этом необходимо следить за тем, чтобы «сырой код» не стал частью целевой системы. К. Вигерс определяет следующую схему перехода от исследовательского прототипа к детализированному дизайну пользовательского интерфейса (см. Рисунок 6). Данный вид эффективен в случае неясности, двусмысленности, неполноты и неопределенности функциональных требований. Более того, такой метод анализа требований позволяет сэкономить денежные ресурсы в связи с итерационным методом уточнения пользовательского интерфейса, так как при резком переходе от описания вариантов использования к финальному детализированному дизайну может возникнуть достаточно большое количество ошибок, которое повлечет за собой выявление ошибок в требованиях и, как следствие, переделки продукта.

Рисунок 6 Схема перехода от исследовательского прототипа к детализированному дизайну

Следующими исследуемыми в контексте данной работы прототипами будут бумажные или электронные. Для удобства создания последних применяются различные инструменты, как Microsoft Visio, ConceptDrawPro, Pidoco, Draw.io и т.д. Прототипы применяются для презентации пользователям и заинтересованным лицам интерфейса без привлечения для работы с ними. Соответственно, они могут быть описаны следующими характеристиками:

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

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

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

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

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

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

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

Таблица 7 Преимущества и недостатки процесса прототипирования

Плюсы прототипирования	Минусы прототипирования
Быстрая обратная связь	Фокус на нефункциональных требованиях
Вовлечение заказчика	Фокус на дизайне
Позволяет наглядно увидеть проблему и разработать наиболее оптимальный вариант ее решения.	При разработке эволюционного прототипа - большие временные затраты
В перспективе помогает разработчикам	Недостаточный анализ
Уменьшение рисков

Самая последняя рассматриваемая в данной работе стратегия сбора функциональных требований - это Use case или варианты использования. В плане разработки именно функциональных требований является универсальным средством. Варианты использования позволяет эффективно взаимодействовать со всеми стейхолдерами и сформировывать их требования к функциональности системы. Диаграммы вариантов использования (см. Рисунок 7) показывают связи с внешними системами и пользователями, а так же определяют границы решения.

Рисунок 7 Пример варианта использования

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

После выявления функциональных требований начинается этап их анализа. Данная фаза разработки включает в себя детализацию требований и исследование их на предмет ошибок и недочетов.

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

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

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

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

К моделям визуального представления данных в контексте функциональных требований относят:

· Диаграммы перехода состояний (STD)

· Диаграммы вариантов использования

· Диаграммы взаимодействия

· Блок-схемы

· Модель бизнес-процессов (IDEF0, IDEF3, BPMN и т.д.)

· Дерево решений

· Нестандартные приемы моделирования

Для оптимизации процесса разработки моделей анализа используются коммерческие инструменты автоматизированного проектирования ПО. Так называемые CASE средства верхнего уровня включают в себя такие программы как Visio, Enterprise architect, ARIS и множество других. Базовым фактором выбора инструментария организацией являются:

1. Цели моделирования

2. Удобство использования

3. Применение стандартных методологий

4. Удобство эксплуатации

5. Трудоемкость (Фактор определяет трудоемкость освоения CASE средства)

На основе требований можно составить таблицу соответствия пожеланий стейкхолдеров и визуального средства моделирования (см. Таблица 8)

Таблица 8 Привязка пожеланий клиента к компонентам модели анализа

Тип слова	Примеры	Модели анализа
Существительные	Люди, организации	Действующие лица (диаграммы вариантов использования) Модель состояний
Глаголы	Действия, задачи, которые пользователь может выполнить или события, которые могут произойти	Варианты использования Диаграммы перехода состояний Схема БП

К визуальным средствам представления информации так же относится и прототипирование, которое было описано выше как стратегия выявления требований стейкхолдеров. Действительно, данный метод универсален и используется и как метод выявления, и детализации, и анализа требований. Ниже (см. Рисунок 8) схематично демонстрируется ценность созданных прототипов в процессе разработки требований в общем процессе разработки ПО.

Рисунок 8 Несколько возможных способов использования прототипов в процессе разработки ПО

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

1. Финансовая отдача от реализации того или иного требования (Но существует проблема в размытости оценки доходности от каждого реализованного требования)

2. Польза для клиентов

3. Стратегические цели компании

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

Итак, остановимся поподробнее на такой технике расстановки приоритетов требований как матрица Эйзенхауэра. Внешне матрица представляет собой четыре квадрата, которые получаются при пересечении оси «Важно - Не важно» с осью «Срочно - Не срочно» (см. Рисунок 9).

СРОЧНО И ВАЖНО	ВАЖНО И НЕ СРОЧНО
СРОЧНО И НЕ ВЖНО	НЕ СРОЧНО И НЕ ВАЖНО

Рисунок 9 Матрица Эйзенхаура



Те требования, которые попадают в левую верхнюю область «Срочно и важно» - Это требования первостепенной важности, которые необходимо реализовать в первой версии продукта. Без них пропадет вся ценность продукта, и реализация данных требований не предполагается на более поздних стадиях.

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

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

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

Далее рассмотрим Модель Кано, так же применяемую в целях приоритезации требований. Главной целью метода является выделение и распределение полного спектра требований потребителей по приоритетам.
Кано смог выделить пять типов реакций - от неприязни до восторга, и создал графические модели. На ось Y Кано выводит эмоциональную составляющую потребителя, а по оси X Кано представил степень сложности продукта. Таким образом, эмоциональная реакция потребителя напрямую зависит от того, насколько сложна и в какой степени представлена характеристика.

Рассмотрим пять типов эмоциональной реакции Кано:

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

Рисунок 10

2. «Одномерные характеристики». Подобные характеристики чаще всего вызывают удовлетворение, если они есть, и полное неудовлетворение, если их нет. Линейная зависимость применяется для базовых характеристик, таких как: простота использования, цена, безопасность.

Рисунок 11

3. «Обязательные характеристики». Проще говоря, это характеристики, которые обязательно должны быть в продукте, по мнению пользователей. Естественно, если делать акцент на подобных характеристиках, то это приведет к замедлению эмоциональной составляющей потребителя.

Рисунок 12



4. «Неважные характеристики». Наличие неважных характеристик, чаще всего, никак не влияет на потребителя. Уровень удовлетворенности - нейтрален, а отдача от таких вложений - низкая.

Рисунок 13

5. «Нежелательные характеристики». Если в продукте присутствуют нежелательные характеристики, то сводится на «Нет» положительное влияние привлекательных характеристик.

Рисунок 14

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

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

Для итогового определения, какие характеристики включать в продукт, есть три оптимальных метода:

1. Анкетирование.

После демонстрации характеристики продукта, пользователя просят указать, насколько ему важна данная характеристика по 9-бальной шкале от «совсем не важно» до «крайне важно»;

2. Статистический анализ Кано.

Сравнение результатов для данных характеристик;

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

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

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

Каждый из процессов разработки нуждается в документации, т.к. цель каждого из них - выявление, детализация и анализ требований. Соответственно ожидаемым результатом всегда будут являться правильно задокументированные решения.

Изначально необходимо определиться с используемой структурой описания функциональных требований. Обычно используются стандартные шаблоны организаций. Шаблоны - согласованная структура, которая позволяет фиксировать описания необходимой функциональности, а также остальную информацию, связанную с требованиями [1].

Теория выделяет следующие способы представления требований:

· Документирование требований при помощи структурированного естественного языка

· Графические модели

· Формальные спецификации, в которых требования определены с помощью формул и математического языка

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

- дают различным участникам проекта представление о разрабатываемом продукте;

- помогают при создании сценариев тестирования;

- являются основой для написания инструкций пользователей системы;

- являются основой для написания обучаемых материалов;

- позволяют юристам провести проверку требования на соответствие существующим законам и постановлениям.

К. Вигерс выделяет следующий универсальный набор требований к функциональной спецификации:

1. Полнота - Ни одно требование не должно быть упущено

2. Согласованность - Отсутствие конфликтов между задокументированными требованиями

3. Способность к модификации - Каждое требование должно иметь свой уникальный идентификатор в целях управления изменениями требований

4. Трассируемость или возможность для анализа

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

Согласование требований

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

· Гарантия верно описанных требований к продукту

· Достоверность того что, задокументированные требования являются однозначными, полными, корректными, приоритетными, ясными и не противоречат друг другу

· Обеспечение качественной основы для дизайна пользовательского интерфейса и сборки программного обеспечения

Способами утверждения можно выделить:

- Экспертная оценка

o Оценка «за столом» - проверкой занимается один коллега

o Коллективная проверка - проверкой параллельно занимаются несколько коллег

o Критический анализ - официальное представление комментариев по предоставленному автору продукту.

- Тестирование требований

o Создание тестов, испытаний и демонстрация возможностей могут являться частью стратегии проверки функциональных требований, т.к. их главным критерием все-таки является выполнимость. Действительно, если требование нельзя проверить тем или иным путем, то как это можно назвать требованием? Оно должно быть легким для понимания и его выполнение должно быть легко демонстрируемо. При написании вариантов тестирования на основании задокументированных требований вы не сможете описать ожидаемую реакцию системы при нечетких и двусмысленных функциональных требованиях.

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

Управление требованиями

Этап управления требованиями сопровождает весь этап разработки программного продукта. Согласно RUP, управление требованиями - это систематический подход к выявлению, организации и документированию требований к системе, а также установка и поддержание соглашения между клиентом и группой разработки по поводу изменений требований к системе [5]. Управление требованиями - это в первую очередь управление изменениями. Одно изменение, как правило, влияет на изменение одного или нескольких требований. Однако влияние любого изменения сложно оценить, а без оценки невозможно предсказать каким образом оно повлияет на рамки проекта.

Основные проблемы, возникающие при управлении требованиями:

- Проблемы с контролем изменений

- Проблемы с контролем хода работ

На этапе разработки функциональных требований всегда присутствует период интенсивных изменений, который обычно приходится на начало проекта. Очевидно, что в этот временной отрезок чаще всего не применяется формальная процедура управления изменениями. Однако главное - это не пропустить момент, когда требования становятся более стабильными. После того, как определена базовая версия требований, процесс изменения должен происходить по установленному регламенту. Это сделано для того, чтобы не подвергать требования хаотическим изменениям просто из-за мнения какого-либо из участников проекта. В этих целях предусмотрена формальная процедура, когда изменения вначале предлагаются, затем происходит оценка его влияния и принимается решение по поводу принятия или отказа от данного изменения. Диаграмма состояний статуса согласования изменений приведена на рисунке ниже (см. Рисунок 15).

Рисунок 15 Диаграмма состояний статуса согласования

После формирования официального запроса на изменение, процесс оформления решения относительно него чаще всего требует участия группы по контролю изменений или руководителя проекта. Чаще всего сам регламент изменения требований рознится от проекта к проекту и представлен в документе «Устав проекта». Унифицированная модель процесса разработки требований в контексте изменений приведена на Рисунке 16.

Рисунок 16 Процесс разработки требований в контексте изменений

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

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

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

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

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

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

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

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

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

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

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

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

В предыдущем разделе достаточно подробно были описаны перечни задач в рамках разработки требований, которые, очевидно, являются основополагающими для процесса управления требованиями. Второй фактор, от которого зависит этот процесс - тип организации-заказчика. В теории выделяют 3 основных типа[2]:

1. Организация-покупатель - Система приобретается и используется для собственных нужд. Главная задача организаций данного типа - разработка и управление пользовательскими требованиями, которые впоследствии используются для приемки системы

2. Организация-поставщик - Отвечает запросам организации-покупателя или вышестоящей организации-поставщика. Организации такого типа обычно получают входящие требования и на их основе разрабатывают системные требования

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

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

- Контроль хода выполнения работ направлен в основном на оценку объема и качества производимого продукта. Это позволяет своевременно принимать корректирующие действия в случае отставания по запланированным срокам. Например, в таком случае руководитель может изменить срок выполнения промежуточных задач или перераспределить ресурсы между задачами. Еще одним важным процессом контроля является актуализация всей проектной документации.

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

Сегодня для эффективного управления требованиями проектной команде необходимо иметь хороший инструментарий. На данный момент на рынке существует множество решений. Отметим наиболее распространенные из них: IBM Rational Requisite Pro, Telelogic DOORS, Borland Caliber RM, Redmine. Ниже приведена сравнительная таблица инструментов управления требованиями (см. Рисунок 17)

Рисунок 17 Сравнительная таблица инструментов управления требованиями

Из таблицы видно, что каждая система обладает определенными достоинствами и недостатками. Для использования в крупных и сложных проектах становится рациональным использование коммерческих СУТ. При грамотном использовании они позволяют легче обнаруживать ошибки на ранних этапах проектирования и оценивать влияние изменений на систему, возможность их реализации, сроки и стоимость. Однако в небольших или некоммерческих проектах бывает удобнее и выгоднее использовать бесплатные и легковесные системы, такие как Redmine.

Суммируя все вышеперечисленное, можно отметить следующие основные факторы, обеспечивающие эффективность процесса управления требованиями:

1. Наличие связей (трассируемость) между требованиями

2. Актуальность проектной документации

3. Хороший инструментарий

Сравнительный анализ методов разработки функциональных требований

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

Сравнительный анализ представляет собой матрицу (см. Таблица 9), в которой указаны методики сбора требований, методики анализа требований и аспекты, по которым можно их сравнить. Оценка проведена исключительно в разрезе теоретической знаний применимо к каскадной модели управления проектами. Вся таблица будет заполнена значениями «+», «-», «+/-». Далее представлены критерии разбалловки.

Ключевые показатели, по которым будет производиться оценка, следующие:

1. Низкие временные затраты

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

Для методик анализа требований: оценивается относительная затрата временных ресурсов на проведение данного метода анализа. Значение заполняется на основании теоритических данных. При относительно небольших временных затратах на применение методики ставится «+», иначе «-».

2. Скорость получения результатов

Для методик сбора требований: оценивается скорость получения обратной связи от заинтересованного лица. При наличии личного контакта со стейкхолдером или наличии быстрого способа получения результатов, ставится «+», иначе «-».

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

3. Бюджетность

Для методик сбора требований: оценивается затрата денежных ресурсов на применение выбранного метода. Так как этот критерий довольно относителен, для его оценки будет применяться его теоретическая оценка и затраты временных ресурсов. При высоких затратах временных ресурсов и теоретическим подтверждением больших денежных затрат ставится «-», при относительно низких затратах временных ресурсов и теоретическим подтверждением низкого уровня денежных затрат, ставится «+».

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

4. Фокус на функциональных требованиях

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

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

5. Достоверность и качественность получаемой информации

Для методик сбора требований: оценивается качество предоставляемой информации. Если предоставляемая информация является недостаточной для прояснения функциональных требований, или недостоверной ввиду отсутствия мотивация заинтересованных сторон - ставится «-», иначе «+».

Для методик анализа требований: Если предоставляемая информация является недостаточной для прояснения функциональных требований, или недостоверной ввиду отсутствия мотивация заинтересованных сторон - ставится «-», иначе «+».