Сергей, пока студенты собираются с мыслями, попробуем обсудить формулировки:
проблем (issue) - потребностей (need) - возможноcтей (feature)
Во вложении выгрузка из модели, если у вас есть ЕА, я предоставлю и сам проект.
Проект касается некой сети библиотек. Поскольку это образец, то он не полон и в нем к сожалению вполне возможны логические ошибки.
Попробуем разобрать какие? Не все, а на примере какой-то определенной части?
Я в этом документе вижу смешение уровней бизнес-требований и требований к реализации. ("Вход в систему" - вообще мой любимый пример. Его обязательно включают во все ДВИ любого уровня, ещё обычно и инклудами обвешивают, потому что как же можно что-то сделать в системе, не войдя в неё.)
Если говорить о потребностях и возможностях при разработке документа уровня Vision (то есть бизнес-требований), то я склонен считать, что Цели / Проблемы / Возможности / Потребности предоставляют собой четыре разных точки зрения на систему и представляют собой разные источники для выявления бизнес-требований. На этом этапе их скорее вредно трассировать друг на друга.
Цели и проблемы существуют у организации-заказчика (или Пользователя в том смысле, который вкладывает в этот термин ГОСТ).
Потребности существуют у пользователей системы, которые будут с ней работать.
Возможности система предоставит пользователям после того, как она будет внедрена или приобретена. Это такой взгляд в будущее: давайте представим, что система у нас уже работает, и посмотрим, какие возможности она нам даёт.
Проанализировав эти источники, можно получить перечень функций (и нефункциональных требований), и их уже трассировать на источники.
Когда я смотрю на матрицу в исходном посте, я вижу и в строках, и в столбцах не возможности и потребности, а разноуровневые функции, которые трассируются друг на друга.
Чем "ведение БД о служащих" отличается от "Администрирования данных о служащих"? И что это за потребность такая - ведение БД?