Текстовая расшифровка одного из уроков курса Введение в профессию аналитика.
На ближайших трёх вебинарах мы познакомимся с тремя наиболее популярными методами разработки пользовательских требований. Я надеюсь, вы понимаете, что за один вебинар изучить ни один из этих методов невозможно, потому что нужно много практики. Я свою задачу вижу в том, чтобы только познакомить вас с этими методами — в надежде, что если вы будете их использовать, то вы
Сегодня мы рассмотрим первый метод, самый популярный и лучше всего проработанный — это метод вариантов использования.
Оригинальный английский термин для «варианта использования»: use case. Его
Иногда в некоторых книгах используют для перевода слово «прецедент». Это интересная история. Вообще, прецедент — это неграмотный перевод для use case. Термин use case используется в англоязычной юридической литературе, и там означает судебный прецедент.
Но бы будем использовать, тем не менее, термин «вариант использования». Он, может быть, более расплывчатый и допускает разные толкования, но он уже устоялся.
Мы обзорно посмотрим на этот метод и в домашнем задании к вебинару попробуем его применить. Самая лучшая книга по вариантам использования — Alister Cockburn, «Writing Effective Use Cases». В русском переводе: Алистер Коберн, «Современные методы описания функциональных требований к системам». Здесь переводчик, с моей точки зрения, выпендрился. Потому что и метод не такой уж современный, и требования не только функциональные, и метод предназначен не только для описания, но и для анализа. Но, тем не менее, книга на русском языке продолжает издаваться в таком переводе, и вышло уже несколько изданий. В любом случае, рекомендую её почитать, даже если вы не планируете использовать именно этот метод. Там очень много полезной информации о том, как работать с требованиями. Конечно, всё это в привязке к методу use case, но, как мы увидим из этого курса, отдельные элементы метода вариантов использования можно использовать и в других методах.
Эта картинка из книги Коберна. В его представлении use case — это такая втулка, на которой крутится колесо требований. То есть, описав правильно варианты использования, мы сможем в дальнейшем заниматься проработкой всех видов требований. Или, другими словами, с помощью метода юзкейсов можно анализировать и разрабатывать все виды требований. Здесь перечислены те виды требований, которые были актуальны на момент написания книги: требования к производительности, к пользовательскому интерфейсу,
Сначала давайте рассмотрим основные элементы, из которых состоит метод. На слайде приведена картинка, которая в UML называется диаграммой вариантов использования. Наверняка вы с ней имели дело. Вообще, большинство аналитиков знакомо с этим методом, но, тем не менее, мы освежим его в памяти и попробуем понять, как он применим к
При использовании этого метода, прежде всего, нужно выявить и описать следующие элементы. На диаграмме вариантов использования, которая здесь представлена, нарисованы графически основные элементы:
Когда мы применяем этот элемент для описания требований, мы описываем их именно в таких терминах. Мы выявляем перечень действующих лиц, затем мы выявляем их цели по отношению к системе, то есть цели, которые они достигают с помощью использования системы, и мы ещё указываем, какие из этих целей решаются в рамках системы. Почему это важно? Потому что некоторые цели, бывает, находятся за ее границами.
Это первая часть анализа. А сами use case или варианты использования, как написано в книге Коберна,- это сценарии. Сценарии взаимодействия акторов с системой и между собой (с другими акторами). Это как раз пошаговое описание того, кто что делает, и что при этом получает. Мы сейчас посмотрим, что за этим стоит.
Мне нравится такая метафора, высказанная одним из коллег, что когда вы описываете варианты использования, часто бывает полезно представлять вашу систему в виде шкафа с кнопками. Примерно так автоматизированные системы и выглядели лет 40 назад, когда их делали на больших машинах, и когда интерфейс был кнопочный. Пользователь по отношению к системе (не обязательно непосредственный пользователь, а
Метод применяется, как правило, именно в такой последовательности, хотя она может и меняться. Она соответствует тем четырем элементам, которые я перечислил. Для того, чтобы описать требования в таком виде, мы должны:
1. Выявить этих действующих лиц, либо роли (мы поговорим сейчас о том, в чём разница между действующими лицами и ролями, и на каких уровнях они появляются);
2. Выявить их цели по отношению к системе;
3. Описать основные сценарии достижения этих целей (как добиться чтобы «всё было хорошо» при нажатии на кнопку);
4. И, наконец, четвёртый шаг состоит в описании так называемых альтернативных сценариев — выявлению ситуаций, когда
Практический анализ ПО с моделированием на UML От 24 000 руб. | |
Введение в профессию аналитика 2 900 руб. | |
Введение в профессию аналитика (демо) Бесплатно | |
Вебинары Сообщества Аналитиков Бесплатно | |
SQL для непрограммистов (СЕРТИФИКАТ) 999 руб. | |
![]() | SQL для непрограммистов Бесплатно |