Частота использования: почти постоянно.

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

• Изучить законодательство по налогообложению.

• Исследовать вопрос восстановления удаленных служб.

• Какая настройка потребуется для различных типов магазинов.

• Должен ли кассир снимать кассу при выходе из системы.

• Может ли пользователь сам использовать устройство считывания данных с карточки или это дол­жен делать кассир.

Этот прецедент скорее является иллюстративным, чем исчерпывающим (хотя и основывается на реальных требованиях к POS-системе). Тем не менее, он описан достаточно подробно и позволяет составить реалистичное представление о развернутом формате описания прецедентов и их сложности.

Этот пример может служить моделью для многих других прецедентов.

Пояснения к примеру

Вводные элементы

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

Главный исполнитель. Основной исполнитель, вызывающий системные службы для достижения цели.

Заинтересованные лица и их потребности

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

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

Предусловия и постусловия

Предусловия (preconditions) – это перечень предпосылок, которые всегда должны выполняться до начала сценария прецедента. Предусловия не проверя­ются при реализации прецедента. То есть это условия, которые считаются ис­тинными. Обычно в качестве предусловия выступает успешный результат вы­полнения другого сценария, например, загрузки или авторизации. В качестве предусловий перечисляются не все возможные истинные условия. На­пример, никто не упоминает в предусловиях наличие напряжения в электросети. Предусловия – это те предпосылки, на выполнение которых разработчик преце­дента хочет обратить особое внимание.

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

Основной успешный сценарий (или основной процесс)

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

Чаще всего в этом разделе нет ни­каких условий или ветвей. И хотя вводить какие-либо условия не запрещается, их обычно выносят в раздел расширений.

В разделе основного сценария описываются три вида действий:

1. Взаимодействие между исполнителями.²

2. Верификация (обычно со стороны системы).

3. Изменение состояния системы (например, запись или модификация неко­торых сущностей).

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

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

Расширения (или альтернативные потоки)

В этом разделе указываются все остальные сценарии или ветви, приводящие к успешному или неудачному завершению прецедента.

При описании прецедента основной успешный сценарий и его расширения должны охватывать почти все интересы заинтересованных лиц. Некоторые ин­тересы лучше выразить в виде нефункциональных требований в дополнительной спецификации, а не в описании прецедента. Расширения – это ответвления от основного сценария.

Специальные требования

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

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

Список технологий и типов данных

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

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

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

Вопрос 3. Задачи и рамки прецедента

Как выделить прецедент?

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

На каком же уровне детализации следует формулировать прецеденты?

В процессе анализа требований к компьютерному приложению следует сосре­доточить внимание на уровне элементарных бизнес-процессов (ЕВР – Elemen­tary Business Processes).

Термин ЕВР заимствован из области исследования бизнес-процессов³ и оп­ределяется следующим образом.

"Элементарный бизнес-процесс – это задача, выполняемая одним челове­ком в одном месте в одно время в ответ на некоторое бизнес-событие, добавляю­щая измеряемое бизнес-значение и переводящая данные в некоторое устойчивое состояние, например, подтверждение платежа по кредитной карточке или распо­ряжение брокеру при изменении цен" (источник неизвестен).

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

Обоснованные отклонения от элементарного бизнес-процесса

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

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

Прецеденты и задачи

Исполнители имеют свои задачи (или потребности), для решения которых они используют систему. Поэтому прецеденты уровня EBF еще называют преце­дентами уровня задач пользователя (user goal). Это делается для того, чтобы об­ратить внимание на реализацию потребностей пользователей системы или основ­ного исполнителя.

Отсюда следует алгоритм выделения прецедентов:

1. Выделить задачи (цели) пользователей.

2. Определить для каждой из них отдельный прецедент.

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

Такая симметрия позволяет оценить адекватность уровня вы­деления прецедентов и задач пользователя в соответствии с правилом выделения элементарных бизнес-процессов.

Таким образом, ключевая идея состоит в том, чтобы для выделения преце­дентов исследовать задачи исполнителей.

Пример: использование рекомендаций в соответствии с EBF

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

Системный аналитик: "Каковы ваши задачи в контексте использования POS-системы?"

Кассир: "Во-первых, быстро зарегистрироваться. Во-вторых, оформлять продажи".

Системный аналитик: "Какая задача более высокого уровня приводит, на ваш взгляд, к необходимости выделения отдельной задачи регистрации?"

Кассир: "Мне необходимо "представиться" системе, а она должна прове­рить, имею ли я право ею пользоваться".

Системный аналитик: "Какова еще более глобальная задача?"

Кассир: "Предотвратить утечку или повреждение данных".

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

Предотвращение утечки данных – это цель более высокого уровня, чем за­дача пользователя. Поэтому пока мы ее рассматривать не будем, хотя она явля­ется чрезвычайно важной для данной системы. (Самым кардинальным решением этой задачи является полный отказ от POS-системы и услуг кассира.)

Цель следующего уровня иерархии ("представиться" системе и выполнить аутентификацию) несколько ближе к задачам пользователя. Но относится ли она к уровню элементарных бизнес-процессов? Ее решение не добавляет ощутимого результата или измеримого бизнес-значения. Если на вопрос о том, чем кассир занимался сегодня на работе, прозвучит ответ: "Я 20 раз зарегистрировался!", то вряд ли такой ответ устроит начальника. Значит, это второстепенная задача, ко­торая служит достижению важной цели, но не относится к уровню ЕВР. Уровню ЕВР точнее всего соответствует задача оформления продажи.

В качестве другого примера можно рассмотреть процесс регистрации вы­ручки, когда кассир задвигает ящик с наличностью и закрывает его в системе, регистрируется и вводит в систему сумму выручки. Регистрация выручки – это прецедент уровня ЕВР (или уровня задач пользователя), а регистрация в сис­теме – это один из его шагов, выполняющий вспомогательную задачу, а не от­дельный прецедент.

Вспомогательные задачи и прецеденты

Несмотря на то, что задача "представиться" системе и выполнить аутенти­фикацию (или задача регистрации) не была отнесена к уровню задач пользовате­ля, она все же является целью, но на более низком уровне.

Такие задачи назы­вают вспомогательными (subfunctional goal), поскольку они призваны обеспечи­вать выполнение задач пользователя. Для вспомогательных задач отдельные прецеденты создаются очень редко, хотя специалисты по написанию прецедентов зачастую рекомендуют улучшать (обычно упрощать) набор прецедентов.

Для вспомогательных задач писать прецеденты не запрещается, однако это не всегда нужно, поскольку при этом усложняется модель прецедентов. Количе­ство вспомогательных задач для системы может исчисляться сотнями, но стоит ли создавать так много прецедентов?

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

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

Таким образом, вполне логично создать прецедент Аутентификация пользователя.

Составные задачи и прецеденты

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

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

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

Задание на самостоятельную работу (для выбранной темы индивидуального проекта):

1. Описать все прецеденты в сжатом формате.

2. Выбрать один прецедент (на примере которого будет выполнено объектно-ориентированное проектирование) и составить для него развернутое описание.