Требование — задокументированное условие или возможность, которой должно соответствовать решение. В разговорной речи аналитики часто сводят классификацию к трём «корзинам» — бизнес-, функциональным и нефункциональным требованиям (БТ, ФТ, НФТ), но на практике этого мало. Рабочая схема шире: БТ → SR → ФТ/НФТ → TR (бизнес-требования, требования заинтересованных сторон, требования к решению, требования перехода) плюс смежные сущности — правила, ограничения, допущения. Без этих уровней легко перемешать стратегию с дизайном кнопок и пропустить критичные свойства системы. Статья задаёт единую схему по BABOK v3 и показывает, куда относить типичные формулировки на проекте.

1. Суть темы

Классификация — не бюрократия, а рабочий инструмент:

Оговорка про «БТ» в заголовке. В BABOK business requirements — стратегический уровень «зачем проект». В быту «бизнес-требование» иногда называют любое пожелание заказчика. В спецификации фиксируйте тип по схеме ниже, а не по должности автора формулировки. Сокращение «БТ, ФТ, НФТ» в названии файла — привычная тройка; полная рабочая модель включает SR и TR.

Граница роли: классификация на уровне solution requirements описывает что должна обеспечить система, но не заменяет архитектурное проектирование — выбор протокола, топологии, паттернов интеграции остаётся за SA и архитектором — 00.02 Бизнес-анализ vs Системный анализ vs Требования, 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая).

2. Ключевые понятия

Иерархия BABOK v3

Опорная модель — Requirements Classification Schema в 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148) (BABOK v3, Chapter 2). ISO/IEC/IEEE 29148 использует близкую терминологию; детали стандарта не дублируем здесь, но для SRS по 29148 удобен мост к BABOK:

Уровень BABOKТипичное место в документе по ISO 29148Примечание
Business RequirementsВведение, business context, цели инициативы (часто вне SRS)Связь с Business or Mission Analysis по ISO 15288
Stakeholder RequirementsРаздел stakeholder requirementsПотребности ролей до детализации системы
Solution: FR + NFR + constraintsРаздел system requirements (функциональные, качественные, ограничения)Основное тело SRS/FRD
Transition RequirementsОперационные/переходные требования, план внедренияЧасто отдельный раздел или приложение

Если контракт ссылается на 29148, проверяйте, что каждый уровень BABOK попал в нужный раздел спецификации, а не «растворился» в User Stories.

flowchart TD
    subgraph L1["Уровень 1: стратегический"]
        BR[Бизнес-требования<br/>Business Requirements]
    end

    subgraph L2["Уровень 2: потребности ролей"]
        SR[Требования заинтересованных сторон<br/>Stakeholder Requirements]
    end

    subgraph L3["Уровень 3: система"]
        FR[Функциональные требования<br/>Functional Requirements]
        NFR[Нефункциональные требования<br/>Non-Functional Requirements]
    end

    subgraph L4["Уровень 4: внедрение"]
        TR[Требования перехода<br/>Transition Requirements]
    end

    BR --> SR
    SR --> FR
    SR --> NFR
    BR --> TR
    SR --> TR

Связи на диаграмме — логическая трассировка «сверху вниз», а не автоматическая генерация текста. Требования перехода (миграция, обучение, параллельный запуск) чаще вытекают из бизнес-изменения и плана внедрения, а не из каждого отдельного ФТ. Стратегический уровень BR пересекается с мотивационным слоем ArchiMate — 06.03.01 Мотивационный слой.

Бизнес-требования (Business Requirements)

Суть: зачем организация инициирует изменение и какую ценность ожидает — без описания системы.

  • Источник: стратегия, спонсор, владелец продукта.
  • Форма: цели, KPI, бизнес-кейс, Vision & Scope — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).
  • Примеры:
    • «Сократить операционные затраты на обработку заказов на 30 % в первый год за счёт автоматизации маршрутизации».
    • «Снизить долю брошенных корзин с 65 % до 45 %».

Не бизнес-требование: любое упоминание экрана, API, технологии или конкретного решения («внедрить чат-бот»). Цели и KPI — 02.01.02 Цели, KPI и критерии успеха (SMART, GQM).

Требования заинтересованных сторон (Stakeholder Requirements)

Суть: потребности конкретных ролей и групп — что им нужно от решения, ещё без технической реализации.

Критерий уровня: формулировка описывает потребность роли, а не поведение системы. Как только появляются «система должна», конкретные поля, протоколы или алгоритм — это уже функциональное или нефункциональное требование к решению. User Story в бэклоге часто смешивает уровни: отделяйте intent стейкхолдера от AC и системной детализации — 04.02 Пользовательские истории (User Stories) и Job Stories.

Требования к решению (Solution Requirements)

Solution Requirements в BABOK делятся на функциональные и нефункциональные. Сюда же относят ограничения (constraints) — жёсткие рамки реализации (регуляторика, стек, сроки), которые не описывают действие системы, но обязательны к соблюдению.

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

