Спецификация требований к автосервису, предмет системная аналитика

Спецификация требований
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. В данной версии продукт предназначен для русскоязычной
аудитории, интерфейс приложения использует только русский язык.