ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ МОБИЛЬНОГО ПРИЛОЖЕНИЯ

Структура документа:

Глоссарий

Общие положения

2.1 Предмет разработки

2.2 Назначение документа

  1. Требования к графическому дизайну сайта

3.1 Требования к дизайну сайта

3.2 Порядок утверждения дизайн-концепции

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

4.1 Классы пользователей

4.2 Требования к представлению сайта

4.3 Требования к системе управления сайтом

4.4 Требования к разделению доступа

  1. Требования к видам обеспечения

5.1 Требования к информационному обеспечению

5.2 Требования к программному обеспечению

5.3 Требования к техническому обеспечению

5.4 Требования к лингвистическому обеспечению

5.5 Требования к эргономике и технической эстетике

  1. Требования к приемке-сдаче проекта

6.1 Требования к наполнению информацией

6.2 Требования к персоналу

6.3 Порядок предоставления дистрибутива

6.4 Порядок переноса сайта на технические средства заказчика

  1. Глоссарий

 

Термин Описание
Сайт Информационная система, предоставляющая пользователям сети

Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц

 

Мобильное приложение Мобильное приложение – это специально разработанное приложение под конкретную мобильную платформу (iOS, Android, Windows Phone).
Нативное мобильное приложение Приложение можно назвать «родным» для операционных систем – Android, IOS, WinPhone . Такие мобильные приложения пишутся на языках программирования, утвержденных разработчиками программного обеспечения под каждую конкретную платформу, а потому органично встраиваются в сами операционные системы. Приложения загружаются через магазины приложений (App Store, Google Play и т.д.) и соответствуют требованиям этих магазинов.
Администратор Лицо, осуществляющее от имени Заказчика информационную поддержку сайта
Дизайн веб-сайта Уникальные для конкретного веб-сайта структура, графическое

оформление и способы представления информации

 

 

  1. Общие положения

2.1 Предмет разработки

 

user case

Рис. Use case

 

Предметом разработки является

  • мобильное приложение с автоматическим наполнением контента;
  • Сайт;

 

Назначение мобильного приложения:

  • Предоставление полной информации о местах курортной зоны;
  • Возможность осуществлять бронирование развлечений (экскурсий, снаряжения и тд);
  • Возможность осуществлять бронирование проживание (тур, отели, дома отдыха, курорты и тд);
  • Возможность осуществлять бронирование транспорта (авиа билетов, жд билетов, такси, автобусов);
  • Возможность осуществлять бронирование питания (столик в ресторане, вызов кейтеринг и тд);

 

Назначение сайта

—   Вывод рекламной информации о мобильном приложении;

—   Осуществление администрирование мобильного приложения;

—   Вывод аналитической информации (с возможностью отправить на принтер и на почтовый адрес);

 

Цель создания мобильного приложения:

—   Агрегирование сервисов курортной зоны России в одной месте;

—   Возможность бронирования путешествий «в один клик»;

—   Обмен сообщениями и отзывами между пользователями;

 

Целевая аудитория сайта:

—   Семейные пары (средний возраст которых родителей 30-35 лет) с маленькими детьми, которые планируют провести отдых на курортных зонах России (Сочи, Крым и тд);

—  Молодежь (от 18 до 30 лет), которая планирует отправиться на зимние курортные зоны (Красная поляна, Кавказ и тд.);

—   Активные люди, которые любят путешествовать по России и сами планируют свой отпуск;

 

 

2.2 Назначение документа

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

Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:

  • Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание, который содержит перечень требований к выполняемым работам.
  • Заказчик согласен со всеми положениями настоящего Технического Задания.
  • Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем Техническом Задании.
  • Исполнитель обязуется выполнить работы в объёме, указанном в настоящем Техническом Задании.
  • Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем Техническом Задании.
  • Все неоднозначности, выявленные в настоящем Техническом задании после его подписания, подлежат двухстороннему согласованию между Сторонами.
  • В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и соответствующим образом оцениваются.

 

  1. Требования к графическому дизайну сайта

3.1 Требования к дизайну сайта

