Ты получал Use Case от бизнес-аналитика

Мой опыт получения Use Case от бизнес-аналитика

Да, я много раз получал Use Case (сценарии использования) от бизнес-аналитика. Это важный артефакт в цепочке: Business Analyst -> System Analyst -> Developer. Поделюсь как я это рассматривал.

Что такое Use Case

Use Case (вариант использования) — это описание взаимодействия между пользователем и системой для достижения конкретной цели.

Пример:

UseCase: "Customer Makes a Purchase"
Actor: Customer
Preconditions: Customer is logged in
MainFlow:
  1. Customer browses products
  2. Customer adds item to cart
  3. Customer proceeds to checkout
  4. System displays order summary
  5. Customer enters shipping address
  6. Customer selects payment method
  7. Customer confirms payment
  8. System processes payment
  9. System displays confirmation
Postconditions: Order is created in system

Как бизнес-аналитик представляет Use Case

Обычно Business Analyst создает документ вроде этого:

Пример: UC-001 User Registration

Actor: New User
Goal: Create account in system
Precondition: User not logged in
Trigger: User clicks "Sign Up" button

Main Success Scenario:
1. System displays registration form
2. User enters email
3. User enters password (min 8 chars)
4. User confirms password
5. User clicks "Sign Up"
6. System validates email (unique)
7. System hashes password
8. System creates user account
9. System sends verification email
10. System shows "Check your email" message
11. User clicks link in email
12. System verifies email
13. System shows "Email verified" message
14. System logs user in
Postcondition: User account created and verified

Alternative Flows:
A1: Email already exists
  At step 6, if email is not unique:
    6a. System shows error "Email already registered"
    6b. System suggests "Sign in" or "Reset password"

A2: Password doesn't match
  At step 4, if passwords don't match:
    4a. System shows error
    4b. Go back to step 2

Типичные проблемы с Use Case от BA

Проблема 1: Too High Level (Слишком высокий уровень)

Плохо (что я получал):

UC-042: User can buy products

Main flow:
1. User selects product
2. User makes payment
3. Order is created

Вопросы которые я задавал:

• Какие валидации при выборе товара?
• Какие способы оплаты поддерживаем?
• Что если платеж упадет?
• Что если товара нет на складе?

Мой job: Детализировать это до уровня разработчика.

Проблема 2: Missing Edge Cases

Плохо:

UC-043: Customer refunds order

Main flow:
1. Customer requests refund
2. System creates refund
3. Money returned to customer

Что я задавал:

• Сроки возврата (30 дней, 60 дней, unlimited)?
• Можно вернуть частичный заказ?
• Что если товар был поврежден?
• Как обрабатывать спорные возвраты?
• Сколько раз можно вернуть один товар?

Решение: Я добавляю "Alternative Flows" раздел.

Проблема 3: Технические детали в Use Case

Плохо (что я получал):

UC-044: User updates profile

Main flow:
1. User goes to /profile/edit
2. User fills out form
3. System sends PUT /api/users/{id} with JSON
4. System validates with Spring annotations
5. System saves to PostgreSQL

Проблема: BA смешал бизнес-логику с техническими деталями.

Как я исправляю: Удаляю технические детали. Use Case должен быть tech-agnostic.

Как я использую Use Case

Шаг 1: Анализирую

Use Case от BA: UC-045 Process Refund Request

Aнализирую:
- Что хочет делать пользователь?
- Какие данные нужны?
- Какие проверки нужны?
- Какие edge cases?
- Какие интеграции (payment gateway)?
- Как это влияет на другие системы?

Шаг 2: Расширяю

Добавляю детали которых не было:

Alternative Flows:
A1: Refund period expired
  If order older than 30 days:
    1a. System shows error
    1b. System suggests "Contact support"

A2: Item already refunded
  If item was already returned:
    1a. System shows error
    1b. No duplicate refund

A3: Payment gateway rejected refund
  If payment processor returns error:
    1a. System logs error
    1b. System moves to manual refund queue
    1c. Support team handles manually

Шаг 3: Делаю диаграмму

UML Sequence Diagram:

