Проектные технологии: как понять требования пользователя

Сегодня мы начинаем серию обзорных статей о проектных технологиях в ИТ-сфере. И начнем с рассмотрения вопроса – как понять требования пользователя.

Выделяют следующие способы анализа пользовательских требований:

Варианты использования ПО\системы;
Пользовательские истории.

При этом важными критериями являются:

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

Варианты использования (use case) — описывает последовательность взаимодействия системы и пользователя, в результате которого последний получает желаемый результат.

Например,

Пользовательская история — короткое, простое описание функции с точки зрения человека, которому нужна эта новая возможность.

Например,

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

Пользовательские истории можно делить на более мелкие итерации – по срокам, по приоритетам и т.д.

Для способа с применением варианта использования продукта характерны:

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

Варианты использования могут быть определены через:

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

Пример вариантов использования и соответствующих пользовательских историй: