Если не считать того что я уже писал про компоновку CRUD (благодаря которой можно было бы уместить всех акторов на одной диаграмме:)), могу заметить следующее:

1.Выйти/войти - вообще не ВИ.
2. У родителя/ученика - посмотреть примечания два раза. И если бы я был проектировщиком системы, я бы дал им разные ВИ и разные наборы доступов, а  не одинаковые, но это к самой диаграмме не относится.
3. Что за особая сиреневая связь между учителем и "просмотреть расписание"?
4. Создание примечаний у учителя - надо по другому назвать. Не ясно что делает ВИ.

Вот студенты выполнили работу над ошибками и сформировали немного иное представление. 
Буду рад замечаниям и предложениям.

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

Замечаний (не очень существенных) два:
1) использовать CRUD, о котором здесь уже говорили, чтобы визуально разгрузить диаграммы
2) вместо "запросить отчёт" использовать "получить отчёт"

1.Выйти/войти - вообще не ВИ.

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

2. У родителя/ученика - посмотреть примечания два раза. И если бы я был проектировщиком системы, я бы дал им разные ВИ и разные наборы доступов, а  не одинаковые, но это к самой диаграмме не относится.

Я думаю это просто ошибка

3. Что за особая сиреневая связь между учителем и "просмотреть расписание"?

Просто выделенная связь - дефект копирования

4. Создание примечаний у учителя - надо по другому назвать. Не ясно что делает ВИ.

Там Записать примечание, а что не понятно, кому примечание пишется?

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

Замечаний (не очень существенных) два:
1) использовать CRUD, о котором здесь уже говорили, чтобы визуально разгрузить диаграммы
2) вместо "запросить отчёт" использовать "получить отчёт"

Спасибо. А как правильно все-таки формулируются CRUD ВИ и далее специфицируются?

Спасибо. А как правильно все-таки формулируются CRUD ВИ и далее специфицируются?

Я обычно просто рисую одно яйцо вместо четырёх и пишу что-то вроде "CRUD: оценка ученика". Примерно как здесь предлагается:

http://www.ijsce.org/attachments/File/v2i2/B0535042212.pdf

Что касается дальнейшей спецификации - я уже говорил, что не использовал ДВИ для этой цели.

Что касается дальнейшей спецификации - я уже говорил, что не использовал ДВИ для этой цели.

Спасибо, Гриша. Никак не мог понять, почему ты говоришь о ДВИ при специфицировании ВИ. Я понимаю, что на диаграмме 4 яйца сворачиваются в 1. Я интересуюсь, как в этом случае формируется текстовая (другой я все равно не знаю) спецификация

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

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

Там Записать примечание, а что не понятно, кому примечание пишется?

Да, именно. Т.е. если записать примечание к оценке, то я бы поместил его в CRUD оценок. Если примечание к ДЗ - в CRUD  к ДЗ.
Сразу схема становится  проще к восприятию.

PS: Но если бы мне надо было впихнуть в ВИ и вход с авторизацией, я бы изобразил его вот так (рис. во вложении). Но все же считаю что так делать не стоит все равно:)

Коллеги,

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

Имя: Добавить нового пользователя
ID: 1
Краткое описание: ВИ описывает создание нового пользователя
Действующие лица: Администратор
Предусловие:
1.Администратор авторизован в системе.
2.У администратора должны быть данные о новом пользователя для создания учетной записи.

Постусловие: Пользователь зарегистрирован в системе “Электронная школа”
1.0 Основной поток:
   1.Администратор делает запрос на регистрацию нового пользователя.
   2.Система предоставляет возможность для выбора роли пользователя
   3.Администратор выбирает роль пользователя
   4.Система предоставляет форму для заполнения личных данных о пользователе в зависимости от роли
   5.Администратор заполняет предоставленную системой форму и сохраняет
   6.Система сохраняет пользователя в базе данных
   7.Система выводит сообщение об успешном сохранении данных
   8.Система предлагает администратору добавить нового пользователя

Альтернативные потоки:
1.1Данный пользователь уже существует в системе (ответвление шага 5)
   1.Система выдает сообщение, о том, что данный пользователь уже зарегистрирован в системе.
   2.Возврат к пункту 2 основного потока.

1.2Не все обязательные поля заполнены (ответвление шага 5)
   1.Система выдает сообщение, о том, что пропущено поле для заполнения
   2.Возврат к пункту 4 основного потока.

