Описывал ли поведение системы?

Как описывать поведение системы в требованиях

Описание поведения системы — это ключевая часть работы Business Analyst. Часто требование размытое именно потому, что BA не описал, как система должна себя ВЕСТИ при различных сценариях. Расскажу, как правильно это делать.

Что такое "поведение системы"

Это не просто функция (что система делает), а КАК она это делает и что делает при различных условиях.

Пример:

❌ Размытое требование (только функция):

"Система должна проверять email пользователя"

✅ Требование с описанием поведения:

"Система должна проверить email на валидность:
- Формат: должен содержать @ и домен
- При valid email: отправить verification письмо
- При invalid email: показать ошибку под полем
- При email уже зарегистрирован: показать сообщение "Email already registered"
- При письмо не доставлено за 30 мин: автоматически переотправить
"

Методы описания поведения

Метод 1: Given-When-Then (BDD style)

Это наиболее популярный и проверенный способ.

Feature: Email verification

Scenario: User enters valid email
  Given: User is on signup page
  When: User enters "john@example.com"
  And: Clicks "Continue"
  Then: System sends verification email
  And: Shows message "Check your email"

Scenario: User enters invalid email
  Given: User is on signup page
  When: User enters "not-an-email"
  And: Clicks "Continue"
  Then: System shows error "Invalid email format"
  And: Does NOT send email

Scenario: User enters email that already exists
  Given: Email "jane@example.com" is registered
  When: User enters "jane@example.com"
  And: Clicks "Continue"
  Then: System shows "This email is already registered"
  And: Offers "Login" button

Плюсы:

• Структурирован
• Легко превратить в автоматизированные тесты
• Минимум неоднозначности

Метод 2: State Machine (для сложных процессов)

Когда поведение зависит от состояния системы.

Пример: процесс оплаты

STATES:
- PENDING (ожидание ввода)
- PROCESSING (отправляем запрос на платёжный сервис)
- AUTHORIZED (платёж авторизован, но не захачен)
- CAPTURED (деньги захачены)
- FAILED (ошибка платежа)
- REFUNDED (возврат)

TRANSITIONS:

PENDING
  │
  ├─[User clicks Pay] → PROCESSING
  └─[User clicks Cancel] → exit

PROCESSING
  │
  ├─[Payment authorized] → AUTHORIZED
  └─[Payment failed] → FAILED

AUTHORIZED
  │
  ├─[Auto-capture after 3 days] → CAPTURED
  ├─[Manual capture click] → CAPTURED
  └─[Timeout after 7 days] → FAILED

FAILED
  │
  ├─[User retries] → PROCESSING
  └─[24 hours passed] → Notify user

Это даёт разработчику полную ясность:

• В какие моменты может упасть система
• Как обработать каждую ошибку
• Какие transition'ы валидны, какие — нет

Метод 3: Decision Tree (для логики с много условиями)

         User applies for discount
                  │
                  ├─ Purchase history < 3 months?
                  │     ├─ YES → Not eligible
                  │     └─ NO → continue
                  │
                  ├─ Total spent < $100?
                  │     ├─ YES → 5% discount
                  │     └─ NO → continue
                  │
                  ├─ Account age > 1 year?
                  │     ├─ YES → 15% discount
                  │     └─ NO → 10% discount
                  │
                  └─ Apply discount, send confirmation

Метод 4: Error Handling Matrix

Для описания того, как система ведёт себя при ошибках.

| Сценарий | Ошибка | Система | Пользователь видит | Action |
|---|---|---|---|---|
| API call | 500 | Retry 3 раза | Loading spinner | Если все 3 fail: show error |
| API call | 429 (rate limit) | Retry after 60s | Loading spinner | Автоматический retry |
| API call | 404 | No retry | Error message | "Something went wrong" |
| Network | Timeout | Retry after 5s | Loading spinner | Если no internet: show offline |
| Database | Connection lost | Failover to read replica | Brief loading | User may see stale data |

