Участники проекта Chemical Tracking System проводили свой первый семинар, посвященный требованиям, чтобы выяснить, как химики будут использовать новую систему. На него были приглашены аналитик требований Лори, которая также выполняла функции ответственного за семинар, сторонник продукта от химиков Тим, еще два представителей от химиков Сэнди и Питер, а также ведущий разработчик Элен. Лори открыла семинар, поблагодарив присутствующих за участие, и сразу приступила к делу.
"Тим, Сэнди и Питер определили приблизительно 15 вариантов использования Chemical Tracking System, — сообщила она группе. — На этих семинарах мы рассмотрим их, чтобы выяснить, какую функциональность необходимо встроить в систему. Вы присвоили высший приоритет варианту использования - «Запрос химиката», и Тим уже составил его краткое описание, поэтому с него и начнем. Тим, как ты представляешь себе запрос химиката с помощью системы?»
«Прежде всего, — сказал Тим, — вам следует знать, что только те люди, у которых есть разрешение руководителей лабораторий, могут запрашивать химикаты».
«Ладно, это похоже на бизнес-правило, — ответила Лори. — Я начну составлять список бизнес-правил, поскольку, вероятно, будут и другие. Видимо, нам придется проверять, включен ли пользователь в утвержденный список лиц». Она также написала «пользователь идентифицирован» и «пользователю предоставлено право запрашивать химикаты» в разделе «Предварительные условия» списка, который она уже подготовила для варианта использования «Запрос химиката». «Есть еще какие-нибудь предварительные условия, которые должны быть выполнены до того, как пользователь получит возможность создать запрос?»
«Прежде чем запрашивать химикат у поставщика, я должна проверить, нет ли его на складке, — сказала Сэнди. — Когда я начну составлять запрос, текущая БД складских запасов должна быть подключена в онлайновом режиме, чтобы я не теряла времени попусту».
Лори добавила этот элемент в список предварительных условий. В течение следующих 30 минут она управляла обсуждением того, как участники семинара представляют себе процесс формирования запроса нового химиката. Ей понадобилось несколько списков, чтобы свести вместе информацию о предварительных условиях, выходных условиях, а также этапах взаимодействия пользователя и Chemical Tracking System. Лори поинтересовалась, чем будет отличаться вариант использования, когда пользователь запрашивает химикат у продавца, от того, когда он запрашивается на складе. А кроме того, какие проблемы при этом могут возникнуть и как система должна обрабатывать каждую ошибку? По истечении получаса удалось выработать четкое представление о том, как пользователь будет запрашивать химикат. Участники семинара были готовы обсуждать следующий вариант использования.
Люди используют системы ПО для выполнения необходимых задач, и в индустрии ПО наблюдается устойчивая тенденция к разработке ПО с повышенной практичностью (Constantine и Lockwood, 1999; Nielsent, 2000). При этом существует обязательное предварительное условие — необходимо знать, как клиенты планируют использовать продукт.
В течение многих лет аналитики извлекали информацию о требованиях пользователей из сценариев использования (McGraw и Harbisont, 1997). Сценарием (scenario) называется описание одного варианта использования системы. Ivar Jacobson с коллегами (1992), Larry Constantine и Lucy Lockwood (1999), Alistair Cockburn (2001) и многие другие преобразовали этот подход в методику, где для сбора информации и моделирования требований применяются варианты использования. Последние прекрасно себя зарекомендовали при разработке требований для бизнес-приложений, Web-сайтов, служб, предоставляемых одной системой другой и систем, позволяющим пользователям управлять определенным оборудованием. У таких продуктов, как процессы пакетной обработки, системы для интенсивных вычислений и приложения для хранения данных, может оказаться всего несколько простых вариантов использования. Сложность их работы заключается в выполняемых вычислениях или генерировании отчетов, а не во взаимодействии пользователя и системы. Работа с требованиями, часто применяемая для систем реального времени, заключается в перечислении внешних событий, на которые система должны реагировать и соответствующих реакций системы. В этой главе описано, как с помощью вариантов использования и таблиц «событие — реакция» зафиксировать пользовательские требования.
| Ловушка Не пытайтесь включить в вариант использования каждое появившееся требование. С помощью вариантов использования удается выявить большинство, но никак не все функциональные требования. |
Подход с применением варианта использования продукта
Вариант использования (use case) продукта описывает последовательность взаимодействия системы и внешнего действующего лица. Действующим лицом (actor) может быть человек, другая система ПО или аппаратное устройство, взаимодействующее с системой для достижения некой цели (Cockburn, 2001). Еще одно название действующего лица — роль пользователя, поскольку эта роль, которую члены одного или нескольких классов пользователей могут выполнять по отношению к системе (Constantine и Lockwood, 1999). Например, в варианте использования Chemical Tracking System «Запрос химиката» участвует действующее лицо — Сотрудник, разместивший заказ на химикат. Класса пользователей Chemical Tracking System с таким именем не существует. И химики, и специалисты, работающие на складе химикатов, могут запрашивать химикаты, поэтому члены любого из этих классов могут играть роль Сотрудника, разместившего заказ на химикат.
Понятие «вариант использования» пришло из мира объектно-ориентированного программирования. Тем не менее они годятся и дляпроектов, где применяются любые приемы разработки, поскольку пользователям безразлично, как именно создается ПО. Варианты использования лежат в основе широко применяемого Унифицированного процесса разработки ПО (Jacobson, Booch и Rumbaugh, 1999).
Варианты использования меняют традиционный подход к сбору информации; пользователей не спрашивают, как прежде, что с их точки зрения, должна делать система, авыясняют, какие задачи собирается с ее помощью решать пользователь. Цель такого подхода — описать все подобные задачи. До включения каждого варианта использования в утвержденную версию требований, заинтересованные в проекте лица проверяют, не выходит ли он за границы проекта. Теоретически в конечный набор вариантов использования должна входить вся желаемая функциональность системы. На практике же вам вряд ли удастся добиться стопроцентного результата, однако варианты использования помогут вам выполнить эту задачу полнее, чем какой-либо другой прием сбора информации, которым я когда-либо пользовался.
Рис. 8-1. Фрагмент диаграммы вариантов использования Chemical Tracking System
Диаграммы вариантов использования (use-case diagrams) позволяют получить отличное визуальное представление о требованиях пользователей. На рис. 8-1 показан фрагмент диаграммы варианта использования Chemical Tracking System, где применяются нотации UML (Unified Modeling Language — унифицированный язык моделирования) (Booch, Rumbaugh и Jacobson, 1999; Armour и Miller, 2001). Прямоугольник показывает границы системы. Линии соединяют каждое действующее лицо (нарисованный человечек) с вариантами использования (эллипсами), с которыми это лицо взаимодействует. Обратите внимание на сходство этой диаграммы варианта использования с контекстной диаграммой на рис. 5-3. Здесь прямоугольник отделяет некоторые внутренние элементы высокого уровня системы — варианты использования — от внешних действующих лиц. Контекстная диаграмма также отображает объекты, расположенные вне системы, но на ней не видны внутренние части системы.
Варианты использования и сценарии использования
Вариант использования (use case) — это отдельная, независимая деятельность, которую действующее лицо может совершить для получения определенного значимого результата. Один вариант использования может охватывать несколько схожих задач с одинаковыми целями. Следовательно, он представляет собой набор связанных между собой сценариев использования, где сценарий — это отдельный пример варианта использования. Вы можете начать разработку требований с абстрактных вариантов использования, а затем на их основе создать конкретные сценарии использования или, наоборот, перейти от некоего сценария к более широкому варианту использования. Далее в этой главе показан подробный шаблон для документирования вариантов использования. К важным элементам описания варианта использования относятся:
· уникальный идентификатор;
· имя, кратко описывающее задачи пользователи в формате «глагол + объект», например «разместить заказ»;
· краткое текстовое описание на естественном языке;
· список предварительных условий, которые должны быть удовлетворены до начала разработки варианта использования;
· выходные условия, описывающие состояние системы после успешного завершения разработки варианта использования;
· пронумерованный список действий, иллюстрирующий последовательность этапов взаимодействия лица и системы от предварительных условий до выходных условий.
Один сценарий считается нормальным направлением развития (normal course) варианта использования, его также называют основным направлением, базовым направлением, нормальным потоком, основным сценарием, главным успешным сценарием и благоприятным путем. Нормальное направление для варианта использования «Запрос химиката» — запрос химиката, который есть на складе.
Рис. 8-2. UML-диаграмма, иллюстрирующая диалоговый поток при нормальном и альтернативном развитии варианта использования
Другие допустимые сценарии из варианта использования, называются альтернативными направлениями (alternative courses) или вторичными сценариями (secondary scenarios) (Schneider и Winters, 1998). Они также могут привести к успешному выполнению задания и удовлетворяют выходным условиям варианта использования. Однако они представляют вариации решения задачи или диалоговой последовательности, необходимой для выполнения задачи. В определенной точке принятия решений в диалоговой последовательности нормальное направление может перейти в альтернативное, а затем вернуться обратно в нормальное. Хотя большинство вариантов использования можно описать простым языком, блок-схема или UML-диаграмма позволяют визуально представить логическое развитие сложного варианта использования, как показано на рис. 8-2. Блок-схема и диаграммы взаимодействия показывают точку принятия решений и условия, при которых основное направление развития событий переходит в альтернативное.
Альтернативное направление для варианта использования «Заказать химикат» — это «Заказать химикат у поставщика». В обеих ситуациях конечная цель действующего лица одна и та же — запрос химиката, поэтому оба сценария входят в один вариант использования. Некоторые этапы альтернативного направления аналогичны этапам нормального направления, но для завершения альтернативного направления необходимо выполнить особые действия. В нашем случае пользователь может искать необходимый химикат по каталогам поставщиков. Если альтернативное направление само по себе является автономным вариантом использования, вы можете расширить (extention) нормальное направление, включив этот отдельный вариант использования в нормальный поток (Armour и Miller, 2001). Диаграмма на рис. 8-1 иллюстрирует подобную расширенную взаимосвязь. Вариант использования «Запросить химикат» был расширен вариантом использования «Выполнить поиск по каталогам поставщика». Кроме того, сотрудники склада химикатов используют «Поиск по каталогам поставщиков» как отдельный вариант.
Иногда несколько вариантов использования имеют общие наборы этапов. Чтобы избежать повторения этих этапов в каждом варианте использования, определите отдельный варианте общей функциональностью и укажите, что он включен (include) в другие варианты использования как подвариант. Эта процедура аналогична вызову общей подпрограммы в компьютерной программе.
В качестве примера рассмотрим работу ПО для бухгалтерии. Возможны два варианта использования — «Оплатить счет» и «Подтвердить кредитную карту», причем в обоих, чтобы выполнить платеж, пользователь должен подписать чек. Вы можете создать отдельный вариант использования «Подписать чек», который содержит набор действий, необходимых для подписи чека. Этот вариант будет включен в обе транзакции, как показано на рис. 8-3.
| Ловушка Не затягивайте обсуждение того, когда, как и стоит ли вообще использовать взаимоотношения типа расширить и включить. Чаще всего применяется следующий прием — указать общие действия во включенном варианте использования. |
Рис. 8-3. Пример того, как вариант использования связан с бухгалтерским приложением
Условия, препятствующие успешному завершению задания, называются исключениями (exceptions). Для варианта использования «Запросить химикат» существует одно исключение — «Химиката нет в продаже». Если в процессе сбора информации вы не укажете, как обрабатывать исключение, то возможны два пути:
1. разработчики предложат лучший по их мнению способ обработки исключений;
2. при генерации пользователем неверного условия произойдет сбой системы, так как никто не предусмотрел такой ситуации.
Бьюсь об заклад, что сбои системы не входят в список требований пользователей.
Иногда исключения рассматриваются как тип альтернативного направления (Cockburn, 2001), однако эти понятия следует разделять. Не обязательно реализовывать каждое альтернативное направление, которое вы определили для варианта использования; кроме того, вы можете отложить его реализацию до следующего выпуска. Однако вы обязаны реализовать исключения, из-за которых завершение сценариев может оказаться неуспешным. Любой, кто когда-либо занимался программированием, знает, что часто именно на работу над исключениями приходится большая часть программирования. Многие недостатки конечного продукта присущи именно обработчикам исключений (или происходят из-за их отсутствия!). Указать условия исключений в ходе сбора информации по требованиям — верный способ создать устойчивые к сбоям продукты.
Для многих систем пользователь может связать последовательность вариантов использование в «макровариант использования», описывающий объемную задачу. Для коммерческого Web-сайта предлагаются, например, такие варианты использования; «Поиск по каталогу», «Добавить товар в корзину» и «Оплатить товары в корзине». Если вы можете выполнить все эти действия по отдельности, то все они считаются независимыми вариантами использования. Кроме того, вы вправе выполнить все три указанные операции подряд, назвав этот один большой вариант использования «Приобрести товар», как показано на рис. 8-4. Причем после каждого варианта использования система должна быть в таком состоянии, чтобы пользователь мог приступить к следующему варианту использования немедленно. То есть выходные условия одного варианта использования должны удовлетворять предварительным условиям следующего за ним варианта. Подобным же образом в приложении обработки транзакций, например ATM, каждый вариант использования должен оставлять систему в состоянии готовности к следующей транзакции. Предварительные условия и выходные условия каждой транзакции варианта использования должны вставать в один ряд.
Рис. 8-4. Предварительные условия и выходные условия определяют границы отдельных вариантов использования, которые можно связать в цепочку для выполнения объемной задачи
Определение вариантов использования
Вы можете определить варианты использования несколькими способами (Ham, 1998; Larman, 1998):
· сначала определить действующие лица, а затем бизнес-процессы, в которых каждое лицо участвует;
· выразить бизнес-процессы в терминах определенных сценариев, обобщить сценарии в варианты использования и определить действующие лица для каждого варианта; определить внешние события, на которые система должна реагировать, а затем соотнести эти события с участвующими лицами и определенными вариантами использования;
· определить вероятные варианты использования на основе функциональных требований, Если какие-либо требования невозможно проследить до какого-либо варианта использования, подумайте, нужны ли они.
В Chemical Tracking System применен первый подход. Аналитик провел несколько семинаров по вариантам использования, примерно два раза в неделю, по два-три часа каждый. Члены различных классов пользователей участвовали в параллельных семинарах, так как лишь несколько вариантов использования были общими для нескольких классов пользователей. На каждом семинаре присутствовали сторонник продукта от класса пользователей, другие выбранные представители пользователей, а также разработчик. Участие в семинарах позволило разработчикам еще на ранней стадии получить представление о создаваемом продукте. Кроме того, они возвращали собравшихся к реальности, когда те предлагали невыполнимые требования.
До начала семинаров аналитики попросили пользователей продумать, какие задачи те собираются выполнять с помощью новой системы. Каждая такая задача становилась потенциальным вариантом использования. Несколько предложенных вариантов, как выяснилось, выходят за границы проекта, поэтому далее они не обсуждались. По мере изучения вариантов использования стало ясно, что некоторые варианты связаны между собой сценариями, которые можно объединить в один абстрактный вариант использования. Также удалось выявить дополнительные варианты использования, не входившие в первоначальный набор.
.Некоторые участники предложили варианты использования, не сформулированные как задачи, например «Данные по безопасному хранению материала» Название варианта использования должно указывать на решаемую задачу, поэтому в названии необходим глагол. Что клиент хочет: просмотреть, напечатать, заказать, отправить по электронной почте, исправить, удалить или создать данные по безопасному хранению материала? Иногда предложенный вариант использования — это всего лишь одно действие, которое выполняется как часть варианта использования, например «сканировать штрих-код». Аналитик должен выяснить, какую цель подразумевал пользователь, когда предлагал это. Он может задать такой вопрос: «Сканируя штрих-код на контейнере с химикатами, что вы пытаетесь сделать?» Предположим, в ответ он услышит: «Это необходимо для того, чтобы я мог отправить этот химикат в свою лабораторию». Следовательно, настоящий вариант использования выглядит как-то так — «Отправить химикат в лабораторию». Сканирование штрих-кода — только один из этапов взаимодействия действующего лица и системы, передающей химикат в лабораторию.
Как правило, пользователи сначала определяют самые важные варианты использования, поэтому порядок предлагаемых тем позволит получить представление о приоритетах. Другой способ расстановки приоритетов — кратко описать каждый потенциальный вариант использования в том виде, как он был предложен. Расставьте приоритеты и предварительно распределите их по выпускам продукта. В первую очередь укажите детали для вариантов использования с наивысшим приоритетом, чтобы разработчики смогли приступить к их реализации как можно скорее.
Документирование вариантов использования
На этой стадии обсуждения участники должны обдумать важнейшие варианты использования. Constantine и Lockwood (1999) дают следующее определение важнейших (абстрактных) вариантов использования (essential use cases): «... упрощенное, обобщенное, абстрактное, не зависящее от технологии и реализации описание одной задачи или взаимодействия... в котором воплощена цель или намерения, лежащие в основе взаимодействия». То есть следует сосредоточиться на задаче, которую пользователю необходимо выполнить, и возможностях системы для выполнения этой задачи. Важнейшие варианты использования характеризуются более высоким уровнем абстракции, чем конкретные варианты использования (concrete use cases), которые описывают определенные действия, предпринимаемые пользователем для взаимодействия с системой. Чтобы проиллюстрировать различие, рассмотрим два способа начала реализации пользователем варианта использования «Запросить химикат».
Конкретный вариант использования. Введите номер ID химиката
Важнейший (абстрактный) вариант использования. Укажите необходимый химикат.
Формулировка на важнейшем (абстрактном) уровне позволяет пользователю выполнить задачу многими способами: ввести номер ID химиката, импортировать химическую структуру из файла, нарисовать структуру на экране с помощью мыши, выбрать химикат из списка и многое другое. Слишком быстрое углубление в детали определенного взаимодействия ограничивает широту мышления участников семинара. Независимость важнейших (абстрактных) вариантов использования от реализации, делает их более пригодными для повторных применений, чем конкретные варианты использования.
Участники семинара, посвященного Chemical Tracking System, начинали каждое обсуждение с определения действующего лица, которое получит преимущество отданного варианта использования и краткого описания этого варианта. Затем они указывали предварительные условия и выходные условия, ограничивающие вариант использования, а также все этапы внутри этих границ. Выяснив частоту использования, вы на ранних стадиях получите представление о необходимости и важности требования. Далее аналитики спрашивали участников, как те себе представляют взаимодействие с системой для выполнения задачи, Установленная последовательность действий лиц и реакции системы определялась, как нормальное направление. Нумерация этапов последовательности окончательно проясняла ситуацию. Хотя у каждого участника было свое представление об интерфейсе и специальных механизмах взаимодействия, группа смогла выработать общее понимание важнейших этапов диалога системы и пользователя.
| Придерживаясь границ Изучая вариант использования из восьми этапов, я понял, что выходные условий удовлетворены уже после пятого этапа. Следовательно, этапы 6, 7 и 8 были излишними, так как выходили за границы варианта использования. Точно так же предварительные условия варианта использования должны быть удовлетворены до начала первого этапа. Изучая описание варианта использования, убедитесь, что предварительные и выходные условия ограничивают его соответствующим образом. |
Аналитик фиксировал действия отдельного лица и реакцию системы на отдельных клейких листочках, которые затем прикреплял на схему. Возможен и другой способ проведения семинара — в ходе обсуждения спроецировать с помощью компьютера шаблон варианта использования на большой экран и отредактировать его, хотя иногда это замедляет обсуждение.
Команда, занимающаяся сбором информации, разработала аналогичные диалоги для определения альтернативных направлений и исключений. Если пользователь говорит: «По умолчанию это должно быть... », значит, он описывает нормальное направление развития варианта использования. Такая фраза, как: «Необходимо, чтобы пользователь также смог... » предполагает обсуждение альтернативное направление. Многие условия исключений удавалось выяснить, когда аналитик задавал примерно такие вопросы: «Что должно произойти, если в текущий момент БД отключена?» или «Что, если этого химиката нет в продаже?». На семинаре также удобно обсудить ожидания пользователей, касающиеся качества продукта, например, времени реакции, доступности и надежности системы, ограничений дизайна пользовательского интерфейса и требований по безопасности.
После того как участники семинара описали каждый вариант использования, и никто не предлагал уже никаких дополнительных вариантов, исключений или специальных требований, приступали к следующему варианту использования. Участники не пытались рассмотреть все варианты использования за одно марафонское обсуждение или точно определить все детали каждого варианта использования. Они запланировали изучение вариантов использования по возрастающей и их последующее многократное рассмотрение и уточнение.
На рис. 8-5 показана последовательность этапов разработки вариантов использования. После семинара аналитик детально фиксировав каждый вариант использования, как на рис. 8-6. Существует два способа представить этапы взаимодействия пользователя и системы, которые и составляют основу варианта использования. На рис. 8-6 диалог представлен в виде пронумерованного списка этапов с указанием того, какой элемент (система или определенное действующее лицо) выполняет каждый шаг. Так же описываются и альтернативные направления и исключения, для которых показан этап нормального направления развития, на котором появляется ответвление, или этап, где возможно исключение. Существует еще один прием — описать процесс средствами таблицы из двух столбцов, как показано на рис. 8-7 (Wirfs-Brock, 1993). Действия лица показаны в левом столбце, а реакция системы — в правом. Цифры указывают на последовательность этапов диалога. Эта схема отлично работает, когда с системой взаимодействует только один пользователь. Чтобы сделать эту таблицу более понятной, вы можете записать каждое действие или реакцию системы в. отдельной строке, чтобы альтернативная последовательность стала очевидной, как показано на рис, 8-8.
Часто варианты использования содержат дополнительную информацию или требования, которые не годятся ни для одного из разделов шаблона. Для таких данных предусмотрен раздел «Специальные требования»: сюда записывают соответствующие атрибуты качества, требования к производительности и др. Также зафиксируйте любую информацию, которая может быть неочевидна пользователям, например необходимое для завершения варианта использования неявное взаимодействие одной системы с другой.
Рис. 8-5. Сбор информации для варианта использования
| Идентификатор варианта использования: | Вариант использования-1 | Название варианта использования: | Запросить химикат | |
| Автор: | Тим | Автор последнего обновления: | Дженис | |
| Дата создания: | 04.12.02 | Дата последнего обновления: | 27.12.02 | |
| Действующее лицо: | Сотрудник, разместивший заказ на химикат | |||
| Описание: | Сотрудник, разместивший заказ на химикат, указывает в запросе необходимый химикат, вводя его название или номер идентификатора химиката или импортируя его структуру из соответствующего графического средства. Система выполняет запрос, предлагая новый или использованный контейнер с химикатом со склада или позволяя создать запрос на заказ у стороннего поставщика. | |||
| Предварительные условия: | 1. Личность пользователя аутентифицирована. 2. Пользователь имеет право запрашивать химикаты. 3. База данных ПО запасам химикатов в данный момент подключена. | |||
| Выходные условия: | 1. Запрос сохраняется в Chemical Tracking System. 2. Запрос был отправлен по электронной почте на склад химикатов или поставщику. | |||
| Нормальное направление развития варианта использования: | 1.0 «Запросить химикат со склада» 1. Сотрудник указывает требуемый химикат. 2. Система подтверждает, что такой химикат доступен, 3. Система перечисляет контейнеры с необходимым химикатом, имеющиеся на складе. 4. Сотрудник может просмотреть историю любого контейнера. 5. Сотрудник выбирает определенный контейнер или просит отправить запрос поставщику (альтернативное направление 1.1). 6. Сотрудник вводит остальную информацию, чтобы завершить запрос. 7. Система сохраняет запрос и отправляет его по электронной почте на склад химикатов. | |||
| Альтернативное направление развития варианта использования: | 1.1 «Запросить химикат у поставщика» (ответвление после этапа 5) 1. Сотрудник ищет химикат по каталогам поставщика. 2. Система отображает список поставщиков, где также указаны размеры, класс и цена контейнеров. 3. Сотрудник выбирает поставщика, размер, класс и количество контейнеров. 4. Сотрудник вводит остальную информацию, чтобы завершить запрос. 5. Система сохраняет запрос и отправляет его по электронной почте поставщику. | |||
| Исключения: | 1.0.И. 1—«Химикат недоступен» (на этапе 2). 1. Система отображает сообщение «Химикат не существует». 2. Система спрашивает сотрудника, хочет ли он запросить другой химикат или выйти из программы. За. Сотрудник просит запросить другой химикат. 4а. Система заново начинает нормальное направление развития варианта использования. 3б. Сотрудник решает выйти из системы. 4б. Система завершает вариант использования. 1.0.И.2. «Химиката нет в продаже»(на этапе 5). 1. Система отображает сообщение «Нет поставщика этого химиката». 2. Система спрашивает сотрудника, хочет ли он запросить другой химикат или выйти из программы. За. Сотрудник запрашивает другой химикат. 4а. Система заново начинает нормальное направление развития варианта использования, 3б. Сотрудник решает выйти из системы. 4б. Система завершает вариант использования. | |||
| Включение: | Вариант использования-22—«Просмотреть хронологию контейнера» | |||
| Приоритет: | Высокий | |||
| Частота использования: | Используется примерно пять раз в неделю каждым химиком, 100 раз в неделю каждым работником склада. | |||
| Бизнес-правила: | Бизнес-правнпо-28—«Только сотрудник, получивший разрешение заведующего лаборатории, может запрашивать химикаты». | |||
| Специальные требования: | 1.Система должна импортировать химические структуры в стандартной зашифрованной форме из любых средств, поддерживающих рисование химических структур. | |||
| Предположения: | 1.Импортированные химические структуры должны быть достоверными, | |||
| Замечания и вопросы: | 1. Тим выяснит, нужно ли одобрение руководства для запроса химиката, относящегося к уровню 1 списка опасных химикатов. Дата выполнения: 04.01.03. | |||
Рис. 8-6. Описание варианта использования •«Запросить химикат».
| Действия лица | Реакция системы |
| 1.Укажите необходимый химикат, 4.Если нужно, запросите историю любого контейнера. 5.Выберите определенный контейнер (выполнено) или попросите отправить заказ поставщику (альтернативное направление 1.1) | 2. Убедится, что такой химикат существует. 3. Отобразит список контейнеров с необходимым химикатом, в данный момент числящихся на складе. |
Рис. 8-7. Описание этапов варианта использования в двухстолбцовом формате
| Действия лица | Реакция системы |
| 1.Укажите необходимый химикат. | |
| 2.Убедится, что такой химикат существует. 3.Отобразит список контейнеров с необходимым химикатом, в данный момент числящихся на складе. | |
| 4.Если нужно, запросите историю любого контейнера, 5.Выберите определенный контейнер (выполнено) или попросите отправить заказ поставщику (альтернативное направление 1.1). |
Рис. 8-8. Альтернативный макет для описания этапов варианта использования
в двухстолбцовом формате
Вам не всегда необходимо полное описание варианта использования. Alistair Cockburn (2001) Дописывает рабочий (casual) и полный (fully dressed) шаблоны вариантов использования (последний показан на рис. 8-6). Рабочий вариант использования — это просто текстовое изложение целей пользователя и взаимодействий с системой; что-то вроде раздела «Описание» на рис. 8-6. Рассказы пользователей, которые рассматриваются как требования в экстремальном программировании, представляют собой, по существу, рабочие версии варианта использования, как правило, написанные на учетных карточках (Jeffries, Anderson и Hendrickson, 2001). Полные описания вариантов использования необходимы, если:
· в работе над проектом представители пользователей действуют не в тесной связи с разработчиками;
· приложение сложное, и высок риск сбоев системы;
· описания вариантов использования — это самый низкий уровень детализации требований, предназначенный для разработчиков;
· вы планируете разработать подробные варианты тестирования на основании пользовательских требований;
· для совместной работы территориально удаленных друг от друга команд необходимо детальные общие данные.
| Ловушка Не пытайтесь догматически определять количество деталей, которые необходимо включить в вариант использования; помните, что ваша задача - достаточно хорошо разобраться, для чего система нужна пользователям, чтобы разработчики могли заняться приложением, не опасаясь необходимости будущих переделок. |
На рис. 8-5 показано, что после каждого семинара аналитики Chemical Tracking System выявляли функциональные требования к ПО на основе описаний вариантов использования (подробнее об этих темах — в следующем разделе главы). Они также создали модели анализа для некоторых сложных вариантов использования, например диаграмму перехода состояний, показывающую все возможные состояния запроса химиката и все допустимые изменения состояний.
Спустя день или два после семинара аналитик раздал описания вариантов использования и функциональных требования участникам, чтобы те просмотрели их до начала следующего семинара. Эти неофициальные просмотры выявили множество ошибок: ранее не выявленные альтернативные направления, новые исключения, некорректные функциональные требования и пропущенные этапы диалога. Оставьте между семинарами хотя бы один день. Умственное расслабление, которое наступает, когда минует день или два после мозгового штурма, позволяет людям взглянуть на проделанную работу с новой точки зрения. Один аналитик, проводивший семинары каждый день, заметил, что участникам стало трудно находить ошибки в просматриваемых документах, потому что информация была еще слишком свежа в памяти. Они прокручивали в уме дискуссии, которые только что завершились, и не замечали ошибок.
| Дополнительная информация В главе 11 описано несколько моделей анализа для Chemical Tracking System. |
| Ловушка Не ждите окончания сбора информации по требованиям, чтобы просить пользователей заняться просмотром собранного материала. |
На ранних стадиях разработки Chemical Tracking System руководитель тестирования создал концептуальные варианты тестирования, не зависящие от специфики реализации, на основе вариантов использования (Collard, 1999). Эти варианты тестирования помогли прийти команде к общему четкому пониманию того, как система должна функционировать при реализации определенных сценариев использования. Эти варианты тестирования позволили аналитикам проверить, действительно ли выявлены все функциональные требования, необходимые для выполнения пользователями каждого варианта использования. На заключительном семинаре, участники вместе провели критический анализ вариантов тестирования, чтобы убедиться, что одинаково понимают, как должны работать варианты использования. Как и при любом контроле качества, они