MisterMOZG
Я говорю не о бизнес-целях проекта. Их мало и с ними нет проблем
Я говорю о профилях стэйкхолдеров и о потребностях этих стэйкхолдеров.

Насколько я понимаю методику, то vision должен описывать потребности этих стэйкхолдеров в контексте задачи (т.н user needs) и предлагать решение - набор высокоуровневых features, которые удовлетворяют эти потребности.
...
Моя проблема в том что у меня этих UserNeeds получилось слишком много.
Я единственный кто с этим столкнулся?


Возможно тут вопрос насколько высокоуровневы эти самы needs, которые вы сформулировали. И не являются ли они по сути юзкейсами. Одно дело, когда главный энергетик говорит, что его потребоность это контроль состояния каких-нит энергоустовновок, чтобы оперативно устранить сбои, напрмер. Другое дело, когда он говорит что ему нужен индикатор показывающий величину <чего-нибудь>. Needs -- эт опроблема, причем КОРНЕВАЯ проблема, но если идти по пути сбора и формулировки needs, то чаще всего вы услышите от стейкхолдеров не столько needs, сколько уже решения. Наличие индикатора <чего-нибудь> -- это решение, чтобы хорошо сформулировать need нужно задать вопрос, а зачем этот индикатор вобще нужен, какую проблему он решит? ... в этом случае вы скорее всего более рационально сможете сформулировать needs.
Features -- вещь вообще интересная :-). Хотя бы потому, что они могут обладать разным уровнем абстракции, например фича системы -- расчет заработной платы и отправка уведомления о начислении по e-mail. Это фичи, только разного порядка.

MisterMOZGТ.е общаюсь со стэйкходерами и всё что слышу раскладываю на три кучи:

1) юз-кейсы
2) бизнес-правила
3) реальные высокоуровневые user need'ы

Потом кучу 1) и кучу 2) переосмысливаю и придумываю достаточно высокоуровневые userneed'ы и featur'и для документа Vision, чтобы обосновать эти use case'ы.
Что-то в таком духе?


Можно не придумывать, а просто проанализировав задачи которые решают различные заинтересованные лица, просто спросить ПОЧЕМУ они это делают. Есть шанс -- докопаться до корневой причины, как правило они ее вам сами озвучат :-) -- это и будет хороший need. Need -- это проблемный домен, а feature -- это уже решение этой проблемы в виде возможности ПО.


MisterMOZG
А куда записывать "сырые" данные полученные от стэйкхолдера?
Просто использовать документы типа "Протокол обсуждения проекта ГГГ от 11.11.11"?

Посмотрите артефакт RUP Stakeholder Requests, возможно он вам окажется полезен.

MisterMOZG
Один из стэйкхолдеров - Расчётчик
Он:
а) Ответственен за определение количества товара, которое подлежит перемещению на СОХ
б) Ответственен за документальное оформление перемещений на СОХ.

Я написал ему такие UserNeed'ы
1) Процедура расчёта поставки на СОХ не должна быть трудоёмкой
2) Расчёт выполняется за разумное время (30 минут)
3) Документирование перемещения товара на СОХ не должно быть трудоёмким.

Чуствую, что 2) это было лишнее...

Вопрос по поводу 3) -
Стоит ли считать юзер-нидом каждую цель пользователя ?

Например, в моём случае "создание накладной на перемещение".
Расчётчик обязан её делать хочет он этого или не хочет и трудоёмкость этой операции, на самом деле, его не слишком волнует. Я написал юзер-нид про трудоёмкость, чтобы хоть как-то упомянуть про необходимость создания накладной на перемещение.


Нет, не стоит ... цели пользователей по отношениею к системе это юзкейсы. Кроме этого, как можно оценить в вашем случае трудоемка процедура или нет?
А требование "размного времени расчета" -- это вообще атрибут качества, а не need. Задайте вопрос Расчётчику, какие у него сейчас основные проблеимы? Навернякак окажется, что если он работает на бумаге, то скорее всего проблема в том, что много чего приходится переписывать, бумаги теряются и т.д. ... сформулируйте это в виде потребности -- это и будет ЕГО needs. Снижение трудоемкости или сокращение времени которое затрачивает клерк -- это интерес в первую очередь менеджмента, ибо время-деньги, и это будут в большей степени его потребности, чем клерка.

MisterMOZG
Возможно нужно было сформулировать юзер-нид как "Должна быть возможность документировать перемещение товара"?
Или может вообще не надо было про это упоминать в user need'ах? Но тогда фича "Накладные на перемещение" вылезает из воздуха - что есть плохо.
Как вы поступаете в таких ситуациях?

Документирование перемещение товара вытекает из бизнес-процесса ... не нужно забывать, что вы автоматизируете некую область где есть бизнес-процессы (хоть и "ручные").

P.S. Needs -- вообще вещь такая, несколько скользкая :-). Думаю что в своем тренинге по управлению требованиями я включу несколько дополнительных слайдов на эту тему. Видимо придется еще и пример разработать :-). Все-таки у многих аналитиков некий mix в голове из RUP, ГОСТ и Вигерса, приводящий иногда к "аналитическому параличу". Второй момент -- не нужно усердно добиваться "методологической чистоты подхода" в реальных проектах.