Добавлен: 15.11.2018
Просмотров: 2218
Скачиваний: 15
- Государственные налоговые службы. Хотят получать налог от каждой продажи.
Предусловия. Кассир идентифицирован и аутентифицирован.
Результаты (Постусловия). Данные о продаже сохранены. Налоги корректно вычислены. Бухгалтерские и складские данные обновлены. Комиссионные начислены. Чек сгенерирован. Авторизация платежа выполнена.
Основной успешный сценарий (или основной процесс)
1. Покупатель подходит к кассовому аппарату PQS-системы с выбранными товарами.
2. Кассир открывает новую продажу.
3. Кассир вводит идентификатор товара,
4. Система записывает наименование товара и выдает его описание, цену и общую стоимость. Цена вычисляется на основе набора правил. Кассир повторяет действия, описанные в пп. 3-4, для каждого наименования товара.
5. Система вычисляет общую стоимость покупки с налогом.
6. Кассир сообщает покупателю общую стоимость и предлагает оплатить покупку.
7. Покупатель оплачивает покупку, система обрабатывает платеж,
8. Система регистрирует продажу и отправляет информацию о ней внешней бухгалтерской системе (для обновления бухгалтерских документов и начисления комиссионных) и системе складского учета (для обновления данных).
9. Система выдает товарный чек.
10. Покупатель покидает магазин с чеком и товарами (если он что-то купил).
Расширения (или альтернативные потоки)
*а. При каждом выходе системы из строя.
Для ввода системы в строй и корректной обработки платежа нужно обеспечить восстановление всех транзакций и событий с любого шага сценария.
1. Кассир перезапускает систему, регистрируется и предлагает восстановить предыдущее состояние.
2. Система восстанавливает предыдущее состояние. 2а. Система определяет аномалию, повлекшую сбой.
2.1. Система уведомляет об ошибке кассира, регистрирует ошибку и переходит в начальное состояние.
2.2. Кассир начинает новую продажу.
За. Неправильный идентификатор.
1. Система уведомляет об ошибке и отменяет ввод данного наименования товара.
3б. В рамках одной категории существует несколько различных наименований товара и идентифицировать конкретное наименование не нужно (например, 5 пакетов леденцов).
1. Кассир может ввести идентификатор категории товара и количество единиц.
3.6а. Покупатель просит кассира отменить покупку одного из товаров,
1. Кассир вводит идентификатор товара для удаления из продажи.
2. Система отображает обновленную промежуточную стоимость,
3.6б. Покупатель просит кассира отменить продажу.
1. Кассир отменяет продажу
3.6в. Кассир приостанавливает продажу.
1. Система записывает сведения о продаже таким образом, чтобы они были доступны с любого терминала POS-системы.
4а. Сгенерированная системой цена товара не устраивает покупателя (например, у него есть дисконтная карта и он рассчитывает на более низкую цену товара).
1. Кассир вводит команду об изменении цены.
2. Система вычисляет новую цену.
5а. Система выявляет сбой при коммуникации с внешней службой вычисления налога.
1. Система перезапускает службу с данного узла PQS-системы и продолжает работу.
….
7а. Оплата наличными.
1. Кассир вводит предложенную покупателем сумму.
2. Система вычисляет положенную сдачу и открывает кассу с наличностью.
3. Кассир складывает поученные деньги и выдает сдачу покупателю.
4. Система регистрирует платеж наличными.
7б. Оплата по кредитной карточке.
1. Покупатель вводит информацию о своей кредитной карточке.
2.Система отправляет запрос на авторизацию платежа внешней системе службы авторизации платежей и запрашивает подтверждение платежа.
…
Специальные требования
- Сенсорный экран с интерфейсом пользователя для большого плоского монитора. Текст должен быть виден с расстояния один метр.
- Отклик службы авторизации в 90% случаев приходит в течение 30 секунд.
- Каким-то образом нужно обеспечить робастное восстановление информации в.случае сбоя при
доступе к удаленным службам, таким как система складского учета.
- Возможность локализации {представления на различных языках) отображаемого текста.
- Возможность добавления новых бизнес-правил на шагах 3 и 7 в процессе функционирования системы.
Список технологий и типов данных
За. Идентификатор товара считывается со штрих-кода (при наличии последнего) лазерным сканером или вводится с клавиатуры.
3б. Идентификатор товара может определяться по схемам кодирования UPC, EAN, JAN или SKU.
7а. Информация об открытом кредите вводится с помощью считывающего устройства или с клавиатуры.
7б. Подпись при оплате чеком ставится на бумажном документе. Однако ожидается, что в течение двух лет большинство покупателей будут требовать цифровые устройства считывания подписи.
Частота использования: почти постоянно.
Открытые вопросы
- Изучить законодательство по налогообложению.
- Исследовать вопрос восстановления удаленных служб.
- Какая настройка потребуется для различных типов магазинов.
- Должен ли кассир снимать кассу при выходе из системы.
- Может ли пользователь сам использовать устройство считывания данных с карточки или это должен делать кассир.
Этот прецедент скорее является иллюстративным, чем исчерпывающим (хотя и основывается на реальных требованиях к POS-системе). Тем не менее, он описан достаточно подробно и позволяет составить реалистичное представление о развернутом формате описания прецедентов и их сложности. Этот пример может служить моделью для многих других прецедентов.
Представление в виде двух колонок
Некоторые предпочитают оформлять прецеденты в виде двух колонок, обращая внимание на факт взаимодействия исполнителей и системы. Вот как выглядит рассмотренное выше описание, представленное в виде двух колонок.
Прецедент П1. Оформление продажи
Основной исполнитель:...
... как и ранее...
Основной успешный сценарий
|
Действие исполнителя |
Отклик системы |
|
1. Покупатель подходит к кассовому аппарату POS-системы с выбранными товарами |
|
|
2. Кассир открывает новую продажу |
|
|
3.Кассир вводит идентификатор товара |
4. Система записывает наименование товара и выдает его описание, цену и общую стоимость. Цена вычисляется на основе набора правил. |
|
Кассир повторяет действия, описанные в пп. 3-4 для каждого наименования товара. |
5. Система вычисляет общую стоимость покупки с налогом |
|
6. Кассир сообщает покупателю общую стоимость и предлагает оплатить покупку. |
|
|
7. Покупатель оплачивает покупку. |
8. Система обрабатывает платеж. |
|
|
9. Система регистрирует продажу и отправляет информацию о ней внешней бухгалтерской системе (для обновления бухгалтерских документов и начисления комиссионных) и системе складского учета (для обновления данных). Система выдает товарный чек. |
Какой формат лучше?
Однозначного ответа на этот вопрос не существует. Главная задача — детально описать основной успешный сценарий и его расширения в некоторой стандартной форме.
Пояснения
Вводные элементы
В описание прецедента можно добавлять различные вводные элементы, из них, которые важны для изложения последующего сценария, следует пом щать в начало описания. Второстепенный материал можно располагать в kohi сценария. Например, в описание можно добавить следующий вводный элемент.
Главный исполнитель. Основной исполнитель, вызывающий системные службы для достижения цели. Заинтересованные лица и их потребности
Этот список играет более важную роль, чем это кажется на первый взгляд. С его помощью можно понять, что должна делать система. Приведем цитату.
“Система реализует соглашение между заинтересованными лицами. Поведение системы описывается с помощью прецедентов... Прецедент, как соглашение о поведении, включает все возможные аспекты поведения, связанные с удовлетворением запросов заинтересованных лиц" (Cockburn A.)
Эта цитата дает ответ на вопрос, что нужно описывать в прецеденте. Tам нужно описывать все, что служит удовлетворению запросов заинтересованнь лиц. Кроме того, начиная описание прецедента с перечня заинтересованных лиц
По окончании обработки расширения по умолчанию выполняется возврат к основному сценарию, если в расширении не предусмотрен другой ход событий (например, завершение работы системы).
Иногда некоторые расширения оказываются очень сложными, например, платеж по кредитной карточке. В этом случае расширение можно выделить в отдельный прецедент.
Вот пример, демонстрирующий описание сбоя при реализации расширения.
76. Оплата по кредитной карточке.
1. Покупатель вводит информацию о своей кредитной карточке.
2. Система отправляет запрос на авторизацию платежа внешней системе службы авторизации платежей и запрашивает подтверждение платежа. 2а. Система определяет сбой при взаимодействии с внешней системой.
1. Система сигнализирует об ошибке кассиру.
2. Кассир просит покупателя изменить тип платежа.
3....
Если нужно описать условия, которые могут возникнуть в любой момент, то в обозначении пункта можно использовать символ * (см. ниже).
*а. При каждом выходе системы из строя.
Для ввода системы в строй и корректной обработки платежа нужно обеспечить восстановление всех транзакций и событий с любого шага сценария.
1. Кассир перезапускает систему, регистрируется и предлагает восстановить предыдущее состояние.
2. Система восстанавливает предыдущее состояние.
Специальные требования
В этот раздел заносятся нефункциональные требования, атрибуты качества или ограничения, связанные с данным прецедентом. Сюда относятся характеристики производительности, надежности, удобства использования и конструктивные ограничения (например, на устройства ввода-вывода).
Специальные требования
- Сенсорный экран с интерфейсом пользователя для большого плоского монитора. Текст должен быть виден с расстояния один метр.
- Отклик службы авторизации в 90% случаев приходит в течение 30 секунд.
- Возможность локализации (представления на различных языках) отображаемого текста. Возможность добавления новых бизнес-правил на шагах 3 и 7 в процессе функционирования системы.
Запись этих условий при описании прецедента — классический совет разработчиков унифицированного процесса. Однако на практике многие специалисты помещают эти требования в едином общем документе, например, в дополнительной спецификации. Тогда их удобнее читать и осмысливать, поскольку обычно они рассматриваются в общем контексте в процессе анализа архитектуры.
Список технологий и типов данных
Зачастую при реализации проекта важно не что сделать, а как. Перечень используемых технологий тоже приводится в описании прецедента. Типичным примером такой ситуации являются технические ограничения, выдвигаемые заинтересованными лицами для технологий ввода и вывода. Например, заказчик может потребовать, чтобы POS-система поддерживала ввод данных кредитной карточки с клавиатуры и с помощью считывающего устройства. Заметим, что здесь приводятся лишь примеры проектных решений и ограничений, появляющихся на ранней стадии реализации проекта. В целом, такой конкретизации следует избегать, однако иногда она бывает неизбежна, особенно в отношении технологий ввода/вывода.
Нужно также указать возможные варианты типов данных, например, различные кодировки идентификаторов товаров.
Список технологий и типов данных
За. Идентификатор товара считывается со штрих-кода (при наличии последнего) лазерным сканером или вводится с клавиатуры.
3б. Идентификатор товара может определяться по схемам кодирования UPC, EAN, JAN или SKU.
7а. Информация об открытом кредите вводится с помощью считывающего устройства или с клавиатуры.
7б. Подпись при оплате чеком ставится на бумажном документе. Однако ожидается, что в течение двух лет большинство покупателей будут требовать цифровые устройства считывания подписи.
Совет. В этом разделе не должно быть много пунктов, описывающих различные действия для разных ситуаций. Если это необходимо, перенесите эти описания в раздел расширений.
Задачи и рамки прецедента
Как выделить прецедент? Зачастую определить правильный (а точнее, полезный) прецедент очень сложно. Каждую задачу можно рассматривать на разных уровнях детализации, начиная от конкретных простых действий и заканчивая деятельностью на уровне предприятия.
На каком же уровне детализации следует формулировать прецеденты?
Прецеденты для элементарных бизнес-процессов
Какой из следующих пунктов можно считать прецедентом?
• Переговоры с поставщиком
• Обработка возврата товара
• Регистрация
Можно сказать, что все это прецеденты на разных уровнях детализации, выделенные в зависимости от рамок системы, исполнителей и задач.
Вместо вопроса "Что такое корректный прецедент?" целесообразнозно задать себе вопрос: "На каком уровне следует рассматривать прецеденты в процессе анализа требований к приложению?".
Совет. В процессе анализа требований в компьютерному приложению следует сосредоточиться на уровне элементарных бизнес-процессов (EBP-Elementary Business Processes)
Термин ЕВР заимствован из области исследования бизнес-процессов и определяется следующим образом.
"Элементарный бизнес-процесс — это задача, выполняемая одним человеком в одном месте в одно время в ответ на некоторое бизнес-событие, добавляющая измеряемое бизнес-значение и переводящая данные в некоторое устойчивое состояние, например, подтверждение платежа по кредитной карточке или распоряжение брокеру при изменении цен".
Однако общая идея этого определения такова. Прецедент — это не один маленький шаг, такой, например, как удаление товара или печать документа. Основной сценарий прецедента обычно включает пять-десять шагов. Описываемый сценарий выполняется не в течение нескольких дней или сеансов, как, например, переговоры с поставщиками. Это задача, выполняемая в течение одного сеанса. Реализация прецедента может длиться от нескольких минут до нескольких дней. Как и при определении унифицированного процесса, основное внимание уделяется получению ощутимого (измеримого) результата и переходу системы и данных в устойчивое состояние.