Собственно, с началом нового месяца, начнем описывать систему :)) (во всяком случае, сейчас еще не 2е число, а очень позднее первое) :)))
В качестве учебника по написанию этих user-story я использовал Коберна "Современные методы описание функциональных требований к системам". Как смогу буду придерживаться его.
В качестве рецензора (или как-там-будет-по-умному), надеюсь, выступит Антон К. Душутин (читать как Антон-ка :)), и сможет найти время, что б высказать много умных замечаний.
Итак, некоторые моменты написания user-story (в основном, перефразированные предложения из книги):
Определение SuD (System under Discussion) - рассматриваемая система.
Актер - человек (или другая система) взаимодействующий с SuD.
Что такое вариант использования?
"Вариант использования описывает поведение системы при ответах на запросы одного из участников".
Таким образом, при описании вариантов использования, скорее всего, будет участвовать "оба" участника (SuD и Актер). Если этого не видно в системе, вариант использования, скорее всего, описан не правильно.
Обязательно буду указывать уровень цели.
Градацию возьму из Коберна. (но иногда буду от нее отступать для удобства описания).
Уровень цели пользователя.
(Голубой уровень) (поскольку у Коберна ассоциации с морем, я решил, что аквамарин - хороший цвет :)))
(Голубой уровень) (поскольку у Коберна ассоциации с морем, я решил, что аквамарин - хороший цвет :)))
Уровень варианта использования, когда цель достигается одним актером за "одну транзакцию", т.е. без разрыва сессии, без долгого ожидания реакции системы и т.д.
В качестве примера:
1. Пользователь хочет посмотреть описание маршрута. Для этого он заходит на сайт, открывает список маршрутов, выбирает нужный, смотрит. Таким образом он выполнил все действия в одной транзакции.
2. Пользователь хочет зарегистрироваться на сайте. Для этого, заходит на сайт, вводит информацию о себе, запрашивает подтверждение. Ждет подтверждения по почте. Когда подтверждение пришло, вводит подтверждающий код. Он становиться зарегистрированным пользователем. Таким образом, пользователь не может выполнить весь процесс за одну транзакцию. Их две с точки зрения SuD: первая - ввод регистрационных данных, вторая - ввод подтверждающего кода.
С точки зрения описания вариантов использования, это плохие примеры, так как они не отражают работу SuD. Приведены только для демонстрации уровня цели
Поступила критика по поводу этих примеров.
Луценко Лапуля (15:22:23 3/07/2008)
нормальные у тебя примеры!!!
Луценко Лапуля (15:23:02 3/07/2008)
типа вот на витрине стоит сапог с отломанным каблуком, но вы не пугайтесь, в коробках у нас с каблуками сапоги. этот, так.., для примера стоит
Мнда... нельзя не согласиться. Привел примеры уровня пользователя, и потом сам же кинул их в уровень индиго (см. ниже).
Поскольку переписывать примеры мне лень, то скажу, что это просто примеры Use-case уровня индиго.
Поясню: ЦЕЛЬЮ пользователя при работе с сайтом НЕ может быть регистрация на сайте. Поскольку регистрация ради регистрации - глупость. Голубым этот уровень никак быть не может. Целью пользователя может являться просмотр маршрута, создание и т.д.
Обобщенный уровень.
(Белый уровень.) (ну... так... сероватый :))
(Белый уровень.) (ну... так... сероватый :))
Уровень общего варианта использования для достижения некой цели при помощи SuD. Тут может быть разрывы во времени, может участвовать несколько Актеров, обычно, ссылается на другие варианты использования.
В качестве примера:
Необходимо организовать выезд по маршруту, который еще не введен в базу.
"Сусанин", вводит маршрут в базу, "Кататель" регистрирует "покатушку".
Как мы видим, взаимодействовали несколько Актеров, использовались другие варианты использования, такие как "ввод маршрута в базу", "регистрация "покатушки"".
Уровень подфункции.
(Уровень индиго) (ну, идниго не прокатил, взял Lavender, хотя он море мне уже не напоминает, но - сойдет!)
(Уровень индиго) (ну, идниго не прокатил, взял Lavender, хотя он море мне уже не напоминает, но - сойдет!)
Ну, тут, думаю, уже понятно. Некая детальная информация. Например, сюда я отнесу "вход в систему".
Пользователь вводит логин/пароль. Система проверят логин/пароль. Система считает пользователя зарегистрированным. (с точки зрения технической реализации - "открывает сессию" и выдает cookie).
Данный вариант использования не приводит пользователя к Цели. Т.е. не позволяет выполнить какое-либо действие, полезное для пользователя. Ведь регистрироваться ради регистрации - глупо.
Раскроем книжку, почитаем что я еще хотел вам
Триггер некое событие, которое приводит в действие вариант использования. Обычно это будет "пользователь ввел нужную строку запроса в браузере или выбрал соответствующий пункт меню.
Предусловия условия, которые априори выполнены при старте этого Варианта использования. Обычно это будет "пользователь зарегистрирован в системе".
Основной сценарий последовательность успешных шагов, приводящая Актера к Цели.
Расширения описания исключительных ситуаций по шагам. Т.е. если шаги "основного сценария" были не успешны.
Если я буду ссылаться явно на какой-то вариант использования, я буду использовать подчеркивание. Но, вроде, у меня такого не предвидится.
Еще пара слов о соглашениях об именах.
Если я буду описывать вариант использования, то заголовок в блоге у него будет следующий:
UC: <роль>: <название>.
Список ролей смотри в прошлых сообщениях.
Ну... теперь осталось описать шаблон, которого я буду стараться придерживаться.
Комментариев нет:
Отправить комментарий