Эффективные юзкейсы (UseCase) по Коберну
Книга Коберна «Написание эффективных вариантов использования» (или "Современные методы описания функциональных требований к системам" - "Writing Effective Use Cases") является одной из основных книг, рекомендованных для прочтения системному аналитику. Да не то, чтобы прочтения - изучения!
Ниже знания из книги, подытожены мною.
Данная книга познавательна, но немного непонятна. Непонятна в силу того, что зачастую автор приводил примеры из сферы, не совсем мне понятной и поэтому не всегда была понятна логика составления юзкейсов в примерах (я работаю с крупными сайтами, а не программным обеспечением).
Но в целом книга весьма занимательна. Увидев таблички юзкейсов с их альтернативными путями, я вспомнила, как приблизительно 4 месяца назад делала точно такое же задание. Тогда у меня перед глазами был образец, и по нему я должна была описать поведение 3 типов пользователей сайта. Ох и наигралась я с этими юзкейсами!
Для тех, кто не в теме, пример юзкейса (UseCase):
Основной поток - Авторизация Пользователя
Что я вынесла из книги:
· К началу проектирования:
o Определить, что входит в область действий проектирования (у автора - составление таблицы «Внутри / Вне»
o Определить цели и приоритеты действующих лиц проектируемой системы
o Кратко описать цели действующих лиц (юзкейс высокого уровня)
o Создавая юзкейсы не стоит сразу вдаваться в детали и мелочи. Важно составить список всех возможных юзкейсов, утвердить его с коллегами, а уже потом расписывать их.
o Выявить все возможные условия неудачи в сценарии.
· По юзкейсам:
o Структура написания юзкейсов. В обычном сценарии 3-9 шагов. Если больше - имеет смысл пересмотреть юзкейс и либо выделить в нем подчиненный сценарий, либо сократить его путем интеграции более мелких шагов.
o Написание. Использовать настоящее время, глагол действия. Описывать, как действующее лицо успешно достигает цели.
o Уровни целей юзкейсов (высокие, пользовательские, ниже пользовательских). Ориентируемся на пользовательские. Чтобы подняться выше, задаем вопрос «Почему». Чтобы опуститься ниже, задаем вопрос «Как?». В итоге у нас должен получится юзкейс высокого уровня, который будет включать юзкейсы нижних уровней.
o Область проектирования, в частности, «черный ящик» и «прозрачный ящик». До этого не сталкивалась с подобными определениями.
o В юзкейсах должны быть описаны гарантии (что получит пользователь в случае успеха и неудачи выполнения сценария).
o Ограничение использования слова «если». Писать не «система проверяет заполненость полей. Если А, то Б. Если В, то Г». А «Система подтверждает заполненость полей и выполняется А. Иначе, выполняется Б».
Автор удобно организовал книгу тем, что вынес все самое главное в виде памяток в 21-23 главы, в которых по самому лишь оглавлению можно вспомнить весь материал. Лично мне понравилась памятка 18-«Рецепт из 12 шагов», которая кратко описала всю суть книги.
Ну и, естественно, остались непонятные сейчас моменты. Например, это понятие «предельные варианты использования».
Я считаю, что автор хорошо описал логику и этапы работы с вариантами использования, но лично его способ написания юзкейсов (в виде таблицы) мне не нравится (громоздок, не всегда удобен).
Этому описанию уже более полугода. Несомненно, за это время я многому научилась в системной аналитике. Но старина Коберн выручал не раз. В последнее время на фирме начали использовать его User-Goal-Matrix, которая помогает выявить всех пользователей продукта, их сценарии поведения, части проекта.
Ниже знания из книги, подытожены мною.
Данная книга познавательна, но немного непонятна. Непонятна в силу того, что зачастую автор приводил примеры из сферы, не совсем мне понятной и поэтому не всегда была понятна логика составления юзкейсов в примерах (я работаю с крупными сайтами, а не программным обеспечением).
Но в целом книга весьма занимательна. Увидев таблички юзкейсов с их альтернативными путями, я вспомнила, как приблизительно 4 месяца назад делала точно такое же задание. Тогда у меня перед глазами был образец, и по нему я должна была описать поведение 3 типов пользователей сайта. Ох и наигралась я с этими юзкейсами!
Для тех, кто не в теме, пример юзкейса (UseCase):
Основной поток - Авторизация Пользователя
- Неавторизованный Пользователь переходит по URL <доменное_имя_сайта>/admin или <доменное_имя_сайта>/admin/<страница_административного_интерфейса> на страницу входа в административный интерфейс.
- С. демонстрирует поля ввода логина и пароля, а также текст, содержащий контактные данные администратора сайта (данные задаются в коде).
- П. заполняет поля логин и пароль и нажимает клавишу "Enter" или кнопку "Войти".
- После ввода правильного логина и пароля П. авторизуется и перенаправляется на страницу административного интерфейса, URL которой был введен в пункте 1 текущего потока
Что я вынесла из книги:
· К началу проектирования:
o Определить, что входит в область действий проектирования (у автора - составление таблицы «Внутри / Вне»
o Определить цели и приоритеты действующих лиц проектируемой системы
o Кратко описать цели действующих лиц (юзкейс высокого уровня)
o Создавая юзкейсы не стоит сразу вдаваться в детали и мелочи. Важно составить список всех возможных юзкейсов, утвердить его с коллегами, а уже потом расписывать их.
o Выявить все возможные условия неудачи в сценарии.
· По юзкейсам:
o Структура написания юзкейсов. В обычном сценарии 3-9 шагов. Если больше - имеет смысл пересмотреть юзкейс и либо выделить в нем подчиненный сценарий, либо сократить его путем интеграции более мелких шагов.
o Написание. Использовать настоящее время, глагол действия. Описывать, как действующее лицо успешно достигает цели.
o Уровни целей юзкейсов (высокие, пользовательские, ниже пользовательских). Ориентируемся на пользовательские. Чтобы подняться выше, задаем вопрос «Почему». Чтобы опуститься ниже, задаем вопрос «Как?». В итоге у нас должен получится юзкейс высокого уровня, который будет включать юзкейсы нижних уровней.
o Область проектирования, в частности, «черный ящик» и «прозрачный ящик». До этого не сталкивалась с подобными определениями.
o В юзкейсах должны быть описаны гарантии (что получит пользователь в случае успеха и неудачи выполнения сценария).
o Ограничение использования слова «если». Писать не «система проверяет заполненость полей. Если А, то Б. Если В, то Г». А «Система подтверждает заполненость полей и выполняется А. Иначе, выполняется Б».
Автор удобно организовал книгу тем, что вынес все самое главное в виде памяток в 21-23 главы, в которых по самому лишь оглавлению можно вспомнить весь материал. Лично мне понравилась памятка 18-«Рецепт из 12 шагов», которая кратко описала всю суть книги.
Ну и, естественно, остались непонятные сейчас моменты. Например, это понятие «предельные варианты использования».
Я считаю, что автор хорошо описал логику и этапы работы с вариантами использования, но лично его способ написания юзкейсов (в виде таблицы) мне не нравится (громоздок, не всегда удобен).
Этому описанию уже более полугода. Несомненно, за это время я многому научилась в системной аналитике. Но старина Коберн выручал не раз. В последнее время на фирме начали использовать его User-Goal-Matrix, которая помогает выявить всех пользователей продукта, их сценарии поведения, части проекта.