Принципы и приемы оперирования требованиями

Приемы оперирования требованиями

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

Прием 1. Анализ проблем

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

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

Результат анализа проблем — ранжированный по степени важности список   потребностей пользователей   с перечислением следствий решения данной проблемы.

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

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

Прием 2. Понимание пользовательских потребностей

Для понимания пользовательских потребностей очень полезно, а зачастую просто необходимо осуществить типизацию   требований (см. лекцию 12). Типы требований определяются их группировкой по тем или иным признакам. Чем более развита система, чем больше функций она реализует, чем шире круг ее пользователей, тем больше типов требований приходится рассматривать в проекте. Идентификация типов требований позволяет разработчикам проекта организованно подходить к решению задачи удовлетворения требований к системе. Использование различных типов требований помогает классифицировать запросы к системе по типам реакции на них. Как следствие, облегчается взаимопонимание в коллективе и между разработчиками и заказчиком.

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

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

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

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