7.9 Заключение

Сценарии использования играют важную роль в процессе разработки программного обеспечения. Они:

• Помогают пользователям и системным аналитикам прийти к соглашению по поводу функциональности системы.

• Могут использоваться в качестве контракта между заказчиком и группой разработчиков.

• Являются основой для проектирования системы, создания документации и тестовых сценариев.

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

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

Сценарий использования описан в документе Спецификация Сценариев Использования (Use Case Specification). Его части описаны в пункте 7.5. Наиболее важная часть – это описание основного потока и альтернативных потоков как последовательности действий при взаимодействии действующего лица с системой.

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

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

Сценарии использования - очень удобный инструмент для хранения функциональных требований. Однако многие требования не могут быть с легкостью отображены с помощью сценариев использования. Такие требования хранятся в Дополнительной Спецификации, описанной в Главе 8 «Дополнительная Спецификация».

Ссылки

[AMB04] Ambler, Scott. The Object Primer: Agile Model-Driven Development with UML 2.0,

Third Edition.

[BIT02] Bittner, Kurt, and Ian Spence. Use Case Modeling, Boston: Addison-Wesley

Professional, 2002.

Глава 8

Дополнительная

Спецификация

Дополнительная Спецификация (Supplementary Specification) содержит все требования, которые не могут быть отражены в сценариях использования (use cases). Это не значит, что все функциональные требования отображены только в сценариях использования, и что все нефункциональные требования находятся только в Дополнительной Спецификации. Спецификация Сценариев Использования (Use Case Specification) также содержит нефункциональные требования, если они применяются к только одному сценарию использования. Дополнительная Спецификация содержит все основные функциональные требования, которые не связаны с определенным сценарием использования. Таблица 8.1. показывает, какой тип требований можно найти в определенном документе.

Таблица 8.1. Распределение Требований Между Спецификации Сценариев Использования и Дополнительной Спецификацией.

Тип Требования	Спецификация Сценариев Использования	Дополнительная Спецификация
Функциональные	Основной поток и альтернативные потоки, относящиеся к определенному сценарию использования.	Функциональные требования, относящиеся к более, чем одному сценарию использования.
Нефункциональные	Нефункциональная спецификация, относящаяся к только одному сценарию использования.	Нефункциональные требования, относящиеся ко многим сценариям использования.

Общее впечатление таково, что все функциональные требования находятся только в Спецификации Сценариев Использования, а нефункциональные – только в Дополнительной Спецификации. Так кажется потому, что:

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

• Функциональные требования чаще всего относятся к определенному потоку событий (поэтому они находятся в Спецификации Сценариев Использования).

Дополнительные требования также называют архитектурными требованиями [EEL01] или факторами качества [LAU02]. Эти понятия нельзя назвать полными синонимами дополнительным требованиям, но в контексте процесса разработке программного обеспечения они означают почти тоже самое.

Недавно в Rational Unified Process (RUP) название артефакта было изменено с «Дополнительной Спецификации» на «Дополнительные Спецификации» (в множественное числе) для отображения того факта, что мы можем использовать более чем один документ для хранения дополнительных требований.

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

Рисунок 8.1. Расположение дополнительных требований в пирамиде требований.

8.1 Сбор Дополнительных Требований

Сбор Дополнительных Требований является довольно сложной задачей по нескольким причинам:

• Заказчики часто забывают про эти требования и не предоставляют их, пока не будут заданы соответствующие вопросы.

• Заказчики обычно не в курсе о стоимости улучшения определенных возможностей.

• У нетехнических пользователей часто возникают проблемы с пониманием смысла некоторых технических требований.

• Некоторые требования являются сложными в измерении, например: «Система должна быть простой для обучения».

Следующий подход, который предложил Peter Eeles [EEL01], относится к следующим проблемам:

1. Создание списка всех категорий дополнительных требований.

2. Создание одного или более вопросов для каждой категории.

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

4. Сохранение ответов заказчика по каждому вопросу.

