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

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

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

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

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

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

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

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

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

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

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

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

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