Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 51

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 51)

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

Например, если программные требования обозначены ярлыком "5К" (лоГ»»гаге ге»)гйгепееп», для ограничений проектироьания можно использовать ярлык "1)С" (дел!бп сопмгтбп»). Можно также попытаться различать истинные ограничения проектирования и регулирующие ограничения, но мы пришли к выводу, что это редко бывает полезно и может привести к непал»ерным затратам на поддержку. ° Лучше включить все ограничения проектирования в специальный р плел пакета требований или использовать специальный атрибут, чтобы их можно было легко собрать вместе. Это позволит при необходимости легко находить их и пересматривать. ° Необходимо указывать источник каждого ограничения проектирования, Тогда вы слюжете позже вернуться к обсуждению этого требования. "Так, зто ограничение поступило от Билла из отдела маркетинга.

Давайте поговорим с ним об этом!" Если имеются ссылки на некие стандарты, следует составить специальную биолнографическую справку. Тогда в будущем будет проще найти данный стандарт. к40 Часть Б. Уточнение определения системы ° Следует документировать объяснения для каждого ограничения проектирования. Записывайте одно-два предложения, объясняющие, почему то или иное ограни. чение проектирования налагается на проект. Это поможет вам позднее вспомнить, что послужило мотивом для наложения конкретного ограничения. Как следует из нашего опыта, практически всегда возникает вопрос: "Почему мы наложили здесь это ограничениег". Документирование пояснений позволяет более эффективно работать с ограничениями проектирования на более поздних фазюс проекта, когда о них (неизбежно) зайдет речь.

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

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

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

Предпочтительнее двигаться вперед (пусть и с несовершенной организацией), чем топтаться на месте, разрабатывая план совершенного разбиения требований по категориям. Глава хэ. Требования к программному обеспечению 241 Использование "дочерних"требований для повышения уровня конкретизации Мы обнаружили, что многие проекты выиграют от использования концепции дочерних требований в качестве средства дополнения невих базовых требований. Дочбэяее требование саужит дел яовмимнил уровня конкретизации, выровненною вредительская требвва нии. Рассмотрим пример.

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

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

Таким образом, спецификация энергетических потребностей данного приб<» дояияе1 ра будет выглядеть следуюнпп~ образом. довяяе ~ Родительское требование. Прибор должен работать от стандартной дввияе 1 электросети Северной Америки. Дочернее й Прибор должен работать при напряжении в диапазоне ххх-ууу вольт АС. Дочернее 2. Для нормального функционирования прибор должен потреблять не более ххх АС ампер. Дочернеед. Прибор должен работать так, как указано в спецификации, если входная частота варьируется в пределах хх — уу герц. Использование дочерних требований является способом гибкою расширения н дополнения спецификации и одновременно обеспечивает контроль глубины представляемых деталей.

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

в котором нуждается продукт. Род и теельскос: Дочернее 1: 242 Часть 5. Уточнение определения системы Внучатое 1: Внучатое 2: Но и здесь необходимо сделать некое предостережение. Хотя понятие дочерних тре. бований чрезвычайно полезно, необходилю избегать слишкол~ большого числа иерархи. ческих уровней детализации, просто потому, что вы запутаетесь в массе микроскопиче.

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

Организация дочерних требований Мы обнаружили, что лучше всего не отделять дочерние требования от родительских, а включать их в главный пакет требований. с1тобы при чтении проще было связать дочерние требования с родительским, обо. значение дочерних требований должно основываться на обозначении родительских. Предположим, что требование к программному обеспечению 3К63.1 (см. табл. 23,1) имеет одно или несколько дочерних требований. Естественно будет обозначить дочерние требования 3К63.1.1, 3К63,1.2, ВК63.1.3 и т.д.

Иерархический вид табл. 23.1 будет тогда выглядеть следующим образом. Функция 63 ВК63. 1 3К63.1.1 3К63.1.2 ЬК63.1.3 3К63,2 При работе в среде программных/дочерних требований полезно иметь возможность расширять/сужать полный набор требований так, чтобы можно было рассматривать только родительские требования (отдельно) или родительские вместе с дочерними. Далее... После того как мы изучили природу требований, можно переходить к методам их фиксации и оРгаякзацви.

Характеристики

Список файлов книги