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

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

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

1.2. Правовая основа

Разработка и ввод в эксплуатацию веб-приложения осуществляется в соответствии с действующим законодательством Российской Федерации, включая Федеральный закон «Об информации, информационных технологиях и о защите информации», нормативные акты в области защиты персональных данных (152-ФЗ), а также внутренними нормативно-распорядительными документами организации. ТЗ разработано на основе предпроектного обследования, утвержденной концепции проекта и технико-экономического обоснования. Все изменения в ТЗ оформляются дополнительными соглашениями и утверждаются сторонами.

1.3. Термины и определения

В настоящем документе используются следующие термины и сокращения: веб-приложение — программное обеспечение, функционирующее в среде браузера и взаимодействующее с серверной частью; API (Application Programming Interface) — программный интерфейс приложения, обеспечивающий обмен данными между компонентами системы; фронтенд — клиентская часть приложения, отвечающая за отображение и взаимодействие с пользователем; бэкенд — серверная часть приложения, реализующая бизнес-логику и работу с данными; REST API — архитектурный стиль взаимодействия компонентов распределенного приложения; база данных — структурированная совокупность данных, хранимых в электронном виде.

2. Цель и область применения

2.1. Цель разработки

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

2.2. Область применения

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

2.3. Ожидаемые результаты

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

3. Архитектура и стек технологий

3.1. Общая архитектура системы

Веб-приложение строится по трехуровневой архитектуре «клиент-сервер» с выделением уровней представления (фронтенд), прикладной логики (бэкенд) и хранения данных (база данных). Коммуникация между уровнями осуществляется посредством REST API, обеспечивающего слабую связанность компонентов и возможность независимого масштабирования. Архитектура предусматривает горизонтальное масштабирование серверной части приложения, балансировку нагрузки и организацию отказоустойчивого кластера баз данных. Безопасность взаимодействия гарантируется использованием протокола HTTPS с актуальными сертификатами и токенизированной аутентификацией.

3.2. Стек технологий фронтенд

Клиентская часть веб-приложения разрабатывается с использованием современного стека технологий, обеспечивающего высокую производительность и богатый пользовательский интерфейс. В качестве основного фреймворка применяется React (версия 18 и выше) с использованием TypeScript для типизации кода. Управление состоянием приложения реализовано через Redux Toolkit с асинхронными операциями на Redux Thunk. Для стилизации используется препроцессор SASS/SCSS и компонентная библиотека Ant Design. Сборка проекта осуществляется с помощью Vite, обеспечивающего быструю разработку и оптимизированную сборку для production-окружения.

3.3. Стек технологий бэкенд

Серверная часть приложения разрабатывается на платформе Node.js с использованием фреймворка NestJS, предоставляющего архитектуру на основе модулей, контроллеров и провайдеров. Взаимодействие с базой данных осуществляется через объектно-реляционный маппер (ORM) TypeORM с использованием паттерна «репозиторий». Для обеспечения производительности и обработки асинхронных задач внедрена очередь сообщений на базе BullMQ с использованием Redis в качестве брокера. Аутентификация пользователей реализована на основе JWT-токенов с поддержкой refresh-токенов и строгой проверкой прав доступа через ролевую модель.

3.4. Система управления базами данных

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

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

4.1. Управление пользователями и аутентификация

Система должна поддерживать регистрацию новых пользователей по приглашениям администратора, а также возможность входа в приложение с использованием электронной почты и пароля. Реализуется механизм двухфакторной аутентификации, использующий одноразовые коды, отправляемые на электронную почту или через мобильное приложение-аутентификатор. Управление профилем пользователя включает изменение контактных данных, смену пароля с проверкой сложности, а также настройку персональных уведомлений. Администратор системы обладает правами блокировки/разблокировки учетных записей, назначения ролей и сброса паролей.

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

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

4.3. Работа с основными сущностями (CRUD)

Приложение предоставляет полный набор операций создания, чтения, обновления и удаления (CRUD) для всех основных бизнес-сущностей, определенных в предметной области. Каждая сущность отображается в виде списка с возможностью фильтрации по множеству критериев, сортировки по одному или нескольким полям, а также постраничной навигации для работы с большими объемами данных. Формы создания и редактирования включают валидацию всех полей как на стороне клиента (для мгновенной обратной связи), так и на стороне сервера (для гарантии целостности данных). Удаление записей выполняется либо полностью, либо с использованием механизма «мягкого удаления», при котором данные помечаются как неактивные и скрываются из интерфейсов, но сохраняются для аудита и восстановления.

4.4. Бизнес-логика и обработка транзакций

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

4.5. Работа с файлами и медиа

