Свободный формат

Свободный формат предполагает описание действий пользователя и системы в повествовательном стиле, например: "Менеджер запрашивает у Системы список заказов за период. Система отображает на экране найденные заказы данного Менеджера с указанием их основных атрибутов". Свободный стиль допускает использование конструкций "Если то". "Если Менеджер имеет полномочия Начальника Отдела, то Система предоставляет возможность просмотра заказов всех менеджеров этого отдела".

Табличные представления варианта использования

Иногда представляется удобным помещать сценарии вариантов использования в таблицу, как это показано ниже. Информация при этом принимает более структурированный вид.

Таблица в 2 колонки:
Актор		Действие
Пользователь		Формирует запрос на поиск заказов
Система		Отображает список заказов
Пользователь		Выбирает требуемый заказ
Система		Показывает подробную информацию по заказу
Таблица в 3 колонки:
№ шага	Пользователь		Система
1	Делает запрос на поиск заказов		Отображает список заказов
2	Выбирает требуемый заказ		Показывает подробную информацию по заказу

Выбор формы описания варианта использования

При выборе формы и степени подробности варианта использования следует учитывать такие факторы, как:

• Размеры проекта,

• Важность проекта и варианта использования,

• Традиции, сложившиеся в коллективе "Заказчик-Разработчик".

Для небольшого проекта вряд ли будет целесообразным применять описания вариантов использования в развернутом формате, достаточно использовать краткую форму свободного стиля. Для проекта, в котором задействовано более десяти участников, в котором возникают проблемы разбиения на микро-коллективы, координации участников, следует выбрать более формализованный и более подробный табличный вариант.

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

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

Визуальные методы описания

Вербальные описания вариантов использования системы, рассмотренные выше, на сегодня являются стандартом де-факто для формулировки соглашения между Заказчиком и Исполнителем. Если обе стороны готовы выделить достаточное количество времени на внимательный и всесторонний анализ требований к системе и на начальной фазе ее создания сформулировали 80% всех возможных сценариев использования системы на понятном сторонами языке - значит, ключевые риски создания системы - риск различного понимания проблемы и риск размытия границ во многом преодолены.

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

Чтобы облегчить процесс формулировки и понимания требований для Заказчика, существует ряд приемов. Во-первых, требования можно формулировать на разных уровнях абстракции.

Хорошим подспорьем в решении задачи является применение визуальных средств описания требований. Как известно, у большинства людей правополушарное (образное) мышление позволяет воспринимать информацию в разы и порядки более ускоренном темпе, чем левополушарное (вербальное).

На сегодня в арсенале аналитика существуют десятки методик, языков, визуальных представлений, позволяющих моделировать требования к системе. При создании информационных систем стандартом де-факто является универсальный язык моделирования, UML

Как определить целесообразность использования тех или иных приемов, методик, языков моделирования при анализе требований? Здесь можно предложить три практические рекомендации.

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

Во-вторых, анализ требований должен находить ответ на то, ЧТО делает система, абстрагируясь от деталей реализации, т.е. того, КАК она это делает. Поэтому, допустим, диаграмма взаимодействия объектов, реализующих тот или иной вариант использования, можно рассматривать скорее, как иллюстрацию внутреннего устройства системы, полезную для программиста, чем модель для заказчика.

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