Собственно, вопрос такой: Стоит ли объединять функционал различных действий, которые кажутся едиными?
Если рассматривать систему управления контентом сайта (CMS), то там можно выделить следующие цели:

1.   Добавить рекламу; -
2.   Удалить рекламу; -

3.   Добавить новость; -
4.   Редактировать новость; -
5.   Удалить новость; -

6.   Добавить ссылку; -
7.   Редактировать ссылку; -
8.   Удалить ссылку; -

9.   Добавить опрос; -
10.   Остановить опрос; -

11.   Добавить раздел; -
12.   Удалить раздел; -
13.   Редактировать раздел; -


14.   Добавить страницу контента в раздел; -
15.   Редактировать страницу контента; -
16.   Удалить страницу контента из раздела; -
17.   Переместить страницу в другой раздел; -

18.   Зарегистрировать нового пользователя; !

19.   Просмотреть список пользователей;
20.   Просмотреть состояние счета пользователя;
21.   Просмотреть статистику пользователя;
22.   Просмотреть информацию о пользователе;
...

Стоит ли объединять пункты 1-17 в один ВИ "Работа с контентом"  или это слишком абстрактно? Или может, выделить в отдельные ВИ только пункты 1-2, 3-5, 6-8 и т.д.? Где действия происходят над одной сущностью.
Заранее спасибо

Такие UC обычно пакетируются в наборы «Управлять X» по классу объекта, смотрите книжку Use Case Patterns.

Но если у вас сценарии будут очень похожи, можно попробовать параметризовать пакет перечислением классов.

Я не утверждаю, что мой подход единственно верный, но я использую следующий критерий для определения кандидата на Use Case:
Есть новый функционал, который вам необходимо реализовать. В рамках данного функционала вами выделены (заявлены заказчиком) набор задач (целей) пользователя (User Goals), которые пользователь хочет решать (достигать) с помощью разрабатываемого приложения. Каждая такая цель пользователя является кандидатом на отдельный сценарий использования (вариант  использования).
С точки зрения "моего" (в кавычках потому, что - это не мое изобретение), каждая цель, перечисленная вами в списке является кандидатом на самостоятельный Use Case. Я бы не стал их объединять, поскольку они самостоятельны, и описывают конкретную, отдельную цель пользователя. Возможно, что один пункт будет описан с помощью несколькиз Use Cases, но это вам решать в зависимости от сложности сценария.   

уточню, под словом "объединять" я понимал объединение нескольких пунктов в один Use Case. Объединение в пакеты - очень правильное решение. Критерии объединения в пакет могут быть разными, я объединял в пакет Use Cases по отдельной, новой функциональности (новый модуль, например).

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

а что, если пункты 1-17 загнать в такие рамки? Это мой первый опыт описания функционала...

Вариант использования 1
Управлять контентом.

Основное действующее лицо: администратор.
Уровень: цель пользователя.
Участники и интересы: Администратор хочет изменить содержание сайта: добавить, удалить или изменить новость, статью, остановить опрос и проч.
Предусловия: пользователь вошел под правами администратора.
Минимальные гарантии: контент не изменится в случае неудачи.
Гарантия успеха: контент изменится.
Основной сценарий:
1.   Администратор определяет вид управляемого контента.
2.   Администратор выбирает тип действия и редактирует данный контент.
3.   Система заносит изменения в базу данных.

Возможно и так. Только вырождается до идеального способа применения:

• Система предлагает пользователю чё-то сделать.
• Система спрашивает "Чё те надо?".
• Пользователь сообщает, что ему надо.
• Система выполняет то, что надо пользователю.
• Система сообщает пользователю об успешном выполнении того, что он просил.

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

Как мне видится, в вашем случае нет никакой принципиальной разницы между тем, - писать один параметризированный UC, несколько укрупненных UC (пообъектно), или много небольших. Так как все они довольно простые и будут интуитивно понятны практически любому человеку.

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

- трудоемкость разработки UC.
Один большой параметризированный UC однозначно менее трудоемко разрабатывать и редактировать, чем кучу мелких однотипных UC.

- возможность отражать нюансы выполнения конкретого UC.
Понятно, что один большой параметризированный UC надо делать только если все охватываемые им UC имеют аналогичные последовательности действий. Иначе нюансы выполнения этих UC'ов не получится отразить.
Хотя возможен и тут вариант - если вы сделаете этот общий UC абстрактным и наследуете (Generalization) от него все остальные UC. А в них уже при необходимости опишите нюансы.

Добавить, удалить и редактировать по-моему мелковато для ВИ. Это функции.
Эти функции обычно имеют смысл в контексте каких-то ВИ, каких - это надо у вас спрашивать
Я поступаю так, как Денис предложил, в таких случаях - делаю ВИ "Управлять такой-то хренью".

Идея плодить кучу ВИ, различающихся только типом контента, мне тоже не кажется осмысленной - ваша мысль насчет объединения 1-17 была верной.

18 это однозначно качественный ВИ.

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

Хотя уверена, найдутся спецы, которые начнут рассуждать о целях системы Не спорю, если все это пишется для системы - мне привычнее думать, что все-таки для людей.

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