[ В этом примере детали не приводятся ]
Регистрация для оплаты заказов различными способами
[ В этом примере детали не приводятся ]
Запрос на доставку заказа
[ В этом примере детали не приводятся ]
Создание, просмотр, изменение, удаление меню кафетерия
[ В этом примере детали не приводятся ]
Требования к внешнему интерфейсу
Интерфейсы пользователей
ПИ-1. Экраны вывода Cafeteria Ordering System должны соответствовать [4].
ПИ-2. Система должна обеспечивать ссылку на справку на каждой HTML странице, объясняющую, как пользоваться этой страницей.
ПИ-3. Интернет-страницы должны предоставлять полную возможность навигации и выбор блюд только при помощи клавиатуры, в дополнение к использованию мыши и клавиатуры.
Интерфейсы оборудования
Интерфейсы оборудования не выявлены.
Программные интерфейсы
ПИ-1. Инвентарная система кафетерия.
ПИ-1-1. Cafeteria Ordering System должна передавать количество единиц заказанных блюд инвентарной системе кафетерия через программный интерфейс.
ПИ-1-2. Cafeteria Ordering System должна опрашивать инвентарную систему кафетерия для определения наличия запрашиваемого блюда.
ПИ-1-3. Когда инвентарная система кафетерия сообщает Cafeteria Ordering System, что определенного блюда нет в наличии, Cafeteria Ordering System должна убирать это блюдо из меню на текущую дату.
ПИ-2. Система расчета зарплат. Cafeteria Ordering System должна сообщаться с системой расчета зарплат через программный интерфейс, выполняя следующие операции:
ПИ-2-1. Позволять клиенту регистрироваться для оплаты через удержания из зарплаты;
ПИ-2-2. Позволять клиенту отменять регистрацию для оплаты посредством удержания из зарплаты;
ПИ-2-3. Проверять, зарегистрирован ли клиент для оплаты посредством удержания из зарплаты;
ПИ-2-4. Передавать запрос на оплату приобретенного набора блюд;
ПИ-2-5. Возвращать полностью или частично предыдущую оплату, если клиент отменил заказ, или не был удовлетворен им, или заказ не был доставлен согласно подтвержденным инструкциям по доставке.
Интерфейсы передачи данных
ИПД-1. Cafeteria Ordering System должна посылать клиенту e-mail с подтверждением принятия заказа, ценой и инструкциями по доставке.
ИПД-2. Cafeteria Ordering System должна посылать клиенту e-mail с сообщением о любых проблемах, возникших с заказом или его доставкой после принятия заказа.
Другие нефункциональные требования
Требования к производительности
ТП-1. Система должна обслуживать 400 пользователей в период пиковой активности с 8:00 до 10:00 по местному времени, со средней продолжительностью сеанса 8 минут.
ТП-2. Все Интернет-страницы, генерируемые системой, должны полностью загружаться не более чем за 10 секунд по модемному соединению со скоростью 40кб/сек.
ТП-3. Загрузка ответов на запросы на экран должна занимать не более 7 секунд после того, как пользователь отослал запрос.
ТП-4. Система должна выводить пользователю сообщение о подтверждении не более чем через 4 секунды после того, как пользователь отсылает информацию системе.
Требования к охране труда
Требования к охране труда не определены.
Требования к безопасности
ТБ-1. Все сетевые транзакции, включающие финансовую или поддающуюся учету личную информацию, должны быть зашифрованы согласно Бизнес-правилу-33.
ТБ-2. Пользователи обязательно регистрируются для входа в Cafeteria Ordering System для выполнения всех операций, кроме просмотра меню.
ТБ-3. Клиенты должны регистрироваться для входа в систему согласно политике ограниченного доступа к компьютерным системам по Бизнес-правилу-35,
ТБ-4. Система должна позволять только сотрудникам кафетерия, внесенным в список авторизованных менеджеров меню, создавать или изменять меню, согласно Бизнес-правилу-24
ТБ-5. Только пользователи, авторизованные для домашнего доступа к корпоративной сети интранет, могут использовать Cafeteria Ordering System из пунктов вне территории компании.
ТБ-6. Система должна позволять клиентам просматривать только заказы, размещенные ими лично, ноне другими клиентами.
Атрибуты качества ПО
Доступность-1. Cafeteria Ordering System должна быть доступна пользователям корпоративной сети интранет и клиентам удаленного доступа по коммутируемой линии 99,9% времени между 5:00 и полуночью по местному времени и 95% времени между полуночью и 5:00 по местному времени.
Надежность-1. Если соединение между пользователем и системой разрывается до того, как заказ подтвержден или отменен, Cafeteria Оrdering System должна позволять пользователю восстановить незавершенный заказ.
Приложение A: Словарь и модель данных
Элемент данных | БНФ-определение | |
Инструкция по доставке | = + + + + | Имя клиента Телефон клиента Дата доставки заказа Пункт доставки заказа Период доставки заказа |
Пункт доставки заказа | = | * здание и комната, в которую должен быть доставлен заказанный набор блюд * |
Период доставки заказа | = | * 15-минутный период времени, когда должен быть доставлен заказ; должен начинаться и заканчиваться в четвертьчасовые промежутки часа * |
№ сотрудника | = | * присваиваемый компанией идентификационный номер сотрудника, разместившего заказ на набор блюд; 6-знаковая цифровая строка * |
Описание блюда | = | * текстовое описание пункта меню; максимум 1 00 знаков * |
Цена блюда | = | * стоимость одной единицы пункта меню до уплаты налогов, в долларах и центах * |
Дата доставки заказа | = | * дата, когда набор блюд должен быть доставлен или получен клиентом в кафетерии; формат ММ/ДД/ГГГГ; по умолчанию — текущая дата, если текущее время - до крайнего срока размещения заказа, в противном случае — следующий день; не может предшествовать текущей дате * |
Заказ набора блюд | = + + + + + | Номер заказа Дата размещения заказа Дата доставки 1:m{заказанное блюдо} Инструкция по доставке Статус заказа |
Номер заказа | = | * уникальное, последовательное целое число, присваиваемое системой каждому принятому заказу; начальное значение = 1 * |
Статус заказа | = | [незавершен принят | готов | ожидает доставки [ доставлен | отменен] * см. диаграмму состояний на рис. Г-3 * |
Оплата заказа | = + + | Размер оплаты Метод оплаты (номер транзакции удержания из зарплаты) |
Меню | = + + | Дата меню 1:m{пункт меню} 0:1{спец. предложение дня} |
Дата меню | = | * дата, на которую данное меню составлено; формат ММ/ДД/ГГГГ * |
Пункт меню | = + | Описание блюда Цена блюда |
Крайний срок размещения заказа | = | * время суток, к которому все заказы на этот день должны быть размещены * |
Дата размещения заказа | = | * дата, когда клиент разместил заказ; формат ММ/ДД/ГГГГ * |
Заказанное блюдо | = + | Пункт меню Заказанное количество блюд |
Клиент | = + + + + | Имя клиента № сотрудника Номер телефона сотрудник Местоположение сотрудника e-mail сотрудника |
e-mail сотрудника | = | * адрес электронной почты сотрудника, разместившего заказ; 30-знаковая буквенно-цифровая строка * |
Местоположение сотрудника | = | * здание и номера комнат сотрудника, разместившего заказ; 50-знаковая буквенно-цифровая строка * |
Имя клиента | = | * имя сотрудника, разместившего заказ; 30 знаковая буквенно-цифровая строка * |
Номер телефона сотрудника | = | * номер телефона сотрудника, разместившего заказ; в формате AAA-EEE-NNNN xXXXX междугородный код, код станции, номер, добавочный номер * |
Размер оплаты | = | * общая сумма стоимость заказа в долларах и центах, подсчитанная соответственно бизнес-правилу BR-12 * |
Метод оплаты | = | [удержание из зарплаты | наличные] * остальные должны быть добавлены, начиная с выпуска 2 * |
Номер транзакции удержания из зарплаты | = | * 8-знаковое последовательное целое число, которое система расчета зарплат присваивает каждой транзакции удержания из зарплаты, которую принимает * |
Заказанное количество единиц | = | * количество единиц каждого блюда, заказываемого клиентом; по умолчанию = 1; максимум = количество, имеющееся на текущий момент в инвентарном списке * |
Спецпредложение дня | = + | Описание спецпредложения дня Цена спецпредложения дня * менеджер меню может определять одно или более блюд дня для каждого меню, в которые входят блюда цена на которые снижена * |
Описание спецпредложения | = | * текстовое описание спецпредложения дня; максимум 1 00 знаков * |
Цена спецпредложения дня | = | * стоимость одной единицы спецпредложения дня в долларах и центах * |
Рисунок 2. Концептуальная модель данных для разрабатываемой системы
Приложение B: Модели анализа
Рисунок 3. Диаграмма состояний для изменения статуса заказа блюд