Use Cases: обзор метода

Текстовая расшифровка одного из уроков курса Введение в профессию аналитика.

На ближайших трёх вебинарах мы познакомимся с тремя наиболее популярными методами разработки пользовательских требований. Я надеюсь, вы понимаете, что за один вебинар изучить ни один из этих методов невозможно, потому что нужно много практики. Я свою задачу вижу в том, чтобы только познакомить вас с этими методами — в надежде, что если вы будете их использовать, то вы где-то более углубленно их изучите. Либо изучите по книгам, либо пройдёте курсы. По каждому из этих методов есть множество курсов. Моя задача — дать вам обзор этих методов, чтобы вы понимали, в чём их суть, и в каких условиях их лучше всего применять.

Сегодня мы рассмотрим первый метод, самый популярный и лучше всего проработанный — это метод вариантов использования.

Оригинальный английский термин для «варианта использования»: use case. Его по-разному пытались переводить. «Вариант использования» — это дословный перевод, в лоб. Но этот вариант перевода используется очень часто.

Иногда в некоторых книгах используют для перевода слово «прецедент». Это интересная история. Вообще, прецедент — это неграмотный перевод для use case. Термин use case используется в англоязычной юридической литературе, и там означает судебный прецедент. Кто-то из переводчиков использовал слово «прецедент» при переводе одной из книг об этом методе. Получился, с одной стороны, не очень грамотный перевод, а с другой, мне кажется, очень удачный, потому что слово «прецедент» в нашей терминологии в IT больше ничего не обозначает. И если бы этот термин прижился, было бы очень хорошо.

Но бы будем использовать, тем не менее, термин «вариант использования». Он, может быть, более расплывчатый и допускает разные толкования, но он уже устоялся.

Мы обзорно посмотрим на этот метод и в домашнем задании к вебинару попробуем его применить. Самая лучшая книга по вариантам использования — Alister Cockburn, «Writing Effective Use Cases». В русском переводе: Алистер Коберн, «Современные методы описания функциональных требований к системам». Здесь переводчик, с моей точки зрения, выпендрился. Потому что и метод не такой уж современный, и требования не только функциональные, и метод предназначен не только для описания, но и для анализа. Но, тем не менее, книга на русском языке продолжает издаваться в таком переводе, и вышло уже несколько изданий. В любом случае, рекомендую её почитать, даже если вы не планируете использовать именно этот метод. Там очень много полезной информации о том, как работать с требованиями. Конечно, всё это в привязке к методу use case, но, как мы увидим из этого курса, отдельные элементы метода вариантов использования можно использовать и в других методах.

Эта картинка из книги Коберна. В его представлении use case — это такая втулка, на которой крутится колесо требований. То есть, описав правильно варианты использования, мы сможем в дальнейшем заниматься проработкой всех видов требований. Или, другими словами, с помощью метода юзкейсов можно анализировать и разрабатывать все виды требований. Здесь перечислены те виды требований, которые были актуальны на момент написания книги: требования к производительности, к пользовательскому интерфейсу, бизнес-правила и так далее. Вообще, Коберн рассматривает этот метод как основной метод проработки всех видов требований. Вы видите, что здесь приведены не только функциональные, но и нефункциональные виды требований. Это ещё одна претензия к названию книги в русском переводе.

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

При использовании этого метода, прежде всего, нужно выявить и описать следующие элементы. На диаграмме вариантов использования, которая здесь представлена, нарисованы графически основные элементы:

• действующие лица или акторы (actor),

• цели действующих лиц, которые они преследуют по отношению к системе (которые, собственно, и называют обычно use case),

• и ещё один важный элемент, о важности которого иногда забывают — это границы системы.

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

Это первая часть анализа. А сами use case или варианты использования, как написано в книге Коберна,- это сценарии. Сценарии взаимодействия акторов с системой и между собой (с другими акторами). Это как раз пошаговое описание того, кто что делает, и что при этом получает. Мы сейчас посмотрим, что за этим стоит.

Мне нравится такая метафора, высказанная одним из коллег, что когда вы описываете варианты использования, часто бывает полезно представлять вашу систему в виде шкафа с кнопками. Примерно так автоматизированные системы и выглядели лет 40 назад, когда их делали на больших машинах, и когда интерфейс был кнопочный. Пользователь по отношению к системе (не обязательно непосредственный пользователь, а какое-то действующее лицо, бизнес-пользователь) хочет от системы получить какой-то результат. И эту диаграмму вариантов использования, которая была на предыдущем слайде, можно представить так: вот человек и вот кнопки, которые ему можно в системе нажимать, чтобы достигать своих целей. Очень полезно держать в голове такую модель, когда мы выявляем цели акторов по отношению к системе.

Метод применяется, как правило, именно в такой последовательности, хотя она может и меняться. Она соответствует тем четырем элементам, которые я перечислил. Для того, чтобы описать требования в таком виде, мы должны:

1. Выявить этих действующих лиц, либо роли (мы поговорим сейчас о том, в чём разница между действующими лицами и ролями, и на каких уровнях они появляются);

2. Выявить их цели по отношению к системе;

3. Описать основные сценарии достижения этих целей (как добиться чтобы «всё было хорошо» при нажатии на кнопку);

4. И, наконец, четвёртый шаг состоит в описании так называемых альтернативных сценариев — выявлению ситуаций, когда что-то идёт не так, и описанию поведения системы, как она должна на эти ситуации реагировать. (Как программисту и аналитику, мне эта часть метода представляется наиболее ценной.)