Вигерс Карл. Разработка требований к программному обеспечению

Подождите немного. Документ загружается.

Выходные

условия:

Клиент зарегистрирован

для

оплаты посредством удержания из

зарплаты.

Нормальное 5.0 Регистрация для оплаты посредством удержания из зарплаты,

направление:

Клиент делает запрос на регистрацию для оплаты посредством

удержания из зарплаты.

2. Система вызывает вариант использования «Подтверждение

идентичности пользователя».

3. Система запрашивает систему расчета зарплат,

имеет ли клиент право на оплату посредством удержания

из

зарплаты.

4. Система

расчета

зарплат подтверждает, что клиенту

предоставлено это право.

5. Система информирует клиента, что он имеет право

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

из зарплаты.

6. Система просит клиента подтвердить желание

зарегистрироваться

для оплаты посредством удержания

из зарплаты.

7. Клиент подтверждает желание зарегистрироваться

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

8. Система

посылает

запрос системе расчета зарплат

на установку процедуру оплаты посредством удержания

из зарплаты для клиента.

9. Система расчета зарплат подтверждает, что процедура

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

10.

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

посредством удержания из зарплаты установлена и выдает

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

Альтернативные

направления:

Н.ч

Исключения:

5.0.И.1

Идентичность клиента не подтверждается

(в

пункте 2).

Система дает пользователю еще две возможности

подтвердит!)

идентичность.

2а. Если подтверждение успешно, клиент продолжает вариант

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

26. Если подтверждение не происходит после трех попыток,

система извещает об этом клиента, записывает

недействительную попытку подтверждения в журнал

и завершает вариант использования.

Приложение Г

507

Исключения:

5.0.И.2

Клиент не имеет права на оплату посредством

удержания

из

зарплаты (на

шаге

4).

Система сообщает

клиенту,

что он не имеет права на оплату

посредством удержания из

зарплаты

и объясняет, почему.

2. Система завершает вариант использования.

5.0.И.З Клиент уже зарегистрирован для оплаты

посредством

удержания из зарплаты (на шаге 4).

Система извещает клиента, что он уже зарегистрирован для

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

2. Система завершает вариант использования.

Включает:

Приоритет:

Подтверждение идентичности

пользователя

Высокий

Частота

использования: В среднем по одному разу на сотрудника

Бизнес-правила:

Бизнес-правило-86

Бизнес-правило-88

определяют права

сотрудника на регистрацию для оплаты через удержания

из зарплаты.

Особые требования:

Допущения:

Подтверждение идентичности пользователя производится

согласно корпоративным стандартам для приложений средней

степени защиты.

"Нет"

Замечания и вопросы:

Нужно ожидать высокой частоты исполнения этого

варианта

использования в первые две недели после выпуска

системы.

№ варианта

использования:

Вариант

использования-11

Название варианта

использования:

Автор:

Дата создания:

Изменение меню

Karl

Wiegers

Последнее обновление:

21 октября 2002 г.

Дата

последнего

обновления:

Действующие лица: Менеджер меню

Описание: Менеджер меню кафетерия должен иметь возможность изменять ме-

ню имеющихся в наличии блюд и цен на указанную дату, чтобы отра-

жать изменения в наличии или ценах или для определения блюд дня.

508

Приложение Г

Предварительные

условия:

Меню уже существуют

системе.

Выходные условия;

Измененное

меню сохранено.

Нормальное

11.0

Редакция существующего

меню.

направление:

Менеджер меню делает запрос на просмотр меню

на определенную дату.

2. Система выводит меню.

3. Менеджер меню изменяет меню, добавляя новые блюда,

удаляя или изменяя

блюда,

создавая или изменяя спец.

предложения

дня,

или изменяя

цены.

Менеджер

меню делает запрос на сохранение меню,

5. Система сохраняет меню.

Альтернативные

направления;

Исключения:

Включает:

Приоритет:

Частота

использования:

Бизнес-правила:

Особые требования:

Допущения:

Hei

1 1

.0.И.1

Меню на указанную дату не существует

