Привет! 🙋‍♀️

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

Но прежде чем определить функциональные требования, аналитику придётся как следует поработать с предыдущими типами требований – бизнес- и пользовательскими. Без этого существует риск спроектировать классную фичу, которая может оказаться никому не нужна - ни бизнесу, ни пользователям.

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


С одной из техник описания пользовательских требований вы уже знакомы — это пользовательская история (англ. user story). Да что там знакомы – вы теперь можете целую карту историй построить (USM)!

🥷: Шаблон для построения USM мы давали вот тут.

Но существует ещё одна популярная техника описания функциональных требований к продукту с участием пользователя. Она помогает качественно и на достаточном для разработчиков уровне детализации отразить ожидаемые функциональные возможности продукта. И техника эта называется «вариант использования» (use case).

#hardGetAnalyst

⬇️⬇️⬇️

✨ ПРО ВАРИАНТ ИСПОЛЬЗОВАНИЯ (USE CASE) ✨

Вариант использования (англ. use case) — это техника представления требований, которая описывает взаимодействие между несколькими участниками (действующим лицом и системой) для получения определённого значимого результата.

🧺 Рассмотрим на бытовом примере.
Почти в каждом доме есть стиральная машина-автомат. Часто в стиральной машине есть множество функций, помимо стирки: сушка, отжим, отложенный запуск и так далее. Помимо внутренних функций, со стиральной машиной можно совершать другие манипуляции: например, настраивать пользовательский режим стирки или чинить. Весь набор функций, который производитель заложил в стиральную машинку, — это и есть варианты использования.

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


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

Актор (англ. actor) — человек, устройство или система, играющие некоторую определённую роль во взаимодействии с решением (BABOK Guide).

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

Выделить акторов, которые участвуют в описании вариантов использования, помогут такие вопросы:
❔ Кто (или что) уведомляется, если что-то происходит внутри системы?
❔ Кто (или что) предоставляет системе информацию и сервисы?
❔ Кто (или что) помогает системе среагировать и выполнить задачу?


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

🤔 USER STORY И USE CASE – В ЧЁМ РАЗНИЦА? 🤔

И пользовательская история, и вариант использования имеют общую цель — описать требования к продукту. Оба подхода помогают понять, что именно должна делать система и каким образом она должна взаимодействовать с пользователем или системой. Но между ними есть отличия.

Рассмотрим их в разрезе ключевых атрибутов:
- фокус (на что делается упор в подходе),
- цель подхода,
- его формулировка,
- уровень детализации.


1️⃣ Фокус

*️⃣Пользовательская история сфокусирована на конкретной задаче или потребности пользователя.

*️⃣Вариант использования делает упор на взаимодействии системы с актором, а также на последовательность событий в этом взаимодействии.


2️⃣ Цель подхода

*️⃣Пользовательская история описывает задачу пользователя и причину для её выполнения.

🥷: Вспомните конструкцию user story:
как [кто-то (пользователь / роль)],
я хочу [выполнить задачу],
чтобы [достичь результата].

*️⃣Вариант использования же представляет описание поведения системы в различных ситуациях.


3️⃣ Формулировка подхода

*️⃣Пользовательская история формулируется по чётко заданному шаблону. Его вы уже знаете.

*️⃣Вариант использования тоже имеет унифицированный шаблон с детальным описанием шагов, условий и ожидаемых результатов. Но этот шаблон довольно гибкий и адаптируется под описываемую функциональность набором полей и уровнем детализации.


4️⃣ Уровень детализации

*️⃣Пользовательская история верхнеуровнево описывает функциональность, которую нужно реализовать.

*️⃣Вариант использования же содержит более структурированное и подробное описание взаимодействия актора и системы.

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


🥷: Хотим КВИЗануть ваше понимание отличий между двумя подходами. Вы как, в ресурсе? 😀
Если да, то ставьте 🔥 на этот пост. Пустим КВИЗ, закрепим полученную теорию и перейдём к шаблону use case.

Хола, амигос! 💃

Вы просили КВИЗ - мы замутили КВИЗ 😎

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

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

Ставим ❤️, если ю а рэди!

#quizGetAnalyst

Ребята, это мы с вами! 🥺

Спасибо большое за вашу классную активность в КВИЗах и в теоретических постах. Ваш отклик очень нас воодушевляет! 🐈

✨ ПЕРЕХОДИМ К ОПИСАНИЮ USE CASE ✨

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

Оформление с помощью нотации UML мы рассмотрим позднее, когда детально углубимся в нотации моделирования 😉

А пока разберём более простой и универсальный способ оформления use case – с помощью таблицы.
В документации к ПО именно этот вариант оформления считается основным, а графический - вспомогательным.

#hardGetAnalyst

Существует два варианта табличного оформления use case: полная табличная форма и свободная табличная форма (упрощённая).

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

🟢 Если проект небольшой и варианты использования — не единственное описание будущих требований к системе (а есть ещё, например, user story, модели процессов, протипы и другие артефакты), можно не использовать полный шаблон записи вариантов использования и обойтись свободным форматом.

Именно его мы и рассмотрим.

⬇️⬇️⬇️

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

🥷: Предлагаем сохранить этот и предыдущий пост в избранное, чтобы шаблон use case был у вас всегда под рукой!


