коллеги, маловато данных по аналитикам, давайте дополним? https://career.habr.com/salaries/reports

Люди! Нужно сделать портфолио системного аналитика уровня middle. То есть примеры работы с UML, ER, DFD, BPMN, IDEF, юзкейсами, юзерстори (пока такие пункты). Я это делал когда-то, кроме IDEF, но под рукой нет. Лучше сейчас с нуля сделаю новые образцы. Но было бы здорово разобрать какую-нибудь современную задачу, и для нее построить UML, BPMN и т. п. Посоветуйте, пожалуйста, на ваш взгляд что-нибудь из интересных задач для 2020-ого?

И по объему портфолио - как лучше сделать?
Например, для UML сделать только диаграммы классов, юзкейсов и последовательности и для каждого типа - 2-3 содержательные картинки-примера. Достаточно будет?

И по 5 юзкейсов и юзерстори?

И еще нужно в портфолио как-то отобразить умение проводить интервью заказчика. Как это лучше сделать? Подготовить образец списка вопросов к интервью?

Я думаю, что на мидла достаточно пары сквозных примеров решения крупных задач. Из них раб-ль в лучшем случае внимательно прочитает один.

Накидывать по 5 юзкейсов - зачем? Кто их будет читать? Вы же не джун, который делает n попыток чтобы изо всех сил изобразить свои  навыки.

Сложную задачу можно попробовать придумать, но лучше придумывать ее на основе своих реальных проектов

NDA и пусть идут нафиг с портфолио, буду я еще на гит портфолио с доками внутренних решений что в vpn вертятся выкладывать, на тех собесе пусть решают. Не нужно потакать всякой ереси. А то придете к метрикам, количество коммитов на гит в md доки, как у некоторых средних разрабов в пет проекте, что пытаются сеньоров занять. Сениоров и без гит перекупают. Я работаю, а не коммиты в петы делаю.

*Гении опен сурс вариант, но как показывает практика 2 гения из опен сурс хуже чем 5 обычных разработчиков.  Простое решение и рабочее решение, круче крутого "преодолевания" в одно-два лица.

P.S. Стартапы с опционами, отдельно от написанного выше. Там правила игры сразу другие определены.

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

Ну начнем с перевода:
Юзстори - это история пользователя, то есть только с точки зрения одного человека
Юзкейс - это сценарий, и в его исполнении принимает участие несколько сторон, как минимум еще система

И юзстори, в большинстве случаев не рассматривает альтернативные ветки развития событий, в отличии от сценариев.

А можно на примерах?

Как я себе это придумал в голове;

User Story: Я как водитель авто хочу получать сообщение о повороте заранее, что бы не пропустить нужный поворот и приехать на место вовремя

Use Case:
Основной сценарий:
1) Пользоваетль (не важно кто водитель или пассажир) указал точки отправления и назначения
2) Система проложила маршрут из точки отправления в точку направления
3) Пользователь начал движение
4) Система отслеживает положение и соответствие заданному маршруту
5) Пользователь остановился
6) Система отметила окончание поездки

Расширение:
4.1) Система на пути следования определила поворот
4.2) Система за 300 метров предупреждает о повороте
4.3) Система отслеживает положение и соответствие заданному маршруту
4.4) Система предупреждает о повороте за 30 метров до поворота

4.4.1) Система определила, что поворот был пропущен
4.4.2) Система перестроила маршрут
Переход к пункту 4 основного сценария

и так далее...

Ну это чисто мое мнение, на сколько я понимаю этот вопрос. Может я где-то не прав и надеюсь остальные меня подправят...

у user story должна быть added value с т.з. пользователя, а у use case'a необязательно

то есть стори реализуется в рамках юзкейса?
или это не обязательно?

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

Не надо пихать оба артефакта в один проект, они аналоги.

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

История это не только statement of value, это еще и бизнес-контекст и критерии  приёмки.

Я как-то ранее по обсуждению спрашивал по уровню UserStory и UseCase.

И вроде как получилось, что UserStory это больше потребности стейкхолдеров, а UseCase это уже больше требования к системе