5. Назначение приоритетов или весомости каждому требованию.

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

Пункт 8.2 представляет пример списка требований.

Чаще всего эти типы требований собираются с помощью интервью и анкетирования. Обычно они не изменяются сильно в процессе перехода от потребностей к функциональным особенностям и далее к дополнительным требованиям. Eeles предлагает Вам создать новый тип требований – Дополнительный Запрос Заинтересованного Лица (Supplementary Stakeholder’s Request - SSTRQ) и отличать этот тип от требований от тех, которые уже находятся на уровне запросов заинтересованных лиц (верхний уровень – Потребности, см. Рисунок 8.1).

8.2 Классификация Дополнительных Требований

Много попыток было предпринято для классификации дополнительных требований. Одна из первых классификаций была опубликована McCall и Matsumoto [MCC80]. Она показана в Таблице 8.2. Международная Организация по Стандартизации использует классификацию, представленную в Таблице 8.3 [ISO91].

Таблица 8.2. Классификация, Предложенная McCall и Matsumoto.

Категория	Подкатегория
Операция	Целостность
	Правильность
	Надежность
	Удобство использования
	Продуктивность
Контроль	Способность к настройке
	Тестируемость
	Гибкость
Доставка	Портативность
	Взаимодействие
	Возможность многократного применения

Таблица 8.3. Классификация, Используемая ISO.

Категория	Подкатегория
Функциональность	Точность
	Защита
	Взаимодействие
	Приспособляемость
	Соответствие техническим условиям
Надежность	Совершенность
	Отказоустойчивость
	Восстанавливаемость
Удобство использования	Удобство использования
Продуктивность	Продуктивность
Способность к настройке	Тестируемость
	Изменяемость
	Способность к анализу
	Стабильность
Портативность	Приспособляемость
	Согласованность
	Взаимозаменяемость

Это книга следует классификации, которую предложил Robert Gray [CRA92] и которая используется в Rational Software. Эта классификация называется FURPS+, что расшифровывается как Functionality (Функциональность), Usability (Удобство использования), Reliability (Надежность), Performance (Производительность), Supportability (Способность к Сопровождению). Знак «+» - это место для различных типов ограничений на: Design (Дизайн), Interface (Интерфейс) и Physical (Аппаратное обеспечение). Шаблон Спецификации Программного Обеспечения (Software Specification) в RUP [RUP04] содержит следующие пункты:

• Online User Documentation (Он-лайн Документация Пользователя) и Help System Requirements (Требования к Справочной Системе).

• Purchased Components (Приобретенные Компоненты).

• Licensing Requirements (Требование по Лицензиям).

• Legal, Copyright and Other Notices (Юридические Нормы, Авторское Право и Другие Заметки).

• Applicable Standards (Допустимые Стандарты).

Существует некоторая свобода в размещении этих требований:

• Он-лайн Документация Пользователя и Требования к Справочной Системе могут быть включены в Functional Requirements (Функциональные Требования).

• Приобретенные Компоненты могут быть описаны в Implementation Constraints (Ограничения на Реализацию).

• Требование по Лицензиям могут быть скомбинированы с требованиями на Юридические Нормы и Авторское Право.

• Допустимые Стандарты могут быть описаны в Implementation Constraints (Ограничения на Реализацию) или в пункте Соответствие Техническим Условиям.

Шаблон RUP не выделяет требования Реализации и Аппаратного Обеспечения в отдельные пункты, т.к. они могут быть описаны в пункте Design Constraints (Ограничения на Дизайн).

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

Таблица 8.4. Категории Дополнительных Требований.

Категория	Подкатегория
Функциональность
Удобство использования	Доступность
	Эстетичность
	Соответствие интерфейсу пользователя
	Эргономичность
	Легкость в использовании
Надежность	Работоспособность
	Прочность
	Точность
	Восстанавливаемость
	Отказоустойчивость
	Безопасность
	Защита
	Корректность
Производительность	Скорость обработки информации
	Время ответа
	Время восстановления
	Время загрузки/выхода
	Емкость
	Использование ресурсов
