Расскажи про свой опыт описания требований

Мой опыт описания требований

Описание требований — это ядро работы системного аналитика. От качества требований зависит все: разработка, тестирование, качество продукта. За 10+ лет я видел от идеальных до ужасных требований, и научился на обоих.

Почему требования часто делают плохо

В начале моей карьеры я думал, что аналитик просто пишет документ и отправляет разработчикам. Быстро понял что это не работает. Проблемы:

Проблема 1: Размытые требования

Денормализованный случай: "Система должна быть быстрой."

Разработчик вопрос: Как быстрой? 1 сек? 100мс?

Правильно: "Система должна загружать список заказов с максимум 50 записей за менее чем 200мс (P99 latency)."

Проблема 2: Неполные требования

Денормализованный случай: "Пользователь может создавать заказы."

Вопросы разработчика:

• Может ли создать заказ без товаров?
• Что если нет денег?
• Может ли создать заказ другому пользователю?
• Какой максимум товаров в заказе?

Правильно: Список критериев приемки, edge cases, исключения.

Проблема 3: Конфликтующие требования

Общее происходит когда разные stakeholders хотят разное:

• CEO: "Нам нужны максимум фичи к дате X"
• CTO: "Мы не можем доделать в срок без денег на людей"
• Product: "Качество должно быть идеальным"

Аналитик должен разрешить эти конфликты.

Проблема 4: Требования меняются

Этого избежать нельзя. Но можно быть готовым:

• Документировать assumptions
• Иметь процесс для изменения требований
• Понимать impact каждого изменения

Как я пишу требования

Шаг 1: Интервью и исследование

Прежде чем писать что-либо, я:

• Провожу интервью с заказчиком
• Изучаю текущие процессы
• Смотрю конкурентов
• Собираю и организую информацию

Шаг 2: Структурирую требования

Я использую вот такую структуру (может быть разная):

1. Executive Summary

"Создание мобильного приложения для розничных инвесторов с целью позволить им торговать акциями в реальном времени с задержкой менее 2 секунд. Целевой рынок: 100,000 пользователей в первый год. Бюджет: $500k. Timeline: 12 месяцев."

2. Functional Requirements

Что система должна делать. Я группирую по функциональным областям:

### FR-001: User Authentication
- FR-001.1: User registration with email
- FR-001.2: Email verification
- FR-001.3: Password reset
- FR-001.4: Two-factor authentication (2FA) for sensitive operations

### FR-002: Quote Streaming
- FR-002.1: Real-time stock quotes
- FR-002.2: Quote history (last 24 hours)
- FR-002.3: Subscribe to quotes for specific stocks

### FR-003: Order Management
- FR-003.1: Create market order
- FR-003.2: Create limit order
- FR-003.3: Cancel order
- FR-003.4: View order history

3. Non-Functional Requirements

Как система должна работать:

### NFR-001: Performance
- Page load: менее 2 сек
- Quote update latency: менее 100мс
- Order creation: менее 500мс

### NFR-002: Scalability
- Support 100,000 concurrent users
- Handle 10,000 orders per second
- Database: 1B+ records

### NFR-003: Reliability
- Uptime: 99.9% SLA
- Disaster recovery: < 1 hour RTO
- Backup: daily incremental, weekly full

### NFR-004: Security
- TLS 1.3 for all communication
- AES-256 encryption for sensitive data
- PCI-DSS compliance

4. Data Models

Я рисую диаграмму Entity-Relationship (ER) и описываю каждую сущность:

User
- id (UUID)
- email (VARCHAR(255), unique)
- password_hash (VARCHAR(255))
- created_at (TIMESTAMP)
- updated_at (TIMESTAMP)

Order
- id (UUID)
- user_id (FK -> User.id)
- symbol (VARCHAR(10)) e.g., "AAPL"
- order_type (ENUM: MARKET, LIMIT, STOP_LOSS)
- quantity (INTEGER, >= 1, <= 10000)
- price (DECIMAL(10,2), nullable for MARKET orders)
- status (ENUM: PENDING, FILLED, CANCELLED)
- created_at (TIMESTAMP)

5. API Specifications

Для каждого endpoint я документирую:

### POST /api/v1/orders

Описание: Create a new order

Request:
{
  "symbol": "AAPL",
  "order_type": "LIMIT",
  "quantity": 100,
  "price": 150.50
}

Response (201 Created):
{
  "id": "uuid-here",
  "status": "PENDING",
  "created_at": "2024-01-15T10:30:00Z"
}

Response (400 Bad Request):
{
  "error": "INSUFFICIENT_FUNDS",
  "message": "Your account balance is insufficient for this order"
}

Response (400 Bad Request):
{
  "error": "RISK_LIMIT_EXCEEDED",
  "message": "This order would exceed your daily risk limit"
}

6. User Flows / Scenarios

Я описываю типичные сценарии использования:

### Scenario 1: Happy Path - Create and Fill Limit Order

1. User logs in
2. User clicks "New Order"
3. User selects stock: "AAPL"
4. User selects order type: "LIMIT"
5. User enters quantity: 100
6. User enters price: $150
7. User clicks "Place Order"
8. System validates order (balance, risk limits)
9. System creates order with status PENDING
10. System sends confirmation to user
11. Market price reaches $150
12. System matches user's order
13. System updates order status to FILLED
14. System sends notification to user
15. User sees filled order in history

