МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙ СКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ

УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра вычислительной техники

Лабораторная работа №4
по дисциплине «Программная Инженерия»
«Разработка требований»

Студенты Халина Д.Н.

Киселев С.А.
Вариант 3
Группа АВТ-718
Преподаватель Токарев В.Г.
Дата сдачи
 Новосибирск, 2020 г.
1. Задание
Определить полный перечень функциональных и нефункциональных требований к
системе. На его основе разработать документ «Спецификация требований к ПО».
2. Вариант задания
Вариант 3. Система автоматизации диспетчерской службы такси. Диспетчер,
водитель, клиент, директор, прием заказов, ведение очередей, ручное
распределение заказов, приложение водителя, мониторинг прохождения заказа.

3. Ход работы
3.1. Цели и задачи системы
Описание функциональных и нефункциональных требований к выпуску
системы автоматизации диспетчерской службы такси.
Целями системы являются:
 Усовершенствование приложения для повышения удобства заказа такси;
 Улучшение рейтинга организации и повышение числа положительных
отзывов пользователей ПО;
 Повышение дохода организации, использующей приложение;
 Кроссплатформенность приложения;
 Расширение штата сотрудников за счет найма программистов для того,
чтобы в кратчайшие сроки исправлять неполадки, возникающие в
процессе работы приложения;
 Тестирование и внедрение беспилотных такси.

Задачи системы:
 Хранение данных в БД о поездках клиентах, его истории заказов, так же
информации о водителе и его истории поездок;
 Предоставление пользователю простого и понятного интерфейса для
заказа такси через приложение;
 Предоставление водителю интерфейса для удобного управления рабочим
процессом;
 Предоставление директору интерфейса для удобного управления рабочим
процессом;
 Сбор статистики о поездках;
 Автоматизация формирования бухгалтерской отчетности.

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

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

Бизнес правила
 Заказ.1. Для заказа такси необходимо постоянное соединение с
Интернетом. В случае, если клиент закрыл приложение, оно будет
работать в фоновом режиме и присылать уведомления. Если
прерывается соединение с Интернетом, заказ не будет отменен.
 Заказ.2. Заказать такси можно в любое время суток и из любого
места. Но в таком случае существует большая вероятность, что
приложение будет долго подбирать водителей и время ожидания
будет составлять больше обычного.
 Ожидание клиента.1. После 5 минут ожидания клиента водителем,
с реквизитов первого будет автоматически взиматься определенная
сумма за каждую последующую минуту ожидания.
 Отмена заказа.1. Осуществить бесплатную отмену заказа можно не
позднее 3 минут, после нахождения подходящего водителя. В
противном случае клиенту полагается штраф.
 Отмена заказ.2. Если в течении 20 минут ожидания клиент не
появляется, заказ отменяется.

Программная часть
 Приложение будет поддерживаться как на Android, так и на IOS;
 На основе приложения будет написан сайт для заказа такси с
помощью ПК;
 Программный код приложения – C#, Java;
 Программный код сайта – JavaScript;
 Язык интерфейса – русский, английский, китайский,
итальянский, французский, испанский, немецкий, казахский.

Дизайн и реализация
 Текстура формата Portable network graphics (.png);
 Система должна использовать текущую версию БД MySQL (не
ниже версии 9);
 Разработка будет вестись с помощью кроссплатформенного
фреймворка разработки приложений PhoneGap;
 Серверная часть будет написана на PHP;
3
  Интерфейс будет реализован с помощью связки
HTML+CSS+Bootstrap+JavaScript.
3.3. Функции системы
 Заказ.Приложение.Статус. Возможность клиенту отслеживать
статус своего заказа («Поиск водителя», «Ожидание водителя» и
т.д.);
 Заказ.Приложение.МестоположениеВодителя. Возможность
клиенту отслеживать местоположение водителя;
 Заказ.Приложение.Уведомление. При закрытии приложения оно
