Добрый день, всем уважаемым участникам форума.

Прошу заранее извинить мое невежество. Обстоятельства сложились определенным образом, что теперь я работаю системным аналитиком.
Небольшая фирма занимается разработкой веб-сервиса, команда работает по scrum. Собственно, хотят начать разрабатывать требования (тз) на uml. С данным инструментом никогда не работал и сейчас все, что прочитал, только еще больше вопросов породило, как и что конкретно применять.
Для примера есть задача. Добавить сущность: поле с ценой за разовую услугу (стрижка). У данной новой сущности есть определенные атрибуты(1 женская 2 мужская 3 окрашивание...6 химия:)) Какой тип диаграммы выбрать, чтобы предоставить разработчикам? Как в данном случае использовать use case диаграммы? Понимаю, что все весьма абстрактно, но даже если пару строк посоветуете, в каком направлении смотреть/копать, что изучать, преисполнюсь личной благодарностью.
Спасибо за уделенное внимание.

А разработчикам то что надо сделать? Что с этой сущностью дальше происходит?

Добрый вечер.

Описание задачи какое-то сумбурное. Реально ваша команда работает по scrum?

Для справки. Если вы хотите использовать uml, то сначала просто ознакомьтесь что это такое, возможностей море. Можно просто начать с youtube. Можете посмотреть эту книгу http://book.uml3.ru. Можете посмотреть эту библиотеку знаний http://uml-diagrams.org,

Функциональные требования выражаются use cases. Требования к структуре данных обычно выражаются в виде диаграммы классов, используя классы предметной области. Приведенная задача предполагает построение диаграммы классов (или диаграммы объектов).
Для начала нужно понять какие понятия (сущности) фигурируют в предметной области. Судя по задаче есть Услуга, есть Клиент.

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

Из этого простого примера можно сделать примерно такое заключение: Клиент (1) - (1 - *) Посещение (0 -*) - (1) Услуга
Услуга может описываться через атрибуты:
Вид услуги
Наименование услуги
Стоимость единицы услуги

Клиент (ФИО, адрес - если вообще нужно)

Посещение
Дата
Время
Кто оказывал услугу
Общая стоимость

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

А разработчикам то что надо сделать? Что с этой сущностью дальше происходит?

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

Реально ваша команда работает по scrum?
Для справки. Если вы хотите использовать uml, то сначала просто ознакомьтесь что это такое, возможностей море.

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

Если SCRUM, то сформулируйте новый функционал в виде user story

http://2tickets2dublin.com/how-to-write-good-user-stories-part-1/

Добрый день, всем уважаемым участникам форума.

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

Небольшая фирма занимается разработкой веб-сервиса, команда работает по scrum.
Собственно, хотят начать разрабатывать требования (тз) на uml.

А про Scrum вы почитали? Никакого когнитивного диссонанса от слов ТЗ и Scrum не возникло?
Команда хочет разрабатывать — пусть разрабатывает. Какова ваша роль тут?
Где менеджер проекта? Руководитель разработки? Руководитель направления? Что хотят они?

С данным инструментом никогда не работал и сейчас все, что прочитал, только еще больше вопросов породило, как и что конкретно применять.
Для примера есть задача. Добавить сущность: поле с ценой за разовую услугу (стрижка).
У данной новой сущности есть определенные атрибуты(1 женская 2 мужская 3 окрашивание...6 химия:))

Какой тип диаграммы выбрать, чтобы предоставить разработчикам?

Никакой.

Как в данном случае использовать use case диаграммы?

Никак.

Используйте словарь данных Data Dictionary. Достаёте Вигерса, читаете эту главу.

Один из важнейших вопросов аналитика — «чтобы что». Зачем вам в проекте UML? Разработчики умеют его читать?

Команда хочет разрабатывать — пусть разрабатывает. Какова ваша роль тут?
Где менеджер проекта? Руководитель разработки? Руководитель направления? Что хотят они?

Как раз от PM исходит желание перейти на использование uml. На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.   
Пошел изучать Вигерса.

Как раз от PM исходит желание перейти на использование uml. На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.   
Пошел изучать Вигерса.

Все-таки стоит понимать, что user stories и uml мало сочетаются.  И реально узнайте, что хотят получить  от вас программисты.

Все-таки стоит понимать, что user stories и uml мало сочетаются.

Такой вопрос: какие диаграммы сочетаются с user stories?

Как раз от PM исходит желание перейти на использование uml.

Чтобы что? Какие именно управленческие решения он хочет принимать на основании диаграмм?

UML – это не инструмент детализации требований. Это инструмент обеспечения их полноты в соотношении многие-ко-многим.

На данный момент есть куча тикетов с неописанными требованиями. Мне предстоит создать варианты user stories.

Ну так создавайте.

Такой вопрос: какие диаграммы сочетаются с user stories?

Любые, даже сайт про это есть: http://www.agilemodeling.com/

Такой вопрос: какие диаграммы сочетаются с user stories?

Недавно у Касперского проходила очень интересная конференция по управлению требованиями в agile.

https://youtu.be/uHjmBAbUJrc

Ее ценность в том, что на ней делились практическим опытом Agile.

Я для себя сделал примерно такой вывод: user story и uml сочетаются ограниченно. То есть uml диаграмма может быть разработана как иллюстрация какой то user story, но обеспечить единый поток моделирования в agile  крайне трудно за счет того, что поток моделирования прерывается из-за итерационности разработки.

Так же много интересного пл управлению требованию в Agile на страничке журнала "Практика проектирования систем"

https://m.facebook.com/story.php?story_fbid=1221314127939008&id=939608916109532

Такой вопрос: какие диаграммы сочетаются с user stories?

Я не совсем верно выразился, хотел сказать, что user stories не следует путать с use cases, которые являются частью uml и соответственно остальные диаграммы выстроены вокруг use case view.

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

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

Поищите в сети книгу Скотта Амблера Гибкое моделирование. Возможно натолкнет Вас на какие-то идеи.

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

Ориентированность обусловлена желанием UX-дизайнера создавать прототипы на основе uml диаграмм.
Начал изучать Фаулера и как он пишет, что в основном применял uml для создания эскизов. Надеюсь это что-то подходящее.