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

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

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

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

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

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

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

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

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

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

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

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

* Заказчик говорит, что продукт не решает всех его проблем, а на вопрос “но об этом же нет ничего в требованиях” говорит “дык меня и никто не спрашивал”.
Причина: Не были выявлены все заинтересованные лица (т.н. stakeholder’s), stakeholder’у не был задан правильный вопрос или ответ был неправильно понят. 

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

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

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

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

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

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

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

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

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

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

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

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

Визуальное моделирование позволяет:
* Увидеть структуру и поведение (а 90% информации мы получаем глазами).
* Увидеть, как части становятся целой системой.
* Связать анализ, проектирование и разработку.
* Показывать/скрывать детали по необходимости.
* Даёт язык для однозначной передачи информации.
= Управление требованиями = 
== Что такое хорошие требования? ==
Хорошие требования должны быть:
* Верными: Описывать реальные проблемы заказчика.
* Полными: Описывать все проблемы.
* Целостными (непротиворечивыми): Не должны противоречить одно другому.
* Недвусмысленными: Не должны допускать более одного понимания.
* Проверяемыми: Должна быть возможность проверить их за разумное время/деньги.
* Прослеживаемыми (traceability): Должна быть возможность проследить требования сквозь всю реализацию.
* Изменяемыми: Внесение изменений не должно нарушать структуру и целостность требований.
* Легкими для понимания: Требования ориентированны на понимание заказчиком, девелопером и тестером.

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

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

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

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

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




[[Category:Управление требованиями (Курс)]]