### Scenario 2: Error Case - Insufficient Funds

1. User has $5,000 in account
2. User tries to place order for 100 shares at $100 = $10,000
3. System validates balance: FAIL
4. System returns error: "Insufficient funds. You need $5,000 more."
5. User sees error message
6. Order is NOT created

7. Business Rules

Я документирую правила которые регулируют бизнес-логику:

### BR-001: Order Validation
- Quantity must be between 1 and 10,000
- Price (for LIMIT orders) must be positive
- Price precision: max 2 decimal places
- Cannot place order for non-existent symbol

### BR-002: Risk Management
- Maximum order size: 10% of account balance
- Maximum daily loss: 5% of account balance
- If loss threshold reached, no new orders allowed

### BR-003: Order Matching
- Orders matched by FIFO (First In First Out) at same price
- Partial fills allowed
- Order valid for 30 days (after that auto-cancelled)

8. Acceptance Criteria

Для каждого требования я пишу критерии как проверить что оно выполнено:

### AC-001: Order Creation

Given: User has $10,000 in account
When: User creates LIMIT order (100 shares, $100/share)
Then:
- Order is created with status PENDING
- Order appears in user's order history
- Confirmation email is sent
- User sees on-screen confirmation
- Order is visible to market makers

9. Constraints и Assumptions

Я документирую ограничения и предположения:

### Constraints
- Must integrate with Bloomberg API for quotes
- Must comply with SEC regulations
- Database must be in US (data residency)
- Mobile app must support iOS 12+ and Android 8+

### Assumptions
- Internet connectivity: 3G or better
- User has valid email address
- Users want to trade during market hours (9:30 AM - 4:00 PM EST)
- Quote provider (Bloomberg) has 99.9% uptime

Типичные ошибки которые я делал

Ошибка 1: Слишком вербально

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

Хорошо: "Пользователь может создать market order на покупку 100 акций AAPL. Ордер исполнится по лучшей доступной цене в течение менее чем 2 сек. Пользователь получит подтверждение по email и в приложении."

Ошибка 2: Требования содержат технические решения

Плохо: "Система должна использовать Kafka для обработки ордеров."

Это решение, не требование!

Хорошо: "Система должна обрабатывать 10,000 ордеров в секунду с latency менее 100мс."

Это требование. Как реализовать (Kafka, Pulsar, custom queue) — решение архитектора.

Ошибка 3: Забываю про исключения

Плохо: "Пользователь может создать ордер."

Хорошо: "Пользователь может создать ордер если:

• У него есть активный аккаунт
• У него есть достаточно средств
• Он не превысил daily risk limit
• Сессия не закрыта

Иначе ордер отклоняется с подходящей ошибкой."

Ошибка 4: Не документирую assumptions

Основная причина конфликтов — разные люди делают разные assumptions.

Плохо: ничего про assumptions

Хорошо: "Мы предполагаем что:

• Quote provider Bloomberg имеет 99.9% uptime
• Пользователи используют стабильное интернет-соединение
• Регуляторы не изменят правила (важно для финансов!)

Если assumptions поменяются, требования нужно пересмотреть."

Как я управляю изменениями требований

Проблема: Требования всегда меняются

Заказчик может сказать в конце проекта: "А можно еще добавить..."

Это normal. Но нужен процесс:

Шаг 1: Документирую изменение "Вместо 3NF нормализации нужна 4NF"

Шаг 2: Оцениваю impact

• Сложность: средняя
• Timeline: +2 недели
• Budget: +$20k
• Risk: низкий

Шаг 3: Согласую с заказчиком "Это изменение добавит 2 недели и $20k. Вы готовы?"

Шаг 4: Обновляю документ требований Добавляю версию, дату, кто одобрил, почему.

Шаг 5: Коммуникирую команде Все знают что требования поменялись.

Как я проверяю качество требований

Перед отправкой требований разработчикам, я проверяю:

Чеклист качества требований

• Каждое требование SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
• Нет противоречий между требованиями
• Все Acceptance Criteria ясны и проверяемы
• Edge cases и исключения задокументированы
• Assumptions явные
• Non-Functional Requirements заданы (performance, security, scalability)
• Data models нормализованы и логичны
• API specifications полны (request, response, error cases)
• User flows описаны для основных сценариев
• Business rules явно написаны
• Вся команда (dev, QA, product) согласна

Если хотя бы один пункт не выполнен, требования еще не готовы.

Инструменты которые я использую

• Confluence/Notion — для документирования
• dbdiagram.io — для ER диаграмм
• Lucidchart — для flowcharts и диаграмм
• Figma — для UI mockups
• Jira — для отслеживания требований
• Miro — для совместного уточнения с командой

Вывод

Хорошие требования — это:

• Ясные — однозначное понимание
• Полные — нет пробелов и edge cases
• Проверяемые — можно написать тест для каждого
• Реалистичные — достижимы в given timeline/budget
• Приоритизированные — понятно что important
• Документированные — в одном месте
• Согласованные — все stakeholders agree

Хороший аналитик не просто пишет требования. Он:

• Глубоко понимает бизнес
• Слушает все stakeholders
• Разрешает конфликты
• Документирует assumptions
• Готов к изменениям
• Проверяет качество