1️⃣ Вариант использования

В этом поле указывается название одного варианта использования, которое вы хотите описать, в формате «глагол + существительное».
Например: «зарегистрироваться на сайте», «создать заявку», «оплатить покупку» и так далее.

Для определения возможных вариантов использования можно руководствоваться следующими способами:
📌Определить действующие лица и бизнес-процессы, в которых они участвуют
В каждом процессе выделить доступную для выполнения функцию — это и будет вариант использования.
📌 Применить CRUD-модель для определения возможных сценариев взаимодействия с данными системы: создания (англ. create), чтения (англ. read), изменения (англ. update) или удаления (англ. delete).


2️⃣ Область действия

Границы системы, в рамках которых выполняется сценарий.
Например, приложение или сайт.


3️⃣ Участники процесса

Участники процесса включают основное действующее лицо и иных участников.
- Основное действующее лицо запускает вариант использования, то есть это и есть актор. Можно записать имя пользователя, должность или роль. Например, пользователь ЛК или администратор.
- В иных участниках указывается перечень дополнительных действующих лиц и их целей в рамках варианта использования. Записывается в формате: [Актор] — [его цель].

Например, сайт, цель которого — сформировать ЛК клиенту. Система-партнёр, которая возвращает информацию об оплате услуги в основную систему.


4️⃣ Предусловие

Здесь указывают описание того, что должно произойти, чтобы актор мог воспроизвести данный вариант использования.
Например, пользователь зашёл на сайт или сформировал корзину для оформления покупки.


5️⃣ Описание

В этом блоке таблицы описывают основной сценарий в виде пошагового описания действий актора и системы.

Например:
1. Система открывает пользователю форму регистрации
2. Пользователь указывает свои персональные данные в форме
3. Система запускает проверку указанных данных на формат
4. Система создаёт пользователю личный кабинет (ЛК)
5. Система авторизует пользователя в ЛК под его персональными данными.

☝🏼 Необходимо указывать номер шага и действия, чтобы порядок шагов был очевиден.


6️⃣ Расширения

В расширениях представлено описание альтернативных сценариев, которые выполняются при ответвлении от основного.

Причин такого ветвления может быть несколько:
- Альтернативные пути к успеху;
- Актор действует некорректно;
- Бездействие актора;
- Некорректные данные;
- Внутренние ошибки системы;
- Критические недостатки в производительности системы.

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


💁🏻‍♀️ Ну вот, собственно, и всё!

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

✨РЕКОМЕНДАЦИИ ПРИ ОПИСАНИИ USE CASE✨

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

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

👌 Используйте предложения с короткими конструкциями
Для этого чётко указываете актора, его действие в рамках шага и необходимую дополнительную информацию. Например, «Система формирует отчёт», «Пользователь вводит логин» и так далее.


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


👌 Не перегружайте сценарий описанием деталей интерфейса
Например, вместо «Пользователь нажимает на кнопку “Подтвердить”» лучше использовать «Пользователь подтверждает регистрацию» и так далее. Так при изменениях в интерфейсе (замена кнопки на поле ввода секретного кода и так далее) вам не нужно будет корректировать все варианты использования, связанные с этим сценарием.

Привет, друзья! 🙃

На этой неделе хотим рассмотреть тему ролей и ролевой модели в рамках разработки ПО.

Кажется, что определение ролей – это интуитивно понятный процесс, но в этом-то и сложность. Когда специалист отрабатывает какой-либо навык до автоматизма, теория, на которой базировалась практика, начинает «затираться». А это значит, при неожиданном запросе теории, ответ может предательски потеряться 🙈

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

Нам такое не надо! Поэтому погрузимся в основную теорию ролей и отработаем полученные знания на практике! 😎

#hardGetAnalyst

🚓 УИИИИУ УИИИИИУ! 🚓
Полиция крутых вебинаров уже на месте!

Для начинающего специалиста тема архитектуры системы – это «чёрный ящик», к которому даже страшно прикасаться. И именно эту тему спрашивают у респондента на собеседованиях! 😔

Нет, не надо слов, не надо паники! (кто пропел эту строчку, ставь 👍)
Уже послезавтра мы расскажем и покажем про:
- интеграции,
- REST,
- монолит / SOA / MSA
и многое другое! Всё это вы не только узнаете, но и поймёте на практическом вебинаре «Проектирование архитектуры: от монолита к микросервисам» с Екатериной Ананьевой!

План вебинара:
1. Роль системного аналитика в проектировании архитектуры;
2. Знакомство с проектом для работы;
3. Проектирование монолита;
4. Переход к сервисам (SOA) и микросервисам (MSA);
5. Проблемы разделения монолита на микросервисы;
6. Что нужно знать системному аналитику про работу с архитектурой.

Эти навыки по проектированию архитектуры помогут выйти на новый качественный уровень в системном анализе и стать ценным специалистом в мире IT!

КОРОЧЕ ГОВОРЯ, НЕ ПРОПУСТИТЕ:

🟢 Проектирование архитектуры: от монолита к микросервисам
🚀 29.02.2024 в 19:00 Мск (ЧТ)
🔗 ЗАРЕГЕСТИРОВАТЬСЯ

Увидимся на вебинаре! 😘