Техническое задание на разработку программы это

Как составить техническое задание на создание мобильного приложения, чтобы результат разработки окупил вложенные в проект средства, кто отвечает за ТЗ и почему в нем так важна конкретика, читайте в статье от команды разработчиков Sibdev.

Что такое ТЗ на разработку мобильного приложения

Техническое задание — документ, определяющий будущее проекта. С одной стороны — это техническая инструкция, которая в максимально развернутой и доступной форме описывает технические требования к продукту, с другой — это договоренности об оказании услуг, где кроме технических характеристик приложения, указываются условия реализации: технологии, сроки, порядок оплаты.

1. Утвержденное техзадание — важный документ рабочего процесса.

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

Вопросы, с которых начинается ТЗ на разработку приложения (пример)

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

051. Что нужно сделать, прежде чем садиться за ТЗ – Алексей Бородкин

Ответы клиента на следующие вопросы помогут сторонам лучше понять друг друга и станут основой для структуры техзадания.

Каким он видит приложение?

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

Какова специфика программы?

Для чего клиенту приложение? Если при помощи мобильного ПО предприятие планирует автоматизировать внутренние бизнес-процессы — это один масштаб, если же цель программы — охват внешней аудитории, другой. Специализация определяет потребность в ресурсах на проект, это время и деньги.

Ожидаемая выгода от запуска сервиса?

Перед заказом ТЗ на разработку приложения следует иметь план монетизации инструмента. Будет ли это реклама, доход с продаж или увеличение прибыли за счет оптимизации логистики? В любом случае для расчета рентабельности нового ПО бизнесу нужно понимать собственный потенциал и трезво соизмерять возможности с условиями на рынке.

Каким бюджетом располагает заказчик?

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

Какую платформу выбрать?

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

Разработка технического задания для мобильного приложения iOS или Android (Technical Requiriments)

Кто будет отвечать за внедрение, релиз и отладку?

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

Как написать ТЗ для мобильного приложения

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

Тем не менее качественная техническая документация имеет несколько вполне очевидных критериев:

1. конкретика — все процессы и элементы описаны максимально подробно с использованием чисел;
2. разделение обязанностей — участие и ответственность сторон заранее определены, ясно изложены и зафиксированы;
3. объективность — в ТЗ нет персональных оценок и описаний — «красиво» и «эффективно», но есть факты и общепринятая проф. терминология.

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

Кто составляет ТЗ?

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

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

Поэтому наиболее оптимальным вариантом является написание ТЗ совместно. Взаимодействие заказчика и команды разработчиков наиболее точно поможет зафиксировать требования к продукту.

Эксперты

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

Специалисты, участвующие в составлении техзадания:

1. маркетологи — проводят анализ ЦА приложения, определяют их боли и потребности;
2. программисты — отвечают за проектирование, разработку, внедрение и поддержку мобильного ПО;
3. дизайнеры — создают интерфейс приложения, совмещая визуальные тренды с эффективным юзабилити;
4. авторы — обрабатывают и компилируют данные, облекая, собранную у технических специалистов информацию, в лаконичную, доступную для понимания форму.

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

Требования к разработке ТЗ мобильного приложения

Указанные в предыдущем разделе специалисты — это состав, минимально необходимый для создания адекватного ТЗ. Однако с учетом рыночного и технического многообразия программных решений, этого может оказаться недостаточно.

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

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

Данное решение наиболее комфортно, так как обещает слаженную командную работу, главное достоинство которой — отработанный алгоритм реакции на возникающие возможности, вызовы и риски при создании нового продукта.

Наконец, основополагающим требованием к разработке является ясное понимание компанией-подрядчиком задач и целей продукта, а также условий среды, в которой после релиза окажется приложение клиента.

Схема построения ТЗ для приложения

В техзадании для реализации приложения выделяют определенную структуру:

Вывод

Создание ТЗ на мобильное приложение — неотъемлемая часть цикла разработки. Грамотно составленная документация позволяет контролировать баланс между условиями, которые известны заранее и обстоятельствами, возникающими в ходе проекта.

1. увеличивает шансы создания ПО, в максимальном соответствии с задачами клиента;
2. готовит объективный прогноз сроков и бюджета проекта;
3. сводит к минимуму риск споров между исполнителем и заказчиком из-за разницы в понимании задач и противоречий в методах их решений;
4. снижает вероятность переделок проекта из-за некорректно зафиксированных требований.

Источник: www.sostav.ru

Как составить техническое задание

Рассказываем, как составить техническое задание. Какая информация должна в нем быть и как правильно структурировать данные в ТЗ.

Что такое техническое задание?

ТЗ – это постановка задачи, план действий и обсуждение грядущей работы в одном документе. Техническое задание необходимо в любой сфере деятельности. Строите дом? Нужен четкий план и требования. Делаете веб-сайт?

Тот же сценарий. Любая деятельность сопровождается хотелками заказчика и нормативами, которые обязуется соблюдать исполнитель. Они и заносятся в ТЗ.

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Зачем нужно ТЗ

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

К тому же ТЗ устанавливает регламент, помогающий вести работу в заданном направлении без самодеятельности с обеих сторон. Четко составленный план действий нивелирует разночтения бизнес-решений и помогает избежать нелепых ошибок на полпути.

Также ТЗ формирует ожидаемый результат и дает возможность оценить результат проделанной работы.

Каким должно быть ТЗ

