Анализ требований при начале проекта
Все процессы предполагают, что с чего-то проект начинается :). Начинается он с того, что у заказчика появляется какая-то потребность, которая выражается в более или менее четко сформулированных требованиях. Получив начальное описание задачи (в неформализованном виде), разработчик (или коллектив разработчиков) оценивают задачу в целом, объем работ, бюджет и принимают принципиальное решение о начале проекта.
Как принимается такое решение? Прежде всего, оценивается возможность решения задачи с помощью существующих и доступных для заказчика разработок. Не следует заниматься изобретением велосипеда. Если все-таки существующие средства не подходят, не отвечают требованиям, разработчик определяет, может ли он (они) сделать то, что требуется в принципе, может ли он сделать это лучше, чем существующие аналоги, насколько реальным ему представляются сроки и бюджет. На данном этапе далеко не на все эти вопросы можно ответить, поэтому задача данного этапа – отсечь явно неприемлимые для разработчика проекты. А в принципе не все еще пока ясно даже в принципе.
В общем случае решение о собственно выполнениии программной разработки может приниматься после достаточно длительных исследований, анализа требований, аналогов. Кроме того, если речь идет не о программном проекте, а о проекте автоматизации (в более общей постановке), то может выполняться анализ требований с последующим созданием технической документации, описывающей использование существующих средств для решения поставленной задачи.
Отличие процессов в плане анализа требований
В разных процессах этап анализа требований занимает разное количество времени :
В традиционном водопаде он может занимать в среднем до 20-30% времени проекта и заканчивается составлением ТЗ.
В унифицированном процессе основные требования анализируются в основном в фазах начала и развития проекта, то есть могут занимать в разных случаях от нескольких недель до нескольких месяцев. Важно отметить, что в UP требования анализируются в несколько приемов , вначале выясняется до 30% процентов требований (причем только 10% описываются подробно), затем еще до 70% - в процессе разработки на этапе развития, остальные – в фазе конструирования системы.
В XP начальный этап анализа требований занимает минимальное время, необходимое для начала работ (для составления списка задач, планирования версий и первых 1-2 итераций и пр.).
Анализ прецедента.
Задачи и роли прецедента
основная идея состоит в исследовании и формулировке функциональных требований путем написания историй "из жизни системы". Эти истории помогают сформулировать различные задачи и представляют собой сценарии использования системы.
Задачи и рамки прецедента
Прецедент — это не один маленький шаг, такой, например, как удаление товара или печать документа. Основной сценарий прецедента обычно включает пять-десять шагов. Описываемый сценарий выполняется не в течение нескольких дней или сеансов, как, например, переговоры с поставщиками. Это задача, выполняемая в течение одного сеанса. Реализация прецедента может длиться от нескольких минут до нескольких дней. Как и при определении унифицированного процесса, основное внимание уделяется получению ощутимого (измеримого) результата и переходу системы и данных в устойчивое состояние.
Типичной ошибкой является рассмотрение прецедентов на слишком низком уровне, когда сценарий выполняется за один шаг и по существу является некоторой подфункцией или подзадачей в рамках элементарного бизнес-процесса.