Веб-приложение поддерживает загрузку, хранение и отображение различных типов файлов, включая изображения, документы Microsoft Office, PDF-файлы и текстовые документы. Загруженные файлы сохраняются в облачном хранилище с автоматической генерацией уникальных идентификаторов, предотвращающих конфликты имен. Для изображений реализована автоматическая генерация миниатюр и оптимизация размера для ускорения загрузки страниц. Ограничения на размер загружаемых файлов устанавливаются системными настройками и могут быть изменены администратором в зависимости от потребностей бизнеса.

5. Нефункциональные требования

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

Веб-приложение должно обеспечивать время отклика страниц не более 2 секунд при стандартной нагрузке и не более 5 секунд при пиковой нагрузке для 95 процентов запросов. API-эндпоинты должны обрабатывать не менее 1000 запросов в секунду в пиковых режимах при среднем времени обработки каждого запроса не более 300 миллисекунд. Система должна выдерживать одновременную работу не менее 500 активных пользователей без деградации производительности, измеряемой по времени отклика и пропускной способности. Все измерения производительности проводятся на этапе нагрузочного тестирования с использованием специализированных инструментов, и результаты фиксируются в отчете.

5.2. Требования к надежности и отказоустойчивости

Система должна функционировать с коэффициентом готовности 99,9 процентов в годовом исчислении, что соответствует времени простоя не более 8,76 часов в год. Для обеспечения непрерывности работы используется кластеризация серверной части с автоматическим переключением при отказе одного из узлов, а также резервное копирование данных с периодичностью раз в 6 часов и хранением копий в двух физически разнесенных центрах обработки данных. Предусмотрен механизм автоматического восстановления после сбоев с минимальным вмешательством администратора и система мониторинга, оповещающая ответственную группу о любых нарушениях в работе приложения.

5.3. Требования к информационной безопасности

Веб-приложение должно обеспечивать защиту от наиболее распространенных угроз в соответствии с OWASP Top 10, включая инъекции SQL, межсайтовый скриптинг (XSS), подделку межсайтовых запросов (CSRF) и небезопасные десериализации данных. Все каналы передачи данных шифруются с использованием протокола TLS версии 1.2 и выше, а хранение паролей осуществляется с применением солевого хеширования алгоритмом bcrypt. Аудит всех действий пользователей ведется в защищенном хранилище с логированием успешных и неудачных попыток входа, критических операций и изменений конфигурации системы. Периодически, но не реже одного раза в квартал, проводится анализ защищенности кода и инфраструктуры с исправлением выявленных уязвимостей.

5.4. Требования к масштабируемости

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

6. API-спецификация

6.1. Общие принципы построения API

Все взаимодействия между клиентской и серверной частями веб-приложения осуществляются через RESTful API, построенный по принципам ресурсо-ориентированной архитектуры. Каждый ресурс идентифицируется уникальным URL-адресом, а операции над ним определяются HTTP-методами: GET — для получения данных, POST — для создания, PUT или PATCH — для обновления, DELETE — для удаления. Все запросы и ответы передаются в формате JSON с корректно установленными заголовками Content-Type. Версионирование API осуществляется через путь к ресурсу, например /api/v1/users, что позволяет развивать функциональность без нарушения совместимости с существующими клиентами.

6.2. Аутентификация и авторизация в API

Для доступа к защищенным эндпоинтам API требуется передача JWT-токена в заголовке Authorization в формате Bearer <token>. Токен должен быть получен через эндпоинт аутентификации /api/auth/login и имеет время жизни 15 минут, после чего требуется обновление с использованием refresh-токена через /api/auth/refresh. Роли и разрешения пользователя проверяются на уровне контроллеров при помощи декораторов и guards в NestJS, отклоняя запросы с кодом 403 Forbidden при недостатке прав. Все попытки несанкционированного доступа логируются с IP-адресом и временем запроса для выявления подозрительной активности.

6.3. Структура ответов и коды состояния

Все ответы API имеют единую стандартизированную структуру, содержащую статус операции, код ответа и основное тело ответа. Для успешных операций используется HTTP-статус 200 OK (при GET), 201 Created (при POST), 204 No Content (при DELETE). В случае ошибок возвращаются соответствующие статусы: 400 Bad Request — ошибки валидации данных, 401 Unauthorized — отсутствие или невалидный токен, 403 Forbidden — недостаток прав, 404 Not Found — ресурс не найден, 500 Internal Server Error — внутренняя ошибка сервера. Каждый ответ с ошибкой содержит поле message с человекочитаемым описанием проблемы и поле details для технической информации, помогающей отладке.

6.4. Пагинация, фильтрация и сортировка

Эндпоинты, возвращающие коллекции ресурсов, поддерживают параметры пагинации page и limit для управления объемом возвращаемых данных, с ограничением максимального размера страницы в 100 записей. Параметры фильтрации передаются в виде строки запроса с использованием синтаксиса field=value или field__operator=value для более сложных условий, таких как диапазон дат или поиск по подстроке. Сортировка результатов выполняется путем передачи параметра sort=field1,-field2, где знак минуса обозначает убывающий порядок. Все параметры запроса документированы в спецификации OpenAPI и валидируются на этапе выполнения запроса.

