В чем разница между видами требований?

Виды требований: полная классификация

Business Analyst работает с разными видами требований. Понимание их различий критично для правильного анализа.

Основная классификация

Функциональные требования (FR) — описывают, ЧТО система должна делать Нефункциональные требования (NFR) — описывают, КАК система должна это делать

1. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

Определение: Описание функций, действий, которые система должна выполнять.

Примеры:

• Пользователь может войти через email и пароль
• Система отправляет уведомление когда товар в наличие
• При сортировке по цене товары упорядочиваются

Характеристики:

• Видны пользователю
• Можно протестировать (yes/no)
• Описываются в user stories и use cases

Виды функциональных требований:

a) Основная функциональность

• Авторизация, регистрация
• CRUD операции
• Поиск и фильтрация
• Уведомления

b) Интеграции

• Платёжные системы
• Email провайдер
• CRM синхронизация

c) Отчёты

• Экспорт в CSV
• Генерация PDF
• Аналитика

d) Расширения

• Поддержка плагинов
• API для третьих
• Custom fields

2. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ

Определение: Требования к качественным характеристикам системы.

Виды NFR:

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

• Страница загружается < 3 сек
• API отвечает < 200 ms
• Обработка 1000 запросов в сек

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

• 99.9% доступность (SLA)
• MTTR < 30 минут
• 4 часа downtime в году

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

• Пароли bcrypt с salt
• TLS 1.2 для данных
• Логирование всех доступов
• PCI DSS для платежей

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

• От 10k до 1M пользователей
• Горизонтальное масштабирование
• Кэширование для БД

e) Удобство (Usability)

• Понять интерфейс за 5 минут
• Первый заказ за < 3 шага
• WCAG 2.1 AA доступность

f) Совместимость (Compatibility)

• Chrome, Firefox, Safari, Edge (последние 2 версии)
• Адаптивность 320px до 2560px
• IE 11 если критично

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

• Code coverage >= 80%
• Документирован каждый метод
• Архитектура позволяет расширяться

h) Локализация (Localization)

• 5 языков (RU, EN, DE, FR, ES)
• Специальные символы
• Форматы дат/времени

i) Compliance (Соответствие)

• GDPR
• HIPAA (healthcare)
• CCPA (California)
• Security audits

3. КЛАССИФИКАЦИЯ по УРОВНЮ АБСТРАКЦИИ

Business Requirements

• Уровень: Стратегический
• Пример: Увеличить доход на 20%

User Requirements

• Уровень: Пользовательский
• Пример: Как клиент, хочу видеть рекомендации

System Requirements

• Уровень: Технический
• Пример: Использовать ML алгоритм для рекомендаций

4. ДОКУМЕНТИРОВАНИЕ ТРЕБОВАНИЙ

User Stories As a role, I want action, So that benefit

Use Cases Детальные сценарии взаимодействия, основной и альтернативные потоки

Спецификации Технический документ с диаграммами и таблицами

Требования как условия Если <условие>, то <результат>

5. КЛАССИФИКАЦИЯ по ИСТОЧНИКУ

От клиента — функциональные требования От пользователей — выявленные через research От регуляторов — compliance, security От инфраструктуры — performance, scalability

6. ПО СТАБИЛЬНОСТИ

Стабильные — хорошо понимаемые Нестабильные — могут измениться Под вопросом — требуют исследования

Пример: Фильтрация по цене

Функциональное: As a customer, I want to filter by price, So that I find affordable products

NFR - Performance: API < 100ms, UI < 300ms

NFR - Usability: Слайдер интуитивен, адаптивен на мобильной

NFR - Compatibility: Кроме, Firefox, Safari, Edge. 320-2560px

NFR - Security: Пользователь не видит чужие цены

Типичные ошибки

• Забывают про NFR
• Смешивают уровни абстракции
• Забывают про compliance
• Недооценивают importance NFR

Вывод

BA должен документировать:

• Функциональные — ЧТО делает
• Нефункциональные — КАК качественно
• На разных уровнях — от бизнеса к технике
• Все виды — performance, security, compliance

Если забыть про вид требований, проект провалится.