Моделирование требований на UML

Минск – 2015
Школа Системного Анализа, г. Москва
IT-Студия WebMax.BY, г. Минск
Моделирование
требований на UML
Курс online-тренингов
Практический анализ и
моделирование на UML
Тема 2
Николай Киреев

 Определение требований
 Классификации требований
 Моделирование функциональных требований
IT-Студия WebMax.BY www.webmax.by
Основные темы2

 Требование (requirement) – желательное
свойство, характеристика или условие,
которым должна удовлетворять система
в процессе своей эксплуатации
[Г. Буч «Объектно-ориентированный анализ и
проектирование с примерами приложений»]
Определение3

Чем являются требования?4
Требования являются:
 основой для оценки
трудоёмкости и стоимости
проекта;
 промежуточным результатом в
процессе разработки ПО;
 архитектуро-определяющими и
служат источником для
проектированияархитектурыПО;
 источником для внесения
изменений в архитектуру ПО в
процессе эксплуатации.
Требования не являются:
 продуктом, в котором
заинтересованы заказчики и
пользователи;
 основной целью аналитиков и
проектировщиков;
 основной целью процесса
разработки;
 полной и достаточной информацией
о программном продукте;
 стабильными и очевидными как в
процессе разработки, так и в
дальнейшей эксплуатации.

Дисциплина Software Requirements в SWEBOK5

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

Уровни требований К. Вигерса
БИЗНЕС-
ТРЕБОВАНИЯ
ПОЛЬЗО-
ВАТЕЛЬСКИЕ
ФУНКЦИО-
НАЛЬНЫЕ
НЕФУНКЦИО-
НАЛЬНЫЕ
7

Группа функциональных требований:
 Бизнес-требования (Business Requirements) – определяют
высокоуровневые цели организации или клиента
(потребителя) – заказчика разрабатываемого
программного обеспечения.
 Пользовательские требования (User Requirements) –
описывают цели/задачи пользователей системы, которые
должны достигаться/выполняться пользователями при
помощи создаваемой программной системы или в рамках
единого бизнес-процесса.
 Функциональные требования (Functional Requirements) –
определяют функциональность (поведение) программной
системы, которая должна быть создана разработчиками
для предоставления возможности выполнения
пользователями своих обязанностей в рамках бизнес-
требований и в контексте пользовательских требований.
Уровни требований К. Вигерса8

 Системные требования (System Requirements) – иногда
классифицируются как составная часть группы
функциональных требований.
Описывают высокоуровневые требования к программному
обеспечению, содержащему несколько или много
взаимосвязанных подсистем и приложений.
При этом, система может быть как целиком программной, так
и состоять из программной и аппаратной частей.
В общем случае, частью системы может быть персонал,
выполняющий определенные функции системы, например,
авторизация выполнения определенных операций с
использованием программно-аппаратных подсистем.

Группа нефункциональных требований
(Non-Functional Requirements):
 Бизнес-правила (Business Rules) – включают или связаны с
корпоративными регламентами, политиками,
стандартами, законодательными актами,
внутрикорпоративными инициативами, учетными
практиками, алгоритмами и т.д.
 Внешние интерфейсы (External Interfaces) – вопросы
организации пользовательского интерфейса и удобства
его пользования (Usability), конкретизация аспектов
взаимодействия с другими системами, операционной
средой, возможностями мониторинга при эксплуатации.

 Атрибуты качества (Quality Attributes) – описывают
дополнительные характеристики продукта в различных
“измерениях”, важных для пользователей и/или
разработчиков. Атрибуты касаются вопросов портируемости,
интероперабельности (прозрачности взаимодействия с
другими системами), целостности, устойчивости и т.п.
 Ограничения (Constraints) – формулировки условий,
модифицирующих требования или, сужающих выбор
возможных решений по их реализации. К ним относится
параметры производительности, влияющие на выбор
платформы реализации и/или развертывания, которые, в
свою очередь, могут относиться, например, к внешним
интерфейсам.