Способность к сопровождению	Тестируемость
	Приспособляемость
	Способность к настройке
	Совместимость
	Способность к настройке конфигурации
	Способность к обновлению
	Способность к установке
	Расширяемость
	Портативность
	Возможность многократного применения
	Взаимодействие
	Соответствие техническим условиям
	Взаимозаменяемость
	Изменяемость
	Способность к анализу
	Способность к аудиту
	Способность к локализации
Ограничение на дизайн
Требования реализации
Требования интерфейса
Требования аппаратного обеспечения
Требования документации
Требования лицензий и юридических норм

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

Функциональность

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

Пример: Он-лайн справочник должен быть доступен из меню на каждой странице.

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

Удобство Использования

Понятие удобства использования многогранно. Этот пункт определяет требования по удобству использования в нескольких областях:

• Доступность

Легкость доступа к системе и использования особой функциональности.

Пример: Функциональность бронирования билета на самолет должна быть доступна с домашней страницы.

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

• Эстетичность

Эстетичность пользовательского интерфейса.

Пример: Поля ввода на одной странице должны быть выровнены вертикально.

• Соответствие интерфейсу пользователя

Соответствие пользовательскому интерфейсу.

Пример: Пользовательский интерфейс должен соответствовать стандарту IBM CUA. [CUA91a] [CUA91b]

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

• Эргономичность

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

Пример: При открытии диалогового окна акцент должен быть на первом поле ввода.

• Легкость в использовании

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

Пример: Для использования системы пользователи не должны обладать специальными техническими навыками (кроме умения пользоваться браузером).

Пример: Представитель службы услуг должен иметь возможность изучать систему он-лайн.

Пример: Среднее время процедуры бронирования номера в гостинице должно быть не более десяти минут.

Надежность

Этот пункт охватывает различные аспекты надежности системы:

• Работоспособность

Время доступности системы в процентах (среднее время между ошибочными состояниями).

Пример: Среднее время между отказами должно быть, по крайней мере, 30 дней.

Пример: Система должна быть доступна 99.93% времени.

• Прочность

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

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

• Точность

Точность, с которой система рассчитывает значения.

Пример: Денежные расчеты должны выполняться и храниться с точностью до двух десятых.

• Восстанавливаемость

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

• Отказоустойчивость

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

• Безопасность

Любая опасность по отношению к пользователям, данным, системным компонентам или системам, представленные в процессе использования системы.

• Защита

Уровень защиты относительно доступа к определенным модулям системы.

• Корректность

Насколько правильно система должна работать (без ошибок).

Пример: При выводе списка рейсов система не должна пропускать прямые рейсы или рейсы с одной остановкой.

Пример: После выпуска релиза система не должна иметь критических и важных ошибок, допускается не более чем 20 незначительных ошибок.

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

Производительность

Этот пункт охватывает различные указания к системной производительности.

• Скорость обработки информации

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

Пример: Система должна обрабатывать 1000 процедур бронирования билетов в минуту.

• Время ответа

Насколько быстро система отвечает на запросы.

Пример: Среднее время ответа системы должно быть менее двух секунд.

Пример: Среднее время отображения списка полетов должно быть не более десяти секунд.

Второе требование относится к определенному запросу, когда пользователь осуществляет поиск соответствующих рейсов в сценарии использования Бронирование рейса. В этой ситуации лучше всего включить его в пункт Special Requirements (Специальные Требования) в Спецификации Сценариев Использования (Use Case Specification). Требования этого пункта более приоритетны, чем основные требования Дополнительной Спецификации.

• Время восстановления

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

Пример: В случае отказа системы резервная система должна позволять выполнение операций в течение 30-ти секунд.

Пример: Среднее время восстановления должно быть менее часа.

• Время загрузки/выхода

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

Пример: Система должна быть работоспособной в течение одной минуты после загрузки.

• Емкость

Количество пользователей, которое система может обслуживать.

