Спецификация проекта - pluxyryprince/Menu Wiki

Original URL: https://github.com/pluxyryprince/Menu/wiki/Спецификация-проекта

1 Введение

1.1 Назначение проекта

Приложение для формирования меню ресторана служит для удобства посетителей и поваров: регистрация, бронирование места и заказ блюд и напитков (для посетителей), добавление блюд и напитков в меню (для поваров).

1.2 Соглашения, приятые в документах

Документация должна быть оформлена по ГОСТу 19.201-78 или 19.202-78. Шрифт в документации – Times New Roman, размер – 16: для заголовков пунктов, 14: для заголовков подпунктов и основного текста. Жирным шрифтом выделяются заголовки пунктов и подпунктов.

1.3 Границы проекта

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

1.4 Ссылки

ГОСТы для документации: http://www.rugost.com/index.php?option=com_content&view=category&id=19&Itemid=50 Git хостинг1, на котором будет размещен проект: https://github.com/pluxyryprince Шаблон для составления технического задания: https://habr.com/ru/post/328822/ Шаблон для составления спецификации программного продукта: https://analytics.infozone.pro/requirements-analysis/template-specification-requirements/

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

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

Продукт является совершенно новым решением как касаемо конкретного ресторана, так и ресторанного бизнеса в целом. Предлагаемый функционал расширяет понимание ресторанных приложений, которые ранее были полезны лишь для гостей заведения. Данный программный продукт доступен для пользования не только посетителям, но и поварам данного ресторана, что упростит процесс обновления меню. Для визуализации вышесказанного была составлена контекстная диаграмма, отражающая связи внутри системы: Рисунок 1 – Контекстная диаграмма

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

2.2.1 Гости или посетители ресторана. Бывают постоянные или не постоянные. Для не постоянных клиентов максимум нужно просмотреть меню, тогда как для постоянных клиентов нужно предусмотреть бонусы, специальные предложения и т.д. Регистрация в приложении доступна всем. Более того, для зарегистрированных посетителей будет реализована система накопительных бонусов.

2.2.2 Повара, работающие в ресторане. Характеризуются более обширным доступом в приложении: помимо просмотра меню, у них есть возможность его редактировать, т.е. добавлять новые блюда и напитки в него. Регистрация и авторизация поваров ресторана отдельна от регистрации и авторизации посетителей.

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

2.3.1 Минимальные системные требования2:

2.3.2 Географическое положение баз данных

Сервер, на котором будут расположены базы данных, должен иметь географическое положение не далее границ европейской части Евразийского материка. Допускается расположение за пределами Российской федерации.

2.3.3 Географическое положение пользователей

Основная часть пользователей приложения находится в РФ и странах СНГ. Однако не исключено, что будут пользователи из других стран или материков.

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

Базы данных должны быть реализованы в СУБД4, работающей на языке запросов SQL. У баз данных и содержащихся в них таблицах должны быть понятные и «говорящие» названия. Программный продукт должен быть создан на языке программирования C# и иметь совместимость с языком запросов SQL. Дизайн приложения должен быть реализован в среде разработки MS Visual Studio 2019 с использованием стандартных элементов дизайна. Допускается использование сторонних цветовых гамм, шрифтов и рисунков для исполнения пожеланий заказчика.

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

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

3.1.1 Описание: Данная функция доступна как посетителям ресторана, так и поварам. Для данных посетителей и поваров использованы разные базы данных.

3.1.2 Требования:

3.2 Авторизация

3.2.1 Описание: данная функция доступна только зарегистрированным пользователям и поварам.

3.2.2 Требования:

3.3 Просмотр меню

3.3.1 Описание: из базы данных вытягивается список блюд и выводится на соответствующий элемент в приложении, пользователи могут его просматривать.

3.3.2 Требования:

3.4 Просмотр винной карты

3.4.1 Описание: см. п. 3.3.1

3.4.2 Требования: см. п. 3.3.2

3.5 Бронирование места

3.5.1 Описание: посетители выбирают место в ресторане, вносят предоплату, вносят личные данные и время в приложение. Таким образом место бронируется за конкретными гостями.

3.5.2 Требования:

3.6 Редактирование меню

3.6.1 Описание: данная функция доступна только поварам, работающим в данном заведении. При добавлении/удалении блюда или напитка оно должно быть удалено и из базы данных, чтобы не вызывать недоразумений.

3.6.2 Требования:

3.7 Заказ блюд и напитков

3.7.1 Описание: посетитель имеет возможность сделать заказ через приложение

3.7.2 Требования:

4 Требования к данным

4.1 Логическая модель данных

Логическая модель данных должна быть представлена визуально в виде диаграммы классов и диаграммы отношений сущностей. Они представлены ниже: Рисунок 2 – Диаграмма классов

Рисунок 3 – Диаграмма сущностей

5 Атрибуты качества

5.1 Удобство использования

5.2 Производительность

Каждый модуль программного продукта должен запускаться не более 0.3 сек. Подгрузка баз данных, отправка данных в базу должна занимать не больше 0.7-1 сек.

5.3 Безопасность

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

5.4 Техника безопасности

Чтобы предотвратить утечку данных или полную их потерю, сброс настроек, заказа/брони и пр. не рекомендуется выключать компьютер или иное при работе с приложением. Для безопасности хранения и использования данных советуется хранить базы данных на серверах с бесперебойными источниками питания.

Приложение А – словарь терминов

  1. Git — система контроля версий, которая позволяет хранить и отслеживать внесённые в файлы изменения. С Git над одним проектом могут работать несколько разработчиков. Хостинг - услуга по предоставлению ресурсов для размещения информации на сервере, постоянно имеющем доступ к сети. В данном случае.
  2. Системные требования – железо устройства, которое необходимо для запуска программного продукта
  3. Сервер — выделенный или специализированный компьютер для выполнения сервисного программного обеспечения (в том числе серверов тех или иных задач).
  4. СУБД – система управления базами данных