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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прием 3. Преодоление сложности многофункциональности требований

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

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

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

• представитель заказчика — отслеживает и представляет интересы
тех, от кого получен заказ на разработку;

• представитель пользователя — отражает взгляд на систему со сторо­ны пользователя;

• инвестор — предъявляет требования тех, кто вкладывает средства в разработку;

• менеджер по продажам — предъявляет требования со стороны рас­пространения программного изделия;

• покупатель — предъявляет требования с точки зрения покупатель­ского спроса.

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

Взаимодействие с группой инициаторов работ со стороны исполни­телей проекта осуществляется сотрудниками, выполняющими следую­щие роли:

• менеджер проекта;

• эксперт предметной области;

• специалист по пользовательскому интерфейсу;

• архитектор и проектировщики подсистем в качестве специалистов,
отражающих реализационные аспекты разработки;

• тестировщики, ответственные за проверку работоспособности сис­темы с точки зрения ее соответствия требованиям.

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

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

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

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

Прием 4. Оперирование многомерными требованиями

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

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

При выполнении анализа полезно иметь следующие возможности:

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

• Сортировка требований по основным измерениям, указывающим
на те или иные атрибуты.

• Ручная корректировка набора требований, отобранных в соответ­ствии с заданным критерием.

• Объединение, пересечение и дополнение отобранных наборов тре­бований.

• Проверка свойств требования (набора требований), формулируе­мых как предикаты над значениями атрибутов.

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

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

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

Прием 5. Определение системы

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

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

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

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

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

Прием 6. Управление областью применимости системы

Управление областью применимости — это решение следующей за­дачи: выбрать приоритетное с точки зрения инициаторов работ направ­ление развития проекта в условиях имеющихся на данный момент ресур­сов (время, кадры, финансы). Это ключевая задача, определяющая ус­пешность проекта в целом. Она решается непрерывно в течение всего итеративного наращивания, которое разбивает область применимости системы на небольшие, доступные для управления части (стоит сопоста­вить это положение с обсуждением мотивации методологических страте­гий в лекции 5).

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

Методы определения области применимости сводятся к достиже­нию соглашений посредством обсуждения атрибутов требований с целью выявления реальных возможностей проекта.

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

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

Прием 7. Детализированное определение системы

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

Распространенная ошибка — уверенность в том, что сложное для разработки нуждается в сложном описании. Это приводит к запутанным объяснениям целей проекта и системы, которые, возможно, и производят впечатление, но не помогают потенциальным пользователям. Необходимо приложить значительные усилия, чтобы добиться понятности детализированного определения системы в описывающем ее документе. Быть может, потребуется несколько такого рода документов, предназначенных ля различных пользователей.

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

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

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

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

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

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

Составление детализированного определения системы — задача, которую решают проектировщики системы. Подготавливаемые на этапе анализа и уточняемые в ходе оценки материалы согласовываются с за­казчиком.

Вариант 1

1. Какие варианты работы с требованиями нужно отразить в
модели жизненного цикла для учета непрерывности по­ступления требований в проект?

□ требование или группа требований обрабатываются до начала
работ над проектом

□ специально отражать в модели эту ситуацию не нужно

□ требование или группа требований обрабатываются до начала
работ итерации

□ требование или группа требований поступают, когда работы
итерации начались

О требование или группа требований поступают, когда работы итерации завершились и релиз системы передан в эксплуата­цию

2. В чем состоит анализ проблем?

□ он выявляет проблемы реализации требований к проектируе­мой программной системе

□ он нацелен на определение того, какие средства должны быть
реализованы

□ он выявляет первичные нужды пользователей

□ он нацелен на определение ранжированного по степени важности списка потребностей пользователей с перечислением
следствий решения данной проблемы

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

3. Что такое многомерность требований?

□ необходимость рассмотрения атрибутного набора требований
при решении задачи их отбора для различных целей

□ противоречивость атрибутов требований

□ фактическое содержание требования отражает несколько по­желаний к системе

□ несводимость параметров отбора требований к одному измере­нию (т.е. к одному показателю)

□ различные характеристики требования, рассматриваемые сов­
местно

Вариант 2

1. Укажите возможные варианты результата анализа
требований.

□ требование отклоняется

□ требование замораживается до следующего проекта

□ требование принимается к реализации на текущей итерации

□ требование откладывается до одной из следующих итераций

□ требование условно принимается к реализации на текущей
итерации

2. Прием «понимание пользовательских потребностей»
нужен для:

□ выяснения средств программной системы, которые необходимы

□ упорядочения требований по степени актуальности для
реализации

□ того, чтобы построить систему типов требований для данного
проекта

□ определения требований, реализуемых в рамках ближайшей
задачи проекта

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

3. Что включает в себя определение системы?

□ соглашения о разработке: виды рабочих продуктов, правила их
построения, проверки

□ внешние рабочие продукты и способы их использования в
проекте

□ общие соглашения о том, как понимаются требования и из приоритетность, оценка затрат на разработку и ресурсных потребностей, какие рисковые ситуации вероятны и стратегия
управления рисками

□ оценка границ применимости проектируемой системы

характеристика требуемого коллектива исполнителей

Вариант 3

1. Какие действия не рассматриваются как этапы обработки
требований?

□ обработка поступления требования или совместной группы
требований

□ принятие решения о переходе к анализу

П расщепление линии жизненного цикла, переход к анализу

□ принятие решения об анализируемых требованиях

□ планирование будущей итерации реализации

2. Что означает многофункциональность требований?

□ определение границ применимости разрабатываемой про­граммной системы

□ различные требования предполагают разные варианты приме­
нения разрабатываемой системы

□ существует множество типов пользователей с разной потребностью в разрабатываемой системе

□ различные инициаторы работ характеризуют будущее или раз­виваемое программное изделие с разных сторон

□ требования фиксируют множество функций, которые должны
поддерживаться программной системой

3. Какая задача решается при управлении областью приме­нимости системы?

□ ранжирование инициаторов работ с точки зрения предоставле­ния ими требований, наиболее важных для реализации систе­мы

□ ранжирование требований к программной системе по степени
актуальности для реализации с точки зрения инициаторов ра­
бот

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

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

□ составление точного описания системы, согласованного со
всеми заинтересованными в проекте сторонами