На самом деле, соблюдение четких правил при составлении ТЗ не требуется. Разные компании и предприниматели оформляют задания по-разному. Вопрос в преследуемых целях.

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

Нужно написать небольшой текст на тему «Душевые кабины». Текст должен быть для людей. Без переспама.

А кто-то описывает все в деталях и структурирует каждый аспект:

Нужно написать текст на тему «Душевые кабины» объемом 3500 знаков. Уровень спама – до 55%, уровень воды не более 18%, уникальность – от 90%. Слово «душевые» использовать не более 15 раз. Избегать стоп-слов (и, или, но, а).

Далее мы рассмотрим пункты, которые входят в базовый шаблон ТЗ.

Технические характеристики

Технические аспекты включают в себя четкие требования к оформлению задачи, которые не получится двояко интерпретировать.

В случае с текстами сюда можно отнести:

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

В техническое задание для программистов можно включить:

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

Структура может варьироваться в зависимости от пожеланий заказчика и поставленных задач. Если ширина страницы не имеет значения, то этот пункт можно убрать. Если, к примеру, необходимо использовать синий цвет в заголовках, то это тоже стоит заранее прописать в ТЗ.

Маркетинговые характеристики

Характеристики, помогающие продвижению сайта, сложнее задать так же четко, как технические.

Этот аспект возвращает нас к фразе «текст пишется для людей, а не для роботов», который часто можно увидеть в копирайтерских ТЗ. Тем самым заказчик дает понять, что нужно написать органичный и легко читающийся текст без обилия ключей для оптимизации под поисковые машины. Но как именно автор этого достигнет – не имеет значения.

Заказчик рассказывает о целевой аудитории и ее особенностях. Задача исполнителя – воспользоваться этой информацией и сделать итоговый проект/текст наиболее привлекательным для указанной ЦА.

Этапы работы

Также в техническом задании можно указать все этапы работы, включая промежуточные дедлайны. Это касается больших проектов. Например, в веб-разработке такой план может выглядеть следующим образом:

1. Этап разработки идей и дополнение существующего плана действий.
2. Демонстрация первого прототипа.
3. Приемка первой тестовой версии продукта.
4. Тестирование функциональности.
5. Разработки дизайна.
6. А/Б-тестирование визуальных компонентов и CTA-элементов.

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

Другие аспекты

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

Также стоит внести систему штрафов за корректировки ТЗ, чтобы ни у одной из сторон сделки не было соблазна постоянно редактировать итоговый продукт и менять сроки.

Срок выполнения работы тоже приписывается заранее, как и общий бюджет проекта.

Примеры ТЗ

Рассмотрим два абстрактных примера технического задания в том виде, в котором они часто встречаются.

Для разработчиков

Это сокращенный вариант технического задания, потому что обычно они гораздо больше.

Сайт должен быть выполнен в соответствии с указанным макетом. Цветовая палитра, расположение объектов, шрифты, текст и прочие элементы из Figma должны быть перенесены на итоговый проект.

Текст ТЗ может содержать более конкретную информацию об имеющихся функциях:

• На сайте должна быть форма для загрузки файлов (только в форматах JPG, PNG).
• При скролле должно появляться сообщение с предложением зарегистрироваться.
• Если пользователь долго бездействует (более 20 секунд), должен появляться робот-помощник (его функциональность описана ниже).
• Под каждым материалом на сайте должна быть секциями с комментариями.

Также в ТЗ можно внести требования к дизайну и оформлению кода:

• Цвет подзаголовков берем из макета (#CD6326).
• Списки должны быть оформлены в формате ul > li > a.
• Блочные структуры должны быть реализованы с помощью свойства селекторов flex.

Отдельно можно указать технические средства, используемые в работе:

• Работа должна быть доступна в репозитории my-new-project.
• Каждое изменение должно сопровождаться отдельным коммитом.
• В качестве базы данных используется технология MongoDB.

Для копирайтеров

Текст на тему «Стоит ли использовать WordPress в 2020 году?».

Общие требования к тексту:

1. Статья должна быть поделена на части. Каждый подзаголовок отделяет один логический блок.
2. В тексте необходимо использовать одну таблицу и минимум один список.
3. Между списками, таблицами, цитатами и подзаголовками должно быть расстояние минимум в 400 знаков.
4. В тексте должны быть подзаголовки второго уровня, минимальный промежуток между подзаголовками – 750 символов, максимальный – 900 символов.
5. Ключевые фразы должны быть использованы столько раз, сколько указано в скобках рядом со словом.
6. Ключевые фразы должны быть равномерно распределены по тексту. Расстояние между ключевыми фразами не менее 1000 знаков. Первое ключевое слово должно использоваться в первом абзаце.

Объем текста: от 10 000 знаков.

Примерная структура текста:

1. Что такое WordPress.
2. Основные преимущества WordPress.
3. Сравнение WordPress с другими CMS.

Ключевые фразы:

• WordPress (8)
• Темы для ВордПресс (1)
• CMS WordPress (2)
• Для разработчиков (1)
• Для новичков (2)
• Как установить на сайт WordPress (1)
• Joomla (2)
• Drupal (1)

Вместо заключения

На этом все. Заносите в ТЗ все важные для бизнеса или проекта данные. Ставьте четкие требования и не допускайте разночтений, чтобы не возникало недопониманий и необходимости вносить срочные правки при приближении к сроку сдачи работы.

Источник: timeweb.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 часа в год. Резервирование данных осуществляет

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

Источник: businessarchitecture.ru