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

Введение

Общее определение требований

Проект является успешным, если он соответствует ожиданиям и потребностям заказчика, а так же поставлен в срок и не превысил бюджет проекта.

Обратим внимание, что когда в исследованиях классифицируют проекты, речь идёт о проектах успешных, превысивших сроки и/или бюджет и проектах неуспешных. Т.е., даже если проект был выполнен в срок, но не соответствует ожиданиям и потребностям заказчика – проект не успешен.

Что бы проект мог соответствовать в первую очередь следует выявить эти самые ожидания и потребности, документировать их, и довести до всех членов команды.

Это делается при помощи группы документов “требования”. Требования – это набор условий, которым должна соответствовать продукт (определение RUP).

Кто и как использует требования?

• Дизайнеры определяют архитектуру и вид системы.
• Программисты разрабатывают код.
• Тестеры проверяют, является ли продукт приемлемым для заказчика.

Если мы вспомним определение проекта из PMI, то проект ВСЕГДА направлен на достижение конкретной цели, как правило, решения какой-то проблемы заказчика. Приемлемость продукта в первую очередь определяется тем, решил ли продукт это проблему (потребность) и решил ли он её способом, приемлемым для заказчика (ожидание).

То есть, первичной задачей является понимание заказчика, его проблем и его точки зрения на применимость того или иного решения.

Какие проблемы часто возникают при попытке организовать работу на основе требований?

• Заказчик получает продукт, но говорит что это не та продукт, который он хотел.

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

• Заказчик говорит, что продукт не решает всех его проблем, а на вопрос “но об этом же нет ничего в требованиях” говорит “дык меня и никто не спрашивал”.

Причина: Не были выявлены все заинтересованные лица (т.н. stakeholder’s), stakeholder’у не был задан правильный вопрос или ответ был неправильно понят.

• Разработчики и/или тестеры принимают решения, основываясь на неверном представлении о том, что необходимо заказчику.

Причина: Требования, даже будучи собранными, не доведены до всех исполнителей в понятном им виде и/или отсутствует контроль за соблюдением требований.

• Исполнители/представители заказчики контактируют напрямую, что в итоге приводит к тому, что проект выходит за оговоренные границы по бюджету или срокам.

Причина: Отсутствует управление требованиями.

Четвертая причина, в общем-то, имеет меньший приоритет, и может быть решена, в том числе за счет effort-based контрактов (т.е. когда оплата идет на основе реально затраченных усилий). Но в случае, если мы имеем жесткий бюджет, мы просто обязаны контролировать любые попытки изменить состав проекта без изменения сроков и бюджета.

Успешные технологии

Существуют успешные технологии работы, так называемые best practices, которые могут быть использованы для решения проблем:

• Итеративная разработка
• Управление требованиями
• Визуальное моделирование

Кратко о каждом:

Итеративная разработка

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

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

• мы можем вынести решение задач с наибольшими рисками в начало проекта и получить работоспособное решение (либо понять, что не получится совсем) (но в любом случае - уменьшить риск, т.е. непредсказуемость) в начале проекта.
• Интеграция и тестирование становятся постоянными, а не отходят к концу проекта.
• (Если заказчик смотрит таки прототипы), мы получаем отзывы заказчика на как можно более ранних этапах, соответственно уменьшаем затраты на их исправление (правило 1:10:100 о затратах на исправление ошибки).
• Облегчаем планирование и проверку, по сути, пользуемся классическим приемом упрощения задачи – декомпозицией.

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

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

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

• Пониманию проблем.
• Выявлению, организации и документированию требований.
• Управлению изменениями.

Визуальное моделирование

Визуальное моделирование позволяет:

• Увидеть структуру и поведение (а 90% информации мы получаем глазами).
• Увидеть, как части становятся целой системой.
• Связать анализ, проектирование и разработку.
• Показывать/скрывать детали по необходимости.
• Даёт язык для однозначной передачи информации.

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

Что такое хорошие требования?

Хорошие требования должны быть:

• Верными: Описывать реальные проблемы заказчика.
• Полными: Описывать все проблемы.
• Целостными (непротиворечивыми): Не должны противоречить одно другому.
• Недвусмысленными: Не должны допускать более одного понимания.
• Проверяемыми: Должна быть возможность проверить их за разумное время/деньги.
• Прослеживаемыми (traceability): Должна быть возможность проследить требования сквозь всю реализацию.
• Изменяемыми: Внесение изменений не должно нарушать структуру и целостность требований.
• Легкими для понимания: Требования ориентированны на понимание заказчиком, девелопером и тестером.

Словарь

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

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

Формирование словаря начинается с началом общения с заказчиком по проекту. Источником терминов служат:

• контракт;
• общение с заказчиком и экспертами;
• информация о предметной области;
• стандарты;

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