Поучительная история

Являются ли ограничения проектирования истинными требованиями?

Можно считать, что ограничения проектирования не являются требованиями к программному обеспечению, так как они не представляют ни один из пяти пунктов нашего сложного определения. Но когда ограничение проектирования поднимается до уровня полноправного политического, технического или бизнес -условия, оно будет удовлетворять нашему определению, как нечто, необходимое для "соответствия контракту, стандарту, спецификации или другой формальной документации".

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

Мы работали с компанией Fortune 500, хорошо известной в отрасли благодаря ее приверженности процессу и процедуре. Представьте себе наше удивление, когда мы обнаружили, что работа компании по сбору требований полностью парализована из-за того, что команда не может прийти к согласию о том, являются ли определенные требования функциональными, нефункциональными или ограничениями проектирования. В результате способность команды двигаться вперед в осуществлении проекта оказалась под вопросом из-за игры слов! Мы сказали команде, что неважно, как это называется, давайте продвигаться хоть в чем-нибудь. Мораль такова. Назначение классификации в том, чтобы стимулировать мышление, помогать при поиске "неоткрытых руин", и в том, чтобы помочь по-разному воспринимать эти вещи. Но в действительности классификация не имеет значения, если вы понимаете, что требования — это нечто, с чем вас или систему будут сравнивать. Предпочтительнее двигаться вперед (пусть и с несовершенной организацией), чем топтаться на месте, разрабатывая план совершенного разбиения требований по категориям.

Использование "дочерних" требований для повышения уровня конкретизации

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

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

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

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

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

Родительское требование. Прибор должен работать от стандартной электросети Северной Америки.

Дочернее 1. Прибор должен работать при напряжении в диапазоне – ххх-ууу

вольт АС.

Дочернее 2. Для нормального функционирования прибор должен потреблять не

более ххх АС ампер.

Дочернее 3. Прибор должен работать так, как указано в спецификации, если

входная частота варьируется в пределах хх-уу герц.

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

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

Внучатое 1:

Внучатое 2;

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