Как формируешь системные требования на текущем проекте?

Как формируешь системные требования на текущем проекте?

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

Фаза 1: Сбор информации

Интервьюирование стейкхолдеров

Получаю требования от:

• Product Owner — бизнес-требования, приоритеты
• UX/Design — пользовательские сценарии
• DevOps / Infrastructure — operational constraints
• Security — требования безопасности
• Existing Users — pain points текущих решений

Методика: структурированные вопросы, use cases, user journeys

Анализ документации

• Существующие системные требования (legacy)
• Архитектурные решения в docs/architecture/
• Decisions в docs/architecture/02_decisions.md
• API specification и схемы БД

Изучение бизнес-контекста

• Бизнес-процессы, которые поддерживает система
• KPI и метрики успеха
• Планы масштабирования (сколько пользователей за X месяцев)
• Compliance требования (GDPR, data protection)

Фаза 2: Категоризация требований

Функциональные требования (FRs)

Что система должна ДЕЛАТЬ:

• FR-1: Аутентификация

  • Система должна поддерживать вход по email и паролю
  • Пароль должен быть >= 8 символов, с цифрой и спецсимволом
  • After 3 failed attempts → block на 15 минут
  • Recovery по email ссылке (действительна 24h)

• FR-2: Search и Filtering

  • Поиск по названию, описанию (fuzzy match)
  • Фильтры: категория, статус, дата, цена
  • Результаты пагинированы по 20 items

Нефункциональные требования (NFRs)

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

Производительность:

• P95 response time: <= 200ms (99% запросов)
• Throughput: >= 1000 RPS при P99 < 500ms
• Latency search: <= 100ms (в памяти, не на диск)

Надёжность:

• Availability: 99.95% uptime (< 22 мин/месяц downtime)
• Recovery Time Objective (RTO): 30 минут
• Recovery Point Objective (RPO): < 5 минут потерь данных

Масштабируемость:

• Horizontal scaling: 3→300 пользователей без пересмотра архитектуры
• Database: должна работать при 1 млн записей
• Storage: запас на 2 года роста данных

Безопасность:

• Все пароли хешированы bcrypt (не MD5!)
• HTTPS обязателен (TLS 1.2+)
• Rate limiting: 100 requests/min per IP
• SQL injection protection (prepared statements)
• XSS protection (Content Security Policy)

Интеграция:

• API версионирование (v1, v2)
• Backward compatibility минимум 2 версии
• REST стандарт (no RPC-style endpoints)

Фаза 3: Определение ограничений

Technical Constraints

• Stack: Python/FastAPI, React, PostgreSQL
• Python версия: >= 3.10
• Deployment: Docker + Kubernetes
• Timezone: UTC (Moscow только на фронте)

Organizational Constraints

• Team size: 3 backend, 2 frontend, 1 DevOps
• Development cycle: 2-week sprints
• Budget: AWS t3.medium instances

External Constraints

• Third-party APIs: Stripe (payment), SendGrid (email)
• Data residency: GDPR compliance (EU servers)
• SLA: Stripe API availability 99.9%

Фаза 4: Документирование

Структура документа

Основной файл: docs/requirements/system_requirements.md

Документ включает:

• Обзор
• Функциональные требования
• Нефункциональные требования
• Ограничения
• Риски
• Assumptions
• Open Questions

Отслеживание в GitHub Issues

• Label: requirements
• Tag: system-requirement
• Очерёдность по приоритету

Фаза 5: Валидация с командой

Design Review

• Разработчики оценивают feasibility
• Выявляют missing requirements
• Обсуждают trade-offs

Risk Assessment

Например:

• Risk: Database не выдержит 100k QPS
• Mitigation: Caching layer (Redis)
• Backup plan: Sharding

Acceptance Criteria

Для каждого requirement:

• Выполнимо с текущей архитектурой
• Есть ясный способ тестирования
• Определены success metrics
• Согласовано с Product Owner

Фаза 6: Приоритизация

MoSCoW метод:

• Must have (MVP): аутентификация, core features
• Should have: analytics, advanced filters
• Could have: recommendations, dark mode
• Won't have: video upload, live collaboration

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

• Confluence / Notion — документация
• Miro / FigJam — диаграммы, mind maps
• GitHub Issues / Jira — отслеживание
• Spreadsheets — таблицы сравнения, матрицы приоритета
• Database diagrams — dbdiagram.io или PlantUML

Ключевые принципы на практике

1. SMART критерии

• S (Specific): не "быстро", а "< 200ms"
• M (Measurable): есть способ измерить
• A (Achievable): реалистично в рамках спринта
• R (Relevant): связано с бизнес-целями
• T (Time-bound): deadline ясен

2. Living document Требования обновляются в процессе:

• Новые insights → update docs
• Tech debt → reassess constraints
• User feedback → refine FRs

3. Collaboration over perfection

• Лучше согласовать требования быстро, чем писать идеальный документ
• Регулярные синхронизации с team
• Итеративное уточнение

4. Trade-offs documentation Пример:

• Option A: Cheap hosting, slow (P95 500ms)
• Option B: Premium hosting, fast (P95 50ms)
• Выбор: A сейчас, upgrade при 10k users

Чеклист готовности

• Все стейкхолдеры согласны с требованиями
• FRs полностью описаны use cases
• NFRs имеют измеримые метрики
• Ограничения задокументированы
• Risks identified и mitigation planned
• Team оценила effort (story points)
• Acceptance criteria понятны QA
• Documentation в version control
• Решения согласованы в decisions.md

Процесс формирования требований — это баланс между амбициями, реальностью и feedback от team. Главное — слушать, документировать и итеративно улучшать.