При разработке сайта должны быть использованы преимущественно светлые и контрастные цветовые решения (пример дизайнерских решений: https://habrahabr.ru/post/334722/ ).

Оформление должно быть разработано в достаточно консервативном ключе.

На страницах недолжно быть большого объема текста.

 

В дизайне сайта не должны присутствовать:

— мелькающие баннеры;

— много сливающегося текста;

— тёмные и агрессивные цветовые сочетания и графические решения.

 

Снимок

Рис. Пример формы авторизации

 

3.2 Порядок утверждения дизайн-концепции

Под дизайн-концепцией понимается вариант оформления главной страницы и графическая оболочка внутренних страниц, демонстрирующие общее визуальное (композиционное, цветовое, шрифтовое, навигационное) решение основных страниц сайта. Дизайн-концепция представляется в виде файла (нескольких файлов) в растровом формате или в распечатке по согласованию сторон.

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

 

В этом случае Исполнитель разрабатывает второй вариант дизайн-концепции (дорабатывает, вносит изменения). Обязательства по разработке второго варианта дизайн-концепции Исполнитель принимает только после согласования и подписания дополнительного соглашения о продлении этапа разработки дизайн-концепции на срок не менее пяти рабочих дней. Дополнительные (третий и последующие) варианты разрабатываются Исполнителем за отдельную плату на основании дополнительных соглашений.

 

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

4.1 Классы пользователей

  • Гость – неавторизованный пользователь, обладает правами:
  • Регистрация в мобильном приложении;
  • Авторизация: ввод аутентификационных данных;
  • Авторизованный пользователь обладает правами:
  • Статические разделы – просмотр;
  • Разделы новостей – просмотр;
  • Новости – просмотр;
  • Раздел бронирование билетов – просмотр;
  • Раздел бронирования развлечений – просмотр;
  • Раздел бронирования путевок – просмотр;
  • Раздел бронирования транспорта – просмотр;
  • Видеоролики, фотографии – просмотр, добавление отзыва, редактирование собственного отзыва
  • Обратная связь – создание письма
  • Сообщение в техподдержку – создание заявки
  • Комментарии к разделам и подразделам– просмотр, добавление собственных, редактирование собственных
  • Подписка на рассылки и уведомления
  • Личный кабинет:
  • Информация о пользователе – просмотр, редактирование собственной информации
  • Статистика писем– просмотр собственных писем
  • Список рассылок и уведомлений – просмотр, редактирование, удаление

 

3) Администратор – пользователь, авторизованный в интерфейсе сайта

  • Полный доступ ко всем функциональным возможностям администрирования мобильного приложения:
  • Статические разделы — просмотр, добавление, редактирование, удаление
  • Разделы новостей — просмотр, добавление, редактирование, удаление
  • Новости – просмотр, добавление, редактирование, удаление
  • Статьи – просмотр, добавление, редактирование, удаление
  • Разделы– просмотр, добавление, редактирование, удаление
  • Видеоролики, фотографии – просмотр, добавление, редактирование, удаление
  • Личные данные пользователей – просмотр, редактирование
  • Список рассылок и уведомлений – просмотр, добавление, редактирование, удаление
  • Комментарии к фотографиям, видеороликам, текстам– просмотр, редактирование, удаление
  • Группы пользователей – просмотр, добавление, редактирование, удаление
  • Пользователь — просмотр, добавление, редактирование, удаление, раздача прав
  • Статистика – просмотр

 

4.2 Требования к представлению мобильного приложения

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

 

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

В нижней части экрана должно располагаться горизонтальное меню и включать разделы: Транспорт, Питание, Развлечение, Проживание.

 

Контентная часть главной странице мобильного приложения должна включать:

  • В верхней части должен присутствовать поиск по всем страницам мобильного приложения
  • Слайдер на всю ширину экрана, которые будет включать картинки
  • Вкладки: транспорт, развлечение, питание, путевки, новости, фото-видео галерея, форум.
  • Недавно просмотренные вкладки;
  • Самые популярные направления

Требования к отображению раздела «проживание».

При переходе пользователя на раздел «проживание» пользователю в верхней части экрана

  • должен присутствовать поиск (в котором пользователь может задать город, в который он хочет поехать);
  • ниже должна быть возможность выбрать дата заезда и дату отъезда;
  • рядом должна быть опция выбора количества взрослых, количества номеров и количества детей;
  • Разделы с отелями, хостелами, домами, гостиницами;
  • Во всей остальной части экрана слева должна отображаться фотография места, рядом с правой стороны должны быть написано название места, количество звездочек, отзывы, соотношение цены и качества, спецпредложение;
  • С правой стороны должна отображаться цена, агент (который предоставил информацию, и кнопка посмотреть).

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

  • стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
  • во всю ширину должен располагаться слайдер с фотографиями данного места, справой стороны должна располагаться кнопка поделиться и сохранить в закладки.
  • название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте)
  • Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).

Требования к отображению раздела «развлечения».

