Во многих источниках информации указано, что use case - это некая цель, которую желает достич пользователь с помощью системы.
Также существует понятие, что use case <> функция системы. Хм.. тут уже сложнее. Как отделить функцию от цели и, собственно, от use case?

Используем для нашего анализа конкретный пример.
Пусть, в некой абстрактной системе, у нас будет use case "Создать веб-страницу".

Основной поток UC:

[ДЛ = Действующее лицо
Макет = HTML-шаблон, состоящий из нескольких блоков. В блоках могут выводится текст и изображения]

Код: [Выделить]

1. ДЛ переходит к созданию веб-страницы
2. ДЛ задает имя веб-страницы
3. Система проверяет имя на уникальность
4. ДЛ выбирает макет страницы из предустановленного перечня макетов
5. ДЛ формирует контент из текста и изображений, для каждой секции макета
6. ДЛ сохраняет веб-страницу
7. Система перенаправляет ДЛ на страницу списка созданных веб-страниц
8. Сохраненная веб-страница отображается в списке
В данном UC пункт 4 - является отдельным use case или функцией? Ведь это всего-лишь шаг, который необходим для достижения цели "Создать веб-страницу".
Ведь у пользователя нет цели "Выбрать макет", как таковой.

Итак, мы определили, что это функциональное требование - "Система должна позволить выбрать макет веб-страницы из предопределенного списка макетов".
Но в тоже время одно из определений use case говорит нам, что если мы можем вынести описание функции в список фич продукта, то это точно use case.
Если подумать, то выбор макета для веб-страницы вполне достойно этого (т.к. одно дело создавать веб-страницы с одним и тем же расположением блоков, и совсем другое - иметь возможность выбрать макет из некоего перечня).
Итак ... "Выбрать макет" это все-таки use case.. или опять нет  ?

Давайте попробуем описать его основной поток:

Код: [Выделить]

Предусловие: ДЛ находится на этапе выбора макета веб-страницы
1. ДЛ выбирает макет страницы из предустановленного перечня макетов
2. ДЛ переходит к шагу формирования контента
Получился неочень-то информативный use case, что опять смущает.

Итого:
1. Хотелось бы услышать ваше мнение и рассуждения по поводу явлется-ли "Выбрать макет" функцией или UC в данном случае?
2. Как вы определяете, что есть use case? На основании каких признаков?

Use Case — это формализованный сценарий (технология, алгоритм) решения задачи пользователя/клиента при взаимодействии с бизнесом/услугой/инструментом, в котором есть чёткое разделение действий между сторонами.

Если реальный сценарий решения задачи пользователя слишком неформализуемый (например, создание векторного рисунка в векторном редакторе), т.е. — не похож на сценарий, то его неэффективно описывать как use case, а лучше описывать как набор возможностей.

Функция — это просто чёрный ящик, которая преобразует конкретные входные данные в выходные данные.

Не стоит рассуждать про «функции» вообще. Я бы предложил различать бизнес-функции, пользовательские функции и технические функции. Чтобы снизить риски, стоит доводить детализацию до технических функций.

Вы вообще какую задачу описанием этого юскейса решаете? Я обычно — как раз выделение технических функций, чтобы не упустить важного.

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

Проблема в том, что вы смешиваете usage scenario, где описываются шаги пользователя с использованием инструментов (выбрать макет) и use case, где описываются отдельно «чистые» действия пользователя и действия системы (Система показывает список макетов в определённом порядке, Система предлагает что-то с этим макетом сделать, Пользователь каким-то образом указывает макет, Система каким-то образом даёт обратную связь о том, какой макет выбран и что-то предлагает дальше).

Например «ДЛ сохраняет веб-страницу» — ДЛ не может ничего никуда сохранять, если только записать карандашом на бумагу. Сохраняет система, а ДЛ даёт команду. Это язык usage scenario, а не use case.

http://boatmanshome.ru/wiki/wacko/?page=Zametki/StopTheMagic&v=1c9h

Слово "функция" очень многозначно, поэтому нельзя ответить на вопрос "является ли что-то функцией", не выбрав определение. По ГОСТ 34, например, функция - это совокупность действий автоматизированной системы, направленная на достижение определённой цели. Под это определение "Выбрать макет" вполне подходит (но мне категорически не нравится идея подводить однопользовательские приложения в веб под определение АС).

Usecase - это, среди прочего, единица разработки. Если вы используете технологию usecase и считаете "выбор макета" существенной единицей разработки, которой нужно управлять, то смело рисуйте для него отдельное яйцо.

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

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

2  Denis Beskov, 2 Григорий Печенкин - большое спасибо за столь развернутые ответы.

Действительно UC "Выбрать макет" не имеет смысла сам по себе. Но с другой стороны, соглашусь с Григорием, что он может сильно эволюционировать (я думал про подключение функционала импорта сторонних макетов, например) и вырасти в нечто большее, чем просто функция.

