Вот результат творческой работы студента.

Если интересно, то прошу вас дать свои комментарии к нему (отметить хорошие стороны, указать на ошибки, сделать замечания по тексту).

Имя: Создать меню
Автор: ХХХХХХХХХХХХ
Дата создания: 14.09.20ХХ
Дата изменения:
Статус: Основной поток отправлен в реализацию. Утвержден 16.10.ХХ (группой товарищей )
D: 10
Действующие лица: Менеджер меню
Краткое описание: Менеджер меню кафетерия составляет меню имеющихся в наличии блюд и соответствующих им цен на выбранную дату.
Предусловия: Нет
Основной поток:
1. Менеджер меню делает запрос на создание меню на определенную дату.
2. Если меню на указанную дату уже существует, то
2.1 Система сообщает менеджеру, что меню на указанную дату уже существует
2.2 Возврат к шагу 1 основного потока
3. Иначе
3.1 Система выводит новое меню с входящим в него списком стандартных блюд.
3.2 Менеджер меню делает запрос на добавление новых блюд.
3.3 Система выводит список типов меню.
3.4 Менеджер меню выбирает тип меню.
3.5 Система выводит категории блюд входящих в выбранное меню.
3.6 Менеджер меню выбирает категорию блюда.
3.7 Система выводит блюда, относящиеся к данной категории.
3.8 Менеджер меню выбирает блюда из выбранной категории и при желании меняет цену.
3.9 Система отображает изменения.
4 Если менеджер меню желает сменить категорию блюда то система сохраняет выбранные блюда и возврат к шагу 3.6
5 Если Менеджер меню хочет сменить тип меню то система сохраняет выбранные блюда и возврат к шагу 3.4
6 Иначе
6.1 Менеджер меню делает запрос на сохранение меню.
6.2 Система сохраняет меню.

Постусловия: Меню сохранено в системе
Альтернативные потоки:
1. Дата превышает текущую более чем на 14 дней.
2. Дата меньше текущей.
3. Не выбрана категория.
4. Не выбран тип.

Имя: Дата превышает текущую более чем на 14 дней.
ID: 10.1

Действующие лица: Менеджер меню
Предусловия: Дата превышает текущую дату более чем на 14 дней.
Альтернативный поток:
1 Система сообщает, что меню на указанную дату создано быть не может.
Постусловия: возврат к вводу даты.

Имя: Дата меньше текущей.

ID: 10.2

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

Имя: Не выбрана категория.

ID: 10.3

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

ID: 10.4

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

Эд, а опубликуй в GDocs, тогда будет проще комментировать попунктно.

Эд, а опубликуй в GDocs, тогда будет проще комментировать попунктно.

Хорошо.

Доступ к файлу на GDocs. ВИ Создать меню

… и теперь пожалуйста доступ на комментирование.

… и теперь пожалуйста доступ на комментирование.

Денис, ты больше меня пользуешься GDocs, посоветуй как корректно настроить доступ. Я дал доступ всем, но вот про комментарии не понял как.

... Я нашел

1. Почему бы сразу не обязать менеджера при создании меню выбирать тип? Это избавит его от ошибок, а нас от альтернативного потока 10.4 - да и выглядит коряво с точки зрения юзабилити:)
2. Судя по ВИ, менеджер не может сохранить стандартный набор блюд как новое меню. Согласно 3.2 он обязан добавить новые блюда. Это так задумано или студент недосмотрел?
3. Альтернативный поток 10.3 - не вижу его применения. Судя по ВИ, категория выбирается только при добавлении нового блюда. А если он хочет добавить новое блюдо, то выбор категории обязателен и осуществляется до выбора блюда. Таким образом я не вижу как ВИ может перейти в этот поток.
4. Ну и проверку на даты я бы не стал включать как альтернативные потоки. Просто контроль при создании меню и все.

Спасибо.

4. Ну и проверку на даты я бы не стал включать как альтернативные потоки. Просто контроль при создании меню и все.

Что значит просто контроль? АП вроде как раз и включает описания исключений, которые могут возникнуть при неверных данных.

