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

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

Когда варианты использования документируют бизнес-процессы организации, рассматриваемая система (SuD, system under discussion) и является этой организацией. Участники — это акционеры компании, заказчики, поставщики, органы государственного управления. Основные действующие лица — это заказчики компании и, возможно, их поставщики.

Если варианты использования описывают требования к поведению части программного обеспечения, SuD — это компьютерная программа. Участники — это пользователи программы, компания, владеющая ею, органы государственного управления и другие компьютерные программы. Основное действующее лицо — это сидящий за компьютером пользователь или другая компьютерная система.

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

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

■ Область действия (Scope): какова на самом деле рассматриваемая система?.

■ Основное действующее лицо (Primary actor): у кого есть цель?.

■ Уровень (Level): какой уровень имеет эта цель?.

Далее следуют примеры вариантов использования. Части варианта использования описаны в следующей главе. А сейчас запомните определения:.

■ Действующее лицо (Actor): кто-то (или что-то), обладающий поведением.

■ Участник (Stakeholder): кто-то (или что-то), проявляющий интерес к поведению рассматриваемой системы (SuD).

■ Основное действующее лицо (Primary actor): участник (некто или нечто), инициирующий взаимодействие с SuD для достижения некоторой цели.

■ Вариант использования (Use case): соглашение относительно поведения SuD.

■ Область действия (Scope): идентифицирует рассматриваемую систему.

■ Предусловия и гарантии (Preconditions and guarantees): то, что должно быть истинным до и после реализации варианта использования.

■ Основной сценарий (Main success scenario): вариант, в котором не возникает никаких ошибок.

■ Расширения (Extensions): различные отклонения от основного сценария.

■ Номера расширений соответствуют номерам шагов основного сценария,.

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

■ Когда один вариант использования ссылается на другой, последний подчеркивается.

В приведенных ниже примерах первый вариант использования описывает лицо, собирающееся купить некоторые ценные бумаги через Сеть. Чтобы обозначить, что данную цель можно достигнуть за один сеанс, я помечаю вариант использования как находящийся на уровне цели пользователя и снабжаю его ярлыком в виде символа уровня моря, 33.. Второй вариант использования описывает лицо, пытающееся получить компенсацию за автомобильную аварию. Эта цель требует более одного сеанса. Чтобы показать это, я помечаю вариант использования как находящийся на обобщенном уровне и снабжаю его ярлыком в виде другого символа — над уровнем моря, . Эти знаки объясняются в главе 5 и представлены на второй странице обложки.

Первый вариант использования описывает взаимодействие индивидуума с программой (PAF), выполняющейся на рабочей станции, подключенной к Интернету. Знак “черного ящика”, О, указывает, что рассматриваемая система является компьютерной. Второй вариант использования описывает взаимодействие индивидуума с компанией, которую я обозначаю символом здания, Ш. Использовать именно эти символы не обязательно, в то время как некоторые метки области действия и уровня в любом случае необходимы.

Ниже следуют варианты использования 1 и 2.

Вариант использования 1 Ш Покупка ценных бумаг через Интернет 33.

Основное действующее лицо: покупатель.

Область действия: персональные консультанты / финансовый пакет.

(PAF).

Уровень: цель пользователя.

Участники и интересы:.

Покупатель — хочет купить ценные бумаги, причем они должны автоматически попасть в портфель PAF.

Биржевое агентство — хочет получить полную информацию.

о покупке.

Предусловие: программа PAF у пользователя уже открыта.

Минимальные гарантии: в наличии достаточно регистрационной информации, чтобы PAF могла обнаружить несоответствие и запросить у пользователя дополнительные данные.

Гарантия успеха: удаленный web-сайт подтвердил покупку; регистрационные файлы и портфель пользователя обновлены.

Основной сценарий:.

1.

Покупатель выбирает покупку ценных бумаг через Сеть.

2.

PAF получает от пользователя адрес нужного сайта (E*Trade, Schwab и т. д.).

3.

PAF подключается к сайту, сохраняя контроль над процессом.

4.

Покупатель выбирает и покупает ценные бумаги на данном сайте.

5.

