И. Соммервилл - Инженерия программного обеспечения (1133538), страница 28
Текст из файла (страница 28)
Гк1. Здесь показано, как пользовательские требования могут быть преобразованы в сметенные. 5. Требования к программному обеспечению 107 Таблица 5.1. Пользовательские н системные требования Пользовательскиетребовання 1. ПО должно предоставить средство доступа к внешним файлам, созданным в других программах. Спецификация системных требований 1.1. Пользователь должен иметь возможность определять тип внешних файлов.
1.2. Для клхщого типа внешнего файла должно иметься соответствующее средство, при- менимое кэтомутипуфайлов. 1.$. Внешний файл каждого типа должен быть представлен соответствукяцей пикто. граммой на дисплее пользователя. 1.4. Пользователю должна быть предоставлена возможность самому определять пикто- грамму для каждого типа внешних файлов. 1.5.
При выборе пользователем пиктограммы, представляющей внешний файл, к этому файлу доллою быть применено средство, ассоциированное с внешними файлами данного типа. Пользовательские требования пишутся длл заказчика ПО и для лица, заключающего контракт на разработку программной системы, причем они мо~>т не иметь детальных технических знаний по разрабатываеиой системс (рнс.5.1). Спецификация системных требований предназначена для руководящего технического состава компании- разработчика н для менеджеров проекта.
Она также необходима заказчику ПО и с>бцодрядчикам по разработке. Этн оба документа также предназначены лля конечных полюо. вателей программной систеиы. Наконец, проектная системная спецификация явллетсл документом, который ориентирован на разработчиков ПО.
Рис. 5.1. Рпзличиыг тким сиецификлвий эфебовлииг> и их швыряли 10В х1асть Н. Требования 5.1. Функциональные и нефункциональные требования Требования к программной системе часто классифицируются как функциональные, нефункциональные и требования предметной области. 1. Функциональные требования Зто перечень сервисов, которые должна выполнять система. причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях н т.д.
В некоторых случаях указывается, что система не должна делать, 2. Нзу(ункцивюмьные тулбмания. Описывают характеристики сисгемы и ее окружения, а не поведение системы. Здесь также может быль приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ог раничения, ограничения на процесс разработки системы, сгандарты и тд. 3. Т(мбаваняя я)мячемиэй обгапли. Характеризуют ту предметную область, где будет эксплуатироваться система.
Зти требования мокнут быть функциональными и нефункциональными. В действительности четкой границы между этими типами требований не существует. Например, пользовательские требования, касающиеся безопасности системы, можно отнести к нефункциональным. Однако при более детальном рассмотрении такое требование можно отнести к функциональным, поскольку оно порождает необходимость включения в систему средства авторизации пользователя. Поэтому, рассматривая далее эти виды тре.
бованнй, мы должны всегда помнить, что данная классификация в значительной степени искусственна. 5.1.1. Функциональные требования Зги требования описывают поведение системы и сервисы (функции), которые она выполняет, н зависят от типа разрабатываеиой системы и от потребностей пользователей.
Если функциональные требования оформлены как пользовательские, они, как правило, описывают системы в обобщенном виде. В противоположность этому функциональные требования, оформленные как системные, описывают систему максимально подробно, включая ее входные и выходные данные, исключения и т.д, Функциональные требования для програминых систем могут быть описаны разными способами. Рассмотрим для примера функциональные требования к библиотечной системе университета, предназначенной для заказа книг н документов из других библиотек (20й). 1. Пользователь должен иметь возможность проводить поиск необходимых ему книг н документов или по всему множеству доступных каталожных баз данных или по определенному их подмножеству.
2. Система должна предоставллть пользователю подходящее средство просмотра библиотечных документов. 3. Каждый заказ должен быть снабжен уникальным идентификатором (ОКВЕВ 111), который копируется в формуляр пользователя для постоянного хранения. Зти функциональные пользовательские требования определяют свойства, которыми должна обладать система.
Онн взяты из документа, содержащего пользовательские требования, и показывают, что функциональные требования могут быть описаны с разным уровнем детализации (сравните первое и третье требования). б. Требования к программному обеспечению 109 Многие проблемы, возникающие при разработке систем, связаны с неточностью и "размытостью" спецификации требований. Естественно, разработчики интерпретируют требования, допускающие двоякое толкование, так, чтобы систему было проще реализовать. Но это толкование может не совпадать с ожиданиями заказчика. Такая ситуация приводит к разработке новых требований и внесению изменений в систему. Зто, в свою очередь, ведет к задержке сдачи готовой системы и ее удорожанию. Рассмотрим второе требование к библиотечной системе нз приведенного выше списка и обратим внимание на выражение "подходящее средство просмотра документов".
Библио. течная система может предоставлять документы в широком спектре форматов. В требовании подразумевается, что система должна предоставить средства для просмотра докумен сов в любом формате. Но поскольку это условие четко не выписано, разработчики в случае де. фицита времени могут использовать простое средство для просмотра текстовых документов и настаивать на том, что именно такое решение следует из данного требования. В принципе спецификация функциональных требований должна быть комплексной и непротиворечивой. Комплексность подразумевает описание (определение) всех системных сервисов.
Непротиворечивость означает отсутствие несовместимых и взаимоисключающих определений сервисов. На практике для больших и сложных систем крайне трудно разработать комплексгг)ю и непротиворечивую спецификацию функциональных требований. Причина кроется частично в сложности самой разрабатываемой системы, а частично — в несогласованных опорных точках зрения (см.
главу б) на то, что должна делать система. Зта несогласованность может не проявиться на этапе первоначального формулирования требований — для ее выявления необходим более глубокий анализ спецификации. Когда несогласованность системных функций проявится на каком-либо этапе жизненного цикла программы, в системную спецификацию придется внести соответст. вующие изменения. 5.1.2. Нефункциональные требования Как следует из названия, нефункциональные требованил не связаны непосредственно с функциями, выполняемыми системой.
Они связаны с такими интеграционными свойствами системы, как надежность, время с пита или размер системы. Кроне того, нефункциональные требования могут определять ограничения на систему, например на пропускную способносп устройств ввода-вывода, или форматы данных, используемых в системном интерфейсе. Многие нефункциональные требования относятся к системе в целом, а пе к отдельным ее средствам. Зто означает, что они более значимы и критичны, чем отдельные функцио. нальные требования. Ошибка, допущениал в функциональном требовании, может снизить качество системы, ошибка в нефункциональных требованиях может сделать систему неработоспособной. Вместе с тем нефункциональные требования могут относиться не только к самой программной систеие: одни мокнут относиться к технологическому процессу создания ПО, другие — содержать перечень стандартов качества, накладываемых на процесс разработки.
Кроме того, в спецификации нефункциональных требований может быть указано, что проектирование системы должно выполняться только определенными САБЕсредствамн, и приведено описание процесса проектирования, которому необходимо следовать. Нефункциональные требования отображают пользовательские потребности; при этом они основываются на бюджетных ограничениях, учитывают организационные возможности компании-разработчика и возможность взаимодействия разрабатываемой системы с другими программными и вычислительными системами, а также такие внешние факторы, как правила техники безопасности, законодательство о защите интеллектуальной собственности и т.п. На рис.
5.2 показана классификация нефункциональных требований. 110 Часть 11. Требования Ркс. 5.2. Ткям кефуккииокпзькмхтукбовпкий Все нсфункциональныс требования, показанные на рис. 5.2, я разбил на три большие группы. 1. Т)кбсэанкя к яРсдукэгу, Описывают эксплуатационныс свойства програимного про.
дукта. Сюда относятся трсбования к производительности системы, объему нсобхо. димой палгяти, надежности (опрсдсляст частоту возможных сбоев в системе), переносимости систсмы на разные компьютерные платформы и удобству эксплуатации. 2. ОРгаккзацнонны т~ейэвания. Отображают политику и организационныс процедуры заказчика и разработчика ПО. Они включают стандарты разработки программного продукта, требования к рсализации ПО (т.с. к языку программирования и мстодам проектирования), выходные требования, которые определяют сроки изготовления программного продукта, и сопутствующую докумсптацию. 3.
Внникие эязгйовакия. Учитывают факторы, внешние по отногпспию к разрабатываемой системс и процессу ес разработки. Они включают требования, определяющие вззииодсйствие данной системы с др)тими системами, юридические требования, слсдованис которым гарантирует, что система будст разрабатываться н функционировать в рамках существующего законодательства, а также этичсскис требования. Последние должны гарантировать, что система будет приемлемой лля пользователей или заказчика. Во врезке 5.1 приведсн пример трсбований к продукту, организационных и внешних требований. Требования к продукту связаны со срсдой программирования АРБЕ для языка Аба. Это ограничивает свободу проектировщика системы в выборе символов — можно использовать только символы из пользовательского интерфсйса АРБЕ.
Организационныс трсбования указывают, что система должна разрабатываться согласно внутреннему стандарту компании на разработку ПО, имеющему код ХУХСо-БР-БТА)Ч-95. Внешнис трсбова- б. Требования к программному обеспечению 111 пия вытекают из необходимости соблюдения законодательства о сохранении конфиденциальности. Вследствие этого системные операторы не будут иметь доступ к тем данным, которые нм не требуются для работы с системой.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
