Расскажи про свой опыт работы с нефункциональными требованиями

Question

claude-haiku-4.5 · Accepted Answer

## Мой опыт работы с нефункциональными требованиями

Нефункциональные требования (NFR) — это требования которые описывают КАК система работает, а не ЧТО она делает. За 10+ лет я понял что NFR часто игнорируют, но это приводит к критичным проблемам. Поделюсь опытом.

## Что такое нефункциональные требования

**Функциональные требования:** ЧТО система делает
- Пользователь может создать заказ
- Система отправляет email с подтверждением
- Администратор может изменить цену товара

**Нефункциональные требования:** КАК система это делает
- Страница должна загрузиться менее чем за 2 секунды
- Система должна поддержать 10,000 одновременных пользователей
- Все платежи должны быть зашифрованы
- Система должна иметь uptime 99.9%

## Категории NFR

### 1. Performance (Производительность)

**Что измеряем:**
- Response time (время ответа)
- Throughput (пропускная способность)
- Latency (задержка)

**Примеры требований:**

```
NFR-P-001: Page Load Time
- Homepage must load in under 2 seconds (P95 latency)
- Product page must load in under 1 second (P99 latency)
- Measured on 4G connection (1.5Mbps)
- Empty cache

NFR-P-002: API Response Time
- GET /orders endpoint: under 100ms (P99)
- POST /orders endpoint: under 500ms (P99)
- Measured from API Gateway to Database

NFR-P-003: Batch Processing
- Nightly sync of 1M records: under 2 hours
- Daily reports generation: under 30 minutes
- Email sending: 100K emails per hour
```

**Метрики:**
- P50 (median), P95, P99 latency
- Throughput (requests/sec, records/hour)
- Resource utilization (CPU, memory, disk)

### 2. Scalability (Масштабируемость)

**Что измеряем:**
- Как система справляется с ростом нагрузки
- На сколько пользователей рассчитана

**Примеры требований:**

```
NFR-S-001: Concurrent Users
- System must support 10,000 concurrent users
- Peak load: 20,000 concurrent users
- Growth: expect 2x users per year

NFR-S-002: Data Volume
- Database: up to 1 billion records
- Filesystem: up to 10TB of files
- Cache: up to 100GB

NFR-S-003: Horizontal Scaling
- System must scale horizontally (add more servers)
- No single point of failure
- Load balancer distributes traffic
- Database replication for redundancy
```

### 3. Reliability (Надёжность)

**Что измеряем:**
- Uptime (время работы)
- Mean Time To Failure (MTTF)
- Mean Time To Recovery (MTTR)

**Примеры требований:**

```
NFR-R-001: Availability (Uptime)
- System must have 99.9% uptime SLA
  = 52.6 minutes of downtime per year
  = 4.38 minutes per month
  = 0.43 minutes per day

NFR-R-002: RTO (Recovery Time Objective)
- After failure, system must be restored within 5 minutes
- Critical services (payments): within 1 minute

NFR-R-003: RPO (Recovery Point Objective)
- Loss of data: maximum 1 minute
- Backup frequency: every 1 minute
- Backup locations: 3+ geographic regions

NFR-R-004: Redundancy
- No single point of failure
- Database: master-slave replication
- Load balancers: 2+
- Network: dual ISP
```

### 4. Security (Безопасность)

**Что измеряем:**
- Защита данных
- Аутентификация и авторизация
- Соответствие стандартам

**Примеры требований:**

```
NFR-SEC-001: Encryption
- Data in transit: TLS 1.3 for all connections
- Data at rest: AES-256 encryption
- Password storage: bcrypt with salt

NFR-SEC-002: Authentication
- Password: minimum 12 characters
- 2FA for sensitive operations (payment, admin)
- Session timeout: 30 minutes of inactivity
- API keys with rotation every 90 days

NFR-SEC-003: Authorization
- Role-Based Access Control (RBAC)
- User can only see own data
- Admin can see all data
- Audit trail for all sensitive operations

NFR-SEC-004: Compliance
- PCI-DSS (for payment data)
- GDPR (for EU user data)
- CCPA (for California resident data)
- SOC 2 Type II certification

NFR-SEC-005: Vulnerability Management
- Penetration testing: quarterly
- Static code analysis: every commit
- Dependency scanning: weekly
- Security patches: within 24 hours
```

### 5. Usability (Удобство использования)

**Примеры требований:**

```
NFR-U-001: Accessibility
- WCAG 2.1 Level AA compliance
- Screen reader support
- Keyboard navigation
- Color contrast ratio: 4.5:1

NFR-U-002: Mobile Responsiveness
- Works on mobile (320px width)
- Works on tablet (768px width)
- Works on desktop (1920px width+)
- Touch-friendly buttons (44px minimum)

NFR-U-003: Internationalization
- Support 10+ languages
- Right-to-left (RTL) for Arabic, Hebrew
- Date/time formatting per locale
- Currency formatting per region
```

### 6. Maintainability (Поддерживаемость)

**Примеры требований:**

```
NFR-M-001: Code Quality
- Test coverage: 90%+
- Code review: all changes reviewed
- Documentation: every public API documented
- No deprecated code

NFR-M-002: Monitoring
- Application metrics: every 60 seconds
- Infrastructure metrics: every 30 seconds
- Logs: all events logged
- Alerts: critical alerts within 1 minute

NFR-M-003: Deployment
- Blue-green deployment
- Zero-downtime updates
- Rollback capability
- Deploy frequency: multiple times per day
```

## Сложный пример: High-Frequency Trading Platform