1. Почему бы сразу не обязать менеджера при создании меню выбирать тип? Это избавит его от ошибок, а нас от альтернативного потока 10.4 - да и выглядит коряво с точки зрения юзабилити:)

Согласен.

2. Судя по ВИ, менеджер не может сохранить стандартный набор блюд как новое меню. Согласно 3.2 он обязан добавить новые блюда. Это так задумано или студент недосмотрел?

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

3. Альтернативный поток 10.3 - не вижу его применения. Судя по ВИ, категория выбирается только при добавлении нового блюда. А если он хочет добавить новое блюдо, то выбор категории обязателен и осуществляется до выбора блюда. Таким образом я не вижу как ВИ может перейти в этот поток.

Согласен. Мне этот момент тоже показался весьма странным. На реализации это выглядит так.
Менеджер меню, выбрав команду "создать меню", получает предложение указать дату, на которую создается меню.
Система отображает список стандартных блюд, сгруппированных
- 1 по типу меню (который есть свойство блюда)
- 2 по категории (с учетом заданного порядка - от первых к напиткам) категория тоже свойство блюда.
Менеджер указывает цену выведенных блюд.
Менеджер может добавить другое (нестандартное) блюдо.
Система предлагает выбрать тип меню - Менеджер выбирает (например Блюда из ресторанов)
Система отображает список категорий блюд  - Менеджер выбирает категорию.
Если!!!! есть блюда соответствующие типу и категории, то отображается первое блюда из списка.
Так что менеджер при формировании меню по сути играет в рулетку. Мне сказали, что реализовано полностью согласно описанию ВИ.
4. Ну и проверку на даты я бы не стал включать как альтернативные потоки. Просто контроль при создании меню и все.
[/quote]

2. Если меню на указанную дату уже существует, то
2.1 Система сообщает менеджеру, что меню на указанную дату уже существует
2.2 Возврат к шагу 1 основного потока
3. Иначе

Если основной поток занимает больше 7-10 строк, я предпочитаю выносить даже мелкие ветвления в альтернативные потоки. Здесь можно было бы так сделать.
И ещё мне нравится стиль описания ветвлений, когда в точке ветвления (2) пишется что-то типа:
"1. Менеджер меню делает запрос на создание меню на определенную дату.
2. Система проверяет существование меню на указанную дату.
3. Система выводит новое меню с входящим в него списком стандартных блюд."
, а остальная часть ветвления выносится в альтернативный поток.

3.7 Система выводит блюда, относящиеся к данной категории.
3.8 Менеджер меню выбирает блюда из выбранной категории и при желании меняет цену.

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

3.9 Система отображает изменения.

Разве если менеджер изменит цену на экране, то это изменение может на нём не отобразиться? Или имеется ввиду что-то другое и нужно уточнить пункт?

4 Если менеджер меню желает сменить категорию блюда то система сохраняет выбранные блюда и возврат к шагу 3.6

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

И возврат не к 3.6, а к 3.5.

5 Если Менеджер меню хочет сменить тип меню то система сохраняет выбранные блюда и возврат к шагу 3.4

Если верить этому пункту, то мы можем добавить в меню блюда категорий, не разрешённых новым типом меню (на который меняем). Так не должно быть?

Альтернативные потоки:
...
Предусловия: Дата превышает текущую дату более чем на 14 дней.

Нужно указать где именно производится проверка на выполнение условия. На каком шаге и какого потока.

Альтернативные потоки:
...
Постусловия: возврат к вводу даты.

Это не постусловие, а описание поведения системы. Нужно указать с какого шага какого потока продолжается выполнение. А постусловие может отражать описание какого-то состояния некоего объекта, которое можно проверить.

- 1 по типу меню (который есть свойство блюда)

Как я понял прямой связи с блюдом не должно быть. Будет связь между типами меню и категориями многие-ко-многим и между категориями и блюдами (один-ко-многим или многие-ко-многим). Я не прав?

- 2 по категории (с учетом заданного порядка - от первых к напиткам) категория тоже свойство блюда.

Кем задан этот порядок и в каком порядке должны располагаться категории между первыми и напитками? Сначала салаты, а потом вторые или наоборот?

4. Ну и проверку на даты я бы не стал включать как альтернативные потоки. Просто контроль при создании меню и все.