Customer -> System: Request Refund
System -> Database: Check order
System -> Inventory: Receive item
System -> PaymentGateway: Process refund
PaymentGateway -> System: Refund processed
System -> Database: Update order status
System -> EmailService: Send confirmation
EmailService -> Customer: Refund confirmation email
System -> Customer: Show success message

Шаг 4: Преобразую в требования

FR-REFUND-001: Validate refund eligibility
  - Order must be less than 30 days old
  - Item must not be already refunded
  - Customer must be order owner
  - Item must be in acceptable condition

FR-REFUND-002: Process refund
  - Refund to original payment method
  - If card expired, refund to bank account
  - Generate refund transaction ID

FR-REFUND-003: Update inventory
  - Add item back to inventory
  - Mark as "returned"
  - Queue for inspection

FR-REFUND-004: Notify customer
  - Send email with refund details
  - Show tracking of refund

NFR-REFUND-001: Timing
  - Refund processing: < 1 hour
  - Bank processing: 1-3 business days
  - Refund page load: < 2 seconds

Сценарий реального проекта

Проект: E-commerce marketplace

Получил от BA: 15 Use Cases:

UC-001: Customer Registration
UC-002: Customer Login
UC-003: Browse Products
UC-004: View Product Details
UC-005: Add Product to Cart
UC-006: Remove Product from Cart
UC-007: Apply Coupon
UC-008: Checkout
UC-009: Pay with Credit Card
UC-010: Pay with PayPal
UC-011: Confirm Order
UC-012: Track Order
UC-013: Request Refund
UC-014: Return Product
UC-015: Leave Review

Что я сделал:

1. Прочитал все и создал matrix:

UC vs Actor:
  UC vs Customer
  UC vs Admin
  UC vs Support
  UC vs System

UC vs System:
  UC vs Database
  UC vs Payment Gateway
  UC vs Email Service
  UC vs Inventory System

1. Вопросы к BA:

• UC-003: "Browse Products" — можно сортировать? фильтровать? поиск?
• UC-008: "Checkout" — можно сохранить и вернуться позже?
• UC-010: "Pay with PayPal" — PayPal account linking required?
• UC-014: "Return Product" — обязательно вернуть физически или только request?
• UC-015: "Leave Review" — может ли анонимный пользователь оставить отзыв?

1. Детализировал: Для каждого UC создал

- Detailed requirements document
- State diagram (order states)
- Data model (what data is needed)
- API specifications
- Error handling
- Non-functional requirements

1. Создал трассируемость:

UC-013: Request Refund
  |
  +-- FR-REFUND-001: Validate eligibility
  |
  +-- FR-REFUND-002: Process refund
  |
  +-- NFR-REFUND-001: < 1 hour processing
  |
  +-- Test case: TC-REFUND-001 to TC-REFUND-010

Как я проверяю качество Use Case

Чеклист:

• Clear goal: что хочет пользователь?
• Clear actors: кто это делает?
• Happy path: основной сценарий
• Alternative flows: что может пойти не так?
• Preconditions: что должно быть перед этим?
• Postconditions: что будет после?
• Boundary conditions: edge cases?
• Data flow: какие данные текут?
• System interactions: какие системы задействованы?
• Performance: сколько это должно занять времени?

Если Use Case не проходит хотя бы 2-3 пункта, я возвращаюсь к BA с вопросами.

Когда Use Case недостаточно

Use Case показывает:

• Что система делает
• Кто это использует
• Когда это используется

Use Case НЕ показывает:

• Как это реализовать технически
• Нефункциональные требования
• Интеграции между компонентами
• Data models
• API specifications
• Error handling details
• Performance requirements

My job: Взять Use Case и создать документацию которую разработчик может использовать.

Вывод

Use Case от BA — это starting point, не конечный продукт.

Мой process:

1. Прочитать и понять goal
2. Задать уточняющие вопросы
3. Детализировать edge cases
4. Создать требования
5. Создать диаграммы
6. Создать API spec
7. Создать data models
8. Определить NFR
9. Трассировать к тестам

Хороший системный аналитик преобразует высокоуровневый Use Case в точные, проверяемые требования.