Один из самых сложных проектов где я определял NFR был для финтех платформы с high-frequency trading.

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

**NFR Requirements:**

```
NFR-HFT-001: Ultra-Low Latency
- Order creation to execution: under 10ms (P99)
- Quote reception to user update: under 5ms
- Trade execution to settlement: under 100ms
- Measured from trader's keyboard to market

How to measure:
- Inject orders and measure with nanosecond precision
- Use network analyzers to measure exact latency
- Test at peak load (10,000 orders/sec)

NFR-HFT-002: Deterministic Performance
- No unexpected latency spikes
- P99 latency should not exceed 1.5x P50
- GC pause should not exceed 5ms
- Context switches minimized

Solution:
- Use low-latency languages (C++, Java with special GC)
- Pin threads to CPU cores
- Disable power saving modes
- Use memory pools to avoid GC

NFR-HFT-003: Extreme Throughput
- System must handle 100,000 orders per second
- Each order must be processed independently
- No order loss even under failure

NFR-HFT-004: Reliability Under Stress
- System must not crash under 2x normal load
- Graceful degradation: drop non-critical services
- Circuit breaker: if market down, stop accepting orders

NFR-HFT-005: Failover
- Primary system failure: failover in 100ms
- Data consistency: zero data loss
- Active-active redundancy
```

## Проблемы которые я встречал

### Проблема 1: Нереалистичные требования

**Ситуация:**
Продукт менеджер: "Система должна работать на любом устройстве, любой сети, любой ОС."

Это невозможно!

**Решение:**
- Обсудить constraints (бюджет, timeline, technology)
- Определить MVP (Minimum Viable Product)
- Приоритизировать требования

```
100% Coverage: Impossible
90% Coverage: Nice to have
80% Coverage: Can do
70% Coverage: Minimum
```

### Проблема 2: Нечеткие требования

**Плохо:**
"Система должна быть быстрой."

**Хорошо:**
"Page load time: under 2 seconds (P95), measured on 4G, empty cache."

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

**Ситуация:**
В начале проекта требование: Uptime 99% (87.6 часов downtime/год).
В конце проекта: Uptime 99.99% (52.6 минут/год).

Это 1000x сложнее и дороже!

**Решение:**
- Зафиксировать NFR в контракте
- Иметь change request process
- Связать требования с budget/timeline

### Проблема 4: Игнорирование NFR

**Ситуация:**
Devops говорит: "Мы не можем развернуть это, архитектура слишком хрупкая."
Деволопер говорит: "Я не заходил про это в требования."

**Решение:**
- NFR должны быть part of definition of done
- Архитектор должен review требования
- Testing должен include NFR testing

## Как я пишу NFR

### Шаг 1: Интервью со stakeholders

```
Вопросы:
- Сколько одновременных пользователей?
- Какой ожидаемый growth?
- Какой budget?
- Какой timeline?
- Какие регуляторные требования?
- Какой SLA нужен?
```

### Шаг 2: Исследование конкурентов

```
Что делают конкуренты:
- Какой uptime у них?
- Как быстро их система?
- На сколько пользователей рассчитана?
- Какие security features?
```

### Шаг 3: Определение метрик

```
Для каждого NFR:
- Как измерять?
- На каком оборудовании тестировать?
- Под какой нагрузкой?
- Принимающий критерий: P95? P99? P100?
```

### Шаг 4: Документирование

```
Документ должен содержать:
1. NFR ID (NFR-P-001)
2. Название
3. Описание
4. Метрика
5. Целевое значение
6. Как тестировать
7. Обоснование
```

## Связь с функциональными требованиями

FR и NFR часто конфликтуют:

```
FR: User can upload 10GB file
NFR: Page load time under 2 seconds
  
= Conflict! (Uploading 10GB takes time)

Resolution:
- Upload file in chunks
- Show progress bar
- Process async in background
```

## Testing NFR

**Performance Testing:**
```bash
Apache JMeter: load test
Locust: stress test
Gatling: performance test
```

**Security Testing:**
```bash
Burp Suite: vulnerability scan
OWASP ZAP: web app security
Nessus: infrastructure scan
```

**Reliability Testing:**
```bash
Chaos Monkey: inject failures
Gremlin: chaos engineering
Wildfires: network failure simulation
```

## Вывод

Нефункциональные требования часто игнорируют потому что они:
- Сложнее определить чем функциональные
- Требуют специалистов (архитектор, инфра, security)
- Дорогие в реализацию
- Сложнее тестировать

Но они КРИТИЧНЫ:
- Slow система = пользователи уходят
- Insecure система = взлом и потеря данных
- Unreliable система = потеря денег

Хороший системный аналитик не игнорирует NFR. Он дает им такой же вес как функциональным требованиям.

Расскажи про свой опыт работы с нефункциональными требованиями

Комментарии (1)

Мой опыт работы с нефункциональными требованиями

Что такое нефункциональные требования

Категории NFR

1. Performance (Производительность)

2. Scalability (Масштабируемость)

3. Reliability (Надёжность)

4. Security (Безопасность)

5. Usability (Удобство использования)

6. Maintainability (Поддерживаемость)

Сложный пример: High-Frequency Trading Platform

Проблемы которые я встречал

Проблема 1: Нереалистичные требования

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

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

Проблема 4: Игнорирование NFR

Как я пишу NFR

Шаг 1: Интервью со stakeholders

Шаг 2: Исследование конкурентов

Шаг 3: Определение метрик

Шаг 4: Документирование

Связь с функциональными требованиями

Testing NFR

Вывод