
- •Часть 1 13
- •Глава 1 14
- •Глава 2 29
- •Часть 2 36
- •Глава 3 37
- •5.6 Заключение 86
- •Глава 6 87
- •6.4 Заключение 108
- •Глава 7 108
- •7.9 Заключение 129
- •Глава 8 130
- •8.7 Заключение 155
- •Глава 9 157
- •9.6 Заключение 176
- •Глава 10 178
- •10.10 Заключение 194
- •Глава 11 195
- •11.4 Заключение 218
- •Глава 12 220
- •14.5 Заключение 246
- •Часть 4 246
- •Глава 15 247
- •3.1 Документы 251
- •Часть 1 Обзор
- •Глава 1
- •1.1 Определение Требования и Заинтересованного Лица
- •1.2 Пирамида Требований
- •1.3 Трассировка (Связь) между Требованиями
- •1.4 Характеристики Хорошего Требования
- •1.5 Обзор Процесса Управления Требованиями
- •Глава 3 «Формирование Плана Управления Требованиями» детально описывает все эти пункты.
- •Глава 8 «Дополнительная Спецификация» детально описывает этот тип требований.
- •1.6 Заключение
- •Глава 2
- •2.1 Интерфейс
- •Окно Проводника Панель Инструментов Область Представлений Описание
- •Views (Область Представлений)
- •2.2 Рабочее Пространство Word
- •2.3 Документы
- •2.4 Требования
- •2.5 Заключение
- •Часть 2
- •Глава 3
- •3.1 Когда Создается Документ rmp
- •3.2 Решения, Которые Могут Быть Оформлены в Документе rmp
- •Глава 1 «Управление Требованиями» перечисляет решения, которые должны быть приняты при создании документа rmp. В следующих пунктах мы обсудим каждое решение и влияющие на него факторы.
- •Глава 12 «Документация» содержит более детальное описание документов, которые, возможно, будет необходимо создать.
- •3.4 Заключение
- •Глава 4
- •4.3 Заключение
- •Глава 5
- •5.6 Заключение
- •Глава 6
- •6.4 Заключение
- •Глава 7
- •7.9 Заключение
- •Глава 8
- •Время ответа
- •Время обработки
- •Число одновременных пользователей
- •Время обработки отчета
- •8.7 Заключение
- •Глава 9
- •9.6 Заключение
- •Глава 10
- •10.10 Заключение
- •Глава 11
- •11.4 Заключение
- •Глава 12
- •12.4 Заключение
- •Часть 3
- •Глава 13
- •13.6 Заключение
- •Глава 14
- •14.5 Заключение
- •Часть 4
- •Заключение
- •Глава 15
- •3.1 Документы
Время ответа
Рисунок 8.2. Точная Степень Удовлетворенности (Sharp Satisfaction Shape).
Умеренная Форма Удовлетворенности (Medium Satisfaction Shape)
Предположим, что в некоторой системе batch-файлы и транзакции с предыдущего дня обрабатываются ночью. Лицо, ответственное за анализ результатов ночного batch-процесса, приходит в офис в 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 пользователей.
Время обработки отчета
Рисунок 8.5. Линейная Форма Удовлетворенности (Linear Satisfaction Shape).
8.5 Ввод Дополнительных Требований в RequisitePro
Как и любые другие требования, мы можем ввести дополнительные требования в RequisitePro тремя разными способами:
Прямо из Explorer (Проводника).
Из представления (view).
Создание Дополнительной Спецификации (Supplementary Specification), а затем добавление требования из документа.
Для добавления требования из Explorer (Проводника) выполните следующие действия:
Правой кнопкой мышки нажмите на папке Supplementary Requirements (Дополнительные Требования) и выберите New>Requirement (Новое>Требование).
Заполните поля в диалоговом окне Requirement Properties (Свойства Требования).
В некоторых шаблонах представление All Supplementary Requirements (Все Дополнительные Требования) уже создано. Если Вы работаете с шаблоном, не содержащим это предустановленное по умолчанию представление, выполните следующие действия для его создания:
Правой кнопкой мышки нажмите на папке Supplementary Requirements (Дополнительные Требования) и выберите New>View (Новое>Представление).
В диалоговом окне View Properties (Свойства Представления), как показано на Рисунке 8.6, View Type (Тип Представления) должен быть Attribute Matrix (Матрица Атрибутов), а Row Requirement Type (Тип Требования в Строке) должен быть SUPL.
Рисунок 8.6. Диалоговое окно View Properties (Свойства Представления).
Добавление требований из представления включает следующие действия:
В окне Explorer (Проводника), двойным щелчком мышки нажмите на представлении All Supplementary Requirements (Все Дополнительные Требования).
В представлении, нажмите на последнюю строку с текстом «Нажмите здесь для создания требования».
Введите Name (Название) и Text (Текст).
Большое преимущество третьего подхода (создание Дополнительной Спецификации - Supplementary Specification и затем добавления требования из документа) в том, что мы можем распечатать внутренний документ и использовать его в качестве коммуникаций с заказчиком. Иногда этот документ даже используется как часть контракта с заказчиком.
Для создания Дополнительной Спецификации (или, если Вы следуете текущей конвенции наименований в RUP, Дополнительных Спецификаций) выполните следующие действия:
Правой кнопкой мышки нажмите на папке Supplementary Requirements (Дополнительные Требования) и выберите New>Document (Новый>Документ).
Заполните поля в диалоговом окне 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 (Требование по Лицензиям)
12. Legal, Copyright, and Other Notices (Юридические Нормы, Авторское Право и Другие Заметки)
13. Applicable Standards (Допустимые Стандарты).
Требования располагаются в определенных пунктах согласно типу. Они могут быть выделены в отдельные пункты, как показано на Рисунке 8.8, а могут быть сгруппированы, как показаны на Рисунке 8.9.
Рисунок 8.8. Каждое требование в отдельном заголовке.
Рисунок 8.9. Несколько требований, скомбинированных под одним заголовком.
После написания требований в виде свободного текста в документе Microsoft Word Вы должны добавить их в базу данных:
Выделите текст, который описывает требование.
Выберите RequisitePro>Requirement>New (Требование>Новое), либо правой кнопкой мышки нажмите на тексте и выберите Create Requirement (Создать Требование), либо нажмите на иконку New Requirement (Новое Требование) в панели инструментов.
Заполните поля в диалоговом окне Requirement Properties (Свойства Требования) на закладке General (Основное), как показано на Рисунке 8.10. Выберите SUPL в качестве Type (Типа).
Рисунок 8.10. Диалоговое окно Requirement Properties (Свойства Требования).
Если сейчас Вы хотите установить атрибуты сейчас, нажмите на закладку Attributes (Атрибуты) для изменения значений атрибутов (Вы также можете сделать это позже).
Если сейчас Вы хотите установить трассировку (связь), нажмите на закладку Traceability (Трассировка) для определения того, из какого требования было получено каждое требование (Вы также можете сделать это позже).
После сохранения требований в базе данных Вы можете выделить целое описание, либо только одно предложение, описывающее требование. Если вся идея выражена одним предложением, а остальные предложения просто поясняют требование, достаточно сохранить только одно предложение, как показано на Рисунке 8.11. Однако если для понимания требования необходимо несколько предложений, можно добавить и длинное описание, как показано на Рисунке 8.12. Преимущество выделения полного описания в том, что оно позволяет осуществлять автоматическую проверку подозрительных связей при изменении требований.
Рисунок 8.11. Сохранение только первого предложения требования в базу данных.
Рисунок 8.12. Сохранение нескольких предложений, описывающих требование, в базу данных.
Когда требования хранятся в базе данных, но документ еще не сохранен, они помечаются префиксом SUPLpending, как показано на Рисунке 8.13. После сохранения документы, префикс меняется на SUPL, как показано на Рисунке 8.14.
Рисунок 8.13. Префикс требований до сохранения документа.
Рисунок 8.14. Префикс требований после сохранения документа.
После сохранения всех требований в базе данных, они появляются в окне Explorer (Проводника), как показано на Рисунке 8.15.
Рисунок 8.15. Дополнительные требования в Explorer (Проводнике) RequisitePro.
8.6 Трассировка к Дополнительным Требованиям
Большинство дополнительных требований трассируются из функциональных особенностей. В зависимости от рекомендаций к проекту, мы можем разрешить их трассировку прямо из потребностей заинтересованных лиц. Мы также можем разрешить требованиям быть добавленными напрямую на уровень дополнительных требований. Тем не менее, эти решения должны приниматься при разработке Плана Управления Требованиями (RMP). Они не должны приниматься спонтанно при завершении работы над Дополнительной Спецификацией (Supplementary Specification).
Установка Атрибута Тип (Type) Функциональным Особенностям
Чтобы облегчить установку трассировки из функциональных особенностей в дополнительные требования, стоит установить значения атрибута Type (Тип) для функциональных особенностей. В зависимости от используемой Вами версии RequisitePro, этот атрибут может быть уже определен. В версии 2003.06.13 этот атрибут имеет следующие значения:
|
|
|
|
|
|
Вы можете использовать предустановленные значения, или же изменить их на более подходящие Вам значения. Например, если Вы хотите меньшую детализацию, Вы можете использовать только четыре значения:
Functional: UC specific (Функциональный: Связан со Сценарием Использования).
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 (Тип) отсутствует в таблице, Вам нужно добавить его в представление, выполнив следующие действия:
Правой кнопкой мышки нажмите на заголовке строки представления и выберите Displayed Attributes (Отображаемые Атрибуты).
В левом окне выберите атрибуты, которые Вы хотите увидеть в представлении, как показано на Рисунке 8.17.
В правом окне Вы можете установить порядок, в котором атрибуты будут появляться.
Рисунок 8.17. Выбор атрибутов, которые будут отображаться в представлении.
Чтобы установить атрибуты нескольким требованиям выполните следующие действия:
Двойным щелчком мышки нажмите представлении All Features (Все Функциональные Особенности) в папке Features and Vision (Функциональные Особенности и Концепция).
Двойным щелчком мышки нажмите на ячейке в пересечении колонки Type (Тип) и строки с требованием, которое Вы хотите изменить.
Выберите соответствующее значение из списка, как показано на Рисунке 8.18.
Рисунок 8.18. Выбор значений атрибутов из представления.
Установка Трассировки (Связей)
Если представление в виде Матрицы Трассировки (Traceability Matrix) из FEAT в SUPL еще не настроено, Вы можете создать его, выполнив следующие действия:
Правой кнопкой мышки нажмите на папке Supplementary Requirements (Дополнительные Требования) и выберите New>View (Новое>Представление).
В диалоговом окне View Properties (Свойства Представления), как показано на Рисунке 8.19, View Type (Тип Представления) должен быть Traceability Matrix (Матрица Трассировки), Row Requirement Type (Тип Требования в Строке) должен быть SUPL, а Column Requirement Type (Тип Требования в Столбце) должен быть FEAT.
Рисунок 8.19. Диалоговое окно View Properties (Свойства Представления) для Матрицы Трассировки (Traceability Matrix).
Это представление может быть создано с требованиями FEAT в строках и SUPL в столбцах.
Так как в эту матрицу нам не нужно включать функциональные особенности, которые уже были отображены в сценариях использования, мы можем создать запрос, чтобы показывать только те функциональные особенности, которые не относятся к сценариям использования:
Нажмите на кнопку Query (Запрос) напротив FEAT.
В диалоговом окне Select Attribute (Выбор Атрибута), как показано на Рисунке 8.20, выберите Type (Тип) в качестве названия атрибута.
Рисунок 8.20. Выбор атрибута, на основании которого мы хотим фильтровать требования.
Нажмите ОК в диалоговом окне Select Attribute (Выбор Атрибута).
В диалоговом окне Query Requirements (Запрос Требований), как показано на Рисунке 8.21, выберите в левом окне нужные значения.
Нажмите ОК в диалоговом окне Query Requirements (Запрос Требований).
Нажмите ОК в диалоговом окне Query Column Requirements (Запрос к Требованиям в Столбце), как показано на Рисунке 8.22.
Рисунок 8.21. Выбор значений атрибута, на основании которого мы хотим фильтровать требования.
Рисунок 8.22. Добавление критерия запроса в диалоговом окне Query Column Requirements (Запрос к Требованиям в Столбце).
Нажмите ОК в диалоговом окне View Properties (Свойства Представления), как показано на Рисунке 8.19.
Представление отображает только функциональные особенности, имеющие один из выбранных значений атрибута Type (Тип).
Для установки трассировки (связей), выполнив следующие действия:
Правой кнопкой мышки нажмите на пересечении функциональной особенности и соответствующего дополнительного требования.
Выберите Traced Frоm (Трассируется Из) или Traced To (Трассируется В) в зависимости от того, что у Вас находится в строках и от Вашей интерпретации направления трассировки.
После установки трассировки (связей) Вы можете анализировать ее как в Матрице Трассировки (Traceability Matrix, см. Рисунок 8.23), так и в Дереве Трассировки (Traceability Tree, см. Рисунок 8.24). Дерево Трассировки позволяет Вам увидеть весь путь от запросов заинтересованного лица.
Рисунок 8.23. Traceability Matrix (Матрица Трассировки) из FEAT в SUPL.
Рисунок 8.24. Traceability Tree (Дерево Трассировки) в SUPL.
Создание Запросов для Требований
После установки трассировки (связей) Вы можете проверить, были ли охвачены все функциональные особенности, относящиеся к дополнительным требованиям. Вы можете сделать это с использованием представления Матрицы Трассировки (Traceability Matrix) или Дерева Трассировки (Traceability Tree).
Нам необходимо отфильтровать функциональные особенности одновременно по двум критериям:
Фильтр 1: Функциональные особенности, у которых есть атрибут Type (Тип), приемлемый для дополнительных требований.
Фильтр 2: Функциональные особенности, которые не трассируются в дополнительные требования.
В представлении Traceability Requirements Traced From Features (Трассировка Требований из Функциональных Особенностей), первый фильтр уже применен к требованиям столбца, так что нам нужно установить только второй фильтр:
Выберите View>Query Column Requirements (Представление>Запрос к Требованиям в Столбце).
Нажмите кнопку Add (Добавить) в диалоговом окне Query Column Requirements (Запрос к Требованиям в Столбце).
Выберите Traced To (Трассируется В) в диалоговом окне Select Attribute (Выбор Атрибута), как показано на Рисунке 8.25.
Рисунок 8.25. Выбор атрибута, на основании которого будет осуществляться фильтрация.
Нажмите ОК в диалоговом окне Select Attribute (Выбор Атрибута).
Выберите SUPL в левом окне диалогового окна Query Requirements (Запрос Требований), как показано на Рисунке 8.26.
Рисунок 8.26. Выбор нужной трассировки.
Выберите Not Traced (Не Трассируются).
Нажмите ОК в диалоговом окне Query Requirements (Запрос Требований).
Нажмите ОК в диалоговом окне Query Column Requirements (Запрос к Требованиям в Столбце), которое теперь показывает оба фильтра (см. Рисунок 8.27).
Рисунок 8.27. Все фильтры, примененные к требованиям.
Мы ожидаем получить пустое представление, как показано на Рисунке 8.28. Если на нем отображается какая-либо функциональная особенность, она требует тщательного анализа. Возможно, мы забыли добавить дополнительные требования, удовлетворяющие данной функциональной особенности, или мы сделали ошибку в установке трассировки (связей) или установки атрибута Type (Тип).
Рисунок 8.28. Пустое представление после применения обоих условий.