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

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

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

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

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

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

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

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

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

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

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

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

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

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