Лекция 6. Заключительные этапы создания ПО. 2 страница

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

Вес нефункциональные требования, показанные на рис. 7.2, разбиты на три большие группы.

Требования к продукту. Описывают эксплуатационные свойства программного продукта. Сюда относятся требования к производительности системы, объему необходимой памяти, надежности (определяет частоту возможных сбоев в системе), переносимости системы на разные компьютерные платформы и удобству эксплуатации.

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

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

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

Таблица 7.2. Количественные показатели для нефункциональных требований

Показатель	Единицы измерения
Скорость	Количество выполненных транзакций в секунду; время реакции на действия пользователя; время обновления экрана
Размер	Килобайты; количество модулей памяти
Простота эксплуатации	Время обучения персонала; количество статей в справочной системе
Надежность	Средняя продолжительность времени между двумя последовательными проявлениями ошибок в системе; вероятность выхода системы из строя; коэффициент готовности системы
Устойчивость к сбоям	Время восстановления системы после сбоя; процент событий, приводящих к сбоям; вероятность порчи данных при сбоях
Переносимость	Процент машинно-зависимых операторов; количество машинно-зависимых подсистем

На практике выразить нефункциональные требования с помощью количественных показателей весьма затруднительно. Часто заказчик ПО не может оформить свое видение будущей системы посредством требований, выраженных количественными показателями. Либо некоторые системные требования, например удобство сопровождения, вообще нельзя выразить через количественные показатели. Кроме того, затраты на объективное измерение количественных нефункциональных требований могут оказаться крайне высокими. Поэтому часто документ, специфицирующий требования к системе, содержит описание системных целей совместно с четко сформулированными требованиями. Эти системные цели полезны, поскольку отражают представления (и приоритеты) заказчика о будущей системе. Вместе с тем заказчик должен понимать, что его системные цели могут трактоваться различными способами и их невозможно объективно проконтролировать.

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

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

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

В качестве примера рассмотрим требования к библиотечной системе.

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

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

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

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

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

Вместе с тем при описании требований на естественном языке могут возникнуть различные проблемы.

1. Отсутствие четкости изложения. Иногда нелегко изложить какую-либо мысль естественным языком четко и недвусмысленно, не сделав при этом текст многословным и трудночитаемым.

2. Смешение требований. В пользовательских требованиях отсутствует четкое разделение на функциональные и нефункциональные требования, на системные цели и проектную информацию.

3. Объединение требований. Несколько различных требований к системе могут описываться как единое пользовательское требование.

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

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

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

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

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

3. Используйте разные начертания шрифта (полужирное и курсив) для выделения ключевых частей требования.

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

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

Спецификация системных требований может строиться на основе различных системных моделей, таких, как объектная модель или модель потоков данных.

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

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

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

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

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

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

Таблица 8.1. Способы записи спецификаций требований

Система записи	Описание
Структурированный естественный язык	Использование стандартных форм и шаблонов для написания спецификации
Языки описания программ	Использование специальных структурированных языков, подобных языкам программирования, где спецификация требований строится на основе выбранной операционной модели системы
Графические нотации	Графический язык, использующий для описания функциональных требований диаграммы и блок-схемы, дополненные текстовыми пояснениями. Наиболее известный пример такого графического языка —диаграммы структурного анализа и проектирования ПО (SADT).
Математические спецификации	Это системы нотаций, основанные на математических концепциях, таких, как теория конечных автоматов или теория множеств. Это формализованная однозначная и лишенная двусмысленности запись системных требований. Однако многие заказчики ПО не понимают формальных спецификаций, вследствие чего возникают определенные проблемы при заключении контрактов на разработку программных продуктов.

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

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

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

3. Описание выходных данных с указанием пункта их назначения.

4. Указание, что необходимо для выполнения функции.

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

6. Описание побочных эффектов (если они есть).

Использование структурированного языка снимает некоторые проблемы, присущие спецификациям, написанным естественным языком, поскольку снижает «вариабельность» спецификации и более эффективно ее структурирует. Вместе с тем некоторая «размытость» определений и описаний в спецификации остается. Альтернативой использованию структурированного естественного языка может служить специальный язык описания спецификаций, который полностью снимает проблему нечеткости описания требований. Но с другой стороны, неспециалист найдет такую спецификацию трудной для чтения и понимания.

Для уменьшения присущей естественному языку нечеткости понятий при описании системных требований используется специальный язык описания программ (program description language— PDL). Этот язык подобен таким языкам программирования, как Java и Ada, но более абстрактен. Достоинством применения PDL для создания спецификации является то, что в такой спецификации можно проверить синтаксис и семантику существующими программными средствами. Эти проверки позволяют удалить ошибки и несогласованность в описании требований.

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

1. Если описываемая операция состоит из последовательности простых действий и важен порядок их выполнения. Описать такие последовательности действий на естественном языке порой затруднительно, поскольку их выполнение может сопровождаться вложенными условиями или они могут повторяться циклически. Этой ситуации соответствует спецификация системы обслуживания банкоматов, приведенная в листинге 8.1. Здесь в качестве PDL используется язык Java. В этом листинге приводится только часть спецификации, опустив описания некоторых сервисов.

2. Если необходимо специфицировать аппаратные или программные интерфейсы, так как практически во всех спецификациях системных требований приходится описывать интерфейсы.

Листинг 8.1. Спецификация системы управления банкоматами

//может породить исключительную ситуацию InvalidCard

thisCard.returnToUser («Пожалуйста, заберите карточку»);