PAF перехватывает ответы web-сайта и обновляет портфель покупателя.

6.

PAF показывает покупателю новое состояние портфеля.

Расширения:.

2а. Покупатель запросил web-сайт, не поддерживаемый PAF.

2а 1. Система получает от покупателя новое предложение с возможностью отменить вариант использования.

За. Отказ любого рода в Сети во время установки:.

3а1. Система сообщает покупателю о неудаче, дает совет и возвращается на предыдущий шаг.

За2. Покупатель либо отказывается продолжать этот вариант использования либо делает новую попытку.

4а. Во время транзакции покупки компьютер выходит из строя или выключается:.

4а 1. (Что здесь нужно делать?).

4Ь.web-сайт не подтверждает покупку, а задерживает ее:.

4Ы. PAF регистрирует задержку, устанавливает таймер, чтобы запросить покупателя о выходе.

5а. web-сайт не возвращает необходимую информацию о покупке:.

5а 1. PAF регистрирует отсутствие информации о том, совершилось ли в портфеле покупателя обновление для зависшей покупки.

Вариант использования 2 # Получить страховую компенсацию за автомобильную аварию Р.

Основное действующее лицо: истец.

Область действия: страховая компания (MylnsCo).

Уровень: обобщенный Участники и интересы:.

Истец — хочет получить максимально возможную сумму.

Компания MylnsCo — хочет заплатить как можно меньше.

Министерство страхования — хочет убедиться, что соблюдены все нормы и правила.

Предусловие: отсутствует.

Минимальные гарантии: MylnsCo регистрирует заявление и все действия.

Гарантия успеха: истец и MylnsCo приходят к соглашению о сумме.

страхового возмещения. Истец получает оговоренную сумму.

Триггер: истец представляет заявление на рассмотрение.

Основной сценарий:.

1.

Истец представляет на рассмотрение заявление с обоснованием.

2.

Страховая компания проверяет законность страхового полиса истца.

3.

Страховая компания назначает агента для расследования страхового случая.

4.

Страховая компания проверяет, укладываются ли все детали в нормативы полиса.

5.

Страховая компания выплачивает истцу страховое возмещение и закрывает дело.

Расширения:.

1а. Предоставленные данные не полны:.

1 а 1. Страховая компания запрашивает недостающую информацию.

1а2. Истец предоставляет недостающую информацию.

2а. Полис истца недействителен:.

2а1. Страховая компания отклоняет заявление, извещает истца, документирует все действия и прекращает дело.

За. На этот момент нет свободных агентов.

3а1. (Что в этом случае делает страховая компания?).

4а. Обстоятельства аварии противоречат основным правилам полиса:.

4а1. Страховая компания отклоняет заявление, извещает истца, документирует все действия и прекращает дело.

4Ь. Обстоятельства аварии противоречат второстепенным правилам полиса: 4Ы. Страховая компания начинает переговоры с истцом относительно суммы платежа.

Большинство вариантов использования взяты из реальных проектов, и я старался не подправлять их (кроме добавления ярлыков области действия и уровня, если их не было). Мне хочется, чтобы вы увидели практические примеры, а не созданные для классной комнаты. У людей редко хватает времени, чтобы написать варианты использования по форме, в полном объеме, да еще отредактировать их. Обычно их делают лишь “достаточными”, а именно это и необходимо. Я показываю жизненные примеры, потому что создать совершенный вариант использования удается редко. Даже я не часто могу написать идеальный вариант использования.

Вариант использования 3 написал Торфин Аас из Центрального банка Норвегии для своего коллеги, представителя пользователя и для себя самого. Он демонстрирует, как можно изменить форму, сохранив ценность. Автор внес в документ дополнительный бизнес-контекст, иллюстрируя работу приложения в течение рабочего дня. Это практично, так как избавляет от необходимости писать отдельный документ, описывающий бизнес-процесс. Это никого не запутало и увеличило информативность для заинтересованных лиц.

Вариант использования 3 О Зарегистрировать привезенную коробку ^.

П — приемщик.

Р — регистратор.

Основное действующее лицо: П.

Область действия: программа регистрации ночных поступлений Уровень: цель пользователя Основной сценарий:.

