Команда: team1

Программный продукт: «Заказ обедов в офис»

Спецификация требований к программному обеспечению

Версия 2

Лист регистрации изменений

Date	Version	Description	Author
20/07/2019	1.1	Draft	Бурилин А.В.
18.02.09	2	RC5	Сорокин П.А

Спецификация требований к программному обеспечению

1. Введение

Данный документ проектируется группой разработчиков Team1 для описания программного продукта «Lunch Manager». А так же системных, функциональных и не функциональных требований к данному продукту.

1. Назначение

• Разработка для практического освоения предмета ”Программная инженерия”.

• Фиксирование всех требований к продукту.

• Описание поведения будущей системы.

• создание продукта, приближенного к промышленным корпоративным продуктам

2. Область применения

Область применения системы – сфера обслуживания.

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

Назначение продукта – автоматизация заказов обедов в офис.

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

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

Пользователи: Офис менеджер, сотрудники фирмы.

Требования:

• Система представляет собой веб-ориентированное приложение, написанное на языке Java с использованием технологии JSP. В качестве СУБД выбрана MySQL. Т.к. продукт является кроссплатформенным решением, его использование не привязывается к конкретной операционной системе. Требуется настроенная локальная сеть в офисе предприятия и настроенная виртуальная машина JAVA и контейнер сервдетов Apache Tomcat 6.

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

Требования для разработки этого продукта:

• среды: Idea, NetBeans и Eclipse и сервер Apache Tomcat.

• Требуется установленная СУБД – MYSQL;

• беспроводная, локальная или другие сети

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

Работа системы:

1. Программный продукт должен обеспечивать работу двум категориям

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

1.1. Идентификация пользователей в соответствии с категорией

должна осуществляться посредством логина и пароля, вводимых

на стартовой странице приложения.

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

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

соответственно в зависимости от введенных данных.

0. 1.2.1. При неверном вводе появляется сообщение о

1. просьбе проверить правильность ввода логина и

2. пароля.

2. Пользователь должен сформировать необходимый ему на данные сутки список блюд к обеду.

2.1. Пользователь должен иметь возможность ознакомиться со всем меню на текущий день

2.1.1 Пользователь должен иметь возможность ознакомиться с

калорийностью блюд из меню.

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

2.2. Пользователь должен иметь возможность формировать свой список блюд.

2.2.1. Пользователь должен иметь возможность добавлять блюдо в свой список заказов.

2.2.2. Пользователь должен иметь возможность удалять блюдо из своего сформированного списка заказов.

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

3.1. Менеджер должен иметь возможность регистрировать

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

3.2. Менеджер должен иметь возможность заполнить меню на текущий

день.

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

некоторые блюда из предыдущих меню.(опция)

3.2.2 Менеджер должен иметь возможность устанавливать максимальное количество экземпляров данных блюд.

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

общий список блюд для заказа (список имеющихся блюд).

3.2.4 Менеджер должен иметь возможность удалять блюдо из

общего списка блюд.

3.2.5. Менеджер должен иметь возможность сгенерировать общий отчет и отчет по каждому пользователю.

4. Система должна предоставлять пользователю средство просмотра меню

и информации о каждом блюде.

3. Количественные показатели для нефункциональных

требований.

• Простота эксплуатации:

Время обучения персонала: 2ч.

• Устойивость к сбоям:

Время восстановления системы после сбоя: 1ч.

Процент событий, приводящих к сбоям: 1.

Вероятность изменения данных при сбоях: 0,1

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

Системная цель:

Система должна быть простой в эксплуатации для опытного оператора.

Проверяемое нефункциональное требование:

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

5. Требования надежности

1. Средняя продолжительность времени между двумя последовательными проявлениями ошибок в системе должно составлять пять часов.

2. Вероятность выхода системы из строя должна составлять 2-3 процента.

3. Коэффициент готовности системы – 98 из 100.

4. Время восстановления системы – 1 час.

5. Количество ошибок на функцию (в средним) – 0,1 багов.

6. Доступность системы: часов непрерывной работы, поддержка на 2-х последних этапах разработки (“Завершение”, “Сдача проекта”).

6. Требования производительности

Скорость:

Количество выполняемых транзакций в секунду(в среднем): 5 тыс.

Требования к RAM: 100 Mb

Требования к свободному месту на жестком диске: 200Мб (server side)

7. Требования к пользовательской документации

Требования на данном этапе отсутствует.

8. Заимствованные компоненты

Заимствованные компоненты на данном этапе отсутствует.

9. Требования к лицензированию

Платное программное обеспечение.

10. Требования распространения

По заказу, развертываемая версия.

Отчет.

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

Наименование блюда	Количество	Цена
	…