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

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

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

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

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

Проблемы определения и анализа требований

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

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

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

Основные проблемы управления требованиями, с которыми приходится сталкиваться при их анализе, сводятся к следующему.

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

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

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

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

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

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

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

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

  При формулировке требований как регламента разработки всегда нужно учитывать свойства или значения свойств, по которым они различаются: не существует двух равно значимых требований. Это не так, если рассматривать исходный материал для требований. Тем не менее не следует сразу отбрасывать некоторое новое требование только потому, что оно кажется похожим на ранее рассмотренные. Необходимо проанализировать, какие дополнительные стороны оно характеризует, и получить аргументированный ответ на вопрос, действительно ли данное требование является новым. По существу, утверждение об уникальности требований определяет то, как они должны быть представлены в проекте в результате анализа ( требование к требованиям ).
• Набор требований чаще всего является компромиссом.

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

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

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

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

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

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

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

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

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

  В результате в сфере оценки требований царят стихийность и произвол.

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