Урок 01.04: Классификация требований
Цель урока
Научиться классифицировать требования по типам и уровням (от бизнес- до системных), освоить модель FURPS+ с подробными примерами по каждой категории и получить чёткий гайд, как никогда не путать функциональные требования с нефункциональными.
Ключевые понятия
- Требование (Requirement) — условие или возможность, которой должна обладать система; формулируется однозначно, проверяемо и измеримо
- Бизнес-требования — высокоуровневые цели организации, ради которых затевается проект
- Пользовательские требования — описание того, что пользователи смогут делать в системе (часто в формате User Stories)
- Функциональные требования (ФТ) — описание конкретного поведения системы: «что система должна делать»
- Нефункциональные требования (НФТ / NFR) — описание ограничений и атрибутов качества: «как система должна это делать»
- FURPS+ — модель классификации требований от Hewlett-Packard: Functionality, Usability, Reliability, Performance, Supportability + дополнительные категории
- Бизнес-правило (Business Rule) — правило или политика компании, которая может не автоматизироваться в системе, но влияет на требования
1. Пирамида требований: от бизнеса до кода
Требования живут на разных уровнях абстракции. Системный аналитик — тот, кто спускается от верхних уровней к нижним.
Уровень 1: БИЗНЕС-ТРЕБОВАНИЯ
┌─────────────────────────────────────────┐
│ «Увеличить скорость обработки заказов │
│ на 30% за счёт автоматизации» │
└────────────────┬────────────────────────┘
↓ (декомпозиция)
Уровень 2: ПОЛЬЗОВАТЕЛЬСКИЕ ТРЕБОВАНИЯ
┌─────────────────────────────────────────┐
│ «Как оператор, я хочу создавать заказ │
│ за 3 клика, чтобы не тратить время │
│ на лишние поля» │
└────────────────┬────────────────────────┘
↓ (детализация)
Уровень 3: ФУНКЦИОНАЛЬНЫЕ + НЕФУНКЦИОНАЛЬНЫЕ
┌─────────────────────┬───────────────────┐
│ ФТ: «Система должна │ НФТ: «Время │
│ автоматически │ создания заказа │
│ подставлять данные │ не должно │
│ клиента по номеру │ превышать 30 сек │
│ телефона» │ при скорости │
│ │ интернета 1 Мбит» │
└─────────────────────┴───────────────────┘
↓ (ещё детальнее)
Уровень 4: СИСТЕМНЫЕ ТРЕБОВАНИЯ / СПЕЦИФИКАЦИЯ
┌─────────────────────────────────────────┐
│ «API POST /api/v1/orders принимает │
│ JSON: {customer_phone, items}. │
│ Ответ: 201 {order_id, status}» │
└─────────────────────────────────────────┘
Роль аналитика: Пройти по всем уровням — от бизнес-цели (уровень 1) до конкретной спецификации API (уровень 4), сохраняя целостность и трассируемость.
2. Классификация по FURPS+ — подробный разбор
FURPS+ — это акроним, предложенный компанией Hewlett-Packard для классификации нефункциональных требований, но на практике его расширяют и используют как полную систему классификации требований (отсюда «+» в конце — добавленные категории).
2.1. F — Functionality (Функциональность)
Что это: Основные функции системы, возможности, которые она предоставляет пользователю. Это ответ на вопрос «ЧТО система делает?».
Подкатегории:
- Feature set — набор функций
- Security — аутентификация, авторизация, шифрование (в контексте функциональности безопасности)
- Accuracy — точность вычислений
5+ подробных примеров функциональных требований:
| № | Пример требования | Пояснение |
|---|---|---|
| 1 | FR-001: Система должна позволять пользователю авторизоваться по email и паролю. | Базовая функция входа. Включает: проверка формата email, проверка существования пользователя, хеширование пароля, выдача сессионного токена (JWT). |
| 2 | FR-012: Система должна отправлять email-уведомление пользователю после успешной регистрации. | Функция отправки уведомления. Включает: генерация письма (тема, тело), вызов SMTP-сервера, обработка ошибок доставки, логирование факта отправки. |
| 3 | FR-034: Система должна рассчитывать стоимость доставки на основе веса посылки и расстояния по тарифам транспортной компании. | Бизнес-логика. Включает: запрос веса из корзины, запрос адреса, получение тарифов из внешнего API (СДЭК / Boxberry), расчёт, отображение пользователю. |
| 4 | FR-056: Система должна генерировать PDF-счёт на оплату с номером заказа, суммой, НДС и QR-кодом. | Функция генерации документов. Включает: шаблон документа (движок шаблонов), вставка данных, генерация QR-кода со ссылкой на оплату, сохранение в облачное хранилище. |
| 5 | FR-078: Администратор должен иметь возможность заблокировать пользователя (деактивировать аккаунт), после чего пользователь не может войти в систему. | Административная функция. Включает: поиск пользователя, изменение статуса (active → blocked), завершение текущих сессий, логирование действия. |
| 6 | FR-091: Система должна каждую ночь в 02:00 запускать сверку остатков товаров с данными складского учёта 1С. | Scheduled job / пакетная обработка. Включает: триггер по расписанию (cron), вызов API 1С, сравнение данных, формирование отчёта о расхождениях. |
2.2. U — Usability (Удобство использования / Юзабилити)
Что это: Требования к пользовательскому опыту — насколько система удобна, интуитивна, доступна.
Важно: Usability-требования не описывают новые функции, а описывают качество взаимодействия с существующими функциями.
5+ подробных примеров требований Usability:
| № | Пример требования | Пояснение |
|---|---|---|
| 1 | US-001: Время освоения системы новым пользователем не должно превышать 15 минут (замеряется как время от первого входа до успешного создания первого заказа). | Измеримый критерий: проводится UX-тестирование с замером времени. |
| 2 | US-007: Все критические действия (списание денег, удаление данных, блокировка пользователя) должны требовать подтверждения: всплывающее окно с кнопками «Подтвердить» / «Отменить». | Защита от ошибок пользователя. Конкретный UI-паттерн. |
| 3 | US-015: Интерфейс должен быть доступен для людей с ограниченным зрением: минимальный контраст текста 4.5:1 (WCAG AA), поддержка screen reader (aria-label). | Требование accessibility (доступности). Соответствует стандарту WCAG 2.1. |
| 4 | US-022: Форма ввода должна содержать подсказки (placeholder) для каждого поля и валидировать ввод в реальном времени (неверный формат email — подсветка красным + сообщение «Неверный формат email»). | Улучшение пользовательского опыта: моментальная обратная связь. |
| 5 | US-031: Мобильная версия сайта должна повторять функциональность десктопной, но с адаптацией под сенсорное управление: кнопки не менее 44x44 px, свайп для переключения вкладок. | Mobile-first / адаптивный дизайн. |
| 6 | US-040: Пользователь должен иметь возможность отменить действие (undo) в течение 5 секунд после его совершения. Кнопка «Отменить» показывается в toast-уведомлении. | Паттерн «undo» — снижает страх случайных действий. |
2.3. R — Reliability (Надёжность)
Что это: Способность системы сохранять работоспособность в заданных условиях в течение заданного времени.
5+ подробных примеров требований Reliability:
| № | Пример требования | Пояснение |
|---|---|---|
| 1 | RL-001: Доступность системы (uptime) должна составлять 99.5% в месячном исчислении, исключая плановые окна обслуживания. | Формула: (общее время — время простоя) / общее время × 100%. 99.5% = ~3.6 часа простоя в месяц допустимо. |
| 2 | RL-008: Система должна автоматически восстанавливаться после сбоя (auto-healing): при падении одного экземпляра сервиса трафик должен переключаться на другой экземпляр в течение 10 секунд (High Availability). | Кластеризация, health check, load balancer. |
| 3 | RL-014: Время восстановления после аварии (RTO — Recovery Time Objective) не должно превышать 1 часа. Допустимая потеря данных (RPO — Recovery Point Objective) — не более 15 минут. | RTO = сколько времени восстанавливаем; RPO = сколько данных теряем. |
| 4 | RL-022: Платежи не должны теряться: если платёжный шлюз ответил успехом, но система упала до сохранения в БД — при восстановлении система должна выполнить компенсирующий запрос к шлюзу (check status). | Идемпотентность платежей + механизм сверки (reconciliation). |
| 5 | RL-035: При недоступности внешнего сервиса (API доставки) система должна сохранять заказ в статусе «Ожидание подтверждения» и повторять запрос каждые 5 минут с exponential backoff до 3 раз, затем — уведомить администратора. | Обработка временных ошибок (circuit breaker / retry pattern). |
| 6 | RL-042: Система должна корректно обрабатывать одновременные запросы от одного пользователя (race conditions): двойной клик на кнопку «Оплатить» не должен создавать два платёжных поручения. | Защита от duplicate запросов (блокировка на уровне UI + idempotency key на уровне API). |
2.4. P — Performance (Производительность)
Что это: Требования к скорости работы системы, времени отклика, пропускной способности, использованию ресурсов.
5+ подробных примеров требований Performance:
| № | Пример требования | Пояснение |
|---|---|---|
| 1 | PF-001: Время отклика API (95-й перцентиль) не должно превышать 500 мс для 95% запросов при нагрузке до 1000 RPS. | Измеряется в перцентилях (p95, p99). Важно: среднее — обманчивая метрика. |
| 2 | PF-008: Страница каталога товаров должна загружаться (First Contentful Paint) не более 2 секунд на мобильном устройстве с 3G-соединением. | Performance Budget: ограничение на время загрузки. |
| 3 | PF-015: Система должна поддерживать до 10 000 одновременных пользователей без деградации производительности более чем на 20%. | Load testing target. Определяет требования к масштабированию. |
| 4 | PF-023: Экспорт отчёта в Excel — не более 5 секунд для 10 000 записей. Для более 10 000 записей — асинхронный экспорт с уведомлением по email. | Разделение на синхронный / асинхронный режимы в зависимости от объёма. |
| 5 | PF-031: Размер передаваемых данных (JSON) по API /api/v1/orders/list не должен превышать 500 КБ на один ответ. Для больших объёмов — пагинация. | Ограничение payload: предотвращение подвисания клиентов при больших данных. |
| 6 | PF-039: Запрос поиска по каталогу должен возвращать первые результаты в течение 200 мс (использовать полнотекстовый поиск Elasticsearch / полнотекстовый индекс). | Требование к поисковому индексу, исключающее полное сканирование таблицы. |
2.5. S — Supportability (Поддерживаемость / Сопровождение)
Что это: Требования, облегчающие эксплуатацию, диагностику и развитие системы.
5+ подробных примеров требований Supportability:
| № | Пример требования | Пояснение |
|---|---|---|
| 1 | SP-001: Система должна логировать (journald / ELK) все ключевые действия: вход пользователя, создание заказа, изменение статуса, ошибки. Формат лога: timestamp, user_id, action, payload (без sensitive data). | Centralised logging. Аналитик определяет, какие действия считать «ключевыми». |
| 2 | SP-008: Все API-запросы должны содержать correlation ID (UUID), который передаётся в заголовке X-Request-ID и логируется на всех сервисах для сквозной трассировки. | Correlation ID — основа для отладки инцидентов в микросервисной архитектуре. |
| 3 | SP-014: Система должна предоставлять health check endpoint (GET /health) с информацией о статусе всех внешних интеграций (БД, платёжный шлюз, API доставки). | Health check — база для мониторинга и алертинга (Kubernetes liveness/readiness probe). |
| 4 | SP-022: Система должна поддерживать rolling update (обновление без остановки сервиса): при развёртывании новой версии старая и новая версии должны работать одновременно, трафик переключается постепенно. | Zero-downtime deployment. Важно для систем с требованием высокой доступности. |
| 5 | SP-030: Код системы должен сопровождаться README-файлом с инструкцией по локальному запуску (не более 5 шагов) и описанием переменных окружения. | Onboarding новых разработчиков. Не техническое, но процессное требование — аналитик может включить его в документ. |
| 6 | SP-037: Система должна иметь mode maintenance (страница «Ведутся технические работы»), который админ может включить одной командой (change config → deploy). | Позволяет проводить плановые работы без потери данных и с корректным уведомлением пользователей. |
2.6. «+» (Дополнительные категории)
Расширение FURPS+ включает:
| Категория | Суть | Пример |
|---|---|---|
| Design | Ограничения по дизайну, UI-фреймворку, фирменному стилю | «Интерфейс должен соответствовать гайдлайнам Material Design 3» |
| Implementation | Ограничения по технологиям, языкам, библиотекам | «Бэкенд реализовать на Java 17 + Spring Boot 3.x» |
| Interface | Требования к совместимости с внешними интерфейсами | «Система должна интегрироваться с 1С:Бухгалтерия через REST API» |
| Physical | Требования к физическому расположению, оборудованию | «Серверы должны размещаться в ЦОД, аттестованном по УЗ-1» |
| Legal / Regulatory | Юридические и регуляторные требования | «Система должна обеспечивать хранение персональных данных на территории РФ (152-ФЗ)» |
| Data | Требования к жизненному циклу данных | «Срок хранения архивных заказов — 5 лет, после — анонимизация» |
| Security | Отдельные требования безопасности | «Доступ по ролям: RBAC, минимум 3 роли (админ, оператор, аудитор)» |
Примечание: В разных источниках «+» может включать разный набор категорий. Важно не заучивать акроним, а понимать логику: любое ограничение, которое не является функциональным требованием и не входит в 5 основных категорий FURPS, отправляется в «+».
3. Гайд: как не перепутать функциональное требование с нефункциональным
Это одна из самых частых ошибок начинающих аналитиков. Вот 4 метода, которые помогут всегда отличать ФТ от НФТ.
Метод 1: Вопрос-тест «ЧТО vs КАК»
Задайте к требованию два вопроса:
| Вопрос | Если ответ относится к... | То это... |
|---|---|---|
| ЧТО система делает? | Действию, функции, результату | Функциональное требование |
| КАК система это делает? | Ограничению, условию, качеству, атрибуту | Нефункциональное требование |
Проверяем:
«Система должна отправлять email при регистрации»
❓ ЧТО? → отправляет email → ФТ
«Email должен доставляться не позднее 30 секунд после регистрации»
❓ КАК? → по времени (30 сек) → НФТ (Performance)
«Система должна вычислять стоимость доставки»
❓ ЧТО? → вычисляет стоимость → ФТ
«Система должна вычислять стоимость с точностью до копейки»
❓ КАК? → с точностью → НФТ (Accuracy — подкатегория F)
Метод 2: Тест «Удаление ФТ vs НФТ»
Представьте, что вы можете выключить это требование.
| Сценарий | Если убрать... | Тип |
|---|---|---|
| «Система НЕ отправляет email при регистрации» | Пользователь не получит письмо, но зарегистрироваться сможет → функция ослабла, но не исчезла | Это НФТ (usability / функциональная опция) — но строго говоря, если отправка email — это поведение системы, то это ФТ. |
| Уточним тест: | ||
| «Система НЕ аутентифицирует пользователя по паролю» | Пользователь не сможет войти → основная функция сломана | ФТ |
| «Система НЕ обеспечивает время отклика < 500 мс» | Функция работает, но медленно → система функционирует, но качество снижено | НФТ |
| «Система НЕ экспортирует отчёт в Excel» | Пользователь не может выгрузить отчёт → функция отсутствует | ФТ |
| «Система НЕ имеет uptime 99.5%» | Система работает, но может чаще падать → качество, но функция есть | НФТ |
Правило: Если удаление требования ломает пользовательский сценарий — это, скорее всего, ФТ. Если сценарий остаётся, но становится менее удобным, быстрым или безопасным — это НФТ.
Метод 3: Тест «Измеримость и инструмент проверки»
| Тип требования | Как проверить (инструмент) | Критерий |
|---|---|---|
| ФТ | Функциональный тест (ручной / автотест) | «Нажал кнопку — получил результат. Да/Нет» |
| НФТ | Нагрузочный тест / замер времени / аудит | «Замерил — уложился в порог / не уложился» |
Пример:
- «ФТ: При нажатии "Экспорт" система выгружает XLSX-файл» → Проверка: нажать → получить файл. ✅ / ❌
- «НФТ: Время экспорта — не более 5 секунд для 1000 записей» → Проверка: замерить время при 1000 записей. 5 сек ✅ / > 5 сек ❌
Подсказка: Если в требовании есть численные метрики (95%, < 200 мс, > 10 000 пользователей, 99.9%), это почти всегда НФТ. Почти — бывают исключения (например, ФТ «отправлять письмо не более 3 раз» — это бизнес-правило, а не НФТ).
Метод 4: Таблица-детектор «ошибочных» формулировок
Студенты часто путают Usability с функциональностью. Вот таблица-помощник:
| Неверная формулировка (смешивает ФТ и НФТ) | Правильная декомпозиция |
|---|---|
| ❌ «Система должна быть удобной и быстрой» | ФТ: отдельные функции (создать заказ, оплатить) |
| НФТ: время отклика < 500 мс | |
| ❌ «Система должна генерировать понятные отчёты» | ФТ: генерация отчёта (Excel, PDF) с фиксированными полями |
| НФТ: отчёт должен содержать пояснения к каждой колонке (tooltip / подсказка) | |
| ❌ «Система должна быть безопасной» | ФТ: аутентификация, RBAC, шифрование паролей |
| НФТ: пароль должен содержать не менее 8 символов, включая цифры и заглавные буквы | |
| ❌ «Корзина должна работать без ошибок» | ФТ: добавление товара, удаление, пересчёт суммы |
| НФТ: 99.9% успешных операций с корзиной | |
| ❌ «Система должна выдерживать много пользователей» | НФТ: 10 000 concurrent users с временем отклика не более 1 с |
Чек-лист для самопроверки (наклейте на монитор)
Проходя каждое требование, задайте 3 вопроса:
- Есть ли в требовании глагол действия? (создать, отправить, рассчитать, показать, сохранить) → возможно, это ФТ
- Есть ли числовая метрика? (секунды, проценты, количество пользователей, размер файла) → возможно, это НФТ
- Если убрать это требование — функция исчезнет или станет хуже? Исчезнет → ФТ. Станет хуже → НФТ.
4. Глубинная ошибка: почему ФТ и НФТ путают чаще всего?
Корень путаницы — формулировка на естественном языке. В быту мы говорим «Система должна работать быстро» — и это звучит как функция. Но «быстро» — это атрибут качества, а не функция.
| В быту говорят | Аналитик должен разделить |
|---|---|
| «Система должна отправлять уведомления» | ФТ: Отправка email/SMS/push |
| НФТ: Время доставки, формат, частота | |
| «Система должна искать товары» | ФТ: Функция поиска по названию / артикулу |
| НФТ: Скорость поиска, точность результатов | |
| «Система должна сохранять данные» | ФТ: Функция сохранения формы / заказа |
| НФТ: Частота автоматического сохранения (каждые 30 сек), хранение 5 лет |
Золотое правило аналитика: Если вы написали одно требование, в котором есть и действие, и ограничение — разбейте на два: отдельно ФТ, отдельно НФТ.
5. Полный пример: декомпозиция требования «Авторизация»
Покажем, как одно бизнес-требование распадается на полный набор ФТ и НФТ:
| Уровень | Формулировка |
|---|---|
| Бизнес-требование | «Обеспечить безопасный доступ к системе для сотрудников компании» |
| Пользовательское требование | «Как сотрудник, я хочу входить в систему по корпоративному email и паролю» |
| ФТ-001 | Система должна предоставлять форму ввода email и пароля |
| ФТ-002 | Система должна проверять, что email существует в БД |
| ФТ-003 | Система должна хешировать пароль (bcrypt) и сравнивать с сохранённым хешем |
| ФТ-004 | При успешной аутентификации система должна выдавать JWT-токен со сроком действия 24 часа |
| ФТ-005 | При неверном пароле система должна возвращать ошибку 401 и логировать попытку |
| ФТ-006 | Администратор должен иметь возможность заблокировать учётную запись (ФТ) |
| НФТ-001 (Usability) | Пользователь должен иметь возможность восстановить пароль: ссылка «Забыли пароль?» на форме входа |
| НФТ-002 (Reliability) | Система должна блокировать учётную запись на 15 минут после 5 неверных попыток входа |
| НФТ-003 (Security, FURPS+) | Пароль должен содержать не менее 8 символов, минимум одну заглавную букву и одну цифру |
| НФТ-004 (Performance) | Время аутентификации — не более 2 секунд (время от нажатия кнопки «Войти» до получения токена) |
| НФТ-005 (Supportability) | Все попытки входа (успешные и неуспешные) должны логироваться в централизованную систему аудита |
6. Распространённые ошибки классификации (с примерами)
Ошибка 1: НФТ выдают за ФТ (и наоборот)
❌ «Система должна иметь красивый интерфейс» — Это не требование, это субъективная оценка. Нужно переформулировать в измеримое НФТ: ✅ «Интерфейс должен соответствовать предоставленным макетам Figma» (Design Constraint) или «Удовлетворённость пользователей по опросу SUS — не менее 80 баллов» (Usability).
Ошибка 2: Смешивают бизнес-правило и функциональное требование
❌ «Скидка на товар — 10% при заказе от 5000 руб.» — Это бизнес-правило (Business Rule). ФТ будет звучать как: ✅ «Система должна рассчитывать сумму заказа с учётом скидки: при сумме >= 5000 руб. применять скидку 10% ко всем позициям корзины».
Ошибка 3: НФТ формулируют нечисленно (непроверяемо)
❌ «Система должна быть быстрой» — Как проверить? 100 мс — быстро? 1 сек — быстро? Для кого? ✅ «95-й перцентиль времени загрузки страницы каталога не превышает 2 секунд при скорости интернета 10 Мбит»
Ошибка 4: Путают ФТ с User Story
User Story — это приём, а не тип требования. User Story может содержать и ФТ, и НФТ.
«Как пользователь, я хочу быстро найти товар по названию»
- ФТ: поиск по названию с автокомплитом
- НФТ: время выполнения поиска < 1 сек
7. Примеры для закрепления: что это за требование?
| Требование | ФТ / НФТ / Иное | Категория FURPS+ |
|---|---|---|
| «Система должна отправлять SMS при смене статуса заказа» | ФТ | Functionality |
| «SMS должно доставляться в течение 60 секунд» | НФТ | Reliability |
| «Кнопка «Оплатить» должна быть контрастного зелёного цвета» | НФТ | Usability |
| «При нажатии «Оплатить» система должна вызвать API платёжного шлюза с параметрами заказа» | ФТ | Functionality |
| «Платежи должны обрабатываться с точностью до копейки» | НФТ | Functionality (Accuracy) |
| «Серверы должны размещаться в РФ (152-ФЗ)» | НФТ | + (Legal) |
| «Система должна быть написана на Java 17» | НФТ | + (Implementation) |
| «Пароль должен содержать минимум 8 символов и одну цифру» | НФТ | + (Security) |
| «Администратор должен иметь дашборд с графиком загрузки сервера» | ФТ | Functionality |
Вопросы для самопроверки
- Назовите все категории FURPS+. Приведите свой пример (не из урока) для каждой категории.
- В чём разница между функциональным требованием и нефункциональным? Приведите 3 пары (ФТ + относящееся к нему НФТ).
- Используя тест «удаление» определите тип: «Система должна отправлять push-уведомление на телефон пользователя». Если убрать — что сломается?
- Почему требование «Система должна быть надёжной» — плохое требование? Как его исправить?
- К какой категории FURPS+ отнести: «Система должна хранить историю заказов 5 лет, после — анонимизировать данные»?
- Придумайте 3 нефункциональных требования для мобильного приложения банка.
Практическое задание
Возьмите любой онлайн-сервис (например, «Яндекс Go», Ozon, Telegram).
Часть 1. Выпишите:
- 3 бизнес-требования
- 5 функциональных требований
- 5 нефункциональных требований (укажите категорию FURPS+)
Часть 2. Возьмите одно функциональное требование и «оберните» его в 2 НФТ (Usability + Performance).
Часть 3. Переформулируйте 3 «плохих» требования (непроверяемых) в хорошие, измеримые:
❌ «Система должна быть удобной» ✅ ...
❌ «Система должна работать быстро» ✅ ...
❌ «Система должна быть безопасной» ✅ ...
Формат: любой (md / doc / таблица). Критерий — требования проверяемы и однозначны.
Дополнительные материалы
- Стандарт: ISO/IEC 25010:2011 — Quality model for software product (развитие FURPS)
- Статья: Karl Wiegers — «When Telepathy Fails: Writing Good Requirements» (о том, как формулировать требования правильно)
- Книга: «Software Requirements» — Karl Wiegers, Joy Beatty (глава 3, 4 — классификация требований)
- Книга: «FURPS+ в реальных проектах» — Robert Grady (оригинальная публикация HP)
- Памятка: FURPS+ cheat sheet — есть в открытом доступе (одностраничный PDF)
- Шаблон: SRS template с секциями FURPS+ (IEEE 830 + расширение)