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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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