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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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