Пример: Система должна обслуживать 5000 пользователей одновременно.

• Использование ресурсов

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

Пример: Система должна хранить в базе данных не более чем один миллион транзакций. Если база данных превысила лимит, старые транзакции должны быть отправлены в резервное хранилище и затем удалены из операционной базы данных.

Эти требования могут быть также описаны в Implementation Requirements (Требования Реализации).

Способность к Сопровождению

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

• Тестируемость

Насколько легко тестировать систему. Требуется ли интеграция с каким-либо инструментом для тестирования?

Пример: Пользовательский интерфейс не должен содержать компонентов, препятствующих автоматическому тестированию с использованием IBM Rational Functional Tester.

• Приспособляемость

Насколько легко система адаптируется к новой программной среде.

Пример: Время развертывания на новой версии WebSphere Application Server должно занимать не более чем один день.

• Способность к настройке

Насколько легко находить и исправлять ошибки.

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

• Совместимость

Степень совместимости системы с предыдущими версиями системы, с заменяемой системой и с интерфейсами.

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

• Способность к настройке конфигурации

Степень конфигурирования системы после ее установки. Какие функции могут конфигурироваться?

• Способность к обновлению

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

Пример: Не должна требоваться установка на клиентском рабочем месте. Все системные обновления и новые релизы должны осуществляться на сервере.

Под способностью к настройке конфигурации и обновлению иногда понимают гибкость.

• Способность к установке

Легкая установка системы.

Пример: Установка новой версии системы не должно требовать никакой установки на рабочем месте пользователя.

• Расширяемость

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

Какое количество пользователей система должна поддерживать со временем

Пример: После шести месяцев работы, система должна иметь возможность обслуживать дополнительно 5000 пользователей.

• Портативность

Насколько легко перемещать систему на другое программное обеспечение или платформу.

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

• Возможность многократного применения

Насколько легко использовать части системы в других системах.

Пример: Главная функциональность системы (бронирование рейса, покупка билета на самолет, бронирование номера в гостинице, бронирование автомобиля) должна быть отражена в компонентах, которые могут быть использованы в приложении клиент/сервер (не через Интернет).

• Взаимодействие

Насколько легко взаимодействовать с другими системами.

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

Пример: Система должна автоматически бронировать билет с Airline Reservation System без необходимости вмешательства человека.

• Соответствие техническим условиям

Насколько хорошо система удовлетворяет всем стандартам и правилам.

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

• Взаимозаменяемость

Насколько легко заменять компоненты системы.

• Изменяемость

Насколько легко изменять функциональность системы.

• Способность к анализу

Насколько легко анализировать систему.

• Способность к аудиту

Насколько легко операции системы подвергаются аудиту.

• Способность к локализации

Какие языки поддерживает система. Насколько легко расширить систему новыми языками.

Пример: Приложение должно поддерживать Английский, Французский и Испанский языки.

Ограничения на Дизайн

Требования, относящиеся к системному дизайну и архитектуре.

Пример: Система должна быть основана на архитектуре J2EE.

Требования Реализации

Примеры требований реализации:

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

• Управление системами и их версиями.

• Используемая база данных.

• Сторонние компоненты.

• Ограничения на ресурсы: память, дисковое пространство.

• Стандарты кодирования.

Требования Интерфейса

Этот пункт описывает различные интерфейсы:

• Пользовательский интерфейс.

• Интерфейс аппаратного обеспечения.

• Интерфейс программного обеспечения.

• Интерфейс коммуникаций.

Требования Аппаратного Обеспечения

Требования Аппаратного Обеспечения обычно относятся только к оборудованию, на котором разворачивается система. Здесь можно указать, например, форму, размер или вес устройства. Это не относится к веб-приложениям.

Требования Документации

Требования к документации могут содержать:

• Распечатанная документация.

• Документация, доступная на СD.

• Документация, доступная он-лайн.

• Он-лайн справочник.

Пример: Руководство Администратора должно быть доступно в формате PDF.