Суть: что система делает — действия, вычисления, обработка данных.

  • Признак: формулируется глаголом: «рассчитать», «отобразить», «отправить», «проверить».
  • Формы: Use Case, User Story с AC, SRS/FRD — 02.03.03 Спецификация требований (SRS, Use Case, User Story).
  • Примеры (раздельно, одно действие — одно требование):
    • «Система рассчитывает стоимость доставки по весу, габаритам, индексу получателя и текущей загрузке курьерских служб».
    • «При оформлении заказа система проверяет наличие товара на складе и блокирует заказ при отсутствии позиции».
    • «Система передаёт сформированный счёт в учётную систему 1С».

Протокол (REST), механизм аутентификации (OAuth 2.0) и шифрование — отдельные требования: интеграция и безопасность чаще оформляются как НФТ или constraints, а не смешиваются с одной «функцией передачи счёта». Детали API — 03.05.01 Виды интеграции (точка-точка, ESB, API-led).

Нефункциональные требования (Non-Functional Requirements, НФТ)

Суть: свойства системы и качество выполнения функций — «как хорошо» и «при каких условиях», а не «что делает».

Краткие примеры:

  • Производительность: «95 % запросов к API каталога — не более 200 мс при 500 одновременных пользователях».
  • Доступность: «99,9 % uptime в рабочее время (08:00–22:00)».
  • Безопасность: «Персональные данные шифруются при передаче (TLS 1.3+) и хранении (AES-256)».
  • Поддерживаемость: «Развёртывание новой версии на production — не более 30 минут».

Полная таксономия качества, ISO/IEC 25010:2023, шаблоны формулировок — в 08.02 Нефункциональные требования (НФТ) — классификация и стандарты и 10.01.12 Шаблон нефункциональных требований (NFR). FURPS+ здесь — только справочник имён категорий, не отдельная модель проекта; для договорённостей в команде достаточно ISO 25010 или вашего корпоративного чек-листа.

Почему НФТ критичны: недооценка качественных свойств — частая причина провалов внедрения. Показательный кейс — запуск Healthcare.gov в 2013 году: CMS не спланировала достаточную ёмкость, систему тестировали на ~2 000 одновременных пользователей при фактическом трафике в миллионы визитов; GAO зафиксировала недостаточное capacity planning и запуск без подтверждения выполнения performance-требований (GAO-15-238, GAO-14-694). IIBA описывает типичную «миопию» по НФТ на реальных проектах. НФТ архитектурно значимы: их нельзя «добавить в конце».

Операционные и инженерные аспекты (CI/CD, observability, IaC) в классической схеме BABOK не выделяются отдельной категорией. На практике их оформляют как НФТ или constraints проекта; связь с DevOps-процессом — 07.06 CICD и конвейеры — влияние на требования.

Объяснимость (explainability) AI-компонентов — прозрачность решений для пользователя и аудита; чаще фиксируют как НФТ или constraint — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 11.01 Введение в искусственный интеллект и LLM.

Бизнес-правила, доменные правила и данные

Бизнес-правила (business rules) описывают политики организации: «скидка 10 % при сумме заказа от 10 000 ₽», «кредитный лимит не более 3× среднемесячного оборота». Это не функции системы, а условия, которым система должна соответствовать. В спецификации их выносят в отдельный реестр правил (раздел BRD или приложение к SRS) и связывают с ФТ, которые правила реализуют — структура документов: 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

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

Constraint или НФТ: как выбрать

Один и тот же норматив или технологический выбор команда может оформить по-разному. Практичное правило:

  • Constraint — рамка вне выбора команды: «только PostgreSQL», «срок запуска до 01.03», «обязательное соответствие PCI-DSS» как условие контракта. Не обсуждается на этапе проектирования; нарушение = невозможность поставки.
  • НФТ — измеримое качество реализации внутри выбранных рамок: «шифрование AES-256», «95-й перцентиль ответа ≤ 200 мс», «аудит всех операций с ПДн». Проверяется тестами и метриками.
  • Ссылка на закон отдельно от реализации: «152-ФЗ» — constraint или ссылка в реестре compliance; «логирование факта доступа к ПДн с retention 3 года» — НФТ Security. Дублировать одну мысль в обоих типах не нужно.

Отраслевой контекст и разбор регуляторики — 08.06 Юридические и регуляторные требования РФ (PCI-DSS), детальная таксономия Security/Safety — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.

Предположения, зависимости и вне скоупа

Требования перехода (Transition Requirements)

Суть: временные возможности для перехода от As-Is к To-Be — не постоянные функции продукта.

  • Миграция и конвертация данных.
  • Обучение пользователей.
  • Параллельная работа старой и новой системы.
  • План отката (rollback).

Пример: «Исторические заказы за 24 месяца переносятся в новую систему с сохранением связей заказ–клиент–товар».

После стабилизации внедрения актуальность таких требований снимается — 02.05.05 Жизненный цикл требования. Типичные ошибки при миграциях — 10.02 Разбор кейса "Миграция legacy-системы".

