Давайте продолжим разговор про классификацию требований, начало можно посмотреть здесь.

Что же такое бизнес требования?

По моему мнению, к бизнес требованиям (БТр) необходимо относить артефакты требований, отвечающие на вопрос – зачем? Таким образом, к БТр я бы отнес следующее:

• Бизнес-процессы

С т.з. системного анализа БП необходимы для того, чтобы понять аналитику и команде эти самые процессы и договориться с бизнесом о том, что они у них есть и именно такие, чтобы в итоге на этой основе потом строить ИС и минимизировать оптимизацию БП во время автоматизации.
Описание БП НЕ всегда является обязательным при формировании требований к ИС, тут больше нужно ориентироваться на сложность БП и их понимание аналитиком и командой. Нотацию или текстовое описание выбирать тоже вам, исходя из опыта и потребностей.
БП принадлежат однозначно к типу функциональных требований.

• Заинтересованные лица (ЗЛ) и их потребностей

Вот список ЗЛ и хотя бы краткое описание их потребностей – это как раз обязательные артефакт БТр.
Список ЗЛ и их потребностей может плавно перетекать из описания БП выше, но должен быть дополнен сервисными ЗЛ, н-р, админами или службой эксплуатации Заказчика. Также данный список можно составить на основе интервью Заказчика.
Описание ЗЛ происходит на уровне ролей, которые тем или иным образом могут повлиять на разработку (работу) Системы или будут затронуты разработкой (работой) Системы. Это описание необходимо для того, чтобы никого не забыть на этапе сборе требований и учесть (или осознанно отбросить) все интересы ЗЛ.
Сам список ЗЛ можно отнести к НФТ, а вот их потребности – ФТ.

• Проблемы, которые будет решать Система

Тут нужно сказать, что необходимо выявить корневые проблемы (а не симптомы), которые будут решены, когда Система будет работать.
Шаблон для описания проблем можно использовать следующий:
o Проблема: Описание проблемы
o Затрагивает: ЗЛ, которых затрагивает проблема
o Влияет на: На что влияет (что затрагивает выше) эта проблема
o Решение позволит: Ключевые преимущества, которые получат ЗЛ при решении этой проблемы
Проблемы я бы отнес к ФТ.

• Цели создания Системы

Это наверное главное, что должно быть в БТр – цель, т.е. зачем или для чего мы создаем\внедряем\модифицируем нашу Систему. Почему цели так важны? Как минимум:
o Договориться с заказчиком – куда бежим и что ключевое решаем, это очень поможет на этапе разработки. Заказчик зачастую сам до конца не знает – зачем мы разрабатываем Систему, а после открытия глаз, может скорректировать движение или даже отказаться от проекта.
o При поступлении заявок на доработки понять – в рамках проекта эта заявка (соответствует цели) или нет.
Нужно стараться, чтобы цель была описана по SMART критерию. Много про цели писал Сергей Нужненко.
Как и проблемы, Цели я бы отнес к ФТ.

• Основные функции Системы (фичи)

Ну а как же не обозначить основные функции предлагаемого решения?! Описание 10-15 таких основных функций (или задач, которые решает Система) должны быть определены в БТр.
Естественно Основные функции Системы относятся к типу ФТ.

• Бизнес ограничения

Безусловно Заказчик должен высказать основные бизнес ограничения, которые должны быть зафиксированы в БТр.
Как, пример, можно привести следующие бизнес ограничения:
o Соблюдение требований ФЗ-152 о персональных данных
o Система должна быть сделана на платформе 1С (если это важно для бизнеса)
o Обмен данными с другими Системами должен соответствовать стандарту EDI.
o И т.д.
Бизнес ограничения относятся к типу НФТ.

• Диаграммы

Конечно модель требований к Системе бедует неполной без диаграмм. По моему мнению, важны следующие диаграммы на уровне БТр:
o Диаграммы бизнес-процессов
o Контекстная диаграмма
o Диаграмма бизнес сущностей

Артефакты, описанные выше, как раз и составляют основу документа «Концепция», который формируется на первоначальном этапе работы над требованиями к Системе.

Вроде бы ничего я не забыл, постарался подробно рассказать про БТр, до встречи в следующих частях.