Ограничения:
1.Пароль должен состоять из набора латинских букв и цифр,  должен быть не менее 6 символов символов.
2.Логин должен содержать не меньше 6 цифр.
3.ФИО должен состоять из русских букв, начиная с заглавной буквы.
4.При заполнении поля “Класс” выбирается число от 1 до 11 включительно и без пробела ставится буква русского алфавита: А, Б, В ,Г ,Д.
5.Адрес должен состоять из букв русского алфавита и цифр и не должен превышать 50 символов.
6.Дата рождения ставится в соответствии с предложенным календарем.
7.Email представляет собой стандартную форму электронного почтового ящика.
8.Администратор может выбрать только одну из ролей, либо ученик, либо учитель.
9.Мобильный телефон должен состоять из 11 цифр, начиная с 8

Давай по шагам юскейса:

1. Чтобы Администратор мог сделать запрос, система должна сначала предоставить ему такую возможность. Хотя бы в виде курсора командной строки. Есть скрытый вариант типа горячих клавиш, но тут, как я понимаю, не тот случай. Не хватает этого шага.

2. Лучше разделить на 2-3 операции опять же (в одном шаге), например, «показывает список доступных ролей и предлагает выбрать одну из них». Если список ролей уже известен (и будет зашит в систему), лучше сразу написать его здесь.

4. Тут нужно указать состав полей или сослаться на структуру из Словаря данных. Юскейс может использоваться для проектирования и разработки без предварительного создания списка ФТ, поэтому в нём должно быть достаточно информации для проектирования.

5. Администратор не может ничего сохранять. Сохраняет система, пользователь только предоставляет данные и команды. См. заметку Сергея Нужненко: http://boatmanshome.ru/wiki/wacko/?page=Zametki/StopTheMagic&v=1c9h

6. Пропущен шаг по проверке корректности заполнения полей и уникальности пользователя.

8. Лучше этот шаг сделать шагом 0, а на 8-м шаге поставить «Сценарий продолжается с шага 0». Но таким образом возникнет бесконечный цикл, который придётся разрывать исключением 1а.

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

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

Если Админ чаще вводит несколько пользователей подряд, то лучше указать, что система показывает форму нового пользователя с последней ролью и возможностью её сменить.

Если Админ чаще вводит по одному пользователю, то логично, чтобы сценарий показывал список всех пользователей с выделением только что добавленного или предлагал какие-то другие шаги, которые обычно делает Админ после регистрации (например, настройка квот, включение в группы, что-то ещё).

По расширениям:

Выбрана неудобная система идентификации расширений. Схема 1а1а1 кмк намного нагляднее.

Расширение 1.1. Условие входа в расширение — это условие-событие, которое ВЗАИМОИСКЛЮЧАЩЕЕ для событий того шага основного потока, в котором оно возникло. В данном случае события шага 5 основного потока и условие входа в расширение 1.1. вполне совместимы. Всё дело в пропущенном шаге контроля вводимых данных.

Обработка расширения — из условия входа неясно, каково всё-таки правило совпадения пользователей — должны совпадать имейлы, или имейлы+ФИО или ещё как-то? Если речь только об имейле, то очень глупо, если человек ошибся в одной букве имейла так, что это привело к совпадению с уже существующим пользователем, терять введённые им данные и просить заполнить всё заново.

Например, у вас уже есть smirnovaa@mstu.ru и вы пытаетесь добавить ещё одного однофамильца, у которого первая буква имени — A. Система должна подсказывать, что делать, а не тупо ругаться и сбрасывать форму.

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

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

Ты пишешь

6. Пропущен шаг по проверке корректности заполнения полей и уникальности пользователя.

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

Ты пишешь:

Выбрана неудобная система идентификации расширений. Схема 1а1а1 кмк намного нагляднее.

Не совсем понял твою схему -(кмк - как мне кажется?)

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

Это где он о таком пишет?

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

В юскейсах нет уровней представления и бизнес-логики, есть чёрный ящик или серый. И ещё я использую юскейсы для выявления ФТ.

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

Да, эту работу может делать аналитик, тут не нужны никакие архитектурные компетенции.

Это где он о таком пишет?

Я имел в виду, именно это

Я здесь не вижу ничего про «внутреннее поведение» и «прячем». Я вижу риторику про сдвиг от содержания деятельности к её результату, также, как в именовании юскейсов «Найти письмо» вместо «Искать письмо».

Я своим студентам рекомендую писать «Система убеждается, что ... и сообщает …», т.к. вижу 2 разных операции, также, как, например, в случае сохранения.