Требования к программному обеспечению.

Функциональные требования к программному обеспечению

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

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

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

Функциональные требования к программному обеспечению описывают, как ведет себя система. Эти требования обычно ориентированы на действия и содержат формулировки вида: "Когда пользователь делает X, система будет делать Y". Большинство продуктов и приложений, предназначенных для выполнения полезной работы, содержит множество функциональных требований к программному обеспече­нию. Программное обеспечение используется для реализации большей части функцио­нальных возможностей.

При определении функциональных требований к ПО следует искать золотую середину ме­жду слишком конкретизированной формулировкой требования и слишком общей и не­однозначной. Например, как правило, ни к чему иметь обобщенное функциональное требование следующего вида: "Когда пользователь нажимает кнопку “Пуск”, система запускается и начинает ра­ботать". С другой стороны, формулировка требования, которая состоит из нескольких страниц текста, по-видимому, слишком конкретизирована, хотя и может быть правомерной в некоторых частных случаях. Опыт свидетельствует, что определение требования, состоящее из одного - двух предложений, обычно является наилучшим, когда нужно соотнести по­требность пользователя с приемлемым для работы команды разработчиков уровнем конкретизации.

Нефункциональные требования к программному обеспечению

Функциональные требования описывают, как система должна вес­ти себя, когда ей предоставляются определенные входные данные или условия. Но этого недостаточно для полного описания требований к системе. Необходимо также учитывать следующие характеристики, которые Роберт Грейди (Grady) [7] назвал "нефункциональными требованиями".

· практичность (Usability);

· надежность (Reliability);

· производительность (Performance);

· возможность обслуживания (Supportability).

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

Требования практичности.

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

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

Указать время выполнения типичных задач или транзакций, осуществляемых ко­нечным пользователем. При создании системы ввода заказов на покупку, вероят­но, наиболее типичными задачами, выполняемыми конечными пользователями, будут ввод, удаление или модификация заказа, а также проверка состояния заказа. Если пользователь знает, как выполнять эти задачи, сколько времени он потратит на ввод типичного заказа: 1 минуту, 5 минут, 1 час… Безусловно, эта характеристика будет зависеть от технической реализации: пропускной способности сети, объема оперативной памяти, мощности процессора, которые совместно определяют время ответа, обеспечиваемое системой, но время выполнения задач также напрямую зависит от практичности системы, и нужно иметь возможность зафиксировать это значение.

Сравнить практичность новой системы с уже существующими современными сис­темами, которые известны и пользуются успехом у пользователей. Иными слова­ми, требование может выглядеть так: "Новая система должна быть признана по­давляющим большинством (90%) пользователей такой же практичной, как и суще­ствующая XYZ-система". Обратите внимание, что нефункциональные требования к ПО, равно как и все остальные, должны допускать возможность проверки соответствия. Команда разработчиков должна описывать требование так, чтобы пользователи могли проверить соответствие практичности установленному критерию.

Оговорить существование систем интерактивных подсказок, программ-помощников, средств предупреждения, руководств пользователя и других форм документации и помощи, а также определить их функциональное поведение.

Следовать соглашениям и стандартам, разработанным для человеко-машинного ин­терфейса. Чтобы новая система работала "почти так же, как та, которую пользователь уже исполь­зовал", необходимо следовать согласованным стандартам от приложения к приложе­нию. Например, можно указать требование соответствия общим стандартам прак­тичности, таким как стандарты CUA (Common user access) компании IBM или стандарты Windows-приложений, опубликованные компанией Microsoft. Примером подлинного прорыва в сфере практичности в компьютерном мире может слу­жить разница между командными строками операционных систем DOS и UNIX и GUI-интерфейсами операционных систем Windows и Macintosh. GUI-интерфейсы значительно упростили использование компьютера для пользователей, не имеющих технического образо­вания. Еще одним примером является Internet-браузер, который стал окном в мир World Wide Web и радикально ускорил освоение Internet рядовым пользователем.

Было предпринято несколько попыток сделать более строгим весьма расплывчатое понятие практичности. Наибольший интерес представляет так называемый "Билль о правах пользователей", предложенный Каратом (Karat), [8]. Последняя его версия состоит из десяти основных пунктов.

· Пользователь всегда прав. Если возникает проблема с использованием системы, то дело в системе, а не в пользователе

· Пользователь имеет право на программное и аппаратное обеспечение, которое легко монтируется и демонтируется без негативных последствий.

· Пользователь имеет право на то, чтобы система делала в точности то, что обещано.

· Пользователь имеет право на простые в использовании инструкции (руководства пользователя, интерактивные или контекстно-зависимые подсказки, сообщения об ошибках), которые позволят ему понимать систему и использовать ее для достиже­ния желаемых целей, а также эффективно и легко выходить из сложных ситуаций.

· Пользователь имеет право на внимание со стороны системы, а также на то, чтобы иметь возможность получить ответ системы на запрос о внимании.

· Пользователь имеет право на то, чтобы система предоставляла четкую, понятную и точную информацию о выполняемой задаче и ее выполнении.

· Пользователь имеет право на то, чтобы его информировали о всех системных требованиях для успешного использования программного обеспечения или аппаратуры.

· Пользователь имеет право знать о пределах возможностей системы.

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

· Пользователь должен быть хозяином программных и аппаратных технологий, а не наоборот. Продукты должны использоваться естественно и интуитивно.

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

