Набор требований чаще всего является компромиссом.

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

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

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

• преобладание специалистов с комбинационным мышлением, а не тех, кто умеет анализировать задачу на уровне метода (см. [16]). Есть и субъективный, чисто экономический фактор: стоимость ра­боты специалиста, способного к аналитическому продуцированию методов, слишком высока, чтобы их можно было привлекать все­гда для выработки решений в противоречивых случаях.

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

• Требования изменяются.

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

• Требования зависят от времени.

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

• Требования очень трудно оценивать.

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

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