Все-таки я убедился, что нет единых правил что считать UC, а что - нет. Если я хочу акцентировать внимание разработчиков на том, что "Выбрать макет" это самостоятельный кусок функционала, то выходит, что могу добавлять его на диаграмму в качестве UC.

Все-таки я убедился, что нет единых правил что считать UC, а что - нет. Если я хочу акцентировать внимание разработчиков на том, что "Выбрать макет" это самостоятельный кусок функционала, то выходит, что могу добавлять его на диаграмму в качестве UC.

Все зависит от уровня, на котором Вы работаете. Но UC - это все-таки некоторая целостная относительно самостоятельная функциональность. У Крэга Лармана есть такие критерии: это элементарный бизнес-процесс (задача), одобрение руководителя, временная протяженность.

Игорь целый день исполняет UC "Выбрать макет"? Ясно, что, если выбор по своей сути это выбор из предопределенного списка доступных значений, то с этой позиции любой выбор, задание или вообще действие пользователя можно рассматривать как некий микро UC. Однако на самом деле в этом случае мы просто полезем в технологии. Другое дело, если выбор макета сопровождается указанием каких-то дополнительных критериев отбора и т.п., но в этом случае наименование UC нужно скорректировать, чтобы ясно и точно передать его цель, назначение.

По работе с UC много хороших книг имеется, это например Коберн. Мне также понравилась книга Use Case Modeling,

Во многих источниках информации указано, что use case - это некая цель, которую желает достичь пользователь с помощью системы.

Просто приклею это сюда и улечу.

Просто приклею это сюда и улечу.

Интересно, а почему на картинке из книги Коберна Writing Effective Use Cases стоит копирайт какого-то Capgemini?

Но вообще, именно эта концепция пяти уровней в книге самая запутанная, и она не даёт ответа на вопрос, что считать функцией.

4. ДЛ выбирает макет страницы из предустановленного перечня макетов

В данном UC пункт 4 - является отдельным use case или функцией? Ведь это всего-лишь шаг, который необходим для достижения цели "Создать веб-страницу".

Итого:
1. Хотелось бы услышать ваше мнение и рассуждения по поводу явлется-ли "Выбрать макет" функцией ... в данном случае?

Выделил, на тему чего могу порассуждать.

В предложенной формулировке оно точно не является функцией системы. Ну, делает там что-то ДЛ... Может, процедура "выбора" представляет из себя последовательное камлание с бубном, подбрасывание монетки и метание валенка за калитку? В общем, чего-то такого, что происходит в целом за рамками системы. Нет, однозначно не функция.

С другой стороны, за этим шагом может скрываться что угодно, включая красную нить, ради которой задумана вся система. Этот момент надо исследовать отдельно, и из него может вырасти целый куст функций. Например:

1. Если есть выбор, значит есть из чего выбирать. Значит, нужно вести какой-то учет вариантов выбора.
2. Если есть учет вариантов выбора, значит в том или ином виде будут стандартные функции: добавление нового элемента, изменение имеющегося, удаление (или деактивация) ненужного, просмотр накопленного "богатства" и поиск в нем. А может, и не очень стандартные, вроде выгрузок, синхронизации или отчетности.
3. Добавление нового элемента - оно какое? Экспорт откуда-то, UI админки, UI балбеса-пользователя, дописка в конфиг-файл? А что для этого должна уметь система?
4. И т.п.

мне категорически не нравится идея подводить однопользовательские приложения в веб под определение АС).

А почему? Чем чревато?

А почему? Чем чревато?

Тем, что вместо сайта получится АС.

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

Во-первых, посетителя сайта нельзя считать персоналом - составной частью АС. Он не винтик машины, обеспечивающий выполнение каких-то функций, а потребитель услуги. Это существенное отличие: действия персонала можно регламентировать, его можно и нужно обучать, для чего разрабатывается целый комплект документации. Ну и персонал, конечно, не платит за услугу эксплуатации АС, а наоборот, платят обычно ему за то, что он с этой АС мучается.

Потребителя услуги регламентировать нельзя. Если продукт предназначен для решения сравнительно сложных специальных задач, можно дать ему рекомендации в виде руководства пользователя. Но не в том составе и не в тех форматах, которые предлагаются стандартами для АС. Иначе он проголосует ногами и деньгами за продукты конкурентов.

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

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

В какой-нибудь банковской системе, которая является типичным представителем класса АС, пользователи готовы десятилетиями мириться с неудобным и непонятным интерфейсом, не очень высокой производительностью на пользовательских задачах (какой-нибудь отчёт генерируется несколько минут), навязчивой системой безопасности - всё ради функциональности, без которой банк просто не сможет работать. Этим, кстати, объясняются кошмарный (с точки зрения обычного пользователя) UI абсолютного большинства банковских систем: функциональность всегда в приоритете, архитектуру поменять можно только путём разработки новой системы, а на всякие эти ваши юзабилити не остаётся ни времени, ни сил. А персонал можно и обучить, ему за это деньги платят.

