Прием 3. Преодоление сложности многофункциональности требований
Большой объем информации, определяемой требованиями, — не единственная сложность с которой приходится сталкиваться при разработке проекта. Не меньшую сложность представляет то, что различные источники требований характеризуют будущее или развиваемое программное изделие с разных сторон. Это свойство называется многофункциональностью требований.
Было бы неразумно ожидать от разработчиков полной компетентности во всех областях деятельности, которые затрагиваются в связи с разработкой и использованием системы. Как следствие, комплексный анализ многофункциональности невозможен без привлечения (в разных качествах) всех доступных инициаторов работ или их представителей.
Важно понять, кто кроме заказчика может предъявлять требования, как получить доступ к этим источникам и как извлекать из них информацию. Если заказчик в состоянии аккумулировать требования всех инициаторов работ, т.е. берет на себя эту задачу, то можно говорить о предпосылках использования для проекта методологии экстремального программирования [3]. Но, к сожалению, это условие выполняется не столь часто, как хотелось бы, а потому для выявления перспектив проекта и с целью согласования разноплановых требований к разрабатываемому изделию определяется специальная группа, представляющая интересы инициаторов работ. Это может быть реальная группа лиц, если у компании есть возможность их содержать, эпизодически собирающийся или дистанционно общающийся коллектив или даже просто ролевой кластер, заполняемый сотрудниками проекта. Примерный состав ролей такой группы следующий:
-
представитель заказчика — отслеживает и представляет интересы тех, от кого получен заказ на разработку;
-
представитель пользователя — отражает взгляд на систему со стороны пользователя;
-
инвестор — предъявляет требования тех, кто вкладывает средства в разработку;
-
менеджер по продажам — предъявляет требования со стороны распространения программного изделия;
-
покупатель — предъявляет требования с точки зрения покупательского спроса.
Деятельность группы инициаторов работ организуется независимо от проектной деятельности, но с учетом конструктивных контактов и согласований с разработчиками. Результат деятельности группы — экспертиза требований: расстановка приоритетов и проверка значимости с различных внешних по отношению к проекту точек зрения.
Взаимодействие с группой инициаторов работ со стороны исполнителей проекта осуществляется сотрудниками, выполняющими следующие роли:
-
менеджер проекта;
-
эксперт предметной области;
-
специалист по пользовательскому интерфейсу;
-
архитектор и проектировщики подсистем в качестве специалистов, отражающих реализационные аспекты разработки;
-
тестировщики, ответственные за проверку работоспособности системы с точки зрения ее соответствия требованиям.
Для организации хранения информации о работе с требованиями привлекаются разработчик информационной поддержки и библиотекарь проекта. Первый из них определяет виды доступа к информации: запросы к базе данных проекта, сохраняющей все сведения о требованиях, второй осуществляет администрирование этой базы.
Если такая группа не предполагается, то ее роли выполняют разработчики, указанные выше в качестве тех, кто взаимодействует с инициаторами работ.
Даже если система строится для использования в рамках компании, полезно воспользоваться опытом тех, кто работал с конечными пользователями, кто может быть экспертом в области распространения подобных систем. Если разработка ведется для продажи, в круг инициаторов работ привлекаются маркетологи, которые выявляют запросы рынка, предъявляемые к системам данного класса, рыночную конъюнктуру и т.д. За счет этого уже в начале проекта можно выявить значительное число факторов, определяющих требования.
Методы, с помощью которых достигается понимание истинных пользовательских потребностей, включают интервью и мозговые штурмы, опросы и анкетирование, изучение прототипов. В результате комплексного изучения получаемых таким путем сведений должен быть составлен перечень типизированных требований, описанных текстуально и/или графически, порядок которого соответствует приоритетности требований для данной разработки.
Прием 4. Оперирование многомерными требованиями
Этот прием носит служебный характер, так как не связывается с конкретными этапами. Его назначение — организация помощи при отборе требований для различных целей. Задача состоит в том, чтобы отбирать требования быстро, а главное — точно, чтобы ни при каких обстоятельствах ни одно из нужных требований не было упущено. Типизация требований — одно из средств, облегчающих решение задачи отбора, но его явно недостаточно, поскольку параметры отбора не сводятся к одному измерению, фиксированному типизацией. Другим примером параметра отбора служит приоритетность требований, отбираемых для реализации в рамках итерации. Единственного значения параметра для этого не хватает: разные инициаторы работ могут выставлять разные приоритеты одним и тем же требованиям. Следовательно, и здесь нужно уметь одновременно оперировать разными параметрами отбора.
Тип требований характеризуется своими атрибутами, и каждое требование имеет различные значения этих атрибутов. К примеру, с] требованием могут быть связаны его приоритет или причина появления, оно может быть соотнесено с теми, кто должен заниматься его реализацией (рабочие группы, ответственные за сетевые взаимодействия, управление поведением системы, интерфейс и др.). Характеризует требование уровень трудоемкости реализации, наконец, срок или итерация, когда планируется реализация. Анализ требований зависит от подобных характеристик, которые называются измерениями атрибутного набора требования.
При выполнении анализа полезно иметь следующие возможности:
-
Отбор требований, которые обладают заданными значениями не которых атрибутов или значениями, попадающими в .определенный диапазон. В частности, сюда попадает отбор требований заданного типа.
-
Сортировка требований по основным измерениям, указывающим на те или иные атрибуты.
-
Ручная корректировка набора требований, отобранных в соответствии с заданным критерием.
-
Объединение, пересечение и дополнение отобранных наборов требований.
-
Проверка свойств требования (набора требований), формулируемых как предикаты над значениями атрибутов.
По существу, здесь выделены те средства отбора, которые являются стандартными при работе с реляционными базами данных. Следует, однако, отметить и специфику оперирования требованиями по сравнению с общими реляционными средствами отбора. Содержание требования — это, как правило, текстовый материал (возможно, с графическими включениями), атрибуты которого определяются при его обработке, а потому при оперировании требованиями необходимо явное предъявление содержания в качестве основного параметра, назначение которого не сводится лишь к идентификационным функциям. Анализ текста требования может сказать больше, чем формальные значения атрибутов.
Оперирование требованиями — один из основных методов анализа. Эта работа входит в обязанности архитектора, проектировщика подсистем и, естественно, менеджера проекта. В каждой из указанных ролей круг требований, доступных разработчику, должен быть ограничен тем, что необходимо в данный момент. Соответственно определяются права доступа к требованиям для разных разработчиков проекта. Организация хранения и предъявления требований в проекте есть функция разработчика информационной поддержки и библиотекаря проекта с разделением обязанностей, соответствующим статусу этих ролей в проекте (разработчик информационной поддержки специфицирует необходимые виды запросов, а библиотекарь занимается администрированием).
Результатом данного приема является группа требований, выделенная в процессе оперирования для тех или иных целей. Подобные группы являются исходным или результирующим материалом при выполнении всех последующих приемов анализа требований, а потому оперирование многомерными требованиями можно рассматривать в качестве технического средства этих приемов.