Уровни требований Д. Леффингуэлла12

 Потребность (need) – отражение проблемы
бизнеса, персоналии или процесса, которое
должно быть соотнесено с использованием или
приобретением новой системы.
 Характеристика продукта (feature) – множество
логически связанных функциональных и
нефункциональных требований, которые
обеспечивают возможности пользователя и
удовлетворяют бизнес-целям.
Уровни требований Д. Леффингуэлла
13

 Классификация требованийпо модели FURPS+:
• функциональные требования (Functionality)
• требования удобства использования (Usability)
• требования надежности (Reliability)
• требования производительности (Performance)
• требования возможности сопровождения (Supportability)
 Символом + обозначены дополнительные условия,
к которым относятся:
• проектные ограничения
• требования управления системой
• требования к графическому интерфейсу пользователя
• физические требования
• юридические требования
Классификация требований FURPS+
14

 Пользовательские требования (User Requirements)
соответствуют конструкции:
<id> <действующее лицо> shall <действие> *
 Системные и/или функциональные требования (System
Requirements &/or Functional Requirements):
<id> <система> shall <действие> *
 Функции системы соответствуют конструкции:
Если Х действительно является функцией системы, то имеет
смысл следующее предложение: система должна выполнять «Х»
* Id – порядковый номер или другой идентификатор
* shall – должен ( англ.)
Как выявлять функциональные требования?
15

Уровни
“видимости”
функциональных
требований
16
• Истинные цели
инвесторов (заказчиков)
иногда скрыты от
разработчиков.
• Пользовательские
требования не всегда
очевидны и понятны.
• Функциональные
требования окончательно
выясняются на этапе
тестирования ПО.

 Business Use Case Model
Моделирование Business Requirements &
User Requirements
 Use Case Model
Моделирование Software Functional Requirements
17 Моделирование функциональных
требований

 В самый широкий круг заинтересованных лиц (ЗЛ), кроме
пользователей ПО и участников бизнес-системы (бизнес-процесса),
входят индивидуумы, группы, организации, должностные лица или
системы, которые взаимодействуют с моделируемой бизнес-
системой, влияют на неё, устанавливая ограничения и правила, но
не являются ее частью. Примером могут быть инвесторы,
законодательные и надзорные органы, непосредственные
заказчики ПО.
 Во второй по ширине круг входят все участники бизнес-системы или
бизнес-процесса. Они могут не быть пользователями программной
системы, но исполнение ими функциональных обязанностей в
рамках данного бизнеса или бизнес-процесса оказывает на неё
влияние. Пример: курьер по доставке товаров из интернет-
магазина.
 Третий самый узкий круг лиц – это пользователи программной
системы, взаимодействующие с ней посредством внешних
интерфейсов.
18 Заинтересованные лица

19 Заинтересованные лица

20 Модели бизнес-требований
 Модели ЗЛ (не входящих в бизнес или
бизнес-процесс) и их бизнес-целей
 Самый высокий уровень абстракции
 Связи «include», «extend» не востребованы
 Модели участников бизнеса или
бизнес-процесса, их бизнес- или
пользовательских требований
 Высокий уровень абстракции
 Детализация со стереотипами
«include», «extend» возможна в
ограниченных пределах
В моделях используем стереотипы:
«Business Actor», «Business Use Case», связи
Association, «include», «extend»
Business Goal 1
Business Goal 2
Business Goal 3 Business Goal 4
CEO-Business Actor
User Requirement 1
User Requirement 2
User Requirement 3
Business Requirement 4
Business Actor
User Requirement 1
User Requirement 2
User Requirement 3
Business Requirement 4
Business Actor
IncludeUseCase
<<include>>
<<include>>

21 Пример 1. Обязанностируководствав проекте учебногоПО

