Управление требованиями
Практикум Упражнение 9
Системный аналитик выявляете требований 
и моделирует прецеденты, выделяя функциональные возможности и границы системы. Например, устанавливая, какие субъекты и прецеденты существуют и как они взаимодействуют
Системный аналитик
(from Актеры)
9. Создание требования возможности
Упражнение 9. Создание требования возможности
Раньше, в Упражнении 5, Вы получили и обработали с использованием ClearQuest запрос расширения по предложению, присланному Вами же по электронной почте.
Пришло время преобразовать этот запрос в требование к разрабатываемому программному обеспечению.
Создание нового требования в документе "Концепция"
Вы могли бы образовать новое требование непосредственно из ClearQuest. Но особенностью Requisite Pro является то, что иерархии требований должны постоянно храниться либо в документе, либо в базе данных. А наше требование возможности нужно поместить в иерархию "Интернет-магазин компании ClassicsCD.Com", которая создавалась в документе "Концепция".
1.Запустите RequisitePro и откройте проект ClassicsCD WebShop. Вы это уже делали.
2.Откройте документ "ClassicsCD Концепция системы" в папке "Концепция и возможности системы".
3.Познакомьтесь со структурой и содержанием документа.
Вы можете убедиться, что требования, касающегося необходимости уведомления заказчика о дате выполнения заказа, в документе нет.
4.Переместитесь в конец последней строки последнего требования раздела 5.1. Нажмите ENTER.
5.Восстановите стиль по умолчанию для новой строки (Paragraph3) и напечатайте:
Уведомление заказчика по электронной почте о дате отгрузки заказа.
6.Выделите напечатанный абзац.
7.В главном меню выберите RequisitePro > Requiriment > New. Отображается окно свойств нового требования:
В поле Name напечатайте:
Уведомление о дате отгрузки.
8.Перейдите на закладку Hierarchy. В поле Parent выберите <choose parent…>, затем FEAT1: Интернет-магазин компании ClassicsCD.Com. Нажмите ОК.
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
41 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями
СОДЕРЖАНИЕ
Цели управления требованиями
Основные понятия управления требованиями
Инструментальная поддержка
Поток работ управления требованиями
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
42 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями Поток работ
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
43 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями
Самостоятельно
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
44 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями Поток работ : Анализ проблемы
Цели:
Произвести документ “Видение”
Договориться о возможностях и назначении системы
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
45 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями Поток работ : Выяснение потребностей заинтерес. лиц
Цель: собрать информацию.
Запросы
заинтересованн ых лиц – это “список пожеланий” для последующей обработки
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
46 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями Поток работ : Выяснение потребностей заинтерес. лиц
Действие: Поиск актеров и прецедентов
применяется с целью представления функциональных возможностей системы
выполняется в частях потока работ:
Анализ проблемы
Выяснение потребностей заинтересованных лиц
Определение системы
шаги:
Поиск актеров
Поиск прецедентов
Описание взаимодействия актеров и прецедентов
Пакетирование актеров и прецедентов
Представление модели прецедентов на диаграммах
Разработка Обзора модели прецедентов
Оценка результатов
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
47 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями Поток работ : Выяснение потребностей заинтерес. лиц
Действие: Поиск актеров и прецедентов (продолжение)
Документирование найденных прецедентов выполняется в модели прецедентов Rational Rose и/или в документе «Спецификация прецедента» RequisitePro
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
48 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями
Практикум Упражнение 10 Моделирование расширения
Упражнение 10. Моделирование расширения
В упражнении 5 Вы представили запрос расширения к системе ClassicsCD.com.
Представленный запрос был одобрен CCB, открыт и передан для реализации системному аналитику.
Сейчас Вы – системный аналитик. В упражнении 9 Вы сформулировать требование возможности на основе этого запроса и включили его в документ "Концепция".
В RUP функциональные требования выражаются (моделируются) с помощью прецедентов.
Прецеденты описывают поведение системы на общем языке, который может понять каждый участник группы. Работа с прецедентами – это ключевой объединяющий механизм в Rational Unified Process (RUP).
Прецеденты важны для всех участников проекта:
Аналитики используют их, чтобы выразить поведение системы и cверять запланированные изменения с заинтересованными лицами.
Разработчики и проектировщики могут начать с описания прецедентов на обычном человеческом и графическом языке. Далее они перерабатывают их сначала в архитектурные спецификации, а затем в классы.
Тестировщики могут разрабатывать проекты тестирования, основанные на прецедентах.
Cистемные тестировщики могут использовать прецеденты для проверки правильности поведения системы до начала фазы конструктирования.
Руководители проекта и администраторы используют прецеденты для формальной проверки, что результирующие требования соответствуют представлениям заказчика системы.
В этом упражнении Вы создадите прецедент "Отгрузка заказа", который, в частности, предназначен для реализации созданного Вами требования возможности.
Rational Rose помогает аналитикам визуализировать поведение системы с использованием диаграмм прецедентов. Эти диаграммы помогают Вам управлять сложностью, потому что они позволяют Вам видеть “всю картину”. Диаграмма прецедентов показывает:
Поведения системы. Прецеденты описывают то, что делает система.
Границы системы. Актеры представляют внешние объекты, которые взаимодействуют с системой.
Отношения между прецедентами и актерами.
Используя Rose для создания диаграмм прецедентов, Вы обеспечиваете концентрированное графическое представление прецедентов системы. Это помогает всем заинтересованным лицам совместно использовать общее понимание проектных целей и ожидаемых результатов.
Кроме того, использование Rose – это эффективный способ непрерывно сообщать о столкновениях изменений во время всего жизненного цикла разработки. Все члены группы совместно используют и исправляют диаграммы прецедентов, потому что они написаны на Унифицированном языке моделирования (UML), понятном, соответствующим промышленным стандартам языке для проектирования программного обеспечения. Например, аналитики используют Rose для создания диаграмм прецедентов при описании системы на высоком уровне. Позже, Вы увидите, как архитекторы продолжают эту работу, используя Rose для более подробного проектирования системы. Поэтому, ваша системная диаграмма, архитектура и данные управляются одним инструментом, Rational Rose, с использованием одного языка, UML.
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
49 |
© 2004, |
Л.Б.Новиков |
|
Управление требованиями Поток работ : Выяснение потребностей заинтерес. лиц
Действие: Поиск актеров и прецедентов (продолжение)
Документирование найденных прецедентов выполняется в модели прецедентов Rational Rose и/или в документе «Спецификация прецедента» RequisitePro
После создания прецедента в Rose можно связать его с документом в RequisitePro
Связь может быть установлена на уровне модели или на уровне пакетов, где каждый пакет связан со своим проектом RequisitePro.
© 2005, |
В.В.Хашковский, Д.П.Калачев, |
50 |
© 2004, |
Л.Б.Новиков |
|