Эдуард, а можно пример-другой из числа частых разногласий?

Ну, сложно это сделать. Но попробую.

вот есть такое определение
Информирование читателей о наличии изданий
Полезно, чтобы при выборе издания для включения в заказ, читатель получал информацию о наличии доступного экземпляра этого издания.

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

Ясно ли где тут что?

Информирование читателей о наличии изданий

Функция системы. Вполне достойна выноса в перечень фич.

Полезно, чтобы при выборе издания для включения в заказ, читатель получал информацию о наличии доступного экземпляра этого издания.

Кому полезно? Ребус. Кроссворд. Если читателю - то наверное не просто полезно, а необходимо. Чтобы в пункте выдачи поменьше удивляться. Но это-то авторы постановки наверняка понимают. Значит, имеется ввиду какое-то другое заинтересованное лицо.

Я бы рассматривал так:
а) Если это фраза из ТЗ, то это необязательное пожелание, исполнение которого оставляется на усмотрение разработчика. Опасное дополнение.
б) Если это фраза из руководства пользователя (или его аналогов) - то просто рекомендация по наиболее эффективному применению системы.

Информирование о новых изданиях

Тоже функция системы. И тоже сойдет для фичлиста.

Читателям библиотеки предоставляется возможность получать информацию о новых изданиях, появившихся в библиотеке. Читатели уведомляются об этом посредством электронной почты, причем только в том случае, если они согласились на рассылку таких уведомлений при регистрации. Уведомления приходят на электронный адрес, который читатель указал при регистрации.

Избыточно лирическое человеко-ориентированное (в отличии от "системо-ориентированного") описание функции системы. Вполне достойно для включения в руководство или детализированное описание фичлиста. Для фичи слишком многословно.

(В качестве не менее лирического отступления.
Постановка с точки зрения удобства функции - жуть. Что значит "только если согласился при регистрации"? Потом - никак? Программисты ведь так и накодят.
И эта... Или библиотека очень маленькая, или недалеких соглашенцев завалит спамом обо всех поступлениях в книжный фонд, включая периодику, обновления редакций имеющихся книг и просто замены износившегося фонда).

Ясно ли где тут что?

Вполне, за исключением невнятного "полезно". Вот его бы и стоило переформулировать. Остальное пригодно для применения в документах различного характера.

Формулировки потребностей и возможностей (need и feature) довольно близки. При изучении этой темы (на практике), часто возникают разногласия . Хотя и поясняется, что потребность - это пожелание, которое может остаться мечтанием или превратится в требование, фича - уже требование, то чему должна соответствовать система (иметь свойства). Возможно я дую на воду, но предполагал, что есть какие-то маркеры позволяющие
а/ различать потребности и фичи
б/ корректно их формулировать чтобы не путать в последствие, ну хотя бы в рамках одной группы

Для того чтобы ощутить различия я обычно рассматриваю следующие свойства NEED и FEATURE:
- Удовлетворение NEED способствует решению проблемы (PROBLEM) или реализации возможности (OPPORTUNITY) при помощи набора FEATURE и прочих решений (вне АС).
- FEATURE обязана быть направлена на решение проблемы (PROBLEM) или реализацию возможности (OPPORTUNITY).
- Одна NEED может быть удовлетворена за счёт одной или нескольких FEATURE.
- Одна FEATURE может удовлетворять несколько NEED.
- Иногда NEED может быть удовлетворена без автоматизации и для неё не будет существовать ни одной FEATURE.
- Иногда NEED может быть вообще проигнорирована, если её удовлетворение не критично. Тогда соответствующая ей FEATURE будет иметь низкий приоритет, может быть исключена из текущего скоупа, оставлена с пометкой COULD (MoSCoW) или запланирована на будущие релизы.
- Иногда NEED не может быть удовлетворена за счёт автоматизации (или это дорого) и требуются другие решения (вне АС).

Коллеги, прошу дополнить/поправить если вы считаете что упущено что-то важное или что-то категорически не соответствует вашим представлениям.

Леонид, спасибо за анализ. Твердая 5-ка.

Однако авторы формулировок считали, что первая формулировка это потребность  (need) - у нее есть конечно заинтересованное лицо: работник абонемента и работник книжного фонда ( через проблему Отсутствие оперативного обновления информации о наличии)

Вторая формулировка - это требование возможности (feature)

Есть краткое наименование элемента и его развернутое описание. По мне так отличить эти элементы сложно, потому полагал, может помимо указания типа элемента стоит подумать над формулировкой?

Для того чтобы ощутить различия я обычно рассматриваю следующие свойства NEED и FEATURE:

- Иногда NEED не может быть удовлетворена за счёт автоматизации (или это дорого) и требуются другие решения (вне АС).

Да потребность - это не требование к системе, она может и не найти решения в системе

Однако авторы формулировок считали, что первая формулировка это потребность  (need) - у нее есть конечно заинтересованное лицо: работник абонемента и работник книжного фонда ( через проблему Отсутствие оперативного обновления информации о наличии)

Тогда, полагаю, там либо до процитированного момента было написано что-то поясняющее, либо после. Поскольку в таком виде - нечто невнятное.

Нет у работника абонемента потребности в том, чтобы читатель информировался о чем-либо. Это происходит далеко за пределами его полномочий. У него есть потребность, чтобы читатель не устраивал ему скандалы (в т.ч., по поводу отсутствия заказанного). Это совсем другая потребность и решаться она может массой методов (большинство из которых - за пределами АИС).

А работнику книжного фонда вообще без разницы, что там заказал, знает или не знает читатель. Он читателя никогда в глаза не видел и не увидит.

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

Не очень удачный подход.

Есть краткое наименование элемента и его развернутое описание. По мне так отличить эти элементы сложно, потому полагал, может помимо указания типа элемента стоит подумать над формулировкой?

Отличить эти элементы достаточно просто, когда тот, кто их описывает, делает это внятно и последовательно. Не всегда в непонимании виноват тот, кто читает.
Сомневаюсь, что стоит как-то формализовать подобные описания. Они "про людей" или "для людей" и описываться должны естественным языком.