При переходе пользователя на раздел «развлечения» пользователю

  • в верхней части экрана должен отображаться поиск (в котором пользователь может задать развлечение, которое он хочет выбрать)
  • Должны присутствовать разделы с самыми лучшими развлечениями, раздел с индивидуальными экскурсиями, раздел с общими экскурсиями, раздел с пешими экскурсиями, раздел с экстремальными экскурсиями.
  • Во всей остальной части экрана слева должна отображаться фотография места, рядом с правой стороны должны быть написано название места, количество звезд, отзывы, соотношение цены и качества, спецпредложение;

 

Требования к внутренним страницам раздела «развлечения».

  • стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
  • во всю ширину должен располагаться слайдер с фотографиями данной экскурсии;
  • название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте);
  • Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).

 

Требования к разрабатываемому разделу «транспорт»

  • Должны присутствовать разделы-выборы авиа-билеты, жд билеты, вызов такси, аренда автобуса;
  • В разделе авиабилеты должен быть календарь с выбором дата отчета и прилета, пунктом отправления и пунктом назначения, класс
  • В разделе авто должны присутствовать выбор тип авто: эконом, «люкс», «комфорт»

 

Требования к разрабатываемому разделу «питание»

  • Вызов питания на дом
  • Заказ столика в ресторане

 

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

  • стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
  • во всю ширину должен располагаться слайдер с фотографиями данной экскурсии;
  • название места, количество звездочек, количество отзывов,
  • ниже должна быть написана цена.

 

 

Требования к внутренним страницам раздела «личный кабинет».

  • После регистрации пользователя у него создается личный кабинет.
  • У пользователя появляются списки меню в нижней части приложения и в боковой части, который открывается с помощью слайдера пальцем.
  • Личный кабинет пользователя находится в боковой части экрана. Там должна быть возможность выбрать фотографию пользователю, выбрать перейти в раздел редактирования личного кабинете. Добавления данных кредитной карты, добавления информации, включения галочки пуш уведовлений.
  • К личному кабинету прикрепляется мониторинг действий (возможно гугл метрика).
  • На основании активности пользователя формируется релевантные предложения

 

 

Требования к странице «оплата».

Оплата путевки, тура, экскурсии, снаряжения и тд.

  • После добавления элемента (путевки и тд) в корзину, пользователю выводится сообщения о том, хочет ли он продолжить покупку чего-нибудь еще и перейти на оплату.
  • После перехода пользователю на вкладку оплаты, если у него не введены данные карты, то ему предлагается вести данные карты (Номер, код, владелец). После введения этих данных пользователь переходит на страницу подтверждения оплаты
  • На странице подтверждения оплаты ему выводится список того, что он выбрал, стоимость заказы, налог на данную услугу, комиссия, если она есть, и итоговая стоимость и кнопка оплатить.
  • После нажатия на кнопку оплатить. Клиенту выводится сообщение, что его заказ принят и обрабатывается. Если у клиента недостаточно денег, то ему выводится сообщение, о том, что у него недостаточно денег и предлагается ему вести другой номер карты или повторить попытку снова.
  • После успешной транзакции на почту клиента приходит чек о совершенной операции.
  • Оплата услуг должна производиться с помощью стороннего сервиса — Payonline.
  • После оплаты пользователю должно вернуться 6% кеш бека со следующей покупки.
  • Передача данных производится внутри приложения с помощь REST или JSON технологии.

Оплата авиа, жд билетов.

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

 

Требования к структуре сайта

  • Сайт создается с целью внесения в ручном режиме информации на сайт.
  • Для выгрузки отчетности

Пользователи группы «Администратор-владелец» могут редактировать все поля. Пользователи группы «Администратор-аналитик» могут выгружать информацию, но не могут редактировать и просматривать информацию о клиентах.

 

Авторизация

Пользователи могут авторизоваться в мобильном приложении, в форме авторизации должны присутствовать:

  • Текстовое поле для ввода логина пользователя
  • Кнопка отправки формы.

 

Данные для доступа (авторизации):

  • Логин – адрес электронной почты пользователя
  • Пароль – строка содержащая от 8 символов, состоящая из A-z, 0-9.

 

Ниже формы располагаются ссылка:

  • Забыли пароль

Форма «Забыли пароль» содержит поля:

  • Email адрес пользователя, указанный при регистрации

При неудачной попытке авторизации – появляется приглашение для повторной попытки

авторизоваться с формой авторизации.

 

Списки рассылок и уведомления

Авторизованные пользователи могут управлять своими списками рассылок, а также

просматривать полученные уведомления.

 

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

Администратор

  • Добавить рассылку
  • Удаление рассылку
  • Редактирование рассылку

 