В вебе такое отношение к пользователям не пройдёт.

Во-первых, посетителя сайта нельзя считать персоналом - составной частью АС. Он не винтик машины, обеспечивающий выполнение каких-то функций, а потребитель услуги.

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

"Посетители" - это отдельная категория, которую и окучивать надо отдельно.

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

Ну так-то да, посетитель у нас ходит, где хочет (а не куда ему разрешают или куда его за ручку водят), пишет в поля ввода что хочет (а не что разрешено по ФЛК), и туториалов для посетителей никто в глаза не видел.

Ну и персонал, конечно, не платит за услугу эксплуатации АС, а наоборот, платят обычно ему за то, что он с этой АС мучается.

Согласен. Прогресс не стоит на месте, и за право эксплуатировать АС уже денег берут. Не говоря уже о том, что это большая честь. Марк Твен обзавидовался бы.

Потребителя услуги регламентировать нельзя. Если продукт предназначен для решения сравнительно сложных специальных задач, можно дать ему рекомендации в виде руководства пользователя. Но не в том составе и не в тех форматах, которые предлагаются стандартами для АС. Иначе он проголосует ногами и деньгами за продукты конкурентов.

Ну как сказать... Если банковский вклад хотя бы на один процент выше, чем у конкурентов, посетителей сайта можно строить как угодно. Проверено, не разбегутся. Будут колоться, плакать, но продолжать.

Зачем для посетителей писать "в том составе и тех форматах", что и для специально обученных людей "при исполнении"? В рамках документирования АС вполне можно изготавливать легкие и непринужденные памятки. А то и комиксы.

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

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

В вебе то, что у аналитиков принято называть "нефункциональными требованиями", сейчас обычно является не ограничениями, а конкурентными преимуществами.

Тоже довольно спорно. Нефункциональные ограничения по пропускной способности, например, и в вебе никуда не делись. А вот "конкурентные преимущества" - они да, появились. Ибо в плановой экономике, откуда выросли наши АС, конкуренция была неактуальна. Но честно говоря не вижу, почему бы благородным донам просто не расширить список нефункциональных требований/возможностей новой категорией.

всё ради функциональности, без которой банк просто не сможет работать. Этим, кстати, объясняются кошмарный (с точки зрения обычного пользователя) UI абсолютного большинства банковских систем: функциональность всегда в приоритете, архитектуру поменять можно только путём разработки новой системы, а на всякие эти ваши юзабилити не остаётся ни времени, ни сил.

Просто бизнес, ничего личного. Так дешевле тому, кто весь этот банкет оплачивает. В очевидно подсчитываемых деньгах дешевле, по крайней мере.

А персонал можно и обучить, ему за это деньги платят.

Логично же.

В вебе такое отношение к пользователям не пройдёт.

Ну так и не надо. Это "традиционный" персонал дро... строить надо. А пользователя никто не запрещает облизывать, пока тот не отдаст все, что у него есть. Добровольно и с песней. Желательно даже, чтобы залез в долги и отдал больше, чем есть.

Просто приклею это сюда и улечу.

"Запутанная концепция" уровней ВИ проиллюстрирована в книге Халл, Джексон, Джереми "Инженерия требований" на примере ресторана. Авторы выделяют сценарий (высокоуровневый ВИ) "Владеть рестораном", кроющий весь "ЖЦ" ресторана под эгидой одного владельца. Внутри его описания они используют менее крупный сценарий одного (каждого) дня работы ресторана -- ВИ более низкого уровня. В свою очередь, внутри его описания используется ещё более мелкий сценарий обслуживания клиента ресторана -- более низкоуровневый ВИ. Можно углубиться дальше -- выделяя подсценарии (ВИ) вроде "Сервировать стол", "Принять пищу". И т. д.

Приклеило и улетело, как обычно.

Во многих источниках информации указано, что use case - это некая цель, которую желает достич пользователь с помощью системы.

Use cases are no longer required to express some needs of actors and to be initiated by an actor.

Написанное относится к UML, начиная с версии 2.5.

Написанное относится к UML, начиная с версии 2.5.

А для чего и как его теперь используют?

Use cases are no longer required to express some needs of actors...

Тут стандарт всего лишь соглашается с Коберном и проч., считающими, что помимо ВИ уровня моря, могут быть ВИ других уровней.

Use cases are no longer required to... be initiated by an actor.

Чтение перечня багов стандарта UML почему-то навело меня на мысль о том, что тут могут иметься в виду расширяющие или включённые ВИ.