7. Схема базы данных

7.1. Концептуальная модель данных

Схема базы данных разработана на основе анализа бизнес-процессов организации и включает сущности, отражающие все аспекты деятельности в рамках автоматизируемой предметной области. Основные сущности включают: users — данные о пользователях системы, roles — справочник ролей и прав доступа, documents — документы и их версии, tasks — задачи и поручения с указанием сроков и ответственных лиц, clients — информация о клиентах и контрагентах. Каждая сущность содержит необходимый набор атрибутов, определенных в процессе предпроектного обследования, с обязательным включением системных полей: идентификатор, время создания, время последнего обновления, признак активности записи.

7.2. Логическая модель и связи между таблицами

Логическая модель данных представлена в виде диаграммы «сущность-связь» и реализует все необходимые связи между таблицами, включая отношения «один ко многим» и «многие ко многим». Ключевые связи включают: пользователи и задачи — связь «один ко многим» (один пользователь может быть ответственным за множество задач), документы и пользователи — связь «многие ко многим» через таблицу связей для маршрутов согласования. Внешние ключи обеспечивают ссылочную целостность данных, гарантируя невозможность создания записей со ссылками на несуществующие сущности. Индексы созданы на всех полях, активно используемых в условиях фильтрации и сортировки запросов, для обеспечения производительности выборок.

7.3. Физическая реализация и оптимизация запросов

Физическая схема базы данных реализована с учетом производительности и включает партиционирование крупных таблиц по временному признаку для ускорения работы с историческими данными. Для полнотекстового поиска по текстовым полям созданы специализированные индексы GIN, обеспечивающие быстрый поиск по ключевым словам в больших объемах текстовой информации. Регулярно, один раз в сутки, выполняется анализ планов запросов с использованием встроенных средств PostgreSQL для выявления и устранения узких мест производительности. Все миграции схемы данных версионируются и управляются через инструмент TypeORM, обеспечивающий согласованность структуры базы данных на всех этапах разработки и эксплуатации.

8. Интерфейс пользователя и опыт взаимодействия

8.1. Общие требования к пользовательскому интерфейсу

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

8.2. Адаптивный дизайн и кроссбраузерность

Все страницы приложения корректно отображаются на экранах с разрешениями от 320 пикселей до 4K, адаптируя расположение и размер элементов под текущее устройство пользователя (настольный ПК, ноутбук, планшет, смартфон). Используется подход «mobile-first» с применением CSS-медиазапросов и гибких сеток, основанных на CSS Grid и Flexbox. Приложение тестируется и корректно работает в актуальных версиях браузеров: Google Chrome (последние 3 версии), Mozilla Firefox (последние 3 версии), Apple Safari (последние 2 версии), Microsoft Edge (последние 2 версии). Для устаревших версий браузеров обеспечивается базовый уровень функциональности с сообщением о необходимости обновления.

8.3. Обратная связь и обработка состояний

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

9. Этапы разработки и сроки

9.1. Планирование и анализ требований

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

9.2. Проектирование и прототипирование

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

9.3. Разработка и внутреннее тестирование

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

9.4. Внедрение и сопровождение

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

10. Требования к документации

10.1. Состав и структура документации

Разработчик обязан предоставить полный комплект документации, включающий: техническое задание в актуальной редакции, руководство администратора системы, руководство пользователя, описание API в формате OpenAPI, схему базы данных, результаты нагрузочного тестирования, акты проведения приемочных испытаний. Каждый документ должен соответствовать требованиям ГОСТ 19 и 34 серии, содержать четкую нумерацию разделов, полное описание функциональности и примеры использования. Документация предоставляется как в электронном виде (в форматах .docx и .pdf), так и в интерактивном виде в самом приложении через встроенную систему помощи.

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

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

11. Порядок приемки и критерии качества

11.1. Приемо-сдаточные испытания

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

11.2. Критерии качества и метрики приемки

Приемка осуществляется на основе следующих количественных критериев: покрытие кода модульными тестами — не менее 85 процентов, время ответа критических API-эндпоинтов — менее 500 миллисекунд при стандартной нагрузке, количество критических ошибок в ходе эксплуатационного тестирования — не более 5 штук, показатель доступности системы — не менее 99,9 процентов. Качественные критерии включают соблюдение принципов UX/UI-дизайна, интуитивно понятную навигацию, соответствие корпоративному стилю заказчика, отсутствие нарушений правил безопасности. Решение о приемке оформляется актом приема-передачи, подписываемым уполномоченными представителями сторон.

11.3. Гарантийные обязательства

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

12. Требования к разработке и контролю качества