Метод 5: Sequence Diagram (для сложных взаимодействий)

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

User         →  Frontend      →  Backend      →  Payment API
  │                │                │                │
  │─ click Pay ───→│                │                │
  │                │─ POST /pay ───→│                │
  │                │                │─ Call SDK ────→│
  │                │                │ (wait)         │
  │                │                │←─ 200 OK ──────│
  │                │←─ 200 OK ──────│                │
  │←─ "Success" ───│                │                │
  │                │─ Send email ──→│ (async job)    │

Здесь видно:

• Что async, а что sync
• Где может быть задержка
• Где может быть failure

Как описать специальные случаи (edge cases)

Boundary Cases

- Что если количество элементов = 0?
- Что если это максимальное значение (INT_MAX)?
- Что если дата в прошлом?
- Что если пользователь админ vs обычный юзер?

Пример:

Requirement: Display product list

Behavior:
- If no products: show "No products found" message
- If 1 product: show it (don't show "1 of 1")
- If > 100 products: show pagination (10 per page)
- If user is admin: show additional "Edit" button per product
- If product is out of stock: show "Unavailable" instead of "Add to cart"

Timing Issues

- Что если пользователь нажмёт кнопку дважды за 100ms?
- Что если сеть упадёт посередине операции?
- Что если операция займёт > 30 сек?

Пример:

Requirement: Submit order

Behavior:
- Button becomes disabled after first click (prevent double-submit)
- If network fails during submission:
  - Show "Connection lost" error
  - Keep order in draft (user can retry)
  - Don't charge payment twice
- If submission takes > 30s:
  - Show "This is taking longer" message
  - Allow user to check status or go back
- Duplicate detection: if same order submitted twice within 5 seconds, ignore second

Как НЕ описывать поведение

❌ Слишком техничный язык:

"System shall instantiate UserService and invoke validateEmail method"

✅ Бизнес-язык:

"System checks if email is in correct format"

---

❌ Слишком размытый:

"System handles errors gracefully"

✅ Конкретный:

"If payment fails, show specific error:
- Insufficient funds: "Your card has insufficient funds"
- Expired card: "Your card has expired"
- Network error: "Please try again"

---

❌ Предполагающий реализацию:

"System caches user data in Redis for 5 minutes"

✅ Описывающий поведение:

"Profile loads within 200ms. When user updates profile,
changes are visible immediately."

Как обсудить поведение с командой

На встречи перед спринтом (refinement)

Ты: "Давайте обсудим поведение при ошибке платежа"

Developer: "Какие виды ошибок?"
Ты: "Платёжный сервис может вернуть: insufficient funds, expired card, network timeout"

Tester: "Как мы тестируем network timeout? У нас нет доступа к реальной API"
Tы: "Хороший вопрос. Engineering Lead, можешь подсказать?"

CTO: "Используем mock платёжного сервиса. Можем симулировать любую ошибку"

Теперь все согласны на один сценарий.

Инструменты для описания поведения

- Gherkin (для Given-When-Then)
- Flowchart tools: Draw.io, Lucidchart, Miro
- State machine tools: PlantUML, ArchiMate
- Sequence diagram: Mermaid, PlantUML
- Simple text: Google Docs / Confluence (если простое требование)

Правило для Business Analyst

Перед тем как отправить требование разработчику, спросись себя:

1. Я описал, что система ДЕЛАЕТ (функция)?
2. Я описал, как система это ДЕЛАЕТ (поведение)?
3. Я описал, как система ведёт себя при ОШИБКЕ?
4. Я описал граничные случаи (edge cases)?
5. Есть ли неоднозначности, которые разработчик неправильно интерпретирует?

Если на все вопросы ты ответил "да" → требование готово. Если хотя бы один "нет" → требование нужно дополнить.

Вывод: описание поведения — это не наука, это искусство быть précis (точным) и полным. Используй Given-When-Then для 80% требований, и это будет достаточно.