То есть в основном потоке написать что система не даёт задать дату, не соответствующую таким-то требованиям?

Спасибо.Что значит просто контроль? АП вроде как раз и включает описания исключений, которые могут возникнуть при неверных данных.

Я бы в ВИ написал не
"1. Менеджер меню делает запрос на создание меню на определенную дату."
а
"1. Менеджер меню делает запрос на создание меню на определенную дату в пределах допустимых дат."
и все, потоки 10.1 и 10.2 уже не нужны:)

Мне сказали, что реализовано полностью согласно описанию ВИ.

ВИ писал один человек, а реализовывал другой?

И еще вопрос по пункту 5. Там речь идет о типе меню всего меню, или о типе меню в котором находится блюдо выбранной категории?
Если не уточнить этот вопрос, может показаться, что есть два вида "типов меню", один тип меню у каждого блюда, и один тип меню у всего меню, в которые входят блюда, каждое со своим типом меню:)
Зачем вообще все так переусложнять с типами меню? Это было озвучено в задаче или так решил создатель ВИ?

Если основной поток занимает больше 7-10 строк, я предпочитаю выносить даже мелкие ветвления в альтернативные потоки. Здесь можно было бы так сделать.
И ещё мне нравится стиль описания ветвлений, когда в точке ветвления (2) пишется что-то типа:
"1. Менеджер меню делает запрос на создание меню на определенную дату.
2. Система проверяет существование меню на указанную дату.
3. Система выводит новое меню с входящим в него списком стандартных блюд."
, а остальная часть ветвления выносится в альтернативный поток.

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

Разве если менеджер изменит цену на экране, то это изменение может на нём не отобразиться? Или имеется ввиду что-то другое и нужно уточнить пункт?

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

Если верить этому пункту, то мы можем добавить в меню блюда категорий, не разрешённых новым типом меню (на который меняем). Так не должно быть?

А что есть новый тип? По-моему в описании сказано, что выбирается тип меню, а потом категория блюда. Но я согласен, описанные действия далеко не ясные.

Как я понял прямой связи с блюдом не должно быть. Будет связь между типами меню и категориями многие-ко-многим и между категориями и блюдами (один-ко-многим или многие-ко-многим). Я не прав?

Ну из описания ВИ Вы никаких таких вывод сделать не можете, верно? На самом деле в реализации Категория блюда и Тип меню - атрибут блюда. Не уверен есть ли перечисление или таблица с категориями и типами, но это 1-ко-многим в лучшем случае. Между Типами и категориями связь опосредованная, но получается что одно блюдо может быть отнесено только к одной категории и только к одному типу меню. Без вариантов.

Кем задан этот порядок и в каком порядке должны располагаться категории между первыми и напитками? Сначала салаты, а потом вторые или наоборот?

Порядок задан Заказчиком

Я бы в ВИ написал не
"1. Менеджер меню делает запрос на создание меню на определенную дату."
а
"1. Менеджер меню делает запрос на создание меню на определенную дату в пределах допустимых дат."
и все, потоки 10.1 и 10.2 уже не нужны:)

Ага понял.
 

ВИ писал один человек, а реализовывал другой?

Точно так.

И еще вопрос по пункту 5. Там речь идет о типе меню всего меню, или о типе меню в котором находится блюдо выбранной категории?
Если не уточнить этот вопрос, может показаться, что есть два вида "типов меню", один тип меню у каждого блюда, и один тип меню у всего меню, в которые входят блюда, каждое со своим типом меню:)
Зачем вообще все так переусложнять с типами меню? Это было озвучено в задаче или так решил создатель ВИ?

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

Таким образом появилось это понятие типа меню, которое реально и не тип меню, а как бы классификатор блюда, определяющий принадлежность к некоторому меню и соответственно имеющий спецправила обработки.

Друзья, спасибо за интерес к разбору ВИ, но может Вы оставите комменты здесь?
https://docs.google.com/document/d/10QgoTnF_sVX9tGnCxmnerN4CyDQso-_IHyiNHGStd7c/edit

Эд, отписал.

Ты давал авторам стандартный чеклист ошибок по Коберну?