Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 49
Текст из файла (страница 49)
Функциональээыс требования описывают, как систелэа должна вести себя, когда ей предоставляются опрсдслсцшые входные данные или условия. По этого недостаточно для полного описания требований к системс. Необходимо также учитывать след>эогцие характеристики, которые Бренди (Огаэ(у) (1992) назвал "лефуээх Кээолпльяьсээээ эээ)>гбованэоэми". ° !! рактич ность (13заЬ1!(эу) ° Надежность (Кс!!аЪ|!!эу) ° !! Роизводительиость (Рс~ Гопээаээсс) ° Возможность обслуживания (бпрроээаЬ!11>у) Эти требования, как правило, используются для описания некоторых "атриоутов систслэы" илп "атрибутов спстсл<ного окружения" из нашего сложного определения. Благодаря пх >добиой классификации мы можслэ больное узнать о системс, котор>эо необходи. мо создать.
Расслютрим каждый из перечисленных пунктов более подробно. Практичность Важно описать, насколько легко б>д> пэээс пользователи смогут освоить д эээп>эо систс. му. Может понадобиться определить различныс категории пользователей: начипшоншс, "средние', опытпыс, а также псграмотпыс пользователи — тс, которые ис владекэт свободно родным взыком "средних" пользователей, и т.д.
Если предполагается, что закаэчик будет ээрослэатривать требования и участвовать в их обсуждении (а так н должно быть!), следует все требования в зтон сфере писать на естественном языке (описание пракпэчиости ис может быть в форме конечного автомата). Поскольку практичность зависит от точки зрения наблюдателя, как описать такой неясный набор требований? Ниже приводятся некоторые рекомендации. ° Уюзать необходимое время подготовки пользователя для достижения минимальной прои.икэдэпелыижти (спосооиости выполнять простые эадачээ) и операционной произв<эдээтельнээсти (способности вьшалэить обычные текущие задачи).
Как отмечалось, мог>т понадобиться отдельные описзния для начинающих пользователей (которыс, быть может, никогда ирсждс пс видели компьютер), средних и опытныж ° Указать время выполнения типичных задач или транзакций, осуществляемых ко. нсчнэнм пользователем. При создании системы ввода заказов на покупку, всрояг но, наиболсс типичными задачами, выполняемыми конечными пользователями, будут ввод, удаление или модификация заказа, а также проверка состоэшия заказа, Если пользователь знает, как выполнять зти задачи, сколько времени он потратит па ввод типичного заказа? Миилу? Пять минут? Час? Конечно, зто будет зависеть от технической реализации (скорости модема, пропускной способности сети, ОП, мощности ЦП, которые соээлэсстно определяют время ответа, обеспечиваемое сис- Глава 23.
Требования к программному обеспечению 233 темой), но время выполнения задач также напрямую зависит от практи шости системы, и нужно иметь возможность определить это отдельно. ° Сравнить практичность новой системы с уже с>чдествующими современными системами, которые известны и пользуются успехом у пользователей. Иными словамп, требование может выглядеть так: "11овая система должна быть признана подавляющим болыяинством (90%) пользователей такой же практичной, как и существ>ющая Х'г'Х-система". Напоминаем, что такис требования. равно как и все остальные, должны допускать возможность проверки соответствия; мы должны описывать трсоование так, чтобы пользователи моглн проверить соответствие практичности >становлениому нами критерию. ° Оговорить существование систем интерактивных подсказок, программ- помощников, средств предупреждения, руководств пользователя и других форм документации и помощи, а также определить их необходимые функции.
° Следовать соглашениям и стэгщэртаьц разработюшым для человеко.мащшшого интерфейса. Чтобы новая система работала "почти так жс, как та, которую я уже использовал", необходимо следовать согласовюшым сзэндаргзм от приложения к прплояи.- нию. Например, вы можете >застать требование соответствия общим стандартам практичности, таким как стандарты С()Л (Сопипоп пзег ассем) компании !ВМ или стандарты )Ь')пдонз-приложений, оп>бликовышглс компанией Мкгозой. Примером подлинного прорыва в сфере практичности в компьютерном мире может служить разница между командными строками операционных систем 1)03 и СХЕХ и 6()1- интерфейсами операционных систем Ъу(произ н Мас!щоз!к ОИ-интерфейсы значительно упростили использование компьютера для пользователей, не имеклцих технического ооразо.
ванна. Еще одним примером является 1пгсгпсгброузер, который стал окном в мир %огЫ ЮЫс Ч'еЬ и радикально ускорил освоение !шегпсг средним пользователем. Было предпринято несколько интересных попыток сделать более строгилг весьма расплывчатое понятие практичности. Наиоольщий ии. терес представляет так называемьш "Билль о правах пользователси" (Карат (Кагаг), 1998). Последняя его версия состоит из десяти основных пунктов, 1. Пользователь всегда прав. Если возникает проблема с использо- ванием системы, то дело в системс, а не в пользователе.
~В 2. Пользователь имеет право на программное и аппаратное обеспечение, которое легко монтируется и демонтируется без негативных последствий. 3. Пользователь имеет право на то, чтобы система делала в точности то, что обещано. 4. Пользователь имеет право на простые в использовании инстр>кцни (руководства пользователя, интерактивные нли контекстно-завнсимыс подсказки, сообщения об ошибках), которые позволят елгу понимать систему н использовать ее для достижения желаемых целей, а также эффективно и легко выходить нз сложных ситуаций. 3. Пользователь имеет право иа внимание со стороны системы, а также на то, чтобы иметь возможность получить ответ системы на запрос о внилюпии, 6.
Пользователь имеет право на то, чтобы система предоставляла четкую, попятную и точную информацию о выполняемой задаче и ее выполнении, 236 Часть Б. Уточнение определения системы 7. Пользователь имеет право на то, пабы его информировали о всех системных требованиях для успешного использования программного обеспечения или аппаратуры. 8. Пользователь имеет право знать о пределах возможностей системы.
9. Пользователь имеет право общаться с провайдером технологии н получать полные исчерпывающие ответы, когда в этом возникает необходимость. 10. Пользователь должен быть хозяином программных и аппаратных технологий, а пе наоборот. Продукты должны использоваться естественно и интуитивно. Отметим, что некоторые из перечисленных пунктов по своей сути являются неизме. риькыьки и не могут быть кандидатами в требования. С другой стороны, ясно, что этот документ может служить отправной точкой при разработке вопросов и определении требований, касающихся практичности предлагаемого продукта. Надежность Конечно, никому пе нравятся ощибки, системные сбои или потери данных, и если подобные явления нигде в требованиях не упоминаются, пользователь, естественно, может предположить, что их не будет вовсе.
Но в современном мире даже самый оптимистически настроенный пользователь знает, что отибки и сбои неизбежны. Таким образом, в требованиях следует указать, в какой степени система обязана вести себя приемлемым для пользователя образом. Как правило, здесь описываются следуюпсие аспекты. ° нуосглуяность (ана11айкб11).
Система должна быть доступна для операционного непользования в течение указанного времени (в процентном выражении). Иногда требование может указывать непрерывную "понгор" доступность, т.е, 24 часа в сутки, Збб дней в году. Но чаще можно встретить указание 99-процентной илн 99.9. процентной доступности между 8 часами утра и полуночью. Отметим, что треба.
ванна должны дказывать, что понимается под "доступностью". Означает ли 10(Ь процентная даст)пность, что все пользователи должны иметь возможность использовать все системные услуги в любое время) ° Среднее креня между откаэамн (Меап бте еегнлел /айнтэ, МТВг). Оно обычно указывает ся в часах, но может также указываться в днях, месяцах или годах. Здесь тоже нужна точность: требования должны четко определять, что понимается под "сбоем". ° Среднее время еосстаноеленкя (пиап бте го гера(г, МТТЛ). Как долго системе разре.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
