Управление Требованиями (RequisitePro)
advertisement
Содержание
Предисловие .............................................................................................................................................................. 7
Вступление .................................................................................................................................................................. 8
Благодарности ........................................................................................................................................................ 11
Об Авторе ................................................................................................................................................................... 12
ЧАСТЬ 1: ОБЗОР........................................................................................................... 13
ГЛАВА 1 Управление Требованиями.................................................................................................... 14
1.1 Определение Требования и Заинтересованного Лица ............................................................... 14
1.2 Пирамида Требований ............................................................................................................................... 15
1.3 Трассировка (Связь) между Требованиями ..................................................................................... 16
1.4 Характеристики Хорошего Требования ............................................................................................. 16
Недвусмысленность........................................................................................................................................ 17
Тестируемость (Возможность Проверки).............................................................................................. 18
Ясность (Краткость, Сжатость, Простота, Точность) ...................................................................... 19
Корректность ..................................................................................................................................................... 19
Понятность ......................................................................................................................................................... 19
Правдоподобность (Реальность, Выполнимость) ............................................................................. 19
Независимость .................................................................................................................................................. 19
Элементарность ............................................................................................................................................... 19
Необходимость ................................................................................................................................................. 20
Независимость от Реализации (Абстрактность) ................................................................................ 20
Постоянство ....................................................................................................................................................... 20
Немногословность ........................................................................................................................................... 21
1.5 Обзор Процесса Управления Требованиями.................................................................................... 21
Формирование Плана Управления Требованиями ........................................................................... 22
Сбор Требований ............................................................................................................................................. 23
Разработка Документа Концепции (Vision) ......................................................................................... 24
Создание Сценариев Использования (Use Cases) ........................................................................... 24
Дополнительная Спецификация .............................................................................................................. 25
Создание Тестовых Сценариев (Test Cases) из Сценариев Использования ........................ 26
Создание Тестовых Сценариев (Test Cases) из Дополнительной Спецификации ............ 26
Проектирование Системы ............................................................................................................................ 27
1.6 Заключение..................................................................................................................................................... 28
Ссылки ...................................................................................................................................................................... 28
ГЛАВА 2 Обзор RequisitePro ....................................................................................................................... 29
2.1 Интерфейс ....................................................................................................................................................... 29
Explorer (Проводник) ..................................................................................................................................... 30
Views (Область Представлений) ............................................................................................................... 31
Toolbar (Панель Инструментов) ................................................................................................................ 33
2.2 Рабочее Пространство Word.................................................................................................................... 33
2.3 Документы ....................................................................................................................................................... 34
2.4 Требования ..................................................................................................................................................... 35
2.5 Заключение..................................................................................................................................................... 35
1
ЧАСТЬ 2: ДЕЙСТВИЯ ПО УПРАВЛЕНИЮ ТРЕБОВАНИЯМИ ..................................... 36
ГЛАВА 3 Формирование Плана Управления Требованиями ................................................ 37
3.1 Когда Создается Документ RMP............................................................................................................. 37
3.2 Решения, Которые Могут Быть Оформлены в Документе RMP ............................................... 37
Будет Использоваться Инструмент Управления Требованиями? .............................................. 37
Какие Типы Требований Будут Присутствовать в Проекте? ....................................................... 38
Каковы Атрибуты Этих Требований? ..................................................................................................... 39
Где Будут Создаваться Требования - в Базе Данных или в Документах? ............................ 41
Между Какими Требованиями Должна Осуществляться Трассировка? .................................. 42
Какие документы необходимы? ................................................................................................................ 42
Какие Требования и Документы Будут Использоваться как Контракт с Заказчиком? ... 43
Если Часть Проекта Разрабатывается Сторонними Исполнителями, Какие Требования
и Документы Будут Использоваться как Контракт со Сторонними Разработчиками? ..... 43
Нужно Следовать RUP или Какой-либо Другой Методологии? .................................................. 43
Нужны Заказчику Особые Документы для Осуществления Разработки? ............................. 43
Как Будет Осуществляться Управление Изменениями? ................................................................ 43
Будет ли Вся Система Храниться в Одном Проекте RequisitePro, или Будет Разделена
на Несколько Проектов? .............................................................................................................................. 43
Какой Процесс Будет Гарантировать, Что Все Требования Будут Выполнены и
Протестированы?............................................................................................................................................. 44
Какие Требования или Представления Необходимы для Генерации Отчетов?.................. 44
3.3 Пример Плана Управления Требованиями ....................................................................................... 44
3.4 Заключение..................................................................................................................................................... 44
Ссылки ...................................................................................................................................................................... 44
ГЛАВА 4 Настройка Проекта ...................................................................................................................... 45
4.1 Настройка Проекта RequisitePro ............................................................................................................ 45
Добавление Атрибутов Требования ........................................................................................................ 48
Изменение Значений Атрибутов Требования ..................................................................................... 49
Импорт Документа .......................................................................................................................................... 51
4.2 Настройка Проекта Rational .................................................................................................................... 52
4.3 Заключение..................................................................................................................................................... 57
ГЛАВА 5 Сбор Требований .......................................................................................................................... 58
5.1 Определение заинтересованных лиц ................................................................................................. 58
5.2 Методы сбора требований ....................................................................................................................... 59
Интервью ............................................................................................................................................................. 61
Анкеты .................................................................................................................................................................. 64
Семинары ............................................................................................................................................................ 65
Использование сценариев .......................................................................................................................... 66
Ролевые игры .................................................................................................................................................... 67
Метод «Мозгового Штурма» (Brainstorming Sessions) ................................................................... 68
Диаграммы Сходства ..................................................................................................................................... 69
Использование Прототипов ........................................................................................................................ 69
Анализ Существующих Документов ....................................................................................................... 69
Сценарии Использования (Use Cases) .................................................................................................. 70
Наблюдение и демонстрирование задач .............................................................................................. 70
Анализ Существующих Систем ................................................................................................................. 71
5.3 Создание Документа Запросов Заинтересованного Лица ......................................................... 71
Открытие Проекта ........................................................................................................................................... 72
Добавление Типа Документа в Проект .................................................................................................. 72
Создание Документа Запросов Заинтересованного Лица ............................................................ 73
5.4 Создание Требований в RequisitePro .................................................................................................. 76
Добавление Требований в Документ ..................................................................................................... 77
Изменение Атрибутов Типов Требований ............................................................................................ 79
Добавление Требований из Проводника .............................................................................................. 80
Изменение Требований из Проводника ................................................................................................ 81
Удаление Требований из Проводника ................................................................................................... 81
2
5.5 Создание Views (Представлений) для Анализа Требований .................................................... 81
Создание Матрицы Атрибутов ................................................................................................................... 81
Открытие View (Представления) .............................................................................................................. 82
Экспорт Представлений (Views) ............................................................................................................... 84
Создание Запросов для Требований ...................................................................................................... 84
5.6 Заключение..................................................................................................................................................... 85
Ссылки ...................................................................................................................................................................... 85
ГЛАВА 6
Разработка Документа Концепции (Vision) ........................................................... 86
6.1 Структура Документа Концепции ......................................................................................................... 86
6.2 Извлечение Функциональных Особенностей из Потребностей Заинтересованных Лиц
...................................................................................................................................................................................... 87
6.3 Атрибуты Функциональных Особенностей ....................................................................................... 94
6.4 Создание Документа Концепции (Vision) в RequisitePro ............................................................ 96
6.5 Создание Функциональных Требований (FEAT) ............................................................................ 97
6.5 Трассировка .................................................................................................................................................... 99
6.7 Представления ............................................................................................................................................ 101
Доступ к Предварительно Созданному Представлению.............................................................. 101
Установка Трассировки .............................................................................................................................. 102
Удаление Трассировки ................................................................................................................................ 103
Изменение требований в Представлении .......................................................................................... 103
Запросы ............................................................................................................................................................. 103
Подозрительная Трассировка .................................................................................................................. 104
Другие Операции над Представлениями............................................................................................ 105
Дерево Трассировки (Traceability Tree) .............................................................................................. 105
6.4 Заключение................................................................................................................................................... 107
Ссылки .................................................................................................................................................................... 107
ГЛАВА 7 Создание Сценариев Использования (Use Cases) ............................................... 108
7.1 Определение Действующих Лиц ......................................................................................................... 109
7.2 Определение Сценариев Использования ........................................................................................ 110
7.3 Диаграммы Сценариев Использования ............................................................................................ 111
7.4 Структурирование Модели Сценариев Использования ............................................................ 113
Отношение Включения (Include Relationship) .................................................................................. 113
Отношение Расширения (Extend Relationship) ................................................................................ 113
Отношение Обобщения (Generalization Relationship) ................................................................... 114
Отношение Обобщения между Действующими Лицами .............................................................. 114
7.5 Документ Спецификации Сценариев Использования ............................................................... 115
Краткое описание (Brief Description) ................................................................................................... 116
Основной Поток (Basic Flow).................................................................................................................... 116
Альтернативный Поток (Alternative Flow) .......................................................................................... 116
Особые Требования (Special Requirements) ..................................................................................... 118
Предусловия (Preconditions) .................................................................................................................... 118
Постусловия (Postconditions) ................................................................................................................... 118
Точки Расширения (Extension Points) .................................................................................................. 118
Контекстная Диаграмма (Context Diagram) ...................................................................................... 118
Диаграмма Активности (Activity Diagram) ......................................................................................... 120
Диаграмма Состояний(State Machine Diagram) ............................................................................... 120
Сценарии (Scenario, Алгоритмы) ........................................................................................................... 121
7.6 Сценарии (Scenario, Алгоритмы) ........................................................................................................ 121
7.7 Сценарии Использования (Use Cases) в RequisitePro. .............................................................. 123
Создание Спецификации Сценариев использования (Use Case Specification) ................. 124
Создание Требований ................................................................................................................................. 125
7.8 Создание Нового Типа Требований в RequisitePro. .................................................................... 127
7.9 Заключение................................................................................................................................................... 128
Ссылки .................................................................................................................................................................... 129
ГЛАВА 8 Дополнительная Спецификация ....................................................................................... 130
8.1 Сбор Дополнительных Требований ................................................................................................... 131
3
8.2 Классификация Дополнительных Требований ............................................................................. 131
Функциональность ........................................................................................................................................ 134
Удобство Использования ........................................................................................................................... 134
Надежность ...................................................................................................................................................... 135
Производительность .................................................................................................................................... 135
Способность к Сопровождению .............................................................................................................. 136
Ограничения на Дизайн ............................................................................................................................. 138
Требования Реализации ............................................................................................................................. 138
Требования Интерфейса ............................................................................................................................ 138
Требования Аппаратного Обеспечения .............................................................................................. 138
Требования Документации ....................................................................................................................... 138
Требования Лицензий и Юридических Норм ................................................................................... 138
8.3 Извлечение Дополнительных Требований из Функциональных Особенностей ............ 139
8.4 Атрибуты Дополнительных Требований .......................................................................................... 141
Importance (Важность) ............................................................................................................................... 141
Satisfaction Shape (Степень Удовлетворенности) .......................................................................... 142
8.5 Ввод Дополнительных Требований в RequisitePro ...................................................................... 144
8.6 Трассировка к Дополнительным Требованиям ............................................................................. 148
Установка Атрибута Тип (Type) Функциональным Особенностям .......................................... 148
Установка Трассировки (Связей) ........................................................................................................... 150
Создание Запросов для Требований .................................................................................................... 153
8.7 Заключение................................................................................................................................................... 155
Ссылки .................................................................................................................................................................... 155
ГЛАВА 9
Создание Тестовых Сценариев (Test Cases) из Сценариев
Использования (Use Cases) ......................................................................................................................... 157
9.1 Создание Тестовых Сценариев ............................................................................................................ 158
Шаг 1: Определение Переменных для Каждого Шага Сценариев Использования ........ 158
Шаг 2: Определение Существенно Различных Вариантов для Каждой Переменной .... 159
Шаг 3: Комбинирование Вариантов для Тестирования в Тестовые Сценарии ................. 163
Шаг 4: Определение Значений Переменных ................................................................................... 168
9.2 Бизнес-правила .......................................................................................................................................... 170
9.3 Создание Нового Типа Документов ................................................................................................... 170
9.4 Добавление Сценариев (Алгоритмов) и Тестовых Сценариев .............................................. 172
Создание Новой Папки ............................................................................................................................... 172
Создание Документа .................................................................................................................................... 172
Добавление Требований из Explorer (Проводника) ...................................................................... 173
9.5 Установка Трассировки ........................................................................................................................... 174
9.6 Заключение................................................................................................................................................... 177
Ссылки .................................................................................................................................................................... 177
ГЛАВА 10 Создание Тестовых Сценариев (Test Cases) из Дополнительных
Требований ............................................................................................................................................................. 178
10.1 Выполнение Выбранных Тестовых Сценариев в Различных Программных Средах . 179
10.2 Добавление Дополнительной Проверки во Все Сценарии Использования .................. 179
10.3 Проверка и Обновление Определенных Сценариев Использования .............................. 181
10.4 Выполнение Задач .................................................................................................................................. 181
10.5 Список Проверок ..................................................................................................................................... 182
10.6 Анализ........................................................................................................................................................... 182
10.7 Тестирование по Принципу «Стеклянного Ящика» ................................................................. 183
10.8 Автоматическое Тестирование .......................................................................................................... 183
10.9 Использование Robot и Test Manager для Автоматического Тестирования ................. 184
Запись скрипта VU (Виртуальных Сессий) ........................................................................................ 184
Как Запустить Пакет в Rational Test Manager .................................................................................. 187
Анализ Результатов ...................................................................................................................................... 192
10.10 Заключение.............................................................................................................................................. 194
Ссылки .................................................................................................................................................................... 194
ГЛАВА 11 Объектно-Ориентированное Проектирование ..................................................... 195
4
11.1 Проектирование Системы из Сценариев Использования (Use Case) .............................. 195
11.2 Использование IBM Rational Rose для Проектирования ........................................................ 206
Создание Новой Модели ............................................................................................................................ 206
Создание Диаграммы Классов ................................................................................................................. 206
Формирование Взаимосвязей .................................................................................................................. 208
Создание Диаграммы Последовательностей .................................................................................... 210
11.3 Использование IBM Rational Software Architect для Проектирования ............................. 211
Создание Проекта ......................................................................................................................................... 211
Создание Диаграммы Сценариев ........................................................................................................... 214
Создание Диаграммы Классов ................................................................................................................. 214
Создание Диаграммы Последовательностей .................................................................................... 216
Публикация Проекта .................................................................................................................................... 217
11.4 Заключение ................................................................................................................................................ 218
Ссылки .................................................................................................................................................................... 219
ГЛАВА 12 Документация ............................................................................................................................ 220
12.1 Типы Документации ............................................................................................................................... 220
Внутренняя Документация ........................................................................................................................ 220
Техническая Документация ...................................................................................................................... 220
Пользовательская Документация .......................................................................................................... 221
Маркетинговые Материалы ...................................................................................................................... 221
12.2 Документы в RequisitePro .................................................................................................................... 221
Создание Документа из Доступного Типа Документов ................................................................ 222
Добавление Нового Типа Документов ................................................................................................. 223
Создание Нового Типа Документов ...................................................................................................... 224
Импорт Документа ........................................................................................................................................ 224
12.3 Использование IMB Rational SoDA ................................................................................................... 224
Генерация Отчета из RequisitePro ......................................................................................................... 225
Генерация Отчета из SoDa ....................................................................................................................... 225
12.4 Заключение ................................................................................................................................................ 228
Ссылки .................................................................................................................................................................... 228
ЧАСТЬ 3: ДРУГИЕ ТЕМЫ ........................................................................................... 229
ГЛАВА 13 Управление Проектами ....................................................................................................... 230
13.1 Распечатка Сводки по Проекту ......................................................................................................... 230
13.2 Типы Файлов RequisitePro.................................................................................................................... 231
13.3 Архивация Проектов .............................................................................................................................. 232
13.4 Перемещение и Копирование Проектов ....................................................................................... 233
13.5 Трассировка Между Проектами ........................................................................................................ 233
13.6 Заключение ................................................................................................................................................ 235
Ссылки .................................................................................................................................................................... 235
ГЛАВА 14 Управление Требованиями В RUP (Rational Unified Process) .................. 236
14.1 Rational Unified Process (RUP) ............................................................................................................ 236
14.2 Пирамида Требований и RUP ............................................................................................................. 238
Начальная фаза (Inception) ..................................................................................................................... 241
Проектирование (Elaboration) ................................................................................................................. 242
Построение (Construction)......................................................................................................................... 243
Внедрение (Transition) ................................................................................................................................ 244
14.3 Пирамида Требований и Модель Водопада (Waterfall) .......................................................... 244
14.4 Переход от модели Водопада к RUP с Использованием Пирамиды Требований ........ 246
14.5 Заключение ................................................................................................................................................ 247
Ссылки .................................................................................................................................................................... 247
ЧАСТЬ 4: РЕЗЮМЕ...................................................................................................... 248
ГЛАВА 15 Заключение ................................................................................................................................. 249
5
15.1 Обобщение Подхода Пирамиды к Процессу Управления Требованиями ....................... 249
15.2 Преимущества ........................................................................................................................................... 251
15.3 RequisitePro ................................................................................................................................................ 251
Приложение Пример Плана Управления Требованиями ...................................................... 252
1 Введение ........................................................................................................................................................... 252
1.1 Назначение ............................................................................................................................................. 252
1.2 Область Применения ........................................................................................................................... 252
1.3 Обзор .......................................................................................................................................................... 252
2 Инструменты, Программная Среда и Инфраструктура ................................................................. 252
3 Документы и Типы Требований ............................................................................................................... 252
3.1 Документы ................................................................................................................................................ 252
3.2 Типы Требований .................................................................................................................................. 253
3.3 Трассировка ............................................................................................................................................. 253
3.4 Атрибуты Требований ......................................................................................................................... 254
3.5 Отчеты и Измерения ............................................................................................................................ 256
6
Предисловие
В течение многих лет я вел курсы по лучшим методикам Управления Требованиями
(Requirements Management) с использованием Сценариев Использования (Use Cases), а
также применение этих методик вместе с лидирующим в этой области инструментом IBM
Rational PequisitePro. В каждом курсе своим студентам я люблю рекомендовать книгу, на
которую они могут ссылаться для получения дополнительного материала (чтобы
подтвердить теорию). К счастью, существует несколько замечательных изданий, которые
я всегда рекомендую.
При изучении различных направлений в управлении требованиями, например
управления изменениями, анализа области применения, расстановки приоритетов и
трассировки (связи), становится очевидным, что достижение успехов без использования
соответствующего инструмента довольно проблематично.
Таким образом, при чтении курса RequisitePro, для меня стало разочарованием
отсутствие изданий, которые действительно показывают, как правильно использовать этот
замечательный инструмент. К счастью, Peter наконец показал в этой книге, как можно
соединить лучшие методики по управлению требований с хорошим инструментом для
упорядочивания процесса требований.
Более того, он показал нам, как хорошо структурированные и оформленные
требования становятся естественным материалом для умело спроектированного
программного обеспечения с объектно-ориентированным анализом и проектированием, а
также использованием дополнительных инструментов IMB Rational.
Я очень долгое время ждал такой книги, как это издание, чтобы я мог рекомендовать
ее моим студентам на курсах RequisitePro. Если сейчас Вы используете IMB Rational
RequisitePro или только еще рассматриваете преимущества этого замечательного
инструмента, эта книга будет Вам лучшим помощником.
—Mark Lines
Учредитель, UPMentors.com
7
Вступление
Один из наиболее важных элементов при разработке программного обеспечения –
управление требованиями (Requirements Management, RM). Это систематический подход к
сбору, организации, документированию
и отслеживанию
требований системы.
Надлежащее управление требованиями помогает проверять систему, управлять
изменениями и анализировать статус проекта. Намного дешевле исправлять проблемы в
течение процесса анализа требований, чем на стадии проектирования, тестирования или
выпуска релиза. Несмотря на этот факт, RM часто игнорируется. На этот процесс отводят
очень мало времени.
Научная исследовательская работа CHAOS, которую выполнил в 1995 году Standish
Group, указала на три фактора, которые не позволяют выпускать проект вовремя,
придерживаться установленного бюджета и предоставлять требуемую заказчику
функциональность:
Недостаток данных от пользователей.
Незаконченные требования и спецификации.
Изменение требований и спецификаций.
Осуществляемое должным образом управление требованиями может улучшить все
три фактора.
О Чем Эта Книга
Использование инструмента для управления требованиями поможет организовать
процесс, а также способствовать созданию и настройке требований. Один из наиболее
популярных инструментов – это IBM Rational RequisitePro. (Для простоты, далее в книге он
называется просто RequisitePro). Эта книга предоставляет практическую инструкцию по
использованию этого инструмента. В конце каждой главы, описывающей шаг процесса
управления требованиями, рассматривается, каким образом RequisitePro может
способствовать реализации этого шага. Это первая книга, которая содержит в себе
описание функциональных особенностей RequisitePro вместе с их практическим
применением. Использование этого инструмента показано на основе простого проектаобразца. Примеры показывают создание наиболее важных документов (Use Cases –
Сценариев Использования, Vision – Концепции и Supplementary Specification –
Дополнительной Спецификации), создание и настройку требований проекта, трассировку
(связь) между типами требований, а также наиболее важные шаги по работе с
требованиями. Для лучшего понимания, документы и другие артефакты созданы в таком
же порядке, в каком они создаются в настоящем проекте.
Online Travel Agency (Он-лайн Агентство Путешествий) - это пример проекта, который
иллюстрирует применение RequisitePro для управления требованиями и документами. Этот
проект представляет собой веб-приложение. Оно имеет сходство с приложениями,
которые могут быть найдены на сайтах www.travel.yahoo.com, www.expedia.com
и
www.travelocity.com.
8
Как Организована Эта Книга
Книга рассматривает организованный подход к управлению требованиями. Каждый
основной шаг описан в отдельной главе. Главы относятся к действиям по управлению
требованиями, включая создание Плана Управления Требованиями (RM Plan), сбор
потребностей заинтересованных лиц, создание документа Концепции (Vision) и создание
сценариев использования (use cases). Эти действия представляются в хронологической
последовательности. Тем не менее, т.к. проект по разработке программного обеспечения
подразумевает сложный процесс с большим количеством итераций и сложными
отношениями между этими действиями, описанные шаги могут выполняться в другом
порядке. Выполняемые различными людьми действия часто перекрывают друг друга, а
многие действия, выполняемые одним и тем же лицом, повторяются в течение процесса.
Эта книга также учит техникам современного управления требованиями, такой как
трассировке.
Часть 1 «Обзор» содержит пару глав, которые предоставляют обзор требований и
RequisitePro. Глава 1 «Управление Требованиями» представляет обзор процесса
управления требованиями. В главе описаны разные типы требований. Отношения между
этими требованиями показаны в форме пирамиды требований. Глава 2 «Обзор
RequisitePro» описывает RequisitePro.
Процесс управления требованиями разделяется на следующие шаги:
1. Формирования Плана Управления Требованиями
2. Настройка Проекта
3. Сбор Требований
4. Разработка Документа Концепции (Vision)
5. Создание Сценариев Использования (Use Cases)
6. Дополнительная Спецификация
7. Создание Тестовых Сценариев (Test Cases) из Сценариев Использования (Use
Cases)
8. Создание Тестовых Сценариев (Test Cases) из Дополнительных Требований
9. Проектирование Системы
10. Создание остальных документов
Эти шаги описаны в этом же порядке в Главах с 3 по 12. В конце большинства этих
глав включены примеры, показывающие, как описанные действия по управлению
требованиями могут быть выполнены на практике с использованием RequisitePro. Шаги с 3
по 9 относятся к созданию элементов в пирамиде требований (см. Главу 1, Рисунок 1.1).
В Части 2 «Действия по Управлению Требованиями» Главе 2 «Формирования Плана
Управления Требованиями» и Главе 4 «Настройка Проекта» описано, как структурировать
весь процесс.
Остальные главы, относящиеся к шагам процесса управления требованиями:
Глава 5 «Сбор Требований»
Глава 6 «Разработка Документа Концепции (Vision)»
Глава 7 «Создание Сценариев Использования (Use Cases)»
Глава 8 «Дополнительная Спецификация»
Глава 9 «Создание Тестовых Сценариев (Test Cases) из Сценариев Использования
(Use Cases)»
Глава 10 «Создание Тестовых Сценариев (Test Cases) из Дополнительных
Требований»
Глава 11 «Объектно-Ориентированное Проектирование»
Глава 12 «Документация»
В Части 3 «Другие Темы» Главе 12 «Управление Проектами» описаны некоторые
дополнительные функциональные особенности RequisitePro относительно процесса
управления проектом. Глава 14 «Управление Требованиями в RUP (Rational Unified
Process)» показывает отношения между пирамидой требований и Rational Unified Process.
В последней, 4-ой Части «Резюме», Главе 15 «Заключение», суммируется все
представленные в данной книге подходы.
Приложение «Пример Плана Управления Требованиями» представляет собой
законченный план по управлению требованиями для ознакомления.
9
Аудитория Книги
Эта книга предназначена главным образом для тех, кто отвечает за процесс
управления требованиями в проекте. То, что у этой функции даже нет названия, служит
доказательством частого игнорирования этой позиции. Данная книга может помочь многим
людям, вовлеченным в процесс разработки программного обеспечения:
Бизнес-аналитикам
Дизайнерам сценариев использования
Менеджерам проектов
Системным архитекторам
Тестерам
Системным дизайнерам
Разработчикам
Эта книга предназначена как для опытных пользователей RequisitePro, так и для
людей, кто только начинает пользоваться этим инструментом. Чтобы читать и понимать
эту книгу, не нужно обладать какими-то особыми знаниями. Полезным может быть
немного знаний о жизненном цикле разработки программно обеспечения и о сценариях
использования. И то совсем не обязательно.
Книга предлагает следующее:
Обзор процесса управления требованиями.
Описание того, как можно быстро начать работать с RequisitePro.
Возможность изучения RequisitePro перед его приобретением.
Описание наиболее важных функциональных особенностей инструмента.
Примеры использования RequisitePro на проекте-образце.
Инструкции по отношению к особым шагам в процессе управления требованиями.
10
Благодарности
Я бы хотел поблагодарить внутреннюю команду Addison-Wesley/IBM Press за их огромную
поддержку. Невозможно упомянуть всех участников, и потому я бы хотел вынести особую
благодарность Старшему Редактору Разработки Chris Zahn за высококлассную редакцию, а
также Исполнительным Редакторам Chris Guzikowski, William Zobrist и Mary O’Brien.
Я также хотел бы поблагодарить Mark Lines и Celso Gonzalez за прочтение книги и
предоставление исключительно ценных комментариев. В дополнение, я бы хотел сказать
спасибо Karen Hyland за просмотр начальных глав.
Я бесконечно признателен тем людям, чьи издательства способствовали моим
исследованиям относительно управления требованиями: Dean Leffingwell и Don Widrig за
введение понятия пирамиды требований, Jim Heumann за его работу над извлечением
тестовых сценариев (test cases) из сценариев использования (use cases).
Особые слова признательности я адресую David Grady за его поддержку.
Я также благодарен всем моим клиентам и работникам. Работа с ними преумножила
мой опыт.
Больше всего я бы хотел поблагодарить всех читателей, кто интересуется
управлением требований и кто выбрал эту книгу.
11
Об Авторе
Peter Zielczynski обладает 25-летним опытом в области информационных
технологий. В Техническом Университете Варшавы он получил степень кандидата
компьютерных наук. Он издал боле десяти статей в технических журналах и провел
несколько презентаций на интернациональных конференциях, включая Rational Users
Conference (Конференция Пользователей Rational). Peter разрабатывал экспертные
системы в Cyfronet, а затем работал в качестве консультанта в таких компаниях, как IBM,
Merrill Lynch, Ernst & Young и AIG. Он был соучредителем и генеральным директором
консалтинговой компании International Object Technology, которая в итоге была
приобретена известной торговой компанией A Consulting Team (в настоящее время Helios
& Matheson North America). Peter специализируется на Управлении Требованиями,
Объектно-Ориентированном Анализе и Проектировании, а также на Управлении Проектом,
использует инструменты Rational с 1994 года.
12
Часть 1
Обзор
1. Управление Требованиями
2. Обзор RequisitePro
13
ГЛАВА 1
Управление
Требованиями
Данная глава начинается с определения понятий требования и заинтересованных
лиц (stakeholders). Далее мы опишем, какие типы требований могут существовать в
проекте. Отношения между этими требованиями представляются в форме пирамиды.
Также представлено понятие трассировки (или связей: какое требование - откуда было
получено). Приведены характеристики хороших требований. Даны примеры проблемных
требований вместе с некоторыми инструкциями по их исправлению. Показаны главные
стадии управления требованиями (Requirements Management - RM) в течение жизненного
цикла проекта. Главные стадии проходят через пирамиду требований сверху вниз.
1.1 Определение Требования и Заинтересованного Лица
Требование определяется как «условие или особенность, которой должна
удовлетворять система». Требованием может быть:
Функциональность, необходимая заказчику или пользователю для разрешения
проблем (или получения прибыли).
Функциональность, которая должна быть реализована в системе в соответствии с
контрактом, стандартом, спецификацией, инструкцией или другим официальным
документом.
Ограничение, наложенное заинтересованным лицом.
Рассмотрим понятие заинтересованного лица, т.к. это слово встречается в книге
много раз. Обычно под заинтересованным лицом (stakeholder) понимают личность, на
которую
оказывает
влияние
разрабатываемая
система.
Два
главных
типа
заинтересованных лиц – это пользователи и заказчики. Пользователи – это лица, которые
будут пользоваться системой. Заказчики – лица, кто заказывает систему и отвечает в
дальнейшем за приемку системы. Обычно заказчики платят за разработку системы. Важно
различать между этими двумя группами заинтересованных лиц, потому что иногда
требования этих двух групп конфликтуют между собой. В большинстве таких конфликтов,
запросы заказчика имеют преимущество над запросами пользователя. В используемом в
данной книге примере веб-сайта агентства путешествий, заказчик – владелец агентства
путешествий, а пользователи – люди, кто будет пользоваться этим веб-сайтом через
Интернет. Кроме заказчиков и пользователей, нельзя забывать про многие другие типы
заинтересованных лиц.
В интересах данной книги, мы будем называть заинтересованным лицом любого, кто
имеет отношение к системе (как в процессе разработки, так и после его завершения), а
также любого, у кого могут быть какие-либо требования к системе.
В качестве заинтересованного лица можно рассматривать:
Любого, участвующего в разработке системы (бизнес-аналитики, дизайнеры,
кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению,
дизайнеры сценариев использования, графические дизайнеры).
Любого, кто привносит свои знания в систему (эксперты предметной области,
авторы документов, которые были использованы для сбора требований,
собственники веб-сайтов, ссылки на которые были предоставлены).
14
Руководство (президент компании, которого представляют заказчики, директор
отдела
информационных
технологий
компании,
проектирующей
и
разрабатывающей систему).
Лица, вовлеченные в управление, настройку и сопровождение системы
(хостинговая компания, справочная служба).
Поставщики стандартов и регламентов (стандарты устанавливаются поисковыми
механизмами согласно содержанию веб-сайта, политическим нормам, а также
порядку налогообложения в конкретном штате).
1.2 Пирамида Требований
В зависимости от формата, источника и общих характеристик, требования могут быть
разделены на различные типы. Несколько типов требований, наиболее часто
использующихся в проектах:
Потребности заинтересованного лица: требование от заинтересованного лица.
Функциональная особенность: предоставляемая системой функциональность,
обычно
формулируемая
бизнес-аналитиком;
назначение
особенности
–
удовлетворить потребности заказчика.
Сценарий Использования (Use Case): описание поведения системы в терминах
последовательности действий.
Дополнительное требование: другое требование (обычно нефункциональное),
которое не может быть охвачено сценариями использования.
Тестовые сценарии (Test Cases): спецификация тестовых исходных данных,
условий выполнения и ожидаемых результатов.
Сценарий
(Алгоритм,
Scenario):
особая
последовательность
действий;
определенный путь по сценариям использования.
Эти типы требований могут быть представлены в виде пирамиды, как показано на
Рисунке 1.1.
На верхнем уровне располагаются потребности заинтересованного лица. На
последующих уровнях находятся функциональные особенности, сценарии использования
и дополнительные требования. Достаточно часто на разных уровнях этих требований
могут быть выяснены детали различного уровня. Чем ниже уровень, тем более детально
описывается требование. Например, потребность может быть следующей: «Данные
должны быть неизменными». Функциональная особенность этого требования будет:
«Система должна использовать реляционную базу данных». На уровне дополнительных
требований, требование еще более точное: «Система должна использовать базу данных
Oracle 9i». Чем дальше вниз, тем более детальным становится требование. Один из
лучших способов управления требованиями – обобщать требования, по крайней мере, на
двух различных уровнях. Например, документ Концепция («Vision») содержит
высокоуровневые требования (особенности), а низшие уровни пирамиды представляют
требования на более детальном уровне. У вышестоящих заинтересованных лиц (таких,
как вице-президент) нет времени читать 200 страниц детально описанных требований. Но
можно надеяться, что они смогут прочитать 12 страниц Концепции.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 1.1. Пирамида требований.
15
Однако то, какой будет степень детализации требований на каждом уровне, зависит
от бизнес-аналитиков. Нет ничего плохого в том, чтобы расположить достаточно подробно
описанные требования заинтересованных лиц на уровень потребностей заинтересованных
лиц.
Главное отличие между потребностями и функциональными особенностями – в
источнике
требований.
Потребности
поступают
от
заинтересованных
лиц,
а
функциональные особенности формулируются бизнес-аналитиками.
Роль тестовых сценариев – проверить, корректно ли были реализованы сценарии
использования и дополнительные требования. Алгоритмы помогают получить сценарии
использования из тестовых сценариев, а также способствуют проектированию и
реализации определенных путей через сценарии использования. В RequisitePro мы можем
определить многие другие типы требований, такие как термины справочника и
действующие лица. Они не являются в чистом виде требованиями, подходящими под
приведенное нами в начале главы определение требований. Но если мы представим их в
RequisitePro в качестве требований, мы получим возможность отслеживать их атрибуты и
трассировку (связь), используя те же механизмы, применяемые к остальным типам
требований.
1.3 Трассировка (Связь) между Требованиями
Трассировка – это способ представления отношений между требованиями различного
уровня в системе. Она помогает определить источник любого требования. Рисунок 1.1.
показывает, как требования переходят от самого верхнего уровня к нижнему. Каждая
потребность обычно соответствует нескольким функциональным особенностям. Обычно
это отношение «многие-ко-многим», т.к. одна потребность может трассироваться ко
многим функциональным особенностям, но из нескольких потребностей может быть
получена одна функциональная особенность. Одна потребность, соответствующая одной
функциональной особенности – это также общий случай. Функциональные особенности
соответствуют
сценариям
использования
в
отношении
«многие-ко-многим».
Функциональные особенности также соответствуют дополнительным требованиям в
отношении «многие-ко-многим».
Каждый сценарий использования соответствует одному или более сценарию
(алгоритму), таким образом, их тип отношений – «один-ко-многим». Сценарии
(алгоритмы) соответствуют тестовым сценариям в отношении «один-ко-многим».
Трассировка играет несколько важных ролей:
Подтверждение, что реализация удовлетворяет всем требованиям: Все, что
требовал заказчик, было реализовано.
Подтверждение, что приложение делает только то, что было заказано: Не
реализовывать то, что заказчик никогда не просил.
Анализ воздействия: Какие элементы будут затронуты при добавлении новых
требований или изменении текущих?
Помощь в управлении изменениями: Когда некоторые требования изменяются, мы
хотим знать, какие тестовые сценарии должны быть изменены, чтобы
протестировать данное изменение.
Элемент трассировки – это элемент проекта, который должен быть получен
(трассирован) из другого элемента. В терминах RequisitePro под ним понимается все, что
принадлежит какому-либо типу требований. Примеры типов требований в RequisitePro:
потребности
заинтересованных
лиц,
функциональные
особенности,
сценарии
использования, действующие лица и термины справочника. В RequisitePro есть очень
удобный способ отображения трассировки (связи) с помощью специальных представлений
(views).
1.4 Характеристики Хорошего Требования
Требование должно удовлетворять нескольким критериям для того, чтобы считаться
«хорошим требованием» [HUL05][LEF03][LUD05][YOU01]. Хорошее требование должно
иметь следующие характеристики:
Недвусмысленность
Правдоподобность (реальность,
Тестируемость (возможность проверки)
выполнимость)
Ясность (краткость, сжатость, простота,
Независимость
16
точность)
Корректность
Понятность
Элементарность
Необходимость
Независимость от реализации
(абстрактность)
Помимо этих критериев для отдельных требований,
применяются три критерия. Требования должны быть:
Постоянными.
Немногословными.
Завершенными.
для
набора
требований
В данной книге используется пример проекта он-лайн агентства путешествий, как
показано на Рисунке 1.2. Возможно, Вы знакомы с приложением этого типа, т.к.
различные его вариации встречаются на нескольких сайтах. Проект достаточно сложный,
чтобы показать возможные отношения между различными типами требований, но в то же
время, достаточно мал, чтобы его можно было легко понять. Большинство примеров в
данной главе (и в других главах) относятся к этому проекту.
Рисунок 1.2. Домашняя страница он-лайн агентства путешествий.
Рассмотрим каждый из критериев хорошего требования и приведем несколько
примеров.
Недвусмысленность
Должен существовать только один путь интерпретации
двусмысленность проявляется в виде неопределенных акронимов.
требования.
Иногда
Треб.1: Система должна быть реализована с использованием ASP.
Что значит ASP – Active Server Pages или Application Service Provider? Для
разрешения этой ситуации, мы можем указать полное наименование и предоставить
акроним в скобках:
Треб.1: Система должна быть реализована с использованием Active Server Pages
(ASP).
Другой пример:
Треб.1: Система не должна принимать пароли более 15-ти символов.
17
Не
совсем ясно, что система должна делать:
Система не должна позволять пользователю вводить более чем 15 символов.
Система должна отсекать введенную строку до 15-ти символов.
Система не должна отображать сообщение об ошибке, если пользователь вводит
более чем 15 символов.
Исправленное требование содержит пояснение:
Треб.1: Система не должна принимать пароли более 15-ти символов. Если
пользователь вводит более 15-ти символов при выборе пароля, сообщение об ошибке
должно информировать пользователя о необходимом исправлении пароля.
Иногда двусмысленность может проявляться местоположением определенного слова:
Треб.1: На экране «Stored Flight» пользователь может только просмотреть одну
запись.
Значит ли это, что пользователь может «только просмотреть», не удалять и не
изменять, или же что пользователь может просмотреть «только одну» запись – не одну, не
две и не три?
Один из способов решения проблемы – это переписать требование с точки зрения
системы:
Треб.1: На экране «Stored Flight» система должна отображать только один рейс.
Тестируемость (Возможность Проверки)
Тестеры должны иметь возможность проверить, было ли требование реализовано
корректно. Тестирование должно быть либо пройдено, либо нет. Чтобы быть пригодным
для тестирования, требование должно быть ясным, точным и недвусмысленным.
Использование некоторых слов может сделать требование невозможным для тестирования
[LUD05]:
Некоторые прилагательные: устойчивый, безопасный, точный, эффективный,
целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный.
Некоторые наречия и фразы с ними: быстро, безопасно, своевременно.
Неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).
Такие требования могут выглядеть примерно следующим образом:
Треб.1: Функция поиска должна позволять пользователю искать заказ на основе
Фамилии, Имени, Даты, и т.д.
В этом требовании все критерии поиска должны быть детально перечислены.
Дизайнер и разработчик не могут догадаться, что пользователь имел в виду под
сокращением «и т.д.».
Другие проблемы могут возникнуть при использовании двусмысленных слов или
фраз:
Изменение фраз: соответственно, как требовалось, если необходимо, должен
быть рассмотрен.
Неопределенные слова: обслуживать, обрабатывать.
Пассивный залог: предмет предложения получает действие глагола, а не
выполняет его.
Треб.1: Код аэропорта должен быть введен пользователем.
Треб.2: Код аэропорта должен быть введен.
Первый пример показывает классический случай пассивного залога. В активном
залоге это предложение бы звучало так: «Пользователь должен ввести код аэропорта».
Второй пример показывает другой результат использования пассивного залога – когда
пропускается агент, исполняющий действие. Кто должен вводить этот код - система или
пользователь?
18
Неопределенные местоимения: немного,
сколько-нибудь, кто-то, что-то, и т.д.
много,
больше
всего,
несколько,
Треб.1: Система должна препятствовать одновременному доступу большого числа
пользователей.
Какое количество здесь имеется в виду под «большим числом» - 10, 100 или 1000?
Ясность (Краткость, Сжатость, Простота, Точность)
Требования не должны содержать ненужных выражений или информации. Они
должны быть изложены кратко и просто:
Треб.1: Иногда пользователь будет вводить Airport Code (Код Аэропорта), который
система будет распознавать. Но иногда код можно заменить близлежащим городом, и
тогда пользователю не нужно знать код аэропорта, т.к. система будет понимать название
города.
Это предложение может быть заменено на более простое:
Треб.1: Система должна идентифицировать аэропорт на основании Airport Code
(Кода Аэропорта) или City Name (Названия Города).
Корректность
Если требование содержит факты, эти факты должны быть достоверны:
Треб.1: Цены на аренду машин должны включать все соответствующие налоги
(включая налог штата - 6%)
Налог зависит от штата, так что представленная цифра в 6 % - некорректна.
Понятность
Требования должны быть грамматически правильные, написаны в соответствующем
стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно
быть использовано вместо «будет», «обязан» или «может».
Правдоподобность (Реальность, Выполнимость)
Требование должно быть выполнимо в рамках существующих ограничений, таких как
время, деньги и доступные ресурсы.
Треб.1: Система должна иметь интерфейс на естественном языке, который будет
понимать команды на английском языке.
Это требование может быть нереальным из-за короткого периода времени
разработки.
Независимость
Чтобы понять требование, не нужно знать какое-либо другое требование.
Треб.1: Список доступных рейсов должен включать номер рейса, время отправления
и время прибытия для каждого отрезка пути.
Треб.2: Он должен быть отсортирован по ценам.
Слово «Он» во втором предложении относится к предыдущему требованию. И если
порядок требований изменить, это требование будет непонятно.
Элементарность
Требование должно содержать отдельный трассируемый элемент (для которого
возможно отслеживание связи):
19
Треб.1: Система должна предоставлять возможность бронировать рейс, покупать
билет, бронировать номер в гостинице, бронировать машину, а также предоставлять
информацию о развлечениях.
Это требование содержит пять элементарных требований, которые затрудняют
трассировку. Предложения,
включающие предлоги «и» или «но» должны быть
пересмотрены на предмет разделениях их на элементарные требования.
Необходимость
В требовании нет необходимости, если:
Ни одному заинтересованному лицу требование не нужно.
или
Удаление требования не повлияет на систему.
Пример требования, которое не нужно заинтересованному лицу – это требование,
которое добавили разработчики или дизайнеры, т.к. полагали, что оно необходимо
пользователям или заказчикам. Например, мнение разработчика о том, что пользователям
понравится функциональная особенность отображения карты аэропорта, и его знание
способов ее реализации, совсем не являются вескими причинами добавлять это
требование.
Пример требования, которое может быть удалено, т.к. оно не предоставляет никакой
новой информации:
Треб.1: Все требования,
реализованы и протестированы.
указанные
в
документе
Концепции
должны
быть
Независимость от Реализации (Абстрактность)
Требования не должны содержать ненужной информации о дизайне и реализации
системы:
Треб.1: Информация должна храниться в текстовом файле.
Решение того, каким образом информация будет храниться, и затем передаваться
пользователю, должно приниматься дизайнерами или архитекторами системы.
Постоянство
Не должно существовать конфликтов между требованиями. Конфликты могут быть
прямые и косвенные.
Прямые конфликты возникают, когда ожидается различное поведение системы в
одной и той же ситуации:
Треб.1: Дата должна отображаться в формате мм/дд/гггг.
Треб.1: Дата должна отображаться в формате дд/мм/гггг.
Иногда возможно разрешить конфликт путем анализа условий, которые явились
источником данных требований. Например, если Треб.1 поступило от американского
пользователя, а Треб.2 от французского, то предыдущие требования могут быть
переписаны следующим образом:
Треб.1: Для пользователей США дата должна отображаться в формате мм/дд/гггг.
Треб.2: Для пользователей Франции дата должна отображаться в формате
дд/мм/гггг.
В итоге это приведет к следующему требованию:
Треб.3: Даты
пользователя.
должны
отображаться
в
формате,
принятом
в
веб-браузере
Другой пример прямого конфликта может быть рассмотрен на следующих двух
требованиях:
20
Треб.1: Должна быть доступна оплата через PayPal.
Треб.2: Должна приниматься оплата только через кредитные карты.
В этом случае конфликт не может быть разрешен путем добавления условий, поэтому
одно из требований должно быть изменено или удалено.
Косвенный
конфликт
возникает,
когда
требования
описывают
разную
функциональность, но выполнить оба этих требования одновременно невозможно:
Треб.1: Система должна иметь интерфейс на естественном языке.
Треб.2: Система должна быть разработана в течение трех месяцев.
Некоторые требования не конфликтуют сами по себе, а используют несовместимую
терминологию:
Треб.1: Пользователь должен иметь возможность сравнить цены на рейсы вылета и
прибытия по отношению с другими близлежащими аэропортами.
Треб.2: Рейсы вылета и возвращения должны быть отсортированы по наименьшему
количеству остановок.
Немногословность
Каждое требование должно быть обозначено только один раз, и не должно
перекрываться другим требованием:
Треб.1: Для удобства ввода даты рейса в системе должен быть доступен календарь.
Треб.2: Система должна отображать всплывающее окно с календарем при вводе
любой даты.
Первое требование (относящееся только к дате рейса) является частью второго
требования (относящееся к любой дате, вводимой пользователем).
Завершенность
Требование должно быть описано для всех возможных условий:
Треб.1: Страна назначения не должна отображаться для рейсов в пределах США.
Треб.2: Для рейсов через море система должна отображать страну назначения.
А как же насчет рейсов в Мексику и Канаду? Они не входят в состав США, но и не
отделены морями от США.
Все необходимые требования должны быть приведены. Это условие является
наиболее сложным для выполнения. Действительно, невозможно быть уверенным, что
были собраны все требования, и за неделю до выпуска продукта одно из
заинтересованных лиц не скажет: «Я забыл упомянуть, что мне нужна еще одна
функциональная особенность в приложении».
Хорошее требование должно удовлетворять как можно большему количеству
критериев. Однако они могут быть выражены в виде комбинации вышеперечисленных
критериев:
Изменяемый: Если требование элементарное и немногословное, то оно обычно
изменяемое.
Трассируемое: Если оно краткое и имеет уникальный идентификатор (ID), то оно
обычно трассируемое (способное к отслеживанию связи).
1.5 Обзор Процесса Управления Требованиями
Самое простое описание процесса управления требованиями содержит следующие
основные пункты:
Формирование плана управления требованиями.
Сбор требований.
Разработка документа Концепции (Vision).
Создание сценариев использования (Use Cases).
Дополнительная спецификация.
21
Создание тестовых сценариев (Test Cases) из сценариев использования (Use
Cases).
Создание тестовых сценариев (Test Cases) из дополнительной спецификации.
Проектирование системы.
Первый шаг (план управления требованиями) определяет пирамиду требований. На
каждом из последующих семи шагов строится один элемент пирамиды. Таблица 1.1.
описывает, какие типы требований и какая документация создаются на каждом шаге. Как
Вы видите, процесс проходит через пирамиду сверху вниз и слева направо.
Таблица 1.1. Требования и Документы, Созданные на Каждом Шаге.
Шаг
Сбор требований
Тип Требований
Потребности заинтересованного
лица
Документы
Запросы заинтересованного
лица
Разработка документа
Концепции (Vision)
Функциональные особенности
Концепция
Создание сценариев
использования (Use cases)
Сценарии использования,
алгоритмы
Спецификация Сценариев
Использования
Дополнительная спецификация
Дополнительные требования
Дополнительная
спецификация
Создание тестовых сценариев
(test cases) из сценариев
использования (use cases)
Тестовые сценарии
Тестовые сценарии
Создание тестовых сценариев
(test cases) из дополнительной
спецификации
Тестовые сценарии
Тестовые сценарии
Проектирование системы
Диаграммы классов, диаграммы
взаимодействий
UML-диаграммы
Управление требованиями – это интерактивный процесс. На типичной итерации
предполагается полное прохождение по пирамиде. На любой итерации мы можем
вернуться назад на несколько шагов и повторить действия. Например, в процессе
создания тестовых сценариев, мы можем обнаружить, что отсутствует некоторая
информация, и нам нужно получить ее от заинтересованного лица. Таким образом, мы
возвращаемся на шаг сбора требований. Для обеспечения целостности модели, важно
обновлять все соответствующие требования. На начальных итерациях акцент делается на
первых нескольких шагах (в вершине пирамиды), а затем, на последующих итерациях,
больше времени проводится на низших уровнях пирамиды.
Описание процесса управления требованиями очень упрощено - приведены только
главные шаги. Некоторые действия в Rational Unified Process (RUP) описаны более
детально. (Например, наш шаг создания сценариев использования содержит следующие
RUP-действия: найти действующие лица и сценарии использования, структурировать
модель сценариев использования, расставить приоритеты сценариям использования и
детально описать сценарии использования).
Пройдемся кратко по всем шагам.
Формирование Плана Управления Требованиями
Одна из самых первых задач в проекте – это разработка Плана Управления
Требованиями (Requirements Management Plan – RMP). RMP содержит в себе общие
подходы к управлению требованиями в проекте. Документ детально описывает, каким
образом создаются требования, как они упорядочиваются, изменяются и отслеживаются в
течение жизненного цикла проекта.
Несколько вопросов, на которые может ответить документ RMP:
Будет использоваться инструмент для управления требованиями?
Какие типы требований будут присутствовать в проекте?
22
Каковы атрибуты этих требований?
Где будут создаваться требования – в базе данных или в документах?
Между какими требованиями должна осуществляться трассировка?
Какие документы необходимы?
Какие требования и документы будут использоваться как контракт с заказчиком?
Если часть проекта разрабатывается сторонними исполнителями, какие
требования и документы будут использоваться как контракт со сторонними
разработчиками?
Нужно следовать RUP или какой-либо другой методологии?
Нужны заказчику особые документы для осуществления разработки?
Как будет осуществляться управление изменениями?
Полагая использование RequisitePro, будет ли система храниться в одном проекте
RequisitePro, или будет разделена на несколько отдельных проектов?
Какой процесс будет гарантировать, что все требования будут выполнены и
протестированы?
Какие требования или представления необходимы для генерации отчетов?
Глава 3 «Формирование Плана Управления Требованиями» детально описывает все
эти пункты.
Сбор Требований
На самом верхнем уровне пирамиды находятся потребности заинтересованного лица,
как показано на Рисунке 1.3.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 1.3. Потребности заинтересованного лица находятся на самом верхнем уровне
пирамиды.
Данная книга использует термины «потребности заинтересованного лица» и
«запросы заинтересованного лица» как синонимы. Тем не менее, если того требует
специфика проекта, можно разделить их на два типа требований. В таком случае,
потребности будут требованиями высшего уровня, например: «Система должна иметь
возможность бронирования рейса». Обычно потребностей такого уровня бывает не более
пяти согласно заинтересованному лицу, и не более пятнадцати согласно проекту. Все
детальные требования будут
зафиксированы как запросы заинтересованного лица.
Однако во многих проектах намного легче зафиксировать всю информацию от
заинтересованного лица в тот же тип требований. Так что в используемом в данной книге
примере потребности заинтересованного лица представляют всю информацию от
заинтересованного лица, независимо от степени детализации. В некоторых проектах
может понадобиться различие между «потребностями заинтересованного лица»,
описывающими изначальные требования, и «запросами заинтересованного лица»,
которые могут включать последующие запросы на изменения функционала.
23
Сбор требований является очень важным шагом. Упущение требований или
неправильная интерпретация на этой стадии может привести к проблемам в течение всего
жизненного цикла проекта.
Несколько методов, используемых для сбора требований от заинтересованных лиц:
Интервью
Диаграммы сходства
Анкеты
Использование прототипов
Семинары
Анализ существующих документов
Сессии
с
применением
метода
Ролевые игры
«мозгового штурма» (Brainstorming
Сценарии приложения
sessions)
Все методы описаны в Главе 5 «Сбор Требований».
Разработка Документа Концепции (Vision)
Пункт 1.3 рассматривает характеристики хороших требований. Тем не менее,
поступающая от заинтересованных лиц информация не обязательно обладает этими
характеристиками. Особенно когда требования приходят от различных источников. Такие
требования могут быть противоречивыми и многословными.
Одна из главных целей бизнес-аналитика в процессе разработки Концепции – это
извлечение функциональных особенностей системы из потребностей заинтересованного
лица (см. Рисунок 1.4). Функциональные особенности должны иметь все атрибуты
хороших требований. Они должны быть тестируемые, немногословные, ясные и т.д.
Концепция должна содержать главную информацию о разрабатываемой системе.
Помимо перечисления всех функциональных особенностей, этот документ должен
содержать обзор системы, описание пользователей, обзор всех возможностей системы и
другую информацию, которая может понадобиться для понимания назначения системы.
Он также может содержать список всех потребностей заинтересованного лица, в случае
если они не были зафиксированы в отдельных документах.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 1.4. Функциональные особенности извлекаются из потребностей.
Некоторые части Концепции создаются в самом начале, даже до начала процесса
сбора требований от заинтересованных лиц. Примеры таких частей следующие:
Описание решаемой проблемы.
Идентификация пользователей/заказчиков/заинтересованных лиц.
Создание Сценариев Использования (Use Cases)
Наилучшая форма описания функциональных требований – это сценарии
использования (use cases). Они извлекаются из функциональных особенностей, как
показано на Рисунке 1.5.
Сценарий использования – это описание системы в терминах последовательности
действий. Он должен иметь значимый результат или определенное значение для
действующего лица (действующее лицо – это некто или нечто, взаимодействующее с
системой). Сценарии использования:
24
Инициируются действующим лицом.
Являются моделью взаимодействий между действующим лицом и системой.
Описывают последовательность действий.
Содержат в себе функциональные требования.
Должны иметь некоторое значение для действующего лица.
Представляют полный и имеющий смысл сценарий событий.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 1.5. Сценарии использования (use cases) извлекаются из особенностей,
описывающих функциональность системы. Сценарии (алгоритмы) извлекаются из
сценариев использования.
Фрагмент сценария использования:
1. Пользователь вводит необходимую информацию о рейсах: аэропорт и дата
вылета, аэропорт и дата прибытия.
2. Система отображает все рейсы вылета, совпадающие с критериями поиска.
3. Пользователь выбирает рейс вылета.
4. Система отображает список доступных рейсов возвращения.
Назначение сценариев использования
- способствовать соглашению между
разработчиками, заказчиками и пользователями на тему того, что именно система должна
делать.
Сценарий
использования
становится
своего
рода
контрактом
между
разработчиками и заказчиками. Он также является основой для реализации сценариев
использования, которые играют большую роль в проектировании системы. Вдобавок к
этому,
из
сценариев
использования
Вы
можете
создавать
диаграммы
последовательностей, диаграммы связей и диаграммы классов. Более того, из сценариев
использования Вы можете получать пользовательскую документацию. Сценарии
использования могут также быть полезны в планировании формального содержания
итераций и позволяют разработчикам системы лучше понять назначение системы. В
конце концов, Вы можете использовать их в качестве исходных данных для тестовых
сценариев (test cases).
При разработке сценариев использования, мы также будем определять сценарии или
алгоритмы (scenarios) – особые пути прохождения по сценарию использования. Обычно
при реализации систем мы выполняем алгоритмы один за другим, а не сразу весь
сценарий использования. Алгоритмы нужны при извлечении тестовых сценариев из
сценариев использования. На пирамиде требований алгоритмы находятся одним уровнем
ниже сценариев использования (см. Рисунок 1.5).
Дополнительная Спецификация
Дополнительная спецификация содержит нефункциональные требования (удобство
использования, надежность, производительность, способность к сопровождению). А также
некоторые функциональные требования, распространяющиеся за пределы системы, и
вследствие этого, сложные для отображения в сценариях использования. Эти требования
называют дополнительными требованиями. Они извлекаются из функциональных
особенностей, как показано на Рисунке 1.6.
25
Глава 8 «Дополнительная Спецификация» детально описывает этот тип требований.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 1.6. Дополнительные требования извлекаются из функциональных
особенностей, которые не могут быть отображены в сценариях использования.
Создание Тестовых Сценариев (Test Cases) из Сценариев
Использования
Как только все требования собраны, мы должны разработать способ проверить,
правильно ли они реализованы в конечном продукте. Тестовые сценарии (test cases)
показывают тестерам, какие шаги должны быть сделаны для того, чтобы протестировать
все требования. На этом шаге мы будем концентрироваться на создании тестовых
сценариев из сценариев использования. Если мы не создали алгоритмы в процессе
создания сценариев использования, мы должны определить их именно сейчас. Тестовые
сценарии находятся на низшем уровне пирамиды, как показано на Рисунке 1.7.
Этот процесс детально описан в Главе 9 «Создание Тестовых Сценариев (Test Cases)
из Сценариев Использования (Use Cases)».
Создание Тестовых Сценариев (Test Cases) из Дополнительной
Спецификации
Использованный на предыдущем шаге подход не подходит для тестирования
дополнительных требований. Для них не подходит понятие сценариев (алгоритмов), т.к.
эти требования не представляются в виде последовательности действий. Для каждого
дополнительного требования нужно применять индивидуальный подход, т.к. способы,
используемые для тестирования требований производительности, отличаются от способов,
используемых для тестирования требований по удобству использования. На этом шаге мы
также разрабатываем инфраструктуру тестирования и выявляем проблемы, касающиеся
платформы.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 1.7. Тестовые сценарии (test cases) для тестирования сценариев использования
(use cases).
26
Иногда нам необходимо «заимствовать» алгоритм (scenario), который был создан для
тестирования сценариев использования (см. Рисунок 1.8). Например, для тестирования
требования «Система должна запускаться с использованием браузеров Internet Explorer
(IE) и Netscape», мы должны выбрать один алгоритм, желательно основной поток (Basic
Flow) наиболее распространенного сценария использования. И затем протестировать
полный алгоритм в браузере IE. После мы должны протестировать тот же алгоритм снова в
браузере Netscape. Нет необходимости проходить в обоих браузерах все
тестовые
сценарии, созданные на предыдущем шаге. Просто выберите те, которые содержат
немного зависящей от браузера функциональности.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 1.8. Тестовые сценарии для тестирования дополнительных требований.
Некоторые
дополнительные
требования
могут
быть
протестированы
использованием средств автоматического тестирования, например Rational Robot.
с
Проектирование Системы
Требования являются основой для проектирования системы, которое чаще всего
сопровождается использованием Универсального Языка Моделирования – Unified Model
Language (UML) [BOO98]. Многие инструменты, такие как Rational Rose, Rational Software
Architect, Rational Data Architect и Rational Software Modeler, могут значительно
способствовать созданию всех необходимых диаграмм.
Один из подходов заключается в одновременном создании диаграмм взаимодействия
из алгоритмов и определении функциональности классов (см. Рисунок 1.9). Данный пункт
детально описан в Главе 11 «Объектно-Ориентированное Проектирование».
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ИСПОЛЬЗОВАНИЯ)
СЦЕНАРИИ
(АЛГОРИТМЫ)
ДИАГРАММЫ ВЗАИМОДЕЙСТВИЙ
ДИАГРАММЫ КЛАССОВ
Рисунок 1.9. Проектирование системы.
27
1.6 Заключение
Данная глава рассматривает процесс управления требованиями с точки зрения
созданных требований и документов. Вкратце, подход заключается в следующем:
1. Потребности заинтересованного лица собираются и оформляются документально
в документы запросов заинтересованного лица (Stakeholder Requests).
2. Функциональные особенности извлекаются из потребностей и фиксируются в
документе Концепции (Vision).
3. Сценарии использования (use cases) и дополнительные требования извлекаются
из функциональных особенностей.
4. Тестовые сценарии (test cases) извлекаются из сценариев использования (use
cases) и дополнительных требований.
Эти шаги должны применяться итеративно на протяжении всего жизненного цикла
проекта.
Ссылки
[BOO98] Booch, Grady, James Rumbaugh, and Ivar Jacobson. UML User Guide, Boston, MA:
Addison-Wesley, 1998.
[HUL05] Hull, Elizabeth, Kenneth Jackson, and Jeremy Dick. Requirements Engineering,
London: Springer, 2005.
[LEF03] Leffingwell, Dean, and Don Widrig. Managing Software Requirements: A Use Case
Approach, Second Edition, Boston, MA: Addison-Wesley, 2003.
[LUD05] Ludwig Consulting Services, LLC, www.jiludwig.com.
[YOU01] Young, Ralph R. Effective Requirements Practices, Boston, MA: Addison-Wesley,
2001.
28
ГЛАВА 2
Обзор
RequisitePro
IBM Rational RequisitePro - это инструмент, который способствует процессу
управления требованиями. Он позволяет вводить, обновлять, отслеживать и
просматривать требования на протяжении всего жизненного цикла проекта.
RequisitePro объединяет Microsoft Word (знакомую среду для обработки документов)
и
мощную
инфраструктуру
базы
данных.
Путем
комбинирования
подхода,
ориентированного на документы и подхода, ориентированного на базу данных,
RequisitePro предоставляет мощную и удобную в использовании систему для управления
требованиями. Навигация между документами и базой данных очень легкая и
интуитивная. Вы можете создавать, организовывать, отслеживать требования и назначать
им приоритеты. Этот инструмент обеспечивает детальное изготовление документов, типов
требований и атрибутов. Управление изменениями поддерживается путем отслеживания
связей между требованиями. У RequisitePro есть условия для сотрудничества с целой
командой проекта.
RequisitePro был разработан компанией Requisite, Inc. В 1996г. Requisite был
приобретен компанией Rational Software Comp. в 1997г., а впоследствии IBM в 2003г.
Недавно была выпущена 7-я версия RequisitePro. Тем не менее, т.к. большинство
компаний до сих пор используют версию 2003, именно она была использована для
примеров в этой книге. Различия между версиями 2003 и 2007 относительно
рассмотренных в данной книге вопросов совсем незначительны.
2.1 Интерфейс
Интерфейс RequisitePro состоит из следующих основных частей, как показано на
Рисунке 2.1:
Explorer window (окно Проводника) слева.
Views (Область Представлений) справа.
Menus (Меню) и Toolbars (Панели Инструментов) наверху.
Когда Вы работаете с документами, в отдельном
пространство Word.
29
окне открывается рабочее
Окно Проводника
Область
Представлений
Панель
Инструментов
Описание
Рисунок 2.1. Основные части интерфейса RequisitePro.
Explorer (Проводник)
Explorer (Проводник) – это главное окно навигации, которое отображает компоненты
проекта в виде дерева (см. Рисунок 2.2). Слово Explorer (Проводник) в этой книге
относится только к Проводнику RequisitePro, не Windows Explorer или Internet Explorer.
Документы, требования и представления объединены в папки. В шаблоне Use Case
(Сценариев Использования) по умолчанию находятся следующие папки:
Features and Vision (Функциональные Особенности и Концепция).
Glossary (Справочник).
Stakeholder Requests (Запросы Заинтересованного Лица).
Supplementary Requirements (Дополнительные Требования).
Use Cases (Сценарии Использования).
Вы можете добавить любое количество папок. Папки отображаются в Проводнике как
каталоги. Папки могут содержать только документы, представления, требования и другие
папки.
Элементы
проекта
представлены
в
Проводнике специальными
иконками,
указывающими на тип элемента:
Документы:
Представления:
Требования:
30
Рисунок 2.2. RequisitePro Explorer (Проводник).
В Проводнике Вы можете осуществлять основные операции (создание, просмотр,
обновление, удаление) над представлениями, требованиями и документами. Вы можете
изменить структуру элементов, просто перетаскивая их между папками.
Проводник обеспечивает легкий доступ к элементам проекта. Двойным щелчком
мышки на документе, Вы открываете его в рабочем пространстве Word. Двойным щелчком
мышки на требовании, Вы переходите к требованию в документе, где оно определено.
Двойным щелчком мышки на представлении открывает его в окне View (Области
Представлений). Вместо двойного щелчка на представлении или документе, Вы можете
также нажать правой кнопкой мышки и выбрать Open (Открыть). Когда Вы выделяете
элемент, его описание появляется в окне под Проводником (см. левый нижний угол на
Рисунке 2.1).
Views (Область Представлений)
Область Представлений - это область для анализа информации по требованиям.
Представление отображает атрибуты требований или отношения между требованиями.
Оно может отображаться в виде матрицы или дерева. В области представлений Вы также
можете создавать и обновлять требования, устанавливать отношения между ними
(например, отношения иерархии и трассировки), сортировать и фильтровать требования,
а также запрашивать статус проекта.
Существует три типа представлений:
Attribute Matrix (Матрица Атрибутов) – отображает требования определенного
типа и их атрибуты, как показано на Рисунке 2.3.
Рисунок 2.3. Attribute Matrix (Матрица Атрибутов).
31
Traceability Matrix (Матрица Трассировки) – отображает отношения между двумя
типами требований в форме матрицы, как показано на Рисунке 2.4.
Рисунок 2.4. Traceability Matrix (Матрица Трассировки).
Traceability Tree (Дерево Трассировки) отображает всю цепь трассировки (связи)
в виде дерева, как показано на Рисунке 2.5.
Рисунок 2.5. Traceability Tree (Дерево Трассировки).
Представления детально рассмотрены в Главе 5 «Сбор Требований».
Матрица Атрибутов может быть использована для выполнения следующих задач:
Просмотр требований определенного типа.
Добавление, обновление и удаление требований.
Настройка атрибутов требований.
Запрос требований, удовлетворяющих определенным критериям (фильтрация и
сортировка требований на основании их атрибутов).
Поиск требований в документах.
32
В добавлении к этим задачам, Матрица Трассировки может быть использована для
следующего:
Установка и анализ трассировки (связи).
Управление изменениями с использованием подозрительной трассировки (связи).
Анализ последствий.
Дерево Трассировки используется в основном для отображения и анализа цепочки
трассировки (связи).
В каждом представлении Вы можете делать следующее:
Сортировать и фильтровать требования.
Сохранять запросы, с помощью которых формировалось представление.
Экспортировать информацию представления в другие форматы.
Печатать представление.
Определяя запрос, Вы можете фильтровать (ограничивать отображаемую
информацию) и сортировать (упорядочивать информацию). Вы можете обрабатывать с
помощью запросов следующие требования:
Строки в Матрице Атрибутов.
Строки и столбцы в Матрице Трассировки.
Требования в корневом каталоге Дерева Трассировки.
Некоторые примеры запросов, которые могут быть отображены в представлениях:
Показывать все сценарии использования, которые еще не подтверждены, и
сортировать их по приоритету.
Показать все запросы заинтересованного лица, которые трассируются в
особенности.
Показать все функциональные особенности, которые были реализованы на
данной итерации.
Показать все функциональные особенности с наивысшим приоритетом, которые
извлечены из дополнительных требований, назначенных определенным
разработчикам.
Показать цепочку трассировки (связей) для всех запросов заинтересованного
лица, которые были получены от конечных пользователей.
Toolbar (Панель Инструментов)
Панель инструментов RequisitePro, показанная на Рисунке 2.6, обеспечивает быстрый
доступ к информации проекта и главным операциям. Полная функциональность панели
инструментов и опции доступны из пунктов меню, описанных в дальнейших главах.
Рисунок 2.6. RequisitePro Toolbar (панель инструментов).
2.2 Рабочее Пространство Word
Рабочее пространство Word - это среда, в которой Вы создаете, отображаете и
изменяете документы. Она открывается в виде окна Microsoft Word внутри RequisitePro и
предоставляет ту же функциональность, что и Microsoft Word. Помимо этого, панель
инструментов RequisitePro дает возможность осуществлять дополнительные операции над
документами и требованиями RequisitePro. Панель инструментов можно свободно
передвигать, как показано на Рисунке 2.7, либо присоединить к остальным панелям
инструментов вверху окна. Рисунок 2.8. показывает иконки на этой панели инструментов.
Вы можете импортировать существующие документы Word в RequisitePro или создавать
документы в среде RequisitePro на основе существующих шаблонов. Каждый документ
обозначается иконкой Word в Проводнике RequisitePro. Двойной щелчок мышки на иконке
откроет соответствующий документ.
33
Рисунок 2.7. Рабочее пространство Word.
Рисунок 2.8. Панель инструментов RequisitePro в рабочем пространстве Word.
2.3 Документы
Многие стандартные типы документов могут быть созданы в RequisitePro. Вы также
можете создать свой собственный тип документов, специфичный для Вашего проекта или
компании (и связать его с шаблонами). Несколько примеров наиболее часто используемых
документов:
Концепция (Vision): Содержит полное описание системы и функциональных
особенностей (один на проект).
Сценарий Использования (Use Case): определяет поведение системы в терминах
последовательности действий (несколько на проект).
Дополнительная Спецификация (Supplementary Specification): Функциональные
требования, не связанные со сценариями использования или нефункциональные
требования (один на проект).
Справочник (Glossary): Описывает все относящиеся к проекту термины (один на
проект).
Каждый документ принадлежит определенному типу документов. Тип документа
определяет шаблон, применяемый в документе. Этот шаблон определяет стандартное
форматирование, содержание, пункты по умолчанию и заголовки. Все документы такого
34
же типа имеют одинаковое расширение файла. Они не имеют используемых в Microsoft
Word расширений, так что они могут быть изменены только из RequisitePro.
Наиболее общие типы документов предустановленны по умолчанию. Создание
нового типа документов, как и новых шаблонов, не составляет трудностей (как описано в
Главе 9 «Создание Тестовых Сценариев (Test Cases) из Сценариев Использования (Use
Cases»)).
2.4 Требования
RequisitePro хранит требования в базе данных проекта. Требования могут храниться
или только в базе данных, или одновременно и в проектной документации, и в базе
данных. Когда Вы создаете требование в документе, оно становится динамической
ссылкой на его представление в базе данных.
У каждого требования есть соответствующие атрибуты. Они определяют свойства
требований, такие как Priority (Приоритет), Status (Статус), Difficulty (Сложность), Risk
(Риск) и Origin (Источник).
Атрибуты предоставляют информацию для управления
требованиями. Они могут использоваться для планирования, коммуникаций и мониторинга
проектной деятельности. Совсем не сложно осуществлять как настройку значений
атрибутов, установленных по умолчанию, так и создавать собственные атрибуты.
Пример требования:
FEAT.5: Система должна предоставлять возможность оплаты по кредитным картам.
По префиксу мы можем распознать, что это требование типа Feature
(Функциональная особенность). Этот тип требований обычно находится в документе
Концепции (Vision).
Вы можете определить трассировку (связь) между требованиями одного или разных
типов. Эта функциональность позволяет Вам отслеживать источник каждого требования,
так же как устанавливать и анализировать последствия изменения. Документы и
требования рассмотрены детально в последующих главах.
2.5 Заключение
Данная глава описывает основные части интерфейса RequisitePro:
Вы используете окно Explorer (Проводника) для навигации по папкам,
документам, представлениям и требованиям.
Вы используете окно Views (Область Представлений) для отображения
информации о требованиях в форме матрицы или дерева.
Вы используете Menus (меню) и Toolbars (панели инструментов) для выбора
операций.
Представления - это мощный механизм для анализа. Вы можете создавать сложные
запросы на основе значений атрибутов требований.
Рабочее пространство Word, открытое в отдельном окне, используется для
редактирования документов. Создание и обновление документов не составляет
сложностей, т.к. оно осуществляется с использованием среды Word, знакомой
наибольшему числу пользователей.
Большим преимуществом RequisitePro является дружественный интерфейс и гибкость
в применении. Очень легко настраивать типы документов, требований, атрибутов и их
значения. Каждое из таких изменений занимает не больше чем несколько минут.
В заключении можно сказать, что RequisitePro – это легко используемое, мощное
решение для управления требованиями.
35
Часть 2
Действия по
Управлению Требованиями
3. Формирования Плана Управления Требованиями
4. Установка Проекта
5. Сбор Требований
6. Разработка Документа Концепции (Vision)
7. Создание Сценариев Использования (Use Cases)
8. Дополнительная Спецификация
9. Создание Тестовых Сценариев (Test Cases) из Сценариев
Использования (Use Cases)
10.
11.
Создание Тестовых Сценариев (Test Cases) из
Дополнительных Требований
Объектно-Ориентированное Проектирование
12.
36
Документация
ГЛАВА 3
Формирование
Плана Управления Требованиями
Приступая к управлению требованиями, Вы должны начать с плана. Эта глава
рассматривает вопросы о том, когда нужно создавать План Управления Требованиями
(Requirements Management Plan - RMP), а также вопросы, на которые должны быть
получены ответы для его разработки. В конце главы приводится пример документа RMP.
RMP содержит в себе общие подходы к управлению требованиями в проекте. Он
описывает, каким образом создаются требования, как они упорядочиваются, изменяются и
отслеживаются в течение жизненного цикла проекта. Он также описывает все
используемые в проекте типы требований и их атрибуты.
Основная часть главы рассматривает решения, которые должны быть приняты, и
какие факторы влияют на эти решения.
3.1 Когда Создается Документ RMP
RMP может быть создан из включенного в RequisitePro шаблона. Однако для создания
проекта в RequisitePro, нам нужно зафиксировать решения в документ RMP. Мы можем
решить эту проблему следующими способами:
Подход 1.
1. Принимаются все решения относительно требуемых документов и типов
требований, но они не оформляются документально в RMP.
2. Создается проект RequisitePro.
3. Документ RMP создается из шаблона RequisitePro.
Подход 2.
1. Документ RMP создается в Microsoft Word. Он по-прежнему содержит все
пункты из шаблона RequisitePro, но создается вне инструмента.
2. Создается проект RequisitePro на основе RMP.
3. Документ Microsoft Word c RMP импортируется в RequisitePro.
Для нашего образца проекта мы будем использовать второй подход, чтобы показать,
как мы можем вносить существующие документы в среду RequisitePro. Импорт документа
Microsoft Word c RMP в RequisitePro описан в Главе 4 «Настройка Проекта».
3.2 Решения, Которые Могут Быть Оформлены в Документе RMP
Глава 1 «Управление Требованиями» перечисляет решения, которые должны быть
приняты при создании документа RMP. В следующих пунктах мы обсудим каждое решение
и влияющие на него факторы.
Будет Использоваться Инструмент Управления Требованиями?
Использование инструмента управления требованиями (RM) значительно облегчает
создание и хранение требований. Обычно инструмент предоставляет отслеживание
трассировки (связи). Могут генерироваться различные отчеты. Как бы то ни было, часто
37
требуются деньги на покупку такого инструмента, а также время на его изучение. Но
обычно такие расходы стоят получаемых преимуществ.
В некоторых случаях даже не требуется дополнительных средств для приобретения
инструмента. Одним из вариантов может быть использование бесплатного инструмента,
например Tracer. У некоторых компаний такой инструмент может уже быть в наличии,
если он был включен в пакет, купленный ранее для других целей. Например, некоторые
компании покупают Rational Suite Enterprise, из-за Rational Rose (для проектирования
системы) и Rational Robot (для тестирования). RequisitePro включен в этот набор, поэтому
не требуется никаких дополнительных лицензий при использовании его в управлении
требованиями.
Многие инструменты поддерживают процесс управления требованиями. Как можно
раньше нужно решить будет ли использоваться такой инструмент, и какой именно
инструмент был выбран для проекта. После принятия этого решения для первого проекта,
этот же инструмент, как правило, используется и в последующих проектах. Сравнения
различных инструментов для управления требованиями могут быть найдены на веб-сайте
International Council on Systems Engineering (www.paper-review.com/tools/rms/read.php).
Для данной книги мы выбрали RequisitePro – один из наиболее известных, мощных,
удобных в использовании и приемлемых в цене инструментов для управления
требованиями. Если из-за ограниченного бюджета нет возможности приобрести такое
средство, для отслеживания требований могут использоваться Microsoft Word и Microsoft
Excel. Отсутствие соответствующих инструментов не должно являться причиной для
игнорирования надлежащего оформления требований и реализации трассировки
(установления связи) между ними.
В остальной части главы полагается, что был выбран RequisitePro.
Какие Типы Требований Будут Присутствовать в Проекте?
Простые проекты могут нуждаться всего в одном или двух типах требований.
Сложные программные продукты нуждаются в требованиях разного уровня. Пирамида
требований, представленная на Рисунке 1.1. (и показанная на Рисунке 3.1), представляет
собой типичный набор требований для большого корпоративного проекта. Однако эта
пирамида может быть преобразована для конкретного отдельного проекта. Следующий
список рассматривает область применения каждого типа требований:
Потребности и запросы заинтересованного лица (Stakeholder requests): В нашем
проекте мы считаем запросы и потребности заинтересованного лица синонимами.
Тем не менее, мы можем разделить эти два типа требований. Один из подходов
заключается в отношении к потребностям как к требованиям наивысшего уровня,
помимо присутствия детальных запросов заинтересованного лица.
Функциональные особенности (Features): Обычно функциональные особенности
являются одними из самых главных требований в проекте, но если пользователь
может выразить все требования в форме сценариев использования (Use Cases UC), то необходимость в функциональных особенностях отсутствует.
Сценарии использования (Use Cases): Если не существует пользователей,
постоянно взаимодействующих с системой, то в UC нет необходимости. Примером
могут послужить некоторые пакетные программы, где пользователь только
инициирует процесс.
Дополнительные требования (Supplementary requirements): Каждый проект имеет
несколько нефункциональных требований, которые должны быть отображены в
Дополнительной Спецификации. Тем не менее, т.к. обычно не существует
большой разницы между дополнительными и нефункциональными требованиями,
мы можем хранить эти требования на уровне функциональных особенностей.
Сценарии (Алгоритмы, Scenarios): Сценарии используются для определения
верных путей сценариев использования (UC). Это очень нужный тип требований.
Алгоритмы содействуют переходу между UC и тестовыми сценариями (test cases).
В процессе проектирования мы создаем диаграммы последовательностей из
алгоритмов, а не из целых UC. Они также очень важны для менеджера проектов,
т.к. мы реализуем UC по алгоритму. Обычно мы выполняем не целый UC на
конкретной итерации, а набор алгоритмов из нескольких UC, по деталям реализуя
полные UC в конце стадии Construction (Построения). Чаще всего мы начинаем со
сценария, состоящего из основного потока (basic flow), а далее добавляем
38
сценарии с альтернативными потоками. Т.к. сами сценарии в RequisitePro не
определены как стандартный тип требований, мы должны создать их сами. К
сожалению, достаточно часто в целях экономии времени они так и не создаются
явно в RequisitePro.
Тестовые сценарии (Test cases): Считается хорошей практикой использование
тестовых сценариев. К сожалению, это не делается для многих проектов. Самый
простой подход к тестированию – это использование UC, а также использование
«ad-hoc» тестирования (случайный выбор подходящих для тестирования
значений). Этот подход сохраняет много времени, но он не гарантирует покрытие
тестированием всей системы.
Проблемы
(Problems):
Тип
требований
«проблемы»
используется
для
фиксирования основных проблем, которые предполагает решить новая система, с
существующими решениями этих проблем. Эти требования находятся наверху
пирамиды, одним уровнем выше потребностей. Наш образец проекта не
использует этот тип требований.
Наш образец проекта содержит типы требований, показанные на Рисунке 3.1.
Каковы Атрибуты Этих Требований?
Атрибуты требований играют важную роль в управлении проектом. Совместно с
представлениями, они представляют собой мощный инструмент для анализа. На основе
значений атрибутов Вы можете фильтровать и сортировать требования с помощью
запросов. Результаты запросов отображаются в представлениях. Некоторые наиболее
важные атрибуты и их значения описаны в пункте 3.4 «Атрибуты Требований»
Приложения «Пример Плана Управления Требованиями».
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 3.1. Пирамида требований.
Начальные требования поступают в RequisitePro с уже предустановленным по
умолчанию набором атрибутов. Этот набор может меняться в зависимости от того, какую
версию инструмента Вы используете. Таблица 3.1. представляет включенные в шаблон
Use Cases (Сценариев Использования) версии 2003.6.13 атрибуты и значения для
следующих типов требований:
Features (FEAT) – Функциональные особенности.
Supplementary requirements (SUPL) - Дополнительные требования.
Use cases (UC) - Сценарии использования.
Stakeholder requests (STRQ) - Запросы заинтересованных лиц.
Таблица 3.1. Атрибуты и Их Значения, Установленные по Умолчанию для Требований:
FEAT, SUPL, UC и STRQ.
Атрибут
Priority (Приоритет)
Значения
High (Высокий)
Medium (Средний)
39
FEAT
√
SUPL
√
UC
√
STRQ
Low (Низкий)
Type (Тип)
Functional (Функциональное)
Usability (Удобство использования)
Reliability (Надежность)
Supportability (Возможность
сопровождения)
Design Constraint (Ограничение на
Дизайн)
Implementation Requirement
(Требование Реализации)
Physical Requirement (Требование к
Аппаратному Обеспечению)
Interface Requirement (Требование
Интерфейса)
√
Status (Статус)
Proposed (Планируемый)
Approved (Подтвержденный)
Incorporated (Включенный)
Validated (Проверенный)
√
√
√
Difficulty (Сложность)
High (Высокий)
Medium (Средний)
Low (Низкий)
√
√
√
Stability (Устойчивость)
High (Высокий)
Medium (Средний)
Low (Низкий)
√
√
√
Risk (Риск)
Schedule – High (График - Высокий )
Schedule – Medium (График Средний)
Schedule – Low (График - Низкий)
Technology – High (Технологии Высокий)
Technology – Medium (Технологии Средний)
Technology – Low (Технологии Низкий)
√
√
√
Planned Iteration
(Планируемые Итерации)
Integer (Целое)
√
√
Actual Iteration (Фактические
Итерации)
Integer (Целое)
√
√
Origin (Источник)
Help Desk (Справочная Служба)
Partners (Партнеры)
Competition (Конкуренция)
Large Customers (Важные Заказчики)
End Users (Конечные Пользователи)
√
Contact Name (Имя Контакта)
Text (Текст)
√
√
√
Enhancement Request
(Запрос на Обновление)
√
√
√
Defect (Ошибки)
√
√
√
√
√
√
Obsolete
(Недействительность)
True (Истина)
False (Ложь)
Affects Architecture (Влияние
на Архитектуру)
True (Истина)
False (Ложь)
√
√
40
Stakeholder Priority
(Приоритет
Заинтересованного Лица)
High (Высокий)
Medium (Средний)
Low (Низкий)
√
Как Вы видите, требования FEAT, SUPL и UC имеют много общих атрибутов. У STRQ
по умолчанию существует только два атрибута - Origin (Источник) и Stakeholder Priority
(Приоритет Заинтересованного Лица).
При создании проекта Вам может понадобиться настройка атрибутов и их значений,
чтобы они подходили к Вашему проекту.
Т.к. некоторые значения атрибутов довольно неточные, будет полезным указать в
документе RMP, какие точно значения имеются в виду. Вот несколько примеров:
Priority - High (Приоритет - Высокий): Может быть реализовано не позже, чем в
первой итерации фазы Construction (Построение).
Priority - Medium (Приоритет - Средний): Может быть реализовано не позже, чем в
конце фазы Construction (Построения).
Priority - Low (Приоритет - Низкий): Может быть реализовано, если позволяет
время.
Risk Technology – High (Риск Технологии - Высокий): Использование новой
технологии, опыта работы с которой команда не имеет.
Risk Technology – Low (Риск Технологии - Низкий): использование хорошо
известной технологии, опыт работы с которой у команды очень большой.
Где Будут Создаваться Требования - в Базе Данных или в
Документах?
Для отслеживания атрибутов требований и трассировки (установления связи), не
обязательно хранить требования в документах. Они могут быть расположены в базе
данных. Однако их наличие в документах дает некоторые преимущества:
Легкий доступ к требованиям для членов команды, не имеющим доступа к RequisitePro.
Возможность визуально группировать и структурировать требования.
Представление требований в более читабельной форме.
Простота добавления комментариев и пояснений.
Альтернативой управлению требований в документах является использование
отчетов. Например, шаблоны Use Case Specification SoDA (Спецификации Сценариев
Использования) могут быть созданы так, что когда нужно объединить сценарии
использования, может быть сгенерирован отчет. Этот отчет будет иметь такую же
структуру, что и шаблон Use Case Specification RequisitePro.
Следующие типы требований обычно хранятся не только в базе данных, но и в
соответствующих документах:
Из-за своей наглядной природы, сценарии использования должны быть связаны с
документами – один документ на отдельный сценарий использования (Use Case
Specification - Спецификация Сценариев Использования).
Функциональные особенности включены в документ Концепции (Vision).
Дополнительные требования фиксируются в Дополнительной Спецификации
(Supplementary Specification).
Требования типа «потребности заинтересованных лиц» обычно включаются в
документы Запросов Заинтересованных Лиц (Stakeholder Requests). Но помимо этого,
существует еще три основных подхода к оформлению потребностей. Требования данного
типа могут храниться:
В документах Запросов Заинтересованных Лиц
За: 1. Все потребности связаны с определенным заинтересованным лицом.
2. Существует место для дополнительных комментариев и для всех ответов
заинтересованных лиц.
3. Не составляет труда дать весь документ заинтересованному лицу для
рассмотрения.
Против: Увеличивается количество документов, которые требуют постоянного
обновления.
41
Только в базе данных
За:
Уменьшается количество документов.
Против: Наименее читабельная форма, особенно если мы хотим выслушать
мнение заинтересованного лица.
В документе Концепции
За:
Уменьшается количество документов.
Против:
Концепция становится документом, который содержит требования как
из области проблем (STRQ), так и из области решений (FEAT).
Между Какими Требованиями Должна Осуществляться
Трассировка?
В зависимости от выбранного типы требований дерево трассировки (Traceability Tree
– дерево связей) может выглядеть по-разному. Рисунок 3.2. показывает трассировку для
типов требований, выбранных для нашего образца проекта.
Рисунок 3.2. Трассировка (связи) между типами требований, используемая в образце
проекта.
Какие документы необходимы?
Как можно раньше в процессе работы мы должны определить, какие документы нам
будут необходимы в проекте. Каждый документ должен иметь свое предназначение.
Например, он может использоваться для коммуникаций между членами команды, либо же
для получения утверждения у заказчика.
В большинстве проектов чаще всего используются следующие документы: Концепция
(Vision), Сценарии Использования (Use Cases) и Дополнительная Спецификация
(Supplementary Specification). Главной причиной является то, что эти документы содержат
важные типы требований - FEAT, UC и SUPL. Эти документы могут также использоваться в
качестве контракта между группой разработчиков и заказчиками.
Документ Запросов Заинтересованного Лица (Stakeholder Requests) используется в
50% проектов случаев. Справочник (Glossary) имеется практически во всех шаблонах
проектов. Несмотря на этого, во многих проектах он не разрабатывается. План
Управления Требованиями (RMP) – очень нужный документ, но он не подвергается
сильным изменениям от проекта к проекту. Вы можете создать общий RMP для всех
проектов организации и просто вносить некоторые мелкие изменения и исключения,
специфичные для конкретного проекта.
Глава 12 «Документация» содержит более детальное описание документов, которые,
возможно, будет необходимо создать.
42
Какие Требования и Документы Будут Использоваться как
Контракт с Заказчиком?
Обычно в качестве контракта используются Сценарии Использования (Use Cases) и
Дополнительная Спецификация (Supplementary Specification), но мы также можем
включить в контракт документ Концепции (Vision). Не имеет смысла утверждать у
заказчика запросы заинтересованных лиц (Stakeholder Requests), т.к. эти требования
обычно написаны на языке пользователей. В этом случае мы берем на себя
ответственность, если вдруг требование будет интерпретировано неверно в процессе
преобразования требований STRQ в FEAT, UC или SUPL.
Если Часть Проекта Разрабатывается Сторонними
Исполнителями, Какие Требования и Документы Будут
Использоваться как Контракт со Сторонними Разработчиками?
Это зависит от степени вовлечения в процесс сторонних исполнителей. Если
проектирование и разработка осуществляются на стороне, мы можем использовать
дополнительные требования и сценарии использования. Если сторонний исполнитель
также участвует в анализе, то можно использовать функциональные особенности. Если
сторонними исполнителями осуществляется только кодирование, мы можем использовать
модель Rational Rose для согласования объема работ.
Нужно Следовать RUP или Какой-либо Другой Методологии?
Rational Unified Process (RUP) - это итеративный процесс разработки программного
обеспечения, который становится все более и более популярным.
Некоторые преимущества использования RUP:
Итеративный подход позволяет определять все риски на ранних стадиях.
Возможность использования стандартных шаблонов документов.
Интеграция с IBM RequisitePro и другими инструментами Rational.
RUP может успешно применяться как в краткосрочном проекте, так и в сложном
многолетнем проекте [KRO03]. RUP можно приспособить под требования конкретного
проекта. Представленный в данной книге подход к управлению требованиями
синхронизирован с RUP. Однако он также может применяться в проектах, где RUP не
используется.
Нужны Заказчику Особые Документы для Осуществления
Разработки?
Некоторые компании создают свой внутренний Жизненный Цикл Разработки
Программного Обеспечения (Software Development Lifecycle). Они могут требовать
некоторые документы, специфичные для их организации. Возможно, нам потребуется
включить эти документы в процесс.
Как Будет Осуществляться Управление Изменениями?
Могут быть использованы автоматические средства. Имеет смысл использовать
ClearQuest, т.к. он является частью Rational Suite и предоставляет некоторую интеграцию
с RequisitePro. Нам также необходимо детализировать процесс. Есть ли у нас центральное
лицо, через которого мы будут назначаться запросы на изменения, или же есть группа
авторизованных тестеров, бизнес-аналитиков и пользователей, кто может назначить
запрос на изменение непосредственно в самой системе?
Будет ли Вся Система Храниться в Одном Проекте RequisitePro,
или Будет Разделена на Несколько Проектов?
Намного легче работать с моделью требований, если она хранится в одном проекте.
Исключения могут быть сделаны для очень больших систем, которые можно разделить на
более мелкие и независимые подсистемы, обслуживающиеся разными командами.
43
Какой Процесс Будет Гарантировать, Что Все Требования Будут
Выполнены и Протестированы?
Достижению этой цели содействует трассировка (установки связи). Процесс
управления требованиями может определить, когда и как мы проверяем корректность
реализации трассировки требования (откуда и куда оно было трассировано). Один из
подходов заключается в генерации отчетов в конце каждой итерации.
Какие Требования или Представления Необходимы для
Генерации Отчетов?
Это зависит от специфики проекта. Однако, обычно необходимы следующие
представления:
Attribute Matrix: Stakeholder Requests (Матрица Атрибутов: Запросы
Заинтересованных Лиц).
Attribute Matrix: Features (Матрица Атрибутов: Функциональные Особенности).
Attribute Matrix: Supplementary Requirements (Матрица Атрибутов:
Дополнительные Требования).
Attribute Matrix: Test Cases (Матрица Атрибутов: Тестовые Сценарии).
Traceability Matrix: Stakeholder Requests to Features (Матрица Трассировки: из
Запросов Заинтересованных Лиц в Функциональные Особенности).
Traceability Matrix: Features to Use Cases (Матрица Трассировки: из
Функциональных Особенностей в Сценарии Использования).
Traceability Matrix: Features to Supplementary Requirements (Матрица
Трассировки: из Функциональных Особенностей в Дополнительные Требования).
Traceability Matrix: Supplementary Requirements to Test Cases (Матрица
Трассировки: из Дополнительных Требований в Сценарии Использования).
Traceability Matrix: Use Cases to Scenario and Test Cases (Матрица Трассировки: из
Сценариев Использования в Алгоритмы (Сценарии) и Тестовые Сценарии).
3.3 Пример Плана Управления Требованиями
Данная книга представляет план документа RMP, основанном на включенном в
предыдущую версию RequisitePro шаблоне. Пример плана находится в Приложении.
Просмотрите его, чтобы более подробно изучить моменты, описанные в данной главе.
3.4 Заключение
Мы представили примеры вопросов, которые могут обсуждаться в Плане Управления
Требованиями. В зависимости от проекта, некоторые из них Вам могут приходиться, а в
других не будет необходимости. Наиболее важная информация для отображения в RMP:
В каких типах документов будут храниться требования.
Какие типы требований будут содержаться в каждом документе.
Какие атрибуты мы хотим назначить каждому требованию.
Какие значения атрибутов доступны для каждого атрибута, и что они означают.
После того как Вы создали RMP для одного проекта, этот документ может быть
использован как шаблон для будущих проектов, т.к. многие решения будут идентичными.
Одно из главных назначений RMP – принять все решения, необходимые для проекта
RequisitePro. Все задачи описаны в Главе 4.
Ссылки
[KRO03] Kroll, Per, and Philippe Kruchten. The Rational Unified Process Made Easy, Boston:
Addison-Wesley, 2003.
44
ГЛАВА 4
Настройка
Проекта
При работе с RequisitePro и другими инструментами Rational, нам нужно настроить
два типа проектов:
Проект RequisitePro, в котором мы указываем настройки относительно управления
требованиями, такие как типы требований и их атрибуты, типы документов и
правила трассировки (установки связи).
Проект Rational, который содержит в себе информацию от различных
инструментов Rational, таких как RequisitePro, ClearQuest Test Manager, ClearCase
и другие.
Эти два шага могут быть выполнены в любом порядке. Настроим сначала проект
RequisitePro, а затем присоединим его при создании проекта Rational.
Если Вы не собираетесь использовать другие инструменты Rational, то в настройке
проекта Rational нет необходимости. Когда Вы настраиваете проект Rational, создается
база данных. И это действительно нужно, если Вы хотите тестировать с помощью
инструментов Rational Robot и Test Director.
4.1 Настройка Проекта RequisitePro
При создании проекта RequisitePro Вам нужно указать необходимые документы, типы
требований для проекта, а также атрибуты требований. Как было рассмотрено в Главе 3
«Формирование Плана Управления Требованиями», обычно эти решения уже приняты в
процессе создания Плана Управления Требованиями (RMP).
Каждый проект находится в отдельном каталоге. Для создания проекта RequisitePro
выберите File>New>Project (Файл>Новый>Проект). Появится диалоговое окно с
шаблонами проекта, как показано на Рисунке 4.1.
При создании, Вы можете определить новый проект на основе:
Пустого шаблона.
Одного из трех включенных в RequisitePro шаблонов: Use Case (Сценариев
Использования), Traditional (Традиционный) или Composite (Комплексный).
Шаблона, созданного из существующего проекта.
Из базовой версии.
Когда Вы создаете проект на основе шаблона, то тип документов, тип требований, их
атрибуты, а также информация по безопасности копируются из шаблона в новый проект.
45
Рисунок 4.1. Доступные в RequisitePro шаблоны проекта.
Дополнительные документы и типы требований могут быть добавлены позже.
Использование шаблона может сэкономить время и избавить от лишних усилий, т.к.
шаблон уже содержит большинство нужных Вам документов. В RequisitePro доступны
следующие типы шаблонов:
Use Case (шаблон Сценариев Использования): Удобен для проектов, где
функциональные требования описаны в сценариях использования.
Traditional
(Традиционный):
Удобен
для
проектов,
где
используются
традиционные (декларативные) требования вместо сценариев использования.
Composite (Комплексный): Объединяет сценарии использования и традиционные
подходы.
Blank (Пустой): Удобен, если в Вашем проекте есть особый набор документов и
типов требований.
Make New: Удобно, если Вы хотите использовать эту же структуру в последующих
проектах.
Create from Baseline (Создание из Базовой Версии): Удобно, если у Вас есть
ClearQuest, интегрированный с RequisitePro.
Таблица 4.1. показывает, какие типы документов и требований включены в
шаблоны.
Таблица 4.1. Типы Требований и Документов, Включенные в Три Главных Шаблона.
Документ
Тип Требований
План Управления
Требованиями
Требование Плана
Управления
Требованиями
√
Шаблон
Сценарии
Использования
√
Запросы
Заинтересованного
Лица
Запрос
Заинтересованного
Лица
√
√
√
Концепция
Функциональная
Особенность
√
√
√
Справочник
Термин Справочника
√
√
√
Спецификация
Требований к
Программному
Обеспечению (SRS)
Требование к
Программному
Обеспечению
√
Традиционный
Комплексный
√
√
46
Спецификация
Сценариев
Использования
Сценарий
Использования
√
Дополнительная
Спецификация
Дополнительное
Требование
√
√
В случае Комплексного шаблона, документ Спецификации Требований к Программному
(SRS
Software
Requirement
Specification)
обычно
называется
Усовершенствованной Спецификацией Требований к Программному Обеспечению (Modern
Software Requirement Specification). Помимо основного содержания документа SRS, в нем
имеется описание модели Сценариев Использования.
Главное отличие между шаблонами в том, каким образом описаны требования к
программному обеспечению. Используем ли мы SRS, Сценарии Использования с
Дополнительной Спецификацией, либо же Усовершенствованный SRS со Сценариями
Использования?
Для нашего примера проекта мы создадим проект на основе шаблона Use Case
(Сценариев Использования).
1. После выбора шаблона нажмите ОК. Появится диалоговое окно Project Properties
(Свойства Проекта), как показано на Рисунке 4.2.
2. Заполните все необходимые поля:
Название: Выберите название для Вашего проекта, отражающее его смысл
(до 64-х символов).
Каталог: Где будет располагаться проект. (Если каталог не существует, то
он создается).
База данных: База данных выбирается для хранения требований.
RequisitePro хранит требования в базе данных, содержащей всю
информацию по ним (атрибуты, трассировку - связи, предыдущие версии,
обсуждения и информацию по безопасности). RequisitePro может
использовать базу данных Microsoft Access, а также работать с базой
данных Enterprise (Oracle или SQL Server). Но работа с последней базой
данных рекомендуется только в следующих случаях:
Для очень больших проектов, содержащих тысячи требований.
Если Вы предполагаете возможность одновременного доступа к
базе данных более чем пяти пользователей.
Когда местонахождение членов Вашей команды различно.
Обеспечению
Т.к. у нас нет причин для хранения требований подобным образом в нашем
образце проекта, то мы должны использовать базу данных Microsoft Access,
которая и предлагается по умолчанию. Последнее поле (Описание)
заполнять не обязательно. Но краткое описание проекта может быть
полезным.
3. Нажмите ОК.
4. Если Вы видите сообщение «Каталог не существует. Хотите ли Вы создать его?»,
нажмите Yes (Да). После того как пройдет немного времени на выполнение
операции, Вы должны увидеть сообщение: «Проект RequisitePro был успешно
создан».
После создания проект появляется в окне Explorer (Проводнике), а также
добавляется в список проектов в диалоговом окне Open Project (Открыть Проект). Т.к. мы
использовали шаблон Use Case (Сценариев Использования), некоторые документы уже
присутствуют в Проводнике, такие как Справочник (Glossary), Концепция (Vision) и План
Управления Требованиями (RMP), как показано на Рисунке 4.3. Также уже созданы
некоторые папки и представления. Когда в проекте создаются требования, они
автоматически появляются в Области Представлений (Views).
47
Рисунок 4.2. Диалоговое окно Project Properties (Свойства Проекта).
Следующие файлы появляются в каталоге проекта:
Online Travel Agency.rqs: файл проекта RequisitePro.
Online Travel Agency.mdb: База данных, содержащая информацию о требованиях.
Glossary.gls, Vision.vis, Requirements Management Plan.rmp: Шаблоны для
документов Справочника, Концепции и Плана Управления Требованиями
соответственно.
Online Travel Agency.rql: Содержит дополнительную информацию по проекту.
Для настройки структуры проекта (добавление, удаление или редактирование типов
документов и требований) используйте диалоговое окно Project Properties (Свойства
Проекта). Чаще всего Вам нужно будет добавлять атрибут или изменять значения
существующих атрибутов.
Рисунок 4.3. Предустановленная структура шаблона Use Case (Сценариев
Использования).
Добавление Атрибутов Требования
Вам может понадобиться добавление нового атрибута, если установленный по
умолчанию атрибут не подходит. Предположим, что мы хотим добавить атрибут Status в
требование типа запросов заинтересованного лица (STRQ). Этот атрибут поможет
отслеживать статус требования.
1. Выберите File>Properties (Файл>Свойства).
2. Выберите закладку Attributes (Атрибуты), как показано на Рисунке 4.4.
48
Рисунок 4.4. Диалоговое окно Project Properties (Свойства Проекта): закладка Attributes
(Атрибуты).
3. Выберите Requirement Type (Тип Требования). В нашем случае STRQ.
4. Нажмите кнопку Add (Добавить). Появится диалоговое окно Add Attribute
(Добавить Атрибут), как показано на Рисунке 4.5.
Рисунок 4.5. Диалоговое окно Add Attribute (Добавить Атрибут).
5. Заполните поля диалогового окна:
Label (Название): Status.
Type (Тип): List (Single Value).
List Values (Значения): Gathered, Approved, Incorporated,
(Полученный, Подтвержденный, Включенный, Отмененный).
Cancelled
6. Нажмите ОК. Атрибут добавляется к требованию.
Изменение Значений Атрибутов Требования
Вы можете менять набор значений для существующих атрибутов требований.
Например, предустановленный по умолчанию набор значений для атрибута Origin
(Источник) для запросов заинтересованных лиц следующий:
Help Desk (Справочная Служба)
End Users (Конечные Пользователи)
Competition (Конкуренция)
Large Customers (Важные Заказчики)
Partners (Партнеры)
Этот набор атрибутов перечисляет всех заинтересованных лиц, кто может
предоставить требования. Для каждого проекта этот набор может быть разным, поэтому
возможно, что Вам надо будет настраивать набор значений. Удалим значения по
умолчанию и создадим следующий набор значений для нашего проекта:
49
User 1 (Пользователь 1)
User 2 (Пользователь 2)
Customer Service Rep (Представитель
Отдела Обслуживания Клиентов)
Administrator (Администратор)
Content Manager (Контент-Менеджер)
Developer (Разработчик)
Hotel Provider (Представитель
гостиницы)
Car Rental Agent (Агент по найму
автомобиля)
Airline Rep (Представитель
авиалиний)
Travel Agency Owner (Владелец бюро
путешествий)
1. Выберите File>Properties (Файл>Свойства).
2. Выберите закладку Attributes (Атрибуты), как показано на Рисунке 4.6.
Рисунок 4.6. Выбор значений для атрибута.
3.
4.
5.
6.
7.
Выберите Requirement Type (Тип Требования). В нашем случае STRQ.
Выберите Attribute level (Название Атрибута). В нашем случае Origin.
Выберите Values per Attribute (Значения Атрибута).
Выберите первое значение (Help Desk).
Нажмите Delete (Удалить). Вы увидите сообщение: «Данная функция требует,
чтобы проект был открыт эксклюзивно. Хотите ли Вы получить эксклюзивный
доступ к проекту сейчас?». Нажмите Yes (Да) если Вы хотите открыть проект
эксклюзивно. «Эксклюзивный доступ» означает, что проект и его документы
доступны только пользователю, открывшему проект. Эксклюзивный доступ
требуется для изменения многих характеристик проекта. Вы можете открыть
проект в эксклюзивном режиме только тогда, когда никакой другой пользователь
в настоящее время не открыл проект или его документ.
8. Нажмите ОК в окне подтверждения, которое сообщает о том, что «Эксклюзивный
доступ к проекту был успешно получен».
9. Продолжайте выбор значений из списка и нажатие кнопки Delete (Удалить), пока
Вы не удалите все значения.
10. Нажмите кнопку Add (Добавить).
11. Введите значение User 1 (Пользователь 1) в диалоговом окне Attribute Value
(Значение Атрибута), как показано на Рисунке 4.7.
12. Нажмите ОК.
13. Продолжайте добавлять остальные значения (User 2 - Пользователь 2, Customer
Service Rep - Представитель Отдела Обслуживания Клиентов, Administrator –
Администратор и т.д.).
14. Нажмите ОК.
Рисунок 4.7. Добавления значения атрибута.
50
Импорт Документа
Некоторые документы могут быть созданы до создания проекта RequisitePro. В таком
случае мы должны импортировать их в инструмент. Импортируем План Управления
Проектами (Requirements Management Plan), который мы создали в Главе 3. Для импорта
документов Microsoft Word в RequisitePro выполните следующие действия:
1. Выберите файл в Explorer (Проводнике).
2. Выберите File>Import (Файл>Импорт). Появится Import Wizard (Мастер Настройки
Импорта), как показано на Рисунке 4.8.
Рисунок 4.8. Import Wizard (Мастер Настройки Импорта.
3.
4.
5.
6.
Выберите Microsoft Word Document.
Выберите путь к файлу, который Вы хотите импортировать.
Нажмите Next (Далее).
Выберите «Document only» («Только документ»), т.к. документ RMP не содержит
никаких требований (см. Рисунок 4.9).
7. Нажмите Next (Далее). Появится диалоговое окно Document Properties (Свойства
Документа), как показано на Рисунке 4.10.
8. Введите Name (Название) и Description (Описание) документа, а также выберите
Document Type (Тип Документа).
9. Если необходимо, Вы можете изменить установленные по умолчанию значения
Filename (Названия файла) и Directory (Каталога).
Рисунок 4.9. Import Wizard (Мастер Настройки Импорта): Выбор импортируемого
документа.
10. Нажмите Да (Yes) в диалоговом окне, предупреждающем Вас об обновлении
изначального формата документа.
11. Нажмите Commit в диалоговом окне, подтверждая создание файла.
51
Рисунок 4.10. Диалоговое окно Document Properties (Свойства Документа).
4.2 Настройка Проекта Rational
Если Вы планируете интегрирование RequisitePro с другими инструментами Rational,
или же использование Rational Robot или ClearQuest Test Manager, то помимо создания
проекта RequisitePro Вам необходимо создать проект Rational. Это делается с помощью
Rational Administrator – отдельного инструмента, входящего в состав Rational Suite.
1. Создайте пустой каталог, где вы хотите хранить файлы проекта.
2. Запустите Rational Administrator, как показано на Рисунке 4.11.
Рисунок 4.11. Главное окно Rational Administrator.
3. Выберите File>New Project (Файл>Новый Проект). Появится диалоговое окно New
Project (Новый Проект), как показано на Рисунке 4.12.
4. Выберите Project name (Название проекта). Оно может быть таким же, как в
RequisitePro, или любым другим.
5. Выберите Project directory (Каталог проекта) из списка (Каталог проекта должен
уже существовать). Нажмите кнопку Next (Далее).
6. Если Вы видите сообщение: «Чтобы открыть доступ другим лицам к Вашему
проекту, Вы должны использовать общий каталог», нажмите кнопку ОК. будьте
осторожны в выборе каталога для проекта. Если Вы создадите его не в общем
каталоге, то Вы будете единственным, кто будет иметь доступ к проекту.
52
Рисунок 4.12. Диалоговое окно New Project – General (Новый проект – Основное).
7. Введите пароль. Если Вам не нужна защита паролем, оставьте поле Password
(Пароль) пустым (см. Рисунок 4.13).
Рисунок 4.13. Диалоговое окно New Project – Security (Новый проект – Безопасность).
8. Нажмите кнопку Next (Далее). Появится диалоговое окно New Project – Summary
(Новый Проект – Сводка), как показано на Рисунке 4.14.
Рисунок 4.14. Диалоговое окно New Project – Summary (Новый Проект – Сводка).
53
9. Нажмите кнопку Finish (Завершить). Появится диалоговое окно Configure Project
(Конфигурация Проекта), как показано на Рисунке 4.15.
Рисунок 4.15. Диалоговое окно Configure Project (Конфигурация Проекта).
10. Нажмите кнопку Select (Выбрать) перед Associated RequisitePro Project
(Соответствующий Проект RequisitePro).
11. Как показано на Рисунке 4.16, выберите .rqs файл, содержащий ранее созданный
Вами проект RequisitePro, и нажмите Open (Открыть). Вы также можете открыть
его двойным щелчком мышки на файле проекта. Вы увидите сообщение «Проект
RequisitePro был успешно поставлен в соответствие проекту Rational: “Online
Travel Agency”» (или любое другое название проекта).
12. Нажмите кнопку Close (Закрыть).
13. Нажмите
кнопку
Create
(Создать)
перед
Associated
Test
Datastore
(Соответствующая Тестовая База Данных) в диалоговом окне Configure Project
(Конфигурация Проекта).
14. Выберите тип базы данных, как показано на Рисунке 4.17.
Если к базе данных будет одновременно обращаться много пользователей, Вы
должны выбрать Sybase SQL Anywhere. Если Вы выберите эту опцию, Вы должны
будете указать Sybase server. Если база будет использоваться только одним
пользователем в определеннее время, то достаточно Microsoft Access.
15. Нажмите кнопку Next (Далее).
Рисунок 4.16. Диалоговое окно для выбора проекта RequisitePro.
54
Рисунок 4.17. Диалоговое окно Create Test Datastore (Создать Тестовую Базу Данных).
16. Нажмите кнопку Next (Далее) для подтверждения пути к тесовой базе данных
(см. Рисунок 4.18).
Рисунок 4.18. Диалоговое окно Microsoft Access Settings (Настройки Microsoft Access).
17. Нажмите кнопку Next (Далее) для подтверждения того, что Вы не задаете активов
и тестовых пользователей, как показано на Рисунке 4.19.
55
Рисунок 4.19. Инициализация свойств для тестовой базы данных.
18. Нажмите кнопку Finish (Закончить) для подтверждения сводки, как показано на
Рисунке 4.20. Вы должны увидеть сообщение «Тестовая база данных была
успешно создана».
19. Нажмите ОК для закрытия окна сообщения.
20. Если Вы хотите присоединить базу данных ClearQuest, нажмите Select (Выбрать) и
присоедините соответствующий файл.
21. Если Вы хотите присоединить модель Rational Rose, нажмите Add (Добавить) и
присоедините соответствующий файл .mdl.
Рисунок 4.20. Диалоговое окно Create Test Datastore Summary (Создать Тестовую Базу
Данных - Сводка).
22. Нажмите ОК в диалоговом окне Configure Project (Конфигурация проекта), как
показано на Рисунке 4.21.
56
Рисунок 4.21. Диалоговое окно Configure Project (Конфигурация проекта) появляется
после связи с проектом RequisitePro и базой данных.
4.3 Заключение
Настройка проекта RequisitePro состоит из следующих шагов:
Выбор названия проекта и его местоположения на жестком диске.
Выбор шаблона со структурой, подходящей Вам больше всего.
Настройка шаблона.
Импорт документов, которые были созданы до создания проекта.
Настройка может включать следующие операции:
Добавление нового типа документов.
Удаление ненужных типов документов.
Добавление новых типов требований.
Удаление ненужных типов требований.
Добавление новых атрибутов требований.
Удаление ненужных атрибутов требований.
Изменение набора значений для определенных атрибутов.
В этой главе было рассмотрено добавление новых атрибутов требований и изменение
набора значений для определенных атрибутов. Другие варианты будут рассмотрены в
последующих главах.
В зависимости от того, как много требуется изменений, настройка проекта
RequisitePro может занимать от 15-ти минут до нескольких часов. Настройка проекта
Rational обычно не требует никаких дополнительных изменений и занимает меньше чем
полчаса.
57
ГЛАВА 5
Сбор
Требований
Данная глава начинается с описания того, каким образом Вы можете определить
заинтересованных в разработке лиц, способных предоставить требования к системе. В
основной части главы представлено одиннадцать методов сбора требований. Они
используются для сбора потребностей заинтересованных лиц, которым должна
удовлетворять система. Эти требования располагаются на высшем уровне пирамиды
требований, как показано на Рисунке 5.1.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 5.1. Потребности заинтересованных лиц располагаются на высшем уровне
пирамиды требований.
Вторая часть главы показывает, каким образом можно оформить требования
заинтересованных лиц в документы Запросов Заинтересованных Лиц (Stakeholder
Requests documents), используя RequisitePro. Данная часть описывает решение
следующих задач:
Добавление типа документа «Запросы Заинтересованного Лица» в проект (если
он отсутствует в проекте).
Создание документа из шаблона.
Заполнение документа необходимой информацией.
Хранение требований в базе данных.
Использование views (представлений) с требованиями.
5.1 Определение заинтересованных лиц
Большое количество требований поступает от лиц, заинтересованных в разработке
системы. Словарь в Rational Unified Process (RUP) определяет заинтересованное лицо
(stakeholder)
как
«Лицо,
на
которое
результат
работы
системы
оказывает
58
непосредственное влияние». Можно выделить две основных группы заинтересованных
лиц:
Заказчики,
по
требованию
которых
осуществлялась
разработка.
Они
подтверждают результат и обычно финансируют проект.
Пользователи системы.
Эти две группы могут частично перекрывать друг друга, но совсем не обязательно.
Важно различать между заказчиками и пользователями. Их запросы могут быть весьма
различными, а иногда даже противоречивыми. Например, пользователи приложения
центра обработки вызовов (call-центра), принимающие звонки, могут предпочитать
изощренный пользовательский интерфейс, даже если он требует большого времени
загрузки. Заказчик (директор call-центра) может запросить простой пользовательский
интерфейс, который будет быстро загружаться и позволять обслуживать больше звонков в
минуту.
Кроме заказчиков и пользователей, к заинтересованным лицам могут относиться:
группа технической поддержки, группа обслуживания системы, расчетная группа,
отвечающая за проведение сделок, акционеры компании и многие другие.
Каждой группе заинтересованных лиц необходим, по крайней мере, один
представитель, кто будет отвечать за поступление требований. Этот человек должен быть
уполномочен представлять группу, обладать соответствующими знаниями и быть
доступным для связи с группой аналитиков.
Пройдемся по списку потенциальных заинтересованных лиц и определим их для
нашего проекта:
Заказчики.
Выявленные заинтересованные лица: владелец агентства путешествий.
Пользователи.
Пользователи, участвующие в предоставлении требований: Пользователь 1 (из
США) и Пользователь 2 (из Франции).
Все кто участвует в разработке системы (бизнес аналитики, дизайнеры,
кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению,
дизайнеры сценариев использования (use cases), графические дизайнеры).
Заинтересованные
лица,
участвующие
в
предоставлении
требований:
разработчики и контент-менеджеры.
Все кто привносит свои знания в систему (эксперты предметной области, авторы
документов, которые были использованы для сбора требований, собственники
веб-сайтов, ссылки на которые были предоставлены).
В данной группе заинтересованные лица не выявлены.
Руководство (президент компании, которого представляют заказчики, директор
отдела
информационных
технологий
компании,
проектирующей
и
разрабатывающей систему).
Владелец бюро путешествий, упомянутый в первой группе.
Лица, вовлеченные в управление, настройку и сопровождение системы
(хостинговая компания, справочная служба).
Выявленные заинтересованные лица: представитель отдела обслуживания
клиентов, администратор.
Поставщики стандартов и регламентов (стандарты устанавливаются поисковыми
механизмами согласно содержанию веб-сайта, политических норм, а также
порядком налогообложения в конкретном штате).
В данной группе заинтересованные лица не выявлены.
Сторонние компании, вовлеченные в процесс.
Выявленные заинтересованные лица: представитель гостиницы, агент по найму
автомобиля, представитель авиалиний.
5.2 Методы сбора требований
Запросы заинтересованных лиц могут быть собраны с использованием различных
методов:
Интервью (индивидуальный диалог с заинтересованным лицом).
Анкеты (набор вопросов, отправленный большому количеству заинтересованных
лиц).
59
Семинары (заинтересованные лица собираются на определенный период для
интенсивных, насыщенных дискуссий).
Сценарии приложения (использование визуальных/графических инструментов
для демонстрирования поведения системы).
Ролевые игры (каждому члену группы назначается определенная роль, обычно
роль одного из пользователей).
Сессии с применением метода «мозгового штурма» (Brainstorming sessions групповой метод решения вопросов путем изложения идей в течение
непродолжительных, интенсивных сессий).
Использование прототипов (разработка прототипов для получения отклика о
системе).
Сценарии использования (Use Cases – взаимодействие между пользователем и
системой, представленное в виде последовательности шагов).
Анализ существующих документов (извлечение информации из документов
Microsoft Word, электронной почты и записей).
Наблюдение и демонстрирование задач (наблюдение за пользователями,
выполняющими определенную задачу).
Анализ существующих систем (сбор требований от морально устаревших
заменяемых систем или от систем, разработанных в ходе конкуренции).
Таблица 5.1. описывает методы сбора требований, которые были отобраны для
нашего проекта для сбора требований каждого заинтересованного лица, определенного в
Главе 4 «Настройка Проекта».
Таблица 5.1. Заинтересованные Лица и Используемые Методы Сбора их Требований.
Заинтересованное
лицо
Владелец агентства
путешествий
Метод сбора требований
Объяснение
Интервью
Семинар
Данное заинтересованное лицо – заказчик,
кто сделал заказ на разработку системы, и
будет оплачивать ее разработку. Это
определяет его/ее высший приоритет. Обычно в
данном случае мы применяем более чем один
метод сбора требований для обеспечения
максимального охвата требований. Сценарий
интервью, включенный в шаблон для документа
Запросов Заинтересованного Лица, весьма
приемлем, потому он может быть использован
как первый шаг в процессе сбора требований.
Следующий метод - семинар – может быть
использован для уточнения требований с целью
минимизировать возможность упущения
деталей. Будучи заказчиком,
заинтересованное лицо должно также
участвовать в предоставлении
нефункциональных требований, таких как
производительность и надежность.
Пользователь 1
Семинар
Сценарии приложения
Семинар предоставляет больше возможностей
для получения более детальных требований.
Так как Пользователь 1 способен встретиться с
командой разработчиков, мы можем пригласить
его на семинар. Сценарии приложения
используются в течение того же семинара.
Пользователь 2
Документ (электронная
почта)
Пользователь 2 находится в другой стране и
нельзя встретиться с ним лично. Он оказывает
услугу, предоставляя свой отклик о системе, так
что мы хотим, чтоб его расходы оставались
минимальными. Его попросили прислать
электронное письмо с перечнем его требований.
Представитель
отдела
Ролевые игры
Функциональность, требуемая представителем
отдела обслуживания клиентов, составляется на
60
обслуживания
клиентов
основе диалога с пользователями,
обращающимися с различными проблемами. Так
что ролевые игры – это подходящий инструмент
для воссоздания подобных ситуаций.
Администратор
Контент-менеджер
Разработчик
Семинар
Семинар
Семинар
Все три заинтересованных лица являются
членами отдела информационных технологий и
работают в одном месте. Собрать их
одновременно очень легко. Семинар обычно не
требует подготовки формальных документов,
таких как анкета или сценарий интервью.
Представитель
гостиницы
Агент по найму
автомобиля
Представитель
авиалиний
Анкета
Одни и те же вопросы задаются всем трем
службам предоставления услуг, поэтому для них
может быть использована одна анкета. Все три
представителя находятся в разных компаниях в
различных частях страны. И они не могут
встретиться лично.
Анкета
Анкета
Согласно
RUP,
лицо,
ответственное
за
деятельность
Сбора
Требований
Заинтересованного Лица – это системный аналитик (system analyst). В RUP, системный
аналитик (как и другие роли) – это роль, выполняемая членом или членами проектной
команды, и не обязательно является должностью в компании. Во многих проектах эта
задача выполняется бизнес-аналитиком (business analyst) или каким-либо другим лицом.
Интервью
Один из наиболее распространенных методов сбора требований – это интервью с
выбранной группой заинтересованных лиц. Преимуществом данного подхода является
интерактивность, предоставляющая возможность внесения дополнений или доработки
вопросов в зависимости от полученных ответов. Интервью - это хороший способ собрать
требования по удобству использования системы, надежности, производительности и
удобству сопровождения. Обычно заказчики не упоминают эти нефункциональные
требования, пока их явно не спросить об этом. Для интервью бизнес-аналитик должен
иметь приготовленный заранее первоначальный набор вопросов. Однако, в процессе
интервью, могут возникнуть дополнительные вопросы. Шаблон ReqeuisitePro для
документа Запросов Заинтересованного Лица содержит пример сценария, который может
быть использован для интервью. Этот сценарий довольно общий и, возможно, потребует
доработки для каждого конкретного интервью.
Несколько рекомендаций для проведения интервью:
При выборе заинтересованных лиц для интервью убедитесь, что Вы понимаете,
какую именно группу заинтересованных лиц они представляют.
Напишите первоначальный список вопросов.
Проговорите ответы своими словами, чтобы убедиться, что Вы понимаете смысл.
Вы не должны предлагать ответ на Ваш вопрос. Например: Какое время
реакции системы Вы ожидаете? Три секунды?
Не соединяйте несколько вопросов в один. Например: Необходимо ли Вам
печатать ответ, отправлять его по электронной почте и факсу? Быть может,
пользователю нужна только возможность печати отчета и отправки его по
электронной почте, но нет необходимости в факсе.
На этом этапе, не спрашивайте о деталях реализации. Например: Вы
предпочитаете list-box или radio-buttons для выбора метода оплаты?
Не используйте слишком длинные и сложные вопросы.
Не задавайте следующий вопрос, если еще не получен ответ на предыдущий.
Если ответ непонятен, задайте дополнительные вопросы, даже если их нет в
сценарии интервью.
Когда пользователи отклоняются от темы при ответе на заданный вопрос, не
перебивайте их. Позвольте им высказать свои мысли, на какую бы тему они не
размышляли. Затем, если Вы не получили ответа на изначальный вопрос,
задайте его снова.
61
Фиксируйте каждое упомянутое пользователем требование, даже если в
настоящий момент оно кажется неуместным.
Спросите пользователей о дополнительной информации (экранные формы
системы).
При разговоре с заказчиками не говорите о том, будет ли их требование
выполнено или нет. Это будет решено позже.
В конце разговора спросите вопрос для получения дополнительной
информации, например «Что еще я должен знать?».
Выясните у заинтересованного лица приоритет для каждого требования.
Делайте примечания или используйте записывающее устройство.
В качестве примера, используем план документа Запросов Заинтересованного Лица
(Stakeholder Requests) [RUP04], как основу для интервью с владельцем агентства
путешествий.
1. Официальное Представление.
2. Заполнение Профиля Заинтересованного Лица или Пользователя
Имя: Mark Merphy.
Компания/Область: Incredible Travel Agency, Inc.
Должность: Владелец.
Каковы Ваши основные обязанности? Руководство агентством, увеличение
прибыли от продаж.
Какие услуги Вы предоставляете? Для кого? Продажа билетов на самолет,
бронирование номеров в гостиницах и предоставление автомобилей в
аренду.
Каким образом определяется успешность деятельности? Прибылью от
продаж и от привлеченных средств.
Какие проблемы препятствуют Вашему успеху? Без веб-сайта мы
ограничены в предоставлении услуг только местным клиентам.
Какие направления (если есть) делают Вашу работу легче или сложнее?
Интернет дает нам возможность находить много новых клиентов.
3. Определение Проблемы
Для каких проблем Вам необходимо хорошее решение? Он-лайн продажи.
Перечислите, каковы они?
Для каждой проблемы, задайте следующие вопросы:
Почему существует данная проблема?
Как Вы решаете ее сейчас? В настоящее время, заказчики звонят,
чтобы сделать заказ.
Как бы Вы хотели решить ее? Мы бы хотели, чтобы клиенты имели
возможность покупать билеты он-лайн, без необходимости звонить
агенту.
4. Понимание Среды Пользователя
Кто является пользователем системы? Всякий, кто хочет купить билет на
самолет, взять в аренду автомобиль или забронировать номер в гостинице.
Какое у них образование? Разное.
Какое у
них
компьютерное образование?
Имеют
компьютерное
образование, могут пользоваться Интернетом.
Есть ли у пользователей опыт работы с приложением данного типа? Да.
Какие платформы они используют? Каковы Ваши предложения в плане
будущих платформ? Приложение будет платформо-независимым, и будет
доступно через браузер.
С какими дополнительными приложениями, которые Вы используете,
система будет взаимодействовать? Airline Reservation.
Каковы Ваши ожидания в плане удобства использования продукта?
Система должна быть проста в использовании.
Каковы Ваши ожидания в плане выделения времени на тренинги? Время
для изучения должно быть минимальным, а навигация - простой.
Какие печатные копии и он-лайн документация Вам необходимы? Он-лайн
помощь для
пользователей.
Печатная
копия
документации
для
62
представителя отдела обслуживания клиентов, контент-менеджера и
администратора.
5. Обобщение для Понимания
Вы сказали мне….(перечислите своими словами список проблем,
обозначенных заинтересованным лицом).
Отражает ли это Ваши текущие проблемы с существующими решениями?
С какими проблемами Вы уже встречались (если есть)?
6. Взгляд Аналитика на Проблемы Заинтересованного Лица (утверждение или
аннулирование требований)
Какие (если есть) проблемы, связанные с …. (список любых недостатков
или дополнительных проблем которые, по Вашему мнению, могут
беспокоить заинтересованного лица или пользователя)? Отсутствие онлайн продаж.
Для каждой предложенной проблемы, задайте следующие вопросы:
Это реальная проблема? Да.
Каковы причины данной проблемы? Отсутствие веб-сайта.
Каким образом Вы решаете эту проблему? С помощью телефонных
звонков.
Как бы Вы хотели решить проблему? Осуществлением продаж через вебсайт.
Каким образом Вы бы распределили по приоритету решение данных
проблем по сравнению с остальными, Вами обозначенными?
7. Оценка Вашего Решения
Что
если
бы
Вы
могли….(суммирование
главных
возможностей
предложенного Вами решения).
Как бы Вы оценили значимость этого?
8. Оценка Возможности.
Кому необходимо данное приложение в Вашей организации? Главная
польза будет для пользователей. Использовать приложение будут
администратор, представитель отдела обслуживания клиентов и контентменеджер.
Насколько много пользователей данного типа будут пользоваться
приложением?
Один
администратор,
два
представителя
отдела
обслуживания клиентов и один контент-менеджер.
Как бы Вы оценили успешное решение? Оценка успеха: количество
продаж через Интернет, количество обращений к агентам по аренде
автомобилей и к представителям гостиниц.
9. Определение Надежности, Производительности и Требований Сопровождения
Каковы Ваши ожидания в плане надежности? Сопоставимо с другими
коммерческими веб-сайтами в этом плане.
Каковы Ваши ожидания в плане производительности? Сопоставимо будет
сопоставима с другими коммерческими веб-сайтами в этом плане.
Будете ли Вы сами осуществлять сопровождение продукта или ее будет
осуществлять иные лица?
Есть ли у Вас какие-либо специальные требования к сопровождению? Как
насчет обслуживания и сервисного доступа?
Каковы требования к безопасности? Представители гостиниц, агенты по
найму автомобилей и представители авиалиний будут иметь свои
идентификаторы (ID) и пароли для страниц, где они могут предоставлять
свои услуги. Пользователи будут выбирать свой ID и предоставлять пароль
при покупке билета.
Каковы требования к установке и конфигурированию системы? Установка
на пользовательских компьютерах не требуется.
Есть ли специальные требования по лицензиям? Нет.
Каким образом будет осуществляться распространение системы? Система
будет установлена на сервере хостинговой компании.
Каковы требования к маркировке и оформлению пакета требований? Нет.
Каковы (если есть) Ваши требования к инструкциям или среде? Должна ли
осуществляться поддержка стандартов? Нет.
63
Есть ли еще какие-либо требования, о которых мы должны знать? Система
должна быть разработана в течение трех месяцев.
10. Подведение итогов.
Есть ли какие-либо другие вопросы, которые я должен задать Вам? Я бы
хотел добавить еще одну часть функциональности. Чтобы обеспечивать
добавленную
стоимость
для
наших
клиентов,
веб-сайт
должен
предоставлять информацию о туристических развлечениях около пункта
назначения.
Если я должен задать сопутствующие вопросы, я могу звонить Вам? Да.
Хотели бы Вы участвовать в обзоре требований? Да.
11. Резюме Аналитика.
Система должна предоставлять возможность бронирования рейса, покупки
билета, бронирования номера в гостинице, аренды автомобиля, а также
должна предоставлять информацию о туристических развлечениях.
Пользователь должен иметь возможность купить билет через веб-сайт без
необходимости звонков по телефону туристическому агенту.
Система должна следовать инструкциям по разработке, установленных в
сети наших бюро путешествий.
Представители гостиниц, агенты по найму автомобилей и представители
авиалиний должны иметь свои ID (идентификаторы) и пароли для доступа
к страницам, где они предлагают свои услуги.
Система должна быть доступной 24 часа в сутки с уровнем надежности,
соответствующим коммерческим приложениям.
Система должна быть разработана в течение трех месяцев.
Система должна запрашивать ID и пароль пользователя при покупке
авиабилета.
Анкеты
Анкеты наиболее полезны в случае, если у Вас есть возможность задать одни и те же
вопросы многим заинтересованным лицам, и Вы не собираетесь задавать дополнительные
вопросы в процессе беседы. Этот подход требует меньше расходов, и Вы можете собрать
требования с гораздо большего числа заинтересованных лиц, чем Вы будете проводить
непосредственные интервью или приглашать их на семинар. Однако, поскольку анкеты
настолько структурированные и не интерактивны, Вы получаете меньший контроль над
результатами. Вопросы анкеты должны быть понятными и прямолинейными, потому что
отсутствует возможность прояснить непонятные моменты или спорные ситуации до тех
пор, пока Вы не будете взаимодействовать с заинтересованным лицом с помощью иной
техники сбора требований. Преимуществом анкет является то, что они могут быть посланы
по электронной почте и обработаны собственноручно.
В проекте он-лайн агентства путешествий мы посылаем следующие вопросы трем
заинтересованным лицам (представителю гостиниц, агенту по найму машин и
представителю авиалиний):
1. Какая информация от клиента Вам необходима?
2. Какую информацию Вы будете отображать для клиента?
3. Требуете ли Вы оплату при бронировании?
4. Если Вы требуете оплату, какой тип оплаты Вы предпочитаете?
5. Есть ли у Вас какие-либо дополнительные требования?
Вот ответы, полученные от представителя гостиниц:
1. Какая информация от клиента Вам необходима?
Клиент будет предоставить следующую информацию: город, даты пребывания,
количество взрослых, количество детей, предпочтения в отношении номеров.
2. Какую информацию Вы будете отображать для клиента?
При предоставлении информации о гостинице, следующая информация будет
отображаться:
Адрес
Телефон
Факс
64
Электронная почта
Предлагаемые скидки
Доступные способы оплаты
И т.д.
3. Требуете ли Вы оплату при бронировании?
Нет.
4. Если Вы требуете оплату, какой тип оплаты Вы предпочитаете?
Нет необходимости в оплате.
5. Есть ли у Вас какие-либо дополнительные требования?
Пользователю будет предложено заключение соглашения на полет и гостиницу.
Семинары
В процессе семинара по требованиям выбранная группа заинтересованных лиц
встречается с проектной командой. Они собираются для интенсивных, насыщенных
дискуссий. Системный аналитик выступает в качестве организатора семинара.
Ниже приведены несколько задач организатора:
1. Перед семинаром:
Пригласите участников.
Распространите план и предварительный материал, чтобы участники могли
подготовиться к встрече.
Подготовьте комнату для совещаний и необходимое оборудование
(например, проектор).
2. В процессе семинара:
Поручите кому-нибудь делать записи.
Ведите дискуссию в соответствии с планом.
Стимулируйте к участию в беседе всех заинтересованных лиц.
Подведите итоги семинара.
3. После семинара:
Проанализируйте полученные сведения и документально оформите
информацию в презентабельном виде.
Распространите результаты среди участников.
Если необходимо, назначьте дополнительные семинары по результатам.
Семинар по требованиям предоставляет возможность применить другие техники
сбора требований, такие как технику «мозгового штурма», использование сценариев
приложения и ролевые игры. Задачей семинара может быть как сбор новых требований,
так и обзор, уточнение и расстановка приоритетов существующих требований. Результаты
семинара по требованиям должны быть документально оформлены. И лучше всего сделать
это в документах Запросов Заинтересованных Лиц (Stakeholder Requests).
В нашем проекте-образце семинары были проведены с бизнес-аналитиком,
Пользователем 1, менеджером проектов, разработчиком и двумя людьми, кто собственно
будет обслуживать систему: контент-менеджер и системный администратор.
Примеры требований, собранных в течение семинара:
Пользователь 1:
1. Для рейсов вылета и прибытия пользователь должен иметь возможность
сравнивать цены на билеты в других близлежащих аэропортах.
2. Иногда пользователь будет вводить код аэропорта, который система будет
распознавать. В других случаях пользователь будет вводить близлежащий город. В
этом случае пользователю нет необходимости знать код аэропорта, поскольку
система будет понимать название города.
3. Система должна быть проста в управлении.
4. Если пользователь прежде уже покупал билет, то он не должен будет вводить
заново информацию, такую как адрес или номер кредитной карты.
5. Должна быть реализована возможность оплаты через PayPal.
65
6. Даты должны отображаться в формате мм/дд/гггг.
7. Список доступных рейсов должен включать такую информацию, как номер рейса,
время отправления и время прибытия для каждого отрезка пути.
8. Он должен быть отсортирован по ценам.
9. Должна быть предоставлена возможность сравнения цен различных компаний на
аренду машин.
10. Цены на аренду машин должны включать все соответствующие налоги (включая
налог штата - 6%).
11. Для удобства выбора даты рейса в системе должен присутствовать календарь.
Администратор:
1. Функция поиска должна позволять пользователю искать заказ по следующим
критериям:
Фамилия
Дата
2. Любая активность на сайте должна записываться в лог.
3. Должны быть доступны различные отчеты.
Контент-менеджер:
1. При вводе данных контент-менеджер должен иметь возможность вводить обычный
текст без тегов HTML.
2. Информация должна храниться в текстовом файле.
Разработчик:
1. Система должна быть полностью протестирована под
браузерами.
2. Система должна отображать схему проезда до аэропорта.
только
популярными
В течение семинара было также использованы сценарии (описание приведено
далее).
Использование сценариев
Идея сценариев – применение визуальных или графических инструментов для
иллюстрирования желаемого поведения системы. Организатор семинара показывает
первоначальные сценарии группе. Затем, на основании полученных комментариев от
участников, сценарии корректируются и показываются вновь. Корректировка сценариев –
процесс многократный. Это означает, что используемый графический инструмент должен
позволять быстро вносить изменения в реальном времени в процессе семинара. Вы
можете использовать как программные приложения, так и офисное приложение по
созданию презентаций.
Несколько примеров инструментов, которые могут быть использованы:
Бумага, карандаш, ластик.
Мольберт, маркеры.
Доски, с которых можно стирать сухими средствами.
Доски для презентаций.
Приложения по созданию пользовательского графического интерфейса, такие
как Visual Basic или Visual C++.
Microsoft Power Point.
Microsoft Visio.
Графические редакторы, такие как Microsoft Paint.
Текстовые редакторы, такие как Microsoft Word.
В
программных
проектах
сценарии
обычно
представляются
в
виде
последовательности экранов, которые в итоге показываются пользователю, как показано
на Рисунке 5.2.
66
Рисунок 5.2. Простой сценарий, созданный в Microsoft Power Point.
Ролевые игры
Членам групп присваиваются роли, связанные с разрабатываемой системой.
Наиболее часто берутся роли пользователей системы, либо иных взаимодействующих с
системой лиц. Команда проходит через различные сценарии.
В проекте он-лайн агентства путешествий взаимодействие между пользователем и
представителем отдела обслуживания клиентов (CSR) может быть смоделировано с
использованием ролевой игры. Рассмотрим на двух примерах.
Диалог 1
Пользователь:
CSR
Пользователь:
CSR
Пользователь:
CSR
Пользователь:
CSR
Пользователь:
CSR
Диалог 2
Пользователь:
CSR
Пользователь:
CSR
Пользователь:
CSR
Пользователь:
CSR
Здравствуйте. Вчера я забронировал номер в гостинице. Однако я
должен отменить мою поездку, так что я бы хотел отменить мой заказ.
Без проблем. Ваша фамилия?
Smith.
У меня 187 броней на фамилию Smith. Ваше имя?
John.
Все еще 47 совпадений. Какой у вас пункт назначения?
Miami.
Дата?
С 12 сентября до 25 сентября.
Хорошо. Ваш заказ отменен.
Добрый день.
Чем я могу Вам помочь?
Я забронировал билет на самолет и заказал место около окна. Я бы
хотел поменять его на место около прохода.
Как Вас зовут?
Arctos Postopolis
Хорошо. Запись с таким имени уникальна, так что другой информации
мне не требуется. У вас самолет до Лос-Анджелеса 5 апреля?
Да.
Хорошо. Изменения внесены.
В течение ролевой игры были сформулированы следующие требования:
Функция поиска должна позволять представителю отдела обслуживания
клиентов искать запись, используя следующие критерии:
Фамилия
Пункт Назначения
Дата
CRS должен иметь возможность вносить изменения в детали брони или отменить
заказ.
67
Метод «Мозгового Штурма» (Brainstorming Sessions)
В течение данных сессий участники собираются для непродолжительных, но носящих
интенсивный характер сессий. Вначале организатор объявляет цель сессии. Это может
быть создание новых требований в отношении какой-либо части системы, либо решение
различных проблем, например разъяснение некоторого числа противоречивых
требований. Каждый участник может предлагать свои идеи. Атмосфера должна быть
такова, чтобы были высказаны всевозможные идеи, даже самые бредовые. Идеи не
должны критиковаться. Эти правила используются для того, чтобы способствовать
творческому мышлению и противодействовать единообразию идей и замкнутости
участников. После того как все идеи будут записаны, тогда уже могут создаваться
различные комбинации и модификации этих идей. Критика позволительна только после
того, как все идеи будут документально оформлены, и каждая идея будет
проанализирована командой одна за другой.
Данный метод особенно применим в случае, когда необходимо решить какую-либо
проблему – либо весомая часть требований была упущена, либо существуют
противоречивые требования. Достаточно часто требования и дизайн обсуждаются
одновременно, поскольку могут быть рассмотрены некоторые решения проблемы.
Пример.
В течение сбора требований пользователей были обнаружены два противоречивых
требования:
От пользователя из США:
Треб.1: Даты должны отображаться в формате мм/дд/гггг.
От пользователя из Франции:
Треб.2: Даты должны отображаться в формате дд/мм/гггг.
Следующая команда была собрана для решения этой проблемы с помощью метода
«мозгового штурма»:
Пользователь 1
Системный аналитик
Разработчик
Дизайнер
Участники выступили с различными идеями:
Идея 1: Жестко закодировать дату в формате мм/дд/гггг и указать формат для
каждого поля ввода.
Идея 2: Запрашивать регистрацию пользователя при доступе к системе. В
процессе регистрации одним из вопросов будет о том, какой формат даты
предпочитает пользователь.
Идея 3: Создать конфигурационный файл, который будет содержать настройки
пользователя в отношении формата даты. Система будет считывать
конфигурационный файл с жесткого диска.
Идея 4: Использовать формат даты из настроек браузера.
Идеи были собраны и документально оформлены. Они не были подвергнуты критике
или обсуждены в процессе сессии. Каждая идея была проанализирована после
документального оформления всех идей.
Идея 1 была отклонена, так как она носит негибкий характер и не предоставляет
корректный формат для пользователей вне США.
Идея 2 была отклонена, поскольку некоторые пользователи могут не захотеть
проходить
регистрацию.
Требование
регистрации
может
снизить
количество
потенциальных пользователей системы.
Идея 3 была отклонена по техническим причинам и причинам безопасности.
Идея 4 была принята как самое верное решение.
68
Диаграммы Сходства
Использование диаграмм сходства не является отдельной техникой; они
используются в сочетании с сессиями «мозгового штурма» или семинаров по требованиям.
Цель такого метода – это сгруппировать большое количество идей, полученных,
например, в процессе сессий «мозгового штурма». Этот метод также может быть
использован для группировки требований, которые были собраны в процессе семинара по
требованиям.
Диаграммы сходства были изобретены Jiro Kawakita из Японии. Они особенно
применимы в случаях, когда:
Количество идей очень велико.
Соотношения между отдельными пунктами не совсем ясны.
Существуют сложные спорные моменты.
Необходимо прийти к консенсусу внутри группы.
Эта техника включает следующие шаги [TAG04]:
Создание карточек. Каждая идея пишется на карточке или стикере. Используйте
маркеры, чтобы текст был виден с достаточно большого расстояния. Карточки
размещаются в любом случайном порядке на большой рабочей поверхности
типа стола или доски.
Сортировка карточек. Каждый участник выделяет пункты, имеющие какую-либо
взаимосвязь, и помещает соответствующие карточки рядом друг с другом.
Участники не должны взаимодействовать в течение этого шага. Если один пункт
подходит сразу к нескольким группам, можно сделать копии карточек и
поместить их в несколько групп. Этот шаг занимает несколько дней.
Обсуждение модели. После того как все карточки были рассортированы, группа
может обсудить классификацию, замеченные тенденции и причины, почему
карточки были сгруппированы именно таким образом.
Создание заголовков. Наименование будет создано для каждой группы.
Структурирование модели. Если необходимо, некоторые группы можно будет
скомбинировать в более большие группы, либо разделить на более мелкие.
Пример «мозгового штурма», приведенный выше, не очень хорош для применения
диаграмм сходства, поскольку в процессе семинара было сгенерировано малое количество
идей. Тем не менее, диаграммы сходства могут быть использованы для группировки
требований, являющихся результатом семинаров.
Использование Прототипов
Использование прототипов – это очень эффективный способ получения отклика от
пользователей и заказчиков. Однако это один из наиболее дорогих методов, потому что
он требует разработки прототипа - упрощенной версии системы. Большинство
функциональности, как правило, жестко кодируется, так что прототип является как бы
усовершенствованной версией сценариев приложения. Иногда работу над прототипом
прекращают, но в других проектах прототип продолжает усовершенствоваться, и в итоге
превращается в конечную систему.
Анализ Существующих Документов
Многие требования могут быть извлечены из существующих документов. В качестве
источника требований могут быть использованы следующие документы:
Бизнес модель
Комментарии к совещаниям
Содержание работы
Корпоративные нормы
Заявка на разработку
Письма
Бизнес правила
Электронная почта
Один из методов - это чтение документов и использование выделения текста чтобы
отметить предложения, которые составляют требования.
Из документов, которые уже есть в электронной форме, Вы можете вырезать части
текста и вставлять в RequisitePro в документ Запросов Заинтересованного Лица
(Stakeholder Requests) - выделять с помощью мышки любое предложение, которые
69
представляет собой требование, и хранить документ в базе данных. Пункт 5.4 объясняет,
каким образом можно это выполнить.
В нашем проекте-образце требования от Пользователя 2 были получены через
электронную почту:
-----Оригинальное Сообщение----От: Claude
Отправлено: Суббота, 26 Августа, 2006 19:01
Кому: Julia
Тема: Требования
Дорогая Julia,
В ответ на твое письмо я собрала немного требований для Вашей новой
системы:
1. Пользователь должен иметь возможность сравнивать цены на билеты в
других близлежащих аэропортах.
2. Даты должны отображаться в формате дд/мм/гггг.
3. На формах ввода данных должно показываться, какие поля являются
обязательными для заполнения.
4. Должна быть возможность отмены покупки билета.
5. Пользователь должен иметь возможность отменить заказ машины или
номера в гостинице.
6. Список рейсов вылета и возвращения должен быть отсортирован по
наименьшему количеству остановок.
7. Пользователь должен иметь возможность выбрать место в самолете.
8. Интерфейс системы должен быть на естественном языке.
9. Система должна показывать всплывающее окно с календарем, когда
пользователь вводит дату.
10. Пользователь с помощью флажка должен указывать, нужен ли ему/ей
билет только в один конец, или билет туда и обратно.
С наилучшими пожеланиями,
Claude
Сценарии Использования (Use Cases)
Сценарии использования (Use Cases) являются одним из типов требований в
пирамиде на Рисунке 1.1. в Главе 1 «Управление Требованиями». Это также формат,
используемый заинтересованными лицами для выражения своих потребностей. Формат
сценариев использования, созданный заинтересованными лицами, в конечном счете,
используется аналитиками. Тем не менее, аналитики должны просмотреть поступившие от
пользователя сценарии использования. Перед тем как поместить сценарии использования
на третий уровень пирамиды, аналитики должны выполнить следующие действия:
1. Убедиться, что каждый шаг сценариев использования содержит все атрибуты для
того, чтобы требование можно было считать хорошим, как было описано в пункте
1.4 «Характеристики Хорошего Требования» в Главе 1.
2. Импортировать сценарии использования в RequisitePro.
3. Создать требования, которые будут отсортированы в базе данных.
4. Установить соответствие с функциональными особенностями системы.
Наблюдение и демонстрирование задач
Иногда пользователи не могут выразить словами детали их задач. В этом случае
может быть гораздо легче показать бизнес-аналитикам, каким образом эта задача должна
быть выполнена [LAU02]. Преимуществом данного подхода является то, что пользователь
может сконцентрироваться на задаче, в то время как аналитик записывает комментарии и
проводит наблюдение. Отличием между наблюдением и демонстрированием задач
является то, что при наблюдении пользователь представляет обычные задачи без
привлечения внимания системного аналитика. При демонстрировании задач аналитик
может попросить пользователя выполнить определенную задачу, и пользователь может
выполнить демонстрацию с объяснениями.
70
Анализ Существующих Систем
Анализ существующих систем может служить источником многих различных
требований. Существует два главных типа систем, заслуживающие проведения анализа:
• Морально устаревшие заменяемые системы.
• Системы, разработанные в ходе конкуренции.
Достаточно часто в ситуации, когда новая система заменяет старую систему, одним
из требований должно быть:
Треб.1: Новая система должна предоставлять всю функциональность от предыдущей
системы.
Этот запрос довольно неясный, так что мы будем призывать заказчиков
предоставлять нам более подробные требования. Тем не менее, очень часто отсутствует
документация на используемый в настоящее время продукт. Так что наилучший способ
получить требования – это проводить эксперимент с существующей системой и извлекать
ее функционал. Так как мы уже имеем разработанные экранные формы, мы можем
скопировать и вставить их в сценарии использования или сценарии приложения.
Если Вы разрабатываете систему, схожую с уже разработанными другими
компаниями системами, и у вас есть доступ к конечному продукту, тогда стоит
проанализировать их работу, чтобы извлечь уроки из их успеха или научиться на их
ошибках.
Так как в Интернете доступно большое количество агентств путешествий, для нашего
проекта-образца системные аналитики решили проанализировать следующие веб-сайты:
• http://travel.yahoo.com
• www.expedia.com
• www.cheaptickets.com
• www.travelocity.com
5.3 Создание Документа Запросов Заинтересованного Лица
Вся полученная в процессе сбора требований информация должна быть
документально оформлена в документ Запросов Заинтересованного Лица (Stakeholder
Requests). В Вашем проекте Вы можете создать один документ, который будет содержать в
себе запросы всех заинтересованных лиц, один документ для каждого заинтересованного
лица, либо можете собрать запросы нескольких заинтересованных лиц в одном документе.
Если нет необходимости описывать требования заинтересованного лица в деталях, Вы
можете создать пункт «Stakeholders Requests» («Запросы Заинтересованных Лиц») в
документе Концепции (Vision). Это снизит необходимость создания отдельного документа.
Предположим, что в целях нашего проекта мы создадим шесть документов Запросов
Заинтересованного Лица, сгруппировав заинтересованных лиц по методам сбора их
требований (примененных к ним в пункте 5.2):
«Запросы Заинтересованного Лица–Заказчик» содержит требования владельца
агентства путешествий, собранные в результате интервью.
«Запросы Заинтересованного Лица–Пользователь 1» содержит требования
Пользователя 1.
«Запросы Заинтересованного Лица–Пользователь 2» содержит требования
Пользователя 2, отправленные по электронной почте.
«Запросы Заинтересованного Лица–CSR» содержит требования CSR (представителя
отдела обслуживания клиентов), собранные в процессе ролевых игр.
«Запросы Заинтересованного Лица–Отдел Информационных Технологий» содержит
требования администратора, контент-менеджера и разработчиков, собранные в
результате семинара по требованиям.
«Запросы Заинтересованного Лица–Служба Предоставления Услуг» содержит
требования представителя гостиницы, агента по найму автомобиля и представителя
авиалиний, собранные в результате анкетирования.
Создадим документ Запросы Заинтересованного Лица (Stakeholder Requests). В
первую очередь, Вам нужно открыть созданный в предыдущей главе проект.
71
Открытие Проекта
Когда Вы запускаете RequisitePro, появляется диалоговое окно Open Project (Открыть
Проект), как показано на Рисунке 5.3.
Рисунок 5.3. Диалоговое окно Open Project (Открыть проект).
Вы можете выбрать проект из списка (по умолчанию список содержит все ранее
используемые проекты) или создать новый проект. Если Вы хотите открыть существующий
проект, которого нет в списке, Вы должны сначала добавить проект в список
существующих проектов нажатием на кнопку Add (Добавить). В данном случае мы
выбираем проект Он-Лайн Агентство Путешествий (Online Travel Agency) из списка.
Добавление Типа Документа в Проект
Каждый тип документа обычно связан с некой моделью - шаблоном Microsoft Word
(.dot файл). Суть данной модели и является стартовой точкой при создании нового
документа. Модель включает в себя форматы, параметры страницы и шрифты. Вы можете
использовать уже предустановленные шаблоны RequisitePro, либо создать их сами. Если
Вы установите модель в None, то при создании нового документа этого типа откроется
пустой документ Microsoft Word.
Тип документов «Запросы Заинтересованного Лица» включен в шаблон Use Case
(Сценариев Использования), который мы использовали для создания нашего проекта, так
что нет необходимости добавлять этот тип документа в наш проект.
Если Вы не уверены, что Ваш проект включает в себя тип документов «Запросы
Заинтересованного Лица», выполните следующие действия:
1. Выберите проект в Explorer (Проводнике).
2. Выберите File>Properties (Файл>Свойства).
3. Выберите закладку Documents Type (Тип Документов).
Если тип документов «Запросы Заинтересованного Лица» находится в списке, то Вам
не нужно добавлять его. Однако если этот тип документа отсутствует в проекте,
следующие шаги помогут добавить его:
1. Выберите File>Properties (Файл>Свойства). Появится диалоговое окно File
properties (Свойства Проекта).
2. Выберите закладку Documents Type (Тип Документов).
3. Нажмите Add (Добавить). Появится диалоговое окно Document Type (Тип
Документа), как показано на Рисунке 5.4.
72
Рисунок 5.4. Диалоговое окно Document Type (Тип Документа).
4. Введите название документа, описание и расширение файла.
5. В списке Default Requirement Type (Тип Требования по Умолчанию) выберите
«Запросы Заинтересованного Лица». Если такого типа нет в списке, создайте его,
нажав на кнопку New (Новый), и заполнив диалоговое окно.
6. В списке Outline Name (Названия Моделей) выберите RUP Stakeholder Requests
outline.
7. Нажмите OK, чтобы закрыть диалоговое окно Document Type (Тип Документа).
8. Нажмите OK, чтобы закрыть диалоговое окно Project Properties (Свойства
Проекта).
Обратите внимание, что пользователь указывает расширение файла. Наличие
отличного от .doc расширения вынуждает использование RequisitePro для изменения
документа, так как другие пользователи не смогут открыть и редактировать его,
используя Microsoft Office или любой другой редактор.
Создание Документа Запросов Заинтересованного Лица
Чтобы создать документ Запросов Заинтересованного Лица (Stakeholder Requests)
выполните следующие шаги:
1. Выберите папку, где Вы хотели бы создать документ. В шаблоне Use Case
(Сценариев
Использования),
папка
«Stakeholders
Requests»
(«Запросы
Заинтересованных Лиц») уже создана.
2. Выберите File>New>Document (Файл>Новый>Документ) (или нажмите правой
кнопкой мышки на папке и выберите New>Document).
Появится диалоговое окно Document Properties (Свойства Документа), как
показано на Рисунке 5.5.
3. В поле Name (Имя) введите имя документа. Если у вас только один документ в
проекте, он может называться просто «Запросы Заинтересованного Лица». Если
Вы создаете документ для каждого заинтересованного лица, включите в название
документа имя или тип заинтересованного лица, например «Пользователь». Если
это комбинированный документ для нескольких заинтересованных лиц, к
которым был применен определенный метод сбора требований, Вы можете
включить метод в название документа, например «Запросы Заинтересованного
Лица–Анкетирование»,
либо
можете
использовать
название
группы
заинтересованных лиц, например «Запросы Заинтересованного Лица-Служба
Предоставления Услуг».
4. В поле Description (Описание) введите краткое описание документа.
73
Рисунок 5.5. Диалоговое окно Document Properties (Свойства Документа).
5. В поле Filename (Название Файла) введите название файла, которое RequisitePro
будет использовать при сохранении документа. Оно может быть аналогично
названию документа или являться только его аббревиатурой.
6. Выберите Document Type (Тип Документа) - Stakeholder Requests (Запросы
Заинтересованного Лица).
7. Нажмите ОК.
Новый созданный документ появится в окне Microsoft Word, как показано на Рисунке
5.6.
Рисунок 5.6. Начальная страница документа Запросов Заинтересованного Лица
(Stakeholder Requests).
RequisitePro управляет документом через рабочее пространство Microsoft Word. Вы
можете изменять текст в документе так же, как бы Вы это делали с обычным документом
Microsoft Word. Некоторые поля в шаблоне содержат общие названия как <Company
Name> (Название Компании) или <Project Name> (Название Проекта). При выборе, фон у
этих полей становится серым. Они должны быть заменены актуальными значениями.
Наиболее удобный способ их поменять - это открыть диалоговое окно Properties
74
(Свойства) (выберите File>Properties (Файл>Свойства)) и ввести соответствующие имена,
как показано на Рисунке 5.7.
Рисунок 5.7. Диалоговое окно Document Properties (Свойства Документа).
После того как были установлены свойства документа, Вы можете сменить поле в
шаблоне путем помещения курсора на поле и нажатия F9. Поле будет заполнено
соответствующим значением из диалогового окна Properties (Свойства), как показано на
Рисунке 5.8.
Рисунок 5.8. Первая страница документа с соответствующими полями, полученными из
диалогового окна Document Properties (Свойства Документа).
Документ, генерируемый RequisitePro по умолчанию, содержит написанный синим
курсивом текст инструкции. Он поясняет, что именно должно быть написано в
определенном пункте документа. Замените текст инструкции соответствующей проектной
информацией.
Формат документа Запросов Заинтересованного Лица зависит от используемого при
сборе требований метода. Изначальная версия документа содержит сценарий интервью,
75
используемый в предыдущем пункте «Интервью». Тем не менее, общая структура
документа может быть модифицирована в зависимости от Ваших потребностей.
Рисунок 5.9. показывает простой формат, который мы использовали для создания
этого документа для Пользователя 2, предоставившего требования по электронной почте.
Требования были просто вырезаны из письма и вставлены в параграф №3 документа.
Рисунок 5.9. Пример структуры документа Запросов Заинтересованного Лица
(Stakeholder Requests).
После заполнения документа считается хорошей практикой пересмотреть таблицу
содержания:
1. Поместите курсор на таблицу содержания.
2. Выберите Insert>Reference>Index and Tables (Вставить> Ссылка>Таблицы).
3. Выберите закладку Table of Contents (Таблица Содержания).
4. Нажмите ОК. Появится сообщение, спрашивающее Вас: «Желаете ли Вы заменить
выбранную таблицу содержания?».
5. Нажмите Yes (Да).
В
конце
сохраните
документ.
Выберите
RequisitePro>Document>Save
(Документ>Cохранить). (Не выбирайте File>Save (Файл>Сохранить), как Вы бы сделали в
обычном документе Microsoft Word).
5.4 Создание Требований в RequisitePro
После того как Вы ввели в документ информацию в свободной форме, Вы должны
создать формальные требования. Определение требований и хранение их в базе данных
очень важно для контроля соответствий потребностей заказчика и функциональных
особенностей системы.
Документ Запросов Заинтересованного Лица не содержит специально выделенного
места для размещения требований типа STRQ (Stakeholder Requests или Запросы
Заинтересованного лица). Требования могут быть вложены в качестве ответов на вопросы
интервью, либо собраны в последнем параграфе, названным «Резюме Аналитика».
Главными атрибутами требования являются Text (Текст, обязательный атрибут) и
Name (Название, не обязательный). Если Text – короткий (описание состоит из одного
предложения), то Вам не надо создавать отдельное Name. Если описание Text длинное,
тогда стоит создать краткое название для требования. Если указано Name, оно
используется для идентификации требования. Если Name не указано, для идентификации
используется Text. Для большей точности лучше использовать название для всех
требований одного типа, либо не использовать название ни для одного из них. В нашем
76
проекте мы создадим названия, потому что некоторые потребности заинтересованных лиц
довольно обширные. Названия требований должны быть короткими, но содержательными.
Требования могут быть созданы в RequisitePro пятью разными способами:
1. Создание в документе (используя рабочее пространство Microsoft Word).
2. Создание во view (представлении).
3. Создание в Explorer (Проводнике).
4. Импорт из файла, имеющем точку с запятой в качестве разделителя (CSV).
5. Импорт из документа требований.
Данная глава описывает создание требований из документа Microsoft Word, который
является наиболее популярным.
Добавление Требований в Документ
Для создания требований в документе Microsoft Word выполните следующие
действия:
1. Выделите текст, описывающий требование, как показано на Рисунке 5.10.
Рисунок 5.10. Выделение текста требования в документе.
2. Выберите RequisitePro>Requirement>New (Требование>Новое), или нажмите
правую кнопки мышки на тексте и выберите Create Requirement (Создать
Требование), или нажмите иконку New Requirement (Новое Требование) на
панели управления.
Появится диалоговое окно Requirement Properties
показано на Рисунке 5.11. Текст уже скопирован
области. Если необходимо, Вы можете добавить
документа тип установлен по умолчанию. Вы
необходимости.
(Свойства Требования), как
с выделенной в документе
название. Для этого типа
можете поменять его при
Рисунок 5.11. Диалоговое окно Requirement Properties (Свойства Требования): Основная
закладка.
77
3. Выберите STRQ (Запросы Заинтересованного лица) как тип требования.
4. Если Вы хотите настроить атрибуты, нажмите закладку Attributes (Атрибуты), как
показано на Рисунке 5.12.
Рисунок 5.12. Диалоговое окно Requirement Properties (Свойства Требования): закладка
Атрибуты.
5. Нажмите ОК.
Атрибуты требования могут быть также изменены из view (представления) и из
Explorer (Проводника). Каждое требование включает префикс и числовое значение.
RequisitePro присваивает уникальный тег каждому создаваемому требованию. Тег
требования – это его уникальный идентификатор. Префиксы связаны с типами
требований.
Пока документ еще не сохранен, теги отображаются со словом «pending»
(ожидающие), как показано на Рисунке 5.13.
Рисунок 5.13. Находящиеся на ожидании требования.
Чтобы
сохранить
документ,
выберите
в
окне
Microsoft
Word
RequisitePro>Document>Save
(Документ>Сохранить).
Не
выбирайте
File>Save
(Файл>Сохранить).
После сохранения документа,теги содержат префиксы с описанием типа требования
и упорядоченными номерами, как показано на Рисунке 5.14.
78
Рисунок 5.14. Сохраненные требования.
Требования могут быть просмотрены в окне Explorer (Проводника), как показано на
Рисунке 5.15.
Когда Вы закончите с первым документом Запросов Заинтересованного Лица, Вы
можете создать подобные документы для остальных заинтересованных лиц.
Рисунок 5.15. Окно Проводника, отображающее STRQ требования (Запросы
Заинтересованного лица).
Изменение Атрибутов Типов Требований
По умолчанию, требования типа STRQ (Запросы Заинтересованного лица)
показываются в документе серым цветом. Если Вы считаете что цвет слишком светлый, Вы
можете сменить его путем изменения атрибутов типа требований. Сменим цвет на темноголубой:
1. Поместите курсор на название проекта в Explorer (Проводнике).
2. Выберите File>Properties (Файл>Свойства).
3. Выберите закладку Requirement (Требование).
4. Выберите тип требования STRQ (Запросы Заинтересованного лица), как показано
на Рисунке 5.16.
79
Рисунок 5.16. Выбор типа требования STRQ (Запросы Заинтересованного лица).
5. Нажмите Edit (Редактировать).
6. Смените цвет требования на Dark Blue (темно-голубой), как показано на Рисунке
5.17.
Появится следующее окно сообщений: «Данная функция требует, чтобы проект
был открыт эксклюзивно. Хотите ли Вы получить эксклюзивный доступ к проекту
сейчас?».
Рисунок 5.17. Смена цвета требования на темно-голубой.
7. Нажмите Yes (Да) для подтверждения открытия проекта в эксклюзивном режиме.
Появится окно сообщения о подтверждении действия.
8. Нажмите OK в окне подтверждения.
9. Нажмите OK в диалоговом окне Requirement Type (Тип Требования).
10. Нажмите OK на экране Project Properties (Свойства Проекта).
Атрибут, отвечающий за цвет для STRQ требований (Запросов Заинтересованного
лица), сменился.
Добавление Требований из Проводника
Если Вы решили, что проект не требует документов Запросов Заинтересованного
Лица, но Вам необходимы требования типа STRQ (Запросы Заинтересованного лица), Вы
можете добавить требования из view (представления) или из Explorer (Проводника).
Для добавления требования из Explorer (Проводника) выполните следующие
действия:
80
1. Нажмите правой кнопкой мышки на названии папки, в которой Вы хотите создать
требование.
2. Выберите New>Requirement (Новое>Требование). Появится то же самое
диалоговое окно Requirement Properties (Свойства Требования).
3. Заполните необходимые поля и нажмите ОК.
Изменение Требований из Проводника
Вне зависимости от того, каким образом требование было создано, Вы можете
изменить его через Explorer (Проводник).
1. Нажмите
правой
кнопкой
мышки
на
требовании
STRQ
(Запросы
Заинтересованного лица) в Explorer (Проводнике) и выберите Properties
(Свойства).
2. Внесите необходимые изменения и нажмите ОК.
Удаление Требований из Проводника
Для удаления требования из Explorer (Проводника) выполните следующие действия:
1. Выделите требование.
2. Нажмите правой кнопкой мышки на нем и выберите Delete (Удалить).
Удаленные требования не могут быть восстановлены. Если Вы считаете, что Вам
необходима функциональность восстановления, лучше создать дополнительный статус,
названный «Deleted» (Удаленный). Требования с этим статусом могут быть восстановлены
путем смены статуса в обратном порядке на Proposed (Планируемый) или Approved
(Подтвержденный).
5.5 Создание Views (Представлений) для Анализа Требований
Views (или представления) используются для отображения требований, а также для
управления требованиями, их атрибутами и их взаимоотношениями с другими
требованиями. Вы можете сортировать и фильтровать требования, чтобы получить
необходимый отчет. RequisitePro имеет три типа представлений:
• Attribute Matrix (Матрица Атрибутов)
• Traceability Matrix (Матрица Трассировки)
• Traceability Tree (Дерево Трассировки)
В этой главе рассматривается Матрица Атрибутов. Остальные два типа будет
рассмотрены в следующих главах.
Создание Матрицы Атрибутов
После того, как Вы ввели требования всех заинтересованных лиц в систему,
создадим представление, показывающее запросы всех заинтересованных лиц. Для
создания нового представления, не включенного в шаблон, выполните следующие
действия:
1. Нажмите правой кнопкой мышки на папке, где Вы хотите создать представление
(папка «Stakeholders Requests» будет хорошим выбором в данном случае), и
выберите New>View (Новое>Представление). В качестве альтернативы Вы
можете выделить папку, где Вы хотите создать view, и выбрать File>New>View
(Файл>Новое>Представление).
Появится диалоговое окно View Properties (Свойства Представления), как показано
на Рисунке 5.18.
2. Дайте название представлению.
3. Выберите View Type (Тип Представления - Матрица Атрибутов, Матрица
Трассировки или Дерево Трассировки). В данном случае - Матрица Атрибутов.
4. Выберите Row Requirement Type (Тип Требования в Строке) – в данном случае
STRQ (Запросы Заинтересованного Лица).
Если бы Вы создавали Матрицу Трассировки, Вам бы также понадобилось бы
выбрать Column Requirement Type (Тип Требования в Столбце).
81
Рисунок 5.18. Диалоговое окно View Properties (Свойства Представления).
5. Нажмите ОК.
Открытие View (Представления)
Многие представления уже предустановленны в шаблонах проектов. Так как мы
использовали шаблон Use Case (Сценариев Использования), у нас уже есть представление
All Stakeholders Requests (Все Запросы Заинтересованного Лица) в папке Stakeholders
Requests. Нам надо лишь открыть представление, выполнив следующие действия:
1. Откройте папку Features and Vision (Функциональные Особенности и Концепция).
2. Двойным щелчком мышки нажмите на представление All Features (Все свойства).
Матрица Атрибутов отобразит все требования определенного типа с их атрибутами.
Это отображение в табличном виде с именами требований в строках и атрибутов в
столбцах, как показано на Рисунке 5.19.
Рисунок 5.19. Матрица Атрибутов, показывающая все потребности заинтересованных
лиц и их атрибуты.
82
Чтобы изменить набор отображаемых атрибутов выполните следующие действия:
1. Поместите курсор на заголовок строки на панели представления, нажмите правой
кнопкой мышки и выберите Displayed Attributes (Отображаемые Атрибуты).
2. В списке Displayed Attributes (Отображаемые Атрибуты) выберите атрибуты,
которые Вы хотите видеть на представлении, как показано на Рисунке 5.20.
Рисунок 5.20. Выбор атрибутов для отображения в матрице атрибутов.
Так как в процессе создания требований мы не установили приоритеты, мы можем
сделать это сейчас. Для изменения атрибутов требования выполните следующие
действия:
1. Нажмите правой кнопкой мышки на соответствующей ячейке и выберите Set
Value (Установить Значение).
2. Выберите значения из списка, как показано на Рисунке 5.21.
Рисунок 5.21. Установка значения атрибута с использованием диалогового окна Set
Value (Установить Значение).
Другой путь изменения атрибутов требования – это двойной щелчок мышки на
соответствующей ячейке в таблице и выбор атрибута из выпадающего списка, как
показано на Рисунке 5.22.
Рисунок 5.22. Установка значения атрибута с использованием выпадающего списка в
ячейке.
Чтобы изменить Requirement Name (Название Требования) или Text (Текст), нажмите
правой кнопкой мышки на требовании и выберите Properties (Свойства).
Требования могут быть созданы прямо в Матрице Атрибутов. Тем не менее, не
считается хорошей практикой хранить часть требований одного и того же типа в
документах, а другую часть только в представлении. Вы можете изменять требования вне
83
зависимости от того как оно было создано. Если Вы меняете текст требования в
представлении, это изменение будет также отображено в документе.
Экспорт Представлений (Views)
Мы можем экспортировать представления в документ Microsoft Word или в CSV-файл
(который мы можем открыть с помощью Microsoft Exсel). Это позволяет использовать
данную информацию вне среды Requisite Pro.
Для экспорта только что созданной нами матрицы атрибутов выполните следующие
действия:
1. Выберите File>Export>Export to CSV (Файл>Экспорт>Экспорт в CSV).
2. Введите название файла.
3. Нажмите кнопку Save (Сохранить).
Представление сохраняется в CSV-файле, который
использованием Microsoft Exсel, как показано на Рисунке 5.23.
Вы
можете
открыть
с
Рисунок 5.23. Матрица Атрибутов, экспортированная в Excel.
Создание Запросов для Требований
Вы можете создавать запросы для требований (на фильтрацию и сортировку
информации) в Матрице Атрибутов (Attribute Matrix). Чтобы фильтровать строки, Вы
можете указать, каким критериям должны удовлетворять строки для отображения в
матрице. В качестве примера, отобразим только требования, которые имеют приоритет
High (Высокий) или Medium (Средний), а Origin (Источник) требования - Пользователя 1
или Пользователя 2.
1. Нажмите правой кнопкой мышки на левом верхнем квадрате представления.
2. Выберите Query (Запрос). Появятся диалоговые окна Query Row Requirements
(Запрос к Требованиям в Строке) и Select Attribute (Выбор Атрибута).
3. Выберите Priority (Приоритет) из списка атрибутов и нажмите ОК.
4. Выберите High (Высокий) и Medium (Средний) из списка значений атрибутов и
нажмите ОК.
5. Нажмите Add (Добавить).
6. Выберите Origin (Источник) из списка атрибутов. Нажмите ОК.
7. Выберите Пользователь 1 и Пользователь 2 из списка значений атрибутов, как
показано на Рисунке 5.24.
84
Рисунок 5.24. Выбор значений атрибутов для фильтрации.
8. Сохраните все изменения нажатием кнопки ОК, как показано на Рисунке 5.25.
Рисунок 5.25. Все критерии запроса (соединенные оператором «AND» - «И»).
В диалоговом окне Query Row Requirements (Запрос к Требованиям в Строке) Вы
также можете установить Sort Order (Порядок Сортировки) для выбираемых атрибутов в
Ascending (Восходящий) or Descending (Нисходящий).
Чтобы отменить все фильтры и вернуться к оригинальному виду выполните
следующие действия:
1. Нажмите правой кнопкой мышки на левом верхнем квадрате view.
2. Выберите Query (Запрос).
3. Нажимайте кнопку Remove (Удалить) в диалоговом окне Query Row Requirements
(Запрос к Требованиям в Строке), пока Вы не удалите все строки.
4. Нажмите ОК.
Вы можете сохранить результаты запроса в представлении. Представление будет
отображать состояние на момент времени запроса. Чтобы отобразить недавно сделанные
изменения
в
базе
данных,
Вам
необходимо
выбрать
View>Refresh
(Представление>Обновить).
5.6 Заключение
Запросы заинтересованных в разработке системы лиц могут быть собраны с помощью
различных методов сбора информации. Мы обсудили одиннадцать из них. Какую технику
выбрать – зависит от природы требований и типа заинтересованного лица. Хорошей
практикой считается запись результатов в RequisitePro в форме документов Запросов
Заинтересованных Лиц (Stakeholder Requests), а также хранение требований в базе
данных. Наличие потребностей заинтересованных лиц в базе данных позволит Вам
присваивать им различные атрибуты, такие как приоритет сложности. Также это позволит
Вам отслеживать требования и сводить их к требованиям другого типа.
Ссылки
[RUP04] Rational Unified Process, Version 2003.06.13, IBM, 2003.
[TAG04] Tague, Nancy. The Quality Toolbox, ASQ Quality Press, 2004.
[LAU02] Lauesen, Soren. Software Requirements: Styles and Techniques, Pearson Education.
85
ГЛАВА 6
Разработка Документа
Концепции (Vision)
Документ Концепции (Vision) – один из трех наиболее важных документов,
создаваемых в RequisitePro (другие два: Сценарии Использования - Use Cases и
Дополнительная Спецификация - Supplementary Specification). Документ Концепции
содержит следующую информацию:
Описание проблемы, которая будет решаться новой системой.
Высокоуровневое описание решения проблемы.
Список основных функциональных особенностей системы.
Концепция может выступать в качестве контракта между заказчиком и
разработчиками для технических требований. Назначение документа Концепции:
Определить границы системы.
Определить ограничения, налагаемые на систему.
Прийти к соглашению с заказчиком по поводу объема работ.
Создать основу, на которой определить Сценарии Использования (Use Cases) и
Дополнительную Спецификацию (Supplementary Specification).
Концепция – это хранилище для требований типа Feature (Функциональные
особенности), как показано на Рисунке 6.1. Данная глава показывает несколько примеров
извлечения функциональных особенностей из потребностей, а также рассматривает
атрибуты функциональных особенностей.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 6.1. Функциональные особенности находятся на втором уровне пирамиды.
6.1 Структура Документа Концепции
Содержание
документа
RequisitePro [RUP04]:
Концепции
86
(Vision),
предустановленное
шаблоном
1. Introduction (Введение)
1.1 Purpose (Назначение)
1.2 Scope (Область Применения)
1.3 Definitions, Acronyms, and Abbreviations (Определения, Акронимы и Аббревиатуры)
1.4 References (Ссылки)
1.5 Overview (Обзор)
2. Positioning (Позиционирование)
2.1 Business Opportunity (Возможности Бизнеса)
2.2 Problem Statement (Изложение Проблемы)
2.3 Product Position Statement (Изложение Позиции Продукта)
3. Stakeholder and User Descriptions (Описание Заинтересованных Лиц и Пользователей)
3.1 Market Demographics (Демография на Рынке)
3.2 Stakeholder Summary (Сводка по Заинтересованным Лицам)
3.3 User Summary (Сводка по Пользователям)
3.4 User Environment (Программная Среда Пользователей)
3.5 Stakeholder Profiles (Профили Заинтересованных Лиц)
3.6 User Profiles (Профили Пользователей)
3.7 Key Stakeholder or User Needs (Ключевые Потребности Заинтересованных Лиц или
Пользователей)
3.8 Alternatives and Competition (Альтернативы и Конкуренция)
3.8.1 <Конкурент>
3.8.2 <другойКонкурентr>
4. Product Overview (Обзор Продукта)
4.1 Product Perspective (Перспективы Продукта)
4.2 Summary of Capabilities (Сводка по Возможностям)
4.3 Assumptions and Dependencies (Предположения и Зависимости)
4.4 Cost and Pricing (Стоимость)
4.5 Licensing and Installation (Лицензирование и Установка)
5. Product Features (Функциональные Особенности Продукта)
5.1 <ФункциональнаяОсобенность>
5.2 <другаяФункциональнаяОсобенность>
6. Constraints (Ограничения)
7. Quality Ranges (Пределы Качества)
8. Precedence and Priority (Очередность и Приоритетность)
9. Other Product Requirements (Другие Требования к Продукту)
9.1 Applicable Standards (Приемлемые Стандарты)
9.2 System Requirements (Системные Требования)
9.3 Performance Requirements (Требования к Производительности)
9.4 Environmental Requirements (Требования к Программной Среде)
10. Documentation Requirements (Требования к Документации)
10.1 User Manual (Руководство Пользователя)
10.2 Online Help (Он-лайн Справка)
10.3 Installation Guides, Configuration, and Read Me File (Руководство по Установке,
Конфигурированию, Файл «Прочти Меня»).
10.4 Labeling and Packaging (Маркировка и Оформление Пакета Программы)
Вы можете изменить содержание согласно Вашему проекту, удаляя неподходящие
пункты или добавляя новые пункты, специфичные для конкретного проекта.
Концепция представляет собой хранилище для требований типа Feature
(Функциональные особенности). Они перечисляются в пункте «Product Features»
(«Функциональные Особенности Продукта»). Другие пункты обычно заполняются в
свободной форме и не содержат никаких требований.
6.2 Извлечение Функциональных Особенностей из Потребностей
Заинтересованных Лиц
Функциональные особенности извлекаются из запросов заинтересованных лиц. Для
каждой функциональной особенности важно отслеживать, из какого запроса она была
получена. Тогда при хранении запросов заинтересованных лиц в RequisitePro они могут
быть трассированы в реализующие их функциональные особенности.
87
Полученные от заинтересованных лиц требования не обязательно обладают
характеристиками хорошего требования, описанных в пункте 1.4 «Характеристики
Хорошего
Требования»
в
Главе
1
«Управление
Требованиями».
Извлечение
функциональных особенностей из запросов заинтересованных лиц предоставляет Вам
хорошую возможность исправить это. Один из подходов – это пройти по всем требованиям
STRQ и применить соответствующее преобразование для создания одного или более
требований FEAT.
Могут быть применены следующие преобразования:
Copy (Копирование): Если не требуется дополнительных изменений, STRQ может
быть просто скопировано в FEAT без изменений. Наличие требований разного
типа с одинаковым текстом вполне нормально. Тем не менее, лучше избегать
таких одинаковых требований, иначе требования будут многословными.
Split (Разделение): Если требование не элементарное, мы можем разделить его на
два или более требований.
Clarification (Пояснение): Пояснение (или объяснение) может быть применено,
когда оригинальное требование непонятное или двусмысленное.
Qualification
(Уточнение):
Мы
выполняем
уточнение
путем
наложения
ограничений или условий на требования. Это может помочь разрешить
противоречивые требования.
Combination (Комбинирование): Многословные или перекрывающиеся требования
могут быть скомбинированы в одно.
Generalization (Обобщение): Если требование не абстрактно и включает
некоторые ненужные детали, мы можем применить обобщение.
Cancellation (Отмена): Иногда требование нужно удалить. Это может случиться,
когда требование невыполнимое, ненужное или несовместимо с другим
требованием.
Completion (Завершение): Если набор требований не закончен, нам может
понадобиться добавить требования на данную стадию.
Correction (Коррекция): Коррекция может означать как перефразировку
требования, чтобы исправить грамматические ошибки, орфографические и
ошибки пунктуации, так и изменение неверной части требования.
Unification (Унификация): Требования, которые используют недопустимую
терминологию, могут быть приведены к соответствующему виду.
Adding Details (Добавление Деталей): Если требование определено не точно, мы
можем добавить детали. Этот способ часто используется, чтобы сделать все
требования возможными для тестирования.
Глава 5 «Сбор Требований» описывает требования типа запросов заинтересованных
лиц. Проанализируем все запросы заинтересованных лиц, собранные в Главе 5 (одно за
другим) и создадим из них функциональные особенности.
STRQ1
Пользователь должен иметь возможность сравнивать цены на билеты в
других близлежащих аэропортах.
Это требование считается многословным вместе с STRQ11. Они могут быть
скомбинированы в одно требование:
FEAT1
Пользователь должен иметь возможность сравнивать цены на билеты в
других близлежащих аэропортах (для рейсов вылета и прибытия).
STRQ2
Дата должна отображаться в формате дд/мм/гггг.
Это требование не совпадает с STRQ16, которое указывает формат даты мм/дд/гггг.
Требование STRQ2 было получено из Франции, а STRQ16 – из США. Подпункт «Метод
«Мозгового Штурма» (Brainstorming Sessions)» пункта 5.2 «Методы Сбора Требований»
Главы 5 рассматривает, каким образом разрешать такую ситуацию. Требования STRQ2 и
STRQ16 были заменены следующим требованием:
FEAT2
Даты должны отображаться в формате, принятом в настройках веб-браузера.
88
STRQ3
На формах ввода данных система должна показывать, какие поля
являются обязательными для заполнения.
На определенном этапе будет принято решение о том, каким именно образом должны
обозначаться обязательные поля. Это решение может быть принято при создании
требования типа FEAT, либо немного позже, когда из функциональных особенностей
извлекаются дополнительные требования. Предположим, что мы хотим это сделать
сейчас, так что мы добавим пояснение для создания FEAT:
FEAT3 На формах ввода данных система должна показывать, какие поля являются
обязательными для заполнения, с помощью звездочки перед обязательным полем.
STRQ4 Может быть предоставлена возможность отмены покупки билета.
Для большей точности при описании требований лучше использовать стандартные
конструкции. Например, использовать «должна» вместо «может». Использование таких
слов, как «может» вместо «должна», может привести к неправильному пониманию уровня
необходимости требования. (Например, «должна» звучит более убедительно, чем
«может»).
Здесь необходимо пояснение, кто именно будет иметь возможность отменить билет
(пользователь, представитель отдела обслуживания клиентов или администратор), а
также на какой стадии процесса эта операция будет допустима:
FEAT4 Пользователь должен иметь возможность отменить покупку билета в любое
время перед последним подтверждением о покупке.
STRQ5
Пользователь должен иметь возможность отменить заказ машины или
номера в гостинице.
Решение о том, является ли определенное требование элементарным или нет,
зависит от системного аналитика. В этом случае он решил, что возможность отмена брони
машины или номера в гостинице должны быть в одном требовании, поэтому нет
необходимости разделять его:
FEAT5 Пользователь должен иметь возможность отменить заказ машины или номера
в гостинице.
STRQ6
Список рейсов вылета и возвращения должен быть отсортирован по
наименьшему количеству остановок.
Терминология требования не совпадает с STRQ11. Рейсы «прибытия» в данном
требовании названы в STRQ11 «рейсами возвращения». Предположим, что после
консультации со специалистами, мы решили использовать термин «рейсы возвращения».
Тем не менее, мы уже соединили STRQ11 и STRQ1 в FEAT1. Мы должны вернуться обратно
к FEAT1 и соответственным образом изменить его:
FEAT1
Пользователь должен иметь возможность сравнивать цены на билеты в
других близлежащих аэропортах (для рейсов вылета и возвращения).
Т.к. мы изменили FEAT1 соответственно с STRQ6, мы можем переписать STRQ6 в
FEAT6:
FEAT6: Список рейсов вылета и возвращения должен быть отсортирован по
наименьшему количеству остановок.
Однако это противоречит STRQ18, которое указывает, что рейсы должны быть
отсортированы по цене билета. Мы можем объединить эти два требования в одну
функциональную особенность:
FEAT6 Пользователь должен иметь возможность выбирать, сортировать рейсы по
наименьшему количеству остановок или по цене.
89
Как Вы видите, извлечение функциональных особенностей
- это итеративный
процесс, и некоторые требования должны быть изменены по нескольку раз, пока они
станут соответствовать друг другу, и перестанут быть многословными.
STRQ7 Пользователь должен иметь возможность выбрать место в самолете.
Чтобы требование выглядело абсолютно независимым, добавим пояснение:
FEAT7: При покупке билета на самолет пользователь должен иметь возможность
выбрать место в самолете.
STRQ8 Интерфейс системы должен быть на естественном языке.
На первый взгляд с этим требованием все в порядке. Однако после анализа объема
системы и некоторых ограничений стало ясно, что это требование нереально
(невыполнимо). Оно противоречит требованию STRQ27, которое указывает, что система
должна быть разработана в течение трех месяцев. Выполнение интерфейса в
естественном языке заняло бы более чем три месяца. Это требование отменено, а
предоставивший это требование пользователь извещен об отмене.
STRQ9
Система должна показывать всплывающее окно с календарем, когда
пользователь вводит дату.
Это требование перекрывается STRQ21, которое указывает, что календарь должен
появляться при вводе даты рейса. Т.к. STRQ9 более общее (оно имеет в виду любую дату,
включая даты пребывания в гостинице и даты аренды автомобиля), мы перепишем STRQ9
и отменим STRQ21. В качестве пояснения, мы можем привести список всех дат:
FEAT8: Система должна показывать всплывающее окно с календарем, когда
пользователь вводит даты, такие как дата рейса, дата пребывания в гостинице и дата
аренды автомобиля.
STRQ10 Пользователь с помощью флажка должен указывать, нужен ли ему/ей
билет только в один конец, или билет туда и обратно.
Это требование содержит ненужные элементы дизайна. Подобные детали реализации
должны быть оставлены на усмотрение дизайнера. На этой стадии не должно происходить
подобного анализа и детализации:
FEAT9: Пользователь должен иметь возможность указывать, нужен ли ему/ей билет
только в один конец или билет туда и обратно.
STRQ11
Для рейсов вылета и прибытия пользователь должен иметь
возможность сравнивать цены на билеты в других близлежащих
аэропортах.
Это требование было соединено с STRQ1 в FEAT1, и поэтому может быть удалено.
STRQ12
Иногда пользователь будет вводить код аэропорта, который система
будет распознавать. В других случаях пользователь будет вводить
близлежащий город. В этом случае пользователю нет необходимости
знать код аэропорта, поскольку система будет понимать название
города.
Это предложение очень сложное и непонятное. Мы можем заменить его на более
простое:
FEAT10: Система будет идентифицировать аэропорт на основании кода аэропорта,
либо названия города.
STRQ13 Система будет проста в управлении.
Это требование довольно неточное, и оно недостаточно определено для проведения
тестирования. Из него могут быть извлечены две более конкретных функциональных
особенности:
90
FEAT11: Для основной функциональности должны присутствовать отдельные
закладки.
FEAT12: На каждой странице кнопка Next (Далее) должна определять основной
сценарий работы приложения.
STRQ14
Если пользователь прежде уже покупал билет, то он не должен будет
вводить заново информацию, такую как адрес или номер кредитной
карты.
В этом требовании мы добавим пояснение «при следующих операциях»:
FEAT13: Если пользователь прежде уже покупал билет, то при следующих операциях
он не должен будет вводить заново информацию (такую как адрес или номер кредитной
карты).
STRQ15 Должна быть реализована возможность оплаты через PayPal.
Это требование противоречит STRQ41, которое указывает, что оплата через PayPal
не может быть доступна. Т.к. по некоторым причинам этот сервис не может быть
предоставлен, мы должны отменить это требование.
STRQ16 Дата должна отображаться в формате мм/дд/гггг.
Это требование было соединено с требованием STRQ2 в FEAT1.
STRQ17
Список доступных рейсов должен включать такую информацию, как
номер рейса, время отправления и время прибытия для каждого
отрезка пути.
С этим требованием все в порядке, так что мы просто переписываем его:
FEAT14: Список доступных рейсов должен включать такую информацию, как номер
рейса, время отправления и время прибытия для каждого отрезка пути.
STRQ18 Он должен быть отсортирован по ценам.
Слово «Он» относится к предыдущему требованию. Но если порядок требований
изменить, то это требование будет непонятно.
Чтобы стать независимым, требование должно быть перефразировано следующим
образом:
Список доступных рейсов должен быть отсортирован по ценам.
Однако мы уже включили это требование в FEAT6.
STRQ19
Должна быть предоставлена возможность сравнения цен различных
компаний на аренду машин.
Требование корректно. Нам только нужно удалить пассивный залог:
FEAT15: Система должна предоставлять возможность сравнения цен различных
компаний на аренду машин.
STRQ20 Цены на аренду машин должны включать все соответствующие налоги
(включая налог штата - 6%).
Налоги зависят от конкретного штата, поэтому предоставленная цифра в 6%
некорректна. Мы можем вырезать эти слова в скобках, оставив вычисление налогов
дизайнерам:
FEAT16: Цены на аренду машин должны включать все соответствующие налоги.
STRQ21
Для удобства выбора даты рейса в системе должен присутствовать
календарь.
Это требование было включено в FEAT8.
STRQ22
Система должна предоставлять возможность бронировать рейс,
покупать
билет,
бронировать
номер
в
гостинице,
арендовать
91
автомобиль, а также будет предоставлять информацию о туристических
развлечениях.
Это требование представляет собой комбинацию пяти элементарных требований,
которые делают сложным процесс трассировки (установки связей). Это требование будет
разделено на пять элементарных:
FEAT17: Система должна предоставлять возможность бронировать рейс.
FEAT18: Система должна предоставлять возможность покупать билет на самолет.
FEAT19: Система должна предоставлять возможность бронировать номер в гостинице.
FEAT20: Система должна предоставлять возможность арендовать автомобиль.
FEAT21: Система должна предоставлять информацию о туристических развлечениях
в определенных местах пребывания.
STRQ23
Пользователь должен иметь возможность купить билет через веб-сайт
без необходимости звонков по телефону туристическому агенту.
С этим требованием все в порядке, так что мы просто копируем его:
FEAT22: Пользователь должен иметь возможность купить билет через веб-сайт без
необходимости звонков по телефону туристическому агенту.
STRQ24
Система должна следовать инструкциям по разработке, установленных
в сети наших бюро путешествий.
Это требование не совсем ясно до тех пор, пока отсутствует конкретный документ с
инструкциями по реализации. Либо если просто не перечислены все инструкции.
Например:
FEAT23: Система должна использовать архитектуру J2EE.
FEAT24: Если архитектура требует сервер приложения, должен быть использован IMB
WebSphere.
FEAT25: Если система требует базу данных, должен быть использован Oracle.
STRQ25
Страницы, где представители служб сервиса предлагают свои услуги,
должны быть защищены паролем. Представители гостиниц, агенты по
найму автомобилей и представители авиалиний должны иметь свои ID
(идентификаторы) и пароли для доступа к этим страницам.
С этим требованием все в порядке, так что мы просто копируем его:
FEAT26: Страницы, где представители служб сервиса предлагают свои услуги,
должны быть защищены паролем. Представители гостиниц, агенты по найму автомобилей
и представители авиалиний должны иметь свои ID (идентификаторы) и пароли для
доступа к этим страницам.
STRQ26 Система должна быть доступной 24 часа в сутки с уровнем надежности,
соответствующим коммерческим приложениям.
Это требование недостаточно определено для проведения тестирования. На
определенном этапе нам будет нужно заменить его более детальным требованием
относительно надежности. Мы можем сделать это сейчас, в процессе создания
функциональных особенностей, либо мы подождать до создания Дополнительной
Спецификации.
Вполне
нормально
принимать
окончательные
решения
по
нефункциональным требованиям в процессе извлечения дополнительных требований из
функциональных особенностей. На настоящий момент, сохраним требование так, как оно
есть:
FEAT27: Система должна быть доступной 24 часа в сутки с уровнем надежности,
соответствующим коммерческим приложениям.
STRQ27 Система должна быть разработана в течение трех месяцев.
Мы можем добавить пояснение, когда именно начинается отсчет времени:
92
FEAT28: Система должна быть разработана в течение трех месяцев с начала даты,
когда заказчик подпишет документы Сценариев Использования и Дополнительную
Спецификацию.
STRQ28
Пользователи должны выбирать свой ID и предоставлять пароль при
покупке билета.
Мы можем просто скопировать это требование, т.к. оно не требует исправлений:
FEAT29: Пользователи должны выбирать свой ID и предоставлять пароль при
покупке билета.
STRQ29 Функция поиска должна позволять представителю отдела обслуживания
клиентов искать запись, используя следующие критерии: Фамилия,
Пункт Назначения, Дата, и т.д.
«И т.д.» выражает некую неопределенность. После того как источник требования
подтвердил, что не требуется никаких других критериев поиска (кроме перечисленных в
требовании), «и.т.д.» было удалено.
FEAT30: Функция поиска будет должна представителю отдела обслуживания
клиентов искать запись, используя следующие критерии: Фамилия, Пункт Назначения,
Дата.
STRQ30
Представитель отдела обслуживания клиентов должен иметь
возможность вносить изменения в детали брони или отменить заказ.
Т.к. это требование не элементарно, разделим его на два требования:
FEAT31: Представитель отдела обслуживания клиентов должен иметь возможность
вносить изменения в детали брони.
FEAT32: Представитель отдела обслуживания клиентов должен иметь возможность
отменить заказ.
STRQ31
При вводе данных контент-менеджер должен иметь возможность
вводить обычный текст без тегов HTML.
С этим требованием все в порядке, так что мы просто копируем его:
FEAT31: При вводе данных контент-менеджер должен иметь возможность вводить
обычный текст без тегов HTML.
STRQ32 Информация должна храниться в текстовом файле.
Решение того, каким образом информация будет храниться, и затем передаваться
пользователю, должно приниматься дизайнерами или архитекторами системы. Это
требование может быть отменено. Тем не менее, предположение может быть передано
дизайнерам для рассмотрения.
STRQ33
Система должна быть полностью протестирована под только
популярными браузерами.
После доведения до сведения заказчика того, что нереально протестировать систему
под всеми доступными браузерами, заказчик согласился сократить их число до двух:
Internet Explorer и Netscape.
FEAT34: Система должна быть полностью
браузерами: Internet Explorer и Netscape.
протестирована
под
следующими
STRQ34 Система должна отображать схему проезда до аэропорта.
Это требование поступило от разработчика, не являющимся ни заказчиком, ни
пользователем. После согласования с заказчиком было подтверждено, что это требование
не нужно, так что оно было отменено.
93
STRQ35 Функция поиска должна позволять пользователю искать заказ по
следующим критериям: Фамилия, Дата.
Т.к. STRQ35 является частью STRQ29, который был включен в FEAT30, мы можем
отменить STRQ35.
STRQ36 Любая активность на сайте должна записываться в лог.
Мы добавим немного деталей и пояснений:
FEAT35: Все транзакции и ошибки должны
администратора.
быть записаны
и доступны
для
STRQ37 Должны быть доступны различные отчеты.
Это требование не определено до конца. После дополнительных интервью, были
добавлены детали:
FEAT36: Следующие отчеты должны быть доступны администратору:
Список всех билетов на самолет, купленных за данный период времени.
Список всех заказов автомобилей за данный период времени.
Список всех заказов номеров гостиниц за данный период времени.
STRQ38
При бронировании номера в гостинице клиент будет предоставить
следующую информацию: город, даты пребывания, количество
взрослых, количество детей, предпочтения в отношении номеров.
С этим требованием все в порядке, так что мы просто копируем его:
FEAT37: При бронировании номера в гостинице клиент будет предоставить
следующую информацию: город, даты пребывания, количество взрослых, количество
детей, предпочтения в отношении номеров.
STRQ39
При предоставлении информации о гостинице будет отображаться
следующая информация: Адрес, Телефон, Факс, Электронная почта,
Предлагаемые скидки, Доступные способы оплаты, и т.д.
Было удалено «и т.д.»:
FEAT38: При предоставлении информации о гостинице будет отображаться
следующая информация: Адрес, Телефон, Факс, Электронная почта, Предлагаемые
скидки, Доступные способы оплаты.
STRQ40
Пользователю будет предложено заключение соглашения на полет и
гостиницу.
Добавлено небольшое пояснение:
FEAT39: Пользователю будет предложен пакет услуг, состоящий из полета и номера
в гостинице.
STRQ41
Должна приниматься оплата только через кредитные карты. Ни по
чекам, ни через PayPal.
Сделано небольшое перефразирование в целях пояснения:
FEAT40: При оплате билета на самолет должны приниматься только кредитные
карты. Оплата через чеки и PayPal не принимается.
6.3 Атрибуты Функциональных Особенностей
Атрибуты описывают свойства требований. Они помогают структурировать и
анализировать требования в проекте. Мы можем создать правила (на основе атрибутов)
для определения того, какие требования реализовывать на следующей итерации, стадии
или релизе. Например, Вы можете определить, что на стадии Проектирования
(Elaboration) вы хотите реализовать все требования, у которых есть Риск (Risk) и
94
Важность (Importance) с высоким приоритетом. А также все требования, у которых
высокая Важность (Importance) и высокая или средняя Сложность (Difficulty).
Атрибуты могут быть как в виде списка, то есть в виде набора предустановленных
значений, например: High, Medium and Low (Высокий, Средний и Низкий), так и в виде
полей для ввода (текст, дата, цифровое значение).
Функциональные требования имеют следующие установленные по умолчанию
атрибуты:
Priority (Приоритет): обычно используется для определения порядка реализации.
Status (Статус): отслеживает прогресс выполнения требования – Proposed
(Планируемый), Approved (Подтвержденный), Incorporated (Включенный),
Validated (Проверенный).
Difficulty (Сложность): насколько сложна реализация этого требования. Значения
по умолчанию – High (Высокий), Medium (Средний) и Low (Низкий).
Stability (Устойчивость): возможность того, что функциональная особенность не
изменится в течение проекта.
Risk (Риск): возможность возникновения спорных вопросов относительно этого
требования – проблемы с реализацией, пропущенные сроки и т.п.
Planned Iteration (Планируемые Итерации): например, E1 – первая итерация
стадии Проектирования (Elaboration).
Actual Iteration (Фактические Итерации).
Origin (Источник): источник требования.
Contact Name (Имя Контакта):
Enhancement Request (Запрос на Обновление).
Defect (Ошибка).
Author (Автор).
Location (Расположение): место, где находятся документы.
Этот список может варьироваться в зависимости от версии RequisitePro.
Очень часто нам приходится добавлять атрибуты. Ниже приведены несколько
примеров.
Нам может потребоваться атрибут Importance (Важность), т.к. это не совсем одно
и то же, что Priority (Приоритет). Он может помочь в управлении объемом работ в
случае непредвиденных перерывов в работе. Значениями атрибута могут быть: Mandatory
(Обязательный), Desirable (Желательный), Nice to have (Возможный). В экстремальных
ситуациях, многие атрибуты могут хранить эти значения, т.к. Важность относительно
пользователя может отличаться от Важности относительно менеджера проекта.
Помимо Difficulty (Сложности), у нас может быть атрибут Effort (Ресурсы). Он
выражается в человеко-днях и может предоставить детальную оценку времени,
требуемого на разработку этого требования.
Чтобы получить наилучшую оценку стоимости, мы можем добавить атрибут Cost to
implement (Стоимость разработки). Этот атрибут полезен, если имеются различия в
стоимости ресурсов (например, различные стоимости часа работы консультантов,
вовлеченных в проект). Мы можем использовать этот атрибут для вычисления отношения
стоимости к оплате, значения которых мы можем хранить в атрибутах Cost/reward
(Стоимость/Оплата) или Risk/Reward (Риск/Оплата).
Вместо Contact Name (Имя контакта) часто используется атрибут Assigned To
(Исполнитель).
Вместо Planned Iteration (Планируемые Итерации) и Actual Iteration
(Фактические итерации) мы можем использовать Planned completion date
(Планируемая дата завершения) и Actual completion date (Фактическая дата
завершения).
Risk (Риск) может быть разделен на два отдельных атрибута: Risk probability
(Возможность риска - какова возможность возникновения проблем), и Risk impact
(Последствия риска – если проблема возникла, насколько тяжелыми будут
последствия).
Описанные атрибуты может быть использованы не только для функциональных
особенностей, но также для других требований (таких как сценарии использования и
дополнительные требования).
95
Добавление нового атрибута не представляет никаких сложностей, так что Вы не
должны даже сомневаться делать это, если новый атрибут поможет в управлении
требованиями соответствующего типа.
6.4 Создание Документа Концепции (Vision) в RequisitePro
Документ Концепции (Vision) включен в шаблон Use Case (Сценариев
Использования) в каталог Features and Vision (Функциональные Особенности и
Концепция) в окне Explorer (Проводника). Чтобы открыть существующий документ
выполните следующие действия:
1. Откройте папку Features and Vision (Функциональные Особенности и Концепция).
2. Двойным щелчком мышки нажмите на иконке документа Концепции.
Шаблон документа открывается в окне Word.
Если Вы используете шаблон, который не содержит документ Концепции, Вы можете
создать его, выполнив следующие действия:
1. В Explorer (Проводнике) выберите папку, куда Вы хотите поместить документ
Концепции.
2. Выберите File>New>Document (Файл>Новый >Документ). Откроется диалоговое
окно Document Properties (Свойства Документа).
3. Введите имя, описание и название файла документа.
4. Выберите Document Type (Тип Документа) из списка - Vision (Концепция).
5. Нажмите ОК.
Эскиз документа Концепции откроется в Microsoft Word, как показано на Рисунке
6.2.
Рисунок 6.2. Документ Vision (Концепция): начальный шаблон.
Шаблон содержит общие названия, такие как <Company Name> (Название
Компании) или <Project Name> (Название Проекта). Глава 5 описывает, как заменить их
фактическими значениями.
Структура документа представлена на Рисунке 6.1, «Структура Документа Концепции
(Vision)». Заполните соответствующие пункты информацией о проекте. Удалите ненужные
пункты документа. Если необходимо, добавьте новые пункты.
Существует некоторая свобода действий в отношении заполнения пункта Product
Features (Функциональные Особенности Продукта). Здесь допустимо применение
различных подходов:
Описывать требования отдельными, ненумерованными предложениями в пункте
5, Product Features (Функциональные Особенности Продукта), как показано на
Рисунке 6.3.
Нумеровать каждый элемент (5.1,5.2, 5.3 и т.д.).
96
Структурировать требования и группировать их в нумерованные пункты.
Например, 5.1 Основная функциональность, 5.2 Функциональность для
Администратора, … 5.9 Требования к производительности. Мы также можем
сделать более детализированные группы, например 5.1 Заказ билета на самолет,
5.2 Бронирование номера в гостинице, 5.3 Бронирование машины, и т.д.
Рисунок 6.3. Список функциональных особенностей в пункте 5 документа Концепции.
Для простоты в нашем примере мы будем использовать первый подход, но в
реальном проекте я бы рекомендовал группировку и структурирование требований.
6.5 Создание Функциональных Требований (FEAT)
После перечисления требований в пункте Product Features (Функциональные
Особенности Продукта) документа Концепции (Vision) Вы должны сохранить их в базе
данных. Это поможет Вам работать с атрибутами в Матрице Атрибутов (Attribute Matrix) и
отслеживать трассировку (связи) между функциональными особенностями продукта и
требованиями к программному обеспечению.
Чтобы создать функциональное требование выполните следующие действия:
1. Выделите текст, который описывает требование, как показано на Рисунке 6.4.
Выполните одно из следующего:
Правой кнопкой мышки нажмите на тексте и выберите Create Requirement
(Создать Требование).
Выберите RequisitePro>Requirement>Create (Требование>Создать).
Нажмите на иконку New Requirement (Новое Требование)
.
Появится диалоговое окно Requirement Properties (Свойства Требования).
Рисунок 6.4. Выделение требования.
2. Введите название требования. Т.к. требованием по умолчанию в документе
Концепции является FEAT (Feature - Функциональная особенность), то поле Type
(Тип) должно быть уже установлено в FEAT, как показано на Рисунке 6.5.
97
Рисунок 6.5. Диалоговое окно Requirement Properties (Свойства Требования).
3. Нажмите на закладку Attributes (Атрибуты) и установите атрибуты требования
(Вы также можете сделать это позже).
4. Нажмите ОК.
5. Требованию будет назначен тег «FEATpending», как показано на Рисунке 6.6.
Слово «pending» (ожидаемый) будет убрано после сохранения документа.
Рисунок 6.6. Ожидающее (pending) требование.
6. Выберите RequisitePro>Document> Save (Документ>Сохранить).
7. После сохранения тег называется FEAT1, как показано на Рисунке 6.7.
Рисунок 6.7. Сохраненное требование.
8. Повторяйте эти действия для каждого требования, описанного в пункте Product
Features (Функциональные Особенности Продукта) документа Концепции. Когда
Вы закончите, выберите RequisitePro>Document>Save (Документ>Сохранить).
RequisitePro назначает теги с упорядоченными номерами всем создаваемым
требованиям.
После сохранения функциональных особенностей продукта в базе данных, они
становятся доступны из Explorer (Проводника), как показано на Рисунке 6.8.
98
Рисунок 6.8. Функциональные особенности в Explorer (Проводнике).
6.5 Трассировка
Трассировка – это техника, используемая для установки связи между требованиями,
проектированием и реализацией системы. Благодаря трассировке мы можем проследить
путь требования в обоих направлениях (прямом и обратном). Это техника позволяет Вам
проследить источники любого требования. Когда требование изменяется, трассировка
помогает проанализировать последствия этого изменения в отношении остальных
требований.
Пирамида требований была представлена в Главе 1. Чаще всего мы используем
трассировку для отслеживания связи между требованиями соседних уровней:
Из STRQ в FEAT.
Из FEAT в UC.
Из FEAT в SUPL.
Обычно требование становится более детальным при движении вниз по пирамиде
требований. Например:
Запросы Заинтересованных Лиц: Данные должны быть постоянными.
Функциональная особенность: Система должна использовать реляционную базу
данных
Дополнительное Требование: Система должна использовать базу данных Oracle 9i.
Главное назначение трассировки заключается в следующем:
Подтвердить, что реализация соответствует требованиям (вся требуемая
функциональность была реализована и протестирована).
Подтвердить, что приложение делает только то, для чего оно предназначено (вся
реализованная функциональность была запрошена заказчиками).
Помочь в управлении изменениями (анализировать последствия изменения
требований).
99
Структура трассировки (в какие требованиями трассируется определенное
требование) устанавливается в Плане Управления Требованиями (Requirements
Management Plan).
В различных источниках Вы можете встретить различные интерпретации «Trace To»
(«Трассировка В») и «Trace From» («Трассировка Из»). Эти понятия определяют
направления трассировки. Даже два образца проектов RequisitePro (QuarterByte Savings
Bank Example и Learning Project) используют различную терминологию. В RequisitePro
версии 2003 требования «Learning Project – Сценарии Использования» трассируются в
направлении из извлеченных - к исходным. В «Learning Project – Традиционный»,
требования трассируются в направлении из исходных - к извлеченным. Данная книга
полагает, что требования трассируются в направлении из исходных - к извлеченным.
Таким образом, STRQ трассируется в FEAT, FEAT трассируется в UC, а FEAT трассируется в
SUPL, и т.д. Некоторые ранние издания и классы RequisitePro в rational.net используют
другие способы. Извлеченное требование трассируется в исходное – т.е., UC трассируется
в FEAT, а FEAT трассируется в STRQ. Тем не менее, не важно, какой способ Вы хотите
использовать, если он будет неизменным для каждой трассировки на протяжении всего
проекта.
Структура трассировки, описанная в данной книге и используемая в нашем образце
проекта, показана на Рисунке 6.10.
Рисунок 6.9. Структура трассировки, соответствующая пирамиде на Рисунке 1.1.
Рисунок 6.10. Структура трассировки с запросами заинтересованных лиц,
функциональными особенностями и дополнительными требованиями.
В некоторых проектах могут быть дополнительные элементы трассировки –
например, PROB (Problems with existing solution – Проблемы с существующим решением)
трассируются в STRQ, как показано на Рисунке 6.11. Этот подход имеет смысл, только
если дополнительные элементы описывают основные высокоуровневые проблемы, такие
как «Текущая система слишком сложна для обучения», но не определяет ошибки системы.
Если проблема относится к области управления ошибками, она должна храниться в
100
ClearQuest и ссылаться на соответствующее требование в RequisitePro, а не создаваться
непосредственно в самом RequisitePro.
Рисунок 6.11. Структура трассировки с проблемами, запросами заинтересованных лиц,
функциональными особенностями и дополнительными требованиями.
6.7 Представления
RequisitePro представляет визуальное представление трассировки (связей) в виде
двух типов представлений: Traceability Matrix (Матрица Трассировки) и Traceability Tree
(Дерево Трассировки). Матрица Трассировки представляет связи между двумя типами
требований. Дерево Трассировки показывает представление всего проекта.
Матрица Трассировки показывает связи между требованиями одного или разных
типов. Матрица также используется также для создания, просмотра, изменения и
удаления отношений трассировки (связи).
Доступ к Предварительно Созданному Представлению
Некоторые представления уже созданы как часть шаблона, который Вы использовали
при создании проекта. Например, в шаблоне Use Case (Сценариев Использования) есть
предустановленное представление. В зависимости от используемой Вами версии
RequisitePro, оно может располагаться в различных папках. В более старой версии
представление Матрицы Трассировки называлось Features to Stakeholder Requests (Из
Функциональных Особенностей в Запросы Заинтересованных Лиц) в папке Features and
Vision (Функциональные Особенности и Концепция). В версии 2003 она называется
Features Traced to Stakeholder Request» (Функциональные Особенности, Трассируемые в
Запросы Заинтересованных лиц) и располагается в папке Coverage. Чтобы отобразить это
представление на рабочем пространстве View (Области Представлений) выполните
следующие действия:
1. Двойным щелчком мышки нажмите на иконку в Explorer (Проводнике).
Откроется представление. Вам может понадобиться изменить размеры
представления, чтобы увидеть полные наименования требований, как показано
на Рисунке 6.12.
Матрица Трассировки содержит в строках - все Функциональные особенности, в
столбцах - все Запросы Заинтересованных Лиц. Это представление используется для
создания, изменения, просмотра и удаления отношений трассировки (связи).
101
Рисунок 6.12. Матрица Трассировки, показывающая все функциональные особенности и
запросы заинтересованных лиц.
Установка Трассировки
Чтобы установить трассировку (связь) выполните следующие действия:
1. Правой кнопкой мышки нажмите на пересечение строки и столбца.
2. Выберите Traced Frоm (Трассируется Из). (Если Вы используете другую
интерпретацию направления трассировки, выберите Traced To (Трассируется В).
Рисунок 6.13 показывает некоторые связи между STRQ и FEAT.
Рисунок 6.13. Матрица Трассировки, показывающая связь между требованиями.
102
Удаление Трассировки
Чтобы удалить трассировку (связь) выполните следующие действия:
1. Павой кнопкой мышки нажмите на ссылку
2. Выберите Delete Trace (Удалить Связь).
Изменение требований в Представлении
Вы
1.
2.
3.
можете изменять требования из Матрицы представлений:
Павой кнопкой мышки нажмите на требование (либо в строке, либо в столбце).
Выберите Properties (Свойства).
Редактируйте свойства.
Запросы
Вы можете использовать запросы для фильтрации и сортировки информации на
любом представлении. Например, отобразим все требования STRQ, которые не
трассируются ни в одно FEAT:
1. Правой кнопкой мышки нажмите на верхнем левом квадрате представления.
2. Выберите Query Column Requirements (Запрос к Требованиям в Столбце).
3. Выберите атрибут Traced-To (Трассирован В), как показано на Рисунке 6.14.
Рисунок 6.14. Выбор атрибутов для фильтрации.
4. Выберите Not Traced (Не Трассируются) в диалоговом окне Query Requirements
(Запросы к Требованиям), как показано на Рисунке 6.15.
Рисунок 6.15. Выбор тира требований для запроса.
5. Нажмите ОК.
Диалоговое окно Query Column Requirements (Запрос к Требованиям в Столбце)
отображается с одним критерием, как показано на Рисунке 6.16. Вы можете
добавить больше критериев для фильтрации.
103
Рисунок 6.16. Критерии запроса.
6. Нажмите ОК.
Представление показывает только столбцы, которые не имеют идущих от них
связей «trace-to» (трассируются в), как показано на Рисунке 6.17. Эти запросы
заинтересованных лиц нужно пересмотреть, чтобы убедиться, что показываются
только отмененные требования.
Рисунок 6.17. Результат запроса.
Подозрительная Трассировка
Когда требование изменяется, RequisitePro автоматически помечает все относящиеся
к нему связи как подозрительные. Подозрительная связь значит, что соответствующие
требования должны быть проанализированы, т.к. изменение могло их коснуться.
Подозрительные ссылки помечаются красной диагональю в Матрице Трассировки и
Дереве Трассировки:
После пересмотра требований, отмеченные подозрением и внесения необходимых
изменений, Вы можете удалить отметку о подозрительности.
104
Чтобы удалить метку о подозрительности выполните следующие действия:
1. Правой кнопкой мышки нажмите на ячейке.
2. Выберите Clear Suspect (Убрать Подозрение).
Вы также можете вручную пометить связь как подозрительную:
1. Правой кнопкой мышки нажмите на ячейке связи.
2. Выберите Mark Suspect (Установить Подозрение).
Другие Операции над Представлениями
Вы можете копировать представление в другой каталог:
1. Выберите File>Save View As (Файл>Сохранить Представление Как).
2. Измените диалоговое окно View Properties (Свойства Представления). Вы можете
изменить Name (Название), Description (Описание), Package (Папка).
3. Нажмите ОК.
Чтобы удалить представление выполните следующие действия:
1. Правой кнопкой мышки нажмите на представлении в Explorer (Проводнике).
2. Выберите Delete (Удалить).
Чтобы изменить представление, выполните следующие действия:
1. Правой кнопкой мышки нажмите на представлении в Explorer (Проводнике).
2. Выберите Properties (Свойства).
3. Измените имя, и нажмите ОК.
Дерево Трассировки (Traceability Tree)
Дерево Трассировки (Traceability Tree) показывает связи к главным требованиям
(или от главных требований) определенного типа. Матрица Трассировки (Traceability
Matrix) показывает трассировку только между требованиями двух типов, а Дерево
Трассировки отображает все требования в проекте, которые трассируются к требованию
(или трассируются от требования).
Создадим Дерево Трассировки для отображения STRQ и FEAT требований:
1. Выделите каталог, в котором Вы хотите создать представление (может быть
выбран каталог Features and Vision – Функциональные Особенности и Концепция).
2. Выберите File>New>View (Файл>Новое>Представление).
3. В диалоговом окне View Properties (Свойства Представления), как показано на
Рисунке 6.18, введите название и описание представления.
4. Выберите View Type Traceability Tree (Тип Представления Дерева Трассировки) –
Traced into. Существует два типа Дерева Трассировки: Traced into (Трассируется
В) и Traced off (Трассируется Из). Их отличие показано далее в последующих
примерах.
Рисунок 6.18. View Properties (Свойства Представления) Дерева Трассировки (Traceability
Tree).
105
5. Выберите Row Requirement Type (Тип Требования в Строке) – в данном случае,
FEAT.
6. Нажмите ОК. Дерево Трассировки отображается на экране, как показано на
Рисунке 6.19.
Рисунок 6.19. Дерево Трассировки (Traceability Tree) – трассировка в функциональные
особенности (traced to).
В данном примере, Функциональные Особенности находятся на верхнем уровне
дерева, а Запросы Заинтересованных Лиц представляют собой ответвления.
Представление в таком виде имеет смысл, когда в проекте присутствует более чем два
типа требований. Мы рассмотрим это в Главе 8 «Дополнительная Спецификация» и Главе
9 «Создание Тестовых Сценариев (Test Cases) из Сценариев Использования (Use Cases)»,
после того как мы добавим сценарии использования в проект.
Та же информация может быть отображена в другой форме, если Вы выберите View
Type Traceability Tree (Тип Представления Дерева Трассировки) – Traced out off
(Трассируется Из) и Row Requirement Type (Тип Требования в Строке) – STRQ, как
показано на Рисунке 6.20.
Рисунок 6.20. View Properties (Свойства Представления) Дерева Трассировки (Traceability
Tree).
106
Теперь Требования Заинтересованных лиц (STRQ) находятся на вершине дерева, а
Функциональные Особенности представляют собой ответвления дерева, как показано на
Рисунке 6.21.
Рисунок 6.21. Дерево Трассировки (Traceability Tree) – трассировка из запросов
заинтересованных лиц (traced out off).
Выделив требование в Дереве Трассировки, Вы сможете просмотреть свойства
требования. Свойства показываются только в режиме чтения в правой части экрана.
Чтобы изменить свойства, Вам необходимо открыть диалоговое окно Properties (Свойства),
нажав правой кнопкой мышки на требовании и выбрав Properties (Свойства).
Представления трассировки (связей) помогают Вам быстро найти определенную
проблему:
Сценарий Использования (UC) или Дополнительное Требование (SUPL) не
трассируются ни из каких требований (это означает, что Вы реализовали что-то,
что не было запрошено заказчиками).
Функциональная Особенность (FEAT) не трассируется ни в какой UC или SUPL
(это означает, что Вы не реализовали что-то из требуемой заказчиком
функциональности).
Чтобы облегчить этот анализ, Вы должны создать представление, показывающее
соответствующие запросы, например:
Все STRQ не трассируются в FEAT
Все UC не трассируются из FEAT
Все FEAT не трассируются в US или SUPL
Все SUPL не трассируются из FEAT
Все FEAT не трассируются из STRQ
6.4 Заключение
Данная глава обсуждает, каким образом можно извлекать функциональные
особенности из требований заинтересованных лиц и затем представлять их в документе
Концепции (Vision). Описана структура документа. Эта глава также рассмотрела понятие
трассировки (установки связей) и то, как можно представить ее с использованием
RequisitePro.
Ссылки
[RUP04] Rational Unified Process, Version 2003.06.13, IBM, 2003.
107
ГЛАВА 7
Создание
Сценариев Использования
(Use Cases)
Сценарий использования (use case) – это описание системы в терминах
последовательности действий. Он должен иметь значимый результат или определенное
значение для лица, взаимодействующего с системой (actor - действующее лицо).
Некоторые характеристики сценариев использования:
Они инициируются действующим лицом.
Они являются моделью взаимодействий между действующим лицом и системой.
Они описывают последовательность действий.
Они содержат в себе функциональные требования.
Они должны иметь некоторое значение для действующего лица.
Они предоставляют полный, имеющий смысл поток событий.
Назначение сценариев использования
- способствовать соглашению между
разработчиками, заказчиками и пользователями на тему того, что именно система должна
делать.
Сценарий
использования
становится
своего
рода
контрактом
между
разработчиками и заказчиками. Он также является основой для реализации сценариев
использования, которые играют большую роль в проектировании системы. Более того, из
сценариев использования Вы можете получать пользовательскую документацию.
Сценарии использования могут также быть полезны в планировании формального
содержания итераций и позволяют разработчикам системы лучше понять назначение
системы.
При разработке сценариев использования мы также будем определять сценарии
(алгоритмы, scenarios) – особые пути прохождения сценария использования. Из
сценариев использования Вы можете создавать диаграммы последовательностей,
диаграммы связей и диаграммы классов. Они также используются как исходные данные
для тестовых сценариев (test cases).
В показанной на Рисунке 7.1. пирамиде требований сценарии использования
находятся одним уровнем ниже функциональных особенностей, а сценарии (алгоритмы) –
одним уровнем ниже сценариев использования.
Сценарии использования – это хороший способ выражения функциональных
требований системы. Модель сценариев использования содержит все сценарии
использования, действующие лица (кто взаимодействует со сценариями использования), а
также отношения между ними. Модель определяет взаимоотношения системы и
действующих лиц.
108
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 7.1. Сценарии использования в пирамиде требований.
7.1 Определение Действующих Лиц
Действующее лицо (actor) – это некто или нечто, взаимодействующее с системой. Им
может быть как человек, так и другая система. Несколько примеров действующих лиц:
Пользователи системы.
Администраторы.
Управление.
Лица, предоставляющие информацию для системы.
Внешние системы, предоставляющие данные.
Внешние системы, получающие уведомления.
Все заинтересованные лица также являются кандидатами в действующие лица. Глава
5 «Сбор Требований» определяет следующих заинтересованных лиц:
Владелец Бюро Путешествий.
Пользователь 1 (из США).
Пользователь 2 (из Франции).
Разработчик.
Контент-Менеджер.
Представитель Отдела Обслуживания Клиентов.
Администратор.
Представитель Гостиницы, Агент по Найму Автомобиля, Представитель
Авиалиний.
Посмотрим, кто из них может быть действующим лицом:
Владелец Бюро Путешествий (Travel Agency Owner) – может быть действующим
лицом, если он предоставит несколько сценариев использования, специфичных
только для него. Это зависит от того, есть ли у владельца бюро путешествий
особые привилегии, и есть ли некая функциональность, доступная только для
владельца. Если он обладает доступом к той же функциональности, что и
Администратор, то создавать действующего лица для Владельца Бюро
Путешествий нет смысла, т.к. Администратор покрывает его функциональность.
Пользователь 1 и Пользователь 2 могут быть соединены в одного. Так как слово
«пользователь» слишком общее, назовем его Турист (Traveler). Действующее
лицо определяет роль, а не определенное лицо, так что существует только одно
действующее лицо для всех лиц, имеющих одинаковую роль.
Нам также нужна роль с названием Пользователь (User), под которым мы будем
понимать всех лиц, имеющих доступ к системе. С этим действующим лицом будут
связаны такие сценарии использования, как Регистрация или Вход в Систему.
Многие действующие лица унаследуют функциональность от Пользователя.
Разработчик не является действующим лицом, т.к. после создания системы,
разработчики не взаимодействуют с ней.
Контент-Менеджер (Content Manager) - это действующее лицо, отвечающее за
содержание сайта.
109
Представитель Отдела Обслуживания Клиентов (Customer Service Representative CSR) - это действующее лицо, имеющее специальный доступ к системной
информации.
Администратор (Administrator) - это действующее лицо, выполняющее различные
задачи по администрированию системы.
Представитель Гостиницы, Агент по Найму Автомобиля, Представитель Авиалиний
могут рассматриваться как отдельные действующие лица, либо же как одно
действующее лицо под названием Служба Предоставления Услуг (Service
Provider). Это зависит от того, насколько различны их сценарии использования.
Это решение может быть принято позже.
Дополнительным действующим лицом является Airline Reservation System (Система
Бронирования). Она не инициирует никаких сценариев использования, но получает
информацию, генерируемую в процессе оформления заказа билетов.
Некоторые сценарии использования могут быть инициированы не лицом, а по
определенному расписанию (например, batch-программа, запускающаяся раз в сутки в
определенное время). В данном случае мы можем показать на диаграмме действующее
лицо Таймер, инициирующие этот сценарий использования. Вы также можете дать этому
действующему лицу такое название, как Системные Часы (System Clock), Время (Time),
или другое название, которое ясно отражает факт того, что сценарий использования
начнется в определенный момент времени.
7.2 Определение Сценариев Использования
Несколько вопросов, которые могут помочь в определении сценария использования:
Какую функциональность каждой действующее лицо ожидает от системы?
Должны ли действующие лица быть информированы о происходящих в системе
событиях?
Какую информацию действующие лица должны предоставлять системе?
Какую информацию действующие лица должны получать от системы?
О каких событиях, происходящих вне системы, система должна быть уведомлена?
Сценарии использования могут быть определены в течение семинара по
требованиям.
Несколько рекомендаций по созданию сценариев использования:
Каждый сценарий использования должен взаимодействовать, по крайней мере, с
одним действующим лицом.
Каждый сценарий использования должен инициироваться действующим лицом.
Названия сценариев использования должны быть смысловыми. Используйте
Поиск Заказа и Поиск Туриста вместо Поиск 1 и Поиск 2. Никогда не называйте
сценарии использования одинаковыми названиями. Названия должны быть
понятны не только команде разработчиков, но также заказчикам и
пользователям.
Сценарии использования должны описывать функциональность, а не реализацию.
Создание компоненты сессии - не совсем хороший сценарий использования.
Должно быть понятно, кто именно инициирует сценарий использования.
Не забывайте, что сценарии использования не могут быть слишком маленькими или
слишком большими. Например, Предоставление информации по кредитной карте является
некорректным сценарием использования, т.к. он не описывает полный поток событий и не
предоставляет никакого значения для действующего лица. В сценарии использования
Заказ билета - только один шаг. Если у сценария использования только один или два
шага, то возможно, что это некорректный сценарий использования.
Другой пример – Выполнение задач по администрированию. Этот сценарий
использования слишком общий и может быть разделен на несколько сценариев
использования, имеющие более точный смысл, например Генерация отчетов или
Обновление информации пользователя.
В нашем проекте для действующих лиц были определены следующие сценарии
использования:
110
Пользователь
Регистрация
Вход в систему
Агент по Найму Автомобиля
Вход в систему
Предоставление информации
Представитель Авиалиний
Вход в систему
Предоставление информации
Контент-Менеджер
Вход в систему
Предоставление информации
Представитель Гостиницы
Вход в систему
Предоставление информации
Администратор
Регистрация пользователя
Поиск пользователя
Обновление информации пользователя
Вход в систему
Генерация отчетов
Представитель Отдела Обслуживания
Клиентов (CSR)
Вход в систему
Изменение заказа
Удаление заказа
Поиск заказа
Турист
Бронирование рейса
Заказ билета
Бронирование номера в гостинице
Поиск развлечений
Аренда автомобиля
Airline Reservation System не инициирует ни один сценарий использования.
7.3 Диаграммы Сценариев Использования
Диаграммы сценариев использования отображают действующих лиц, сценарии
использования и отношения между ними. Вы можете разработать диаграммы с
использованием IBM Rational Rose, IBM Rational Software Architect, Microsoft Visio и многих
других инструментов.
На показанной на Рисунке 7.2. диаграмме сценариев использования действующие
лица схематично отображаются фигурками человека, а сценарии использования –
овалами. Сплошная стрелка показывает путь связи между действующим лицом и
сценарием использования.
Бронирование
рейса
Турист
Рисунок 7.2. Действующее лицо и сценарий использования.
Диаграммы сценариев использования показывают отношения в виде модели
сценариев использования. Для небольших систем вся модель сценариев использования
может быть представлена в виде одной диаграммы. Для больших систем мы должны
поделить всю систему на несколько диаграмм. Не существует конкретных правил для того,
как именно нужно делить систему.
Несколько вариантов опций, которые могут быть собраны в одну диаграмму:
Все сценарии использования, инициированные одним действующим лицом или
группой действующих лиц.
Сценарии использования, которые обычно выполняются в данном контексте.
Сценарии использования, относящиеся к одному типу задач (например, задачи по
администрированию).
Рисунки 7.3. - 7.5. представляют начальные диаграммы сценариев использования
для проекта Он-лайн Агентства Путешествий.
111
Бронирование номера в
гостинице
Аренда
автомобиля
Заказ билета
Вход в систему
Регистрация
Поиск
развлечений
Бронирование
рейса
Пользователь
Турист
Рисунок 7.3. Сценарии использования, инициированные действующими лицами Турист и
Пользователь.
Изменение заказа
Генерация отчетов
Регистрация
пользователя
Удаление заказа
Поиск
пользователя
Поиск заказа
Администратор
CSR
Обновление информации
пользователя
Рисунок 7.4. Сценарии использования для Представителя Отдела Обслуживания
Клиентов и Администратора.
Предоставление информации
Служба Предоставления Услуг
Контент-Менеджер
Рисунок 7.5. Сценарий использования, инициированный Службой Предоставления Услуг
и Контент-Менеджером.
112
7.4 Структурирование Модели Сценариев Использования
После создания начальной модели сценариев использования мы можем
структурировать ее. Основная цель структурирования модели – это удаление любой
многословности, делающее сценарии использования более легкими для понимания и
изменения. Первым делом мы должны проанализировать сценарии использования и найти
части потоков, содержащие одинаковые шаги. Затем мы можем определить связь между
сценариями использования с помощью отношений трех типов:
Включения (Include).
Расширения (Extend).
Обобщения (Generalization).
Мы можем связать отношениями Обобщения как сценарии использования, так и
действующие лица.
Если два сценария использования всегда выполняются в одной и той же
последовательности, то мы можем их соединить. Например, т.к. сценарий использования
Заказ билета идет после Бронирования рейса, мы решили объединить их.
Если сценарий использования слишком сложный, мы можем его разделить. Один из
способов определения того, когда именно сценарий использования должен быть
разделен, это рассмотрение альтернатив. Когда существует альтернативный путь для
альтернативного пути, как правило, это означает, что сценарий использования становится
слишком сложным. Это знак для того, что сценарий использования является кандидатом
на разделение на два различных сценария использования. Один сценарий использования
будет расширением основного.
Тем не менее, если у сценария использования много шагов, которые всегда
выполняются вместе в одной и той же последовательности, он не должен быть разделен
на два сценария использования.
Отношение Включения (Include Relationship)
Если важная часть потока используется в более чем одном сценарии использования,
то ее можно считать хорошим кандидатом на извлечение в отдельный сценарий
использования, который будет связан с основным отношением включения (include
relationship). Сценарий использования будет содержать основной и включенный сценарии
использования. Включенный сценарий использования должен быть самостоятельным, он
не может содержать информации о том, в какой сценарий использования он включается.
Чтобы показать это отношение на диаграмме сценариев использования, Вы должны
создать зависимость между двумя сценариями использования (используя пунктирную
стрелку) и затем назначить тип включения этой зависимости, как показано на Рисунке
7.6. Направление стрелки – от основного сценария использования к включенному.
Поиск заказа
Изменить заказ
Удалить заказ
Рисунок 7.6. Отношение включения (include relationship) между двумя сценариями
использования.
Отношение Расширения (Extend Relationship)
Если некоторая часть сценария является необязательной или зависит от выполнения
какого-либо условия, то с целью уточнения модели мы можем извлечь ее как отдельный
сценарий использования, связанный отношением расширения (extend relationship). Чтение
113
сценария использования, являющегося расширением основного сценария использования,
не обязательно для понимания назначения основного сценария использования.
Чтобы показать отношение расширения на диаграмме сценариев использования,
создайте зависимость между двумя сценариями использования. Стрелка указывает на
основной сценарий использования, как показано на Рисунке 7.7.
Удалить заказ
Процесс возмещения затрат
Рисунок 7.7. Отношение расширения (extend relationship) между двумя сценариями
использования.
Отношение Обобщения (Generalization Relationship)
Если два или более сценариев использования похожи, мы можем извлечь схожие
элементы в один основной (родительский) сценарий использования. Извлеченные
сценарии использования (дочерние) могут изменить поведение (или добавить новое
поведение)
родительского
сценария
использования.
Родительский
сценарий
использования необязательно должен знать, какие дочерние сценарии использования
являются его специализацией. Но т.к. этот способ может быть трудным в понимании для
заинтересованных лиц, IBM Rational предлагает избегать использования этого типа
отношений.
Рисунок 7.8. показывает, как отношение обобщения (generalization relationship)
представляется на диаграмме сценариев использования.
Предоставление информации
Предоставление
информации по
гостинице
Предоставление
информации по
автомобилю
Предоставление
информации по рейсу
Рисунок 7.8. Отношение обобщения (generalization relationship) между двумя сценариями
использования.
Отношение Обобщения между Действующими Лицами
Обобщение может быть использовано между действующими лицами. Особенно когда
некоторое число действующих лиц инициируют один и тот же сценарий использования.
Рисунок 7.9. показывает, как отношение обобщение между действующими лицами
показывается на диаграмме сценариев использования.
114
Пользователь
Администратор
Турист
CSR
Представитель
Гостиницы
Служба Предоставления Услуг
Агент по Найму
Автомобилей
Контент-Менеджер
Представитель
Авиалиний
Рисунок 7.9. Отношение обобщения (generalization relationship) между действующими
лицами.
7.5 Документ Спецификации Сценариев Использования
Эта книга использует следующий формат документа Спецификации Сценариев
Использования (Use Case Specification):
1. Brief description (Краткое описание)
2. Basic flow (Основной поток)
3. Alternative flows (Альтернативный поток)
3.1 Alternative flow 1 (Альтернативный поток 1)
3.2 Alternative flow 2 (Альтернативный поток 2)
4. Special requirements (Особые требования)
5. Preconditions (Предусловия)
6. Postconditions (Постусловия)
7. Extension points (Точки расширения)
8. Context diagram (Контекстная диаграмма)
9. Activity diagram (Диаграмма активности)
10. State machine diagrams (Диаграмма состояний)
11. Scenarios (Сценарии, Алгоритмы)
Этот шаблон содержит несколько отличий по сравнению с шаблоном сценариев
использования, включенным в RequisitePro:
Основной и Альтернативные потоки разделены в разные пункты, чтобы избежать
трехуровневой нумерации.
Добавлены диаграммы активности, состояний и контекстная диаграмма.
Добавлены Сценарии (Алгоритмы)
Дальнейшие пункты рассматривают все части документа сценариев использования.
115
Краткое описание (Brief Description)
Краткое описание (Brief Description) должен понятно объяснять назначение
документа. Вы также должны указать всех действующих лиц, взаимодействующих с
системой.
Основной Поток (Basic Flow)
Основной поток (Basic flow) содержит наиболее важную последовательность
действий – шагов, определяющих корректное поведение системы. В нашем проекте Онлайн Агентства Путешествий, основной поток сценария использования Бронирование
рейса может выглядеть следующим образом:
В1. Турист вводит URL сайта.
В2. Система отображает домашнюю страницу сайта.
В3. Турист вводит:
Аэропорт вылета, дату, время.
Аэропорт прибытия, дату, время.
Число путешествующих взрослых и детей.
Турист выбирает «Поиск рейсов».
В4. Система отображает рейсы вылета, отсортированные по цене.
В5. Турист выбирает рейс.
В6. Система отображает рейс прибытия.
В7. Турист выбирает рейс прибытия.
В8. Система отображает детали рейса.
В9. Турист подтверждает рейс.
В10. Пользователь предоставляет Идентификатор и Пароль для покупки билета.
В11. Турист предоставляет информацию пассажира.
В12. Система отображает свободные места.
В13. Турист выбирает места.
В14. Турист предоставляет информацию по кредитной карте и расчетный адрес.
В15. Система предоставляет номер подтверждения.
Альтернативный Поток (Alternative Flow)
Альтернативные потоки (Alternative, Alternate flows) представляют собой вариации
потоков, включая наименее вероятные сценарии использования и ошибочное поведение
системы. Следующие вопросы помогут найти альтернативные потоки:
Какие другие действия могут быть выполнены на каждом шаге основного потока?
Какие ошибки могут возникнуть на каждом шаге (неверные данные, пропущенная
информация, проблемы соединения)?
Существует ли такое поведение системы, которое может возникнуть в любое
время (такое как выход, печать, помощь)?
Могут ли условия (такие как определенные комбинации вводимых данных)
существенно изменить поток?
Данная книга использует следующие правила для обозначения потоков
Основной поток (Basic flow): В.
Альтернативный поток (Alternative flows): А1, А2, А3…
Шаги в основном потоке: В1, В2, В3…
Шаги в альтернативном потоке 1: А1.1, А1.2, А1.3…
Шаги в альтернативном потоке 2: А2.1, А2.2, А2.3…
Не существует универсального стандарта для нумерации этих шагов в сценарии
использования. Некоторые используют последовательную нумерацию 1,2,3…, а другие
используют 2.1, 2.2, 2.3… (т.к. они находятся в пункте 2 документа). Некоторые вообще
не используют нумерованные шаги. Но я не рекомендую применять этот подход, т.к.
далее будет трудно ссылаться на конкретные шаги.
Несколько альтернативных потоков для сценария использования Бронирование
рейса:
А1. Сравнение рейсов в близлежащих аэропортах.
А1.1. На шаге В3 Турист выбирает «Сравнить близлежащие аэропорты».
116
А1.2. Система показывает список аэропортов в пределах 100 миль от аэропорта
вылета и прибытия.
А1.3. Турист выбирает, какой аэропорт должен быть рассмотрен.
А1.4. Поток возвращается на шаг В4 основного Потока.
А2. Сортировка рейсов.
А2.1. После шага В4 Турист изменяет порядок сортировки рейсов.
А2.2. Система отображает рейсы, отсортированные по выбранному критерию.
А2.3. Поток возвращается на шаг В5 основного потока.
А3. Сохранение состояния.
А3.1. После шага В8 Турист выбирает сохранение состояния и выходит.
А3.2. Система возвращается на домашнюю страницу.
А3.3. Сценарий использования заканчивается.
А4. Возвращение к выбору рейсов прибытия.
А4.1. После шага В8 Турист возвращается к выбору рейсов прибытия.
А4.2. Поток возвращается на шаг В6 основного потока.
А5. Возвращение к выбору рейсов вылета.
А5.1. После шага В8 Турист возвращается к выбору рейсов вылета.
А5.2. Поток возвращается на шаг В4 основного потока.
А6. Новый пользователь.
А6.1. После шага В9 турист выбирает опцию Новый Пользователь.
А6.2. Система запрашивает информацию пользователя.
А6.3. Турист регистрируется, вводя имя, фамилию, адрес, адрес электронной
почты и пароль.
А6.4. Система подтверждает, что адрес электронной почты уникален и будет
рассматриваться в качестве идентификатора пользователя.
А6.5. Поток возвращается на шаг В11 основного потока.
А7. Новый идентификатор пользователя недействителен.
А7.1. После шага А6.3. альтернативного потока А6 система возвращает
сообщение, что предоставленный адрес электронной почты уже есть в
системе.
А7.2. Турист предоставляет новый адрес электронной почты.
А7.3. Поток возвращается на шаг А6.4. основного потока.
А8. Неверный пароль.
А8.1. После шага В10 основного потока система возвращает сообщение об
ошибке, что пароль неверен.
А8.2. Турист предоставляет корректную комбинацию адреса электронной почты и
пароля.
А8.3. Поток возвращается на шаг В11 основного потока.
Альтернативные потоки должны иметь уникальную последовательность действий.
Они не могут быть различными только в данных. Например, если бы в альтернативном
потоке А1 не было бы дополнительного шага выбора Туристом аэропорта, то он не был бы
хорошим кандидатом на альтернативный поток:
А1. Сравнение рейсов в близлежащих аэропортах.
А1.1. На шаге В3 Турист выбирает «Сравнить близлежащие аэропорты».
А1.2. Система показывает список аэропортов в пределах 100 миль от аэропорта
вылета и прибытия.
А1.4. Поток возвращается на шаг В5 основного потока.
Этот сценарий не должен извлекаться как отдельный альтернативный поток, т.к.
последовательность шагов такая же, как в основном потоке. Разница лишь только в
117
данных. На экране ввода выбирается дополнительная опция, а на экране вывода
отображаются дополнительные рейсы. Однако данный случай должен рассматриваться
как отдельный тестовый сценарий (test case) в процессе извлечения тестовых сценариев
из этого сценария использования - см. Главу 9 «Создание Тестовых Сценариев (Test
Cases) из Сценариев Использования (Use Cases)».
При структурировании модели сценариев использования мы можем сделать два
изменения:
Так как функциональность входа в систему может использоваться в других
сценариях использования, шаг В10 и альтернативный поток А8 могут быть
извлечены в отдельный сценарий использования Вход в систему.
Так как у альтернативного потока (А6) существует свой альтернативный поток
(А7), структура сценария использования становится достаточно сложной. Чтобы
от этого уйти, мы можем извлечь функциональность А6 и А7 в отдельный
сценарий использования Регистрация.
Особые Требования (Special Requirements)
Пункт Особые требования (Special requirements) содержит все требования,
относящиеся к сценарию использования, которые не были покрыты потоком событий.
Обычно это нефункциональные требования. Однако если требование довольно общее и
встречается во многих сценариях использования, оно должно быть описано в
Дополнительной Спецификации.
Предусловия (Preconditions)
Предусловие (Precondition) – это состояние, в котором должна находиться система
перед началом сценария использования. Например, предусловием для сценария
использования Поиск заказа может быть: «Администратор должен выполнить вход в
систему».
Постусловия (Postconditions)
Постусловие (Postcondition) – это состояние, в котором должна находиться система
после окончания сценария использования. Пока постусловие не указано в каждом
конкретном потоке, оно должно быть одинаковым для всех альтернативных потоком, а не
только для основного.
Точки Расширения (Extension Points)
Точка расширения (Extension points) – это место, откуда может быть извлечен
расширенный сценарий использования. Например, сценарий использования Удаление
заказа может иметь следующее расширение:
Название: Процесс возмещения затрат.
Местоположение: После шага В5 основного потока.
Контекстная Диаграмма (Context Diagram)
Показанная на Рисунке 7.10. Контекстная диаграмма (Context diagram) – это часть
диаграммы сценариев использования,
отражающая
отношения этого сценария
использования с действующими лицами и другими сценариями использования. Все
сценарии использования, имеющие отношения включения, расширения или обобщения с
данным сценарием использования, также должны быть показаны на контекстной
диаграмме.
Бронирование рейса
Пользователь
Airline Reservation System
Рисунок 7.10. Контекстная диаграмма (Context diagram) для сценария использования
Бронирование рейса.
118
Контекстная диаграмма и диаграмма активности не являются обязательными, но они
помогают Вам визуально представить сценарий использования и его позицию в проекте.
Ввод URL
Домашняя
страница
Ввод даты
рейса. Поиск.
Отображение
аэропорта
Да
Включая близлежащие
аэропорты?
Нет
Выбор
аэропорта
Отображение
рейсов вылета
Хотите ли Вы
Да
Смена критерия
поиска
изменить критерий?
Нет
Выбор рейса
Отображение
рейсов прибытия
Выбор рейса
прибытия
Отображение
деталей рейса
Хотите ли Вы сохранить
Нет
Да
состояние и выйти?
Да
Сохранить
состояние
Хотите ли Вы изменить
обратный рейс?
Нет
Хотите ли Вы изменить
рейс вылета?
Нет
Подтверждение
Рисунок 7.11. Диаграмма активности (Activity diagram) для сценария использования
Бронирование рейса (см. продолжение ниже).
119
Подтверждение
Да
Вы новый
Регистрация
пользователь?
Нет
Вход в систему
Нет
Пароль
корректный?
Нет
Да
Ввод информации
о пассажире
Идентификатор
Да
действительный?
Вывод свободных
мест
Выбор места
Ввод расчетной
информации
Вывод номера
подтверждения
Рисунок 7.11. Диаграмма активности (Activity diagram) для сценария использования
Бронирование рейса (продолжение).
Диаграмма Активности (Activity Diagram)
Показанная на Рисунке 7.11. Диаграмма активности (Activity diagram) - схожа с
диаграммой потока. Она может быть использована для графического представления
потоков в сценариях использования. Прямоугольники с закругленными краями
изображают состояния активности, стрелки - переходы, а ромбы изображают ответвления
сценариев. Одна диаграмма активности должна содержать основной поток и все
альтернативные потоки. Шаги, не имеющие ответвлений между собой, могут быть
скомбинированы в один.
Хорошей практикой считается представлять основной поток прямой линией, а
альтернативные - в виде исходящих из нее ответвлений или циклов.
Диаграмма активности может быть легко создана с использованием различных
инструментов моделирования, таких как Rational Rose, Rational Software Architect, Rational
Data Architect, Rational Software Modeler.
Диаграмма Состояний(State Machine Diagram)
Иногда нам нужно описать поведение объектов, различное в зависимости от их
состояния. В этом случае мы можем использовать UML2 Диаграммы состояний (State
machine diagram) [AMB04]. В предыдущей версии UML эти диаграммы назывались State
chart diagrams, а в других языках моделирования они называются State – transition
diagrams или просто State diagrams.
120
Диаграммы cсостояний UML2 отображают разные состояния, в которых может
находиться объект, а также переходы между этими состояниями. Например, объект Рейс
может находиться в состоянии Забронирован или Зарезервирован.
Прямоугольники с закругленными краями изображают состояния. Стрелки
переходы из одного состояния в другое, вызванные каким-либо событием. Черные круги
изображают начальное и конечное состояние.
Этот пункт документа сценариев использования не обязателен.
Сценарии (Scenario, Алгоритмы)
Сценарий (Scenario, Алгоритм) – это часть сценария использования. Он описывает
один определенный путь по потоку событий. Важно определить все корректные сценарии
для каждого сценария использования. Они будут использованы для анализа и
проектирования, также как и для извлечения тестовых сценариев (test cases) из
сценариев использования (use cases). Следующий пункт главы описывает, как найти все
сценарии.
7.6 Сценарии (Scenario, Алгоритмы)
Чтобы найти все сценарии (алгоритмы), нужно определить все пути по данному
сценарию
использования.
Рисунок
7.12.
показывает
гипотетический
граф,
представляющий сценарий использования с основным потоком В и альтернативными
потоками А1, А2, А3 и А4. Чтобы найти все алгоритмы, нарисуем все возможные линии
через этот граф.
Рисунок 7.12. Поиск сценариев (алгоритмов) в сценарии использования.
Существует один сценарий для основного потока, один сценарий для каждого
альтернативного потока и один сценарий для каждой комбинации альтернативных
потоков. Получается больше сценариев, чем альтернативных потоков, т.к.: один - А1,
другой - А2, а третий сценарий будет комбинацией этих двух альтернативных потоков.
Простейший способ описать сценарий - это предоставить последовательность
альтернативных потоков. Например:
SC5: A3, A4.
Нам не нужно добавлять В, показывающее основной поток, т.к. почти все сценарии в
любом случае начинаются с основного потока.
Другой способ описания сценария – это перечислить все его шаги, но это более
сложно и содержит ненужные детали:
SC5: В1, В2, A3.1, А3.2, А3.3, A4.1, А4.4, А4.3
121
Что Вы должны делать, если у Вас присутствуют бесконечные циклы (постоянно
возвращающиеся назад)? Теоретически, это будет генерировать бесконечное число
сценариев. Рисунок 7.13. показывает бесконечный цикл.
Рисунок 7.13. Бесконечный цикл.
Разумный подход в данной ситуации – это пройти по основному потоку один раз, а
затем по циклу пару раз. Если система работает для обоих случаев прохождения цикла,
Вы можете полагать, что она будет работать и для многочисленных запусков цикла.
Сценарий использования Бронирование рейса содержит основной поток и восемь
альтернативных потоков, как показано на Рисунке 7.1. Рисунок 7.14. был получен из
показанной на Рисунке 7.11. диаграммы активности. Пять альтернативных потоков
возвращаются назад, а другие три идут дальше. Если Вы хотели описать все возможные
комбинации альтернативных потоков, Вы бы получили несколько тысяч сценариев.
Очевидно, что Вам не нужно составлять все их комбинации.
Таблица 7.1. Потоки в Сценарии Использования Бронирование Рейса.
ID Потока
В
А1
А2
А3
А4
А5
А6
А7
А8
Название
Основной поток
Сравнение рейсов в близлежащих аэропортах
Сортировка рейсов
Сохранение состояния
Возвращение к выбору рейсов прибытия
Возвращение к выбору рейсов вылета
Новый пользователь
Новый идентификатор пользователя недействителен
Неверный пароль
Рисунок 7.14. Диаграмма, показывающая основной поток и альтернативные потоки.
122
Выберите самый рациональный набор сценариев из подмножества девяти тысячи
сценариев. Обычно лучше всего выбрать основной поток, один сценарий, покрывающий
каждый альтернативный поток, и несколько комбинаций альтернативных потоков.
Используя потоки из Таблицы 7.1., возможно, нет смысла добавлять сценарий,
содержащий оба потока А1 и А8. На диаграмме они расположены настолько далеко, что
никак не влияют друг на друга. Но это имеет смысл для А1 и А2, т.к. они выполняются
сразу один за другим, и поэтому могут быть соединены.
Таблица 7.2. показывает выбранные сценарии: один представляет основной поток,
восемь представляют каждый альтернативный поток, а 13 относятся к некоторым
комбинациям потоков.
Таблица 7.2. Сценарии, Выбранные для Тестирования в Сценарии Использования
Бронирование рейса.
Номер
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
1
2
3
4
5
6
7
8
9
10
11
Последовательность
Потоков
В
А1
А2
А3
А4
А5
А6
А6, А7
А8
А1, А2
А1, А5
Сценарий 12
А1, А4
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
Сценарий
А2,
А4,
А4,
А5,
А5,
А4,
А5,
А5,
А6,
А8,
13
14
15
16
17
18
19
20
21
22
А2
А3
А5
А4
А3
А4
А5,А4
А5,А3
А7,А7
А8
Описание
Близлежащие аэропорты
Сортировка
Сохранение и выход
Возвращение к выбору рейсов прибытия
Возвращение к выбору рейсов вылета
Новый пользователь
Новый идентификатор пользователя недействителен
Неверный пароль
Близлежащие аэропорты, затем сортировка
Возвращение к выбору рейсов вылета с близлежащими
аэропортами
Возвращение к рейсам прибытия с близлежащими
аэропортами
Двойное изменение порядка сортировки
Возвращение к рейсам прибытия, затем сохранить
Возвращение к рейсам прибытия, затем вернуться в начало
Изменить рейс вылета, затем изменить рейс прибытия
Изменить рейс вылета, затем сохранить
Дважды изменить рейс прибытия
Дважды изменить рейс вылета, один раз – рейс прибытия
Дважды изменить рейс вылета, затем сохранить
Двойной ввод недопустимого идентификатора
Двойной ввод недопустимого пароля
7.7 Сценарии Использования (Use Cases) в RequisitePro.
Документ Спецификации Сценариев Использования (Use Case Specification) создается
из шаблона, содержащего рассмотренные в предыдущее главе пункты. Если у Вас нет
доступа к RequisitePro, Вы можете создать этот документ в Microsoft Word. Однако
использование RequisitePro предлагает Вам больше функциональности, такой как
создание требований типа сценариев использования, установка трассировки (связи) и
генерация соответствующих отчетов.
Вам не нужно заканчивать весь документ за один раз. Создание сценариев
использования – это итеративный процесс. Как только сценарий использования
определен, Вы можете создавать соответствующий документ с кратким описанием его
назначения. На следующей итерации Вы можете добавить содержание, затем все шаги и в
конце – детальное описание каждого шага. Детальный анализ всех стадий жизненного
цикла сценариев использования представлен в книге Use Case Modeling, авторами которой
являются Kurt Bittner и Ian Spence [BIT02].
123
Создание Спецификации Сценариев использования (Use Case
Specification)
Для создания документа Спецификации Сценариев Использования (Use Case
Specification) в RequisitePro, Вы должны выполнить действия, аналогичные действиям при
создании документа Требований Заинтересованных Лиц (Stakeholder Request) и
Концепции (Vision).
1. В Explorer (Проводнике), выберите папку Use Cases.
2. Выберите File> New>Document (Файл>Новый>Документ).
3. Заполните поля в диалоговом окне Document Properties (Свойства Документа),
как показано на Рисунке 7.15. Нажмите ОК.
Эскиз документа откроется в Microsoft Word.
Рисунок 7.15. Диалоговое окно Document Properties (Свойства Документа) для сценария
использования Бронирование рейса.
4. Заполните все пункты документа, как было рассмотрено в пункте 7.5.
Для визуального представления некоторых шагов в документ можно включить
экранные формы прототипа. Тем не менее, назначение этих экранных форм – не дизайн
пользовательского интерфейса, а пояснение того, какие объекты взаимодействуют с
действующим лицом. Экранная форма также может показывать примерные значения для
ввода.
Один из наиболее быстрых способов создания таких экранных форм – использование
Microsoft Excel для создания таблиц, а затем копирование и вставка в документ сценариев
использования, как показано на Рисунке 7.16.
Рисунок 7.16. Прототип экранной формы.
124
Более наглядные и сложные прототипы экранных форм могут быть созданы с
использованием Visio, Microsoft PowerPoint, Visual Basic и многих других инструментов.
Для облегчения обновления Вы можете отделить прототипы экранных форм от
потока сценариев использования. В этом случае Вам лучше создать отдельный пункт в
документе (например, Экранная Форма - Prototype Screen) и сделать ссылки из шагов
сценариев использования на соответствующий пункт документа.
Создание Требований
Перед созданием требований в RequisitePro Вы должны решить, что будет пониматься
под одним требованием:
Целый сценарий использования.
Каждый альтернативный поток.
Группа соответствующих шагов.
Каждый шаг.
Это решение зависит от уровня желаемой Вами детализации в трассировке
(установки связи). Единственным преимуществом сохранения целых сценариев
использования является ограничение затрат в целом, но такой подход может быть не
совсем хорошим для отслеживания корректного назначения всех заданий. Сохранение
каждого шага в качестве отдельного требования обеспечит хорошую трассировку (связь),
но это требует огромных затрат и может затмить основную функциональность и многие
детали. Наиболее лучшим подходом является хранение основного и альтернативных
потоков в качестве отдельных элементарных требований. Тем не менее, это решение
может меняться для разных проектов.
Процесс создания требований сценария использования – тот же, который был
использован нами для требований STRQ и FEAT.
1. Выделите название сценария использования.
2. Правой кнопкой мышки нажмите на названии и выберите New Requirement (Новое
Требование), или выберите RequisitePro>Requirement>New (Требование>Новое),
или нажмите на иконку New Requirement (Новое Требование).
Появится диалоговое окно Requirement Properties (Свойства Требования). На
закладке General (Общее) Вам не нужно ничего вводить. Тип показывается по
умолчанию: «UC: Use Case». Вам не нужно вводить Name (Название), т.к. для
определения требования может использоваться Text (Текст).
3. Нажмите ОК на диалоговом окне Requirement Properties (Свойства Требования).
Вместо выделения названия сценария использования Вы можете включить в
требование весь поток. Это позволит автоматическое отслеживание изменений, если ктото добавит, удалит или изменит любой шаг. Любые изменения будут отображены в
подозрительных связях. Для требования Вы можете использовать заголовок в качестве
имени, а поток в качестве описания. Если Вы будете использовать заголовок в качестве
требования, тогда при изменении описания потока Вам понадобится вручную обозначать
связи как подозрительные.
RequisitePro предоставляет возможность установки иерархии требований. Это очень
удобно, особенно при структурировании требований сценариев использования. Вы можете
определить каждый сценарий использования как родительский и присоединить все
альтернативные потоки как дочерние требования. Для создания дочернего требования
выполните следующие действия:
1. Выделите название альтернативного потока, как показано на Рисунке 7.17.
2. Правой кнопкой мышки нажмите на названии и выберите New Requirement (Новое
Требование), или выберите RequisitePro>Requirement>New (Требование>Новое),
или нажмите на иконку New Requirement (Новое Требование).
Появится диалоговое окно Requirement Properties (Свойства Требования).
125
Рисунок 7.17. Выделение текста требования.
3. Выберите закладку Hierarchy (Иехархия).
4. В списке Parent (Родительский), выберите «choose parent» («выбрать
родительский»).
Появится диалоговое окно Parent Requirement Browser (Обзор Родительского
Требования), как показано на Рисунке 7.18.
5. Выберите родительское требование.
Рисунок 7.18. Выбор названия сценария использования в диалоговом окне Parent
Requirement Browser (Обзор Родительского Требования).
6. Нажмите ОК в диалоговом окне Parent Requirement Browser (Обзор Родительского
Требования).
7. Нажмите ОК в диалоговом окне Requirement Properties (Свойства Требования),
как показано на Рисунке 7.19.
Рисунок 7.19. Закладка Hierarchy (Иерархия) в диалоговом окне Requirement Properties
(Свойства Требования).
126
После сохранения документа, RequisitePro назначает уникальный номер требованию.
В случае дочернего требования номер состоит из номера родительского требования, точки
и номера дочернего требования, как показано на Рисунке 7.20. Иерархия требований
может быть просмотрена из Explorer (Проводника), как показано на Рисунке 7.21.
Рисунок 7.20. Нумерация дочерних требований.
Рисунок 7.21. Иерархия сценариев использования в Explorer (Проводнике).
7.8 Создание Нового Типа Требований в RequisitePro.
В зависимости от того, насколько точно Вы хотите отслеживать трассировку (связь) в
RequisitePro, Вы можете ввести все сценарии (алгоритмы) в систему, либо установить
трассировку прямо из сценариев использования в тестовые сценарии. Преимущество
ввода сценариев
- это предоставление более детальной трассировки. Недостатком
является то, что это создает лишние расходы. Данный пункт использует подход ввода
всех сценариев.
Сценарий не является стандартным типом требований в RequisitePro, так что Вам
необходимо добавить его как новый тип требований, выполняя следующие действия:
1. В Explorer (Проводнике), правой кнопкой мышки нажмите на проекте и выберите
Properties (Свойства).
2. Выберите закладку Requirements Type (Тип Требований).
3. Нажмите Add (Добавить).
4. Заполните соответствующие поля, как показано на Рисунке 7.22:
Name (Название): Scenario.
Requirement Tag Prefix (Префикс Требования): Может быть любым, но лучше если
со смыслом, например SC.
Requirement Color (Цвет Требования): Оставьте по умолчанию Синий (Blue) или
выберите другой.
Requirement Style (Стиль Требований): Оставьте по умолчанию Двойное
Подчеркивание (Double Underline) или выберите другой.
127
Рисунок 7.22. Добавление типа требований Scenario (Сценарий).
5. Нажмите ОК. Сценарий появится на закладке Requirements (Требования), как
показано на Рисунке 7.23.
Рисунок 7.23. Тип требований Scenario (Сценарий), добавленный в список типов
требований.
7.9 Заключение
Сценарии использования играют важную роль в процессе разработки программного
обеспечения. Они:
Помогают пользователям и системным аналитикам прийти к соглашению по
поводу функциональности системы.
Могут использоваться в качестве контракта между заказчиком и группой
разработчиков.
Являются основой для проектирования системы, создания документации и
тестовых сценариев.
Первый шаг моделирования сценария использования – определение действующих
лиц и сценариев использования, а также представление их на диаграмме сценариев
использования.
Чтобы избежать многословности в модели сценариев использования, Вы можете
извлекать некоторые сценарии использования и устанавливать одно из трех отношений:
включения, расширения и обобщения. Тем не менее, Вам следует быть осторожным, чтобы
не создать ненужных отношений, которые будут только усложнять модель. Если Вы
можете выразить функциональность с использованием только не избыточных
альтернативных сценариев, становится ненужным извлечение сценариев использования и
установление отношений между ними. Особенно Вы должны избегать длинных цепочек
отношений включения и расширения.
128
Сценарий
использования
описан
в
документе
Спецификация
Сценариев
Использования (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.
129
ГЛАВА 8
Дополнительная
Спецификация
Дополнительная
Спецификация
(Supplementary
Specification)
содержит
все
требования, которые не могут быть отражены в сценариях использования (use cases). Это
не значит, что все функциональные требования отображены только в сценариях
использования, и что все нефункциональные требования находятся только в
Дополнительной Спецификации. Спецификация Сценариев Использования (Use Case
Specification) также содержит нефункциональные требования, если они применяются к
только одному сценарию использования. Дополнительная Спецификация содержит все
основные функциональные требования, которые не связаны с определенным сценарием
использования. Таблица 8.1. показывает, какой тип требований можно найти в
определенном документе.
Таблица 8.1. Распределение Требований Между Спецификации Сценариев
Использования и Дополнительной Спецификацией.
Тип Требования
Спецификация Сценариев
Дополнительная
Использования
Спецификация
Функциональные
Основной поток и альтернативные
потоки, относящиеся к определенному
сценарию использования.
Функциональные требования,
относящиеся к более, чем одному
сценарию использования.
Нефункциональные
Нефункциональная спецификация,
относящаяся к только одному
сценарию использования.
Нефункциональные требования,
относящиеся ко многим сценариям
использования.
Общее впечатление таково, что все функциональные требования находятся только в
Спецификации
Сценариев
Использования,
а
нефункциональные
–
только
в
Дополнительной Спецификации. Так кажется потому, что:
Нефункциональные требования обычно применяются в целом к системе, а не к
определенному
сценарию
использования
(поэтому
они
находятся
в
Дополнительной Спецификации).
Функциональные требования чаще всего относятся к определенному потоку
событий (поэтому они находятся в Спецификации Сценариев Использования).
Дополнительные требования также называют архитектурными требованиями [EEL01]
или факторами качества [LAU02]. Эти понятия нельзя назвать полными синонимами
дополнительным требованиям, но в контексте процесса разработке программного
обеспечения они означают почти тоже самое.
Недавно в Rational Unified Process (RUP) название артефакта было изменено с
«Дополнительной Спецификации» на «Дополнительные Спецификации» (в множественное
числе) для отображения того факта, что мы можем использовать более чем один документ
для хранения дополнительных требований.
130
В пирамиде требований дополнительные требования располагаются на том же
уровне, что и сценарии использования, как показано на Рисунке 8.1.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 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].
131
Таблица 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 (Функциональные Требования).
132
Приобретенные Компоненты могут быть описаны в Implementation Constraints
(Ограничения на Реализацию).
Требование по Лицензиям могут быть скомбинированы с требованиями на
Юридические Нормы и Авторское Право.
Допустимые Стандарты могут быть описаны в Implementation Constraints
(Ограничения на Реализацию) или в пункте Соответствие Техническим Условиям.
Шаблон RUP не выделяет требования Реализации и Аппаратного Обеспечения в
отдельные пункты, т.к. они могут быть описаны в пункте Design Constraints (Ограничения
на Дизайн).
Предложенная в данной главе классификация – это попытка охватить многие типы
требований (собранные из различных классификаций) и представить их соответственно с
помощью структуры FURPS+ (см. Таблицу 8.4). Эта классификация включает пять
категорий, охватываемых FURPS, четыре категории, охватываемые «+», и две категории
из шаблона RUP.
Таблица 8.4. Категории Дополнительных Требований.
Категория
Функциональность
Подкатегория
Удобство использования
Доступность
Эстетичность
Соответствие интерфейсу пользователя
Эргономичность
Легкость в использовании
Надежность
Работоспособность
Прочность
Точность
Восстанавливаемость
Отказоустойчивость
Безопасность
Защита
Корректность
Производительность
Скорость обработки информации
Время ответа
Время восстановления
Время загрузки/выхода
Емкость
Использование ресурсов
Способность к сопровождению
Тестируемость
Приспособляемость
Способность к настройке
Совместимость
Способность к настройке конфигурации
Способность к обновлению
Способность к установке
Расширяемость
Портативность
Возможность многократного применения
Взаимодействие
Соответствие техническим условиям
Взаимозаменяемость
Изменяемость
Способность к анализу
Способность к аудиту
Способность к локализации
Ограничение на дизайн
133
Требования
Требования
Требования
Требования
Требования
реализации
интерфейса
аппаратного обеспечения
документации
лицензий и юридических норм
Далее пункты описывают каждую категорию. Ни одна
обязательной. Многие из них могут быть пропущены, если они не
случае. Тем не менее, требование должно исключаться
запланированного решения заказчика и системного аналитика,
важность не была проанализирована.
из них не является
подходят в конкретном
только в результате
а не потому что его
Функциональность
Этот пункт содержит функциональные требования, которые не были отображены ни
в одном сценарии использования. Он обычно включает некоторые общие функции,
доступные во многих частях системы. Например: печать, он-лайн справочник, отчеты.
Пример: Он-лайн справочник должен быть доступен из меню на каждой странице.
Тем не менее, если функциональность более сложная и не может быть выражена в
паре предложений, нам может понадобиться создание дополнительного сценария
использования для ее описания.
Удобство Использования
Понятие удобства использования многогранно. Этот пункт определяет требования по
удобству использования в нескольких областях:
Доступность
Легкость доступа к системе и использования особой функциональности.
Пример: Функциональность бронирования билета на самолет должна быть
доступна с домашней страницы.
Пример: Функциональность бронирования автомобиля должна быть доступна
после не более чем одного щелчка с домашней страницы.
Эстетичность
Соответствие интерфейсу пользователя
Эстетичность пользовательского интерфейса.
Пример: Поля ввода на одной странице должны быть выровнены вертикально.
Соответствие пользовательскому интерфейсу.
Пример: Пользовательский интерфейс должен соответствовать стандарту IBM
CUA. [CUA91a] [CUA91b]
Чтобы избежать неясности при упоминании стандартов, лучше предоставить
ссылку на источник с описанием стандарта.
Эргономичность
Легкость в использовании
Эргономические аспекты пользовательского интерфейса (избегание ненужных
действий, неудобных перемещений мышкой и т.д.).
Пример: При открытии диалогового окна акцент должен быть на первом поле
ввода.
Легкость в обучении и использовании системы.
Пример: Для использования системы пользователи не должны обладать
специальными техническими навыками (кроме умения пользоваться браузером).
Пример: Представитель службы услуг должен иметь возможность изучать систему
он-лайн.
Пример: Среднее время процедуры бронирования номера в гостинице должно
быть не более десяти минут.
134
Надежность
Этот пункт охватывает различные аспекты надежности системы:
Работоспособность
Время доступности системы в процентах (среднее время между ошибочными
состояниями).
Пример: Среднее время между отказами должно быть, по крайней мере, 30 дней.
Пример: Система должна быть доступна 99.93% времени.
Прочность
Точность
Восстанавливаемость
Отказоустойчивость
Безопасность
Защита
Корректность
Способность системы противостоять внешним нарушениям, например неверный
ввод данных или нехватка ресурсов.
Пример: Для каждого неверного ввода пользователем система должна отображать
соответствующее сообщение об ошибке объясняющее, какого формата должны
быть вводимые данные.
Точность, с которой система рассчитывает значения.
Пример: Денежные расчеты должны выполняться и храниться с точностью до
двух десятых.
Насколько
искусно
система
восстанавливается
из
состояния
неработоспособности. В этом пункте мы заботимся об искусстве восстановления и
отсутствии последствий, в то время как время восстановления описывается в
пункте Производительность. Тем не менее, можно скомбинировать эти два
аспекта в одном месте.
Чувствительность модулей системы к отказам в работе.
Любая опасность по отношению к пользователям, данным, системным
компонентам или системам, представленные в процессе использования системы.
Уровень защиты относительно доступа к определенным модулям системы.
Насколько правильно система должна работать (без ошибок).
Пример: При выводе списка рейсов система не должна пропускать прямые рейсы
или рейсы с одной остановкой.
Пример: После выпуска релиза система не должна иметь критических и важных
ошибок, допускается не более чем 20 незначительных ошибок.
В идеале система не должна иметь ошибок совсем. Однако эта цель практически
всегда нереальна для достижения в рамках устанавливаемых временных
ограничений.
Производительность
Этот пункт охватывает различные указания к системной производительности.
Скорость обработки информации
Время, за которое система выполняет задачи. Оно может быть выражено,
например, в количестве транзакций в минуту.
Пример: Система должна обрабатывать 1000 процедур бронирования билетов в
минуту.
Время ответа
Насколько быстро система отвечает на запросы.
Пример: Среднее время ответа системы должно быть менее двух секунд.
135
Пример: Среднее время отображения списка полетов должно быть не более
десяти секунд.
Второе требование относится к определенному запросу, когда пользователь
осуществляет поиск соответствующих рейсов в сценарии использования
Бронирование рейса. В этой ситуации лучше всего включить его в пункт Special
Requirements
(Специальные
Требования)
в
Спецификации
Сценариев
Использования (Use Case Specification). Требования этого пункта более
приоритетны, чем основные требования Дополнительной Спецификации.
Время восстановления
Время загрузки/выхода
Емкость
Использование ресурсов
Насколько быстро система восстанавливается из состояния неработоспособности.
Важно различать между времени, когда система становится рабочей с точки
зрения пользователя (обычно потому что резервная система позволяет
выполнение различных операций), и времени, когда проблема будет фактически
исправлена.
Хотя
переключение
на
резервную
систему
выполняется
автоматически, исправление изначальной проблемы достаточно часто требует
вмешательства человека.
Пример: В случае отказа системы резервная система должна позволять
выполнение операций в течение 30-ти секунд.
Пример: Среднее время восстановления должно быть менее часа.
Продолжительность по времени загрузки системы и ее выключения.
Пример: Система должна быть работоспособной в течение одной минуты после
загрузки.
Количество пользователей, которое система может обслуживать.
Пример: Система должна обслуживать 5000 пользователей одновременно.
Использование памяти, дискового пространства, базы данных и т.д.
Пример: Система должна хранить в базе данных не более чем один миллион
транзакций. Если база данных превысила лимит, старые транзакции должны быть
отправлены в резервное хранилище и затем удалены из операционной базы
данных.
Эти требования могут быть также описаны в Implementation Requirements
(Требования Реализации).
Способность к Сопровождению
Способность к сопровождению касается многочисленных аспектов сопровождения и
обновления системы.
Тестируемость
Насколько легко тестировать систему. Требуется ли интеграция с каким-либо
инструментом для тестирования?
Пример: Пользовательский интерфейс не должен содержать компонентов,
препятствующих автоматическому тестированию с использованием IBM Rational
Functional Tester.
Приспособляемость
Способность к настройке
Насколько легко система адаптируется к новой программной среде.
Пример: Время развертывания на новой версии WebSphere Application Server
должно занимать не более чем один день.
Насколько легко находить и исправлять ошибки.
Пример: Лог ошибок, содержащий информацию обо всех критических ошибках,
должен быть доступен системному администратору через Интернет, чтобы он мог
проверить его удаленно в любое время.
136
Совместимость
Способность к настройке конфигурации
Способность к обновлению
Степень совместимости системы с предыдущими версиями системы, с заменяемой
системой и с интерфейсами.
Пример: После выхода системы последующие версии системы должны быть
совместимы сверху вниз. Все введенные в предыдущей версии транзакции
должны быть доступны в новой версии.
Степень конфигурирования системы после ее установки.
конфигурироваться?
Какие функции могут
Насколько легко расширить систему новыми функциональными особенностями.
Пример: Не должна требоваться установка на клиентском рабочем месте. Все
системные обновления и новые релизы должны осуществляться на сервере.
Под способностью к настройке конфигурации и обновлению иногда понимают
гибкость.
Способность к установке
Легкая установка системы.
Пример: Установка новой версии системы
установки на рабочем месте пользователя.
Расширяемость
Портативность
Возможность многократного применения
Взаимодействие
Соответствие техническим условиям
Взаимозаменяемость
не
должно
требовать
никакой
Насколько легко система расширяет объемы данных или пользователей.
Какое количество пользователей система должна поддерживать со временем
Пример: После шести месяцев работы, система должна иметь возможность
обслуживать дополнительно 5000 пользователей.
Насколько легко перемещать систему на другое программное обеспечение или
платформу.
Пример: Смена базы данных системы в будущем не должно требовать перезаписи
логики приложения.
Насколько легко использовать части системы в других системах.
Пример: Главная функциональность системы (бронирование рейса, покупка
билета на самолет, бронирование номера в гостинице, бронирование автомобиля)
должна быть отражена в компонентах, которые могут быть использованы в
приложении клиент/сервер (не через Интернет).
Насколько легко взаимодействовать с другими системами.
Взаимодействие
- это возможность программ, систем или бизнес-процессов
работать вместе для выполнения общей задачи.
Пример: Система должна автоматически бронировать билет с Airline Reservation
System без необходимости вмешательства человека.
Насколько хорошо система удовлетворяет всем стандартам и правилам.
Пример: Процесс сбора персональной информации у пользователя, покупающего
билет на самолет, должен соответствовать PatriotAct.
Насколько легко заменять компоненты системы.
137
Изменяемость
Способность к анализу
Способность к аудиту
Способность к локализации
Насколько легко изменять функциональность системы.
Насколько легко анализировать систему.
Насколько легко операции системы подвергаются аудиту.
Какие языки поддерживает система. Насколько легко расширить систему новыми
языками.
Пример: Приложение должно поддерживать Английский, Французский и
Испанский языки.
Ограничения на Дизайн
Требования, относящиеся к системному дизайну и архитектуре.
Пример: Система должна быть основана на архитектуре J2EE.
Требования Реализации
Примеры требований реализации:
Язык программирования, используемый для разработки системы.
Управление системами и их версиями.
Используемая база данных.
Сторонние компоненты.
Ограничения на ресурсы: память, дисковое пространство.
Стандарты кодирования.
Требования Интерфейса
Этот пункт описывает различные интерфейсы:
Пользовательский интерфейс.
Интерфейс аппаратного обеспечения.
Интерфейс программного обеспечения.
Интерфейс коммуникаций.
Требования Аппаратного Обеспечения
Требования Аппаратного Обеспечения обычно относятся только к оборудованию, на
котором разворачивается система. Здесь можно указать, например, форму, размер или вес
устройства. Это не относится к веб-приложениям.
Требования Документации
Требования к документации могут содержать:
Распечатанная документация.
Документация, доступная на СD.
Документация, доступная он-лайн.
Он-лайн справочник.
Пример: Руководство Администратора должно быть доступно в формате PDF.
Требования к он-лайн документации иногда описываются в пункте Functionality
(Функциональность) Дополнительной Спецификации (Supplementary Specification).
Требования Лицензий и Юридических Норм
Этот пункт содержит юридические нормы, правила и требования лицензий.
Пример: На страницах, где приводятся данные пользователя, должна быть ссылка
на страницу с политикой конфиденциальности.
138
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 и выше).
139
Следующее требование – это требование надежности/работоспособности:
FEAT27: Система должна быть доступной 24 часа в сутки с уровнем надежности,
соответствующим коммерческим приложениям.
Так как оно слишком общее, при преобразовании его в дополнительные требования
мы можем разделить его на более точные утверждения:
SUPL: Система должна быть доступна 24 часа в сутки 7 дней в неделю.
SUPL: Среднее время между состояниями неработоспособности должно быть по
крайней мере 20 часов.
SUPL: Система может быть недоступна не более чем одну минуту за 24 часа.
SUPL: Система должна быть доступна 99.93% времени.
Последние два требования эквивалентны. Они выражают одно и то же требование
различными словами. Достаточно включить только одно из них.
Следующее требование – это требование способности к сопровождению/способности
к настройке, но оно также может рассматриваться как требования удобства
использования:
FEAT35: Все транзакции и ошибки должны быть записаны и доступны для
администратора.
Так как лог ошибок и лог транзакций будут реализованы в отдельности друг от
друга, в целях трассировки (установки связей) лучше всего разделить это требование на
два:
SUPL: Все системные ошибки должны быть записаны и быть доступными для
администратора.
SUPL: Все транзакции (покупка билета, выполнение заказа, изменение деталей
заказа и удаление заказа) должны быть записаны и быть доступными для
администратора.
Следующие два требования – это требования к надежности/защите:
FEAT26: Страницы, где представители служб сервиса предлагают свои услуги,
должны быть защищены паролем. Представители гостиниц, агенты по найму автомобилей
и представители авиалиний должны иметь свои ID (идентификаторы) и пароли для
доступа к этим страницам.
FEAT29: Пользователи должны выбирать свой ID и предоставлять пароль при
покупке билета.
Следующее требование довольно сложное:
FEAT36: Следующие отчеты должны быть доступны администратору:
Список всех билетов на самолет, купленных за данный период времени.
Список всех заказов автомобилей за данный период времени.
Список всех заказов номеров гостиниц, за данный период времени.
Этому требованию необходимо немного пояснения. Например, следующие аспекты
требования нуждаются в уточнении:
Откуда должны быть доступны отчеты.
Какие атрибуты должны быть доступны для поиска.
Как выбирать доступные отчеты.
В этой ситуации лучше создать отдельный сценарий использования, чем включать
требование в Дополнительную Спецификацию (Supplementary Specification).
Следующее требование описывает не саму систему, а требование к разработке
системы:
FEAT28: Система должна быть разработана в течение трех месяцев с начала даты,
когда заказчик подпишет документы Сценариев Использования и Дополнительную
Спецификацию.
140
Наилучшее место для хранения этого требования – это Контракт или План Работ, но
не документация требований к системе. Тем не менее, если мы хотим включить его в
Дополнительную Спецификацию (Supplementary Specification), мы можем создать
отдельный пункт Development Process Requirement (Требования Процесса Разработки).
Вот несколько других требований, которые могут попасть в эту же категорию:
Пример: Разработка должна быть сделана в помещении заказчика.
Пример: Группа тестирования должна включать, по крайней мере, два тестера для
ручного тестирования и два тестера с опытом в Rational Robot.
Пример: Система должна быть разработана с использованием RUP.
8.4 Атрибуты Дополнительных Требований
Атрибуты, установленные по умолчанию у дополнительных требований:
Priority (Приоритет)
Author (Автор)
Status (Статус)
Location (Расположение)
Difficulty (Сложность)
Enhancement Request (Запрос на
Stability (Устойчивость)
Обновление)
Risk (Риск)
Defect (Ошибка)
Contact Name (Имя Контакта)
Obsolete (Недействительный)
Этот список может немного меняться в зависимости от версии RequisitePro.
Некоторые требования (особенно относительно производительности) могут
различаться в зависимости от количества пользователей. В этом случае мы можем
использовать метод, который предложил Mark Lines: создать таблицу с требованиями
производительности по числу одновременных пользователей, чтобы показать приемлемое
уменьшение. В Таблице 8.5. показан пример. Вам может понадобиться отдельная таблица
для каждой транзакции сценария использования.
Таблица 8.5. Дифференцирование Требований в Зависимости от Количества
Одновременных Пользователей.
Количество Одновременных Пользователей
от 1 до 10
от 11 до 50
от 51 до 100
Более чем 100
Максимальное Время транзакции (сек)
3
5
7
10
Данный пункт описывает два атрибута,
дополнительных требований.
которые могут быть полезными для
Importance (Важность)
Поскольку все функциональные требования обычно действительно требуют
реализации в системе, нефункциональные требования могут иметь разный уровень
важности. Например, некоторые из требований – обязательны:
Приложение должно быть доступно для пользователей браузера Internet Explorer.
Если Internet Explorer системой не поддерживается, наибольшая часть пользователей
Интернет не будет иметь возможность пользоваться приложением.
Некоторые требования – желаемые:
Последующие формы экрана должны появляться менее чем через две секунды.
Если по времени будет не две, а четыре секунды, пользователи будут менее
счастливы, но они также будут иметь возможность пользоваться приложением.
Некоторые требования – не так важны:
Система должна быть работоспособной в течение одной минуты после запуска.
Система перегружается только раз в несколько дней, и системный администратор –
единственный, кто ждет это время, так что даже если это будет занимать пять или десять
минут, ничего страшного в этом нет.
141
Понимание уровня важности поможет Вам правильно распределить ресурсы на
проектирование и реализацию определенных решений с разумной стоимостью.
Для хранения уровня важности, мы можем создать новый атрибут Важность
(Importance) с тремя возможными значениями:
Mandatory (Обязательный).
Desirable (Желаемый).
Nice to have (Возможный).
Если Вы не хотите создавать новый атрибут, Вы можете использовать Priority
(Приоритет) для хранения этих значений (тем не менее, приоритет и важность не совсем
синонимы).
Satisfaction Shape (Степень Удовлетворенности)
Другой атрибут, применимый к дополнительным требованиям это степень
удовлетворенности (satisfaction shape). Этот атрибут описывает, как степень
удовлетворенности заказчика меняется в зависимости от качества исполнения требуемых
характеристик.
Степень удовлетворенности может иметь следующие значения:
Sharp (Точная): Характеристики требования должны быть реализованы в
точности так, как описаны в требовании. Результат не может быть даже на
немного хуже.
Medium (Умеренная): Значение результата должно быть близко к ожидаемым
значениям. Однако допускается небольшое расхождение.
Linear (Линейная): Чем лучше результат, тем выше удовлетворенность. Однако
точных ожидаемых значений не приводится.
Проанализируем несколько примеров.
Удовлетворенность
Точная Степень Удовлетворенности (Sharp Satisfaction Shape)
Представьте систему, сортирующую папки в реальном времени. Папки перемещаются
в цепочку конвейера. Система сканирует адрес метки на папке и, на основании пункта
назначения, дает инструкции дивертору направить папку в определенную цепочку.
Требование заключается в том, что система должна вычислять определенное действие
дивертора в течение одной секунды. Если нет, то папка пройдет мимо дивертора.
В этом случае время ответа должно быть меньше одной секунды, иначе вся система
не будет работать. Но не важно, если это будет выполняться за 0.99 секунд или 0.5
секунд. Нет дополнительного значения для получения более короткого времени ответа.
Рисунок 8.2. показывает степень удовлетворенности для этого требования. Для всех
значений, которые меньше одной секунды, удовлетворенность равна единице. А для всех
значений, больших одной секунды, удовлетворенность равно нулю.
Время ответа
Рисунок 8.2. Точная Степень Удовлетворенности (Sharp Satisfaction Shape).
Умеренная Форма Удовлетворенности (Medium Satisfaction Shape)
Предположим, что в некоторой системе batch-файлы и транзакции с предыдущего
дня обрабатываются ночью. Лицо, ответственное за анализ результатов ночного batch-
142
Удовлетворенность
процесса, приходит в офис в 8 утра. Это означает, что batch-процесс должен быть
закончен до 8-ми утра. Не страшно, если он закончится в 8:30. Но если в 9 или 10- это
уже будет проблемой. Степень удовлетворенности показана на Рисунке 8.3.
Будет ли значение удовлетворенности уменьшаться или увеличиваться, зависит от
требования.
Например, для требования «Система должна обслуживать 5000
одновременных пользователей»: чем выше значения удовлетворенности – тем выше
количество пользователей по горизонтальной оси, как показано на Рисунке 8.4.
Время обработки
Удовлетворенность
Рисунок 8.3. Умеренная Степень Удовлетворенности (Medium Satisfaction Shape) для
требования ко времени обработки.
Число одновременных пользователей
Рисунок 8.4. Умеренная Степень Удовлетворенности (Medium Satisfaction Shape) для
требования к количеству одновременных пользователей.
Линия не обязательно должна быть симметричной.
Линейная Степень Удовлетворенности (Linear Satisfaction Shape)
Отчет должен отображаться в течение 20-ти секунд или менее. Двадцать секунд –
это просто разумная цифра, обеспечивающая хорошие ожидания по отношению стоимости
(см. Рисунок 8.5).
Важность (Importance) не обязательно стоит рядом с удовлетворенностью. Например,
количество одновременных пользователей очень важно, но нет точного значения. Нет
большой разницы между 4900 и 5000 пользователей.
143
Удовлетворенность
Время обработки отчета
Рисунок 8.5. Линейная Форма Удовлетворенности (Linear Satisfaction Shape).
8.5 Ввод Дополнительных Требований в RequisitePro
Как и любые другие требования, мы можем ввести дополнительные требования в
RequisitePro тремя разными способами:
Прямо из Explorer (Проводника).
Из представления (view).
Создание Дополнительной Спецификации (Supplementary Specification), а затем
добавление требования из документа.
Для добавления требования из Explorer (Проводника) выполните следующие действия:
1. Правой кнопкой мышки нажмите на папке Supplementary Requirements
(Дополнительные Требования) и выберите New>Requirement
(Новое>Требование).
2. Заполните поля в диалоговом окне Requirement Properties (Свойства Требования).
В некоторых шаблонах представление All Supplementary Requirements (Все
Дополнительные Требования) уже создано. Если Вы работаете с шаблоном, не
содержащим это предустановленное по умолчанию представление, выполните следующие
действия для его создания:
1. Правой кнопкой мышки нажмите на папке Supplementary Requirements
(Дополнительные Требования) и выберите New>View (Новое>Представление).
2. В диалоговом окне View Properties (Свойства Представления), как показано на
Рисунке 8.6, View Type (Тип Представления) должен быть Attribute Matrix
(Матрица Атрибутов), а Row Requirement Type (Тип Требования в Строке) должен
быть SUPL.
Рисунок 8.6. Диалоговое окно View Properties (Свойства Представления).
144
Добавление требований из представления включает следующие действия:
1. В окне Explorer (Проводника), двойным щелчком мышки нажмите на
представлении All Supplementary Requirements (Все Дополнительные Требования).
2. В представлении, нажмите на последнюю строку с текстом «Нажмите здесь для
создания требования».
3. Введите Name (Название) и Text (Текст).
Большое преимущество третьего подхода (создание Дополнительной Спецификации Supplementary Specification и затем добавления требования из документа) в том, что мы можем
распечатать внутренний документ и использовать его в качестве коммуникаций с
заказчиком. Иногда этот документ даже используется как часть контракта с заказчиком.
Для создания Дополнительной Спецификации (или, если Вы следуете текущей конвенции
наименований в RUP, Дополнительных Спецификаций) выполните следующие действия:
1. Правой кнопкой мышки нажмите на папке Supplementary Requirements
(Дополнительные Требования) и выберите New>Document (Новый>Документ).
2. Заполните поля в диалоговом окне Document Properties (Свойства Документа),
как показано на Рисунке 8.7.
Рисунок 8.7. Диалоговое окно Document Properties (Свойства Документа).
Формат документа, предложенный шаблоном RUP [RUP04]:
1. Introduction (Введение)
1.1 Purpose (Назначение)
1.2 Scope (Область Применения)
1.3 Definitions, Acronyms, and Abbreviations (Определения, Акронимы и Аббревиатуры)
1.4 References (Ссылки)
1.5 Overview (Обзор)
2. Functionality (Функциональность)
3. Usability (Удобство Использования)
4. Reliability (Надежность)
5. Performance (Производительность)
6. Supportability (Способность к Сопровождению)
7. Design Constraints (Ограничения на Дизайн)
8. Online User Documentation and Help System Requirements (Он-лайн Документация
Пользователя и Требования к Системе Сопровождения)
9. Purchased Components (Приобретенные Компоненты)
10. Interfaces (Интерфейсы)
10.1 User Interfaces (Интерфейсы Пользователя)
10.2 Hardware Interfaces (Интерфейсы Аппаратного Обеспечения)
10.3 Software Interfaces (Интерфейсы Программного Обеспечения)
10.4 Communications (Интерфейсы Коммуникаций)
11. Licensing Requirements (Требование по Лицензиям)
145
12. Legal, Copyright, and Other Notices (Юридические Нормы, Авторское Право и Другие
Заметки)
13. Applicable Standards (Допустимые Стандарты).
Требования располагаются в определенных пунктах согласно типу. Они могут быть
выделены в отдельные пункты, как показано на Рисунке 8.8, а могут быть сгруппированы,
как показаны на Рисунке 8.9.
Рисунок 8.8. Каждое требование в отдельном заголовке.
Рисунок 8.9. Несколько требований, скомбинированных под одним заголовком.
После написания требований в виде свободного текста в документе Microsoft Word
Вы должны добавить их в базу данных:
1. Выделите текст, который описывает требование.
2. Выберите RequisitePro>Requirement>New (Требование>Новое), либо правой
кнопкой мышки нажмите на тексте и выберите Create Requirement (Создать
Требование), либо нажмите на иконку New Requirement (Новое Требование) в
панели инструментов.
3. Заполните поля в диалоговом окне Requirement Properties (Свойства Требования)
на закладке General (Основное), как показано на Рисунке 8.10. Выберите SUPL в
качестве Type (Типа).
Рисунок 8.10. Диалоговое окно Requirement Properties (Свойства Требования).
146
4. Если сейчас Вы хотите установить атрибуты сейчас, нажмите на закладку
Attributes (Атрибуты) для изменения значений атрибутов (Вы также можете
сделать это позже).
5. Если сейчас Вы хотите установить трассировку (связь), нажмите на закладку
Traceability (Трассировка) для определения того, из какого требования было
получено каждое требование (Вы также можете сделать это позже).
После сохранения требований в базе данных Вы можете выделить целое описание,
либо только одно предложение, описывающее требование. Если вся идея выражена одним
предложением, а остальные предложения просто поясняют требование, достаточно
сохранить только одно предложение, как показано на Рисунке 8.11. Однако если для
понимания требования необходимо несколько предложений, можно добавить и длинное
описание, как показано на Рисунке 8.12. Преимущество выделения полного описания в
том, что оно позволяет осуществлять автоматическую проверку подозрительных связей
при изменении требований.
Рисунок 8.11. Сохранение только первого предложения требования в базу данных.
Рисунок 8.12. Сохранение нескольких предложений, описывающих требование, в базу
данных.
Когда требования хранятся в базе данных, но документ еще не сохранен, они
помечаются префиксом SUPLpending, как показано на Рисунке 8.13. После сохранения
документы, префикс меняется на SUPL, как показано на Рисунке 8.14.
Рисунок 8.13. Префикс требований до сохранения документа.
Рисунок 8.14. Префикс требований после сохранения документа.
147
После сохранения всех требований в базе данных, они появляются в окне Explorer
(Проводника), как показано на Рисунке 8.15.
Рисунок 8.15. Дополнительные требования в Explorer (Проводнике) RequisitePro.
8.6 Трассировка к Дополнительным Требованиям
Большинство дополнительных требований трассируются из функциональных
особенностей. В зависимости от рекомендаций к проекту, мы можем разрешить их
трассировку прямо из потребностей заинтересованных лиц. Мы также можем разрешить
требованиям быть добавленными напрямую на уровень дополнительных требований. Тем
не менее, эти решения должны приниматься при разработке Плана Управления
Требованиями (RMP). Они не должны приниматься спонтанно при завершении работы над
Дополнительной Спецификацией (Supplementary Specification).
Установка Атрибута Тип (Type) Функциональным Особенностям
Чтобы облегчить установку трассировки из функциональных особенностей в
дополнительные требования, стоит установить значения атрибута Type (Тип) для
функциональных особенностей. В зависимости от используемой Вами версии RequisitePro,
этот атрибут может быть уже определен. В версии 2003.06.13 этот атрибут имеет
следующие значения:
Functional, non use-case
Design Constraint (Ограничения на
(Функциональный, не связан со
Дизайн)
сценариями использования)
Implementation Reqt (Требования
Usability (Удобство Использования)
Реализации)
Reliability (Надежность)
Physical Reqt (Требования
Performance (Производительность)
Аппаратного Обеспечения)
Supportability
(Способность
к
Interface Reqt (Требования
Сопровождению)
Интерфейса)
Вы можете использовать предустановленные значения, или же изменить их на более
подходящие Вам значения. Например, если Вы хотите меньшую детализацию, Вы можете
использовать только четыре значения:
Functional: UC specific (Функциональный: Связан со Сценарием Использования).
148
Functional: Generic (Функциональный: Основной).
Non-functional: UC specific (Нефункциональный: Связан
Использования).
Non-functional: Generic (Нефункциональный: Основной).
со
Сценарием
Для использования этих четырех опций Вы можете установить тип атрибута в List
(Single Value) и ввести их в список. Либо установить тип атрибута в List (Multiple Value) и
указать следующие значения (см. Рисунок 8.16):
Functional (Функциональный)
Non-functional (Нефункциональный)
UC specific (Связан со Сценарием Использования)
Generic (Основной)
Рисунок 8.16. Атрибут типа List (Multiple Value).
Для Multiple Value List (списка с множественными значениями) Вы можете ввести
более чем одно значение, например Functional (Функциональный) и UC specific (Связан со
Сценарием Использования). Тем не менее, убедитесь, что Вы вводите верные комбинации
значений атрибутов. Например, Вам не следует вводить UC specific (Связан со Сценарием
Использования) вместе с Generic (Основной).
Если Вы не установили атрибут Type (Тип) при вводе функциональных особенностей,
Вы можете сделать это сейчас. Наиболее быстрый путь для установления атрибутов сразу
нескольких требований – из представлений (views). Первым делом проверьте, находится
ли требуемый атрибут в представлении. Если атрибут Type (Тип) отсутствует в таблице,
Вам нужно добавить его в представление, выполнив следующие действия:
1. Правой кнопкой мышки нажмите на заголовке строки представления и выберите
Displayed Attributes (Отображаемые Атрибуты).
2. В левом окне выберите атрибуты, которые Вы хотите увидеть в представлении,
как показано на Рисунке 8.17.
3. В правом окне Вы можете установить порядок, в котором атрибуты будут
появляться.
Рисунок 8.17. Выбор атрибутов, которые будут отображаться в представлении.
149
Чтобы установить атрибуты нескольким требованиям выполните следующие
действия:
1. Двойным
щелчком
мышки
нажмите
представлении
All
Features
(Все
Функциональные Особенности) в папке Features and Vision (Функциональные
Особенности и Концепция).
2. Двойным щелчком мышки нажмите на ячейке в пересечении колонки Type (Тип) и
строки с требованием, которое Вы хотите изменить.
3. Выберите соответствующее значение из списка, как показано на Рисунке 8.18.
Рисунок 8.18. Выбор значений атрибутов из представления.
Установка Трассировки (Связей)
Если представление в виде Матрицы Трассировки (Traceability Matrix) из FEAT в SUPL
еще не настроено, Вы можете создать его, выполнив следующие действия:
1. Правой кнопкой мышки нажмите на папке Supplementary Requirements
(Дополнительные Требования) и выберите New>View (Новое>Представление).
3. В диалоговом окне View Properties (Свойства Представления), как показано на
Рисунке 8.19, View Type (Тип Представления) должен быть Traceability Matrix
(Матрица Трассировки), Row Requirement Type (Тип Требования в Строке) должен
быть SUPL, а Column Requirement Type (Тип Требования в Столбце) должен быть
FEAT.
Рисунок 8.19. Диалоговое окно View Properties (Свойства Представления) для Матрицы
Трассировки (Traceability Matrix).
Это представление может быть создано с требованиями FEAT в строках и SUPL в
столбцах.
Так как в эту матрицу нам не нужно включать функциональные особенности,
которые уже были отображены в сценариях использования, мы можем создать запрос,
чтобы показывать только те функциональные особенности, которые не относятся к
сценариям использования:
1. Нажмите на кнопку Query (Запрос) напротив FEAT.
2. В диалоговом окне Select Attribute (Выбор Атрибута), как показано на Рисунке
8.20, выберите Type (Тип) в качестве названия атрибута.
150
Рисунок 8.20. Выбор атрибута, на основании которого мы хотим фильтровать
требования.
3. Нажмите ОК в диалоговом окне Select Attribute (Выбор Атрибута).
4. В диалоговом окне Query Requirements (Запрос Требований), как показано на
Рисунке 8.21, выберите в левом окне нужные значения.
5. Нажмите ОК в диалоговом окне Query Requirements (Запрос Требований).
6. Нажмите ОК в диалоговом окне Query Column Requirements (Запрос к
Требованиям в Столбце), как показано на Рисунке 8.22.
Рисунок 8.21. Выбор значений атрибута, на основании которого мы хотим фильтровать
требования.
Рисунок 8.22. Добавление критерия запроса в диалоговом окне Query Column
Requirements (Запрос к Требованиям в Столбце).
7. Нажмите ОК в диалоговом окне View Properties (Свойства Представления), как
показано на Рисунке 8.19.
Представление отображает только функциональные особенности, имеющие один из
выбранных значений атрибута Type (Тип).
151
Для установки трассировки (связей), выполнив следующие действия:
1. Правой кнопкой мышки нажмите на пересечении функциональной особенности и
соответствующего дополнительного требования.
2. Выберите Traced Frоm (Трассируется Из) или Traced To (Трассируется В) в
зависимости от того, что у Вас находится в строках и от Вашей интерпретации
направления трассировки.
После установки трассировки (связей) Вы можете анализировать ее как в Матрице
Трассировки (Traceability Matrix, см. Рисунок 8.23), так и в Дереве Трассировки
(Traceability Tree, см. Рисунок 8.24). Дерево Трассировки позволяет Вам увидеть весь путь
от запросов заинтересованного лица.
Рисунок 8.23. Traceability Matrix (Матрица Трассировки) из FEAT в SUPL.
152
Рисунок 8.24. Traceability Tree (Дерево Трассировки) в SUPL.
Создание Запросов для Требований
После установки трассировки (связей) Вы можете проверить, были ли охвачены все
функциональные особенности, относящиеся к дополнительным требованиям. Вы можете
сделать это с использованием представления Матрицы Трассировки (Traceability Matrix)
или Дерева Трассировки (Traceability Tree).
Нам необходимо отфильтровать функциональные особенности одновременно по двум
критериям:
Фильтр 1: Функциональные особенности, у которых есть атрибут Type (Тип),
приемлемый для дополнительных требований.
Фильтр 2: Функциональные особенности, которые не трассируются в дополнительные
требования.
В представлении Traceability Requirements Traced From Features (Трассировка
Требований из
Функциональных Особенностей), первый фильтр уже применен к
требованиям столбца, так что нам нужно установить только второй фильтр:
1. Выберите View>Query Column Requirements (Представление>Запрос к
Требованиям в Столбце).
2. Нажмите кнопку Add (Добавить) в диалоговом окне Query Column Requirements
(Запрос к Требованиям в Столбце).
3. Выберите Traced To (Трассируется В) в диалоговом окне Select Attribute (Выбор
Атрибута), как показано на Рисунке 8.25.
153
Рисунок 8.25. Выбор атрибута, на основании которого будет осуществляться
фильтрация.
4. Нажмите ОК в диалоговом окне Select Attribute (Выбор Атрибута).
5. Выберите SUPL в левом окне диалогового окна Query Requirements (Запрос
Требований), как показано на Рисунке 8.26.
Рисунок 8.26. Выбор нужной трассировки.
6. Выберите Not Traced (Не Трассируются).
7. Нажмите ОК в диалоговом окне Query Requirements (Запрос Требований).
8. Нажмите ОК в диалоговом окне Query Column Requirements (Запрос к
Требованиям в Столбце), которое теперь показывает оба фильтра (см. Рисунок
8.27).
Рисунок 8.27. Все фильтры, примененные к требованиям.
Мы ожидаем получить пустое представление, как показано на Рисунке 8.28. Если на
нем отображается какая-либо функциональная особенность, она требует тщательного
анализа. Возможно, мы забыли добавить дополнительные требования, удовлетворяющие
данной функциональной особенности, или мы сделали ошибку в установке трассировки
(связей) или установки атрибута Type (Тип).
154
Рисунок 8.28. Пустое представление после применения обоих условий.
8.7 Заключение
В зависимости от области применения, требования к программному обеспечению
могут быть расположены либо в Спецификации Сценариев Использования (Use Cases
Specification), либо в Дополнительной Спецификации (Supplementary Specification).
Дополнительные требования вместе со сценариями использования содержат в себе все
требования к программному обеспечению. Большинство дополнительных требований –
нефункциональные.
Они
относятся
к
удобству
использования,
надежности,
производительности, способности к сопровождению и ограничениям на дизайн системы.
Наиболее распространенный метод сбора дополнительных требований – интервью и
анкетирование с использованием предустановленного набора вопросов. Список
упорядочивает
требования
согласно
выбранной
классификации,
такой
как
FURPS+[GRA92].
Так как небольшое улучшение производительности или надежности может стоить
достаточно дорого в отношении требуемых ресурсов, стоит определять важность и степень
удовлетворенности для каждого требования. Анализ этих атрибутов может помочь Вам
оптимально распределить ресурсы и направить усилия туда, где они больше всего
необходимы.
После сбора всех требований в RequisitePro мы должны установить трассировку
(связь) из функциональных требований (и, если требуется, из потребностей
заинтересованного лица). Далее, мы можем создавать запросы, чтобы проверить, все ли
функциональные особенности были охвачены дополнительными требованиями.
Ссылки
[EEL01] Eeles, Peter. Capturing Architectural Requirements, Rational Edge, 2001.
[LAU02] Lauesen, Soren. Software Requirements: Styles and Techniques, Boston: AddisonWesley, 2002.
[MCC80] McCall, J.A., and M. Matsumoto. Software Quality Metrics Enhancements, Rome Air
Development Center, 1980.
[ISO91] ISO/IEC TR 9126, Information Technology, software product evaluation, quality
155
characteristics and guidelines for their use. International Organization for Standardization,
Geneva, 1991.
[GRA92] Grady, Robert. Practical Software Metrics for Project Management and Process
Improvement, Upper Saddle River, NJ: Prentice Hall, 1992.
[RUP04] Rational Unified Process, Version 2003.06.13, IBM, 2003.
[CUA91a] Systems Application Architecture Common User Access Guide to User Interface
Design, SC34-4289, IBM Corporation, 1991.
[CUA91b] Systems Application Architecture Common User Access Advanced Interface Design
Reference, SC34-4290, IBM Corporation, 1991.
156
ГЛАВА 9
Создание Тестовых Сценариев
(Test Cases) из
Сценариев Использования
(Use Cases)
Эта глава описывает, как создавать функциональные тестовые сценарии (test cases)
из сценариев использования (use cases). Во многих проектах не уделяется достаточного
внимания важности этого шага. Часто тестерам отдают распечатанную версию
Спецификации Сценариев Использования (Use Case Specification), а затем они проводят
тестирование вручную. Однако если мы проигнорируем формальное создание тестовых
сценариев, мы можем придти к тому, что будет покрыта не вся область тестирования, в то
время как многие тесты будут дублироваться.
Здесь представлен формальный метод, способствующий достижению довольно
хорошего покрытия области тестирования с использованием разумного количества
тестовых сценариев. Этот подход представил Jim Heumann [HEU01a] [HEU01b]. Подход
требует создания сценариев (алгоритмов). Алгоритмы были представлены в Главе 7
«Создание Сценариев Использования (Use Cases)». Тестовые сценарии располагаются
одним уровнем ниже сценариев (алгоритмов), как показано на Рисунке 9.1.
Так как эта глава представляет новый тип документов, не определенный в
стандартных шаблонах RequisitePro, пункт 9.3 показывает, как создавать новый тип
документов в RequisitePro. Если мы хотим избежать любых дополнительных усилий по
созданию и настройке нового типа требований и нового типа документов, мы можем
связать требования с тестовыми сценариями в инструменте управлением тестированием
(например, ClearQuest Test Manager). Тем не менее, создание нового типа - процесс очень
быстрый и несложный, и я считаю, что стоит хранить все в среде RequsitePro.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 9.1. Извлечение тестовых сценариев (test cases) из сценариев (алгоритмов,
scenarios).
157
9.1 Создание Тестовых Сценариев
Когда у нас есть все сценарии (алгоритмы), полученные в Главе 7, нам нужно
создать тестовые сценарии. Этот процесс включает в себя четыре шага:
1. Определение переменных для каждого шага сценариев использования.
2. Определение существенно разных вариантов для каждой переменной.
3. Комбинирование вариантов для тестирования в тестовые сценарии.
4. Определение значений переменным.
Последующие пункты описывают детали каждого шага.
Шаг 1: Определение Переменных для Каждого Шага Сценариев
Использования
Первым делом нам нужно определить все входные переменные во всех шагах в
представленном сценарии (алгоритме). Например, если на некотором шаге пользователь
вводит свой идентификатор и пароль, это две переменных. Первая переменная
Идентификатор, вторая – Пароль. Переменной также может быть выбор, который
пользователь должен сделать (такой как выбор рейса из списка).
Приведем переменные из сценария использования Бронирование рейса:
В3. Турист вводит информацию о рейсе.
o Аэропорт вылета
o Дату вылета
o Аэропорт прибытия
o Дату прибытия
o Число путешествующих взрослых
o Число путешествующих детей
В5. Турист выбирает рейс.
o Рейс вылета
В7. Турист выбирает рейс прибытия.
o Рейс прибытия
В10. Пользователь предоставляет Идентификатор и Пароль для покупки билета.
o Идентификатор
o Пароль
В11. Турист предоставляет информацию пассажира.
o Имя
o Фамилия
o Пол
o Дата рождения
В13. Турист выбирает места.
o Места
В14. Турист предоставляет информацию по кредитной карте и расчетный адрес.
o Тип кредитной карты
o Номер кредитной карты
o Дата окончания срока действия
o Название карты
o Адрес
o Город
o Штат
o Почтовый индекс
o Страна
Количество переменных может зависеть от введенных на предыдущем шаге
значений. На шаге В3 Число путешествующих взрослых = 2, Число путешествующих детей
= 1. Тогда шаг В11 будет содержать три набора данных – по одному на каждого
158
пассажира. Если на шаге В5 выбранный рейс имеет остановку, на шаге В13 места должны
быть указаны для каждого отрезка полета.
Шаг 2: Определение Существенно Различных Вариантов для
Каждой Переменной
Варианты считаются «существенно разными», если они могут вызывать различное
поведение системы.
Например, если мы выберем Идентификатор, который предполагается быть длиной
до 10-ти символов, следующие приведенные значения будут существенно разными:
Alex - слишком короткий и мы ожидаем появления сообщения об ошибке.
Alexandra – верный Идентификатор.
Alexandrena – слишком длинный, и мы ожидаем, что система не позволит нам
вводить слишком длинный Идентификатор.
Однако, Alexandria или JohnGordon различны не существенно, т.к. оба являются
верными идентификаторами, вызывающими одно поведение системы.
Ниже приведены некоторые особые случаи.
Вариант может считаться существенно другим, если:
Он вызывает другой ход процесса (обычно альтернативный поток).
Пример: Ввод неверного пароля вызовет Альтернативный Поток 2.
Он вызывает другое сообщение об ошибке.
Пример: Если адрес электронной почты слишком длинный, сообщение должно
быть: «E-mail должен быть не более 50-ти символов».
Пример: Если адрес электронной почты не содержит символа «@», сообщение
должно быть: «Неверный E-mail адрес».
Он вызывает другой вид пользовательского интерфейса.
Пример: Если кредитная карта была выбрана в качестве способа оплаты, система
должна отображать экран с полями для ввода номера кредитной карты, даты
окончания срока действия и название организации, обслуживающей карту.
Он вызывает различный набор значений списков.
Пример: Экран регистрации пользователя должен содержать список Страна и
Штат/Провинция. Список Штат/Провинция будет содержать значения на основе
выбранной страны: для США он должен содержать все штаты, для Канады – все
провинции, для других стран он должен быть недоступен.
Это требования создает три существенно разных варианта:
o США
o Канада
o Любая другая страна
Он является исходными данными для бизнес-правил.
Пример: Если заказ сделан после 18:00, а пользователь выбрал «Overnight
Shipment», будет выдано информационное сообщение о том, что заказ прибудет
послезавтра.
Бизнес-правило образует два варианта:
o Ночная Доставка, заказ поступил до 18:00.
o Ночная Доставка, заказ поступил после 18:00.
Он является условием ограничения.
Пример: Пароль должен быть не менее 6-ти символов.
В этом случае мы должны протестировать следующее:
o Пароль с пятью символами.
o Пароль с шестью символами
Что-то должно быть изменено вместо использования значения по умолчанию.
Пример: На экране оплаты кредитной картой название организации,
обслуживающей кредитную карту, должно быть заполнено именем лица,
159
размещающего заказ. Пользователь должен иметь возможность хранить это
значение по умолчанию или ввести новое.
Это создает два различных варианта:
o Хранить
установленное
по
умолчанию
название
организации,
обслуживающей кредитную карту.
o Изменить установленное по умолчанию название организации на другое.
Формат ввода точно не определен и может быть интерпретирован разными
способами.
Пример: поле ввода номера телефона должно принимать текст в свободной
форме.
Номера телефонов разными лицами пишутся по-разному:
o Использования скобок: (973) 123-4567
o Использование тире: 973-123-4567
o Использование пробелов: 973 123 4567
o Без пробелов: 9731234567
Все доступные варианты должны быть протестированы.
Стандартные варианты могут быть разными для разных стран.
Формат даты срока окончания действия кредитной карты может быть разным для
США и Европы.
Если Вы тестируете номера, Вы можете проверить следующие существенно
разные варианты:
o Стандартный номер, верный с точки зрения приложения.
o Ноль
o Отрицательный номер
o Наибольшее
значение,
которое
только
может
быть
введено
(99999999999999 – столько девяток, сколько может поместиться в поле
для ввода).
Многие варианты зависят от специфики самого приложения. Например, различными
вариантами для выбора рейса могут быть:
Выбор прямого рейса
Выбор рейса с одной остановкой
Выбор рейса с двумя остановками
Выбор рейса, прибывающего на следующий день
Выбор рейса, прибывающего через два дня после даты вылета
Если Вы удивляетесь, каким образом возможен последний вариант, проверьте
вечерние рейсы из США в Австралию.
Достаточно часто существенно разные варианты включают комбинации более одного
значения. На экране, где мы вводим даты рейсов вылета и прибытия, у нас есть
следующие комбинации:
Дата прибытия позже даты вылета (стандартный случай).
Дата прибытия равна дате вылета (условие ограничения – правильность зависит
от времени рейсов).
Дата прибытия раньше даты вылета (ошибка).
Не указаны даты (ошибка).
В зависимости от специфики правил Airline Reservation System, мы можем добавить
еще вариант, например «Дата прибытия более чем на один год позже даты вылета».
Определим несколько вариантов, нужных для тестирования в основном потоке
сценария использования Бронирования рейса:
В3. Турист вводит информацию о рейсе.
o Аэропорт вылета
Верный код аэропорта
Верный город и штат
Верный город и страна
160
o
o
o
o
o
Неверный код аэропорта
Несуществующий код аэропорта
Пустое поле
Дату вылета
Верная дата в будущем, установленная вручную
Верная дата в будущем, установленная из календаря
Дата в прошлом
Сегодняшняя дата
Февраль 30 или 31 число
Пустое поле
Аэропорт прибытия
Верный код аэропорта
Верный город и штат
Верный город и страна
Неверный код аэропорта
Несуществующий код аэропорта
Пустое поле
Дату прибытия
Приемлемая дата, одна неделя позже даты вылета
Приемлемая дата, установленная из календаря
Дата, равная дате вылета
Дата в будущем раньше даты вылета
Дата в прошлом
Февраль 30 или 31 число
Число путешествующих взрослых
0
1
2
Максимально допустимое
Число путешествующих детей
0 (с числом взрослых = 0)
0 (с числом взрослых > 0)
1 (с числом взрослых = 0)
1 (с числом взрослых > 0)
В5. Турист выбирает рейс.
o Рейс вылета
Любой прямой рейс
Рейс с одной остановкой
Рейс с максимальным количеством остановок
Самый дешевый рейс
Рейс, прибывающий на следующий день (если такой есть)
Рейс, прибывающий через два дня (если такой есть)
В7. Турист выбирает рейс прибытия.
o Рейс прибытия
То же самое, что и для рейса вылета
В10. Пользователь предоставляет Идентификатор и Пароль для покупки билета.
o Идентификатор
Верный идентификатор пользователя
Идентификатор, содержащие недопустимые символы
Несуществующий идентификатор пользователя
Пустое поле
o Пароль
Правильный пароль пользователя (с правильным идентификатором)
Неправильный пароль (с правильным идентификатором)
Верный пароль (с неверным идентификатором)
Пароль, содержащий недопустимые символы
161
Пустое поле
В11. Турист предоставляет информацию пассажира.
o Имя
Верное имя
Длинное имя (максимально допустимое количество символов)
На один символ больше чем допустимо
Один символ
Пустое поле
o Фамилия
Стандартная фамилия
Длинная фамилия (максимально допустимое количество символов)
Фамилия, содержащая апостроф (например Д’Артаньян)
На один символ больше чем допустимо
Один символ
Пустое поле
Два слова с пробелом между ними
o Пол
М
Ж
o Дата рождения
Верная дата
Дата в будущем
Слишком поздняя дата для взрослого
Слишком ранняя дата для ребенка
Неверная дата
В13. Турист выбирает места.
o Места
Оставить значение по умолчанию
Место у окна
Место в середине
Место у прохода
Два места рядом
Два места отдельно
Одно место при наличии двух пассажиров
В14. Турист предоставляет информацию по кредитной карте и расчетный адрес.
o Тип кредитной карты
Один вариант для каждой кредитной карты
o Номер кредитной карты
Верный номер для данного типа
Неверный номер для данного типа
Неверный номер для любой карты
Номер, содержащий буквы
Номер, содержащий специальные символы
Пустое поле
o Дата окончания срока действия
Верная дата в будущем
Дата в прошлом
Неверная дата для верной карты
Неверная дата
o Название карты
Оставить значение по умолчанию (имя пассажира)
Ввести новое значение
Верное имя, но не владельца этой карты
Пустое поле
Максимальное количество допустимых букв
o Адрес
162
o
o
o
o
Верный адрес
Максимальное количество допустимых символов
Пустое поле
Верный адрес, но не расчетный адрес для этой карты
Город
Верный город
Максимальное количество допустимых символов
Пустое поле
Штат
Верный штат
Штат не выбран
Почтовый индекс
Верный код
Недопустимые символы
Четырехзначный код
Шестизначный код
Пустое поле
Страна
США
Верная страна, но не США
Несуществующая страна, максимальное количество допустимых символов
Пустое поле
Шаг 3: Комбинирование Вариантов для Тестирования в
Тестовые Сценарии
Предыдущий пункт определил все существенно разные варианты, нужные для
тестирования. Теперь нам нужно скомбинировать их в последовательность шагов
тестового сценария. Один из способов это сделать – создать Матрицу Распределения
Тестовых Сценариев (Test Case Allocation Matrix). Строки этой матрицы содержат все
переменные для всех шагов, требующие ввода данных он пользователя. Первая колонка
содержит номер шага, вторая – название переменной, а остальные – тестовые сценарии.
Вы можете назвать их Т1, Т2, и т.д. Вам нужно оценить, насколько много тестовых
сценариев нужно для охвата данного сценария (алгоритма). Жестким вариантом оценки
будет максимальное количество существенно различных вариантов, определенное для
переменной. Не проблема, если Вы допустите ошибку при оценке, т.к. Вы можете
добавить или удалить колонку при заполнении матрицы. Обычно типичный сценарий
охватывают от пяти до семи тестовых сценариев. Тем не менее, иногда в особых случаях
требуется больше тестовых сценариев. Нам нужно создать матрицу для сценария,
выбранного для тестирования. Таблица 9.1. показывает Матрицу Распределения Тестовых
Сценариев для основного потока сценария использования Бронирование рейса.
Таблица 9.1. Матрица Распределения Тестовых Сценариев со Всеми Переменными для
Сценария использования Бронирование Рейса.
Шаг
В3
В3
В3
В3
В3
В3
В5
В7
В10
В10
В11
В11
В11
В11
В11
Переменная
Аэропорт вылета
Дата вылета
Аэропорт прибытия
Дата прибытия
Число путешествующих взрослых
Число путешествующих детей
Рейс вылета
Рейс прибытия
Идентификатор
Пароль
Имя
Фамилия
Пол
Дата рождения
Имя второго пассажира
Т1
163
Т2
Т3
Т4
Т5
Т6
В11
В11
В11
В11
В11
В11
В11
В13
В13
В13
В13
В13
В13
В14
В14
В14
В14
В14
В14
В14
В14
В14
Фамилия второго пассажира
Пол второго пассажира
Дата рождения второго пассажира
Имя третьего пассажира
Фамилия третьего пассажира
Пол третьего пассажира
Дата рождения третьего пассажира
Места рейса вылета для первого отрезка пути
Места рейса вылета для второго отрезка пути
Места рейса вылета для третьего отрезка пути
Места рейса прибытия для первого отрезка пути
Места рейса прибытия для второго отрезка пути
Места рейса прибытия для третьего отрезка пути
Тип кредитной карты
Номер кредитной карты
Дата окончания срока действия
Название карты
Адрес
Город
Штат
Почтовый индекс
Страна
Для каждой строки введите все необходимые для тестирования варианты. В первой
строке - переменная Аэропорт вылета. В каждой колонке мы введем различные варианты
для тестирования, как показано в Таблице 9.2.
Таблица 9.2. Ввод Выбранных Вариантов в Матрице Распределения Тестовых Сценариев.
Шаг
В3
Переменная
Аэропорт
вылета
Т1
Верный код
аэропорта
Т2
Верный
город и
штат
Т3
Верный
город и
страна
Т4
Неверный
код
аэропорта
Т5
Несуществую
щий код
аэропорта
Т6
Пустое
поле
Некоторые из этих вариантов неверны, т.к. мы выполняем «негативное
тестирование» чтобы увидеть, отображает ли система правильные сообщения об ошибках
(или не позволяет пользователю вводить неправильные данные). Чтобы не разрушать
тестовый сценарий, мы добавим дополнительные пустые строки, где мы введем несколько
верных вариантов для всех значений в предыдущей строке, на которые система должна
ответить отказом. Для второго набора вариантов используйте приемлемые комбинации
всех верных вариантов из предыдущей строки, а также наиболее популярные варианты.
Например, у переменной Аэропорт вылета есть три верных варианта: Верный код
аэропорта, Верный город и штат, Верный город и страна. Мы можем использовать все три
в строке со вторым набором вариантов. Однако, т.к. зарубежные страны используют
аэропорт вылета менее чаще, чем свой аэропорт, и т.к. мы уже протестировали этот
вариант в Т3, для второго набора вариантов в Т6 мы выбрали верный код аэропорта (см.
Таблицу 9.3). Тем не менее, для Аэропорта прибытия мы выбрали второй раз Верный
город и страна, т.к. чаще всего мы не знаем код аэропорта и потому указываем город и
штат (см. Таблицу 9.4). Когда у нас встречается несколько раз один и тот же вариант, для
каждого из них мы можем позже выбрать различные значения (см. пункт «Шаг 4:
Определение Значений Переменным»). Например, Верный код аэропорта может быть EWR
в тестом сценарии Т1, LAX в Т4 и JFK в Т6.
Таблица 9.3. Второй Выбор для Неверных Вариантов.
Шаг
В3
Переменная
Аэропорт
вылета
Т1
Верный
код
аэропорта
Т2
Верный
город и
штат
Т3
Верный
город и
страна
Т4
Неверный
Т5
Несуществующий
Т6
Пустое
поле
Таблица 9.4. Варианты для Аэропорта Прибытия (Предыдущие Строки не Показаны).
Шаг
В3
Переменная
Аэропорт
Т1
Верный
Т2
Верный
Т3
Верный
164
Т4
Неверный
Т5
Несуществующий
Т6
Пустое
вылета
код
аэропорта
город и
штат
город и
страна
поле
Верный
код
аэропорта
Верный код и
штат
Верный
город и
страна
Продолжим заполнение матрицы. При добавлении варианта для каждой строки
будьте уверены, что он не содержит противоречий значениям, выбранным ранее в данной
колонке. В качестве элемента заполнения Вы можете использовать верные варианты или
необычные комбинации, которые не были еще протестированы. Например, Верная дата
через неделю и Верная дата через один год – не существенно разные, т.к. они должны
вызывать одинаковое поведение. Но т.к. у нас есть доступная ячейка в Матрице
Распределения Тестовых Сценариев, мы можем использовать ее для добавления
необычных вариантов, чтобы быть уверенными, что система работает корректно в этих
случаях, как показано на Рисунке 9.5.
Таблица 9.5. Заполнение Последующих Строк в Матрице Распределения Тестовых
Сценариев.
Шаг
В3
В3
Переменная
Аэропорт
вылета
Дата вылета
Т1
Верный
код
аэропорта
Верная
дата
(вручную)
Т2
Верный
город и
штат
Т3
Верный
город и
страна
Верная
дата (из
календаря)
Прошлая
Т4
Неверный
Т5
Несуществую
щий
Т6
Пустое поле
Верный
код
аэропорта
Текущая
Верный код и
штат
Верный
город и
страна
Пустое поле
Неверная
Верная дата
(вручную)
Верная,
через
год
Верная дата
(из
календаря)
Часто нам нужно проверять варианты, установленные нами несколько шагов назад.
Например, при установке даты прибытия, нам нужно быть уверенными, что эти варианты
соответствуют датам вылета, установленным ранее (см. Таблицу 9.6). Также, при
установке числа пассажиров, нам нужно рассмотреть разные комбинации количества
взрослых и детей, как показано в Таблице 9.7. Вариант 0/0 не допустим, так что в
качестве второго выбора мы добавили 1/max, чтобы добавить случай с максимально
допустимым числом детей. Случай 0/1 возможно вызовет сообщение, объясняющее
условия, при которых ребенок может путешествовать без сопровождения взрослых.
Таблица 9.6. Варианты для Даты Прибытия.
Шаг
В3
Переменная
Дата вылета
Т1
Верная
дата
(вручную)
Т2
Верная
дата (из
календа
ря)
Т3
Прошлая
Т4
Текущая
Верная,
через
год
Верная,
через
неделю
Т5
Неверная
Т6
Пустое
поле
Верная дата
(вручную)
Верная
дата (из
календаря
)
Верная
Верная дата,
(из
календаря)
дата
(вручную)
Таблица 9.7. Варианты для Количества Взрослых и Детей.
Шаг
В3
Переменная
Число
путешествующих
взрослых
Т1
1
Т2
2
Т3
0
Т4
1
Т5
0
Т6
Максимально
допустимое
В3
Число
0
1
1
0
2
1
1
165
путешествующих
детей
Максимально
допустимое
Иногда число вариантов для тестирования меньше, чем число колонок, как показано
в Таблице 9.8. Заполните оставшиеся ячейки наиболее популярными вариантами или
немного другими, но верными вариантами.
Таблица 9.8. Варианты для Идентификатора и Пароля.
Шаг
В10
Переменная
Идентификатор
пользователя
Т1
Верный
В10
Пароль
Правиль
ный
Т2
Неверный
Т3
Несуществу
ющий
Т4
Пустое
поле
Верный
Неправиль
ный
Правильн
ый
Верный
Неверный
Верный
Пустое
поле
Правиль
ный
Правильный
Т5
Верный,
максимально
допустимое колво символов
Т6
Неправильный
Иногда существует больше вариантов, чем изначально заданное число колонок.
Перед тем как добавить новую колонку, проанализируйте, могут ли некоторые варианты
быть перемещены на следующую строку? Так как некоторые варианты вызывают
сообщения об ошибке, мы можем переместить некоторые верные варианты на строку
вторых вариантов. В Таблице 9.9. вариант Два слова не подходит в ту же строку с
остальными шестью вариантами, но т.к. Длиннее чем допустимо - это один из неверных
вариантов, в тестовом сценарии мы можем повторно ввести фамилию, состоящую из двух
слов.
Таблица 9.9. Семь Вариантов для Фамилии (Седьмой Вариант Перемещен на Строку
Вторых Вариантов).
Шаг
В11
Переменная
Фамилия
Т1
Стандартная
Т2
Максималь
ная длина
Т3
С
апострофом
Т4
Длиннее
чем
допустимо
Два слова
Т5
Один
символ
Т6
Пустое
поле
Стандарт
ная
Некоторые строки заполнены не для каждой колонки. В нашем примере строки с
информацией о втором пассажире используются только в тестовых сценариях, где
количество пассажиров больше одного. Строки с информацией о третьем пассажире
используются только в тестовых сценариях, где количество пассажиров больше двух, и
т.п. (см. Таблицу 9.10). Для тестовых сценариев, в которых много пассажиров, нам не
нужно тестировать все негативные случаи для каждого пассажира. Если некоторые
необычные варианты работают корректно для первых трех пассажиров, то возможно они
будут работать для остальных тоже.
Некоторые ячейки могут быть не заполнены, когда создается тестовый сценарий. В
тестовом сценарии, в котором мы тестируем «Прибытие на следующий день», мы не знаем
заранее, сколько остановок будет в рейсе, поэтому строки относительно выбранных мест
для вторых и далее отрезков могут быть заполнены во время тестирования, если
выбранный рейс будет состоять из более одного отрезка пути (см. Таблицу 9.11).
Таблица 9.10. Заполнение Информации о Пассажире в Зависимости от Числа Пассажиров
в Определенном Тестовом Сценарии
Шаг
В3
Переменная
Число
путешествующих
взрослых
Т1
1
Т2
2
Т3
0
Т4
1
Т5
0
Т6
Максималь
ное
В3
Число
0
1
1
0
2
1
1
166
путешествующих
детей
В11
В11
Имя
Фамилия
Стандарт
ное
Стандарт
ная
Правиль
ное
Максима
льное
Максима
льная
В11
Пол
М
Ж
В11
Дата Рождения
Верная
Будущая
В11
Имя второго
пассажира
Пустое
поле
М
Неверна
я
Длиннее
чем
допусти
мо
Два
слова
М
Прошлы
й год
Правиль
ное
Пустое
поле
С
пробелом
Стандарт
ное
Один
символ
Пустое
поле
Ж
Более 20
лет
назад
Верная
Стандартн
ое
Пустое
поле
Ж
Верная
В11
Пол второго
пассажира
М
Ж
В11
Дата рождения
второго
пассажира
Будущая
Неверна
я
Верная
Верная
Верная
Стандарт
ное
Стандартн
ое
Два
слова
Стандартн
ая
М
Ж
Верная
Верная
Фамилия второго
пассажира
Максима
льная
Верная
Максима
льное
Правиль
ное
Один
символ
Верная
Длиннее
чем
допусти
мо
Один
символ
Длиннее
чем
допусти
мо
Один
символ
Пустое
поле
Ж
Прошлы
й год
В11
Верная
Стандарт
ное
Максима
льное
Правиль
ное
Длиннее
чем
допусти
мо
Стандарт
ное
С
апостро
фом
С
апостро
фом
В11
Имя третьего
пассажира
Максима
льное
В11
Фамилия третьего
пассажира
Максима
льная
В11
Пол третьего
пассажира
Дата рождения
третьего
пассажира
Имя четвертого
пассажира
Фамилия
четвертого
пассажира
Пол четвертого
пассажира
Дата рождения
четвертого
М
С
пробело
м
С
апостро
фом
Ж
Верная
Верная
В11
В11
В11
В11
В11
Пустое
поле
С
пробелом
Пустое
поле
Два слова
М
Верная
Верное
Верное
В Верное
Верное
Ж
М
Верная
Верная
167
В11
В11
В11
В11
В11
В11
В11
В11
пассажира
Имя пятого
пассажира
Фамилия пятого
пассажира
Пол пятого
пассажира
Дата рождения
пятого пассажира
Имя шестого
пассажира
Фамилия шестого
пассажира
Пол шестого
пассажира
Дата рождения
шестого
пассажира
Верное
Верное
В Верное
Верное
М
Ж
Верная
Верная
Верное
Верное
В Верное
Верное
Ж
М
Верная
Верная
Таблица 9.11. Заполнение Мест в Зависимости от Числа Пассажиров в Определенном
Тестовом Сценарии и Числа Остановок в Выбранном Рейсе.
Шаг
В3
Переменная
Число
путешествующих
взрослых
Т1
1
Т2
2
Т3
0
Т4
1
Т5
0
Т6
Максималь
ное
В3
Число
путешествующих
детей
0
1
1
0
2
1
1
Правиль
ное
Самый
дешевый
Правиль
ное
Прибыти
е на
след.
день
Прибыти
е на
след.
день
У
прохода
Максималь
ное
В5
Рейс вылета
Прямой
Правиль
ное
1 ост.
В7
Рейс прибытия
Прямой
1 ост.
Макс. колво
остановок
Самый
дешевый
В13
Места в рейсе
вылета для
1отрезка пути
Окно
3 места
рядом
По
умолчанию
2 места
вместе,
3-е в
след.
ряду
В13
Места в рейсе
вылета для
2отрезка пути
Только 1
место
выбрано
В13
Места в рейсе
вылета для
3отрезка пути
Все места
около
окна в
разных
рядах
По
умолчани
ю
Правильное
Макс. колво
остановок
Прибытие
через 2
дня
Прибытие
через 2
дня
Только 2
места
выбраны
Шаг 4: Определение Значений Переменных
На четвертом шаге Вы заменяете неопределенные варианты, такие как «очень
длинная фамилия» или «длинный номер телефона с ext. (дополнительным номером)» на
действительные значения, например «Georgiamistopolis» и «011-48 (242) 425-3456 ext.
1234» соответственно.
На этом шаге мы также разделяем все тестовые сценарии из Матрицы Распределения
Тестовых Сценариев, создавая отдельную таблицу для каждого тестового сценария.
168
Для тестового Сценария 1 сценария использования Бронирование рейса, матрица
тестового сценария показана в Таблице 9.12. В дополнении к строкам из Матрицы
Распределения Тестовых Сценариев мы добавили строки, представляющие действия.
Например, В3 Поиск рейсов означает, что мы выбираем действие, инициирующее поиск
рейсов. Обычно это подразумевает нажатие мышкой на кнопке с названием
соответствующего действия. Однако на этой стадии мы пытаемся избегать решений о том,
будет ли это нажатие на кнопку, ссылку или опцию меню. Позже дизайнер
пользовательского интерфейса решит, что лучше использовать в данном случае.
Для строк, представляющих входных переменные, ожидаемый результат обычно
либо «принято», либо «отклонено». Для строк, представляющих действия, ожидаемый
результат – это чаще всего появление нового экрана или диалогового окна.
Таблица 9.12. Тестовый Сценарий.
Шаг
Переменная
Т1
В3
В3
В3
EWR
39166
LAX
39179
1
Принято
Принято
0
Принято
В3
Аэропорт вылета
Дата вылета
Аэропорт
прибытия
Дата прибытия
Число
путешествующих
взрослых
Число
путешествующих
детей
Поиск рейсов
Ожидаемый
результат
Принято
Принято
Принято
Список рейсов
В5
Рейс вылета
В7
Рейс прибытия
В10
Идентификатор
В10
В10
Пароль
Вход в систему
В11
В11
В11
В11
В11
Имя
Фамилия
Пол
Дата рождения
Подтверждение
В11
Места в рейсе
вылета
Подтверждение
Поиск
рейсов
Выбор
прямого
рейса
Выбор
прямого
рейса
Пользоват
ель 1
Пароль
Вход в
систему
John
Smith
M
Верная
Подтверж
дение
Окно
Подтверж
дение
Окно
Экран выбора
мест
Принято
Подтверж
дение
Visa
Экран выбора
мест
Принято
41234567
89012340
01/01/200
9
John Smith
1 Main St.
New York
NY
Принято
В3
В3
В3
В11
В11
В14
В14
В14
В14
В14
В14
В14
В14
Места в рейсе
прибытия
Подтверждение
Тип кредитной
карты
Номер
кредитной карты
Дата окончания
срока действия
Название карты
Адрес
Город
Штат
Список рейсов
Экран входа в
систему
Принято
Принято
Экран
пользователя
Принято
Принято
Принято
Принято
Экран выбора
мест
Принято
Принято
Принято
Принято
Принято
Принято
169
Фактический
результат
Удачный/
неудачный
Комментарии
В14
В14
В14
Почтовый
индекс
Страна
Подтверждение
10001
Принято
USA
Подтверж
дение
Принято
Номер
подтверждения
Этот документ будет отдан тестерам. Тестер будет идти по колонкам 2 и 3, и
записывать результаты в колонки 5 и 6.
При создании сценариев (алгоритмов) из тестовых сценариев, Вы можете
предоставлять информацию дизайнерам сценариев использования с целью улучшения
требований. Это может помочь Вам рано обнаружить пробелы в требованиях.
9.2 Бизнес-правила
Предыдущий пункт часто ссылался на требуемую длину поля или допустимые
значения для некоторых параметров. Откуда Вы можете знать минимально и максимально
допустимые величины полей? Это требование может поступить от различных источников.
Иногда оно исходит от самого бизнес-аналитика или заказчика. Например, если мы
вводим Dun & Bradstreet номер, который определяет компанию, этот номер должен быть
всегда длиной 9 символов. Это бизнес-требование.
Достаточно часто требование не поступает ни от заказчика, ни от пользователя. Если
Вы спросите заказчика, насколько большим должно быть поле фамилии, он может
сказать, что ему неважно и попросить Вас решить это. В этом случае, определение длины
переменной – это больше стадия проектирования, чем стадия требований.
Мы назовем такой тип требований бизнес-правилами. Их отделение от остальных
требований обеспечивает дополнительную гибкость, т.к. бизнес-правила могут меняться
со временем. Например, Номер Счета при разработке системы был 8 цифр, а год спустя
сменился на 9.
Существует вопрос в том, где бизнес-правила должны быть документально
оформлены. Один из вариантов – добавить этот тип требований в пункт Special
Requirements (Специальные Требования) в документ Сценариев Использования (Use
Cases). Это возможно, если эти правила относятся к сценариям использования. Другой
вариант – это справочник или словарь данных.
Еще одна неплохая возможность - создать отдельный документ Business Rules (BR,
Бизнес-Правила). Вы можете определить BR как отдельный тип требований. Тогда шаг
сценария использования может иметь такую формулировку: «Система проверяет
Информацию Счета согласно BRnnn», где nnn – это номер бизнес-правила. Таким образом,
бизнес-правила включаются в контекст, что очень полезно для разработчиков. Используя
подход OOAD (Object Oriented Analysis and Design – Объектно-Ориентированный Анализ и
Проектирование), они знают, в каком методе для конкретного класса нужна проверка.
9.3 Создание Нового Типа Документов
Тестовый Сценарий (Test Case) не является частью стандартного шаблона
RequisitePro. Нам нужно создать новый тип документов. Выполните следующие действия:
1. Создайте требуемый шаблон документа в Microsoft Word.
2. Сохраните его как шаблон с расширением .dot, например testcases.dot.
3. Создайте текстовый файл, содержащий три линии:
Title (Заголовок).
Description (Описание).
Name (Название файла, содержащего шаблон).
4. Сохраните текстовый файл с тем же названием, что и шаблон, но с расширением
.def, например testcases.def.
Пример .def файла:
Test Cases Outline
The outline to be used for deriving Test Cases from Use Cases.
testcases.dot
5. Положите .dot и .def файлы в каталог ProgramFiles\Rational\RequisitePro\outlines.
170
6. Откройте диалоговое окно Project Properties (Свойства Проекта), нажав правой
кнопкой мышки на названии проекта и выбрав Properties (Свойства), либо
выделив название проекта и выбрав File>Properties (Файл>Свойства).
7. Выберите закладку Document Types (Типы Документа).
8. Нажмите кнопку Add (Добавить).
9. Заполните поля диалогового окна Document Type (Тип Документа), как показано
на Рисунке 9.2:
Name (Название): Это название появится в списке доступных типов документов
в диалоговом окне New Documents (Новые Документы) когда документ будет
создаваться.
Description: Любое описание, отражающее смысл.
File Extension: Вы можете выбрать любое расширение, но по смыслу (например
TCD для документа Test Case Design - Проектирование Тестовых Сценариев).
Рисунок 9.2. Определение нового типа документов.
10. Выберите Default Requirement Type (Тип Требования по Умолчанию).
Если Вы уже добавили Test Case (Тестовый Сценарий) в список типов документов,
используемых в проекте (с помощью описанного в пункте 9.3 метода), выберите
его в списке.
Если Вы еще не создали требование тестового сценария, выполните следующие
действия для его создания:
а. Нажмите кнопку New (Новый).
б. Заполните поля диалогового окна Requirement Type (Тип Требования), как
показано на Рисунке 9.3:
Name (Название): Test Case.
Requirement Tag Prefix (Префикс Требования): TC.
Requirement Color (Цвет Требования): Оставьте по умолчанию Синий (Blue),
или выберите другой.
Requirement Style (Стиль Требований): Оставьте по умолчанию Двойное
Подчеркивание (Double Underline), или выберите другой.
11. Выберите из списка Outline, Name название шаблона (он был определен в первой
линии файла testcases.txt).
12. Нажмите ОК в диалоговом окне Document Type (Тип Документа).
171
Рисунок 9.3. Добавление нового типа требований.
9.4 Добавление Сценариев (Алгоритмов) и Тестовых Сценариев
После добавления типа документа мы можем создать сам документ. Хорошей
практикой считается создать каждый документ в определенной папке. Тем не менее, у нас
нет папки для сценариев (алгоритмов) и тестовых сценариев. Мы можем создать две
отдельные папки для них, или же положить эти документы в одну папку.
Создание Новой Папки
Создадим новую папку. Мы можем создать отдельные папки для сценариев
(алгоритмов) и тестовых сценариев, либо одну папку для хранения обоих документов.
Для создания новой папки выполните следующие действия:
1. Правой кнопкой мышки нажмите на названии проекта и выберите New >Package
(Новая>Папка).
2. Заполните поля диалогового окна, как показано на Рисунке 9.4.
3. Нажмите ОК.
Рисунок 9.4. Создание новой папки.
Создание Документа
Сейчас мы можем создать документ в этой папке. Выполните следующие действия:
1. Правой кнопкой мышки нажмите на папке Scenarios и Test Cases и выберите
New>Document (Новый>Документ).
В Document Type (Тип Документа), выберите из списка название, которое было
назначено в диалоговом окне Document Type (Тип Документа - см. Рисунок 9.2).
2. Используйте документ как шаблон для создания тестовых сценариев.
172
Рисунок 9.5. Настройка свойств документа.
Добавление Требований из Explorer (Проводника)
Пункт 5.4 описывает, как можно извлечь требования из документа. Данный же пункт
описывает, как добавлять требования из Explorer (Проводника):
1. Правой кнопкой мышки нажмите на папке Supplementary Requirements
(Дополнительные
Требования)
и
выберите
New>Requirement
(Новое>Требование).
2. Заполните поля диалогового окна Requirement Properties (Свойства Требования),
как показано на Рисунке 9.6:
Type (Тип): Выберите SC:Scenario из списка.
Name (Название): Вы можете назвать сценарий, используя номер сценария
использования и последовательность потоков (например UC1, A6, A7).
Рисунок 9.6. Заполнение диалогового окна Requirement Properties (Свойства Требования)
для сценариев.
Введенный сценарий появится в Explorer (Проводнике), как показано на Рисунке 9.7.
Мы можем ввести тестовые сценарии таким же образом. Нам нужно определить
названия каждому тестовому сценарию. Мы можем назвать их номером сценария и
последующего номера тестового сценария.
SC1 TC5 (сценарий 1, тестовый сценарий 5).
Либо можем включить номер сценария использования в название:
UC1, SC1, TC5 (сценарий использования 1, сценарий (алгоритм) 1, тестовый
сценарий 5).
173
Рисунок 9.7. Сценарии (алгоритмы) в Explorer (Проводнике).
9.5 Установка Трассировки
Соответствие между сценариями использования (use cases) и сценариями
(алгоритмами, scenarios) – это отношение одно-ко-многим или многие-ко-многим в
зависимости от того, что мы сохранили в качестве требований сценария использования.
Если мы сохранили полный сценарий использования, один сценарий использования будет
соответствовать многим сценариям (одному или более). Если мы сохранили каждый поток
или каждый шаг как отдельное требование, отношения между сценариями использования
и сценариями будут многие-ко-многим.
Как было рассмотрено в предыдущих главах, для установки трассировки (связи) нам
нужно создать Матрицу Трассировки (Traceability Matrix, см. Рисунок 9.8). Затем мы можем
установить трассировку путем расстановки стрелок в определенные ячейки, как показано
на Рисунке 9.9.
Рисунок 9.8. Диалоговое окно View Properties (Свойства Представления) для создания
Матрицы Трассировки (Traceability Matrix) между сценариями использования (use cases) и
сценариями (алгоритмами, scenarios).
174
Рисунок 9.9. Трассировка между сценариями использования (use cases) и сценариями
(алгоритмами, scenarios).
Другой путь установки трассировки (связей) – это настройка ее из диалогового окна
Requirement Properties (Свойства Требования). Создадим тестовый сценарий из Explorer
(Проводника) таким же образом, как мы создавали сценарии. Для установки трассировки
при создании требования выполните следующие действия:
1. В диалоговом окне Requirement Properties (Свойства Требования), как показано
на Рисунке 9.10, выберите закладку Traceability (Трассировка).
Рисунок 9.10. Диалоговое окно Requirement Properties (Свойства Требования) для
тестовых сценариев.
2. Нажмите Add (Добавить) напротив поля From (Из), как показано на Рисунке 9.11.
175
Рисунок 9.11. Диалоговое окно Requirement Properties (Свойства Требования) для
тестовых сценариев.
3. Выберите сценарий, из которого трассируется тестовый сценарий, как показано
на Рисунке 9.12.
Рисунок 9.12. Установка трассировка из диалогового окна.
4. Нажмите ОК в диалоговом окне Trace From Requirement(s).
После настройки трассировки (связей) между сценариями и тестовыми сценариями
мы можем создать Дерево Трассировки (Traceability Tree), показывающее все пути
перехода требования от сценариев использования, к тестовым сценариям, как показано
на Рисунке 9.13. Создание Дерева Трассировки было рассмотрено в Главе 6 «Разработка
Документа Концепции (Vision)».
Рисунок 9.12. Дерево Трассировки (Traceability Tree) из сценариев использования.
176
9.6 Заключение
Эта глава представляет метод извлечения функциональных тестовых сценариев (test
cases) из сценариев использования (use cases). Несколько преимуществ этого подхода:
Тестовые сценарии получаются с использованием более автоматического
подхода.
Уход от дублирования тестовых сценариев.
Достигается больший охват тестового пространства.
Легкость мониторинга тестового процесса.
Легкость распределения работы между тестерами.
Легкость регрессионного тестирования.
Раннее обнаружение пропущенных требований.
Созданные Вами тестовые сценарии могут быть использованы для ручного
тестирования, также как и для автоматического тестирования с использованием таких
инструментов, как IMB Rational Robot или IBM Rational Functional Tester.
Этот подход применяется к функциональным требованиям. Следующая глава
описывает, как тестировать нефункциональные требования.
Ссылки
[HEU01a] Heumann, Jim. From Use Cases to Test Cases: Ensuring Quality from the Beginning,
RUC, 2001.
[HEU01b] Heumann, Jim. “Using Use Cases to Create Test Cases.” The Rational Edge, June
2001.
177
ГЛАВА 10
Создание
Тестовых Сценариев (Test Cases)
из Дополнительных Требований
В предыдущей главе был представлен метод, который может применяться к любому
сценарию использования (use case) для получения тестовых сценариев (test cases).
Данная глава рассматривает получение тестовых сценариев из дополнительных
требований (см. Рисунок 10.1). Однако что касается дополнительных требований, то для
них не существует единого подхода, т.к. эти требования различны по своей природе и их
тестирование требует довольно разных методик. Эта глава представляет следующие
методы создания тестовых сценариев:
Выполнение выбранных тестовых сценариев в различных программных средах.
Добавление дополнительной проверки во все сценарии использования.
Проверка и обновление определенных сценариев использования.
Выполнение задач.
Список проверок.
Анализ.
Тестирование по принципу «Стеклянного Ящика».
Автоматическое тестирование.
Эта глава также охватывает использование IBM Rational Robot и IBM Rational Test
Manager для автоматического тестирования. Один из самых последних инструментов IBM,
заменивший предыдущие версии Test Manager, называется ClearQuest Test Manager. Эти
инструменты могут также использоваться для функционального тестирования, а не только
для тестирования производительности, описанного в данной главе.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 10.1. Извлечение тестовых сценариев (test cases) из дополнительных
требований.
178
10.1 Выполнение Выбранных Тестовых Сценариев в Различных
Программных Средах
Некоторые требования указывают, что приложение должно работать в различных
средах:
Веб-приложение должно запускаться под браузерами: Internet Explorer (версии 6.0 и
выше) и Netscape (версии 6.0 и выше).
Наилучший подход к работе с таким типом требований - это выбрать некоторый
большой тестовый сценарий (в нашем случае, им может быть один из тестовых сценариев
относительно основного потока сценария использования Бронирование рейса) и
выполнить его в различных программных средах. Это означает, что один тестовый
сценарий будет полностью пройден с использованием сначала браузера Internet Explorer,
а затем Netscape.
Достаточно часто требование относится к операционным системам, на которых
должно работать приложение:
Система должна запускаться на операционных системах: Windows XP, Windows и
Vista Solaris 10.
В случае Интернет-приложений операционная система не столь важна, как в случае
настольных приложений или приложений клиент/сервер.
Как вариант этого случая – если необходимо протестировать приложение в той же
программной среде, но с разными настройками:
Система должна отображать данные согласно формату, хранимому в настройках веббраузера.
В этом случае тестирование включает следующие шаги:
1. Проверить настройки веб-браузера.
2. Запустить полный тестовый скрипт на этих настройках.
3. Изменить настройки веб-браузера (например,
на
отображения даты).
4. Запустить полный тестовый скрипт на новых настройках.
Французский
формат
Рисунок 10.2. показывает этот подход. Выбранный сценарий тестируется в
различных программных средах, так что у нас есть один тестовый сценарий для каждой
программной среды.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 10.2. Выбранный сценарий тестируется в различных программных средах.
10.2 Добавление Дополнительной Проверки во Все Сценарии
Использования
Многие требования описывают появление или поведение некоторых элементов
управления пользовательского интерфейса. Несколько примеров:
179
На каждой странице кнопка Next (Далее) должна определять основной сценарий
работы приложения.
На формах ввода данных система должна показывать, какие поля являются
обязательными для заполнения, с помощью звездочки перед обязательным полем.
Система должна показывать всплывающее окно с календарем, когда пользователь
вводит даты, такие как дата рейса, дата пребывания в гостинице и дата аренды
автомобиля.
Поля ввода на одной странице должны быть выровнены вертикально.
При открытии диалогового окна акцент должен быть на первом поле ввода.
Для каждого неверного ввода пользователем система должна отображать
соответствующее сообщение об ошибке объясняющее, какого формата должно быть
вводимые данные.
Денежные расчеты должны выполняться и храниться с точностью до двух десятых.
Каждая функциональная особенность системы должна быть описана в он-лайн
справочнике, доступному из меню на каждой странице.
На страницах, где приводятся данные пользователя, должна быть ссылка на
страницу с политикой конфиденциальности.
Наилучший способ осуществлять тестирование этих функциональных особенностей –
добавить проверку ко всем тестовым сценариям, которые уже созданы для различных
сценариев использования. Так как извлеченные из сценариев использования тестовые
сценарии охватывают каждую используемую в данном приложении экранную форму, мы
можем просто добавить определенные проверки при посещении каждой экранной формы
в первый раз. Рисунок 10.3. показывает, что все тестовые сценарии обновляются
определенными дополнительными требованиями.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 10.3. Дополнительные проверки, добавленные во все тестовые сценарии.
Каждый раз при появлении нового диалогового окна или экранной формы нам нужно
вводить список проверок в тестовый сценарий.
Некоторым требованиям нужна проверка только однажды для страницы, а другие
требуют тестирование всех элементов управления определенного типа. Несколько
примеров:
Одна проверка для страницы:
o Присутствует ли кнопка Next (Далее), представляющая основной сценарий
работы приложения?
o Существуют ли страницы с многочисленными полями на них? Выровнены ли
эти поля по вертикали?
o Доступен ли справочник из меню?
Проверка определенных элементов управления:
o Есть ли у всех обязательных полей звездочка?
o Доступен ли всплывающий календарь для каждого поля ввода даты?
180
o
Все поля ввода валюты принимаются и отображаются в формате до двух
десятых?
10.3 Проверка и Обновление Определенных Сценариев
Использования
Даже некоторые из требований, описанные в Supplementary Specification
(Дополнительной Спецификации), связаны с некоторыми определенными сценариями
использования. Так может случиться, если эта часть функциональности не относится к
главному сценарию использования, но играет административную роль или роль
сопровождения. Как пример рассмотрим требования относительно защиты и доступ с
защитой паролем к некоторым частям приложения:
Должен быть предоставлен пароль для доступа к экранным формам администратора.
Для предоставления своих услуг представители гостиниц, агенты по найму
автомобилей и представители авиалиний должны войти в систему, используя свои ID
(идентификаторы) и пароли.
Пользователи должны выбирать свой ID и предоставлять пароль при покупке билета.
На каждом из этих требований мы можем добавить пару шагов к определенному
сценарию использования. Если процедура входа в систему сложна, мы можем
рассматривать ее как отдельный сценарий использования, который будет включен в
остальные сценарии использования.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 10.4. Некоторые дополнительные требования влияют на сценарии
использования, а также на все сценарии (алгоритмы) и тестовые сценарии, извлеченные
из них.
10.4 Выполнение Задач
Довольно часто нам нужно выполнить действие, описанное в требовании. Во многих
случаях задача не требует создания формальных сценариев (алгоритмов) и тестовых
сценариев.
Лог ошибок, содержащий информацию обо всех критических ошибках, должен быть
доступен системному администратору через Интернет, чтобы он мог проверить его
удаленно в любое время.
Для тестирования этой функциональной особенности кто-то будет входить в систему
через Интернет и проверять, есть ли у него/нее доступ к логу ошибок.
Иногда требования относятся к среднему времени, требуемому на выполнение задач:
Представитель Службы Услуг должен иметь возможность обучиться пользованию
системой за час.
Среднее время процедуры бронирования номера в гостинице должно быть не более
десяти минут.
181
В этих случаях более выгодно будет выполнять задачи тремя независимыми
тестерами, и затем сравнивать временные значения.
Другие тесты могут быть выполнены одним и тем же лицом, но несколько раз подряд,
чтобы проверить, действительно ли полученные результаты неизменны:
В случае отказа системы резервная система должна позволять выполнение операций
в течение 30-ти секунд.
Среднее время восстановления должно быть менее часа.
Система должна быть работоспособной в течение одной минуты после загрузки.
Вполне нормально выполнять только однажды тесты, требующие много времени,
пока мы не обнаружим некоторые проблемы:
Время развертывания на новой версии WebSphere Application Server должно занимать
не более чем один день.
Если тестовая установка системы на новой версии WAS занимала 15 часов, то нет
необходимости проверять это еще раз. Но если первый тест занял 40 часов, мы должны
проанализировать причину и пройти тест заново после устранения проблемы.
Другой пример требования, которое может быть проверено простым выполнением
задачи:
Пользовательский интерфейс не должен содержать компонентов, препятствующих
автоматическому тестированию с использованием IBM Rational Functional Tester.
Некоторые требования нуждаются в мини-сценарии использовании, например
подсчет количества нажатий для получения доступа к определенной функциональности.
Функциональность бронирования билета на самолет должна быть доступна с
домашней страницы.
Функциональность бронирования автомобиля должна быть доступна после не
более чем одного щелчка с домашней страницы.
10.5 Список Проверок
Некоторые требования не нуждаются в сложном тестировании, так что Вы можете
просто проверить, реализованы ли они. Например:
В качестве базы данных должен быть использован Oracle.
Был ли использован Oracle или нет – просто пометьте в списке проверок.
Некоторые другие примеры такого рода тестирования могут включать следующее:
Все системные ошибки должны быть записаны и быть доступными для
администратора.
Все транзакции (покупка билета, выполнение заказа, изменение деталей заказа и
удаление заказа) должны быть записаны и быть доступными для администратора.
Система должна быть основана на архитектуре J2EE.
Если архитектура требует сервер приложения, должен быть использован IMB
WebSphere.
Руководство Администратора должно быть доступно в формате PDF.
Для основной функциональности должны присутствовать отдельные закладки.
10.6 Анализ
Некоторые требования не нуждаются в большом тестировании, но требуют
небольшого анализа. Часто достаточно ментального выполнения задачи без физической
реализации теста.
Для использования системы пользователи не должны обладать специальными
техническими навыками (кроме умения пользоваться браузером).
Система должна быть доступной 24 часа 7 дней в неделю.
В процессе анализа последнего требования, мы можем задать следующие вопросы:
Существует ли что-то, препятствующее приложению работать постоянно?
182
Существует ли управление расписанием работы, которое
приложение недоступным на некоторый период времени?
может
сделать
Многие функциональные особенности такого типа требуют анализа архитектуры.
Имеет смысл включить архитектора системы в этот анализ:
Не должна требоваться установка на клиентском рабочем месте. Все системные
обновления и новые релизы должны осуществляться на сервере.
Система должна автоматически бронировать билет с Airline Reservation System без
необходимости вмешательства человека.
Смена базы данных системы в будущем не должно требовать перезаписи логики
приложения.
Некоторый архитектурный анализ может поддерживаться простой демонстрацией:
Главная функциональность системы (бронирование рейса, покупка билета на
самолет, бронирование номера в гостинице, бронирование автомобиля) должна быть
отражены в компонентах, которые могут быть использованы в приложении клиент/сервер
(не через Интернет).
Может быть создано очень простое тестовое клиентское приложение, которое
доказывает, что компоненты могут использоваться в других приложениях
10.7 Тестирование по Принципу «Стеклянного Ящика»
Часть тестирования должно быть выполнено со знанием кода приложения или других
составных частей приложения. Это называется тестированием по принципу «Стеклянного
Ящика» или структурным тестированием.
При выводе списка рейсов, система не должна пропускать прямые рейсы или рейсы с
одной остановкой.
Для проверки этого требования нам нужно напрямую получить доступ к базе данных
и сравнить результаты со списком, полученным в нашей системе.
Довольно часто тестирование требует проверки правильности применения
определенных алгоритмов:
Список рейсов, возвращаемый системой после поиска, должен содержать рейсы,
вычисленные с помощью алгоритма Dijkstra’s Shortest Path
10.8 Автоматическое Тестирование
Автоматическое тестирование очень полезно при проверке производительности и
надежности требований, таких как следующие:
Среднее время ответа системы должно быть менее двух секунд.
Система должна обрабатывать 1000 процедур бронирования билетов в минуту.
Система должна обслуживать 5000 пользователей одновременно.
Среднее время между состояниями неработоспособности должно быть, по крайней
мере, 20 часов.
Система может быть недоступна не более чем одну минуту за 24 часа
Для тестирования производительности и надежности, нам не обязательно
автоматизировать все тестовые сценарии. Мы можем выбрать от одного до трех тестовых
сценариев. Стоит выбрать тестовый сценарий, представляющий наиболее популярный
сценарий (алгоритм), а также самую длинную операцию. В нашем примере основной
поток сценария использования Бронирований рейса - наиболее популярный, и в то же
время он содержит наиболее длинную процедуру (поиск рейсов). Так как бронирование
автомобилей и номеров гостиниц также используется довольно часто и содержит сложные
процедуры, стоит тоже включить их в автоматическое тестирование.
Мы можем запустить тот же скрипт много раз с различными параметрами. Два
наиболее важных параметра – это номера пользователей и номера итераций. Итерации
отображаются последовательно. Количество пользователей определяет, как много
операций выполняется одновременно.
Для анализа последствий одновременного доступа определенного количества
пользователей тот же самый скрипт должен быть выполнен на разном количестве
183
пользователей, например – на 1, 10, 1000 и 1000. Фактические значения могут
изменяться в зависимости от приложения и требуемого максимального количества
пользователей.
Для тестирования среднего времени между состояниями неработоспособности мы
должны запустить систему на долгое время – по крайней мене на 48 часов.
Некоторые вопросы, на которые могут быть получены ответы при использовании
автоматического тестирования:
Каково время ответа при нормальных условиях?
Как много пользователей может поддерживать система, перед тем как становится
недоступной?
Как система ведет себя при максимальном количестве пользователей?
Если количество пользователей больше чем максимально допустимое, у системы
снижается производительность, или она становится неработоспособной?
Как производительность и надежность системы зависят от ресурсов системы
(доступной памяти, дискового пространства)?
Как производительность системы зависит от времени дня (вечер по сравнению с
утром, выходные по сравнению с буднями)?
Автоматическое тестирование также полезно для функционального регрессионного
тестирования. В этом случае стоит создать скрипты для многих сценариев.
Основные инструменты для тестирования представляет IBM: Rational Robot, Rational
Test Manager, Rational ClearQuest Test Manager, Rational Functional Tester и Rational
Performance Tester. В качестве примера, следующий пункт показывает, как создавать и
выполнять скрипты, используя Rational Robot и Rational Test Manager.
10.9 Использование Robot и Test Manager для Автоматического
Тестирования
IBM Rational Robot [IBM03a] может использоваться для разработки двух типов
скриптов:
Скрипты пользовательского интерфейса для функционального тестирования (GUI
scripts).
Виртуальные сессии пользователей для тестирования производительности (Virtual
session – VU).
IBM Rational Test Manager [IBM03b] – это инфраструктура для планирования,
проектирования, реализации, выполнения, а также оценки тестирования. Мы можем
создать пакет (suite), выполняющий скрипты для многих виртуальных пользователей.
Недавно был выпущен новый инструмент – IBM Rational ClearQuest Test Manager.
Обычный подход к выполнению тестирования заключается в записи скриптов с
помощью Robot, а затем использовании Test Manager (ClearQuest Test Manager) для
планирования и перезапуска этих скриптов.
Запись скрипта VU (Виртуальных Сессий)
Запись скриптов VU (виртуальных сессий) с помощью Rational Robot осуществляется
довольно просто. Выполните следующие действия:
1. Запустите Rational Robot, выбрав All Programs>Rational Software>Rational Robot
(Все Программы>Rational Software>Rational Robot).
2. Введите имя пользователя и пароль, как показано на Рисунке 10.5. Пароль для
администратора был установлен при настройке проекта Rational (см. Главу 4
«Настройка Проекта», Рисунок 4.12).
3. Выберите проект из списка.
4. Нажмите ОК.
5. Нажмите на круг, помеченный как VU, как показано на Рисунке 10.6.
184
Рисунок 10.5. Диалоговое окно Rational Test Login.
Рисунок 10.6. Начальное окно Rational Robot.
6. Назовите сессию, как показано на Рисунке 10.7. Вы можете использовать
название сценария использования (use case), сценария (алгоритма, scenario) или
тестового сценария (test case).
Рисунок 10.7. Выбор названия для сессии.
185
7. Выберите путь к IE в поле Executable (Выполнимый), все остальные поля оставьте
пустыми (см. Рисунок 10.8). Как правило, путь должен быть следующим:
C:\Program Files\Internet Explorer\IEXPLORE.EXE
Рисунок 10.8. Выбор приложения. В случае Интернет-приложений выбирается
запускаемый браузер.
8. Начните запись всех шагов тестового сценария (test case). Появится панель
инструментов Session Record (Запись Сессии). Она содержит четыре иконки, как
показано на Рисунке 10.9:
Stop recording (Остановить запись).
Open Robot window (Открыть окно Robot).
Split session into scripts (Разделить сессию на скрипты).
Open Session Insert toolbar (Открыть панель инструментов Session Insert Вставка Сессии).
Рисунок 10.9. Панель инструментов Session Record (Запись Сессии).
Нажав на иконку «Открыть панель инструментов Session Insert (Вставка Сессии)»,
Вы откроете панель инструментов, показанную на Рисунке 10.10. Она содержит
следующие иконки:
Run (Запуск)
Synchronization point (Точка
Start timer (Запустить таймер)
синхронизации)
Stop timer (Остановить таймер)
Start block (Начать блокировку)
Comment (Комментарии)
Stop block (Остановить блокировку)
Рисунок 10.10. Панель инструментов Session Insert (Вставка Сессии).
9. Если Вы хотите выяснить время, за которое выполняется определенная операция,
запустите таймер, нажав на светло-зеленую иконку (вторая справа) на панели
инструментов Session Insert (Вставка Сессии). Назовите таймер, как показано на
Рисунке 10.11. Остановите таймер, нажав красную иконку (третья справа), когда
операция будет завершена. Когда Вы останавливаете таймер, Вам нужно выбрать
таймер из списка, как показано на Рисунке 10.12, т.к. одновременно может быть
запущено много таймеров.
Рисунок 10.11. Определение названия таймера.
186
Рисунок 10.12. Выбор таймера, который необходимо остановить.
10. Когда Вы закончите с записью скрипта, нажмите темно-синий квадрат на панели
инструментов Session Record - Запись Сессии (первая иконка слева на Рисунке
10.9).
11. Назовите скрипт, как показано на Рисунке 10.13. Вполне нормально, если Вы
введете то же название, которое использовали в сессии на шаге 6.
Рисунок 10.13. Выбор названия для только что записанного скрипта.
12. Нажмите ОК в диалоговом окне Stop Recording (Остановить Запись). Появится
окно с кодом языка VU, как показано на Рисунке 10.14.
Как Запустить Пакет в Rational Test Manager
Test Manager может имитировать ситуации выполнения одновременно большим
количеством пользователей различных задач, отраженных в тестовых скриптах. Тестовый
скрипт может быть следующим:
Сессия, записанная с использование Robot.
Скрипт, импортированный из Quality Architect.
Написанный с помощью Java или Visual Basic, следуя требуемым условиям.
Написанный в любом языке для скриптов (в этом случае должен быть написан
адаптер).
187
Рисунок 10.14. Код записанного скрипта.
Эта глава использует сессию, записанную в Robot. Для создания и запуска тестового
пакета, выполните следующие действия:
1. Запустите Test Manager, выбрав All Programs>Rational Software>Rational Test
Manager (Все Программы>Rational Software>Rational Test Manager), как показано
на Рисунке 10.15.
Рисунок 10.15. Главное окно Test Manager.
2. Если появляется диалоговое окно входа в систему, введите Вашу информацию в
поля User Name (Имя Пользователя) и Password (Пароль).
3. Из главного окна Test Manager, выберите File>Open Suite (Файл>Открыть Пакет).
4. В диалоговом окне New Suite (Новый Пакет) выберите Performance Testing Wizard
(Мастер Тестирования Производительности), как показано на Рисунке 10.16, и
нажмите ОК.
188
Рисунок 10.16. Диалоговое окно New Suite (Новый Пакет).
5. Выберите Local computer, как показано на Рисунке 10.17.
Рисунок 10.17. Performance Testing Wizard - Computers (Мастер Тестирования
Производительности - Компьютеры).
6. Нажмите кнопку Add to List (Добавить к списку).
7. Нажмите кнопку Next (Далее).
8. Выберите скрипты. Вы видите диалоговое окно, показанное на Рисунке 10.18.
9. Нажмите кнопку Add to List (Добавить к списку).
10. Нажмите кнопку Finish (Закончить).
11. Правой кнопкой мышки нажмите на VU User Group 1, как показано на Рисунке
10.19, и выберите Run Properties (Запустить Свойства).
189
Рисунок 10.18. Выбор тестовых скриптов.
Рисунок 10.19. Дерево представления тестового пакета.
12. В диалоговом окне Run Properties of User Group (Запустить Свойства), как
показано на Рисунке 10.20, установите максимальное количество пользователей.
Другими
словами,
установите
количество
одновременных
виртуальных
пользователей, которое Вы хотите имитировать. Нажмите ОК.
13. Правой кнопкой мышки нажмите на иконке, представляющей скрипт (на Рисунке
10.19. она называется Бронирование рейса - Book a flight) и выберите Run
Properties (Запустить Свойства).
Рисунок 10.20. Диалоговое окно Run Properties of User Group, где устанавливается
максимальное количество пользователей.
190
14. В диалоговом окне Run Properties of Test Script, показанном на Рисунке 10.21,
установите количество итераций – как много раз Вы хотите повторить скрипт для
одного и того же пользователя. Нажмите ОК.
15. Сохраните пакет, выбрав File>Save As (Файл>Сохранить как), как показано на
Рисунке 10.22.
16. Запустите пакет, выбрав File>Run Suite (Файл>Запустить Пакет).
Рисунок 10.21. Диалоговое окно Run Properties of Test Script (установление количества
итераций).
Рисунок 10.22. Сохранение пакета.
17. Вы можете настроить количество пользователей для текущего запуска, как
показано на Рисунке 10.23.
191
Рисунок 10.23. Диалоговое окно Run Suite (Запустить Пакет) - установка параметров
для текущего запуска.
Анализ Результатов
Когда закончится тестирование, на экране показывается результат (см. Рисунок
10.24) со статусом выполненных команд. На этом экране Вы видите красные и зеленые
колонки. Зеленые означают успешное прохождение теста, красные – неудачное.
Рисунок 10.24. Отчет со статусом команд, выполненных в ходе успешного запуска
тестирования.
Чтобы увидеть результаты производительности, нажмите на кнопку Perf наверху
экрана. Рисунок 10.25. показывает пример результатов одной итерации для одного
пользователя, а Рисунок 10.26. показывает результаты пяти итераций другого тестового
скрипта. Колонки содержат следующую информацию:
Номер команды.
Идентификатор команды
Число выполнений команды.
Среднее время по всем пользователям (в секундах).
192
Стандартное отклонение (средняя разница времени по отношению к среднему
времени).
Минимальное время.
Пять колонок с процентами: 50, 70, 80, 90 и 95.
Максимальное время.
Рисунок 10.25. Результаты производительности (одна итерация).
Вторая колонка - Идентификатор команды. Она генерируется путем взятия первых
семи символов из названия скрипта и добавления к ним тильды (~) и трехзначного
последовательного номера. Вот почему идентификаторы команды для скрипта
Бронирование рейса (Book a flight) называются «Book a~001», «Book a~002» и т.д.
Мы ожидаем, что число из третьей колонки будет равно числу виртуальных
пользователей, умноженному на количество итераций. Но если полный тестовый пакет
выполняется некорректно, то некоторые скрипты не достигнут этой команды, и
количество выполнений этой команды будет меньше.
Показанный на Рисунке 10.25. результат взят с одной итерации для одного
пользователя, так что все времена равны (среднее, максимальное и минимальное). В
процессе работы, результаты которой показаны на Рисунке 10.26, каждая команда была
выполнена пять раз, поэтому мы видим разницу между максимальным и минимальным
временем. Эти таблицы содержат время от всех ответов системы. Эта информация
бесполезна, т.к. мы не знаем, каким операциям они соответствуют. Более полезно время,
полученное для каждой операции между началом и окончанием таймера, т.к. у нас была
возможность присвоить им названия., отражающие смысл
Рисунок 10.26. Результаты производительности (пять итераций).
Мы можем скопировать информацию из таблицы результатов производительности,
вставить ее в Microsoft Excel и убрать ненужные строки.
193
Таблица 10.1. представляет пример такой таблицы для пяти итераций. Первая
колонка содержит название операции, а остальные колонки – те же, что и в Таблице
10.25. Анализ этих данных показывает, удовлетворительно ли время выполнения
определенных операций.
Таблица 10.1. Сценарии, Выбранные для Тестирования Сценария Использования
Бронирование Рейса.
Операция
Номер
Среднее
Отклонение
Мин
50
70
80
90
95
Макс
Поиск
рейсов
5
5.88
0.69
5.11
5.92
6.09
6.31
6.66
6.84
7.02
Поиск
рейсов
вылета
5
3.06
0.28
2.72
2.91
3.26
3.36
3.4
3.42
3.44
Поиск
рейсов
прибытия
5
3.61
1.97
1.92
2.16
4.68
5.57
6.1
6.37
6.63
Выбор мест
5
3.45
0.38
2.74
3.69
3.7
3.71
3.72
3.73
3.74
Покупка
билета
5
4.57
0.55
4.05
4.23
5.03
5.23
5.25
5.25
5.26
10.10 Заключение
Эта глава представляет восемь методов извлечения тестовых сценариев (test cases)
из дополнительных требований. В большинстве случаев мы имели дело с
нефункциональными требованиями. Дополнительные требования бывают довольно
разными, также как и тип. Поэтому не существует универсального метода для их
тестирования. Нам нужно выбирать соответствующий подход для каждого требования.
Использование автоматического тестирования - очень хорошая помощь при
тестировании требований производительности и надежности. Представленный в пункте
10.9. пример – это простой случай записи сессий IBM Rational Robot и запуска их для
требуемого числа виртуальных пользователей. Более углубленное использование Robot
включает настройку типа записей в зависимости от архитектуры системы, характеристик
генерации скриптов, использование хранилищ данных, а также изменение записанных
скриптов вручную.
Инструменты автоматического тестирования также полезны при
выполнении функциональных тестовых сценариев, как описано в предыдущей главе. И
если функциональное тестирование может быть выполнено вручную, то выполнить
тестирование производительности без этих инструментов практически невозможно.
Тестовые сценарии должны быть приготовлены достаточно рано в проекте, потому
что их создание может породить некоторые вопросы, которые помогут улучшить
требования. Однако фактическое тестирование начинается только после того, как
некоторая часть системы уже спроектирована и разработана. Следующая глава
рассматривает порядок проектирования.
Ссылки
[IBM03a] Rational Robot, User’s Guide, IBM Corporation, 2003.
[IBM03b] Rational Test Manager, User’s Guide, IBM Corporation, 2003.
194
ГЛАВА 11
Объектно-Ориентированное
Проектирование
Данная глава описывает, каким образом собранные до настоящего момента
требования могут выступать в качестве основы для объектно-ориентированного
проектирования системы. Существует много подходов к проектированию, и в этой главе
описан один из таких подходов. Рассмотренный в данной главе подход является общим и
может применяться независимо от архитектуры системы и языка реализации. Тем не
менее, такое высокоуровневое проектирование должно быть усовершенствовано с учетом
взятия во внимание языка программирования и архитектуры системы.
Рисунок 11.1. представляет высокоуровневое видение данного подхода. Для каждого
сценария мы создаем одну диаграмму последовательностей. Одновременно с созданием
диаграмм последовательностей мы создаем классы, которые содержат в себе требуемую
функциональность. Классы, их атрибуты и операции, а также отношения между классами,
отображаются на диаграмме классов.
Пункты 11.2 и 11.3 показывают, каким образом для проектирования можно
использовать два инструмента IBM: Rational Rose и Rational Software Architect.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ИСПОЛЬЗОВАНИЯ)
СЦЕНАРИИ (АЛГОРИТМЫ)
ДИАГРАММЫ
ВЗАИМОДЕЙСТВИЙ
ДИАГРАММЫ КЛАССОВ
Рисунок 11.1. Создание диаграмм проектирования из сценариев.
11.1 Проектирование Системы из Сценариев Использования
(Use Case)
Проектирование может быть выполнено с использованием Универсального Языка
Моделирования - Unified Model Language (UML) – графического языка моделирования,
195
который использует специальную систему обозначений для создания абстрактной модели
системы [BOO04] [BOO05].
Основная задача данного метода - это создание диаграммы последовательностей
для каждого сценария. Одновременно с этим осуществляется формирование классов, а
отношения между классами показываются на диаграмме классов.
При проектировании диаграммы взаимодействий сообщения от действующего лица
(actor) должны идти в класс представления пользовательского интерфейса (boundaryclass). Boundary-класс затем передает сообщения в controller-class, который впоследствии
взаимодействует с определенными классами-сущностями (entity-классы).
Мы будем придерживаться следующей последовательности шагов для каждого
сценария:
1. Получить пару шагов сценария: запрос пользователя и ответ системы.
2. Решить,
какой
boundary-класс
будет
обеспечивать
взаимодействие
с
действующими лицами.
3. Создать название для операции, которая будет позволять действующему лицу
передавать входные значения системе.
4. Разработать аргументы для этой операции. Обычно, на экране для каждого
элемента управления пользовательского интерфейса (UI control) существует один
аргумент. Например, текстовая переменная может представлять поле для ввода, а
Булева переменная может представлять radio-button или checkbox.
5. Решить, какая controller-операция должна обеспечить эту функциональность.
6. Решить, какой controller-класс должен предоставить данную операцию (взять из
существующих классов или создать новый).
7. Разработать аргументы и возвращаемое значение операции (если необходимо,
создать новые entity-классы).
8. Если необходимо, создать в boundary-классе операцию, которая отображает на
экране информацию, полученную от controller-класса.
9. Продолжить выполнение этих пунктов для следующих шагов сценария.
В качестве примера рассмотрим основной алгоритм (Basic Flow) сценария
использования Бронирование рейса.
Мы можем пропустить первые два шага, потому что данная функциональность
предоставляется не нашим приложением, а Интернетом и браузером.
В1. Турист (Traveler) вводит URL сайта.
В2. Система отображает домашнюю страницу сайта.
Следующие два шага предоставляют список рейсов согласно данным по аэропортам
вылета и прибытия, а также даты и количество пассажиров.
В3. Турист вводит:
Аэропорт вылета, дату вылета.
Аэропорт прибытия, дату возвращения.
Количество путешествующих с ним взрослых и детей.
Турист выбирает «Найти рейсы».
В4. Система отображает рейсы вылета, отсортированные по цене.
Создадим класс FlightReservationForm, который будет включать функциональность
пользовательского интерфейса, относящуюся к этим шагам сценария. В UML класс
представляется в виде прямоугольника с тремя ячейками:
Верхняя ячейка содержит название класса.
Средняя ячейка содержит атрибуты.
Нижняя ячейка содержит операции.
Класс FlightReservationForm не имеет атрибутов.
getOutboundFlights, как показано на Рисунке 11.2.
Рисунок 11.2. Представление класса с помощью UML.
196
Первая
операция
–
это
Довольно часто аргументы создаваемой операции состоят из предоставленных
пользователем переменных. Операция getOutboundFlights имеет следующие аргументы:
Аэропорт вылета (departure airport).
Аэропорт прибытия (arrival airport).
Дата вылета (departure date).
Дата возвращения (return date).
Количество путешествующих взрослых (number of traveling adults).
Количество путешествующих детей (number of traveling children).
На данном этапе мы должны подумать о том, обладает ли система всей информацией,
требуемой для выполнения операции. Например, как система будет определять, нужен ли
нам билет в один конец, либо же билет до пункта назначения и обратно? Мы можем
создать правило: если Турист не указал дату возвращения, то ему или ей нужен билет в
один конец. В операции класса мы не можем просто пропустить аргумент, но мы можем
установить соглашение, что если дата получена в формате 01/01/0001, то это означает,
что Турист не ввел дату, а значит, не указал рейс обратно. Другим вариантом может быть
добавление Булевого аргумента returnFlag, указывающего, существует ли рейс обратно.
Мы можем показать аргументы на UML-диаграмме, но такое отображение делает
класс очень широким, как показано на Рисунке 11.3.
Рисунок 11.3. Отображение сигнатуры операции на диаграмме классов.
Как только у нас появилась операция boundary-класса, нам стало необходимо
разработать операцию controller-класса, которая будет снабжать boundary-класс
необходимой информацией.
Назовем эту операцию getFlights, а controller-класс, предоставляющий данную
операцию, FlightSelector. Аргументы операции getFlights класса FlightSelector будут такими
же, как и у операции getOutboundFlights из класса FlightReservationForm. Почему мы
называем одну операцию getOutboundFlights, в то время как название другой – getFlights?
Потому что функциональность controller-класса та же самая: независимо от того, являются
ли запрашиваемые рейсы вылетами или рейсами возвращения, необходимо возвращать
список рейсов на основании некоторых входных атрибутов. Тем не менее,
функциональность boundary-класса немного отличается в отношении рейсов вылета и
возвращения, т.к. пользовательский интерфейс немного различен в этих двух случаях.
Сейчас нам нужно определить entity-классы, которые будут использоваться для
возвращения информации о рейсе. Поместим всю информацию относительно рейсов в
класс Flight. Атрибутами этого класса будут:
Аэропорт вылета (departure airport)
Аэропорт прибытия (arrival airport)
Дата вылета (departure date)
Время вылета (departure time)
Дата прибытия (arrival date)
Время прибытия (arrival time)
Так как ни один из атрибутов однозначно не идентифицирует рейс, мы можем
добавить дополнительный атрибут под названием flightId. В целях улучшения
производительности системы лучше определить его как Integer, чем как String. При
разработке нашего класса Flight мы имеем в виду полную связь между аэропортом вылета
и пунктом назначения. Однако если это не прямой рейс, то он будет состоять из
нескольких отрезков пути с остановками между ними. Рейс будет содержать один или
более отрезков пути. В объектно-ориентированном проектировании это называется
агрегацией. Рисунок 11.4. показывает UML-представление классов Flight и FlightLeg, а
также их агрегацию. Класс FlightLeg содержит атрибуты, подобные атрибутам класса
Flight, но они описывают отдельные отрезки пути. Вдобавок он содержит Airline (название
авиалиний) и FlightNumber (номер рейса), используемый этими авиалиниями для
идентификации рейса.
197
Рисунок 11.4. Агрегация классов Flight и FlightLeg.
Для этих классов нам также необходимо добавить атрибут flightLegId (идентификатор
отрезка пути). FlightNumber однозначно не идентифицирует рейс, потому что в разные
дни могут быть рейсы с одним и тем же номером. Другой подход заключается в
использовании пары атрибутов Flight Number и Departure Date, но использование двух
атрибутов для идентификации менее удобно.
У классов Flight и FlightLeg есть некоторые атрибуты, но нет операций. Ситуация,
когда одна из ячеек класса пуста, является достаточно распространенной. У entityклассов есть атрибуты, но нет операций, а у controller-классов есть операции, но нет
атрибутов.
Так как мы ожидаем, что в результате поиска будет найдено большое количество
рейсов, объект, возвращаемый функцией getFlights, будет представлять собой список
объектов Flight. Мы можем определить новый класс ListOfFlights. На UML диаграмме мы
можем показать, что ListOfFlights содержит ноль или более объектов класса Flight, как
показано на рисунке 11.5. Берется множество от 0 до n, т.к. список может быть пустым.
Рисунок 11.5. ListOfFlights содержит в себе несколько рейсов.
После того как мы сформировали классы Flights и ListOfFlights, а также части классов
FlightReservationForm и FlightSelector, мы можем отобразить шаг сценария (относительно
поиска) на диаграмме последовательностей, как показано на Рисунке 11.6. На диаграмме
последовательностей мы показываем сообщения, посылаемые между объектами.
Пунктирная линия, идущая вниз от каждого объекта, называется линией жизни (lifeline).
Boundary-класс
FlightReservationForm
на
данной
диаграмме
представляет
пользовательский интерфейс, или клиентскую часть, которая взаимодействует с
действующим лицом. Controller-класс FlightSelector представляет серверную часть
приложения. Реализация этих классов зависит от архитектуры системы.
198
Рисунок 11.6. Диаграмма последовательностей, показывающая вызов операции
getOutboundFlights класса FlightReservationForm и операции getFlights класса
FlightSelector.
Как только FlightReservationForm получает список рейсов от FlightSelector, он
отображает его на экране. Для этого мы можем определить возвратную операцию
displayOutboundFlights. Значение, возвращаемое этой операцией, может быть Булевым,
показывающим, было ли успешным выполнение операции или нет.
Иногда нам необходимо более чем одна controller-операция для реализации
требуемой функциональности. В нашей системе одним из требований было то, что помимо
кода аэропорта, система будет распознавать пары наименований город/штат или
город/страна. Чтобы смоделировать данную функциональность, мы можем ввести класс
AirportController с операцией getAirportCode (town, location). Почему мы не называем этот
класс AirportCodeResolver? Потому что в будущем мы можем использовать этот же класс
для поиска расположенных рядом аэропортов или каких-либо других операций,
связанных с аэропортами. Более общее название обеспечивает нам гибкость в
применении
Если строка, описывающая аэропорт в аргументе операции getFlights – не
трехзначный код аэропорта, то FlightSelector полагает, что он содержит пару
наименований город/штат или город/страна. Он также передает этот аргумент классу
AirportController, который возвращает код аэропорта на основании входных переменных
(см. Рисунок 11.7).
Рисунок 11.7. FlightSelector вызывает операцию getAirportCode класса AirportController.
199
Как только мы закончили с моделированием шагов В3 и В4, мы можем перейти к
следующим шагам:
В5. Турист выбирает рейс.
В6. Система отображает рейсы возвращения.
Операция boundary-класса, обеспечивающая данную функциональность, может быть
названа selectOutboundFlight, а ее аргументами будут:
flightId: Идентификатор (ID) выбранного рейса вылета.
airport: Аэропорт посадки для рейса возвращения.
date: Дата рейсов возвращения.
Возвращаемое значение – набор объектов Flight.
Для получения списка рейсов возвращения мы можем использовать уже
определенную операцию getFlights класса FlightSelector. Так как отображение рейсов
возвращения на экране требует немного иной функциональности, чем отображение
вылетов,
нам
необходимо
определить
другую
операцию
boundary-класса
displayReturnFlights. Мы можем добавить три новых сообщения в диаграмму
последовательностей, как показано на рисунке 11.8.
Рисунок 11.8. Диаграмма последовательностей после добавления сообщения
getReturnFlights.
Рассмотрим два следующих шага сценария:
В7. Турист выбирает рейс возвращения.
В8. Система отображает детали рейса.
Операция boundary-класса может быть названа selectReturnFlight.
Теперь нам нужна controller-операция, которая возвращает
основании flightId:
Название операции: getFlightDetails.
Аргумент: flightId.
Возвращаемое значение: Flight.
Класс, выполняющий данную операцию: FlightSelector.
200
детали рейса на
Мы добавляем операцию getFlightDetails к классу FlightSelector, а также добавляем
соответствующие сообщения в диаграмму последовательностей. Так как нам необходимы
детали рейсов вылета и возвращения, у нас будут два различных вызова этой операции.
Операция boundary-класса, отображающая детали рейсов обоих типов, будет называться
displayFlightDetails (см. Рисунок 11.9).
Рисунок 11.9. Диаграмма последовательностей после добавления сообщений
selectReturnFlight, getFlightDetails и displayFlightDetails.
Так как шаг В10 не является ответом системы на шаг В9, мы возьмем только один
шаг для формирования следующей операции:
В9. Турист подтверждает рейс.
Операция boundary-класса называется confirmFlight, а ее аргументы включают
идентификаторы для обоих типов рейсов.
До настоящего времени мы получали информацию о доступных рейсах. Сейчас мы
хотим начать фактическое бронирование рейсов. Мы можем сгруппировать всю
функциональность, относящуюся к бронированию, в отдельный controller-класс
BookingSystem. Каким образом разделить функциональность между классами – будет
решать дизайнер системы. В нашем случае мы бы могли рассмотреть комбинирование
функциональности классов FlightSelector и BookingSystem в один большой класс
FlightController. Однако этот класс был бы очень большим и обеспечивал бы довольно
обширную функциональность.
Создадим класс BookingSystem и добавим операцию bookFlight, которая будет иметь
в качестве аргументов идентификаторы двух типов рейсов – один для рейса вылета и
один для рейса возвращения. Если мы бронируем билет в один конец, второй аргумент
будет нулевым. Операция возвращает reservationNumber. Нам понадобится этот ID в
будущем. Рисунок 11.10. показывает начальное представление этого класса. Позже нам
будет нужно больше операций.
Рисунок 11.10. Начальное представление класса BookingSystem (была добавлена только
одна операция).
201
Следующий шаг также берется отдельно для формирования операции:
В10. Турист предоставляет свой идентификатор и пароль для покупки билета.
Наиболее удобным будет вынести все функции идентификации пользователя в
системе в отдельный объект, такой как LoginController (см. Рисунок 11.11). Он будет
содержать функциональность, относящуюся к смене паролей, восстановления забытых
паролей и т.д. Операция Login будет иметь идентификатор пользователя (userid) и пароль
(password) в качестве аргументов. Возвращаемое значение – Булево, подтверждающее,
была ли идентификация успешна. Соответствующая функция boundary-класса может
называться также - login.
Рисунок 11.11. Класс LoginController.
Следующие два шага сценария:
В11. Турист предоставляет информацию пассажира.
В12. Система отображает доступные места.
Эти два шага фактически не относятся друг к другу. Даже если отображение мест на
экране выступает в качестве ответа на предоставление информации пассажира, лучше
разделить эти две функциональности на две отельные операции. Это обеспечивает
большую гибкость в применении в случае, если мы хотим изменить ход процесса в
будущем.
В первую очередь, boundary-класс вызывает данную операцию для отображения
PassengerDataRequest.
Чтобы принять информацию пассажира, boundary-класс, как и controller-класс
BookingSystem, должен иметь операцию setPassengerData, которая берет объект Passenger
в качестве аргумента. Объект Passenger содержит следующие атрибуты:
Идентификатор пассажира (passenger ID)
Город (city)
Имя (first name)
Штат (state)
Фамилия (last name)
Почтовый индекс (zip code)
Отчество (middle initial)
Страна (country)
Дата рождения (date of birth)
Наиболее часто используемый
Адрес (address)
номер рейса (frequent flyer
number)
Рисунок 11.12. показывает представление этого класса с помощью UML.
Рисунок 11.12. Класс Passenger.
Помимо объекта Passenger операция setPassengerData должна содержать второй
аргумент, определяющий reservation ID, чтобы система корректно присваивала эти
202
данные определенному заказу. Операция может быть вызвана много раз, в зависимости от
того, как много пассажиров путешествует.
Для шага В12 операция boundary-класса и соответствующая операция controllerкласса – это getAvailableSeats. Ее аргумент – flightId. Она возвращает список номеров
доступных мест. Controller-операция предоставляется классом BookingSystem. Когда
boundary-класс получает список мест от controller-класса, она вызывает операцию
displayAvailableSeats.
После того как турист получает список доступных мест мы должны смоделировать
способ сообщить системе, какие места Турист выбрал:
В13. Турист выбирает места.
Место, выбранное туристом, передается в boundary-класс с помощью операции
selectSeat, а затем перенаправляется в BookingSystem класс с использованием той же
операции. Эта операция содержит три аргумента: reservationNumber (номер заказа),
passengerId (идентификатор пассажира) и seatNumber (номер места). Переменная
seatNumber
имеет тип String вместо Integer, потому что места в самолете обычно
обозначаются комбинацией цифр и букв, например: 5А, 5В, 5С. Возвращаемое значение в
данном случае неважно. Она может возвращать итоговый код, указывающий, была ли
операция закончена успешно.
Операция вызывается количество раз, равное количеству пассажиров.
Внутренне информация о заказе может храниться в объекте Reservation со
следующими атрибутами:
Номер заказа (reservationNumber).
Идентификатор клиента (customerId, может быть идентичным идентификатору
делающего заказ пользователя).
Идентификатор рейса вылета (outboundFlightId).
Идентификатор рейса возвращения (returnFlightId).
Этот класс связан с одним или несколькими объектами FlightLegReservation, которые
присваивают определенный номер места паре FlightLeg/Passenger, как показано на
Рисунке 11.13.
Рисунок 11.13. Класс Reservation и связанные с ним классы.
Следующие два шага обрабатывают информацию, необходимую для осуществления
платежей:
В14. Турист предоставляет информацию о его кредитной карте и расчетный адрес.
В15. Система предоставляет номер подтверждения.
Функции оплаты могут поддерживаться отдельным классом PaymentProcessor. Этот
класс внутренне использует связь с системами расчета большинства кредитных карт. С
203
точки зрения интерфейса, у класса есть метод submitPayment, который содержит объект
Payment в качестве аргумента. Этот объект содержит следующие атрибуты:
Номер кредитной карты (credit card number).
Дата окончания срока действия (expiration date).
Наименования компании, обслуживающей кредитную карту (cardholder name).
Расчетный адрес (billing address) .
Класс FlightReservationForm и класс BookingSystem также содержат операцию
submitPayment. Однако у этой операции есть дополнительный аргумент – reservationId
(идентификатор заказа), так что BookingSystem знает, какой именно заказ был оплачен.
Когда вызывается операция submitPayment класса BookingSystem, фактически
вызывается операция submitPayment класса PaymentProcessor. Для разных классов
вполне нормально иметь операции с одинаковыми названиями. (У нас уже есть операции с
одинаковыми именами в boundary-классе и controller-классе).
После прохождения всех шагов основного алгоритма сценария Бронирование рейса
наша диаграмма классов может выглядеть так, как показано на Рисунке 11.14. Вторая
часть диаграммы последовательностей показана на Рисунке 11.15. (первая часть была
показана на Рисунке 11.9).
Рассмотренный подход предполагает одновременное создание классов и диаграммы
последовательностей. Некоторые дизайнеры предпочитают сначала создавать диаграммы
сотрудничества, а затем уже формировать детали классов. В этом случае, когда мы
присваиваем название сообщению, это сообщение еще не определено в классе, так что
мы не можем просто выбрать его из списка. Нам нужно создать место метку для этого
сообщения. Для отличия метки от фактических сообщений, мы можем добавить знак
комментария «//» перед названием и написать название в простой форме (допускается
использование пробелов). Например: //get outbound flights (см. Рисунок 11.16). После
того, как мы определили эту операцию в классе, мы заменяем метку фактической
операцией. Преимущество подхода, при котором в первую очередь создаются
фактические операции для диаграммы классов, заключается в том, что нам не нужно
беспокоиться о подобных заменах в будущем.
Рисунок 11.14. Диаграмма классов, показывающая классы, реализующие
функциональность основного алгоритма сценария Бронирование рейса.
204
Рисунок 11.15. Диаграмма последовательностей, представляющая основной алгоритм
сценария Бронирование рейса.
Рисунок 11.16. Диаграмма последовательностей, представляющая первые две операции
основного алгоритма сценария Бронирование рейса, с комментариями вместо актуальных
имен операций.
205
11.2 Использование IBM Rational Rose для Проектирования
IBM Rational Rose - это инструмент, обеспечивающий очень удобный подход к
объектно-ориентированному проектированию, с использованием UML [IBM03c]. Данный
пункт описывает, каким образом можно осуществлять проектирование, описанное в
предыдущем пункте, используя Rational Rose.
Создание Новой Модели
Для создания новой модели Rational Rose выполните следующие действия:
1. Откройте Rational Rose (выберите Start>All Programs>Rational Software>Rational
Rose (Пуск>Все программы>Rational Software>Rational Rose).
2. В диалоговом окне Create New Model (Создать Новую Модель) нажмите кнопку
Cancel - Отмена (для загрузки настроек по умолчанию).
3. Определите название модели, нажав File>Save As (Файл>Сохранить как),
выбирая директорию и вводя наименование.
4. Левая панель отображает браузер, как показано на Рисунке 11.17.
Рисунок 11.17. Окно браузера IBM Rational Rose.
Создание Диаграммы Классов
На панели диаграмм Вы можете открыть несколько окон с диаграммами. При запуске
приложения должно открыться окно диаграммы классов, установленное по умолчанию.
Оно называется «Class Diagram: Logical View/Main». Вы можете выбрать это окно или
создать новое окно диаграммы классов. Для создания нового окна выполните следующие
действия:
1. Нажмите правой кнопкой мышки на Logical View и выберите New>Class Diagram
(Новая>Диаграмма Классов).
2. Дайте название диаграмме, например Booking Flight (Бронирование рейса).
3. Двойным щелчком мышки на диаграмме (в окне браузера) откройте окно на
главной панели.
Между панелью браузера и панелью диаграмм расположена вертикальная панель
инструментов, как показано на Рисунке 1.18. Чтобы поместить нужный элемент на
диаграмму, Вам нужно нажать на иконку на данной панели инструментов, а затем нажать
на нужное место на диаграмме, где Вы хотите поместить данный элемент.
Рисунок 11.18. Панель инструментов для диаграммы классов.
206
Создайте класс на диаграмме, выполняя следующие действия:
1. Нажмите на иконку класса на панели инструментов (пятая иконка сверху).
2. Нажмите на окно Class Diagram (Диаграмма Классов), чтобы поместить на него
иконку.
3. Класс появляется с названием NewClass.
4. Двойным щелчком мышки на данном классе откройте диалоговое окно Class
Specification (Характеристика Класса), как показано на Рисунке 11.19.
5. Измените название класса, например FlightSelector.
6. Введите описание класса в области Documentation (Документация).
7. Выберите закладку Operation (Операция).
8. Правой кнопкой мышки нажмите на главной панели диалогового окна и выберите
Insert (Вставить).
9. Назовите операцию, например getFlights. Когда Вы нажмете Enter, операция будет
добавлена в список.
Рисунок 11.19. Диалоговое окно Class Specification (Характеристика Класса).
10. Двойным щелчком мышки нажмите на названии операции.
11. Выберите закладку Detail (Детали), как показано на Рисунке 11.20.
Рисунок 11.20. Добавление аргументов операции.
207
12. Правой кнопкой мышки нажмите на текстовом поле Argument (Аргумент) и
выберите Insert (Вставить).
13. Назовите атрибут, например departureAirport.
14. Нажмите Tab для помещения курсора под столбцом Type (Тип). Появляется поле
со списком доступных типов.
15. Выберите из списка тип атрибута, например String.
16. Продолжите добавление всех аргументов.
17. Правой кнопкой мышки нажмите на классе и выберите Option>Show operations
signature (Опции>Показать сигнатуру операций).
Для создания класса Flight выполните следующие действия:
1. Нажмите на иконку класса на панели инструментов.
2. Нажмите на окне Class Diagram (Диаграмма Классов).
3. Класс появляется с названием NewClass.
4. Двойным щелчком мышки на классе откройте диалоговое окно Class Specification
(Характеристика Класса), как показано на Рисунке 11.21.
Рисунок 11.21. Атрибуты класса.
5.
6.
7.
8.
Измените название класса на Flight.
Введите начальное описание класса в области Documentation (Документация).
Выберите закладку Attribute (Атрибут).
Правой кнопкой мышки нажмите на главной панели диалогового окна и выберите
Insert (Вставить).
9. Назовите атрибут, например flightId.
10. Двойным щелчком мышки нажмите на столбце Type (Тип).
11. Выберите из списка тип атрибута, например String.
12. Продолжите добавление всех аргументов.
Выполняйте эти действия для добавления классов FlightReservationForm, FlightLeg и
других классов, сформированных в предыдущем пункте.
Формирование Взаимосвязей
Предположим, что мы создали классы Flight и FlightLeg. Теперь мы хотим создать
связь, показывающую агрегацию этих классов. Для создания соответствующего типа
связи нам нужно соединить их с помощью дуги связи, двойным щелчком мышки нажать на
дуге между классами и установить некоторое значение в диалоговом окне Association
Specification (Характеристики Связи):
1. Выберите иконку связи на панели инструментов.
2. Нажмите на класс Flight.
208
3. Перетащите конец связи на класс FlightLeg.
4. Двойным щелчком мышки на связи между Flight и FlightLeg откройте диалоговое
окно Association Specification (Характеристики Связи), как показано на Рисунке
11.22.
Рисунок 11.22. Определение деталей роли.
5. Выберите закладку Role B Detail (Детали Роли В).
6. Выберите Multiplicity 1 (Множественность).
7. Выберите галочку Aggregate (Агрегация). После выбора данной галочки при
последующем открытии этого диалогового окна его название будет изменено с
Association Specification (Характеристики Связи) на Aggregation Specification
(Характеристики Агрегации), как показано на Рисунке 11.22.
8. Поставьте переключатель в By Reference (По Ссылке), чтобы определить
Containment (Ячейки) класса FlightLeg.
9. Выберите закладку Role A Detail (Детали Роли А).
10. Выберите 1…n из списка Multiplicity (Множественность).
11. Нажмите ОК.
После создания этой связи экран приложения должен выглядеть так, как показано на
Рисунке 11.23.
Рисунок 11.23. Диаграмма классов, созданная в IBM Rational Rose.
209
Создание Диаграммы Последовательностей
Прежде чем создать диаграмму последовательностей мы должны создать
пользователей, взаимодействующих со сценарием, который относится к этой диаграмме
(помимо того что мы уже сделали при создании диаграммы сценариев).
1. Правой кнопкой мышки нажмите на Logical View и выберите New>Sequence
Diagram (Новая>Диаграмма Последовательностей).
2. Правой кнопкой мышки нажмите на Use Case Package (Папка Сценариев
Использования) и выберите New>Actor (Новое>Действующее Лицо).
3. Дайте название действующему лицу, например Traveler (Турист).
Для создания диаграммы последовательностей выполните следующие действия:
1. Выберите и перетащите мышкой действующее лицо на главное окно.
2. Нажмите на иконку класса на вертикальной панели инструментов.
3. Нажмите на главном окне, чтобы поместить туда класс.
4. Двойным щелчком мышки на классе откройте диалоговое окно Object Specification
(Характеристики Объекта), как показано на Рисунке 11.24.
Рисунок 11.24. Выбор названия класса из списка определенных классов.
5. Выберите FlightReservationForm из списка Class (Классы).
6. Нажмите на иконке Object Message (Сообщение Объекта) на вертикальной панели
инструментов.
7. Соедините линию жизни Туриста с линией жизни FlightReservationForm.
8. Двойным щелчком мышки на сообщении откройте диалоговое окно Message
Specification (Характеристики Сообщения), как показано на Рисунке 11.25.
9. Выберите метод getOutboundFlights из списка Name (Название).
10. Нажмите ОК.
210
Рисунок 11.25. Выбор названия сообщения из списка доступных операций.
После этих действий экран приложения должен выглядеть так, как показано на
Рисунке 11.26.
Рисунок 11.26. Диаграмма последовательностей, созданная в IBM Rational Rose.
11.3 Использование IBM Rational Software Architect для
Проектирования
IBM Rational Software Architect – это встроенный инструмент для проектирования и
разработки программных проектов. Он соединяет в себе функциональность Rational
Software Modeler, инструмента для моделирования с использованием UML и Rational
Application Developer (среда разработки J2EE). В этом пункте Вы научитесь, как создавать
проект, сценарий использования (use case), класс и диаграмму последовательностей.
Создание Проекта
Для создания проекта выполните следующие действия:
1. Запустите программу, выбрав Start>Programs>IBM Rational>IBM Rational Software
Architect v.6.0>Rational Software Architect (выбрав Пуск>Программы>IBM
Rational>IBM Rational Software Architect v.6.0>Rational Software Architect).
2. В диалоговом окне Workspace Launcher (Модуль Установки Рабочего
Пространства), как показано на Рисунке 11.27, нажмите кнопку ОК для
подтверждения установленной по умолчанию рабочей директории.
211
Рисунок 11.27. Диалоговое окно Workspace Launcher (Модель Установки Рабочего
Пространства).
3. Выберите File>New>Project (Файл>Новый>Проект).
4. В диалоговом окне New Project (Новый Проект), как показано на Рисунке 11.28,
выделите UML Project и нажмите кнопку Next (Далее).
Рисунок 11.28. Диалоговое окно New Project (Новый Проект).
5. Введите название проекта, как показано на Рисунке 11.29, и нажмите на кнопку
Next (Далее).
Рисунок 11.29. Выбор названия проекта в диалоговом окне UML Modeling Project
(Моделирование Проекта UML).
212
6. Введите название файла модели UML, оставьте выделенным Blank Model, уберите
выделение галочки «Create a default diagram in the new model» (Создать
диаграмму по умолчанию в новой модели) и нажмите кнопку Finish (Закончить).
(см. Рисунок 11.30).
Рисунок 11.30. Выбор деталей проекта в диалоговом окне UML Modeling Project
(Моделирование Проекта UML).
Откроется рабочее пространство с пустой моделью, как показано на Рисунке 11.31.
Рисунок 11.31. Рабочее пространство с UML modeling project (проектом,
смоделированным с помощью UML).
213
Создание Диаграммы Сценариев
Создадим диаграмму сценариев:
1. Нажмите правой кнопкой мышки на Online Travel Agency Model (Модель Он-лайн
Агентства Путешествий) в Model Explorer (Проводник Моделей, в левой части
экрана) и выберите Add Diagram>Use Case Diagram (Добавить
Диаграмму>Диаграмма Сценариев).
2. Измените название Diagram 1, установленное по умолчанию, на имеющее смысл
имя.
3. Нажмите Actor (Действующее Лицо) в меню Palette (Палитра, справа от окна
диаграммы) и затем нажмите в любом месте окна диаграммы для создания на ней
действующего лица. Замените название Actor 1, установленное по умолчанию, на
Traveler (Турист).
4. Нажмите Use Case (Сценарий Использования) в меню Palette (Палитра) и затем
нажмите в любом месте окна диаграммы для создания на ней сценария
использования. Замените название UseCase 1, установленное по умолчанию, на
Book a flight (Бронирование рейса).
5. Нажмите Associations (Связи) в меню Palette (Палитра). Нарисуйте линию связей
от действующего лица к сценарию использования, как показано на Рисунке
11.32.
Рисунок 11.32. Создание диаграммы сценариев с помощью IBM Rational Software
Architect.
6. Продолжайте добавление действующих лиц, сценариев и связей.
7. Нажмите Ctrl+S для сохранения диаграммы.
Создание Диаграммы Классов
Вы можете создать диаграмму классов, выполняя следующие действия:
1. Нажмите правой кнопкой мышки на Online Travel Agency Model (Модель Он-лайн
Агентства Путешествий) в Model Explorer (Проводник Моделей) и выберите Add
Diagram>Class Diagram (Добавить Диаграмму>Диаграмма Классов).
2. Измените название Diagram 1, установленное по умолчанию, на имеющее смысл
имя.
3. Выберите Class (Класс) в меню Palette (Палитра) и затем нажмите в любом месте
окна диаграммы для создания на ней класса.
4. Замените название Class 1, установленное по умолчанию, на
FlightReservationForm.
214
5. Правой кнопкой мышки нажмите на созданном классе и выберите Add
UML>Operation (Добавить UML>Операция) для создания операции этого класса.
Назовите ее getOutboundFlights.
6. Продолжайте добавлять остальные операции класса.
7. Нажмите Class (Класс) в меню Palette (Палитра) и затем нажмите в любом месте
окна диаграммы для создания на ней класса Flight.
8. Правой кнопкой мышки нажмите на классе Flight и выберите Add UML>Attribute
(Добавить UML>Атрибут) для создания атрибута этого класса. Назовите его
FlightId.
9. Двойным щелчком мышки на атрибуте FlightId откройте окно Properties (Свойства)
в нижней части экрана.
10. В окне Properties (Свойства) нажмите Select Type (Выбрать Тип), выберите Integer
в диалоговом окне Select Element (Выбрать Элемент), как показано на Рисунке
11.33.
Рисунок 11.33. Выбор типа атрибута.
11. Продолжайте добавление атрибутов.
12. Добавьте в диаграмму новый класс ListOfFlights.
13. Нажмите Assosiations (Связи) в меню Palette (Палитра).
14. Соедините классы ListOfFlights и Flight.
15. Двойным щелчком мышки на линии связи откройте окно Properties (Свойства) в
нижней части экрана, как показано на Рисунке 11.34.
16. В списке Type (Тип) окна Properties (Свойства), выберите «1-Aggregation».
17. Установите Multiplicity (Множественность) роли ListOfFlights равную 1, а Multiplicity
роли Flight равную *.
215
Рисунок 11.34. Создание диаграммы классов с помощью IBM Rational Software Architect.
Создание Диаграммы Последовательностей
Показанная на Рисунке 11.35. Диаграмма последовательностей может быть создана
выполнением следующих действий:
1. Нажмите правой кнопкой мышки на название модели в Model Explorer (Проводник
Моделей) и выберите Add Diagram>Sequence Diagram (Добавить
Диаграмму>Диаграмма Последовательностей).
2. Измените название Diagram 1, установленное по умолчанию, на имеющее смысл
имя.
3. Перетащите мышкой Traveler (Турист) из окна Explorer (Проводника) на
диаграмму для создания действующего лица.
4. Перетащите мышкой класс FlightSelector из окна Explorer (Проводника) на
диаграмму.
5. Выберите Asynchronous Message (Асинхронное Сообщение) в Palette (Палитра).
6. Нажмите на линию под Traveler (Туристом) и перетащите к линии под
FlightReservationForm.
7. Выберите операцию getOutboundFlights из списка.
8. По аналогии создайте оставшиеся сообщения.
9. Выберите File>Save All (Файл>Сохранить Все), чтобы сохранить все изменения.
216
Рисунок 11.35. Создание диаграммы последовательностей в IBM Rational Software
Architect.
Публикация Проекта
После того как все необходимые диаграммы были созданы, Вы можете осуществить
публикацию всей модели на веб, выполняя следующие действия:
1. Выделите название модели в Model Explorer (Проводник Моделей).
2. Выберите Modeling>Publish>Web (Моделирование>Публикация>Web).
3. В диалоговом окне Publish to Web (Опубликовать на Web), как показано на
Рисунке 11.36, задайте местоположение генерируемых HTML файлов и нажмите
кнопку ОК.
Рисунок 11.36. Задание местоположения в диалоговом окне Publish to Web
(Опубликовать на Web).
Для доступа к опубликованной модели выполните следующее:
1. Следуйте по пути, который был указан Вами, затем двойным щелчком мышки
откройте файл index.html.
2. Нажмите на ссылку модели, как показано на Рисунке 11.37.
217
Рисунок 11.37. Первая страница, где Вы выбираете опубликованную модель.
3. Перемещайтесь по опубликованной модели, нажимая на ссылки элементов и
диаграммы, как показано на Рисунке 11.38.
Рисунок 11.38. Диаграмма классов опубликованной модели.
11.4 Заключение
Данная глава представляет систематизированный подход к разработке объектноориентированного проектирования с использованием UML. Тем не менее, была обсуждена
лишь только главная часть проектирования. Из сценариев использования мы получили
диаграммы классов и диаграммы последовательностей. Чтобы иметь полную модель
системы, нам нужно будет добавить диаграммы активности, взаимодействия, состояний и
топологии. Диаграммы сценариев были кратко упомянуты в Главе 7 «Создание Сценариев
Использования (Use Cases)». Более детальное обсуждение проектирования с
использованием UML выходит за рамки этой книги.
218
Данная глава показала, каким образом классы образуются от сценариев
использования, и что сценарии предоставляют полноценный, структурированный подход к
распределению поведения системы (операций) по определенным классам, позволяющий
получить устойчивые и удобные в сопровождении системы. К сожалению, этот подход
часто игнорируется, и многие организации используют для идентификации классов и
операций
несистематический,
ситуативный
«ad-hoc»
подход,
приводящий
к
низкокачественному дизайну.
С помощью спроектированной модели системы некоторые инструменты (такие как
IBM Rational Rose и IBM Rational System Architect) позволяют Вам по частям генерировать
код (или, по крайней мере, stub-код - использующий вызов удаленных процедур) в
конечный язык программирования. Тем не менее, если даже Вы не используете модель
для генерации кода, UML диаграммы помогают осуществлять эффективные коммуникации
между дизайнерами, разработчиками, бизнес-аналитиками и другими членами команды.
Ссылки
BOO04] Booch, Grady, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language
Reference Manual, Second Edition, Boston: Addison-Wesley, 2004.
[BOO05] Booch, Grady, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language
User Guide, Second Edition, Boston: Addison-Wesley, 2005.
[IBM03c] Rational Rose User’s Guide, IBM Corporation, 2003.
219
ГЛАВА 12
Документация
Данная глава рассматривает документацию RequisitePro –
доступные типы
документации, существующие шаблоны в RequisitePro, а также как использовать IBM
Rational SoDA для автоматической генерации отчетов. Прежде чем перейти к типам
документации, предлагаемых RequisitePro, данная глава начинается с обсуждения
основных существующих типов документации.
12.1 Типы Документации
Существует много способов классификации документации. Возможно, наиболее
важный из них – классификация по аудитории, для которой предназначается
документация:
Внутренняя документация для коммуникаций между членами команды.
Техническая документация для тех, кому может понадобиться оптимизация
системы в будущем.
Пользовательская документация.
Маркетинговые материалы для потенциальных заказчиков.
Внутренняя Документация
Внутренняя документация используется на протяжении всего жизненного цикла
проекта для коммуникаций между членами команды в процессе разработки системы.
Некоторые документы данного типа могут быть также использованы для коммуникаций с
пользователями (Спецификация Сценариев Использования - Use Case Specification) или
как приложение к контракту заказчика (Концепция проекта – Vision).
Техническая Документация
Мы не можем рассчитывать на то, что когда понадобится оптимизация системы, мы
сможем привлечь к этому изначальную команду разработчиков. Это означает, что вся
система должна быть документально оформлена на различных уровнях (архитектура,
дизайн, код). С помощью этой документации команда, вносящая изменения в систему,
может легко понять, каким образом исправить ошибки или расширять функционал
системы. Она может включать UML – диаграммы, описывающие дизайн системы,
диаграммы отношений сущностей, показывающие схему базы данных, а также
графические схемы, отображающие алгоритмы.
Одна из наиболее важных форм технической документации – это документация
исходного кода. Для облегчения создания таких документов, многие инструменты могут
генерировать документацию из кода, главным образом из комментариев, включенных в
код.
Сравнение
некоторых
таких
инструментов
может
быть
найдено
тут:
http://en.wikipedia.org/wiki/Comparison_of_documentation_generators. Использование этих
инструментов требует от разработчиков следовать некоторым указаниям по извлечению
документации из кода. Преимущество в использовании таких генераторов кода в том, что
документация может быть автоматически обновлена после изменений в самом коде. Тем
не менее, довольно трудно добавлять текст в свободной форме в такие документы.
220
Пользовательская Документация
Пользовательская документация описывает, как пользоваться системой. Она может
быть адресована пользователям, системным администраторам, персоналу справочной
службы или группе по обслуживанию системы. Вместо печатной версии, некоторые
документы могут быть доступны он-лайн в форме справки или руководства.
Пользовательская документация включает:
Руководства пользователей (User Guides).
Справочники (Reference materials).
Инструкции (Tutorials).
Руководства по установке (Tutorials).
Различные типы пользовательской документации могут иметь различную структуру.
Справочники обычно имеют форму списка некоторых команд, функций или инструкций,
отсортированных в алфавитном порядке. Руководства пользователя используют
тематический подход – они содержат главы, которые фокусируются на определенной
теме. Инструкции содержат пошаговое описание определенных задач [WIK06].
Пользовательская документация может также содержать описание программного
интерфейса приложения, веб-сервисов или иных интерфейсов между системой и другими
приложениями. В этом случае такой документ адресуется программистам, которые
разрабатывают взаимодействующие с системой приложения.
Маркетинговые Материалы
Маркетинговая информация, обычно адресуемая потенциальным заказчикам и
клиентам, описывает преимущества системы. Нет необходимости детально описывать, что
система делает и каким образом она построена. Этот тип публикации включает в себя
брошюры, листовки, таблицы и каталоги. Он также может быть опубликован в
электронной форме, например в презентации Microsoft PowerPoint, веб-сайт или CDдемонстрации.
12.2 Документы в RequisitePro
В предыдущем пункте была описана классификация типов документов, чтобы
показать, для каких типов документов RequisitePro наиболее полезен.
Большая часть документов, разрабатываемых с помощью RequisitePro, попадает в
категорию внутренней документации. Все предустановленные шаблоны, предлагаемые в
данном инструменте, относятся к документам, которые используются в течение процесса
разработки программного обеспечения.
Иногда RequisitePro также используется для создания технической документации,
особенно если один и тот же документ используется сначала в течение разработки, а
затем хранится в качестве справочника после выпуска системы.
Некоторые документы, изначально созданные в процессе управления требованиями,
позже могут быть использованы в пользовательской документации. Например,
применение текста сценариев использования (use cases) в руководствах пользователей.
Гораздо
реже
RequisitePro
используется
для
маркетинговых
материалов.
Маркетинговые брошюры обычно требуют сложного графического дизайна, а возможности
графики RequisitePro ограничены функциональностью Microsoft Word.
Для создания документа в RequisitePro тип документа должен быть доступен в
проекте. Какой тип документов уже добавлен в проект зависит от того, какой шаблон
проекта был использован. Например, для шаблона Use Case (Сценариев Использования)
типы документов по умолчанию следующие:
Словарь (Glossary).
План Управления Требованиями (Requirements Management Plan).
Запросы Заинтересованного Лица (Stakeholder Request).
Спецификация на Дополнительные Требования (Supplementary Requirements
Specification).
Спецификация Сценариев Использования (Use Case Specification).
Концепция проекта (Vision).
221
Традиционный шаблон содержит Спецификацию Требований к Программному
Обеспечению (Software Requirements Specification) вместо Сценариев Использования и
Дополнительных Требований:
Словарь (Glossary).
План Управления Требованиями (Requirements Management Plan).
Спецификация Требований к Программному Обеспечению (Software Requirements
Specification).
Запросы Заинтересованного Лица (Stakeholder Request).
Концепция проекта (Vision).
Чтобы увидеть, какой тип документов доступен в Вашем проекте, выполните
следующие действия:
1. Нажмите правой кнопкой мышки на названии проекта и выберите Properties
(Свойства).
2. Выберите закладку Document Types (Типы Документа), как показано на Рисунке
12.1.
Рисунок 12.1. Типы документов, доступные по умолчанию в шаблоне проекта Use Case
(Сценариев Использования).
Создание Документа из Доступного Типа Документов
Если тип документа уже находится в проекте, то для создания документа выполните
следующие действия:
1. Нажмите правой кнопкой мышки на папке, где Вы бы хотели создать документ.
2. Выберите New>Document (Новый>Документ).
3. Заполните диалоговое окно, как показано на Рисунке 12.2. Доступные типы
документов находятся в списке внизу экрана.
222
Рисунок 12.2. Диалоговое окно Document Properties (Свойства Документа).
Добавление Нового Типа Документов
Если нужный тип документа отсутствует в проекте, добавьте его, выполнив
следующие действия:
1. Выберите File>Properties (Файл>Свойства).
2. Нажмите на закладку Document Type (Тип Документа).
3. Нажмите Add (Добавить).
4. Заполните диалоговое окно, как показано на Рисунке 12.3.
Рисунок 12.3. Outlines (шаблоны), доступные в RequisitePro.
При добавлении документа Вам необходимо выбрать outline – шаблон, который будет
использоваться для всех документов данного типа. В RequisitePro доступны следующие
типы шаблонов:
Спецификация на Функциональные Тестовые Сценарии (Functional Test Case
Specification).
• Усовершенствованная Спецификация Требований к Программному Обеспечению
(Modern Software Requirement Specification).
• Спецификация Мульти-Сценариев Использования (Multi-Use Case Specification).
• Шаблон Требований Продукта (Product Requirements Outline).
• RUP Словарь Предметной Области (Rational Unified Process Business Glossary).
• RUP Бизнес Правила (Business Rules).
• RUP Спецификация на Реализацию Сценариев Использования Предметной
Области (Business Use Case Realization Specification).
223
•
•
•
•
•
•
•
•
•
•
•
•
•
RUP Спецификация Сценариев Использования Предметной Области (Business Use
Case Specification).
RUP Концепция Предметной Области (Business Vision Document).
RUP Словарь (Glossary).
RUP План Управления Требованиями (Requirements Management Plan).
RUP Дополнительные Требования к Предметной Области (Supplementary Business
Specification).
RUP Спецификация Требований к Программному Обеспечению (Software
Requirement Specification).
RUP Спецификация Сценариев Использования Требований Программного
Обеспечения (Use Case Software Requirement Specification).
RUP Дополнительная Спецификация (Supplementary Specification).
RUP Запросы Заинтересованного Лица (Stakeholder Requests).
RUP План Тестирования (Test Plan).
RUP Спецификация Сценариев Использования (Use Case Specification).
RUP Концепция проекта (Vision Document).
Требования к Программному Обеспечению (Software Requirements).
Создание Нового Типа Документов
Если Вы хотите создать документ, для которого нет соответствующего типа, Вам
нужно создать новый тип документов и шаблон для этого типа. Этот процесс детально
описан в Главе 9 «Создание Тестовых Сценариев (Test Cases) из Сценариев
Использования (Use Cases)» в пункте 9.3.
Импорт Документа
Каждому документу назначается определенный тип. Даже если Вы импортируете
документ из приложения вне RequisitePro (см. Главу 4 «Настройка Проекта» пункт 4.1),
Вам все равно нужно определить тип для него. Если формат импортируемого документа не
совпадает с выбранным типом документа, появляется сообщение с предупреждением, как
показано на Рисунке 12.4. Нажатие на No (нет) оставляет оригинальный формат
документа.
Рисунок 12.4. Сообщение с предупреждением появляется, когда импортируемый
документ имеет формат, отличный от выбранного типа документа.
12.3 Использование IMB Rational SoDA
IBM Rational SoDA (Software Documentation Automation) – это инструмент для
документирования и генерации отчетов [IBM01]. Основное преимущество SoDA – это
возможность извлекать информацию из остальных инструментов Rational (таких как
RequisitePro Rational Rose). Большинство шаблонов отчетов уже предопределены.
Вдобавок к этому, Вы можете настраивать существующие шаблоны или создавать новые,
используя простой язык, состоящий из всего лишь четырех команд: Open (Открыть),
Display (Отобразить), Repeat (Повторить) и Limit (Ограничить).
Разница между отчетами и документом в том, что отчет генерируется каждый раз с
нуля, тогда как в процессе генерации документа пункты, добавленные вручную, остаются
неизменными. Обновляется только информация, извлеченная из других инструментов.
Данный пункт показывает, как создавать отчет с использованием предустановленных
шаблонов SoDA.
224
Генерация Отчета из RequisitePro
Если Вам необходим отчет относительно элементов проекта в RequisitePro, Вы можете
создать его как из RequisitePro, так и из SoDA. Чтобы сделать это из RequisitePro (что
гораздо проще и быстрее) выполните следующие действия:
1. Выберите Tools>Generate RequisitePro Report (Инструменты>Генерировать Отчет
RequisitePro).
2. Выберите отчет из списка, как показано на Рисунке 12.5, и нажмите ОК.
Рисунок 12.4. Выбор отчета RequisitePro.
Рисунок 12.6. показывает примерный отчет, который содержит все документы и все
требования.
Рисунок 12.6. Отчет RequisitePro, показывающий всю проектную документацию и
требования.
Генерация Отчета из SoDa
Вы можете сгенерировать тот же самый отчет из SoDa,
выполняя следующие
действия:
1. Запустите Rational SoDA, выбрав All Programs>Rational Software>Rational SoDA for
Microsoft Word (Все Программы>Rational Software>Rational SoDA для Microsoft
Word). Откроется пустой документ Microsoft Word.
2. Выберите SoDA>Getting Started (Начало Работы).
3. Нажмите Next (Далее) в диалоговом окне, как показано на Рисунке 12.7.
225
Рисунок 12.7. Генерация предустановленного отчета с использованием SoDA: Шаг 1.
4. Выберите отчет, который вы хотите получить, например reqpro\docsreqts.doc (см.
Рисунок 12.8), и нажмите кнопку Next (Далее).
Рисунок 12.8. Генерация предустановленного отчета с использованием SoDA: Шаг 2.
5. Нажмите кнопку Browse (Обзор), чтобы выбрать путь для сохранения файла, как
показано на Рисунке 12.9).
226
Рисунок 12..9 Генерация предустановленного отчета с использованием SoDA: Шаг 3.
6. Нажмите кнопку Generate (Генерировать), как показано на Рисунке 12.10.
Рисунок 12.10. Генерация предустановленного отчета с использованием SoDA: Шаг 4.
7. В диалоговом окне Identify Project (Идентификация Проекта) нажмите кнопку
Browse (Обзор), выберите файл .rqs, который содержит проект RequisitePro, и
нажмите ОК (см. Рисунок 12.11).
По умолчанию проект расположен в директории C:\Program Files\Rational\
RequisitePro\Projects\project name.
Рисунок 12.11. Идентификация проекта, из которого будет генерироваться отчет.
227
Сгенерированный отчет должен выглядеть так же, как отчет, сгенерированный из
RequisitePro (см. Рисунок 12.6).
12.4 Заключение
В данной главе были описаны основные типы документации, и как RequisitePro
используется для их создания:
Для внутренней документации - используется наиболее часто.
Для технической документации - используется иногда.
Для пользовательской документации – используется изредка.
Для маркетинговых материалов – используется очень редко.
Были приведены документы и шаблоны, доступные в RequisitePro.
Также были описаны шаги по созданию документов:
Создание нового типа документа, если шаблон не существует.
Добавление нового типа документа из доступных шаблонов в проект.
Создание документа из типа документа, который уже присутствует в проекте.
Вы можете импортировать документ извне RequisitePro, но в этом случае шаблон
документа должен быть определен перед импортом.
В заключение данной главы были рассмотрены два метода генерации
предустановленных шаблонов SoDA:
Генерация отчета из RequisitePro.
Генерация отчета из SoDA.
Эта глава завершает главную часть данной книги. В вышеприведенных главах было
рассмотрено, каким образом осуществляется прохождение по пирамиде требований. В
главах с 5 по 12 было рассмотрено следующее:
Создание сценариев использования (use cases) и дополнительных требований.
Генерация тестовых сценариев (test cases).
Проектирование Системы.
Генерация документации.
В конце этой главы было описано, каким образом RequisitePro может содействовать в
решении всех этих задач.
Следующая глава сосредоточена на некоторых особенностях RequisitePro, которые
еще не были обсуждены.
Ссылки
[WIK06] See http://en.wikipedia.org/wiki/Software_documentation.
[IBM01] Using Rational SoDA for Word, Version 2001A.04.00, IBM Corporation, 2001.
228
Часть 3
Другие Темы
13.
14.
Управление Проектами
Управление Требованиями в RUP (Rational Unified
Process)
229
ГЛАВА 13
Управление
Проектами
Данная глава охватывает различные задачи, относящиеся к управлению проектами
RequisitePro:
Распечатка сводки по проекту.
Архивация и восстановление проектов.
Перемещение и копирование проектов.
Настройка и использование трассировки между проектами.
Также рассматриваются типы файлов RequisitePro.
13.1 Распечатка Сводки по Проекту
Наиболее быстрый способ получить отчет с основной информацией о проекте – это
распечатать сводку по проекту, выполняя следующие действия:
1. Выберите File>Project Administration>Print Summary (Файл>Администрирование
Проекта>Печать Сводки).
2. Выберите принтер в диалоговом окне Print (Печать).
Распечатанный отчет содержит следующее:
Основную информацию по проекту, например каталог, где хранится проект,
текущее количество требований и используемая база данных.
Все требования и их атрибуты.
Типы документов с главной информацией, например имя файла и краткое
описание.
Документы с главной информацией, например каталог, тип документа и данные о
времени создания текущей версии.
Рисунок 13.1. показывает первую страницу отчета.
230
Рисунок 13.1. Сводка по проекту.
13.2 Типы Файлов RequisitePro
Рисунок 13.2. показывает некоторые файлы, обычно хранящиеся в каталоге
C:\Program Files\Rational\RequisitePro\Projects\project name:
.rqs – файл, содержащий информацию о проекте.
.rql – файл, содержащий информацию о базе данных.
.mdb – файл с базой данных проекта (если вы используете Microsoft Access).
Файлы документов, у которых расширение зависит от типа документа, например
.vis для Vision и .ucs для Use cases.
.bak – файлы, содержащие резервные копии предыдущих версий документов.
Некоторые файлы из каталога C:\Program Files\Rational\RequisitePro\outlines:
.def – файлы, содержащие описания шаблонов для всех типов документов.
.dot – файлы, содержащие шаблоны для всех типов документов.
Файлы .def и .dot были рассмотрены в Главе 9 «Создание Тестовых Сценариев (Test
Cases) из Сценариев Использования (Use Cases)» в пункте 9.3.
Рисунок 13.2. Файлы проекта.
Так как файлы документов могут иметь различные расширения, чаще назначаемые в
процессе настройки проекта, эти расширения могут случайно перекрываться с
расширениями, используемыми в других приложениях. В таком случае Windows Explorer
может неверно истолковать название файла и назначить файлу неверную иконку.
Например, расширение .rmp, используемое для Плана Управления Требованиями
(Requirements Management Plan), также используется для RealJukebox Metadata Packages.
231
В данном случае это не является проблемой. Просто не обращайте внимания на иконку.
RequisitePro распознает данный файл.
У каждого типа документа есть свое расширение файла. Вы можете выбрать и
настроить нужное Вам расширение. Хорошей практикой считается назначать расширения,
несущие смысловую нагрузку (например .vis для Vision), т.к. в каталоге Вы сможете легко
распознать файлы, принадлежащие определенному типу. Не используйте такие
расширения, как .doc или .txt, т.к. эти расширения могут быть случайно открыты с
помощью Microsoft Word или Notepad, а Вы не можете обновлять эти файлы вне среды
RequisitePro.
Пример .rqs – файла:
[Project]
Owner=Peter Z
Name=Online Travel Agency
GUID={CD8E4430-4506-4173-9D06-6245DC2AFD6A}
Description=Project creates an online travel agency system.
Owner Key=2
Revision number=1.0010
Prefix=
NbrRequirements=140
Directory=C:\Program Files\Rational\RequisitePro\Projects
\Online Travel Agency\Online Travel Agency.rqs
Key=1
[Application]
Data file version=1.0040
Program Version=8.23.0068.1
Пример .rql – файла:
[ODBC]
DRIVER=Microsoft Access Driver (*.mdb)
[DBMaint]
CompactDate=2005-07-21 21:42:49
CompactBaselineSize=1495040
CompactPreviousSize=1540096
CompactThresholdSize=10
13.3 Архивация Проектов
Целью архивации является создание копии текущего состояния файлов проекта,
чтобы в дальнейшем Вы могли восстановить их. Вы можете архивировать, используя как
команду RequisitePro Archive (Архивация), так и команду ClearCase Archive. Данный пункт
демонстрирует первый вариант.
Для архивации проекта выполните следующие действия:
1. Выберите
File>Project
Administration>Archive>RequisitePro
Archive
(Файл>
Администрирование Проекта>Архивация>Архив RequisitePro).
2. В диалоговом окне Archive Project (Архивация Проекта), как показано на Рисунке
13.3, выберите каталог.
Рисунок 13.3. Диалоговое окно Archive Project (Архивация Проекта).
232
3. Если необходимо, введите номер версии, наименование версии и описание
изменений.
4. Если Вы хотите применить название версии ко всем документам, выберите
галочку Propagate to all documents (Распространить на все документы).
5. Нажмите кнопку ОК.
6. Если Вы получили сообщение то том, что каталог проекта не существует и Вам
предлагается создать его, нажмите (Yes) Да для создания каталога.
Проектные файлы (.rql, .rqs) и документы копируются в архивный каталог. Для
проектов, используемых базу данных Microsoft Access, также копируется файл .mdb с
базой данных, а база данных обновляется в соответствии с новым местонахождением
документов. Для проектов, используемых базу данных enterprise, файл базы данных не
копируется автоматически, поэтому нужны некие дополнительные действия, такие как
создание файла с помощью логического экспорта или с использованием Data Transport
Wizard. (См. Руководство Пользователя Rational RequisitePro – Rational RequisitePro User’s
Guide[IBM03d]).
Для восстановления проекта из архива выполните следующие действия:
1. Выберите File>Open (Файл>Открыть).
2. В диалоговом окне Open Project (Открыть Проект) нажмите кнопку Add
(Добавить).
3. Выберите файл RQS, содержащий заархивированный проект. Проект добавляется
в список существующих проектов.
4. Двойным щелчком мышки нажмите на названии проекта, либо выберите проект и
нажмите кнопку ОК.
13.4 Перемещение и Копирование Проектов
Вы не можете копировать или перемещать проекты простым копированием
проектных каталогов. Для копирования проекта в новый каталог выполните следующие
действия:
1. Скопируйте проектные файлы (.rqs и .rql) в новый каталог (используя Windows
Explorer).
2. Скопируйте все файлы документов в новый каталог.
3. Если проект использует базу данных Microsoft Access, также скопируйте файл
.mdb.
4. Выберите File>Open Project (Файл>Открыть Проект).
5. Нажмите кнопку Add (Добавить).
6. Выберите проект в новом каталоге для добавления его в список проектов.
7. Если Вам больше не нужен проект в прежнем каталоге, выберите его и нажмите
кнопку Remove (Удалить).
13.5 Трассировка Между Проектами
Трассировка (связь) между проектами позволяет Вам отслеживать требования между
различными проектами. Она используется, если набор требований является общим для
многих проектов, например некие главные требования, которым следуют все проекты в
организации.
Для осуществления трассировки между проектами выполните следующие действия:
1. Назначьте префикс всем проектам, участвующим в трассировке.
2. Отметьте типы требований, которые будут доступны для трассировки.
3. Соедините проекты.
Создадим проект Global, который содержит общие для нескольких других проектов
требования.
Чтобы назначить префикс проекту выполните следующие действия:
1. Откройте проект.
2. Выберите проект в Explorer (Проводнике).
3. Откройте диалоговое окно Project Properties (Свойства Проекта), выбрав
File>Properties (Файл>Свойства).
4. На закладке General (Основное), как показано на Рисунке 13.4, заполните поле
Prefix (Префикс).
233
Рисунок 13.4. Диалоговое окно Project Properties (Свойства Проекта) для проекта Global.
5. Нажмите кнопку ОК.
Чтобы отметить типы требований, доступных для трассировки, выполните следующие
действия:
1. В диалоговом окне Project Properties (Свойства Проекта) выберите закладу
Requirement Types (Типы Требований).
2. Двойным щелчком мышки на типе требований откройте диалоговое окно
Requirement Type (Тип Требований), либо выберите тип требований и нажмите на
кнопку Edit (Редактировать).
3. Выберите галочку Allow External Traceability (Разрешить Внешнюю Трассировку),
как показано на Рисунке 13.5.
4. Нажмите ОК.
5. Выполняйте эти же действия для всех типов требований, которые будут
использованы в трассировке между проектами.
Рисунок 13.5. Разрешение внешней трассировки в диалоговом окне Requirement Type
(Тип Требований).
Чтобы соединить проекты выполните следующие действия:
1. Выберите File>Project Administration>External Projects (Файл>Администрирование
Проекта>Внешние Проекты).
2. Нажмите на кнопку Add (Добавить).
3. Выберите путь к файлу RQS. Проект появится в списке, как показано на Рисунке
13.6.
234
Рисунок 13.6. Добавление проекта в список внешних проектов.
После того как Вы выполнили эти действия, требования из внешних проектов будут
доступны в процессе трассировки. Они отображаются с определенными префиксами, как
это показано на Рисунке 13.7.
Рисунок 13.7. Требования проекта Global доступны для настройки трассировки.
13.6 Заключение
Данная глава представляет несколько полезных операций, которые могут быть
выполнены над проектами.
Распечатка сводки по проекту – это наиболее быстрый способ получения главной
информации о проекте без создания настраиваемого отчета. Более сложные отчет могут
быть созданы с использованием SoDA (см. Главу 12 «Документация»).
Важно время от времени архивировать проект. Некоторые файлы проекта могут быть
повреждены, и их невозможно будет использовать. Восстановление проекта из архивной
версии может сохранить много времени.
Перемещение и копирование проектов может быть полезным при организации
структуры каталогов.
Трассировка между проектами может быть использована для реализации требований,
являющимися общими для многих проектов.
Более детальную информацию об этой информации можно найти в Руководствt
Пользователя Rational RequisitePro – Rational RequisitePro User’s Guide[IBM03d].
Ссылки
[IBM03d] Rational RequisitePro User’s Guide, Version 2003.06.00, IBM Corporation, 2003.
235
ГЛАВА 14
Управление Требованиями
В RUP (Rational Unified Process)
Эта глава объясняет, каким образом представленные в данной книге подходы к
управлению требованиями могут соответствовать IBM Rational Unified Process (RUP). Глава
также рассматривает применение подхода пирамиды к процессам без итераций (таким,
как модель Водопада - Waterfall) и показывает, как перейти от этих процессов в RUP.
14.1 Rational Unified Process (RUP)
RUP – это процесс разработки программного обеспечения. Он представляет собой
рациональный подход к разработке программ [GOR03] путем назначения задач и
обязанностей членам команд с указанием технологического процесса и предоставлением
инструкций.
У этого процесса есть два измерения, как показано на Рисунке 14.1. По
горизонтальной оси располагаются четыре фазы: Inception (Начальная), Elaboration
(Проектирование), Construction (Построение) и Transition (Внедрение). Каждая фаза
состоит из одной или более итераций. На каждой итерации выполняются действия из
различных
областей:
Бизнес-Моделирование
(Business
Modeling),
Requirements
(Требования),
Анализ
и
Проектирование
(Analysis
and
Design),
Реализация
(Implementation), Тестирование (Testing), Развертывание (Deployment), Конфигурация
(Configuration) и Управление Изменениями (Change Management), Управление Проектом
(Project Management) и Программная Среда (Environment). Эти области представлены на
вертикальной оси. Они относятся к определенным действиям, артефактам, исполнителям,
а также технологическому процессу.
В RUP мы выполняем работу параллельно во всех областях. Например, на стадии
Проектирования,
пока
Разработчики
кодируют
некоторую
функциональность,
Специалисты по требованиям работают над остальными требованиями, Тестеры готовят
тестовые сценарии, Менеджеры Проектов пересматривают планы, и т.д. На каждой из
этих четырех фазах работа производится по всем областям, однако основное движение
идет в направлении: от Моделирования и Требований в Начальной фазе, к Реализации и
Тестированию в фазе Построения, а затем к Развертыванию в фазе Внедрения. Все стадии
(кроме Развертывания) начинаются в Начальной фазе. Даже Реализация и Тестирование
(на которых мы проводим больше времени в фазе Построения) начинаются в Начальной
фазе и доходят до Внедрения. График, показанный на Рисунке 14.1, часто называют
«диаграммой вершин» RUP. Размер вершин отражает соответствующие усилия,
потраченные на конкретную задачу на определенной точке жизненного цикла.
236
Фазы
Области
Бизнес-Моделирование
Начальная Проектирование
Inception
Elaboration
Построение
Внедрение
Construction
Transition
Требования
Анализ и Проектирование
Реализация
Тестирование
Развертывание
Конфигурация и Управление Изменениями
Управление Проектом
Программная Среда
Начало
Рисунок 14.1. Два измерения RUP [RUP04].
В конце каждой фазы должна быть достигнута особая контрольная точка (milestone)
[WES03]. Таблица 14.1. представляет эти контрольные точки:
Таблица 14.1. Контрольные точки и Акценты Фаз RUP.
Название
Фазы
Начальная
Название Контрольной
Точки
Объекты Жизненного Цикла
Акцент Фазы
Проектирование
Архитектура Жизненного
Цикла
Формализация требований. Архитектурный
дизайн. Доказательство того, что архитектура
способна поддерживать требования. Как
правило, нужно реализовать от 20 до 30%
системы, чтобы проверить архитектуру и
уменьшить риски.
Построение
Начальное Рабочие
Состояние
Разработка рабочей версии системы. Завершение
всей функциональности.
Внедрение
Релиз Проекта
Развертывание финальной версии системы.
Понимание области применения. Достижение
соглашений по проекту. (Мы должны быть
уверены, что все оговорено и что проект стоит
дальнейших инвестиций). Для этого нам
необходимо высокоуровневое представление
объема работ, план (расписание), отношение
стоимость/прибыль и описание рисков.
Каждая итерация планируется отдельно. В начале каждой итерации готовится План
Итераций (Iteration Plan). Он предоставляет детальное описание действий, которые будут
выполнены, определяет работников и указывает, какие артефакты будут созданы. Каждая
итерация производит некоторую тестируемую часть системы, которая постепенно
добавляется в финальный проект. Артефакты могут быть в следующей форме:
Рабочее программное обеспечение.
Модели (Use Case Model – Модель Сценариев Использования, Object Model –
Объектная Модель и т.д.), обычно описанные в UML.
Документы (Запросов Заинтересованных Лиц, Концепции и т.д.).
237
Для определения того, насколько успешно проведена итерация, можно провести в
конце каждой итерации Оценку Итерации (Iteration Assessment).
Следующие шесть принципов составляют фундамент RUP:
Итеративный процесс разработки программного обеспечения.
Управление требованиями.
Использование архитектур на основе компонентов.
Визуальное моделирование программного обеспечения (в UML).
Непрерывная проверка качества (Это включает проверку не только финального
продукта, но и качества требований, кода, дизайна, плана проекта, тестов и
других элементов разработки системы).
Управление
изменениями
(Это
включает
управление
«действиями»
и
«конфигурацией» - управление процессом изменений, а также измененных
артефактов).
Вы можете настроить RUP для Вашего конкретного проекта. Простая версия может
быть использована для небольших проектов [POL03], а более полный RUP можно
применять к большим проектам. Вы можете использовать продукт IBM, который также
называется «Rational Unified Process», чтобы облегчить настройку процесса [KRO03]. Это
огромная HTML-система поддержки, которая включает шаблоны, инструкции, списки
проверок, руководства по инструментам и путеводители.
Инструменты IBM Rational (такие как RequisitePro и Rational Rose) могут оказать
существенную помощь в реализации RUP. Тем не менее, RUP может также применяться к
тем проектам, которые не используют инструменты IBM Rational.
14.2 Пирамида Требований и RUP
Отношения между действиями, относящимися к определенной области, представлены
в RUP в форме технологического процесса. Рисунок 14.2. показывает технологический
процесс для области Требований [KRU00].
Соответствие высокоуровневых действий этого технологического процесса пирамиде
требований:
Анализ проблем и Понимание Потребностей Заинтересованных Лиц – это два
верхних уровня пирамиды. Они определяют процесс создания документа
Концепции (Vision), а также извлечение функциональных особенностей из
потребностей заинтересованных лиц.
Определение Системы относится к созданию третьего уровня (сценарии
использования и дополнительные требования).
Уточнение Определений Системы добавляет больше деталей на третий уровень.
Управление Объемом Работ Системы состоит из расстановки приоритетов
требованиям на каждом уровне, а также распределения требований по релизам.
Управление Изменениями Требований находится само по себе. Если Вы
формируете требования в форме пирамиды и устанавливаете трассировку
(связь), управление изменениями требований становится довольно ясным.
238
[Новая Система]
[Настоящая Система]
[Новый
Ввод]
Понимание Потребностей
Заинтересованного Лица
Анализ
Проблемы
[Неверная
Проблема]
Управление Изменением
Требований
Направление
Корректной Проблемы
[Нельзя Выполнить
Всю Работу]
Определение
Системы
[Объем
Работы]
Управление
Объемом Работ
в Системе
Уточнение
Определений Системы
Рисунок 14.2. Технологический процесс требований [RUP04].
Технологические процессы отражают только высокоуровневые действия. Диаграммы
деталей технологических процессов показывают действия более подробно, как показано
на Рисунке 14.3. Порядок действий не показан, т.к. обычно многие из них выполняются
одновременно. Таблица 14.2 приводит список всех действий RUP в области требований и
их соответствие пирамиде. Некоторые действия определены в RUP более детально.
Например, шаг создания Сценариев Использования (Use Cases, см. Глава 7 «Создание
Сценариев Использования (Use Cases»)) содержит следующие действия RUP: Найти
Действующих Лиц и Сценарии Использования, Структурировать Модель Сценариев
Использования, Установить Приоритеты Сценариям Использования, Детализировать
Сценарии Использования.
239
Бизнес Правила
Концепция
Потребности
Заинтересованных
Лиц
Дополнительные
Спецификации
План Управления
Требованиями
Атрибуты
Требований
Разработка
Концепции
Управление
Зависимостями
Атрибуты
Требований
Системный
Аналитик
Разработка Общего
Словаря
Словарь
Поиск Действующих
Лиц и Сценариев
Использования
Словарь
Концепция
(уточненный) (уточненная)
Модель Сценариев
Использования
(уточненная)
Модель Сценариев
Использования
Сценарий Использования
(эскиз)
Рисунок 14.3. Диаграмма деталей технологического процесса.
Таблица 14.2. Действия в Области Требований RUP .
RUP Действие
Разработка Плана
Управления Требованиями
Работник
Системный аналитик
Отношение к Пирамиде
Выполняется вначале, перед созданием
пирамиды (см. Главу 3).
Сбор Потребностей
Заинтересованных Лиц
Системный аналитик
Создание верхнего уровня пирамиды (см.
Главу 5).
Создание Общего Словаря
Системный аналитик
Не связано с определенным элементом
пирамиды. Обычно выполняется на уровне
создания Концепции.
Разработка Концепции
Системный аналитик
Концепция создается в то же время, когда на
втором уровне пирамиды определяются
функциональные особенности (см. Главу 6).
Поиск Действующих Лиц и
Сценариев Использования
Системный аналитик
Выполняется в начале создания сценариев
использования (см. Главу 7).
Детали Сценариев
Использования
Специалист по
требованиям
Выполняется в начале создания сценариев
использования (см. Главу 7).
Структурирование Модели
Сценариев Использования
Системный аналитик
Выполняется в начале создания сценариев
использования (см. Главу 7).
Расстановка Приоритетов
Сценариям Использования
Архитектор системы
Выполняется в начале создания сценариев
использования (см. Главу 7).
Детали Требований
Программного Обеспечения
Специалист по
требованиям
Создание дополнительных требований (см.
Главу 8).
Обзор Требований
Технический
обозреватель
Будет применено к требованиям на всех
уровнях.
Управление Зависимостями
Системный аналитик
Будет применено к требованиям на всех
уровнях и к трассировке между требованиями.
240
Помимо действий области требований, также важными являются действия,
относящиеся к проектированию и тестированию.
Несколько действий по проектированию на основе сценариев использования и
других требований вместе с исполнителями, кто предположительно будет выполнять эти
действия (см. Главу 11 «Объектно-Ориентированное Проектирование»):
Анализ Сценариев Использования (дизайнер)
Определение Элементов Дизайна (архитектор системы)
Проектирование Классов (дизайнер)
Обзор Дизайна (технический обозреватель)
Следующие действия по тестированию относятся к извлечению тестовых сценариев
из сценариев использования (см. Главу 8 «Создание Тестовых Сценариев (Test Cases) из
Сценариев Использования» (Use Cases)), а также из дополнительных требований (см.
Главу 10 «Создание Тестовых Сценариев (Test cases) из Дополнительных Требований):
Определение Идей Тестирования (аналитик по тестированию)
Определение Детали Тестирования (аналитик по тестированию)
Выполнение Тестирования (тестер)
Анализ Неудачных Тестов (аналитик по тестированию)
Определение Результатов Тестирования (аналитик по тестированию)
Реализация Структуры Тестирования (дизайнер по тестированию)
Остальная часть этого пункт описывает,
завершаются в течение каждой фазы RUP.
какие
части
пирамиды
требований
Начальная фаза (Inception)
На Начальной фазе (Inception) делается акцент на бизнес-моделировании и сборе
требований. Обычно Начальная фаза состоит из одной или двух итераций. К концу фазы
собирается основная часть (85%) потребностей заинтересованных лиц. Создается
начальная версия документа Концепции (Vision); разрабатывается диаграмма Сценариев
Использования (Use Case); создается начальная версия документа Спецификации
Сценариев Использования (Use Case Specification); определяется большинство сценариев
(алгоритмов, scenario), а также создается Дополнительная Спецификация (Supplementary
Specification). В общем случае, создается примерно от 15 до 50 страниц документации.
Этого вполне достаточно для понимания общей области применения приложения и
технологического процесса. Рисунок 14.1. показывает, какие части пирамиды были
определены. Вы можете удивиться, почему некоторые сценарии помечены как
определенные, хотя еще не были созданы Сценарии Использования, из которых они
трассируются. Причина в том, что для определения сценария (алгоритма) достаточно
начальных сценариев использования. Детали, которые будут описаны в Спецификации
Сценариев Использования (Use Case Specification), могут быть добавлены позже.
Сценарии использования еще не окончены, но некоторые сценарии (алгоритмы) могут
быть уже получены из них.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 14.4. Часть пирамиды, выполненная на Начальной фазе (Inception).
241
На последней итерации Начальной фазы, показанной на Рисунке 14.5, может быть
создан прототип. Он отражает функциональность большинства важнейших сценариев
использования. Довольно часто реализуется один сценарий, поэтому для этого могут быть
созданы диаграммы последовательностей и классов.
Так как одно из главных назначений Начальной фазы – это соглашение по поводу
объема работ в проекте, в конце фазы мы должны получить согласие от клиентов с
предложенными им условиями.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ИСПОЛЬЗОВАНИЯ)
СЦЕНАРИИ
(АЛГОРИТМЫ)
ДИАГРАММЫ ВЗАИМДЕЙСТВИЙ
ДИАГРАММЫ КЛАССОВ
Рисунок 14.5. Часть пирамиды, выполненная на последней итерации Начальной фазы
(Inception).
Проектирование (Elaboration)
Цели фазы Проектирования (Elaboration) – это минимизировать большинство рисков
и спроектировать архитектуру системы (см. Рисунок 14.6). На этой фазе определяется
основная часть (от 80 до 90%) функциональных особенностей, сценариев использования
и дополнительных требований. Как Вы видите, многие сценарии (алгоритмы) и тестовые
сценарии отмечены как завершенные. Это означает, что созданы тестовые сценарии.
Некоторые из них будут выполнены на фазе Проектирования, а остальные – на фазе
Построения (Construction). При использовании метода Водопада (Waterfall), тестовые
сценарии создаются и выполняются на фазе Тестирования. В итеративной разработке
лучше создавать тестовые сценарии пораньше. Тогда если в процессе создания тестовых
сценариев будет обнаружено пропущенное требование, еще не поздно будет добавить и
реализовать его. В процессе этой фазы также завершается основная часть
проектирования (см. Рисунок 14.7). Некоторые диаграммы классов отмечены как
завершенные, но созданы еще не все соответствующие диаграммы взаимодействия. Это
означает, что эти классы спроектированы только частично. Тем не менее, даже частично
спроектированные классы могут быть реализованы и включены в рабочую часть
приложения.
На первой итерации фазы Проектирования мы должны завершить все сценарии
использования, которые представляют большие риски. Реализация этих сценариев
использования должны быть проанализирована с технической точки зрения.
Разрабатывается соответствующая архитектура, способствующая реализации требуемых
сценариев использования. Дополнительные требования достаточно часто влияют на
архитектуру, поэтому все они определяются к концу фазы Проектирования.
242
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 14.6. Элементы пирамиды, выполненные в течение фазы Проектирования
(Elaboration).
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ИСПОЛЬЗОВАНИЯ)
СЦЕНАРИИ
(АЛГОРИТМЫ)
ДИАГРАММЫ ВЗАИМДЕЙСТВИЙ
ДИАГРАММЫ КЛАССОВ
Рисунок 14.7. Элементы пирамиды, выполненные к концу фазы Проектирования
(Elaboration).
К концу фазы проектирования обычно бывает готово от 20 до 30% системы. Это код,
который может тестироваться и демонстрироваться. Построенный к концу фазы
Проектирования код должен показывать, что архитектура системы позволяет
реализовывать все требования. Выполненная часть системы будет включать все элементы
технологий, которые планируется использовать. Будут реализованы и протестированы все
сценарии (алгоритмы), которые помогают проверить архитектуру системы.
Построение (Construction)
Так как разработанный на фазе Проектирования (Elaboration) код принадлежит
фактическому приложению (а не его прототипу) и был проверен на архитектуре, на
итерациях фазы Построения (Construction) мы шаг за шагом начинаем строить базовую
версию системы на основе этой архитектуры.
На фазе Построения создается рабочая версия системы. Это наиболее длинная и
ресурсоемкая фаза. К ее окончанию выполняются все оставшиеся требования. Создаются
оставшиеся тестовые сценарии, заканчивается тестирование (см. Рисунок 14.8). На
ранних итерациях фазы Построения заканчивается разработка диаграмм, как показано на
Рисунке 14.9.
Целью этой фазы является реализация и тестирование всех требований к концу
фазы. Если некоторые требования на настоящий момент еще открыты, они должны быть
спроектированы, реализованы и протестированы к концу фазы.
243
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 14.8. Все элементы пирамиды, выполненные к концу фазы Построения
(Construction).
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ИСПОЛЬЗОВАНИЯ)
СЦЕНАРИИ
(АЛГОРИТМЫ)
ДИАГРАММЫ ВЗАИМДЕЙСТВИЙ
ДИАГРАММЫ КЛАССОВ
Рисунок 14.7. Диаграммы, выполненные на ранних итерациях фазы Построения
(Construction).
Внедрение (Transition)
На
фазе
Внедрения
(Transition)
строится
финальная
версия
системы,
разворачивается и поставляется заказчику. Ключевой точкой этой фазы является
финальный продукт, поэтому все требования должны быть реализованы и
протестированы. Так как все элементы пирамиды предположительно должны быть
выполнены на фазе Построения (Construction), пирамида не изменяется на фазе
Внедрения.
14.3 Пирамида Требований и Модель Водопада (Waterfall)
Подход пирамиды может также быть применен к проектам, не использующим RUP.
Проанализируем, как она бы работала на жизненном цикле модели Водопада при
разработке программного обеспечения. В модели Водопада все уровни пирамиды
представляются последовательно. На каждой фазе производится элемент определенного
уровня.
На фазе Сбора Требований (Requirements Elicitation), показанной на Рисунке 14.10,
собираются все потребности заинтересованных лиц.
244
На фазе Анализа (Analysis), показанной на Рисунке 14.11, бизнес-аналитики
извлекают все функциональные особенности из потребностей. На этой фазе также
определяются сценарии использования и дополнительные требования.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 14.10. На фазе Сбор Требований (Requirements Elicitation) модели Водопада
(Waterfall) создается верхний уровень пирамиды.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 14.11. На фазе Анализа (Analysis) модели Водопада (Waterfall) создаются
функциональные особенности, сценарии использования и дополнительные требования.
При разработке с использованием модели Водопада в конце фазы Проектирования
(Design) завершается создание всех диаграмм (см. Рисунок 14.12).
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ИСПОЛЬЗОВАНИЯ)
СЦЕНАРИИ
(АЛГОРИТМЫ)
ДИАГРАММЫ ВЗАИМДЕЙСТВИЙ
ДИАГРАММЫ КЛАССОВ
Рисунок 14.12. Элементы пирамиды, выполненные к концу фазы Проектирования
(Design) модели Водопада (Waterfall).
245
На фазе Тестирования (Testing), показанной на Рисунке 14.13, мы разрабатываем
тестовые сценарии и выполняем их. Если сценарии (алгоритмы) не были созданы на фазе
Проектирования, они будут созданы на фазе Тестирования. К концу фазы будут запущены
все тестовые сценарии. Если обнаружены некие ошибки, они должны быть исправлены и
протестированы заново.
ПОТРЕБНОСТИ
ФУНКЦИОНАЛЬНЫЕ
ОСОБЕННОСТИ
USE CASES (СЦЕНАРИИ
ДОПОЛНИТЕЛЬНЫЕ
ИСПОЛЬЗОВАНИЯ)
ТРЕБОВАНИЯ
СЦЕНАРИИ
(АЛГОРИТМЫ)
ТЕСТОВЫЕ
ТЕСТОВЫЕ
СЦЕНАРИИ
СЦЕНАРИИ
Рисунок 14.13. Элементы пирамиды, выполненные к концу фазы Тестирования (Testing)
модели Водопада (Waterfall).
Имейте в виду, что определение сценариев (алгоритмов) необходимо для создания
тестовых сценариев, также и как для создания диаграмм последовательностей. В
жизненном цикле модели Водопада проектирование (и соответствующие диаграммы)
создаются перед тестовыми сценариями, потому сценарии (алгоритмы) необходимы на
фазе Проектирования (Design). Тем не менее, в RUP создание тестовых сценариев
происходит достаточно часто на фазе Проектирования (Elaboration), иногда даже перед
разработкой UML- диаграмм. В этом случае исполнители, выполняющие тестовые
сценарии, и дизайнеры должны решить, кто будет извлекать сценарии (алгоритмы) из
сценариев использования. Хорошей практикой считается извлечение сценариев сразу же
после того, как создаются сценарии использования (на фазе Анализа - Analysis).
14.4 Переход от модели Водопада к RUP с Использованием
Пирамиды Требований
Большое различие между процессом в модели Водопада (Waterfall) и RUP – порядок,
в котором мы проходим по пирамиде требований. В модели Водопада мы движемся
горизонтально, пока не будет закончен весь уровень. В итеративных методах на каждой
итерации мы движемся вертикально, завершая часть каждого уровня. Разница
заключается в порядке, в котором выполняются определенные задачи. Каждая итерация
RUP включает несколько требований: сбор, анализ, проектирование, кодирование,
тестирование и развертку.
Главный шаг в переходе от Водопада к RUP - это смена порядка, в котором создаются
элементы пирамиды. Создаваемые в течение проекта документы изменять не нужно. У нас
могут быть: Документ Требований Бизнеса - Концепция (Business Requirements Document
- Vision), Спецификация Требований Программного Обеспечения – Сценарии
Использования и Дополнительная Спецификация (Software Requirements Specification Use Cases and Supplementary Specification), Тестовые Сценарии (Test Cases) и т.д. Может
потребоваться дополнительная документация, такая как Планы Итераций (Iteration Plans).
Помимо реализации итеративной разработки, для полной реализации RUP
необходимо использовать все лучшие практики:
Итеративный процесс разработки программного обеспечения: Мы введем
итерации путем изменения порядка создания элементов пирамиды. Перед каждой
итерацией должен быть создан План Итерации (Iteration Plan). В конце каждой
итерации выполняется Оценка Итерации (Iteration Assessment).
246
Управление требованиями: Использование подхода пирамиды, представленного в
этой книге, позволяет эффективно управлять требованиями и трассировкой
(связями) между различными типами требований. Желательно использование
RequisitePro.
Использование архитектур на основе компонентов: Предлагается использование
объектно-ориентированного проектирования. В зависимости от платформы и
архитектуры системы, компоненты могут формироваться из различных сущностей
(такие как архитектуры EJBs и J2EE).
Визуальное моделирование программного обеспечения (в UML): Использование
UML и любого инструмента для создания диаграмм (например, одного из
инструментов IBM Rational: Rose, Software Architect, Data Architect или Software
Modeler) способствует процессу проектирования (см. Главу 11).
Непрерывная проверка качества: Глава 1 «Управление Требованиями»
представляет атрибуты хороших требований, а Глава 6 «Разработка Документа
Концепции (Vision)» представляет несколько примеров исправления требований.
При разработке тестовых сценариев мы должны быть уверены, что финальный
набор тестовых сценариев покрывает все требования системы (см. подход в Главе
9).
Управление изменениями: После представления нового требования должна быть
проверена трассировка (связь). Использование подхода пирамиды, в особенности
с RequisitePro, способствует реализации трассировки. Использование инструмента
по управлению изменениями, такого как IBM Rational ClearQuest, а также системы
контроля версий, такой как IBM Rational ClearCase, помогает контролировать и
отслеживать изменения.
В итоге мы получаем, что переход от модели Водопада (Waterfall) к RUP не очень
сложный. Но организация процесса требует соблюдения некоторых правил.
14.5 Заключение
Подход с использованием пирамиды требований очень хорошо подходит к RUP.
Создание элементов пирамиды соответствует специфике действий RUP. Тем не менее,
подход пирамиды может также применяться к проектам, которые не используют RUP.
Ссылки
[GOR03] Gornik, Davor. IBM Rational Unified Process: Best Practices for Software
Development, IBM, 2003.
[RUP04] Rational Unified Process, Version 2003.06.13, IBM, 2003.
[WES03] West, David. Planning a Project with the IBM Rational Unified Process, IBM, 2003.
[POL03] Pollice, Gary. Using IBM Rational Unified Process for Small Projects, IBM, 2003.
[KRO03] Kroll, Per, and Philippe Kruchten. The Rational Unified Process Made Easy, Boston:
Addison-Wesley, 2003.
[KRU00] Kruchten, Philippe. The Rational Unified Process: An Introduction, Boston: AddisonWesley, 2000.
247
Часть 4
Резюме
15.
248
Заключение
ГЛАВА 15
Заключение
Представленный в данной книге подход показал Вам, как можно структурировать
процесс управления требованиями путем формирования требований в пирамиду.
15.1 Обобщение Подхода Пирамиды к Процессу Управления
Требованиями
Приведем обобщенное описание данного подхода.
После того, как был создан план управления требованиями, и была завершена
настройка проекта, создаются элементы пирамиды требований:
1. Собираются требования на верхнем уровне пирамиды (запросы заинтересованных
лиц) с использованием различных методов сбора знаний:
Интервью
Анкеты
Семинары
Сценарии приложения
Ролевые игры
Сессии с применением метода «мозгового штурма»
Использование прототипов
Сценарии использования (Use Cases)
Анализ существующих документов
Наблюдение и демонстрирование задач
Анализ существующих систем
2. Бизнес-аналитик извлекает второй уровень пирамиды (функциональные
особенности) из потребностей заинтересованных лиц путем уточнения
требований и перевода их из области проблем в область решений.
Функциональные особенности должны иметь все атрибуты хорошего требования:
Недвусмысленность.
Тестируемость (возможность проверки).
Ясность (краткость, сжатость, простота, точность)
Корректность
Понятность
Правдоподобность (реальность, выполнимость)
Независимость
Элементарность
Необходимость
Независимость от реализации (абстрактность)
Постоянность.
Немногословность.
Завершенность.
Чтобы исправить требования, которые не содержат хотя бы один из этих
атрибутов, Вы можете применить некоторые следующие преобразования:
Копирование
Отмена
Разделение
Завершение
249
Пояснение
Уточнение
Комбинирование
Обобщение
Коррекция
Унификация
Добавление деталей
3. Третий уровень пирамиды содержит сценарии использования и дополнительные
требования. Сценарии использования фиксируют функциональные требования.
Создание сценариев использования состоит из следующих шагов:
1. Определение действующих лиц.
2. Определение сценариев использования.
3. Разработка начальной модели сценариев использования.
4. Структурирование модели.
5. Создание документов сценариев использования.
4. Дополнительные
требования
фиксируют
большинство
нефункциональных
требований. Они могут также содержать некие общие функциональные
требования, которые не связаны со сценариями использования. Дополнительные
требования могут быть классифицированы следующим образом:
Функциональность.
Удобство использования (Доступность, Эстетичность, Соответствие интерфейсу
пользователя, Эргономичность, Легкость в использовании).
Надежность (Работоспособность, Прочность, Точность, Восстанавливаемость,
Отказоустойчивость, Безопасность, Защита, Корректность).
Производительность (Скорость обработки информации, Время ответа, Время
восстановления , Время загрузки/выхода, Емкость, Использование ресурсов).
Способность к сопровождению (Тестируемость, Приспособляемость, Способность к
настройке, Совместимость, Способность к настройке конфигурации, Способность к
обновлению, Способность к установке, Расширяемость, Портативность,
Возможность многократного применения, Взаимодействие, Соответствие
техническим условиям, Взаимозаменяемость, Изменяемость, Способность к
анализу, Способность к аудиту, Способность к локализации).
Ограничение на дизайн.
Требования реализации.
Требования интерфейса.
Требования аппаратного обеспечения.
Требования документации.
Требования лицензий и юридических норм.
5. Тестовые сценарии создаются для тестирования требований на третьем уровне.
Для извлечения тестовых сценариев из сценариев использования применяются
следующие шаги:
1. Создание сценариев (алгоритмов).
2. Определение переменных для каждого шага сценариев использования.
3. Определение существенно разных вариантов для каждой переменной.
4. Комбинирование вариантов для тестирования в тестовые сценарии.
5. Определение значений переменным.
6. Для создания тестовых сценариев из дополнительных требований Вы можете
использовать один из следующих подходов:
Выполнение выбранных тестовых сценариев в различных программных
средах.
Добавление дополнительной проверки во все сценарии использования.
Проверка и обновление определенных сценариев использования.
Выполнение задач.
Список проверок.
Анализ.
Тестирование по принципу «Стеклянного Ящика».
Автоматическое тестирование.
250
7. Диаграммы проектирования также извлекаются из требований на третьем уровне,
особенно из сценариев использования. Возможные подходы:
Проектирование классов, которые будут содержать требуемые данные и
функциональность.
Создание одной диаграммы последовательности для каждого сценария
(алгоритма).
Одновременно добавлять требуемые методы и атрибуты в класс на
диаграмме классов.
8. Документация создается из различных элементов пирамиды.
15.2 Преимущества
Несколько преимуществ представленного в данной книге подхода по управлению
требованиями:
Легкость в реализации трассировки (установки связи) между различными типами
требований. Благодаря трассировке можно легко убедиться, что ни одно
требование не было забыто. Она также помогает отследить источник требования.
Понятное отличие между необработанными требованиями, назначенными
заинтересованными лицами, и требований, извлеченными бизнес-аналитиком.
Разумное количество тестовых сценариев обеспечивает хорошее покрытие
требований.
Легкость отслеживания прогресса.
15.3 RequisitePro
Использование инструмента по управлению требованиями RequisitePro может
значительно способствовать процессу управления требованиями. RequisitePro – это
надежный инструмент, содержащий все аспекты пирамиды требований:
Обеспечивает возможность ввода различных типов требований и их атрибутов.
Обеспечивает трассировку (связь) между требованиями.
Обладает хорошими возможностями генерации отчетов.
Предоставляет шаблоны документов.
Мы показали, как использовать RequisitePro для Ваших специфичных задач по
управлению требованиями. Некоторые основные задачи, которые позволяют Вам
использовать RequisitePro для управления требованиями:
Настройка проекта RequisitePro.
Создание документов.
Создание требований.
Настройка атрибутов требований.
Использование представлений для анализа требований.
Настройка трассировки.
Создание нового типа требований.
Создание нового типа документов.
Желаем Вам удачи в осуществлении эффективного управления требованиями!
251
Приложение
Пример
Плана Управления Требованиями
1 Введение
1.1 Назначение
Данный документ описывает инструкции, используемые в проекте для создания
документов требований, типов требований и атрибутов требований. Он также описывает
трассировку (связь) между различными типами требований, которая будет обновляться в
течение всего жизненного цикла проекта. Он служит конфигурационным документом для
инструмента RequisitePro. Целью трассировки требований является уменьшение
количества ошибок, которые могут быть найдены позже в процессе разработки.
Уверенность в том, что все требования были сохранены в требованиях к программному
обеспечению, проектировании и тестовых сценариях, повышает качество программного
обеспечения.
1.2 Область Применения
Данный план следует всем стадиям проекта.
1.3 Обзор
Параграф 2 описывает инструменты, которые будут использоваться для управления
требований.
Параграф 3.1 описывает элементы трассировки и определяет, как они будут
называться, отмечаться и нумероваться.
Параграф 3.2 описывает типы требований, используемые в качестве элементов
трассировки.
Параграф 3.3 описывает трассировку – какие элементы требований трассируются в
другой тип требований.
Параграф 3.4 описывает предлагаемые атрибуты для каждого типа требований.
2 Инструменты, Программная Среда и Инфраструктура
Для управления требований будет использоваться инструмент RequisitePro. Атрибуты
требований и трассировки будут храниться в базе данных RequisitePro. Члены команды, у
кого нет доступа к RequisitePro, будут использовать Microsoft Word. Некоторые диаграммы
будут созданы в Rational Rose и затем преобразованы в документы RequisitePro.
3 Документы и Типы Требований
3.1 Документы
Следующие документы будут созданы в проекте:
252
Тип Документа
Описание
Тип Требования по
Умолчанию
Stakeholder Request
(STRQ – Запрос
Заинтересованного
Лица)
Feature (FEAT –
Функциональная
Особенность)
Stakeholder Requests (STR –
Запросы Заинтересованных Лиц)
Ключевые запросы
заинтересованных лиц
Vision (VIS - Концепция)
Полное описание системы и
специфичные требования
Use Case Specification (UCS –
Спецификация Сценариев
Использования)
Описание Сценариев
Использования
Use Case (UC - Сценарий
Использования)
Glossary (GLS - Справочник)
Используется для хранения
основных терминов
Glossary Item (TERM –
Термин Справочника)
Supplementary Specification (SS –
Дополнительная Спецификация)
Нефункциональные требования
Supplementary
Requirements (SUPLДополнительные
Требования)
Requirements Management Plan
(RMP – План Управления
Требованиями)
Данный документ
Нет требований
3.2 Типы Требований
Данный параграф описывает элементы трассировки и определяет, как они будут
называться, отмечаться и нумероваться. Элемент трассировки – это любой элемент
проекта, который должен быть точно трассирован из другого элемента текста или модели,
чтобы отследить зависимости между ними. В RequisitePro элементы трассировки
представлены отдельными типами требований RequisitePro. Следующая таблица
описывает все типы требований, используемые в проекте.
Элемент Трассировки (Тип
Требования)
Stakeholder Requests (STRQ –
Запросы Заинтересованных Лиц)
Артефакт (Тип
Документа)
Vision (STR) - Концепция
Описание
Feature (FEAT – Функциональная
Особенность).
Vision (VIS) – Концепция
Условия системы и
функциональные возможности.
Use Case (UC – Сценарий
Использования)
Use Case (UC) – документы
Сценариев Использования
Сценарии Использования,
содержащие все
функциональные требования.
Supplementary Requirement (SUPLДополнительное Требование)
Supplementary Specification
(SS – Дополнительная
Спецификация)
Нефункциональные
требования, которые не
отражены в модели сценариев
использования.
Ключевые запросы
заинтересованных лиц. Они
описывают требования
высокого уровня.
3.3 Трассировка
Рисунок А.1 показывает структуру трассировки, используемую в проекте.
253
Рисунок А.1. Диаграмма трассировки.
STRQ
(Потребности
Заинтересованных
Лиц)
будут трассироваться в FEAT
(Функциональные Особенности), определенные в документе Vision (Концепции), и в SUPL
(Дополнительные
Требования),
определенные
в
Supplementary
Specification
(Дополнительной Спецификации).
FEAT (Функциональные Особенности) будут трассироваться в UC (Сценарии
Использования) или в SUPL (Дополнительные Требования). Каждая подтвержденная
функциональная особенность может быть трассирована, по крайней мере, в один UC или
SUPL. Также могут присутствовать отношения многие-ко-многим между FEAT, UC и SUPL.
UC (Сценарии Использования), определенные в Use Case Specification (UCS –
Спецификация Сценариев Использования), будут трассироваться обратно в FEAT
(Функциональные Особенности).
SUPL (Дополнительные Требования), будут трассироваться обратно в FEAT
(Функциональные Особенности).
3.4 Атрибуты Требований
3.4.1 Атрибуты для Функциональных Особенностей (FEAT)
Status (Статус)
Отслеживает прогресс разработки требования от начальной стадии до финальной
проверки.
Значение Атрибута
Proposed (Предполагаемый)
Описание
Описывает функциональные особенности, которые находятся в
стадии принятия решения. Они не были еще пересмотрены и
подтверждены.
Approved (Подтвержденный)
Функциональные особенности, подтвержденные для
дальнейшего проектирования и разработки.
Realized (Реализованный)
Функциональная особенность на стадии проектирования.
Диаграммы Rational Rose отражают эту функциональную
особенность.
Incorporated (Включенный)
Функциональная особенность, включенная в проект.
Validated (Проверенный)
Функциональная особенность, протестированная и проверенная
на правильность работы.
Priority (Приоритет)
Определяет приоритет
разработки.
Значение Атрибута
High (Высокий)
Medium (Средний)
требования
для
назначения
Описание
Высокий приоритет.
Средний приоритет.
254
определенным
ресурсам
Low (Низкий)
Низкий приоритет. Выполнение этой функциональной
особенности менее критично и может быть отложено на
последующие итерации или релизы.
Benefit (Выгода)
Выгода и важность требования для конечных пользователей и заказчиков.
Значение Атрибута
Critical (Критичный)
Описание
Существенные функциональные особенности. Их
невыполнение означает, что система не удовлетворяет
потребностям заказчика. Все критические функциональные
особенности должны быть выполнены в релизе, либо график
разработки должен быть пересмотрен.
Important (Важный)
Функциональные особенности, важные для эффективности
системы и производительности большинства приложений. Они
не могут быть реализованы в каком-либо другом виде.
Useful (Полезный)
Функциональные особенности, которые будут использоваться
менее часто, или предназначенные для возможного достижения
каких-либо решений. Если этот элемент не будет включен в
релиз, это не повлечет за собой значительных отрицательных
последствий по отношению к прибыли или нуждам заказчика.
Effort (Усилия)
Устанавливается командой разработчиков. Должен быть выражен
количестве времени работы лиц, количестве дней на разработку системы.
в
общем
Risk (Риск)
Возможность, что выполнение требования повлечет за собой нежелательные
события, такие как лишние усилия, высокое количество ошибок, низкое качество и
производительность. Достаточно разделить технические риски каждого сценария
использования на высокие, средние и низкие.
Значение Атрибута
High (Высокий)
Medium (Средний)
Low (Низкий)
Описание
Серьезные последствия риска вместе с высокой возможностью
его возникновения.
Последствия риска менее критичные, а возможность
возникновения меньше.
Последствия риска минимальны, а возможность возникновения
риска мала.
Stability (Устойчивость)
Возможность, что будущее изменится, или же у команды изменится понимание
функциональной особенности. Используется для содействия при оценке приоритетов
разработки и определения элементов, для которых требуются дополнительный анализ.
Target Release (Планируемый Релиз)
Планируемый релиз может быть выражен в качестве названия итерации, в котором
функциональная особенность будет включена в программное обеспечение.
Assigned To (Исполнитель)
Функциональные особенности могут быть назначены лицам, ответственным за
дальнейшее исследование, оформление требований программного обеспечения и
реализации.
255
Reason (Причина)
Это текстовое поле используется для отслеживания источника требуемой
функциональной особенности. Требования существуют по различным причинам. Это поле
содержит объяснение или ссылку на объяснение.
3.4.2 Атрибуты для Потребностей Заинтересованных Лиц (STRQ)
Атрибуты те же, что и для FEAT кроме Target Release (Планируемого Релиза):
Status (Статус)
Priority (Приоритет)
Benefit (Выгода)
Effort (Усилия)
Risk (Риск)
Stability (Устойчивость)
Reason (Причина)
3.4.3 Атрибуты для Сценариев Использования (UC)
Атрибуты те же, что и для FEAT. Дополнительный атрибут – Actor (Действующее
Лицо).
Actor (Действующее Лицо)
Описывает, какое действующее лицо инициирует данный сценарий использования.
Остальные атрибуты те же, что и для FEAT:
Status (Статус)
Priority (Приоритет)
Benefit (Выгода)
Effort (Усилия)
Risk (Риск)
Stability (Устойчивость)
Target Release (Планируемый Релиз)
Reason (Причина)
3.4.4 Атрибуты для Дополнительных Требований (SUPL)
Атрибуты те же, что и для FEAT:
Status (Статус)
Priority (Приоритет)
Benefit (Выгода)
Effort (Усилия)
Risk (Риск)
Stability (Устойчивость)
Target Release (Планируемый Релиз)
Reason (Причина)
3.5 Отчеты и Измерения
Будут созданы представления для отображения следующих отчетов:
Attribute Matrix (Матрица Атрибутов), показывающая все требования определенного типа:
Все Потребности Заинтересованных Лиц
Все Функциональные Особенности
Все Дополнительные Требования
Все Сценарии Использования
Traceability Matrix (Матрица Трассировки):
Трассировка STRQ в FEAT
Трассировка FEAT в UC
Трассировка FEAT в SUPL
STRQ не трассированы в FEAT
256
FEAT не трассированы в UC или SUPL
FEAT не трассированы в STRQ
UC не трассированы в FEAT
SUPL не трассированы в FEAT
Traceability Tree (Дерево Трассировки):
Дерево Трассировки: из STRQ
Дерево Трассировки: в UC
Дерево Трассировки: в SUPL
257
