Между ними - пользовательские требования, User Requirements

а способы решения - это уже ближе не к требованиям, а к анализу/проектированию (хотя решения могут быть оформлены как требования-ограничения)

Бизнес-процессы - это самое начало работы.
Например, можно рассмотреть процессы RUP/MSF (упрощенная последовательность):
1. "Бизнес-моделирование"
2. "Выявление требований"
3. RUP: "Анализ и проектирование", MSF: "концептуальный, логический и физический дизайн"
4. "Реализация"
5. ...


Совсем упрощенно:
1. От заказчика поступает начальная концепция системы (в нескольких предложениях что они хотят, что это позволит достигнуть и т.д.) - по сути это и есть бизнес-требования.
2. Приступаем к моделированию бизнес-процессов, которые хотим автоматизировать (тут в помощь нам ARIS, IDEF0/IDEF3, UML), возможно, строим дополнительную модель (оптимизированную), в которой будут прописаны бизнес-процессы после автоматизации.
3. Вытрясаем из заказчика требования к разрабатываемой системе (это будут пользовательские требования).
4. На основе пользовательских требований формулируем функциональные требования к системе (пользовательские требования - не единственный источник функциональных требований).

Пример различий между пользовательскими и функциональными требованиями:
Пользовательское: "Система должна выводить отчеты на печать"
Функциональное: "Система должна обеспечивать вывод отчетов на печать, обеспечивать возможность выбора и настройки локального или сетевого принтера, выбора ориентации бумаги".

Пользовательские и функциональные требования как правило связаны между собой. Это необходимо для отслеживания зависимостей требований друг от друга. В системах управления требованиями (например, Borland CaliberRM. TelelogicDoors, Rational RequisitePro) для этого есть так называемые "матрицы трассировки", на которых графически стрелками показываются зависимости между требованиями.

И еще момент: важно сохранять пользовательские требования для хранения их в первоначальном виде, отслеживания источника их возникновения (вплоть до конкретного лица), расстановки их приоритетов (с точки зрения пользователя) и т.д.
Можно сказать, что пользовательские требования формулируются в требованиях предметной области, и функциональные требования - в терминах системы.

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