3. Как применяется в работе аналитика

  1. Сверху вниз: зафиксируйте бизнес-требования и контекст до детальных User Stories — 02.01.01 Определение бизнес-проблем и возможностей.
  2. Разделяйте документы по уровням: Vision/BRD — стратегия; бэклог — потребности ролей (SR); SRS/Use Cases — функции; отдельный раздел или артефакт — НФТ.
  3. НФТ параллельно с ФТ: на каждом интервью задавайте вопросы о нагрузке, безопасности, доступности, миграции.
  4. Тестируемость ≠ тип: измеримая формулировка нужна на всех уровнях; верификация и валидация — 02.04.01 Верификация и валидация (V&V), качество формулировок — 02.04.03 Управление качеством требований.
  5. Трассировка: матрица связывает цель → стейкхолдер → ФТ/НФТ → тест — 02.03.04 Трассировка требований (концепция), шаблон — 10.01.15 Шаблон матрицы трассировки.
  6. ИИ — вспомогательный инструмент на этапе черновика и поиска пробелов; финальную классификацию подтверждает аналитик — 11.07 Практические кейсы применения LLM в анализе.

4. Типовые ошибки и ограничения

ОшибкаКак распознатьЧто делать
Подмена БТ решением«Внедрить LLM-чат» вместо «сократить нагрузку на 1-ю линию на 40 %»Переформулировать на уровень ценности
Пропуск НФТВ спецификации только «что делает»Пройти чек-лист 08.02 Нефункциональные требования (НФТ) — классификация и стандарты
Размытые НФТ«Система должна быть быстрой/удобной»Задать метрику и условие измерения
Смешение ФТ и UI-дизайна«Зелёная кнопка подтверждения»Функция — «подтвердить заказ»; внешний вид — дизайн или НФТ Interaction Capability
Stakeholder = FR в одной строкеUser Story с протоколами и полями БДРазделить intent роли и solution requirements
Constraint vs NFR в одной строке«PCI-DSS + AES-256 + только Oracle»Закон/стек — constraint; метрики шифрования — НФТ
Дублирование таксономийОдно требование и как NFR, и как «engineering»Один тип + трассировка к процессу 07.06 CICD и конвейеры — влияние на требования
Игнор transitionНет плана миграции и обученияВыделить TR до старта разработки data-heavy систем
Правила внутри ФТПолитика скидок спрятана в сценарииВынести business rules, связать с ФТ

Граница статьи: здесь — каркас типов и уровней. Приоритизация, форматы SRS, глубокий разбор ISO 25010, DevOps и LLM-process — в соседних заметках по ссылкам выше. ML-классификация требований (см. источники) — экспериментальная помощь, не замена аналитику на проекте.

Связи с другими разделами базы

Раздел дополняет ссылки из текста тем, что не разобраны здесь подробно:

Источники и дополнительные материалы

Книги и стандарты

  • IIBA (2015). BABOK® Guide v3. Chapter 2 «Requirements Classification Schema»; Chapter 7 «Requirements Analysis and Design Definition». https://www.iiba.org/standards-and-resources/babok/
  • ISO/IEC 25010:2023. Systems and software engineering — SQuaRE — Product quality model. https://www.iso.org/standard/78176.html
  • ISO/IEC/IEEE 29148:2018. Systems and software engineering — Life cycle processes — Requirements engineering. https://www.iso.org/standard/45171.html
  • Wiegers, K.; Beatty, J. (2013). Software Requirements, 3rd ed. Microsoft Press. FR/NFR, business rules, constraints.
  • Robertson, J.; Robertson, S.; Reed, A. (2024). Mastering the Requirements Process, 4th ed. Addison-Wesley. Модель Volere и классификация требований.
  • Robertson, S.; Robertson, J. Volere Requirements Specification Template. https://volere.org/templates.htm

Статьи и онлайн-ресурсы

  • IIBA (2024). «Correcting Non-Functional Myopia in Business Analysis» — разбор недооценки НФТ; материалы на https://www.iiba.org/
  • U.S. GAO (2015). Healthcare.gov: CMS Has Taken Steps to Address Problems, but Needs to Further Implement Systems Development Best Practices (GAO-15-238) — inadequate capacity planning, слабое тестирование и oversight. https://www.gao.gov/products/gao-15-238
  • U.S. GAO (2014). Healthcare.gov: Ineffective Planning and Oversight Practices Underscore the Need for Improved Contract Management (GAO-14-694) — запуск без верификации performance requirements. https://www.gao.gov/products/gao-14-694
  • Modern Requirements. «How AI is Reshaping Requirements Engineering» — обзор LLM/NLP в RE (коммерческий вендор). https://www.modernrequirements.com/blog/

Дополнительно (исследования)

  • Á. García-Fariña et al. (2025). «Requirements Classification and Multi-Criteria Prioritization Using AI Techniques». Universidade da Coruña — ML-классификация FR/NFR.
  • M. R. Hasan et al. (2025). «Cross-Project Multiclass Classification of EARS-Based Functional Requirements…» — NLP/ML для классификации требований.