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: Addison-

Wesley, 2000.

Часть 4

Резюме

15. Заключение

Глава 15

Заключение

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

15.1 Обобщение Подхода Пирамиды к Процессу Управления Требованиями

Приведем обобщенное описание данного подхода.

После того, как был создан план управления требованиями, и была завершена настройка проекта, создаются элементы пирамиды требований:

1. Собираются требования на верхнем уровне пирамиды (запросы заинтересованных лиц) с использованием различных методов сбора знаний:

• Интервью

• Анкеты

• Семинары

• Сценарии приложения

• Ролевые игры

• Сессии с применением метода «мозгового штурма»

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

• Сценарии использования (Use Cases)

• Анализ существующих документов

• Наблюдение и демонстрирование задач

• Анализ существующих систем

2. Бизнес-аналитик извлекает второй уровень пирамиды (функциональные особенности) из потребностей заинтересованных лиц путем уточнения требований и перевода их из области проблем в область решений. Функциональные особенности должны иметь все атрибуты хорошего требования:

• Недвусмысленность.

• Тестируемость (возможность проверки).

• Ясность (краткость, сжатость, простота, точность)

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

• Понятность

• Правдоподобность (реальность, выполнимость)

• Независимость

• Элементарность

• Необходимость

• Независимость от реализации (абстрактность)

• Постоянность.

• Немногословность.

• Завершенность.

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

Копирование	Отмена
Разделение	Завершение
Пояснение	Коррекция
Уточнение	Унификация
Комбинирование	Добавление деталей
Обобщение

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

1. Определение действующих лиц.

2. Определение сценариев использования.

3. Разработка начальной модели сценариев использования.

4. Структурирование модели.

5. Создание документов сценариев использования.

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

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

• Удобство использования (Доступность, Эстетичность, Соответствие интерфейсу пользователя, Эргономичность, Легкость в использовании).

• Надежность (Работоспособность, Прочность, Точность, Восстанавливаемость, Отказоустойчивость, Безопасность, Защита, Корректность).

• Производительность (Скорость обработки информации, Время ответа, Время восстановления , Время загрузки/выхода, Емкость, Использование ресурсов).

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

• Ограничение на дизайн.

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

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

• Требования аппаратного обеспечения.

• Требования документации.

• Требования лицензий и юридических норм.

5. Тестовые сценарии создаются для тестирования требований на третьем уровне. Для извлечения тестовых сценариев из сценариев использования применяются следующие шаги:

1. Создание сценариев (алгоритмов).

2. Определение переменных для каждого шага сценариев использования.

3. Определение существенно разных вариантов для каждой переменной.

4. Комбинирование вариантов для тестирования в тестовые сценарии.

5. Определение значений переменным.

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

• Выполнение выбранных тестовых сценариев в различных программных средах.

• Добавление дополнительной проверки во все сценарии использования.

• Проверка и обновление определенных сценариев использования.

• Выполнение задач.

• Список проверок.

• Анализ.

• Тестирование по принципу «Стеклянного Ящика».

• Автоматическое тестирование.

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

• Проектирование классов, которые будут содержать требуемые данные и функциональность.

• Создание одной диаграммы последовательности для каждого сценария (алгоритма).

• Одновременно добавлять требуемые методы и атрибуты в класс на диаграмме классов.

8. Документация создается из различных элементов пирамиды.

15.2 Преимущества

Несколько преимуществ представленного в данной книге подхода по управлению требованиями:

• Легкость в реализации трассировки (установки связи) между различными типами требований. Благодаря трассировке можно легко убедиться, что ни одно требование не было забыто. Она также помогает отследить источник требования.

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

• Разумное количество тестовых сценариев обеспечивает хорошее покрытие требований.

• Легкость отслеживания прогресса.

15.3 RequisitePro

Использование инструмента по управлению требованиями RequisitePro может значительно способствовать процессу управления требованиями. RequisitePro – это надежный инструмент, содержащий все аспекты пирамиды требований:

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

• Обеспечивает трассировку (связь) между требованиями.

• Обладает хорошими возможностями генерации отчетов.

• Предоставляет шаблоны документов.

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

• Настройка проекта RequisitePro.

• Создание документов.

• Создание требований.

• Настройка атрибутов требований.

• Использование представлений для анализа требований.

• Настройка трассировки.

• Создание нового типа требований.

• Создание нового типа документов.

Желаем Вам удачи в осуществлении эффективного управления требованиями!

Приложение

Пример

Плана Управления Требованиями

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 Документы и Типы Требований