Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 59
Текст из файла (страница 59)
Например, посмотрев на требование, разработчик может сказать: "Хм, я думаю, что реализовать это требование будет действительно очень сложно, я даже не уверен, что мы знаем, как вообп1е это сделать". Хотя зта информшгия и важна для управ. ления масштабом и принятия решений об очередности реализации, она, как правило, описывается на более высоком уровне абстракции, представленном документом- концепцией. По причинам, которые мы уже обсуждали, эти элементы обычно нг следуем включать в набор требований. На данном этапе лучше использовать атрибуты "важности" и "стабнльносги", которые более тесно связаны с мировосприятием пользователя. Пользователь может скэзаты "Это гребо ванне не очень стабильно, поскольку мы ожидаем, что в будущем месяце изменятся государст. веппые инструкции, влияющие на него. Но с другой стороны, оно очень важно для нас, так кэк влияет на нашу конкурентоспособиосгь".
До того, как команда разработчиков начнет разрабатывать стратепгн, основанные на технологических возможностях, полезно упорядочить требования, например, с помощью состоящей из двух столбцов таблицы. Глава 27. Критерии качества требований к программному обеспечению 273 Обладая этой информацией (в случае равенства других факторов), благоразумный менеджер разработки выделит пропорционально болыпую часть ресурсов иа ЬК103 и Ж172 и, скорее всего, вычеркнет БЕ071, так как оно не столь важное и относительно непостоянное по своей природе.
Проверяемые требования Требования должны быть верифицируемыми (или "тестируемыми" ). Требование в целом является верифицируемым «югда и онмько тогда, когда каэсдое нз анаавллющил его элемента(зныл требований делается ве(»ифииируемым. Элкигнта(зное нфебование считаевия вгрифииируемым тогда и только оюгда, когда существует конечный фи плисово эффективный п(гоиесс, с помощью коякгрого человек или мамина могут определить чню розРаботанная про~аммная система действительно удовлеяю~)яет данному нбэгбоеанию (1ЕЕЕ 830-1993, $ 4.3.6, 1994). Если сказать проще, практическая задача состоит в таком определении требований, чтобы лгожно было впоследствии протестировать их и выяснить, действительно ли они выполняются. Вряд ли можно предложить строго научное доказателытво того, что каждое требование является верифицируемым.
В большинстве случаев зто и не нужно. Создание соответствующих тестовых примеров и процедур для проведения верификации разработанной программы является задачей персонала, занимающегося тестированием и обеспечением качества. Конечно, чтобы иметь возможность сделать это, они нуждаются в хороню определенных и недвусмысленных требованиях. На совещании, посвященном проверке, типичной является картина, когда кюкдый из участников обращается к специалистам по тестированию и спрашивает: "Вы уверены, что можете создать тестовый сценарий для проверки того, что данное требование выполнено?".
Ниже приводятся примеры требований и типичные высказывания разработчиков и/или специалистов по тестированию о воэможности их верификации. ° Система должна поддерлсивать до 1000 полыоеапмлей одное)геменно. "Это зависит от того, что разрешено делать этим пользователям после регистрации. Если полам» ватели имеют неограниченныг возьюжности и теоретически могут ввести транзакцию. которая приведет к тому, что прикладная программа будет последовательно просматривать каждую запись базы данных, очень сложно проверить, сможет ли система работать с 1000 пользователями; существует ничтожная (по ие нулевая) вероятность, что все эти пользователи одновременно захотят запустить такие транзакции.
Но если пользователи ограничены в выборе запускаемых транзакций и мы сможем определить, какая из этих транзакций является наиболее трудоем. кой. можно будет проверить, как удовлетворяется это требование (с разумной степенью достоверности), хотя нам придется использовать наше средство контроля загрузки для имитации 1000 активных терминалов." ° Система долзсна отвечать на гфонзвольный эап~юс е течение 500 миллисекунд. "Все зависит от того, что подразумевается под словом гфоизеольный. Если число возможных запросов конечно и нам удастся выявить наиболее сложные из них, мы сможем проверить поведение системы." 274 Часть 5. Уточыеные определения системы ° Циф)зм на экране, ноказмвающгм г))гмя, должны ж~юао тггледееь "Даже ые думайте об этом.
Красота — вопрос вкуса." 8888 ° Сисныма должна быть дружгствгнной яольюваемлю. "Это еще хуже, чем приятная фо)сиа! Если не будут тщательно определены условия и детали, фужо сэюгнносэсь нольюваэмлюявляется просто приглюпеннем для введения аргументов." ° Сисэмма должна вкснсрсиифовавсь данные для нросиот)за (ими банг) в формате, в ко. тараи в качгсэюг раздглиеыля иснагьзутлся занятая. "Хотелось бы уточнить некого. рые детали; например, что будет, если эти данные представляют собой пустое множество? Но в принципе, мы можем проверить, будет лн система вести себя нужным образом в данном вопросе." Верификация и проверка правильности являются важнымн вопросами при разрабог ке высококачественной программы. Мы вернемся к этой теме в части б.
Модифицируемый набор требований Множество требоваыий является модифицируемым тогда и только тогда, когда гго стРуктуРа и стиль таковы, что любое изменение тРгбований мозкно нРоизвгсти нро. сто, колко и согласованно, нг каузу исая существующей структуры и стиля всего мнохсгства (1ЕЕЕ 830-1993, 9 4.3.7, 1994). Для этого требуется, чтобы пакет имел минимальыую избыточность и был хорошо оргаыизован, с соответствующим содержанием, индексом и возможностью перекрестыых ссылок. Это не всегда означает, что пакет ведется и поддерживается с помощью некоего автоматического средства, но в больших системах, которые могут иметь тысячи требований, использование подобных средств становится практически необходимым.
Требования будут модифицироваться, нравится это кому-то нлн нет; альтернативаэто "замороженный" пакет требований, что равносильно его отсутствию и, соответсз венио, "провалу" проекта. Если требование (нли содержащий его пакет) немодифицнруемо, оно фактически становится недействительным через несколько недель или месяцев, так как команда постепеыно откажется от своих усилий по его изменению и поддержанию его актуальности.
Каждому администратору программного продукта хочется думать, что его множество требований является модифицируемым, н кюкдый производитель вспомогательных про. грамм хвастается, что одним нз главных достоинств его средства является то, что оыо действительно обеспечивает модифнцируемость. Все это звучит красиво, но нужно его опробовать, чтобы увидеть, работает ли оыо. И это нужно делать для того же масштаба и уровня сложности, что н в будущем проекте. Трассируемые требования Требование в целом является трассируемым тогда и только тогда, когда ясно нроисхохсдо ниг каждого из сосииимяющих гго еггмгниигрнмх т)ибований и сущгстгуге мгханизм, коиифмй дсамт возмозкным офащисиг к зтаиу требованию ири дальнгйтих деЫввиях ио разработке (1ЕЕЕ 830-1993, б 4.3.8, 1994).
На практике это обычно означает, что каждое требование имеет уникальный номер нлн идентификатор. Иногда моэасо испольювать ключевое ело. во, например "должна" (зЬай), чтобы выделить требование н отличить его от других не столь важных утверждений, комментариев и т.п., которые также могут содержаться в набо- Глава 27. Критерии качества требований к программному обеспечению 276 ре требований. При использовании автоматического средства работы с требованиями, идентификация требований может осуществляться системой автоматически. В пределах одного проекта или, возможно, одного пакета будет необходимо трасси.
ровать одни компоненты к др)тим. Например, некоторые компоненты будут зависеть от других; если одни меняются, это повлияет и на другие. Некоторые утверждения требова. ннй могут уточняться "дочерними" требованиями (субтребованюгми), для которых возможность трассировки является очевидным свойством. Нам необходима возможность асраягной трассировки (Ьаскзгагб ггасеаЬ1)йу) — от текущих стадий к предыдущим стадиям определения или разработки, в частности, к документу-концепции, который мы обсуждали в части 3.
Например, из табл. 23.1 видно, что все требования 6К63.1, Я(63.2, БК63.з можно трассировать к Функции 63 документа-концепции (Ч)йоп босншенг). Это очень существенно, если нам понадобится добавить нлн исключить некоторые функции; это также существенно, если возникают трудности с определенными требованиями и необ. ходимо вновь согласовывать с пользователем сроки или бюджет для затронутой этим процессом функции. Также необходима возможность х)Вямой трассировки (согнав пвсе- аЬ)Игу) — от текущего требования ко всем подчиненным ему требованиям, независимо от того, какие контейнеры (документы проектирования, блок-схемы, программный код, тестовые примеры и т.п.) порождаются данным контейнером.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