Требования к он-лайн документации иногда описываются в пункте Functionality (Функциональность) Дополнительной Спецификации (Supplementary Specification).

Требования Лицензий и Юридических Норм

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

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

8.3 Извлечение Дополнительных Требований из Функциональных Особенностей

Многие функциональные особенности, определенные в документе Концепции (Vision), становятся дополнительными требованиями. Включение их в Дополнительную Спецификацию (Supplementary Specification) предоставляет возможность добавить больше деталей и упорядочить требования путем помещения их в определенные пункты. Один из подходов заключается в прохождении по всем функциональным особенностям, определении тех, которые не отражены в сценариях использования, и преобразования их в дополнительные требования. Довольно часто не нужно делать никаких изменений и мы можем просто использовать те же формулировки функциональных особенностей.

Среди всех функциональных особенностей, полученных в Главе 6 «Разработка Документа Концепции (Vision)», пятнадцать - нефункциональные требования, которые не были отражены ни в одном сценарии использования. Проанализируем каждое их этих требований и используем их в качестве основы для создания дополнительных требований.

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

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

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

FEAT11: Для основной функциональности должны присутствовать отдельные закладки.

FEAT12: На каждой странице кнопка Next (Далее) должна определять основной сценарий работы приложения.

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

FEAT23: Система должна использовать архитектуру J2EE.

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

Следующие два требования - ограничения реализации:

FEAT24: Если архитектура требует сервер приложения, должен быть использован IMB WebSphere.

FEAT25: Если система требует базу данных, должен быть использован Oracle.

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

SUPL: В качестве сервера приложения должен быть использован IMB WebSphere.

SUPL: В качестве базы данных должен быть использован Oracle.

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

FEAT34: Система должна быть полностью протестирована под следующими браузерами: Internet Explorer и Netscape.

Это требование должно иметь версию программного обеспечения:

SUPL: Система должна быть полностью протестирована под следующими браузерами: Internet Explorer (версии 6.0 и выше) и Netscape (версии 6.0 и выше).

Следующее требование – это требование надежности/работоспособности:

FEAT27: Система должна быть доступной 24 часа в сутки с уровнем надежности, соответствующим коммерческим приложениям.

Так как оно слишком общее, при преобразовании его в дополнительные требования мы можем разделить его на более точные утверждения:

SUPL: Система должна быть доступна 24 часа в сутки 7 дней в неделю.

SUPL: Среднее время между состояниями неработоспособности должно быть по крайней мере 20 часов.

SUPL: Система может быть недоступна не более чем одну минуту за 24 часа.

SUPL: Система должна быть доступна 99.93% времени.

Последние два требования эквивалентны. Они выражают одно и то же требование различными словами. Достаточно включить только одно из них.

Следующее требование – это требование способности к сопровождению/способности к настройке, но оно также может рассматриваться как требования удобства использования:

FEAT35: Все транзакции и ошибки должны быть записаны и доступны для администратора.

Так как лог ошибок и лог транзакций будут реализованы в отдельности друг от друга, в целях трассировки (установки связей) лучше всего разделить это требование на два:

SUPL: Все системные ошибки должны быть записаны и быть доступными для администратора.

SUPL: Все транзакции (покупка билета, выполнение заказа, изменение деталей заказа и удаление заказа) должны быть записаны и быть доступными для администратора.

Следующие два требования – это требования к надежности/защите:

FEAT26: Страницы, где представители служб сервиса предлагают свои услуги, должны быть защищены паролем. Представители гостиниц, агенты по найму автомобилей и представители авиалиний должны иметь свои ID (идентификаторы) и пароли для доступа к этим страницам.

FEAT29: Пользователи должны выбирать свой ID и предоставлять пароль при покупке билета.

Следующее требование довольно сложное:

FEAT36: Следующие отчеты должны быть доступны администратору:

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

Список всех заказов автомобилей за данный период времени.

Список всех заказов номеров гостиниц, за данный период времени.

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

• Откуда должны быть доступны отчеты.