{ Screen.printmsg («Недействительна карточка или Pin-код»);

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

Вместе с тем подход к построению спецификаций, основанный на PDL, имеет свои недостатки.

1. PDL, используемый для написания спецификации, может не иметь достаточных средств для описания всех системных функций.

2. Спецификации, созданные с помощью PDL, понятны только людям, имеющим определенные знания языков программирования.

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

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

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

Различают три типа специфицируемых интерфейсов.

1. Процедурные интерфейсы, когда существующие подсистемы предлагают набор сервисов, доступных посредством вызываемой интерфейсной процедуры.

2. Структуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой. В этом случае может использоваться PDL, основанный на языке программирования Java, который позволяет описать классы данных с соответствующими полями, формирующими структуру данных. Однако, для описания этого типа интерфейса наиболее подходят диаграммы «сущность-связь».

3. Специальные представления данных, например в виде упорядоченной последовательности двоичных разрядов. Язык Java не поддерживает такие детальные описания данных, поэтому не рекомендуется в подобном случае использовать PDL, основанный на языке Java.

Формальные нотации, позволяют описать интерфейсы четко и недвусмысленно. Однако такие спецификации понятны только специалистам, обладающим определенными знаниями. Формальные нотации редко используются на практике, хотя, с моей точки зрения, они идеально подходят для создания спецификаций интерфейсов. Менее формальные спецификации интерфейсов, полученные с помощью PDL, являются компромиссом между понятностью и точностью описания интерфейсов.

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

Листинг 8.2. Описание интерфейса сервера печати с помощью PDL

// предоставляет функции: initialize (инициализация),

Спецификация, приведенная в листинге 8.2, — абстрактная модель сервера печати без детализации интерфейсных частностей. Интерфейсные функции можно описать с помощью структурированного естественного языка посредством PDL, основанного на языке программирования Java (см. листинг 8.1), либо с помощью формальных нотаций, которые более подробно описаны далее.

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

Системную спецификацию читает множество разных людей, начиная от высшего руководства компании — заказчика системы и заканчивая рядовым разработчиком системы. На рис. 8.1 показаны категории читателей спецификации.

Хенингер (Heninger) сформулировал шесть условий, которым должна соответствовать спецификация программной системы.

- Описывать только внешнее поведение системы.

- Указывать ограничения, накладываемые на процесс реализации системы.

- Предусматривать возможность внесения изменений в спецификацию.

- Служить справочным средством в процессе сопровождения системы.

- Предусматривать реакцию системы и группы сопровождения на непредвиденные (нештатные) ситуации.

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

Многие организации, такие, как Министерство обороны США и Институт инженеров по электротехнике и радиоэлектронике IEEE, разработали собственные стандарты документирования спецификаций. Наиболее известный стандарт разработан IEEE и называется IEEE/ANSI 830-1993 [IEEE, 1993]. Данный стандарт предполагает следующую структуру спецификации.

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

Хотя стандарт IEEE не идеален, он может служить отправной точкой при написании спецификации. Конечно, при ее написании необходимо также учитывать стандарты, принятые в организации — разработчике ПО. В табл. 8.2 описаны возможные разделы спецификации, построенной на основании стандарта IEEE.

Таблица 8.2. Структура спецификации требований

Раздел	Описание
Предисловие	Здесь определяется круг лиц, на которых рассчитан данный документ. Описываются предыдущие версии разрабатываемого программного продукта, а также изменения, внесенные в каждую версию. Дается обоснование для создания новой версии продукта
Введение	Здесь более развернуто обосновывается необходимость создания системы. Кратко перечисляются системные функции, и объясняется, как система будет работать совместно с другими системами. Должно быть показано, как разработка системы «вписывается» в общую бизнес-стратегию компании, заказывающей программный продукт
Глоссарий	Дается описание технических терминов, используемых в документе. Здесь не делается каких-либо предположений об уровне знаний или практическом опыте читателя документа
Пользовательские требования	Описываются сервисы, предоставляемые пользователям, и нефункциональные системные требования. Это описание может быть сделано на естественном языке с использованием диаграмм, блок-схем и других форм записи, понятных заказчику программной системы. Здесь также должны быть приведены стандарты на программный продукт и процесс его разработки
Системная архитектура	Здесь приводится высокоуровневое представление возможной системной архитектуры с указанием, как распределены системные функции по компонентам системы. Обязательно должны быть выделены повторно используемые (т.е. уже существующие) компоненты
Системные требования	Подробно описываются функциональные и нефункциональные требования. Если необходимо, нефункциональные требования дополняются описанием интерфейсов других систем
Системные модели	Здесь представлено несколько системных моделей, показывающих взаимоотношения между системными компонентами и между системой и ее окружением. Это могут быть объектные модели, модели потоков данных или модели данных
Эволюция системы	Приводятся основные предположения и допущения, на которых базируется система, а также ожидаемые (прогнозируемые) изменения в аппаратных средствах, в потребностях пользователей и т.п.
Приложения	Здесь приводится специализированная информация, относящаяся к разрабатываемой системе, например описание аппаратных средств или базы данных, с которыми должна работать система. При описании аппаратных средств необходимо показать минимальную и оптимальную конфигурации, при которых может работать программная система. Описание базы данных должно отображать логическую структуру данных, с которыми будет работать система, и отношения между ними
Указатели	В документе возможно использование различных указателей. Это может быть обычный алфавитный указатель, указатель диаграмм или указатель системных функций