22 Пример 2. Модель требований работника
регистратуры
 Детализация пользовательских требований не всегда оправдана.
Связи «include» и «extend» усложнят обсуждение модели с
заказчиками.

23 Модели функциональных требований
Actor (действующее лицо, ДЛ) – абстрактное ролевое
описание внешнего пользователя (нескольких пользователей),
находящегося вне системы и взаимодействующего с ней.
 Три типа ДЛ: одна из ролей физического лица; одна из ролей
внешней системы (подсистемы); роль таймера (момент или
интервал времени).
 Взаимодействие – это послать или принять сообщение.
 Единственная возможная связь между Actor и Use Case – это
ассоциация, единственная связь между ДЛ – это «generalization»
(наследование).
 Взаимодействие ДЛ с системой осуществляется через граничные
объекты – интерфейсы (объекты boundary).
Use Case (вариант использования, ВИ) – внешняя спецификация
последовательности действий, которые система может
выполнять в процессе взаимодействия с ДЛ для получения
определенного значимого для них результата.

 ВИ определяет набор действий, совершаемый системой при
диалоге с актером.
 Диаграмма ВИ иллюстрирует функциональные требования к
системе и показывает, что и для кого должна делать система.
 ВИ иллюстрирует не отдельную функцию системы, а
функциональный сервис, направленный на достижение
результата для ДЛ.
 Каждая функция системы должна иметь отображение на
диаграмме ВИ.
 Каждый ВИ инициируется ДЛ, если он не входит в отношения
«include» и «extend».
 Между ВИ возможны только три типа связей (отношений):
«include», «extend» и «generalization» (наследование).
 ВИ группируются вокруг инициирующих их ДЛ в папках
(Package).

 Каждое действующее лицо и варианты использования,
инициируемые им, помещаются в отдельную папку.

 Общие для нескольких
действующих лиц варианты
использования инициируются
«абстрактным» актёрами.
 Следует избегать
функциональной
декомпозиции:

Используя представленную ниже концепцию заказа пиццы по сети
Интернет выполните следующие задания:
1. Определите возможные цели, преследуемые инвесторами
(заказчиками) данной программной системы.
2. Выявите заинтересованных лиц, внешних по отношению к данной
бизнес-системе, участников бизнеса/бизнес-процесса, а также
непосредственных пользователей программного обеспечения.
3. Постройте модели, отражающие функциональные обязанности всех
участников данного бизнеса (Business Use Case Model).
4. Постройте модели, отражающие функциональные сервисы,
предоставляемые программной системой каждому пользователю
(Use Case Model).
27 Задание для самопроверки

Клиент регистрируется в системе, выбирает пиццу в меню и
оформляет заказна изготовление.Пиццы отличаютсянаименованием,
весом и ценой. Клиент может заказать пиццы разных наименований в
разном количестве, поэтому каждый заказ включает позиции.
Отдельная позиция содержит наименование пиццы, которую клиент
желает получить, количество и общую стоимость по данной позиции.
При оформлении заказу присваивается порядковый номер и статус,
рассчитывается общая стоимость, планируется время готовности,
указывается фамилия клиента, телефон и комментарии. Статус
исполнения заказа (очередь, производство, выполнен) позволяет
администратору контролировать процесс выполнения заказов.
В случае, если заказывается пицца с доставкой, то в заказе
указывается адрес, дата, время и стоимость доставки.
Если заказ должен быть выполнен не в порядке очерёдности, а к
определённому сроку, то указываются планируемая дата и время
готовности или доставки.
28 Vision: заказ пиццы по Интернету

29
IT-Студия WebMax.BY www.webmax
 Контакты:
e-Mail: info@webmax.by
Skype: nousy123
Тел.: +375 (25) 633-76-78
Сайт: www.webmax.by
СПАСИБО ЗА ВНИМАНИЕ!

Моделирование требований на UML

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (11)

Моделирование требований на UML