1.

П получает и открывает коробку (идентификатор (ID) коробки, сумки с ID), полученную от транспортной компании (ТК).

2.

П проверяет, совпадает ли ID коробки с зарегистрированными ID ТК.

3.

П, возможно, подписывает бумагу посыльного.

4.

П регистрирует поступление коробки в системе, которая хранит:.

ID П.

дату, время ID коробки.

название транспортной компании количество сумок (с ID сумок?).

.

5.

П извлекает сумки из коробки, кладет в тележку, доставляет Р. Расширения:.

2а. ID коробки не соответствует ID транспортной компании.

4а. Срабатывает пожарная сигнализация и прерывает регистрацию.

4Ь. Выходит из строя компьютер.

Оставьте деньги на столе и подождите, когда компьютер заработает. Вариации:.

4. С персональным ID или без него.

4”. С оценкой или без оценки. .

5. Поставляет сумки в коробке.

1.2. У каждого свой вариант использования.

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

■ Описать рабочий процесс в бизнесе.

■ Сконцентрировать усилия на обсуждении принципиальных требований к разрабатываемой системе, а не на подробном их описании.

■ Описать функциональные требования к системе.

■ Документировать проект системы.

■ Написать документ в небольшой компактной группе или в большой распределенной группе.

В каждой ситуации требуется свой стиль. Ниже приведены основные формы описания, диктуемые заданной целью.

■ Компактная группа, собирающая требования, или более крупная группа, обсуждающая требования к разрабатываемой системе, пишет бессистемно, в противоположность вариантам использования, созданным по полной программе, которые принадлежат более многочисленной, географически распре деленной команде. Бессистемная (casual) форма в целях экономии времени упрощает шаблон варианта использования (подробнее см. ниже). Варианты использования 1-3 написаны по полной форме (fully dressed) с использованием полного шаблона варианта использования и схемы нумерации шагов. Вариант использования 4 — это пример бессистемной формы.

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

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

■ Лицо, формулирующее требования для проектируемой системы, компьютерной либо для бизнеса, пишет варианты использования типа “черный ящик". При этом внутренняя структура системы не обсуждается. Разработчики бизнес-процессов описывают варианты использования типа “прозрачный ящик", показывающие, как в компании или организации протекают внутренние процессы. Группа технической разработки может сделать то же самое, чтобы документировать эксплуатационный контекст системы, которую ей предстоит разработать, а также создать варианты использования типа “прозрачный ящик” для описания функционирования только что разработанной системы.

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

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

Вы можете протестировать себя на предмет составления вариантов использования в этой главе. Варианты использования 1, 3 и 5 были написаны с целью создания требований к системе, поэтому они полностью соответствуют форме, имеют тип “черный ящик” для системы и уровень цели пользователя. Вариант использования 4 того же типа, но написан произвольно. Вариант использования 2 с контекстной установкой, предназначенный для документирования бизнес-процесса, написан по полной форме, имеет тип “черный ящик” и сложный уровень.

Самое большое различие между форматами вариантов использования заключается в их соответствии полной форме. Рассмотрим совершенно разные ситуации:.

■ Команда работает над программным обеспечением для большого, критически важного для организации проекта. Разработчики решили, что дополнительная процедура стоит затрат, поэтому (а) шаблон варианта использования должен быть длиннее и подробнее, (Ь) члены пишущей команды должны писать в одном стиле, чтобы сократить количество двусмысленных и непонятных мест, (с) варианты использования следует тщательно проверять на предмет пропусков и двусмысленностей. Учитывая низкую устойчивость к ошибкам, они также решили сократить допустимые отклонения при написании варианта использования.

■ Команда из 3-5 человек разрабатывает систему, самая серьезная неисправность которой заключается в потере комфорта. С ней легко справиться, позвонив по телефону специалисту. Разработчики посчитали соблюдение формальностей напрасной тратой времени, сил и денег. Поэтому они выбрали: (а) более простой шаблон, (Ь) более свободный стиль изложения, (с) меньшее количество менее строгих проверок. Обнаружение ошибок и упущений в тексте варианта использования перекладывается на другие механизмы проекта, возможно, на обсуждение среди коллеги пользователей. Разработчикам позволено допускать больше ошибок в письменном общении между собой, а потому менее формально подойти к созданию вариантов использования при большем разнообразии неформальных отношений между людьми.

