Добрый вечер, уважаемые!
Столкнулся с задачей описать usecase выдачи книги читателю библиотекарем (зарегистрировать выдачу в системе).
И вот, как я вижу решение этой задачи:

Краткое описание: Выдача экземпляра книги
Пользователь: Библиотекарь
Предварительное состояние: Система загружена
Запускающее событие(я): Пользователь просит выдать книгу
Цели: Регистрация выдачи экземпляра книги в Системе
Результирующее состояние: Выдача книги зарегистрирована в Системе
1.   Библиотекарь  находит книгу в справочнике, выделяет её и нажимает кнопку «Выдать экземпляр»
2.   Система удостоверяется, есть ли доступные для выдачи экземпляры книги, в противном случае выводит сообщение о том, что доступных для выдачи экземпляров нет. Возвращается к п.1
3.   Система отображает интерфейс «Выдача экземпляра книги»
4.   Библиотекарь  заполняет поля:
     a.   Инвентарный номер выдаваемой книги – можно выбрать из списка
     b.   Номер читательского билета, на который выдается книга
И нажимает кнопку «Выдать»
5.   Система удостоверяется,  что есть возможность выдачи книги на указанный номер читательского билета. В противном случае выводит сообщение о том, что выдача по указанному номеру читательского билета не возможна. Возвращается к п. 4
6.   Система вносит данные о выдаче экземпляра книги:
     a.   Уникальный номер выдачи (генерируется системой)
     b.   Номер экземпляра выдаваемой книги.
     c.   Номер читательского билета, на который выдается книга.
     d.   Дата выдачи книги (генерируется системой)

и выводит сообщение: «Данные о выдаче экземпляра успешно зарегистрированы в системе»

Прошу Вас, знающие люди, укажите мне на мои ошибки.

Прошу Вас, знающие люди, укажите мне на мои ошибки.

Уважаемый Limon. А Вам какие указывать ошибки?
Технические ошибки спецификации варианта использования
или
Ошибки логического характера?

В первую очередь меня интересуют логические ошибки.
Но и указание на технические ошибки не повредит))
В целом, ошибок масса, да?

Пошарьте документ в Google Doc и дайте возможность комментировать.

Что вы нас заставляете возиться с цитатами в 2016-м году?

Навскидку
1) Непонятно, кто такой пользователь. Посетитель библиотеки? Его роль в описании туманна: он вроде указан в стартовом событии, непонятно, каким образом он сообщает о своем желании взять книгу и каким образом. Он должен либо сообщить  всю информацию до начала процесса оформления, либо участвовать в сценарии как одно из ДЛ
2) Некорректно выделены границы процесса: почему из процесса исключена книговыдача, но включен поиск книги
3) Исключения объединены с шагами happy path (п.п 2 и 5). В шагах объединены действия и системы и ДЛ
4) Не предусмотрено исключение по п.1. , если книга не находится в каталоге
5) Не предусмотрена возможности прервать процесс . Например в п.2 после того, как книга не найдена в каталоге , то библиотекарь зачем то повторяет процесс поиска...


Алистер Коберн рекомендуется... 

 

Пошарьте документ в Google Doc и дайте возможность комментировать.

Что вы нас заставляете возиться с цитатами в 2016-м году?

Вот ссылка на документ в google docs
https://docs.google.com/document/d/1p-of8527g2cv5AodrWUohRz3bnWiZsOh8ISmuf1ThSc/edit?usp=sharing
внизу красным выделен сценарий использования, который шел вместе с заданием, как пример

2Humbert:
1. Пользователь - читатель, имеющий читательский билет. Предполагается, что до начала процесса он сообщает какая книга ему нужна, а остальная информация известна.
2. Добавил пункт выдачи книги, спасибо.
3. Альтернативный сценарий (исключения) лучше записывать ПОСЛЕ основного сценария?
Не могу понять в каком шаге объедены действия системы и библиотекаря...
4. Согласен, добавлю альтернативный сценарий к первому пункту.
5. Ну... я таким образом хотел прервать процесс выполнения сценария и, возможно, вернуться к поиску новой книги. А каким образом можно прервать процесс выполнения?

«Идеальный» юскейс:

Предусловие:
* Читатель проносит книгу мимо камеры системы, выходя из библиотеки

