Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 58
Текст из файла (страница 58)
Полный набор требований должен также задавать требуемый ответ программы на всевозможные классы ввода— как правильные, так и неправильные — во всевозможных ситуациях. Помимо этого, он должен содержать полные ссылки и подписи всех рисунков, таблиц и диаграмм набора требований, а также определения всех терминов и единиц измерения. Гарантия полноты О некоторык аспектах полноты может судить любой компетентный рецензент, который критически оценивает пакет программных требований, чтобы удостовериться, что все рисунки, таблицы и диаграммы снабжены соответствугощими ссылками и подписями. Кое- гго ме жег оценить даже сам разработчик, не имея специальных знаний о приложении.
Например, если в требованиях указано: аимкма догзсма кримимать вводимое магьюваяилвм отдгяьмог чисго и вогграцззть квод)гатммй ко(земь иг мего с точностью до яфгк знаков мгою жгмятой, возникает очевидный вопрос: что будет, гоги когьюватпеяь комитагтся ввести оэфикатгльное чиоюУ 270 Часть 5. Уточнение определения системы Вообще-то, ничего страшного в попытке вычислить квадратный корень из отрицательного числа нет, если в приложении имеет смысл возвращение в качестве ответа системы мнимого числа. Но в таком случае уже требуется понимание проблемной области, чтобы отличить правильный и неправильный ввод. Эта при блема особенно часто встречается при задании верхнего и нижнего пределов вводимых числовых параметров, длины символьных строк и т.п.
Поскольку эти детали зачастую игнорируются в требованиях, разработчику приходится осознанно или неосознанно принимать решение, и в результате получается система, которая отказывается принимать имя клиента, состоящее из более чем 25 символов, или выдает причудливые резуль. таты при ошибочном вводе пользователя. Просмотр возможных классов вводов с целью удостовериться в том, что полный набор требований надлежащим образом описывает поведение системы при правильных и неправильных вводах, — зто то, о чем знает каждый разработчик, хотя мы до сих пор делаем ошибки в написании таких требований.
Именно для пользователей типично игно. рировать эту область при обсуждении: "Почему нормальный человек будет пытаться ввести отрицательное число, когда система спрашивает о возрасте?". Опытный разработчик знает, что это может случиться иэ-за простой опечатки или потому, что пользователь умышленно пытается "повредить" систему либо по другим неясным причинюь Полнота нефункциоваяьньтк требований Чаще других пропускают аспекты производительности и ограничения проектирова. ния, а также предположения о внешних интерфейсах с другими системами. Мы советуем (следуя нашим указаниям, которые мы предлагали при обсуждении практичности, на.
дежиости, производительности и возможности сопровождения) создать простой контрольный перечень (сЬесИш), содержащий вопросы, которые необходимо задать при выявлении ограничений проектирования. При этом разработчики н пользователи, по крайней мере, гложут быть уверены в том, что они эадаэи соответствующие вопросы при создании требований. Пользователь-новичок вновь может выразить недовольство: "Конечно же, я хочу, чтобы система имела хорошие характеристики производительно. сти, это настолько очевидно, что я не понимаю, зачем специально указывать это".
Опытный разработчик знает, насколько важно указать требования производительности в виде максимального и среднего времени ответа или в виде утверждения: "Время ответа для 90 процентов всех транзакций будет составлять менее 3 секунд". Полнота функциональных требований Вопросы полноты функциональных требований более сложные. Не будучи экспертом в области приложения, техническому разработчику очень трудно узнать, не пропущена ли важная часть функциональных возможностей. В конце концов, поскольку все функ.
циональные воэгяожности новые, откуда вы можете знать, сколько их еще должно быть? Иногда эти воэможности настолько привычны и "очевидны", что пользователь даже не осознает, что они есть. (" Конечно, мы запускаем систему расчета заработной платы на день раныпе, если день выплаты приходится на праздник.
Мы всегда так делаем! Какие другие варианты вы можете себе представить?") В этом случае может помочь метод прецедентов. Глава 27. Критерии качества требований к программному ебеспечегппо 271 Деетнясеипе нелиеты с помевзью прототипирования Раскадровка. проверка требований и создание прототипов системы при использовании итеративного подхода к разработке помогуг справиться с большей частью этих проблем. Чем ближе мы подходим к реальному использованию и чем больший опыт работы с внедряемой системой приобретают наши пользователи, тем выше вероятность заметить проблемы в нашем определении. Но даже тогда команда разработчиков должна идти на шаг вперед в своем анализе н задавать всевозмо|кные вопросы "что, если..." с целью гарантировать полноту требований. При этом следует обратить внимание ка граничные условия, исключения и неординарные события.
Например, иногда в описании функциональных возможностей представлены сигуа. ции столь редкие, что они никогда не возкнкали в процессе деловой жизни пользователя; никто и не думает составлять требования для подобной ситуации. Полыователь системы начисления зарплаты может считать, что требуемое поведение системы а„ опп '"очевидно" в случае, если день выплаты приходится на выходной. Но что если национальный праздник, праздник штата и городской праздник придутся на три последовательных рабочих дня? "Такого не бывает",— ~~®: может возразить пользователь, но разработчик в состоянии продемонстрировать, что такое может произойти в течение последующих 3 лег. Эти вопросы не так уж нереальны, как может показаться. Суматоха во. крут "проблемы 2000" наглядно иллюстрирует последствия близоруких решений, основанных на "обоснованных" ожиданиях, касающихся будущих событий. г Непротиворечивость иабора требований Множеспю требований является внугренне непротиворечивым магда и гщмько магда, хе гда ии одно аю подмиожвтжщ акжаяиие из оадгльимл эз)ггбээапигь пг п)зоглиггргкиж г7зугии под мпежгсжэам (1ЕЕЕ 830-1993, 4 4.3.4.1, 1994).
Конфликты могут иметь различную форму и проявляться на различных уровншс детализации; если набор требований был написан достаточно формально и поддерживается соответствующими автоматическими средствами, конфликт иногда удается обнаружить посредством механического анализа. Но, скорее всего, раз. работчикаьг вместе с друпппи учасппповги проекта придется провести проверку множества требований вручную, чтобы удащггь все потенциальные конфликты. Иногда конфликты бывают явкыми и очевидными.
Например, одна часть требований гласит: когда происходим Х, смдугтл эмпагпяжь дгдгэмиг Р, в то время как другая часть утверждает: при возникновении Х гмполклгэь О. Порой неясно, является лн проблема конфликтом нли следствием неоднозначности. Например, часть требований в системе расчета заработной платы может выглядеть так: гсг служагаиг, достигшие 65 лги и багге, г коибг коленда)экого года должны получишь поогбргииг $1000, а другая часть гласит: ггг сотрудии- Г Известно, что в свое время были приняты неблагоразумные решения, приведшие к возникновению "проблемы 2000". Существует н множество другах примеров. Например. прн подготовке полета космического корабля 1(жениная (Сепцш) была допущена ошибка з программе бортового компьютера, вызэаннаа сознательным пренебрежением определеннымп законэмн физики с целью повышения эффективности программы. Принятое тогда решение привело к тому, что место приземления на несколько сотен миль отличалось от расчетного.
272 Часть б. Уточнение определения системы ки, имеогцкг сжаэс работы 10 лги и йигг, г конце календарного года догзснм получишь яоомРгниг в сумме,$500. Как в этом случае поступить с работниками, для которых выполнены оба условия? В данном случае прототипы мало чем могут нам помочь. Хотя опи весьма успешно по.
зволяют выявить пропущенные функции и очень эффективны при проверке требований пользователя, касающихся деталей ввода-вывода, редко бывает, чтобы пользователь нли специалисты по тестированию или обеспечению качества работали с прототипом настолько тщательно, чтобы выявить наиболее скрытые ошибки-конфликты. Их необхо. димо выявлять с помощью тщательной выполняемой вручную ревизии и анализа полис» го набора требований, опираясь на профессиональные навыки команды разработчиков и имеющиеся в наличии автоматизированные средства.
Упорядочение требований по их важности и стабильности Требования, упорядоченные по нх важности Требования, упорядоченные по нх стабильности 5К103 5К172 5К105 5К00$ 5К071 5К192 ВК172 5К192 ба071 5К063 В высококачественном наборе требований разработчики, клиенты и другие заинтересованные лица упорядочивают отдельные требования по их важности для клиента и стабильности (1ЕЕЕ 830-1993, 9 4.3.э, 1994).
Этот процесс упорядочения особенно важен для управления масштабом. Если ресурсы недостаточны, чтобы в пределах выделенного времени и бюджета реализовать все требования, очень полезно знать, какие требования являются не столь уж обязательными, а какие пользователь считает критическими. Можно присвоить дополнительные атрибуты каждому требованию, как мы делэлн при описании требований в документе-концепции; особенно полезны стоимость, риск, сложность и т.п. Но многие из них, по всей видимости, будут зависеть от оценки стратегий реализации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