И то, и другое допустимо. Такой выбор должен предоставляться для каждого проекта. Это наиболее важный урок, который я как методист усвоил за последние пять лет. Конечно, мы годами говорили, что не все можно мерить одной меркой. Но как конкретизировать это, осталось тайной.

Не нужно гнаться за точностью и строгостью, если в них нет большой необходимости — на это уйдет много времени и сил. Как написал Джим Сэвайер, участвуя в дискуссии по электронной почте, “...пока шаблоны не станут такими формальными, что вы потеряетесь в рекурсивном спуске, который, как червоточины, пронизывает пространство проекта. Если это начнется, я велю разобрать эту сомнительную конструкцию до основания и стану рассказывать истории и писать на салфетках”.

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

Вариант использования 4 В Совершить покупку (бессистемная версия) Р.

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

В любой момент, предшествующий получению товаров, Инициатор запроса может изменить или отменить запрос. При отмене запрос выводится из любой активной обработки (удаляется из системы?). Снижение цены оставляет его неизменным. При повышении цены он снова отсылается Утверждающему лицу.

Вариант использования 5 В Совершить покупку (полная версия) Р.

Основное действующее лицо: инициатор запроса.

Цель в контексте: инициатор запроса покупает что-нибудь с помощью зтой системы, получает заказ. Не включена оплата заказа.

Область действия: бизнес — общий механизм совершения покупки (электронный и обычный), как его представляют в компании.

Уровень: обобщенный Участники и интересы:.

Инициатор запроса: хочет получить то, что заказал, без особых хлопот. Компания: позволяя сделать необходимые покупки, хочет проконтролировать расходы.

Поставщик: хочет, чтобы ему заплатили за все доставленные товары. Предусловие: отсутствует.

Минимальные гарантии: каждый отосланный заказ одобрен законным.

уполномоченным лицом. Заказ отслеживается, чтобы компании.

присылали счета только за действительно доставленные товары.

Гарантии успеха: инициатор запроса получает товары, правильный.

бюджет готов к дебетованию.

Триггер: инициатор запроса решает что-то купить.

Основной сценарий:.

1.

Инициатор запроса: инициирует запрос.

2.

Утверждающее лицо: проверяет наличие денег в бюджете, цены товаров, завершает оформление запроса для подачи.

3.

Покупатель: просматривает содержимое памяти, ищет лучшего поставщика товаров.

4.

Уполномоченное лицо: удостоверяет подпись утверждающего лица.

5.

Покупатель: завершает формирование запроса для заказа. инициирует денежный перевод поставщику.

6.

Поставщик: доставляет товары приемщику, получает квитанцию о доставке (вне сферы проектируемой системы).

7.

Приемщик: регистрирует доставку, отправляет товары инициатору запроса.

8.

Инициатор запроса: отмечает, что заказ доставлен.

Расширения:.

1а. Инициатор запроса не знает поставщика или цены — пропустить эти части бланка и продолжить.

1Ь. В любой момент до приема товаров инициатор запроса может изменить или отменить запрос:.

При отмене запроса прекращается его активная обработка (удалить из системы?).

Снижение цены не затрагивает обработку запроса.

При повышении цены запрос снова отправляется утверждающему лицу.

2а. Утверждающее лицо не знает поставщика или цену — оставить пропуск и дать покупателю его заполнить или забрать.

2Ь. Утверждающее лицо не является руководителем покупателя — не страшно, если утверждающее лицо подписывает запрос.

2с. Утверждающее лицо отклоняет запрос — вернуть инициатору запроса для изменения или аннулирования.

За. Покупатель находит товары в памяти — отослать их, уменьшить запрос на эту величину и продолжить.

ЗЬ. Покупатель заполняет пропущенные поля поставщика и цены — запрос повторно посылается утверждающему лицу.

4а. Уполномоченное лицо отказывает утверждающему лицу —.

