Коллеги, посоветуйте, сталкивался ли кто-либо со стандартным шаблоном описания бизнес-требований?
В каком виде вы описываете бизнес-требования?
У Вигерса есть некое описание шаблона бизнес-требований. Но очень мне не нравится в подходе Вигерса описание бизнес-требований как бизнес-целей системы, что, на мой взгляд, не одно и тоже.  Как мне кажется, бизнес-требования нужно отличать от целей, и в бизнес-требованиях должно быть сформулировано то, что должно быть сделано системой, но не как.
Возможно, в бизнес-требованиях нужно формулировать также бизнес ВИ.
Коллеги, поделитесь опытом.

Я включаю в БТ:

1. Контекст и ЗЛ
2. Цели создания системы и критерии достижения
3. Ключевые требования к решению и их приоритеты
4. Ограничения на решение

Приложения:
А. Описание бизнес-процессов
Б. Бизнес-правила
В. Концептуальная модель предметной области

Цели, сформулированные в виде результатов — это, в каком-то смысле и есть «что должно быть сделано системой», если под системой понимать ИС, включающую людей

«Бизнес ВИ» — это разновидность формата описания бизнес-процессов на уровне бизнес-фунций и операций.

Нужно ли фиксировать в БТ описание бизнес-функций и операций — зависит от сложившейся практики и процессного охвата системы.

Спасибо за развернутый ответ.
Не очень понятно, что включает в себя п. 1 Контекст и ЗЛ
Бизнес-процессы вы описываете в общем виде или на данном этапе также прорабатываете отдельные действия пользователей в системе? т.е. есть ли необходимость на данном этапе сбора требований отдельные сценарии бизнес ВИ прорабатывать?
и какие еще диаграммы вы включаете в раздел Концептуальная модель предметной области?

Не очень понятно, что включает в себя п. 1 Контекст и ЗЛ

Контекст — это что стало причиной создания системы, какая ситуация была в компании, какая проблема и как пришли к тому, что систему надо делать. ЗЛ — заинтересованные лица.

Бизнес-процессы вы описываете в общем виде или на данном этапе также прорабатываете отдельные действия пользователей в системе?

В общем виде почти всегда. Если системы ещё нет, то конечно не описываем отдельные действия, т.к. это уже проектирование.

т.е. есть ли необходимость на данном этапе сбора требований отдельные сценарии бизнес ВИ прорабатывать?

Зависит от проекта. В общем случае это делать полезно.

и какие еще диаграммы вы включаете в раздел Концептуальная модель предметной области?

Понятия и связи, Состояния.

Кстати, структура документа требований заинтересованных лиц по
ISO/IEC/IEEE 29148:2011 Системная и программная инженерия. Процессы жизненного цикла. Разработка требований

1. Introduction
1.1 Business purpose
1.2 Business scope
1.3 Business overview
1.4 Definitions
1.5 Stakeholders

2. References

3. Business management requirements
3.1 Business environment
3.2 Goal and objective
3.3 Business model
3.4 Information environment

4. Business operational requirements
4.1 Business processes
4.2 Business operational policies and rules
4.3 Business operational constraints
4.4 Business operational modes
4.5 Business operational quality
4.6 Business structure

5. User requirements

6. Concept of proposed system
6.1 Operational concept
6.2 Operational scenario

7 Project Constraints

8. Appendix
8.1 Acronyms and abbreviations

А вот что я думаю по этому поводу:
http://blogs.uml2.ru/node/284

Вот мой подстрочный перевод описания структуры документа Stakeholder Requirements из ISO 29148.

Я пробовал описывать в виде инструментов Голдратта: деревьев текущей и будущей реальности. Получается красиво, но к сожалению при создании очень "мозги едут". Подробную инструкцию можно найти в книге Детмера "Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию". Более простую инструкцию можно найти на сайте flyinglogic.com. Если нужна просто примеры - смотрите книгу "Управленческие дилеммы" Шрагенхайма.

Еще писал концепции с ограничением Тойоты "Если концепция на проект в миллиард долларов не умещается на лист формата А3, то документ идет в мусорное ведро." По составу мне нравится формат описанный Денисом в блоге.

Матрицу "заинтересованные лица и их интересы" считаю обязательной к написанию.