Основной поток:
1. Система распознаёт читателя и книгу и фиксирует факт взятия книги

Всё.

2Humbert:
1. Пользователь - читатель, имеющий читательский билет. Предполагается, что до начала процесса он сообщает какая книга ему нужна, а остальная информация известна.
2. Добавил пункт выдачи книги, спасибо.
3. Альтернативный сценарий (исключения) лучше записывать ПОСЛЕ основного сценария?
Не могу понять в каком шаге объедены действия системы и библиотекаря...
4. Согласен, добавлю альтернативный сценарий к первому пункту.
5. Ну... я таким образом хотел прервать процесс выполнения сценария и, возможно, вернуться к поиску новой книги. А каким образом можно прервать процесс выполнения?

1. Что понимается под читательским билетом? Его читатель носит с собой или он хранится в библиотеке? Если библиотека автоматизирована, то каковы его функции? Как про этот билет и что с ним делать узнает система?
2. Если книга выдается в этом сценарии, то как она оказывается у библиотекаря или читателя? Процесс  физического поиска кстати тоже может быть неуспешен.
3. Да. Формат сценария хорошо описан у Коберна. Насчет объединения действия SuD и ДЛ я ошибся
5. Если не находится читательский билет, книга в каталоге или физически, то в качестве одной из альтернатив выступает отказ от выдачи книги.

Повторно рекомендую 

Alistair Cockburn - Writing Effective Use-Cases

(есть и на русском)

Вы избежите многих ошибок, если хотя бы бегло ознакомитесь с ней.

«Идеальный» юскейс:

Предусловие:
* Читатель проносит книгу мимо камеры системы, выходя из библиотеки

Основной поток:
1. Система распознаёт читателя и книгу и фиксирует факт взятия книги

Всё.

1а Система не распознает читателя
1b Система не распознает книгу
1с Система распознает книгу, лежащую рядом с выходом и ошибочно считает, что ее вынес читатель
1d Факт взятия книги не удалось зафиксировать - она числится у другого читателя
..... 

Убрали библиотекаря из процесса, поставили считыватели, а сценарий почти не изменился

В первую очередь меня интересуют логические ошибки.
Но и указание на технические ошибки не повредит))
В целом, ошибок масса, да?

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

Существуют различные рекомендации, которые продиктованы практикой. В нашем FAQ есть пример таких рекомендаций (http://www.uml2.ru/faq-use-cases/). Участники форму уже дали свои рекомендации и советы.

С точки зрения логичности - тут тоже можно спорить, но мне кажется это условие

5.   Система удостоверяется,  что есть возможность выдачи книги на указанный номер читательского билета. В противном случае выводит сообщение о том, что выдача по указанному номеру читательского билета не возможна. Возвращается к п. 4

должно быть предусловием к выполнению Вашего ВИ. Т.е. можно выдать книгу только тому, у кого все в порядке изначально

Спасибо всем, кто проявил активность и помог мне с задачей! 

Уважаемые аналитики, помогите, пожалуйста еще с одной:
Мне требуется дополнить диаграмму сущность-связь для описания модели автоматизации библиотеки.  Была дана диаграмма (все, что ченым цветом - было дано) на которой нужно было нарисовать недостающие объекты (дорисованное мной выделено красным цветом). Ссылки из одного объекта на другой, являющиеся реализацией связи один-ко-многим.
Главное требование: необходима возможность вести учет взятых читателями книг (какой читатель когда взял какую книгу).



Всё ли я сделал верно?

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

Нельзя не отметить странность того, от чего Вам предложено отталкиваться. Плюсики и минусики на т. н. "диаграмме сущность-связь" что должны изображать по мнению её составителя? Экземпляр книги на полке (на нескольких полках?), полка в нескольких стеллажах? Как найти экземпляр? К какому стеллажу идти?
Если не обращать внимания на вышесказанное, то Вы скорее всего справились со стоящей перед Вами задачей. Добавлю, что можно отмечать действительную дату возвращения книги и дату, до которой книга должна быть возвращена. Это поможет определять величину задержки книги нерадивым читателем и, например, начислять разные штрафы. С другой стороны, если правила библиотеки устанавливают одинаковый срок, на который выдаётся книга, хранить ещё одну дату не обязательно. Она может быть вычислена.

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

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

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

+100500

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