возвратить запрос покупателю и прекратить его активную обработку. (Что это значит?).

5а. Запрос включает несколько поставщиков — покупатель осуществляет несколько денежных переводов.

5Ь. Покупатель объединяет несколько запросов — тот же процесс,.

но следует пометить, к какому запросу относится каждый денежный перевод.

6а. Поставщик не доставляет заказ вовремя — система сигнализирует о том, что заказ не доставлен.

7а. Частичная доставка — приемщик отмечает частичную доставку в денежном переводе и продолжает.

7Ь. Частичная доставка по переводу на несколько запросов: — приемщик записывает количество полученных товаров для каждого запроса и продолжает.

8а. Товары не те или не того качества — инициатор запроса отказывается от доставленных товаров (Что это значит?).

8Ь. Инициатор запроса ушел из компании — покупатель решает с руководителем инициатора запроса, назначить ли другого инициатора или возвратить товары и отменить запрос.

Список изменений в технологии и данных: отсутствуют.

Приоритет: различный Реализации: несколько Время реакции: различное Частота использования: 3 раза в день.

Канал для Основного действующего лица: браузер Интернета, почтовая.

система или равноценный механизм.

Второстепенные действующие лица: поставщик.

Каналы для второстепенных действующих лиц: факс, телефон,.

автомобиль.

Открытые вопросы:.

Когда отмененный запрос удаляется из системы?.

Чье разрешение нужно, чтобы отменить запрос?.

Кто может изменить содержание запроса?.

В каком объеме должна поддерживаться история изменений для запросов?.

Что происходит, когда инициатор запроса отказывается от доставленных товаров?.

В чем отличие требования от заказа?.

Как при размещении заказов происходит обращение к внутренней памяти и ее использование?.

Нельзя просто сказать, что мы пишем варианты использования для этого проекта. Любая рекомендация или определение процесса, типа “Напишите варианты использования”, будет недостаточной. Вариант использования, достоверный для одного проекта, не применим к другому. Кроме того, следует указать, применяются ли варианты использования по полной или бессистемной форме, какие части шаблона и форматы обязательны и каковы пределы допустимого отклонения разработчиков от формы.

Всестороннее обсуждение возможных отклонений и вариаций в проектах содержится в книге Software Development as a Cooperative Game, упоминавшейся в предисловии. Чтобы научиться писать варианты использования, не требуется подробное обсуледение. Что действительно необходимо, так это различать метод написания, качество варианта использования и стандарты проекта.

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

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

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

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

* Стив Эдолф:.

"Выявление" требований на новой территории.

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

Но что, если никто не знает, что должна делать система? Автоматизация процесса обычно изменяет сам процесс. В полиграфической промышленности недавно произошла одна из самых больших перемен со времен изобретения офсетной печати: появилась технология "непосредственно на печатную форму/непосредственно на пресс". Раньше установка печатного пресса была трудоемким, многошаговым процессом. Новая технология сделала промышленную полиграфию таким же простым делом, как распечатка документа, подготовленного в текстовом процессоре.

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

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

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

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

Затем погрузитесь в подробности одного варианта использования. Рассмотрите альтернативы. Учтите, что людям проще понять рассказ, и отложите формирование требований. Прочитайте шаг в варианте использования и задайтесь вопросом, что происходит, когда клиент предпочитает твердую, а не цифровую копию корректуры. Это проще, чем пытаться построить полную мысленную модель работы системы.

Наконец, вернитесь на поверхность. Что изменилось, после того как вы погрузились в детали? Настройте модель, затем повторите погружение для другого варианта использования.

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

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

Если вы пишете варианты использования как требования, имейте в виду:.

■ Это действительно требования. Не следует превращать их в другую форму требований к поведению системы. Написанные надлежащим образом, они точно описывают, что должна делать система.

■ Это не все требования. Они не детализируют внешние интерфейсы, форматы данных, бизнес-правила и сложные формулы. Они устанавливают только часть (возможно, треть) всех требований, которые вам необходимо собрать, очень важную, но лишь часть.

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

