Спецификация требований 1. Введение 1.1. Назначение 1.1.1. Система предназначена для связи посетителей автосервиса с его администратором для организации встреч и проведения ремонтных работ клиентовю 1.1.2. Редакция 1 1.1.3. Адресовано команде разработки 1.2. Соглашений между разработчиками и заказчиком документально принято не было, в связи с тем, что система разрабатывается в рамках учебного предмета «Проектный практикум» 1.3. Границами проекта являются 1.3.1. Реализуется только мобильное приложение для Android; 1.3.2. В рамках спецификации реализуется следующий функционал клиента: 1.3.2.1. Система регистрации и авторизации клиентов; 1.3.2.2. Запись на ремонт; 1.3.2.3. История встреч; 1.3.2.4. Чат между клиентом и администратором автосервиса. 1.3.3. В системе предполагается работа только одного автосервиса. 1.3.4. Личный кабинет администратора автосервиса будет описан в следующих спецификациях. 1.4. Ссылки: 1.4.1. Гайдлайн по дизайну от: 1.4.2. Гайдлайн по дизайну от: 2. Общее описание 2.1. Система представляет собой мобильное приложение для связи клиентов и автосервисов. В рамках спецификации реализуется только личный кабинет клиента. 2.1.1. Рабочий процесс системы выглядит так: 2.1.1.1. Пользователь регистрируется в системе; 2.1.1.2. Пользователь интересующую дату для ремонта; 2.1.1.3. Пользователь отправляет заявку на ремонт; 2.1.1.4. Администратор автосервиса обрабатывает заявку на ремонт и сообщает результат пользователю; 2.1.1.5. Пользователь ведет общение с автосервисом с помощью чата. 2.1.1.6. В личном кабинете пользователь может посмотреть историю своих посещений автосервиса. 2.2. Существует два класса пользователей: 2.2.1. Клиент: записывается на ремонт, получает консультации от автосервиса. 2.2.2. Администратор автосервиса (в данной спецификации не рассматривается): принимает заявки и ведет учет поступающих заявок. Дает обратную связь клиентам. 2.3. Операционная среда 2.3.1. Проект представляет из себя мобильное приложение для Android выше версии 8.3. 2.4. Ограничение дизайна и реализации 2.4.1. Установить заглушки для процесса работы сотрудника автосервиса; 2.4.2. Не реализовывать авторизацию и регистрацию сотрудников автосервиса. 3. Функции системы 3.1. Функция системы Регистрация пользователя 3.1.1. Регистрация незарегистрированнх пользователей. 3.1.2. Функциональные требования: 3.1.2.1. Если хотя бы одно из полей не заполнено, система должна сообщать пользователю об ошибке и не регистрировать пользователя; 3.1.2.2. Если все обязательные поля заполнены – регистрировать и авторизовать пользователя. 3.1.2.3. Поля, доступные для заполнения (все обязательны для заполнения): 3.1.2.3.1. ФИО; 3.1.2.3.2. Название автомобиля; 3.1.2.3.3. Год выпуска автомобиля; 3.1.2.3.4. Контактный телефон; 3.1.2.3.5. Email; 3.1.2.3.6. Пароль. 3.1.2.4. Проверять согласие пользователя с соглашением об обработке персональных данных согласно Федеральному Закону 152 “О персональных данных”: пользователь не может зарегистрироваться в системе, если он не согласен с политикой конфиденциальности. 3.1.2.5. Текст политики будет разработан и подключен вне данной спецификации. 3.1.2.6. Если пользователь с указанным email уже существует, сообщать пользователю ошибку, не регистрировать пользователя. 3.2. Функция системы Авторизация пользователей 3.2.1. Пользователи должны иметь возможность авторизоваться в системе, если они уже прошли регистрацию 3.2.2. Функциональные требования: 3.2.2.1. Для авторизации пользователей использовать email и пароль 3.2.2.2. Если пользователь вводит email незарегистрированного пользователя, отображать ошибку и предложить зарегистрироваться в системе 3.3. Функция системы Просмотр доступного для записи времени в автосервисе 3.3.1. Пользователи должны иметь возможность просмотреть доступное для записи время в приложении. 3.3.2. Функциональные требования: 3.3.2.1. Пользователь должен видеть доступное для записи время; 3.3.2.2. Пользователь должен видеть мастера, работающего на смене в этот день. 3.3.2.3. Время должно отображаться по Екатеринбургу (GMT+5) 3.4. Функция системы Запись на ремонт 3.4.1. У пользователя должна быть возможность записаться на ремонт. 3.4.2. Функциональные требования: 3.4.2.1. Для доступного в автосервисе времени пользователь может записаться на ремонт; 3.4.2.2. При записи на ремонт пользователь заполняет информацию о возникшей проблеме: 3.4.2.2.1. Марка и модель автомобиля (предзаполняется из информации о пользователи) 3.4.2.2.2. Год выпуска автомобиля 3.4.2.2.3. Описание проблемы 3.4.2.3. У пользователя должна быть возможность прикрепить фотографии. 3.5. Функция системы Просмотр истории заявок 3.5.1. Возможность просмотра информации о уже созданных заявках на ремонт. 3.5.2. Функциональные требования: 3.5.2.1. Возможность просмотра информации о заявке: 3.5.2.1.1. Марка и модель автомобиля (предзаполняется из информации о пользователи) 3.5.2.1.2. Год выпуска автомобиля 3.5.2.1.3. Описание проблемы 3.5.2.1.4. Средняя оценка коворкинга 3.5.2.1.5. Статус и время заявки; 3.5.2.1.6. Контактная информация мастера, выполняющего обслуживание по заявке. 3.5.2.2. В заявке присутствует чат с менеджером, в котором пользователь может прикреплять изображения в форматах IMG, JPEG, JPG и PDF. 4. Требование к данным 4.1. Логическая модель данных представляет из себя тоже самое, что словарь данных, в виде одной таблицы. 4.2. Получение, целостность, хранение и утилизация данных 4.2.1. Данные получаются при регистрации пользователей в приложении 4.2.2. Контактные данные пользователя не изменяются 4.2.3. Хранятся данные в базе данных 4.2.4. Данные утилизируются по следующим моментам: 4.2.4.1. Старая версия документа удаляется из бд при добавлении новой версии 4.2.4.2. Данные пользователя удаляются по его личному требованию в соответствии с 152 Федеральным законом Российской Федерации “О персональных данных” 5. Требования к внешним интерфейсам 5.1. Пользовательские интерфейсы 5.1.1. Основной функционал в интерфейсах должен быть реализован согласно гайдлайнам, указанным в п.1.4.1 и п.1.4.2. 5.1.2. Остальные решения принимаются командой дизайнеров. Решения должны быть утверждены с менеджером продукта. 5.2. Интерфейсы ПО 5.2.1. Сервис должен быть связан с базой данных 5.3. Интерфейсы оборудования 5.3.1. Система должна быть разработана для смартфонов с операционной системой Android 8.3 и выше. 5.3.2. Основные входные данные: 5.3.2.1. Другие. Этот пункт остается на усмотрения разработчика. 5.4. Коммуникационные интерфейсы 5.4.1. В сервисе не подразумевается коммуникация с пользователями. 6. Атрибуты качества 6.1. Удобство использования 6.1.1. Каждое действие в приложении должно быть интуитивно понятным и не вызывающим вопросов. 6.1.2. Стандартный рабочий процесс, указанный в п.2.1.1 не должен вызывать ошибок и корректно обрабатываться системой; 6.1.3. Сайт должен работать стабильно для мобильных телефонов с ОС Android 8.3. и выше. 6.2. Производительность 6.2.1. В процессе рутинных действий (авторизация, регистрация, запись, работа с чатом, просмотр истории) – не должно быть заметных глазу зависаний. 6.3. Безопасность в данной версии продукта не имеет значения. 7. Требования по интернационализации и локализации. 7.1. В данной версии продукт предназначен для русскоязычной аудитории, интерфейс приложения использует только русский язык.