будет работать в фоновом режиме и оповещать клиента о статусе
такси;
 Заказ.Приложение.Отмена. Система должна предоставлять
возможность клиенту отменить заказ на стадиях:
внесения информации, поиска подходящих водителей, ожидания
водителя, если не прошло 3 минуты;
 Заказ.Приложение.Оплата. Система должна предоставлять
возможность выбора формата оплаты клиенту удобным для него
способами;
 Заказ.Приложение.ПолучениеЧека. Система должна предоставлять
возможность выбора получение чека о совершенной оплате
поездки: получение pdf файла на устройство, получение чека на
электронную почту;
 Заказ.Водитель.Оплата. Система должна
предоставлять возможность водителю получать заработанные им
средства сразу, по завершению поездки;
 Заказ.Водитель.Оплата.НаличныеСредства. Система должна
предоставлять возможность списание средств с реквизитов
водителя, если оплата была произведена наличными средствами;
 Заказ.Водитель.ПринятьОтказатьсяОтПоездки. Система должна
предоставить водителю возможность принять или отказаться
от поездки через приложение;
 Директор.Информация. Система должна предоставлять директору
возможность просматривать информацию о поездках водителей;
 Заказ.СтадииЗаказа. Система должна фиксировать статус 
заказа в реальном времени и корректно отображать его клиенту,
водителю и директору в режиме реального времени;
 Заказ.Водитель.ЗавершениеПоездки. Система должна 
предоставить водителю возможность завершить поездку, нажав на 
специальную кнопку в приложении;
 Заказ.Клиент.Отзыв. Система должна предоставлять возможность
оценить поездку по пятибалльной шкале и указать, по каким
причинам была выставлена соответствующая оценка;
 Заказ.Клиент.Чаевые. Система должна предоставлять возможность
дать чаевые водителю, если оплата производилась онлайн;

4
  Приложение.СлужбаПоддержки. Система должна предоставлять
возможность звонка в службу поддержки.
3.4. Требования к системе
Система должна состоять из: 
 Физическая часть – компьютеры, устройства с установленными 
приложениями, сервера; 
 Программно-операционной системы (Android, IOS), веб-сервера 
(Apache+Nginx+PHP) и базы данных(MySQL). Должен быть
локальный веб-интерфейс для зарегистрированных сотрудников;
 Для директора и техподдержки должна быть доступна БД с
информацией о поездках и даны права на
добавление/изменение/удаление данных из БД; 
 Для водителя должна быть доступна БД с информацией о 
предыдущих поездках.
3.5. Другие нефункциональные требования 
 Другие.Простота.ИнформационнаяСистема.1. 
Использование стратегии минимизации числа элементов для ввода
информации (использовать combobox, чтобы ограничить
вероятность неверного ввода, автозаполнение информации о
клиенте); 
 Другие.Простота.ИнформационнаяСистема.2. 
Линейность при оформлении заказа такси (для того, чтобы
пользователь не запутался при заказе такси); 
 Другие.Безопасность.ИнформационнаяСистема.1. 
Использование PKI и SSL/TLS шифрование для шифрования
трафика и использования проверки идентичности других
пользователей. 
 Другие.Безопасность.ИнформационнаяСистема.2. Использование 
SSH-ключей в качестве альтернативы аутентификации с помощью
пароля. 
 Другие.Надежность.ИнформационнаяСистема.1. Создания 
резервных копий БД ежедневно. 
 Другие.Надежность.ИнформационнаяСистема.2. Использование 
технологии Firewall для защиты данных сервера.
 Другие.Надежность.ИнформационнаяСистема.3. Использование
защиты БД от SQL-иньекций.
4. Вывод
В результате выполнения данной лабораторной работы был сформирован 
документ «Спецификация требований ПО». На основе модели прецедентов, 
разработанной в третьей лабораторной работе, был определен перечень
функциональных требований к системе, описаны бизнес-правила, программная
часть, дизайн и реализация, функции системы, требования к системе и другие
нефункциональные требования.