Следующая схема требований представляется мне весьма полезной. Я взял ее из шаблона, который Сьюзен Робертсон и консорциум Atlantic Systems Guild опубликовали на своем web-сайте и в книге Managing Requirements (1999). Их шаблон впечатляет своей полнотой, так что я урезал его до приведенной ниже схемы, которую использую как руководство. Однако она слишком длинна для большинства проектов, с которыми я сталкиваюсь, поэтому я стараюсь сокращать ее и далее. Каков бы ни был ее размер, она задает много интересных вопросов, которые в другом случае не возникли бы, например: “Как влияет человеческий потенциал на сбои системы? Какие политические соображения управляют каждым требованием?”.

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

Приемлемая схема требований.

Раздел 1. Цель и область действия.

1а. Что представляют собой общая область действия и цель?.

1Ь. Участники (Кого это интересует?).

1с. Что входит в область действия и что нет?.

Раздел 2. Используемые термины/Глоссарий.

Раздел 3. Варианты использования.

За. Основные действующие лица и их общие цели ЗЬ. Варианты использования для бизнес-процессов Зс. Системные варианты использования.

Раздел 4. Используемая технология.

4а. Какие технологические требования предъявляются к данной системе?.

4Ь. С какими системами будет взаимодействовать данная, каковы требования?.

Раздел 5. Другие требования 5а. Процесс разработки.

Q1. Кто участвует в проекте?.

Q2. Какие оценки проекта будут отражены (простой, ранний, быстрый или гибкий)?.

Q3. Какая обратная связь или прозрачность проекта нужна пользователям и организаторам?.

Q4. Что мы можем купить, что должны построить, с кем конкурируем?.

Q5. Какие еще существуют технологические требования (тестирование, установка и т.д.)?.

Q6. От чего зависит развитие проекта?.

5Ь. Бизнес-правила.

5с. Производительность.

5d. Эксплуатация, безопасность, документация.

5е. Использование (простота использования).

5f. Сопровождение и мобильность.

5д. Нерешенные или отложенные вопросы Раздел 6. Людские резервы, правовые, политические, организационные вопросы.

Q1. Как влияют людские резервы на функционирование системы?.

Q2. Какие существуют правовые и политические требования?.

Q3. Какие последствия для людей будет иметь создание этой системы?.

Q4. Каковы требования к обучению?.

Q5. Какое влияние оказывает система на окружающее сообщество?.

Вариантам использования посвящен только Раздел 3 требований. Это не вообще все требования, а только требования к поведению. Бизнес-правила, глоссарий, производительность, технологические требования и многое другое не попадает в категорию поведения. Для этих аспектов нужны собственные разделы (см. рис. 1.1).

Варианты использования как структура связей проекта.

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

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

Рис. 1.1. Модель требований в виде колеса.

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

1.4. Когда варианты использования повышают ценность проекта.

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

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

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

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

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

Без дискретизации шагов вариантов использования и обсуждения возможных отказов в режиме “мозгового штурма” многие условия ошибок остаются необнаруженными до тех пор, пока какой-нибудь программист не наткнется на них, кодируя фрагмент программы. При этом уже слишком поздно открывать новые функции и бизнес-правила. Эксперты по бизнесу, как правило, уже отключились от проекта, и время поджимает, так что программисты кодируют то, что им придет в голову в этот момент, вместо того чтобы выяснить, какое поведение требуется.

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

1.5. Дозируйте свою энергию.

Берегите свои силы или по крайней мере управляйте ими. Если вы стремитесь описать все детали за один раз, вы не успеете раскрыть все разделы за отведенное время. Если вы записываете только схему, чтобы начать и затем описать сущность каждого варианта использования, вы можете:.

* Дать участникам шанс внести необходимые коррективы и понять приоритеты на ранней стадии.

■ Позволить распределить работу между несколькими группами, увеличивая параллелизм и производительность.

Часто говорят: “Дайте мне обзор с расстояния 15 км”, “Дайте мне только схему” или “Детали добавим позднее”. Это означает: “Пишите пока не слишком подробно; детали добавим позже”.

