November 2, 2022

Современные методы описания функ.требований

Обложка книги


Шаблоны для создания Use Case

[ссылка на документ] (скоро на компонентах сделаю такой же в фигме)
Шаблон для Фигмы/FigJam

Забрать из комьюнити — https://www.figma.com/community/file/1156251794157908401


Что такое UseCase?

Сценарий — это путь, который проходят пользователи, чтобы что-то решить. При этом в таких сценариях присутствуют открытые и закрытые системы, так называемые, чёрные и прозрачные ящики — абстрактная модель системы, с которой будет взаимодействовать человеки. Наши дорогие пользователи и покупатели.

В историях про пользователей или клиентов — система может выступать как черный ящик и прозрачный ящик.

1. Чёрный чщик — система, содержимое которой не видно.
Внутринние действ.лица не упоминаются.

2. Прозрачный ящик — открытая система, где описаны все компоненты и перечислены паттерны поведения пользователей или покупателей.

Для чего нужны сценарии использования:

Описать рабочий процесс в бизнесе

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

Описать ФТ (функциональные требования) или ТЗ (техническое задание) к системе.

Документировать и версионировать проект. Версионировать можно по месяцам, кварталам, годам.

Написать документ в небольшой компактной группе или в большой распределённой группе.

Соглашение о поведении (фасилитация)

1 - Первая концептуальная модель имеет действующие лица системы и цели.
2 - Вторая модель имеет участников системы и интересы.

Цели можно не достигнуть
Для этого описываются альтернативные варианты развития истории.

Составная структура взаимодействия

- Все взаимодействия имеют отношение к одной и той же цели одного и того же основного действующего лица
- Use Case начинается с инициирующего события и продолжается, пока цель не будет достигнута или ее достижение не прервано и система не освобождается от обязанностей по отношению к данному взаимодействию.


Scopes — области действия
Означают границы нашего проекта.

Для управления обсуждением области действия есть инструмент — список Внутри/Снаружи.

![[Pasted image 20210315023303.png]]
*Пример таблицы*

Два других инструмента — список Действующее лицо/Цель и краткое описание вариантов использования.

- В списке Дейст.лицо/Цель перечисляются все цели пользователя, которые поддерживает система.
- Список Внутри/Снаружи показывает в какой области находятся элемнты сценария.

![[Pasted image 20210315023716.png]]
*Пример списка*


Краткое описание варианта использования

Описание поведения варианта в двух-шести предложениях, где упоминается наиболее значимые действия и сбои.

![[Pasted image 20210315024034.png]]
*Пример краткого описания*


Области действия проектирования

Это рамки системы. Это множество систем, аппаратных и программных, которые будут проектироваться и обсуждаться.

Пример: проектирования банкомата. Для него нам нужно разработать аппаратное и программное обеспечение. Комп.сеть, с которой будет общаться банкомат не входит в область проектирования.

![[Pasted image 20210315024911.png]]
*Пример областей действия*

**Системы делятся на:**
- Чёрный ящик — внутренняя структура не обсуждается
- Прозрачный ящик — обсуждается, как работают компоненты системы

---

**Область действия включают:**
- Концепцию
- Диаграммы области действия проектирования
- Список Внутри/Снаружи
- Список Действющее лицо/Цель

---

## Участники и действующие лица

Участник — это кто-то (или что-то), кто выполняет запрос.

Действующее лицо — это кто-то (или что-то), кто этот запрос обрабатывает. Подразумевает индивидуума в действии.

Вспомогательные действ.лица — Внешние действующие лица, которые предоставляют некоторую услугу для разрабатываемой системы. Например, это может быть принтер или люди, которые должны провести для нас небольшое исследование (например, следователь по делам насильственной смерти даёт страховой копмпании заключение о смерти клиента). Указывают на внешние интерфейсы и протоколы. **Отсюда требование:** форматы данных и внешние интерфейсы (API).

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

Разрабатываемая система сама по себе может быть действующим лицом — особым.

---

## Прозрачный ящик
При проектировании масштабных систем компоненты проявляются как действующие лица. Например можно описать, что данные передаются с мобильного устройства на систему ПК, где пользователь после приёма данных, взаимодействует с ними.

Заглядывая внутрь системы, с которой взаимодействует пользователь мы трактуем систему как «Прозрачный ящик». При таком подходе обсуждаются поведение внутренних и внешних действующих лиц. В варианте использования «Прозрачный ящик» существует более двух действующих лиц, так как раскрыты компоненты системы и внешние действующие лица.

**Упражнения:**
Существуют: владелец бизнеса вендинговых (торговых) автоматов.

**Варианты использования:**
— Получение доступа ко всем функциям автомата и денежным. средствам, которые пропускаются через купюроприёмник.
— Сформировать отчёт с выручкой за сутки.
— Собрать данные о кликах клиентов для последующей аналитики и комплексного изучения.


---

## Характеристики основных действ.лиц
![[Pasted image 20210530063223.png]]

---

## UML
Язык графического описания для объектного моделирования в области разработки ПО.