• Какие атрибуты должны быть доступны для поиска.

• Как выбирать доступные отчеты.

В этой ситуации лучше создать отдельный сценарий использования, чем включать требование в Дополнительную Спецификацию (Supplementary Specification).

Следующее требование описывает не саму систему, а требование к разработке системы:

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

Наилучшее место для хранения этого требования – это Контракт или План Работ, но не документация требований к системе. Тем не менее, если мы хотим включить его в Дополнительную Спецификацию (Supplementary Specification), мы можем создать отдельный пункт Development Process Requirement (Требования Процесса Разработки). Вот несколько других требований, которые могут попасть в эту же категорию:

Пример: Разработка должна быть сделана в помещении заказчика.

Пример: Группа тестирования должна включать, по крайней мере, два тестера для ручного тестирования и два тестера с опытом в Rational Robot.

Пример: Система должна быть разработана с использованием RUP.

8.4 Атрибуты Дополнительных Требований

Атрибуты, установленные по умолчанию у дополнительных требований:

Priority (Приоритет)	Author (Автор)
Status (Статус)	Location (Расположение)
Difficulty (Сложность) Stability (Устойчивость)	Enhancement Request (Запрос на Обновление)
Risk (Риск)	Defect (Ошибка)
Contact Name (Имя Контакта)	Obsolete (Недействительный)

Этот список может немного меняться в зависимости от версии RequisitePro.

Некоторые требования (особенно относительно производительности) могут различаться в зависимости от количества пользователей. В этом случае мы можем использовать метод, который предложил Mark Lines: создать таблицу с требованиями производительности по числу одновременных пользователей, чтобы показать приемлемое уменьшение. В Таблице 8.5. показан пример. Вам может понадобиться отдельная таблица для каждой транзакции сценария использования.

Таблица 8.5. Дифференцирование Требований в Зависимости от Количества Одновременных Пользователей.

Количество Одновременных Пользователей	Максимальное Время транзакции (сек)
от 1 до 10	3
от 11 до 50	5
от 51 до 100	7
Более чем 100	10

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

Importance (Важность)

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

Приложение должно быть доступно для пользователей браузера Internet Explorer.

Если Internet Explorer системой не поддерживается, наибольшая часть пользователей Интернет не будет иметь возможность пользоваться приложением.

Некоторые требования – желаемые:

Последующие формы экрана должны появляться менее чем через две секунды.

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

Некоторые требования – не так важны:

Система должна быть работоспособной в течение одной минуты после запуска.

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

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

Для хранения уровня важности, мы можем создать новый атрибут Важность (Importance) с тремя возможными значениями:

• Mandatory (Обязательный).

• Desirable (Желаемый).

• Nice to have (Возможный).

Если Вы не хотите создавать новый атрибут, Вы можете использовать Priority (Приоритет) для хранения этих значений (тем не менее, приоритет и важность не совсем синонимы).

Satisfaction Shape (Степень Удовлетворенности)

Другой атрибут, применимый к дополнительным требованиям - это степень удовлетворенности (satisfaction shape). Этот атрибут описывает, как степень удовлетворенности заказчика меняется в зависимости от качества исполнения требуемых характеристик.

Степень удовлетворенности может иметь следующие значения:

• Sharp (Точная): Характеристики требования должны быть реализованы в точности так, как описаны в требовании. Результат не может быть даже на немного хуже.

• Medium (Умеренная): Значение результата должно быть близко к ожидаемым значениям. Однако допускается небольшое расхождение.

• Linear (Линейная): Чем лучше результат, тем выше удовлетворенность. Однако точных ожидаемых значений не приводится.

Проанализируем несколько примеров.

Точная Степень Удовлетворенности (Sharp Satisfaction Shape)

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

В этом случае время ответа должно быть меньше одной секунды, иначе вся система не будет работать. Но не важно, если это будет выполняться за 0.99 секунд или 0.5 секунд. Нет дополнительного значения для получения более короткого времени ответа.

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