Точность определяется тем, как много вы сумели сказать. Когда вы утверждаете: “Заказчик захочет взять напрокат видео”, вы не тратите слишком много слов, но действительно сообщаете важную информацию читателям. Когда вы показываете список всех целей, которые будет поддерживать проектируемая система, вы предоставляете участникам огромное количество информации, содержащееся в небольшом количестве слов.

Точность — это не то же самое, что правильность. Если кто-то говорит вам: “Число Пи равно 4,141592", он выдает высокую точность, однако далек от правильности. Если вам говорят: ”Пи равно 3", точность здесь невелика (маловато цифр), но это правильно в определенных пределах. Та же идея справедлива для вариантов использования.

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

Усилия, потраченные на описание вариантов использования, можно разделить на четыре стадии точности:.

1.

Действующие лица и цели. Перечислите действующих лиц и каждую из их целей, которые будет обеспечивать система. Проанализируйте правильность и полноту этого списка. Расставьте приоритеты и распределите цели между командами разработчиков и версиями. Теперьу вас есть функциональные требования к первому уровню точности.

2.

Краткое изложение варианта использования или основной сценарий. Для вариантов использования вы выбрали следование основному сценарию в общих чертах. Рассмотрите его в форме набросков, чтобы быть уверенным, что система действительно удовлетворяет интересам участников, о которых вы заботитесь. Это второй уровень точности функциональных требований. Этот материал довольно легко набрать, в отличие от двух следующих уровней.

3.

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

4.

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

Большая часть проектов требует немного времени и усилий. Поэтому управление уровнем точности, к которому вы стремитесь, должно быть приоритетом проекта. Я настоятельно рекомендую работать в описанном выше порядке.

1.6. Разминка с помощью повествовательного стиля.

Описание использования системы в повествовательном (narrative) стиле — это пример варианта использования в действии при определенных обстоятельствах. Это единичный, очень специфический пример того, как действующее лицо использует систему. Это даже не вариант использования, и в большинстве проектов он не доживает до официального документа “Функциональные требования”. Однако это очень полезный метод, который стоит того, чтобы вы о нем прочитали.

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

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

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

Такое описание не требует много усилий и места и вводит читателя в сам вариант использования легко и незаметно. Вот пример.

Описание использования: быстрое получение наличных денег.

Мэри с двумя дочками по пути на работу заезжает в центр медицинской помощи, подъезжает к банкомату, пропускает карточку через считывающее устройство, вводит свой PIN-код, выбирает режим FAST CASH (быстрое получение наличных денег) и вводит сумму, $35. Банкомат выдает банкноту в $20 и три по $5, а также квитанцию, показывающую остаток на ее счете после дебетования $35. После каждой транзакции FAST CASH банкомат восстанавливает экран, так что Мэри может не беспокоиться о том, что следующий пользователь получит доступ к ее счету. Мэри нравится FAST CASH, поскольку он не задает лишних вопросов, затягивающих общение. Она пользуется этим банкоматом, так как он выдает банкноты в $5, которые она использует для платы за медицинскую помощь, к тому же для получения наличности ей не приходится выходить из машины.

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

Описание использования — это не требования, скорее это ступень для создания более продуманных и обобщенных описаний требований. Описание использования служит отправной точкой для создания варианта использования. Сам по себе вариант использования — это сухой остаток описания использования, формула с обобщенными именами лиц, действующих в описании использования.

1.7. Упражнения.

Файл требований.

1.1.

Какие разделы файла требований зависят от вариантов использования, какие нет? Обсудите это с коллегой и подумайте, почему ваши ответы различны.

1.2.

Сделайте набросок других приемлемых требований, который можно распространить по корпоративной сети интранет. Уделите внимание структуре вашего подкаталога и соглашениям о календарных штампах (зачем вам понадобятся такие соглашения?).

Описание использования.

1.3.

Создайте два описания использования для банкомата, которым вы пользуетесь. Чем и почему они отличаются от примера описания, приведенного выше? Насколько важны эти различия для разработчиков, которые будут создавать систему?.

1.4.

Создайте описание использования для лица, идущего в новый фирменный салон видеопроката, чтобы взять напрокат оригинал фильма The Parent Trap.

1.5.

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