Авторизованный пользователь

  • Просмотреть список рассылок
  • Подписаться на список рассылок
  • Отписать от списка рассылок
  • Просмотреть уведомления

 

4.4 Требования к разделению доступа

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

Комментарии к статьям и разделам могут оставлять только зарегистрированные пользователи.

 

  1. Требования к видам обеспечения

5.1 Требования к информационному обеспечению

Требования к хранению данных

Все данные сайта должны храниться в структурированном виде под управлением реляционной

СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания

(изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД

размещаются ссылки на них.

Наполнение различных сайтов, функционирование которых поддерживается одной и той же

инсталляцией системы, должно храниться под управлением единой СУБД.

 

Требования к языкам программирования

Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS.

Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).

Для реализации интерактивных элементов клиентской части должны использоваться языки

JavaScript и DHTML.

Для реализации динамических страниц должен использоваться язык PHP.

Для разработки мобильного приложения должен быть использован ReactJS

 

Требования к организации гиперссылок

Все ссылки в мобильном приложении должны быть относительными (за исключением внешних).

Требования к иллюстрациям

Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть

выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.

Требования к объему одной страницы

Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.

 

5.2 Требования к программному обеспечению

Серверная часть:

  • Операционная система семейства Unix (Linux, FreeBSD и пр.)
  • Веб-сервер Apache 1.3.18 и выше
  • Nginx, модуль mod_accel для Apache
  • Набор библиотек и утилит ffmpeg
  • PHP 4.2.0 и выше (должен быть собран как модуль Apache)
  • СУБД MySQL 4.1.14 и выше (предпочтительно: поддержка формата InnoDB).
  • Модули PHP: Mcrypt, FTP, ffmpeg-php
  • Библиотеки PHP: Smarty, GeoIP
  • Возможность доступа к localhost по FTP протоколу
  • 2 пользователя БД

Желательно, чтобы PHP не был запущен в SafeMode.

Клиентская часть:

  • Любой из перечисленный ниже браузеров (указана минимальная версия) с включенным
  • Internet Explorer 6
  • Mozilla 1.6 (Firefox 1.0)
  • Opera 9
  • Adobe Flash Player версии 9 и выше. Сайт должен быть работоспособен (информация,
  • расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и

 

5.3 Требования к техническому обеспечению

Серверная часть:

  • Компьютер с процессором Xeon 4 ядерный
  • 2 ГГц (рекомендуется от 3 ГГц)
  • Оперативная память 4 Гб
  • Место на жестком диске от 1 Гб

Точные технически характеристики сервера будут уточнены после завершения системы и

обширного тестирования всех модулей

 

Клиентская часть:

  • Компьютер с процессором i3 ГГц (рекомендуется от 1.5ГГц)
  • Оперативная память 256 Мб (рекомендуется от 512 Мб)

5.4 Требования к лингвистическому обеспечению

Сайт должен выполняться на русском языке.

5.5 Требования к эргономике и технической эстетике

Дизайн приложения должен быть адаптивный и работать корректно во всех устройствах (Android и IOS) с разрешением экрана 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

 

  1. Требования к приемке-сдаче проекта

6.1 Требования к наполнению информацией

Общие требования к информационному наполнению

Наполнение страниц мобильного приложения должно происходить в автоматическом режиме.

6.3 Требования к персоналу

Для эксплуатации веб-интерфейса сайта от администратора не должно требоваться специальных технических навыков, знания технологий или программных продуктов, за исключением общих навыков работы с персональным компьютером и стандартным веб-браузером (например, MS IE 6.0 или выше).

Администратор, оператор: уверенный пользователь сети Интернет, знание Microsoft Word.

Прочие пользователи: уверенный пользователь сети Интернет.

6.4 Порядок предоставления дистрибутива

По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в

составе:

— архив с исходными кодами всех программных модулей и разделов сайта;

— дамп проектной базы данных с актуальной информацией.

Дистрибутив предоставляется на CD-диске в виде файлового архива.

6.5 Порядок переноса сайта на технические средства заказчика

После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем

производится однократный перенос разработанного программного обеспечения в apple store, google market .

Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и

доступ к базе данных сайта.

6.6 Дополнительные требования

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

Работа любого скрипта не должна превышать 60 секунд.

При условии нагрузки на сервер не более

500.000 обращений к страницам портала в сутки.

Требования к безопасности

Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php-

код скриптов. Требуется разграничение доступа.

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

На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.

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

Система может быть недоступна не более чем 24 часа в год. Резервирование данных осуществляет

хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить

копию сайта

Читайте также:


Добавить комментарий