(в

пункте

.Система

сообщает менеджеру меню, что меню на

указанную

дату не существует.

2.Система

спрашивает менеджера меню,

желает ли он создать меню на указанную дату,

За. Менеджер меню

отвечает

«да».

36.

Система вызывает вариант использования

«Создание меню».

4а. Менеджер меню отвечает «нет».

46.

Система завершает вариант

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

.0.И.2

Указанная дата - в прошлом

(в

пункте

Система сообщает менеджеру меню, что меню на указанную

дату не может быть изменено.

2. Система завершает вариант использования.

Создание меню

Высокий

Приблизительно 20 раз в неделю, один

пользователь.

Бизнес

-правило

-24

Менеджер меню должен иметь возможность отменить изменение

меню в любое время. Если меню было изменено, система

дол*

запросить подтверждение отмены.

Меню будет создаваться Process Impact на каждый официальный

рабочий день, включая те выходные и праздники, когда плани-

руется присутствие сотрудников на территории компании.

Приложение Г

509

Замечания и вопросы;

Некоторые блюда не пригодны

для

доставки, и поэтому меню

для

клиентов Cafeteria Ordering System,

заказывающих

блюда с

доставкой, не всегда в точности соответствует меню в кафетерии,

В меню будет

указано,

каше

блюда

не

доставляются.

Система не

позволит клиентам

заказывать

доставку этих блюд.

Спецификация требований к ПО

Введение

1.1.

Назначение

Эта спецификация требований к ПО описывает функциональные и не-

функциональные требования к выпуску 1.0 Cafeteria Ordering System

(COS). Этот документ предназначен для команды, которая будут реа-

лизовывать и проверять корректность работы системы. Кроме специ-

ально обозначенных

случаев,

все указанные здесь требования имеют

высокий приоритет и приписаны к выпуску

1.0.

1.2.

Объем проекта и функции продукта

Cafeteria Ordering System позволит сотрудникам Process Impact зака-

зывать блюда в кафетерии компании через Интернет для доставки в

указанные пункты на территории компании. Детальное описание про-

дукта приведено в документе «Cafeteria Ordering System Vision and

Scope Document» [1]. В разделе этого документа под названием «Объ-

емы первого и следующих выпусков системы» перечислены функции,

полная или частичная реализация которых запланирована в этом вы-

пуске.

1.3.

Ссылки

1. Wiegers, Karl. Cafeteria Ordering System Vision and Scope

Document,

www.

processimpact.

com/projects/COS/COS_yision_and_scope.

doc

2. Wiegers, Karl. Process Impact Intranet Development Standard,

Version 1.3, www.processimpact.com/corporate/standards/

Pt_intranetj3ev_std.doc

510 Приложение Г

Zambito,

Christine. Process Impact Business Rules

Catalog,

www.processimpact.com/corporate/policies/PI__business_rutes.doc

Zambito, Christine. Process Impact Internet Application User

Interface

Standard, Version 2.0,

www.processimpact.com/corporate/standards/

PI internet

std.doc

2. Общее описание

2.1.

Общий взгляд на продукт

Cafeteria Ordering System — это новая система, которая заменяет

текущие процессы заказа и получения обедов в кафетерии Process Im-

pact. Контекстная диаграмма на рис.

Г-1

показывает внешние

объекты

и системные интерфейсы для версии 1.0. Предполагается

выпустить

несколько версий системы, чтобы в конечном итоге удалось встроить

ее в службу заказов нескольких близлежащих ресторанов, работаю-

щую через Интернет, а также, в службы авторизации кредитных и

дебе-

товых карт.

Регистрация

для

оплаты

посредством удержания

из зарплаты

Клиент

kj-~~Y~-!

Заказы

на питание

Информация

о подписке

на питание

Заказы

на питание

Запрос

на

регистрацию

для оплат через

удержания

из зарплаты

Инвентарная

система

кафетерия

Рис.

Г-1.

Контекстная диаграмма для версии

1.0

Cafeteria Ordering System

Приложение Г

2.2. Классы и характеристики пользователей

Класс

пользователей

Описание

Клиент

(привилегированный)

Сотрудники

кафетерия

Менеджер меню

Сотрудник по

доставке

Клиент

- это сотрудник Process Impact, находящийся на террито-

рии компании в Clackamas, штат Орегон, желающий

заказывать

пи-

тание с доставкой из кафетерия компании, Всего потенциальных

клиентов - 600, из

которых400,

как ожидается, будут

использовать

Cafeteria Ordering System в среднем 4

раза

в неделю

(источник:

те-

кущие данные по работе кафетерия). Иногда клиенты будут заказы-

вать питание на нескольких человек (мероприятия или гости). Ожи-

дается, что 90%

заказов

будут поступать через

корпоративную

сеть

интранет,

а 10% - с домашних компьютеров. Все клиенты имеют

доступ к

интранету

из

офисов. Некоторые клиенты пожелают уста-

новить

подписку на питание либо чтобы один набор блюд достав-

лялся им каждый день, либо чтобы автоматически доставлялось

спецпредложение дня. Клиент должен иметь возможность

вручную

корректировать подписку на любой

выбранный

день.

В кафетерии Process Impact в настоящее время работает около 20

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

Cafeteria

Order-

ing System, готовить блюда, упаковывать их для доставки, печатать

инструкции по доставке и

запрашивать

доставку. Большинство со-

трудников кафетерия придется обучать работе с компьютером, Ин-

тернет-браузером и Cafeteria Ordering System.

Менеджер меню -

это

сотрудник кафетерия, может быть,

менед-

жер кафетерия, отвечающий за создание и поддержку меню на каж-

дый

день,

в котором указано, какие блюда имеются в наличии в ка-

фетерии, и время дня, когда они есть в наличии, Менеджер меню

также определяет спецпредложение дня кафетерия. Менеджер ме-

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

ких запланированных блюд нет в наличии, или изменение в ценах.

Готовя заказы к доставке, сотрудники кафетерия будут печатать ин-

струкции для доставки и передавать запросы на доставку сотрудни-

ку по доставке - это может быть либо один из сотрудников кафете-

рия, либо подрядчик. Сотрудник по доставке будет забирать про-

дукты и инструкции для каждого заказа и доставлять их клиентам.

Главное

взаимодействие

сотрудника по доставке с системой будет

заключаться в подтверждении успеха

(или

неудачи}

доставки или

периодической повторной распечатке инструкций по доставке.

512

Приложение Г

2.3. Операционная среда

Операционная

среда-1.

Cafeteria Ordering System работает со сле-

дующими Интернет-браузерами: Microsoft Internet Explorer версии 5.0

и 6.0, Netscape Communicator версия 4.7, Netscape версии 6 и 7.

Операционная среда-2. Cafeteria Ordering System установлена на

сервере, работающем под управлением текущих утвержденных корпо-

рацией версий Red Hat Linux и Apache HTTP Server.

Операционная среда-3. Cafeteria Ordering System должна допускать

доступ пользователей через корпоративную сеть интранет и, если

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

брандмауэр, через Интернет-соединение из дома пользователя.

2.4. Ограничения дизайна и реализации

Ограничения дизайна и

реализации-1.

Документация

системы по

конструкции, коду и

сопровождению

должна соответствовать Process

Impact Intranet Development Standard, версия

1.3

[2]

Ограничения дизайна и

реализации-2,

Система должна использо-

вать текущую версию корпоративного стандарта процессора базы

данных Oracle.

Ограничения дизайна и реализации-3. Весь код HTML должен со-

ответствовать

стандарту

HTML

4.0.

Ограничения дизайна и реализации-4. Все сценарии должны быть

написаны на Perl.

2.5. Документация для пользователей

Документация для

пользователей-1.

Система должна предостав-

лять иерархическую и перекрестно связанную систему справки в фор-

мате HTML с доступом по сети, описывающую и иллюстрирующую все

функции системы.

Документация для

пользователей-2.

При первом доступе пользо-

вателя к системе и далее по требованию пользователя система

дог

жна

включать интерактивную обучающую программу, позволяющую поль-

зователям осуществить заказ блюд через

статическое

обучающее ме-

ню. Система не должна сохранять блюда, заказанные с помощью этого

шаблона, в базе данных или передавать заказы на них в

кафетерий,

Приложение Г 513

2.6.

Предположения

и зависимости

Предположения и

зависимости-1.

Кафетерий открыт для завтра-

ков, обедов и ужинов каждый рабочий день компании, когда предпола-

гается, что на территории компании будут находиться сотрудники.

Предположения и

зависимости-2.

Работа Cafeteria Ordering System

зависит от изменений в системе расчета зарплат, позволяющих при-

нимать запросы на оплату за питание, заказанное через COS.

Предположения и

зависимости-3.

Работа Cafeteria Ordering System

зависит от изменений в инвентарной системе кафетерия, позволяю-

щих обновлять информацию о наличии блюд по мере

принятия

зака-

зов Cafeteria Ordering System.

3. 3. Функции системы

3.1.

Заказы питания

3.1.1 Описание и приоритет

Клиент кафетерия, идентификация которого подтверждена, может за-

казывать набор блюд либо с доставкой в указанный пункт на террито-

рии

компании,

либо для получения его в кафетерии. Клиент должен

иметь возможность отменить или изменить заказ на

питание,

если

блюда еще не приготовлены. Приоритет — высокий.

3.1.2

Последовательности

«воздействие - реакция»

Воздействие: Клиент делает запрос на размещение заказа на один или более

приемов пищи.

Реакция:

Система

опрашивает

клиента

о деталях заказа, оплате

и инструкциях по доставке.

Воздействие: Клиент делает запрос на

изменение

заказа.

Реакция: Если

воздействие

имеет статус «Принято», система

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

Воздействие:

Клиент

делает запрос на

отмену

заказа.

Реакция: Если воздействие имеет статус «Принято», система

отменяет

заказ,

514 Приложение Г

3.1.3

Функциональные требования

Заказ.Размещение:

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

в Cafeteria Ordering

System,

размещать

заказ на один или более

наборов блюд.

Заказ.

Размещен

не.

Система должна подтвердить, что клиент зарегистрирован

для

оп

Регистрация:

латы посредством удержания из зарплаты для размещения

заказа.

Заказ.Размещение.

Если клиент не зарегистрирован для оплаты посредством удержа

Регистрация.Нет:

ния из

зарплаты,

система должна предложить клиенту

следующие

варианты: зарегистрироваться сейчас и продолжать размещать

заказ, сделать заказ и самому получить его в кафетерии

(без

до-

ставки), или выйти из Cafeteria Ordering

System.

Заказ.Размещение.

Система должна спрашивать клиента о дате доставки

(см.

Бизнес

Дата: правило-8)

Заказ.Размещение.

Если дата доставки заказа — текущий день, а крайний срок

прием.)

Дата.Крайнийсрок:

заказов уже прошел, то система должна известить клиента, что

уже слишком поздно размещать заказ на сегодня.

Клиент

должен

либо изменить дату, либо отменить заказ.

Заказ

Доставка.

Выбор:

Заказ.

Доставка.

Место:

Заказ

.Доставка.

Нетрезервов:

Заказ

.Доставка.Время:

Клиент должен

указать,

получит ли он заказ в кафетерии, или за-

каз должен быть доставлен.

Если заказ должен быть доставлен и все еще есть резервы време-

ни доставки на дату заказа, клиент должен указать место доставки.

Система должна известить клиента, если на дату заказа нет резер-

вов времени доставки. Клиент должен либо отменить заказ,

либ<|

указать,

что получит его в кафетерии.

Система должна показывать свободные интервалы времени

дос-

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

выбрать

один из показанных

интерва

доставки, сделать заказ без доставки

или отменить заказ.

Заказ

.Меню.

Дата:

Заказ. Меню.

Наличие:

Система должна отображать меню для указанной даты.

Меню на текущую дату должно показывать

только

те блюда,

кото-

рые хотя бы в одном экземпляре есть в

инвентарном

списке

кафе-

терия.

Приложение Г

515

Заказ.

Единицы.

Блюда:

Заказ. Единицы.

Несколько:

Заказ. Единицы.

Слишком

много:

Заказ. Единицы.

Изменение:

Система должна

позволять

клиенту указывать количество единиц

каждого

блюда,

которое он хочет заказать.

Система должна позволять клиенту заказывать несколько одинако-

вых наборов блюд, вплоть до минимального числа любого

из

ука-

занных блюд в меню, если таковое есть в заказе.

Если клиент заказывает большее единиц одного блюда, чем в

на-

стоящее время указано в инвентарном списке

кафетерия,

система

должна извещать клиента о максимальном количестве единиц это-

го блюда, которое он может заказать.

Если остатка блюд

инвентарном списке недостаточно для удов-

летворения

заказа,

клиент должен иметь возможность изменить

количество заказанных единиц блюд, изменить количество зака-

занных наборов блюд или отменить заказ,

Заказ.

Подтверждение.

Вывод:

Заказ.

Подтверждение.

Приглашение:

Заказ.Подтверждение.

Отказ:

Заказ.

Подтверждение.

Еще:

Заказ. Оплата.

Метод:

Заказ.

Оплата,

Доставка:

Заказ.Оплата.

Вкафетерии:

Заказ. Оплата

.Детали:

Когда клиент указывает, что не хочет больше

заказывать

никакие

блюда, система должна выводить заказанные

блюда,

цены на

каж-

дое из них и сумму к оплате, подсчитанную согласно Бизнес-пра-

вилу-12.

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

Если клиент не подтверждает заказ, он может либо изменить, либо

отменить его.

Система должна позволять клиенту заказывать дополнительные

наборы блюд на ту же или другие даты. Включение нескольких на-

боров блюд в один заказ регулируют

Бизнес-правило-3

Бизнес-

правило-4.

Когда клиент указывает, что закончил размещать заказы, система

должна попросить пользователя выбрать метод оплаты.

См. Бизнес-правило-11.

Если клиент сам получит блюда в

кафетерии,

система должна

предложить ему возможность оплаты через удержание из зарпла-

ты или наличными в кафетерии,

Система должна выводить названия заказанных блюд, сумму к оп-

лате, метод оплаты и инструкции по доставке.

516

Приложение Г