Предположения и зависимости-1. В кафетерии будут установлены компьютеры и принтеры, подключенные к сети Интранет, что позволит сотрудникам кафетерия обрабатывать необходимый объем заказов, не пропуская сроки доставки заказов.
Предположения и зависимости-2. Персонал кафетерия будут иметь возможность доставлять все заказы в пределах 15 минут от указанного в заказах времени.
Предположения и зависимости-3. Если у какого-либо ресторана есть собственная система заказов через Интернет, Cafeteria Ordering System должна получить возможность двустороннего взаимодействия с ней.
Масштабы и ограничения
Объем первого и последующих выпусков системы
| Функция | Выпуск 1 | Выпуск 2 | Выпуск3 |
| Основные Функции-1 | Только стандартные функции из меню обедов; оплата заказов производится только посредством удержания из зарплаты | Возможность принимать заказы на завтраки и ужины, а не только на обеды; возможность принимать оплату через кредитные и дебетовые карты | |
| Основные функцни-2 | Не реализована | Не реализована полностью | Реализована |
| Основные функции-3 | Реализована, если позволит время (средний приоритет) | Реализована полностью | |
| Основные функции-4 | Только регистрация на оплату посредством удержания из зарплаты | Регистрация на оплату кредитной или дебетовой картой | |
| Основные фунщии-5 | Блюда доставляются только на территории компании | Добавить доставку из кафетерия к избранным точкам вне территории компании | |
| Основные функции-6 | Реализована полностью | ||
| Основные функции-7 | Не реализована | Не реализована | Реализована полностью |
| Основные функции 8 | Не реализована | Реализована полностью | |
| Основные функции- 9 | Реализована полностью |
|
|
Ограничения и исключения
Ограничения и исключения-1. На некоторые пункты меню кафетерия доставка не распространяется, поэтому меню, доступные клиентам Cafeteria Ordering System, будут подмножеством полных меню кафетерия.
Ограничения и исключения-2. Cafeteria Ordering System применяется только для кафетерия главного офиса Process Impact в Clackamas, штат Орегон.
Бизнес-контекст
Профили заинтересованных в проекте лиц
| Заинтересованные в проекте лица | Понимание основной ценности проекта | Отношение | Основные интересы | Ограничения |
| Управление компании | Увеличение производительности труда сотрудников; сокращение затрат на кафетерий | Сильная поддержка вплоть до выпуска 2; поддержка выпуска 3 в зависимости от результатов предыдущих выпусков | Сокращение расходов должно превысить затраты на разработку и использование | Не определены |
| Сотрудники кафетерия | Более эффективное использование рабочего времени сотрудников в течение дня; большее удовлетворение клиентов | Озабоченность взаимоотношениями с профсоюзом и возможным сокращением персонала; в остальном — все воспринимается нормально | Сохранение рабочих мест | Необходимость обучения сотрудников работе с Интернет; необходимость в персонале и транспорте для доставки |
| Постоянные клиенты кафетерия | Лучший выбор блюд; экономия времени; удобство | Большой энтузиазм, но могут использовать систему меньше, чем ожидается, из-за социальной значимости обедов в кафетерии и ресторанах | Простота использования; надежность доставки; возможность выбора блюд | Необходимость доступа к корпоративной сетиинтранет. |
| Отдел расчета зарплат | Отсутствие какой-либо выгоды; необходимость создания схемы регистрации удержания стоимости заказов из зарплаты | Не особо счастливы относительно предстоящей работы над ПО, но понимают ценность для компании и сотрудников | Минимум изменений в текущих приложениях расчета зарплат | Еще не выдан но никаких ресурсов на изменение ПО |
| Менеджеры ресторанов | Увеличение продаж; выход на новые области рынка для привлечения новых клиентов | Воспринимают нормально, но осторожно | Минимум новых технологий; озабоченность ресурсами и затратами, необходимыми для доставки блюд | Могут не иметь персонала и возможностей для обработки нужных объемов заказов; им может потребоваться доступ к Интернету |
Приоритеты проекта
|
|
| Область | Движущая сила | Ограничения | Степень свободы |
| Сроки | Выпуск 1 планируется на 01.03.03, выпуск 2 - на 01.05.03, до 3-х недель опоздания допустимо без пересмотра сроков заказчиками | ||
| Функции. | Все функции, запланированные к выпуску 1.0, должны быть полностью реализованы | ||
| Качество | 95% проверочных испытаний, проводимых пользователями, должны быть выполнены; все тесты на защищенность должны быть выполнены; соответствие корпоративным стандартам безопасности должно быть показано для всех защищенных транзакций | ||
| Персонал | Планируемый размер команды: работающий на полставки менеджер проекта, 2 разработчика, тестировщик, работающий на полставки; при необходимости могут быть дополнительно привлечены разработчик и тестировщик, оба работающие на полставки | ||
| Расходы | До 15% процентов перерасхода по бюджету возможны без пересмотра заказчиками |
Варианты использования
|
|
Различные классы пользователей определили следующие варианты использования и основных действующих лиц для Cafeteria Ordering System.
| Основное действующее лицо | Вариант использования |
| Клиент | 1. Заказ блюд. 2. Изменение заказа блюд. 3. Отмена заказа блюд. 4. Просмотр меню. 5. Регистрация для оплаты посредством удержания из зарплаты. 6. Отмена регистрации для оплаты посредством удержания из зарплаты. 7. Подписка на стандартные блюда, 8. Изменение подписки. 9. Ручная корректировка подписки. |
| Менеджер меню | 10. Создание меню. 11. Изменение меню. 12. Определение блюд на заказ. |
| Персонал кафетерия | 13. Приготовление блюд. 14. Генерация запроса на оплату, 15. Запрос на доставку. 16. Генерация отчетов по использованию системы. |
| Персонал доставки блюд. | 17. Доставка блюд. 18. Регистрация доставки блюд. 19. Распечатка инструкций по доставке. |
| № варианта использования: | Вариант использования-1 | |||
| Название варианта использования: | Заказ блюд | |||
| Автор: | KarlWegers | Последнее обновление: | JackMcGillicutty | |
| Дата создания: | 21 октября 2002 г. | Дата последнего обновления: | 7 ноября 2002 г. | |
| Действующие лица: | Клиент | |||
| Описание: | Клиент входит в Cafeteria Ordering System из корпоративной сети интранет или с домашнего компьютера, возможно, просматривает меню на определенную дату, выбирает блюда и делает заказ на доставку блюд в определенный пункт а пределах 15-минутного интервала времени. | |||
| Предварительные условия: | 1. Клиент зарегистрирован в Cafeteria Ordering System. 2. Клиент зарегистрирован для оплаты блюд через удержание из зарплаты. | |||
| Выходные условия: | 1. Заказ на доставку блюд сохранен в Cafeteria Ordering System со статусом «Принят». 2. Инвентарный список доступных блюд обновлен с учетом элементов этого заказа. 3. Остающиеся резервы возможности доставки в указанный интервал времени обновлены с учетом этого заказа. | |||
| Нормальное направление: | 1.0. Заказ одного набора блюд. 1. Клиент запрашивает просмотр меню за указанную дату. 2. Система выводит меню доступных блюд и спецпредложение дня. 3. Клиент выбирает один или более пунктов меню. 4. Клиент указывает, что заказ блюд завершен. 5. Система выводит заказанные пункты меню, стоимость каждого из них и общую сумму, включая все налоги и стоимость доставки. 6. Клиент подтверждает заказ блюд или делает запрос на изменение заказа (обратно к пункту 3). 7. Система выводит доступные периоды времени доставки наг дату доставки. 8. Клиент выбирает время доставки и указывает пункт доставки. 9. Клиент указывает метод оплаты. 10. Система подтверждает, что заказ принят. 11. Система посылает клиенту e-mail с подтверждением деталей заказа, цены и указаниями по доставке. 12. Система сохраняет заказ в базе данных, посылает e-mail с уведомлением персонала кафетерия о заказе, посылает информацию о заказанных блюдах инвентарной системе кафетерия и обновляет доступные периоды времени доставки. | |||
| Альтернативные направления: | 1.1. Заказ нескольких наборов блюд (ответвление после пункта 4). 1. Клиент делает запрос на заказ еще одного набора блюд. 2. Возврат к пункту 2.<abz> 1.2. Заказ нескольких одинаковых наборов блюд (после пункта 3). 1. Клиент делает запрос на определенное число одинаковых блюд. 2. Возврат к пункту 4. 1.3. Заказ спецпредложения дня (после пункта 2). 1. Клиент заказывает спецпредложение дня из меню. 2. Возврат к пункту 5. | |||
| Исключения: | 1.0.И.1 Текущее время - после истечения крайнего срока заказов (в пункте 1). 1. Система извещает клиента, что уже слишком поздно делать заказ на сегодня. 2а. Клиент отменяет заказ. 26. Система завершает вариант использования. За. Клиент делает запрос на другое число. 36. Система начинает вариант использования сначала. 1.0.И.2 Не осталось резервов времени доставки (в пункте 1). 1. Система сообщает клиенту, что нет не занятого времени доставки на выбранное число. 2а. Клиент отменяет заказ. 26. Система завершает вариант использования. 3. Клиент делает запрос, чтобы самому получить заказ в кафетерии (пропустить пункты 7, 8). 1.2.И.2 Невозможно выполнить заказ на указанное количество одинаковых блюд (в пункте 1). 1. Система извещает клиента о максимальном числе одинаковых блюд, которое она способна принять. 2. Клиент изменяет количество заказов на одинаковые блюда или отменяет заказ. | |||
| Включает: | Heт | |||
| Приоритет: | Высокий | |||
| Частота использования: | Приблизительно 400 пользователей, в среднем по одному обращению в день | |||
| Бизнес-правила: | Бизнес-правило-1; Бизнес-правило-2; Бизнес-правило-3; Бизнес правило-4; Бизнес-правило-8; Бизнес-правило-11; Бизнес-правило-12; Бизнес-правило-33 | |||
| Особые требования: | 1. Клиент должен иметь возможность отменить заказ в любой момент времени до подтверждения заказа. 2. Клиент должен иметь возможность просматривать все заказы за последние шесть месяцев и повторить один из них в качестве нового заказа при условии, что все его пункты присутствуют в меню на указанную дату доставки (приоритет = средний). | |||
| Допущения: | 1. Предполагается, что 30% клиентов будут заказывать спецпредложение дня (источник: данные кафетерия за предыдущие шесть месяцев). | |||
| Замечания и вопросы: | 1. Дата заказа по умолчанию - текущая, если клиент обращается к системе до истечения срока размещения заказов на этот день. В противном случае дата по умолчанию - следующий день, когда кафетерий открыт. 2. Если клиент не желает, чтобы заказ был доставлен, предварительное условие, требующее регистрации для удержания из зарплаты, не применяется. 3. Пиковая загрузка использования этого варианта использования -между 8:00 и 22:00 по местному времени. | |||
| № варианта использований: | Вариант использования-5 | ||
| Название варианта использования: | Регистрация на оплату через удержание из зарплаты | ||
| Автор: | KarlWegers | Последнее обновление: | Chris Zambito |
| Дата создания: | 21 октября 2002 г. | Дата последнего обновления: | 31 октября 2002 г. |
| Действующие лица: | Клиент, система расчета зарплат | ||
| Описание: | Клиенты кафетерия, использующие Cafeteria Ordering System и заказывающие блюда с доставкой, должны быть зарегистрированы для оплаты посредством удержания из зарплаты. Для безналичных покупок через Cafeteria Ordering System кафетерий будет выставлять счета на оплату системе расчета зарплат, которая будет удерживать. стоимость заказов из той суммы, которую клиент должен получить в следующий раз чеком или прямым зачислением в депозит в день зарплаты.. | ||
| Предварительные условия: | 1. Клиент зарегистрирован в Cafeteria Ordering System. | ||
| Выходные условия: | 1. Клиент зарегистрирован для оплаты посредством удержания из зарплаты. | ||
| Нормальное направление: | 5.0 Регистрация для оплаты посредством удержания из зарплаты, 1. Клиент делает запрос на регистрацию для оплаты посредством удержания из зарплаты. 2. Система вызывает вариант использования «Подтверждение идентичности пользователя». 3. Система запрашивает систему расчета зарплат. имеет ли клиент право на оплату посредством удержания из зарплаты. 4. Система расчета зарплат подтверждает, что клиенту предоставлено это право. 5. Система информирует клиента, что он имеет право на регистрацию для оплаты посредством удержания из зарплаты. 6. Система просит клиента подтвердить желание зарегистрироваться для оплаты посредством удержания из зарплаты. 7. Клиент подтверждает желание зарегистрироваться для оплаты посредством удержания из зарплаты. 8. Система посылает запрос системе расчета зарплат на установку процедуру оплаты посредством удержания из зарплаты для клиента. 9. Система расчета зарплат подтверждает, что процедура оплаты посредством удержания из зарплаты установлена. 10. Система уведомляет клиента, что процедура оплаты посредством удержания из зарплаты установлена и выдает номер подтверждения для транзакции регистрации. | ||
| Альтернативные направления: | Нет | ||
| Исключения: | 5.0.И.1 Идентичность клиента не подтверждается (в пункте 2). 1. Система дает пользователю еще две возможности подтвердить идентичность. 2а. Если подтверждение успешно, клиент продолжает вариант использования. 26. Если подтверждение не происходит после трех попыток, система извещает об этом клиента, записывает недействительную попытку подтверждения в журнал и завершает вариант использования. |
| Исключения: | 5.0.И.2 Клиент не имеет права на оплату посредством удержания из зарплаты (на шаге 4). 1. Система сообщает клиенту, что он не имеет права на оплату посредством удержания из зарплаты и объясняет, почему. 2. Система завершает вариант использования. 5.0.И.3 Клиент уже зарегистрирован для оплаты посредством удержания из зарплаты (на шаге 4). 1. Система извещает клиента, что он уже зарегистрирован для оплаты посредством удержания из зарплаты. 2. Система завершает вариант использования. | ||
| Включает: | Подтверждение идентичности пользователя | ||
| Приоритет: | Высокий | ||
| Частота использования: | В среднем по одному разу на сотрудника | ||
| Бизнес-правила: | Бизнес-лравило-86 и бизнес- правило-88 определяют права сотрудника на регистрацию для оплаты через удержания из зарплаты. | ||
| Особые требования: | 1. Подтверждение идентичности пользователя производится согласно корпоративным стандартам для приложений средней степени защиты. | ||
| Допущения: | Нет | ||
| Замечания и вопросы: | 1. Нужно ожидать высокой частоты исполнения этого варианта использования в первые две недели после выпуска системы. | ||
| № варианта использования: | Вариант использования-11 | ||
| Название варианта использования: | Изменение меню. | ||
| Автор: | KarlWiegers | Последнее обновление: | |
| Дата создания: | 21 октября 2002 г. | Дата последнего обновления: | |
| Действующие лица: | Менеджер меню | ||
| Описание: | Менеджер меню кафетерия должен иметь возможность изменять меню имеющихся в наличии блюд и цен на указанную дату, чтобы отражать изменения в наличии или ценах или для определения блюд дня. | ||
| Предварительные условия: | 1.Меню уже существуют системе. | ||
| Выходные условия: | 1.Измененное меню сохранено. | ||
| Нормальное направление: | 11.0 Редакция существующего меню. 1. Менеджер меню делает запрос на просмотр меню на определенную дату. 2. Система выводит меню. 3. Менеджер меню изменяет меню, добавляя новые блюда, удаляя или изменяя блюда, создавая или изменяя спецпредложения дня, или изменяя цены. 4. Менеджер меню делает запрос на сохранение меню, 5. Система сохраняет меню. | ||
| Альтернативные направления: | Нет | ||
| Исключения: | 11.0.И. Меню на указанную дату не существует пункте 1. Система сообщает менеджеру меню, что меню на указанную дату не существует. 2. Система спрашивает менеджера меню, желает ли он создать меню на указанную дату, За. Менеджер меню отвечает да». 36. Система вызывает вариант использования «Создание меню». 4а. Менеджер меню отвечает «нет». 46. Система завершает вариант использования. 11.0.И.2 Указанная дата – в прошлом (раньше текущей)(в пункте 1) 1. Система сообщает менеджеру меню, что меню на указанную дату не может быть изменено. 2. Система завершает вариант использования. | ||
| Включает: | Создание меню | ||
| Приоритет: | Высокий | ||
| Частота использования: | Приблизительно 20 раз в неделю, один пользователь. | ||
| Бизнес-правила:: | Бизнес-правило-24 | ||
| Особые требования: | 1. Менеджер меню должен иметь возможность отменить изменение меню в любое время. Если меню было изменено, система дол» ю запросить подтверждение отмены. | ||
| Допущения: | 1. Меню будет создаваться Process Impact на каждый официальный рабочий день, включая те выходные и праздники, когда планируется присутствие сотрудников на территории компании. |