Требования надежности.

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

Доступность (availability). Система должна быть доступна для операционного использования в течение указанного времени (в процентном выражении). Иногда требование может указывать непрерывную "nonstop" доступность, т.е. 24 часа в сутки, 365 дней в году. Однако на практике чаще оперируют, к примеру, 99-процентной доступностью между 8 часами утра и полуночью. При этом следует определить, что понимается под "доступностью". Означает ли процентная доступность, что все пользователи должны иметь возможность использовать все системные услуги в любое время?

Среднее время между сбоями (mean time between failures, MTBF). Обычно оно указывается в часах, но может также указываться в днях, месяцах или годах. Здесь тоже нужна точность: требования должны четко определять, что понимается под "сбоем".

Среднее время восстановления (mean time to repair, MTTR). Как долго системе разрешается не работать после сбоя? MTTR может иметь несколько значений; например, пользователь может указать, что 90% всех системных сбоев должны ликвидироваться за 5 минут, а 99.9% — в течение часа. Вновь важна точность: требования должны четко указывать, означает ли восстановление, что все пользователи снова будут иметь возможность получать доступ ко всем услугам, или допускается частичное восстановление системы.

Точность (accuracy). Указывается точность в системах с числовым выводом. На­пример, должны ли результаты в финансовых системах приводиться с точностью до копеек или рублей, каково количество точек после запятой в системе, осуществляющей математические расчеты.

Количество различных ошибок. Обычно ошибки делятся на незначительные, серьезные и критические. Здесь также важны четкие определения: требования должны опреде­лять, что понимается под "критической" ошибкой — полная потеря данных или невоз­можность использовать определенную часть функциональных возможностей системы.

Требования производительности

При записи требований производительности обычно используют следующие характеристики:

· среднее и максимальное время ответа для транзакции;

· число транзакций в секунду, именуемое также пропускной способностью;

· емкость: количество пользователей или транзакций, которые система может обслуживать;

· допустимые режимы снижения производительности при ухудше­нии параметров работы системы.

Если новая система должна совместно с другими системами или приложениями ис­пользовать аппаратные ресурсы (ЦП, память, каналы, дисковую память, сетевой диапа­зон частот), может потребоваться указать, насколько "цивилизованно" она себя при этом ведет.

Возможность обслуживания

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

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

Но предположим, что налоговая инспекция периодически вносит в алгоритм расчета налога на добавленную стоимость существенные поправки, например следующего вида: "Разрешено ведение бухгалтерского учета по упрощенной схеме налогообложения. При этом предприятия, работающие по упрощенной схеме освобождены от уплаты НДС. Налог на прибыль в этом случае исчисляется как 10 процентов от оборота по счету юридического лица за отчетный период". Подобные модификации слож­нее предусмотреть в программе; хотя можно попытаться сделать ее максимально гибкой. Команда разработчиков, вероятно, согласится, что данная модификация попадает в категорию измене­ний "среднего уровня" сложности, для которых требование может задавать время реаги­рования — одна неделя.

Ограничения проектирования

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

Типы ограничений проектирования приведены в табл. 3.12.

Таблица 3.12. Типы ограничений проектирования.

Еще одним важным источником ограничений проектирования яв­ляются разнообразные инструкции и стандарты, которым подчиняется разработка проекта. Как правило, сформулированные в виде разнообразных инструкций проектные ограничения этого типа слишком длинные, чтобы их можно было непосредственно включить требования. В большинстве случаев достаточно внести их в список ограничений проектирования в форме ссылок. Однако при включении подобных ссылок тоже имеется определенный риск. Нужно внимательно следить за тем, чтобы включать конкретные, имеющие отношение к делу, а не общие ссылки. Например, одна ссылка вида: “Продукт должен соответствовать стандарту ISO 9001” фактически "связывает" продукт со всеми стандартами документа. Следует стремиться найти "золотую середину" между чрезмерной и недостаточной конкретизацией.

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

Следует отличать ограничения проектирования от других требований. Например, если требо­вания к ПО обозначены ярлыком "SR" (software requirement), для ограничений проек­тирования можно использовать ярлык "DC" (design constraint).

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

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

Следует документировать объяснения для каждого ограничения проектирования: несколько предложений, объясняющих причину наложения того или иного ограничения проектирования. Это поможет восстановить, что послужило мотивом для наложения конкретного ограничения.

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

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

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

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

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

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

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

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

· Дочернее 1. Прибор должен работать при напряжении в диапазоне Х1-X2 вольт АС.

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

· Дочернее 3. Прибор должен работать так, как указано в спецификации, если входная частота варьируется в пределах Х3-Х4 герц.

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

Лучше всего не отделять дочерние требования от родительских, а включать их в главный пакет требований. Чтобы при чтении проще было связать дочерние требования с родительским, обо­значение дочерних требований должно основываться на обозначении родительских. Предположим, что требование к программному обеспечению SR63.1 име­ет одно или несколько дочерних требований. Естественно будет обозначить дочерние требования SR63.1.1. SR63.1.2, SR63.1.3 и т.д.

При работе с требованиями, содержащими дочерние требования полезно иметь возможность расширять / сужать полный набор требований так, чтобы можно было рассматривать только родительские требования (отдельно) или родительские вместе с дочерними.

• ⇐ Назад
• 1
• 2
• 3
• 4
• 567
• Далее ⇒