From 3d790b2102c4321d1056e10d727fd5318a5198a6 Mon Sep 17 00:00:00 2001 From: Ruslan Bakiev <572431+veikab@users.noreply.github.com> Date: Mon, 4 May 2026 11:20:02 +0700 Subject: [PATCH] Use automatic numbering in specification --- docs/tz-fregat.typ | 443 ++++++++++++++++++--------------------------- 1 file changed, 172 insertions(+), 271 deletions(-) diff --git a/docs/tz-fregat.typ b/docs/tz-fregat.typ index 00240a1..9ac93fe 100644 --- a/docs/tz-fregat.typ +++ b/docs/tz-fregat.typ @@ -9,6 +9,7 @@ #set text(font: "Times New Roman", size: 10.5pt, lang: "ru") #set par(justify: true, leading: 0.58em, first-line-indent: 0pt) #set list(indent: 13pt, body-indent: 5pt) +#set heading(numbering: "1.1") #show link: underline #show raw: set text(font: "Times New Roman") #show heading.where(level: 1): set text(size: 16pt, weight: "bold") @@ -46,14 +47,14 @@ #pagebreak() -= 1. Введение, основание, цель и состав проекта += Общие положения -Настоящее техническое задание описывает разработку программного продукта Личный кабинет Фрегат для поддержки клиентских, менеджерских, заказных, бонусных и интеграционных сценариев в едином веб-интерфейсе. +Настоящее техническое задание описывает разработку программного продукта Личный кабинет Фрегат. -Документ используется для согласования состава работ, функциональных и технических требований, этапов разработки, требований к программной документации, порядка приемки и гарантийного сопровождения. +Документ фиксирует назначение продукта, границы разработки, основные пользовательские контуры, функциональные и технические требования, порядок выполнения работ, приемки и гарантийного сопровождения. -== 1.1 Основание для разработки +== Основание для разработки Разработка программного продукта выполняется на основании следующих документов и материалов: @@ -62,129 +63,10 @@ - приложение №1 к договору: спецификация основных требований к программному обеспечению Личный кабинет Фрегат - согласованные требования заказчика к клиентскому, менеджерскому, бонусному и интеграционному контурам -== 1.2 Цель разработки +== Назначение продукта -Программный продукт Личный кабинет Фрегат предназначен для организации единого цифрового канала взаимодействия между ООО Фрегат Групп и B2B-клиентами компании. - -Система должна обеспечивать: - -- подключение и регистрацию клиентов -- выбор готовой продукции из каталога -- подачу заявок на заказ готовой продукции -- подачу заявок на расчет продукции с индивидуальными параметрами -- согласование стоимости и условий поставки -- сопровождение заказов по статусам -- отправку клиентских уведомлений -- ведение бонусной и реферальной программы - -== 1.3 Объект автоматизации - - -Объектом автоматизации являются процессы клиентского обслуживания и внутренней обработки заявок, выполняемые менеджерами ООО Фрегат Групп при работе с готовой и индивидуальной продукцией. - -== 1.4 Состав системы - - -В состав программного продукта входят: - -- клиентский веб-интерфейс -- менеджерский веб-интерфейс -- серверная бизнес-логика -- база данных -- модуль синхронизации с внешними системами -- модуль уведомлений -- модуль бонусной программы -- модуль административных настроек - -== 1.5 Границы реализации - - -В состав программного продукта входят следующие функциональные области: - -- регистрация и подключение клиента -- профиль клиента и данные компании -- каталог готовой продукции -- карточка товара и выбор параметров -- корзина и заявка на заказ -- заявка на расчет индивидуальной продукции -- обработка заявок менеджером -- список заказов и карточка заказа -- уведомления -- бонусный кабинет -- административные настройки - -Программный продукт не предназначен для выполнения следующих функций: - -- самостоятельного ценообразования клиентом -- ведения бухгалтерского учета -- выполнения функций публичного B2C-магазина -- прямого редактирования клиентом внутренних бизнес-правил компании -- замены учетной системы 1С как первичного источника учетных данных - -== 1.6 Основные принципы работы - - -Система должна обеспечивать следующие базовые принципы: - -- доступ к функциям и данным определяется ролью пользователя -- клиент работает только в пределах собственных данных и данных своего контрагента -- стоимость товара и условия поставки публикуются только после обработки менеджером -- история изменений по заявкам, заказам и бонусным операциям фиксируется в системе -- сведения о товарах, остатках, заказах и статусах могут обновляться из внешней учетной системы - -#pagebreak(weak: true) -= 2. Основания для разработки и нормативные материалы - - -== 2.1 Основания для разработки - - -Разработка программного продукта выполняется на основании следующих документов: - -- договор на разработку программного продукта №28/04-26ПО от 28 апреля 2026 года -- приложение №1 к договору: спецификация основных требований к программному обеспечению Личный кабинет Фрегат -- согласованные требования заказчика к клиентскому, менеджерскому, бонусному и интеграционному контурам - -== 2.2 Нормативные и методические материалы - - -Настоящее техническое задание подготовлено как документ для согласования требований к разработке веб-программного продукта. - -Настоящий документ устанавливает требования к программному продукту применительно к современному веб-решению с разграничением ролей, интеграцией с учетной системой, журналированием событий и поддержкой клиентских и менеджерских сценариев. - -== 2.3 Исходные материалы для детализации требований - - -При разработке технического задания использованы следующие исходные материалы: - -- договорная документация заказчика -- согласованные бизнес-сценарии работы клиента и менеджера -- перечень разделов личного кабинета -- перечень основных товарных направлений и параметров каталога -- требования к обмену данными с учетной системой 1С -- требования к уведомлениям, бонусной программе и административным настройкам - -== 2.4 Назначение настоящего документа - - -Настоящий документ предназначен для: - -- фиксации полного объема требований к программному продукту -- определения состава реализуемых функций -- определения состава данных и интеграционных точек -- определения требований к пользовательским и административным интерфейсам -- определения критериев приемки результата работ -- определения состава артефактов, передаваемых заказчику - -#pagebreak(weak: true) -= 3. Назначение и границы программного продукта - - -== 3.1 Назначение системы - - -Программный продукт Личный кабинет Фрегат предназначен для организации единого цифрового канала взаимодействия между ООО Фрегат Групп и клиентами компании. +Программный продукт предназначен для организации единого цифрового канала взаимодействия между ООО Фрегат Групп и B2B-клиентами компании. Система должна обеспечивать: @@ -197,10 +79,24 @@ - информирование клиентов о значимых изменениях - ведение бонусной и реферальной программы -== 3.2 Границы программного продукта +Объектом автоматизации являются процессы клиентского обслуживания и внутренней обработки заявок, выполняемые менеджерами ООО Фрегат Групп при работе с готовой и индивидуальной продукцией. + +== Границы продукта -В состав программного продукта входят следующие функциональные области: +В состав программного продукта входят: + +- клиентский веб-интерфейс +- менеджерский веб-интерфейс +- административный контур суперменеджера +- серверная бизнес-логика +- база данных +- модуль синхронизации с внешними системами +- модуль уведомлений +- модуль бонусной программы +- модуль административных настроек + +В состав реализации входят следующие функциональные области: - регистрация и подключение клиента - профиль клиента и данные компании @@ -214,9 +110,6 @@ - бонусный кабинет - административные настройки -== 3.3 Функции, не входящие в состав программного продукта - - Программный продукт не предназначен для выполнения следующих функций: - самостоятельного ценообразования клиентом @@ -225,7 +118,7 @@ - прямого редактирования клиентом внутренних бизнес-правил компании - замены учетной системы 1С как первичного источника учетных данных -== 3.4 Пользовательские контуры +== Пользовательские контуры В системе должны быть предусмотрены следующие пользовательские контуры: @@ -240,10 +133,18 @@ Административный контур предназначен для управления настройками каталога, уведомлений, интеграционных параметров и отдельных сервисных настроек системы. -== 3.5 Основные бизнес-сценарии +== Основные принципы работы + +- доступ к функциям и данным определяется ролью пользователя +- клиент работает только в пределах собственных данных и данных своего контрагента +- стоимость товара и условия поставки публикуются только после обработки менеджером +- история изменений по заявкам, заказам и бонусным операциям фиксируется в системе +- сведения о товарах, остатках, заказах и статусах могут обновляться из внешней учетной системы + +== Основные бизнес-сценарии -=== 3.5.1 Подключение клиента +=== Подключение клиента + Потенциальный клиент получает приглашение на регистрацию либо подает заявку на подключение самостоятельно. @@ -251,7 +152,7 @@ + При положительном решении клиенту предоставляется доступ к завершению регистрации. + После завершения регистрации клиент получает доступ к личному кабинету. -=== 3.5.2 Заказ готовой продукции +=== Заказ готовой продукции + Клиент открывает каталог готовой продукции. @@ -263,7 +164,7 @@ + Менеджер указывает стоимость, условия поставки и комментарий. + Система публикует обновленные условия клиенту. -=== 3.5.3 Заявка на расчет индивидуальной продукции +=== Заявка на расчет индивидуальной продукции + Клиент переходит в режим расчета индивидуальной продукции. @@ -271,7 +172,7 @@ + Клиент направляет заявку менеджеру. + Менеджер подготавливает коммерческие условия и публикует их клиенту. -=== 3.5.4 Сопровождение заказа +=== Сопровождение заказа + Заказ получает уникальный идентификатор и статус. @@ -279,7 +180,7 @@ + Клиент отслеживает состав, статус, сроки и иные существенные сведения. + При изменении статуса либо условий система направляет уведомления. -=== 3.5.5 Бонусная и реферальная программа +=== Бонусная и реферальная программа + Для клиента фиксируются правила участия в бонусной программе и, при наличии, реферальные связи. @@ -288,10 +189,10 @@ + Менеджер обрабатывает заявки, связанные с использованием либо выводом бонусов, в пределах установленных правил. #pagebreak(weak: true) -= 4. Функциональные требования += Функциональные требования -== 4.1 Требования к регистрации и подключению клиентов +== Требования к регистрации и подключению клиентов Система должна поддерживать два базовых сценария подключения клиента: @@ -310,7 +211,7 @@ + После завершения регистрации клиент должен получить доступ к личному кабинету. + Система должна поддерживать подключение доступных каналов уведомлений для клиентской учетной записи. -== 4.2 Требования к каталогу готовой продукции +== Требования к каталогу готовой продукции Система должна предоставлять клиенту каталог готовой продукции без отображения цены до обработки менеджером. @@ -326,7 +227,7 @@ + Система должна исключать отображение стоимости до момента публикации условий менеджером. + Для параметров товара система должна отображать пояснения, помогающие клиенту понять назначение параметра и ограничения выбора. -== 4.3 Требования к параметрам каталога и кастомизации +== Требования к параметрам каталога и кастомизации Система должна поддерживать настройку параметров по каждому товарному направлению. @@ -341,7 +242,7 @@ + Наборы стандартных параметров должны редактироваться в административном контуре. + Изменение набора стандартных параметров не должно приводить к потере уже сохраненных заказных данных. -== 4.4 Требования к корзине и заявке на заказ +== Требования к корзине и заявке на заказ Система должна позволять клиенту собрать корзину и направить заявку на заказ. @@ -356,7 +257,7 @@ + Для заявки должны сохраняться дата создания, инициатор и закрепленный менеджер. + До обработки менеджером стоимость в заявке не должна отображаться клиенту. -== 4.5 Требования к обработке заявки менеджером +== Требования к обработке заявки менеджером Менеджер должен иметь возможность обработать клиентскую заявку вручную. @@ -373,7 +274,7 @@ + Менеджер должен иметь возможность перевести заявку в работу. + Менеджер должен иметь возможность отменить заявку с фиксацией основания отмены. -== 4.6 Требования к заявке на расчет индивидуальной продукции +== Требования к заявке на расчет индивидуальной продукции Система должна поддерживать отдельный сценарий расчета продукции с индивидуальными параметрами. @@ -398,7 +299,7 @@ - иные параметры в зависимости от вида продукции - текстовый комментарий клиента -== 4.7 Требования к статусам заявок +== Требования к статусам заявок Система должна обеспечивать сквозное сопровождение заявок по статусам. @@ -420,7 +321,7 @@ - пользователя или источник, выполнивший изменение - комментарий, если он предусмотрен сценарием -== 4.8 Требования к заказам и их сопровождению +== Требования к заказам и их сопровождению Система должна предоставлять клиенту и менеджеру доступ к списку заказов, карточке каждого заказа и актуальным учетным сведениям, полученным из 1С. @@ -436,7 +337,7 @@ + Система должна отображать текущую задолженность клиента, если такие сведения получены из 1С. + Для задолженности должна отображаться дата актуальности данных. -== 4.9 Требования к уведомлениям +== Требования к уведомлениям Система должна поддерживать уведомления по нескольким каналам связи. @@ -456,7 +357,7 @@ - изменение бонусного баланса - обработка заявки на использование либо вывод бонусов -== 4.10 Требования к бонусной и реферальной программе +== Требования к бонусной и реферальной программе Система должна включать бонусный контур как самостоятельную функциональную область с отдельным пользовательским интерфейсом. @@ -473,7 +374,7 @@ + Менеджер должен иметь возможность обрабатывать операции бонусного контура. + Система должна уведомлять клиента об изменениях бонусного состояния. -== 4.11 Требования к административным настройкам +== Требования к административным настройкам Система должна содержать административные разделы для управления следующими объектами: @@ -485,10 +386,10 @@ - отдельными настройками бонусного контура #pagebreak(weak: true) -= 5. Требования к ролям и правам доступа += Требования к ролям и правам доступа -== 5.1 Состав ролей +== Состав ролей В системе должны быть предусмотрены следующие роли пользователей: @@ -497,7 +398,7 @@ - менеджер - суперменеджер -== 5.2 Роль клиента +== Роль клиента Пользователь с ролью Клиент представляет организацию-контрагента и работает только с данными своей компании. @@ -519,7 +420,7 @@ - просмотр бонусного баланса и истории бонусных операций - подача заявки на использование либо вывод бонусов при наличии соответствующих правил -== 5.3 Роль менеджера +== Роль менеджера Пользователь с ролью Менеджер представляет сотрудника компании, закрепленного за клиентами. @@ -538,7 +439,7 @@ - просмотр карточек клиентов, заявок и заказов - выполнение операций в бонусном контуре в пределах полномочий -== 5.4 Роль суперменеджера +== Роль суперменеджера Пользователь с ролью Суперменеджер обладает всеми правами менеджера и дополнительными административными полномочиями. @@ -552,7 +453,7 @@ - управление параметрами интеграции и синхронизации - расширенное управление бонусным и реферальным контуром -== 5.5 Матрица доступа +== Матрица доступа #text(size: 7.6pt)[ @@ -625,7 +526,7 @@ ] -== 5.6 Ограничения доступа и требования к безопасности +== Ограничения доступа и требования к безопасности Система должна обеспечивать: @@ -637,10 +538,10 @@ - хранение истории изменения статусов, условий заявок и бонусных операций #pagebreak(weak: true) -= 6. Требования к данным и сущностям += Требования к данным и сущностям -== 6.1 Общие требования к данным +== Общие требования к данным Основное хранилище данных программного продукта реализуется на PostgreSQL. Прикладной доступ к данным осуществляется через Prisma ORM. @@ -659,7 +560,7 @@ В прикладной реализации должны использоваться фактические сущности базы данных, определенные в schema.prisma. Наименование сущностей в документации и в базе данных должно сопоставляться однозначно. -== 6.2 Справочник сущностей базы данных +== Справочник сущностей базы данных #text(size: 7.6pt)[ @@ -732,7 +633,7 @@ ] -== 6.3 Служебные перечисления и статусы +== Служебные перечисления и статусы В модели данных используются следующие перечисления: @@ -744,10 +645,10 @@ - OrderStatus: NEW, MANAGER_PROCESSING, WAITING_DOUBLE_CONFIRM, CLIENT_REJECTED, MANAGER_REJECTED, MANAGER_BLOCKED, CONFIRMED, IN_PROGRESS, COMPLETED - WithdrawalStatus: PENDING, APPROVED, REJECTED -== 6.4 Пользователи и компании +== Пользователи и компании -=== 6.4.1 Company +=== Company Русское наименование: Компания @@ -769,7 +670,7 @@ - одна компания связана со многими пользователями -=== 6.4.2 User +=== User Русское наименование: Пользователь @@ -799,7 +700,7 @@ - пользователь может выступать клиентом или менеджером в заказах - пользователь может иметь бонусные операции и заявки на вывод -=== 6.4.3 DeliveryAddress +=== DeliveryAddress Русское наименование: Адрес доставки @@ -820,7 +721,7 @@ - createdAt - updatedAt -=== 6.4.4 CounterpartyProfile +=== CounterpartyProfile Русское наименование: Профиль контрагента @@ -849,7 +750,7 @@ - createdAt - updatedAt -=== 6.4.5 RegistrationRequest +=== RegistrationRequest Русское наименование: Заявка на подключение @@ -872,7 +773,7 @@ - createdAt - updatedAt -=== 6.4.6 Invitation +=== Invitation Русское наименование: Приглашение @@ -893,7 +794,7 @@ - acceptedAt - createdAt -=== 6.4.7 MessengerConnection +=== MessengerConnection Русское наименование: Подключение мессенджера @@ -915,10 +816,10 @@ - isActive - createdAt -== 6.5 Каталог и складской контур +== Каталог и складской контур -=== 6.5.1 Product +=== Product Русское наименование: Товар @@ -946,7 +847,7 @@ - createdAt - updatedAt -=== 6.5.2 CatalogProductTypeSetting +=== CatalogProductTypeSetting Русское наименование: Настройки типа товара @@ -976,7 +877,7 @@ - createdAt - updatedAt -=== 6.5.3 Warehouse +=== Warehouse Русское наименование: Склад @@ -993,7 +894,7 @@ - createdAt - updatedAt -=== 6.5.4 ProductStock +=== ProductStock Русское наименование: Складской остаток @@ -1010,10 +911,10 @@ - availableQty - updatedAt -== 6.6 Корзина, заявки и заказы +== Корзина, заявки и заказы -=== 6.6.1 Cart +=== Cart Русское наименование: Корзина @@ -1030,7 +931,7 @@ - createdAt - updatedAt -=== 6.6.2 CartItem +=== CartItem Русское наименование: Позиция корзины @@ -1052,7 +953,7 @@ - createdAt - updatedAt -=== 6.6.3 Order +=== Order Русское наименование: Заказ / заявка @@ -1088,7 +989,7 @@ - kind = CALCULATION означает сценарий расчета индивидуальной продукции - поле calculationPayload хранит параметры расчетной заявки -=== 6.6.4 OrderItem +=== OrderItem Русское наименование: Позиция заказа @@ -1107,7 +1008,7 @@ - unitPrice - createdAt -=== 6.6.5 OrderStatusEvent +=== OrderStatusEvent Русское наименование: Событие статуса заказа @@ -1125,10 +1026,10 @@ - note - createdAt -== 6.7 Бонусный и реферальный контур +== Бонусный и реферальный контур -=== 6.7.1 ReferralLink +=== ReferralLink Русское наименование: Реферальная связь @@ -1146,7 +1047,7 @@ - bonusPercent - createdAt -=== 6.7.2 BonusTransaction +=== BonusTransaction Русское наименование: Бонусная транзакция @@ -1165,7 +1066,7 @@ - referralLinkId - createdAt -=== 6.7.3 RewardWithdrawalRequest +=== RewardWithdrawalRequest Русское наименование: Заявка на вывод бонусов @@ -1185,7 +1086,7 @@ - createdAt - updatedAt -== 6.8 Основные связи между сущностями +== Основные связи между сущностями Укрупненная структура связей определяется следующими правилами: @@ -1199,10 +1100,10 @@ - реферальные связи реализуются через ReferralLink, связывающий одного пользователя с другим пользователем #pagebreak(weak: true) -= 7. Требования к интерфейсу и прототипам += Требования к интерфейсу и прототипам -== 7.1 Карта экранов +== Карта экранов Ниже приведен базовый состав экранов, подлежащих реализации и сопровождению в рамках программного продукта. @@ -1297,12 +1198,12 @@ ] -== 7.2 Маршруты и экранные формы +== Маршруты и экранные формы Ниже приведен перечень экранных форм, предусмотренных в составе frontend-контура программного продукта. -=== 7.2.1 Публичные и клиентские страницы +=== Публичные и клиентские страницы #text(size: 7.6pt)[ @@ -1345,7 +1246,7 @@ ] -=== 7.2.2 Профиль клиента +=== Профиль клиента #text(size: 7.6pt)[ @@ -1379,7 +1280,7 @@ ] -=== 7.2.3 Менеджерские и административные страницы +=== Менеджерские и административные страницы #text(size: 7.6pt)[ @@ -1419,7 +1320,7 @@ ] -=== 7.2.4 Бонусный менеджерский контур +=== Бонусный менеджерский контур #text(size: 7.6pt)[ @@ -1450,7 +1351,7 @@ ] -== 7.3 Общие требования к экранным формам +== Общие требования к экранным формам Экранные формы должны обеспечивать: @@ -1469,10 +1370,10 @@ Ниже приведены низкодетализированные wireframe-прототипы. Они используются как визуальная фиксация состава страниц, ключевых блоков и пользовательских действий. -== 7.4 Клиентские экранные формы +== Клиентские экранные формы -=== 7.4.1 Главная страница клиента +=== Главная страница клиента Назначение страницы: @@ -1497,7 +1398,7 @@ Wireframe-прототип: ) -=== 7.4.2 Каталог продукции +=== Каталог продукции Назначение страницы: @@ -1521,7 +1422,7 @@ Wireframe-прототип: ) -=== 7.4.3 Карточка товара +=== Карточка товара Назначение страницы: @@ -1571,7 +1472,7 @@ Wireframe-прототип: - правила по втулке с логотипом - правила по нанесению индивидуальной надписи -=== 7.4.4 Корзина +=== Корзина Назначение страницы: @@ -1598,7 +1499,7 @@ Wireframe-прототип: ) -=== 7.4.5 Карточка заявки или заказа +=== Карточка заявки или заказа Назначение страницы: @@ -1626,7 +1527,7 @@ Wireframe-прототип: - история статусов - системные комментарии -=== 7.4.6 Страница логина и регистрации +=== Страница логина и регистрации Назначение страницы: @@ -1650,7 +1551,7 @@ Wireframe-прототип: ) -=== 7.4.7 Список заказов +=== Список заказов Назначение страницы: @@ -1664,14 +1565,14 @@ Wireframe-прототип: - таблица заказов - переход в карточку конкретного заказа -=== 7.4.8 Уведомления +=== Уведомления Назначение страницы: - просмотр истории уведомлений по заказам, заявкам и бонусным операциям -=== 7.4.9 Бонусный кабинет +=== Бонусный кабинет Назначение страницы: @@ -1696,10 +1597,10 @@ Wireframe-прототип: ) -== 7.5 Менеджерские экранные формы +== Менеджерские экранные формы -=== 7.5.1 Список клиентов +=== Список клиентов Назначение страницы: @@ -1722,7 +1623,7 @@ Wireframe-прототип: ) -=== 7.5.2 Карточка клиента +=== Карточка клиента Назначение страницы: @@ -1747,7 +1648,7 @@ Wireframe-прототип: ) -=== 7.5.3 Карточка обработки заявки +=== Карточка обработки заявки Назначение страницы: @@ -1775,7 +1676,7 @@ Wireframe-прототип: - история изменений - блок действий со статусом -=== 7.5.4 Список заказов менеджера +=== Список заказов менеджера Назначение страницы: @@ -1792,7 +1693,7 @@ Wireframe-прототип: ) -=== 7.5.5 Настройки каталога +=== Настройки каталога Назначение страницы: @@ -1818,7 +1719,7 @@ Wireframe-прототип: ) -=== 7.5.6 Настройки синхронизации и уведомлений +=== Настройки синхронизации и уведомлений Назначение страницы: @@ -1841,7 +1742,7 @@ Wireframe-прототип: ) -== 7.6 Дополнительные профильные и сервисные страницы +== Дополнительные профильные и сервисные страницы Помимо основных клиентских и менеджерских экранов, программный продукт включает дополнительные экранные формы: @@ -1874,10 +1775,10 @@ Wireframe-прототип: #pagebreak(weak: true) -= 8. Требования к интеграции с 1С и внешним интерфейсам += Требования к интеграции с 1С и внешним интерфейсам -== 8.1 Общие требования к интеграционному контуру +== Общие требования к интеграционному контуру Интеграционный слой должен обеспечивать обмен данными между личным кабинетом и внешними системами без потери целостности внутренних сущностей и статусов. @@ -1892,7 +1793,7 @@ Wireframe-прототип: - повторную обработку неуспешных сообщений - хранение истории обновлений по интеграционным операциям -== 8.2 Интеграция с 1С +== Интеграция с 1С Интеграция с 1С должна обеспечивать обмен данными, необходимыми для сопровождения каталога, заказов, статусов, остатков и сведений о задолженности клиента. @@ -1910,7 +1811,7 @@ Wireframe-прототип: 1С рассматривается как первичный источник учетных данных по заказам, складам, статусам, стоимости, доставке и задолженности. Личный кабинет отображает эти сведения и фиксирует дату их актуальности. -== 8.3 События от 1С +== События от 1С Система должна поддерживать прием webhook-событий от 1С в согласованном формате. @@ -1936,7 +1837,7 @@ Wireframe-прототип: Система должна защищаться от повторной обработки дублей webhook-событий. -== 8.4 Методы получения данных из 1С +== Методы получения данных из 1С Система должна поддерживать получение данных из 1С через согласованные методы. @@ -1952,7 +1853,7 @@ Wireframe-прототип: Точный набор методов, параметры запросов, формат ответов и ограничения по частоте вызовов фиксируются в интеграционной спецификации. -== 8.5 Требования к структурам обмена +== Требования к структурам обмена Входные и выходные данные интеграционного слоя должны описываться в структурированном виде и позволять однозначно восстанавливать: @@ -1968,7 +1869,7 @@ Wireframe-прототип: Точная структура payload, схема подписи запросов и набор обязательных полей согласуются сторонами до начала этапа интеграции с 1С. -== 8.6 Интеграционные поля и служебные атрибуты +== Интеграционные поля и служебные атрибуты Для сущностей, участвующих в обмене, должны поддерживаться: @@ -1980,7 +1881,7 @@ Wireframe-прототип: - журнал интеграционных ошибок при наличии - технический идентификатор последнего обработанного события, если он передается 1С -== 8.7 Журналирование интеграционных операций +== Журналирование интеграционных операций Для ключевых операций обмена система должна сохранять: @@ -1994,7 +1895,7 @@ Wireframe-прототип: - статус обработки сообщения - текст ошибки при наличии -== 8.8 Требования к защите интеграционного обмена +== Требования к защите интеграционного обмена Интеграционные запросы должны выполняться с использованием согласованного механизма авторизации или подписи. @@ -2008,7 +1909,7 @@ Wireframe-прототип: Секреты, используемые для интеграции с 1С, должны храниться только в Vault и передаваться сервисам через runtime-конфигурацию. -== 8.9 Критерии приемки интеграции с 1С +== Критерии приемки интеграции с 1С Интеграция с 1С считается готовой в согласованном объеме, если: @@ -2023,10 +1924,10 @@ Wireframe-прототип: - неуспешные сообщения могут быть проанализированы и повторно обработаны в согласованном порядке #pagebreak(weak: true) -= 9. Техническая архитектура, стек, компоненты и эксплуатационный контур += Техническая архитектура, стек, компоненты и эксплуатационный контур -== 9.1 Общая архитектурная схема +== Общая архитектурная схема Программный продукт реализуется по клиент-серверной модели и включает веб-клиент, сервер бизнес-логики, базу данных, модуль интеграции и вспомогательные сервисы уведомлений. @@ -2037,7 +1938,7 @@ Wireframe-прототип: ) -== 9.2 Состав прикладных сервисов +== Состав прикладных сервисов Согласно действующей карте деплоя в составе проекта используются следующие сервисы: @@ -2051,7 +1952,7 @@ Wireframe-прототип: Основные прикладные сервисы web-frontend и apollo-backend разворачиваются через dokploy_webhook на сервере main. -== 9.3 Технологический стек фронтенда +== Технологический стек фронтенда Клиентская часть программного продукта реализуется на следующих технологиях: @@ -2064,7 +1965,7 @@ Wireframe-прототип: - Storybook — контур изоляционного просмотра компонентов - VitePress — подготовка проектной документации -== 9.4 Технологический стек серверной части +== Технологический стек серверной части Серверная часть программного продукта реализуется на следующих технологиях: @@ -2077,7 +1978,7 @@ Wireframe-прототип: - Zod — валидация структур данных в прикладных сценариях - Nodemailer — отправка уведомлений по электронной почте -== 9.5 Архитектура клиентской части +== Архитектура клиентской части Клиентская часть организована по следующим слоям: @@ -2099,7 +2000,7 @@ Wireframe-прототип: - /catalog-settings — административные настройки каталога - /bonus-program, /bonus-system/\* — бонусный контур -== 9.6 Карта слоев и компонентов +== Карта слоев и компонентов #figure( @@ -2108,7 +2009,7 @@ Wireframe-прототип: ) -== 9.7 Архитектура серверной части +== Архитектура серверной части Серверная часть организована по следующим основным модулям: @@ -2122,7 +2023,7 @@ Wireframe-прототип: - src/prisma-client.js — точка подключения Prisma - src/messenger\*.js, src/telegram\*.js, src/max-mini-app.js — мессенджерный контур и мини-приложения -== 9.8 Взаимодействие фронтенда и backend +== Взаимодействие фронтенда и backend Взаимодействие клиентской и серверной части строится через GraphQL API. @@ -2140,7 +2041,7 @@ Wireframe-прототип: - централизованно передавать авторизационные данные - поддерживать единый клиентский GraphQL endpoint -== 9.9 Интеграционные и вспомогательные HTTP-точки +== Интеграционные и вспомогательные HTTP-точки Помимо GraphQL API, во фронтенд-контуре реализованы вспомогательные серверные маршруты: @@ -2152,7 +2053,7 @@ Wireframe-прототип: - /api/dadata/party — подсказки контрагентов - /api/messenger-avatar/[connectionId] — выдача изображений, связанных с мессенджерными подключениями -== 9.10 Компонентные требования к реализации +== Компонентные требования к реализации Архитектура программного продукта должна сохранять следующие правила: @@ -2164,14 +2065,14 @@ Wireframe-прототип: - серверная логика доступа к данным должна проходить через Prisma - бизнес-правила доступа должны контролироваться серверной частью, а не только интерфейсом -== 9.11 Требования к конфигурации и секретам +== Требования к конфигурации и секретам Сервисы программного продукта должны получать прикладные секреты из Vault. В конфигурации сервисов допускается хранение только bootstrap-параметров для подключения к Vault. Бизнес-секреты, ключи интеграций и иные чувствительные данные должны загружаться из Vault при старте приложения. -== 9.12 Инфраструктура, деплой и эксплуатационный контур +== Инфраструктура, деплой и эксплуатационный контур Текущая инфраструктурная схема проекта включает прикладные сервисы, сервис секретов, мессенджерные сервисы и вспомогательный worker-контур. @@ -2242,7 +2143,7 @@ Wireframe-прототип: Эксплуатационные операции доступа и диагностики выполняются через Tailscale SSH. -== 9.13 Dokploy и цепочка развёртывания +== Dokploy и цепочка развёртывания Для основных сервисов проекта используется режим dokploy_webhook. @@ -2262,7 +2163,7 @@ Wireframe-прототип: - apollo-backend стартует через загрузку Vault env, prisma migrate deploy и запуск src/server.js - bot-сервисы стартуют через общий паттерн загрузки Vault env и запуск node src/server.js -== 9.14 Vault и хранение секретов +== Vault и хранение секретов Сервис vault развернут как отдельное приложение на базе образа hashicorp/vault:1.21.3. @@ -2282,7 +2183,7 @@ Wireframe-прототип: - загружает project secrets - экспортирует секреты в runtime environment процесса -== 9.15 Структура сервисных каталогов +== Структура сервисных каталогов Текущая сервисная структура репозитория: @@ -2296,7 +2197,7 @@ Wireframe-прототип: - vault — Dockerfile, конфигурация и entrypoint Vault - hatchet — docker-compose инфраструктурного контура Hatchet -== 9.16 Контур фоновых процессов +== Контур фоновых процессов В проекте присутствует отдельный контур фонового исполнения задач: @@ -2308,7 +2209,7 @@ Wireframe-прототип: Конфигурация этого контура находится в hatchet/docker-compose.yml. -== 9.17 Зафиксированные runtime-версии и технологические зависимости +== Зафиксированные runtime-версии и технологические зависимости === Базовые runtime и контейнерные образы @@ -2470,7 +2371,7 @@ Wireframe-прототип: ] -== 9.18 Технические конфигурационные файлы +== Технические конфигурационные файлы Ключевые технические файлы текущей реализации: @@ -2486,15 +2387,15 @@ Wireframe-прототип: - vault/entrypoint.sh — startup/unseal логика Vault #pagebreak(weak: true) -= 10. Нефункциональные требования += Нефункциональные требования -== 10.1 Общие требования к архитектуре +== Общие требования к архитектуре Программный продукт должен быть реализован как веб-система с разделением клиентского и менеджерского контуров, серверной бизнес-логикой, постоянным хранением данных и возможностью интеграционного обмена с внешними системами. -== 10.2 Требования к доступности интерфейсов +== Требования к доступности интерфейсов Система должна обеспечивать корректную работу: @@ -2505,7 +2406,7 @@ Wireframe-прототип: Интерфейсы должны сохранять работоспособность и читаемость при адаптивном отображении. -== 10.3 Требования к производительности +== Требования к производительности При штатной эксплуатации система должна обеспечивать: @@ -2516,7 +2417,7 @@ Wireframe-прототип: Точные количественные показатели производительности подлежат фиксации в рабочей документации по инфраструктуре и тестированию. -== 10.4 Требования к безопасности +== Требования к безопасности Система должна обеспечивать: @@ -2527,7 +2428,7 @@ Wireframe-прототип: - хранение и передачу чувствительных данных с использованием защищенных механизмов - исключение несанкционированного доступа к административным функциям -== 10.5 Требования к надежности и журналированию +== Требования к надежности и журналированию Система должна обеспечивать: @@ -2537,7 +2438,7 @@ Wireframe-прототип: - фиксацию ошибок интеграционного обмена - фиксацию значимых системных и пользовательских событий -== 10.6 Требования к сопровождаемости +== Требования к сопровождаемости Реализация должна обеспечивать возможность: @@ -2547,7 +2448,7 @@ Wireframe-прототип: - изменения параметров каталога и уведомлений без переработки базовой структуры системы - расширения интеграционного обмена с 1С и иными внешними системами -== 10.7 Требования к данным и актуальности сведений +== Требования к данным и актуальности сведений Система должна обеспечивать: @@ -2556,7 +2457,7 @@ Wireframe-прототип: - отображение даты актуальности сведений, полученных из внешних систем, когда это применимо - защиту от потери данных при обновлении параметров каталога и заказных сущностей -== 10.8 Требования к документации +== Требования к документации По результатам выполнения работ должна быть сформирована документация, достаточная для: @@ -2566,10 +2467,10 @@ Wireframe-прототип: - понимания состава функций, данных, ролей и интеграций #pagebreak(weak: true) -= 11. Требования к программной документации += Требования к программной документации -== 11.1 Общий подход +== Общий подход Настоящее техническое задание является основным техническим документом программного продукта. @@ -2588,7 +2489,7 @@ Wireframe-прототип: Отдельные документы не должны дублировать техническое задание. Дополнительная документация должна описывать только то, что необходимо для использования, эксплуатации или интеграции программного продукта и не раскрыто в настоящем документе в достаточном объеме. -== 11.2 Пользовательская документация +== Пользовательская документация Пользовательская документация должна быть подготовлена в объеме, достаточном для работы пользователей в предусмотренных ролях: @@ -2611,7 +2512,7 @@ Wireframe-прототип: Документация должна быть написана прикладным языком и ориентирована на выполнение пользовательских сценариев, а не на описание внутренней реализации. -== 11.3 Эксплуатационная документация +== Эксплуатационная документация Эксплуатационная документация должна быть подготовлена в объеме, достаточном для сопровождения программного продукта после передачи результата работ. @@ -2629,7 +2530,7 @@ Wireframe-прототип: Эксплуатационная документация не должна содержать бизнес-секреты, токены, пароли и иные чувствительные значения. Для секретов указываются только имена переменных, назначение и источник получения. -== 11.4 Интеграционная документация +== Интеграционная документация Для интеграции с 1С должна быть подготовлена интеграционная спецификация либо отдельный раздел настоящего технического задания, если к моменту согласования ТЗ формат обмена уже определен. @@ -2648,7 +2549,7 @@ Wireframe-прототип: Если точный формат обмена с 1С не определен на момент утверждения ТЗ, он фиксируется отдельной согласованной интеграционной спецификацией до начала завершающего этапа интеграции. -== 11.5 Перечень сторонних компонентов +== Перечень сторонних компонентов Перечень сторонних компонентов формируется на основании фактических файлов проекта, включая package.json, lock-файлы, Dockerfile и конфигурационные файлы сервисов. @@ -2663,17 +2564,17 @@ Wireframe-прототип: Ключевые сторонние компоненты, используемые в текущей реализации, перечислены в разделе технической архитектуры настоящего технического задания. #pagebreak(weak: true) -= 12. Стадии и этапы разработки += Стадии и этапы разработки -== 12.1 Общий порядок выполнения работ +== Общий порядок выполнения работ Работы выполняются поэтапно, чтобы согласовывать ключевые решения до перехода к следующей части реализации. Переход к следующему этапу выполняется после согласования сторонами результата предыдущего этапа либо после фиксации замечаний, не препятствующих продолжению работ. -== 12.2 Этап 1. Разработка и согласование технического задания +== Этап 1. Разработка и согласование технического задания На этапе разрабатывается и согласуется настоящее техническое задание. @@ -2687,7 +2588,7 @@ Wireframe-прототип: Критерий завершения этапа: утверждение технического задания сторонами. -== 12.3 Этап 2. UX/UI и согласование визуального подхода +== Этап 2. UX/UI и согласование визуального подхода На этапе подготавливаются 2-3 сверстанные страницы личного кабинета с основными элементами интерфейса. @@ -2707,7 +2608,7 @@ Wireframe-прототип: Критерий завершения этапа: согласование визуального подхода сторонами. -== 12.4 Этап 3. Функциональная реализация без интеграции с 1С +== Этап 3. Функциональная реализация без интеграции с 1С На этапе реализуются основные пользовательские и менеджерские сценарии без подключения обмена с 1С. @@ -2732,7 +2633,7 @@ Wireframe-прототип: Критерий завершения этапа: готовность и приемка основного функционала без интеграции с 1С. -== 12.5 Этап 4. Интеграция с 1С и отладка обмена +== Этап 4. Интеграция с 1С и отладка обмена На этапе выполняются подключение, настройка и отладка интеграции с 1С. @@ -2755,7 +2656,7 @@ Wireframe-прототип: Критерий завершения этапа: подтвержденная сторонами работоспособность сценариев с 1С в согласованном объеме. -== 12.6 Этап 5. Передача результата и приемка +== Этап 5. Передача результата и приемка На этапе выполняются итоговая проверка, устранение критичных замечаний и передача результата работ. @@ -2771,10 +2672,10 @@ Wireframe-прототип: Критерий завершения этапа: подписание акта приемки либо наступление условий приемки, предусмотренных договором. #pagebreak(weak: true) -= 13. Порядок контроля, приемки и гарантийного сопровождения += Порядок контроля, приемки и гарантийного сопровождения -== 13.1 Общие положения приемки +== Общие положения приемки Приемка результата работ должна подтверждать соответствие программного продукта требованиям настоящего технического задания, условиям договора и согласованным требованиям заказчика. @@ -2792,7 +2693,7 @@ Wireframe-прототип: - интеграционный обмен с 1С в согласованном объеме - пользовательская и эксплуатационная документация в согласованном объеме -== 13.2 Виды проверок +== Виды проверок Для контроля результата работ используются следующие виды проверок: @@ -2805,7 +2706,7 @@ Wireframe-прототип: - проверка интеграционного обмена с 1С - проверка запуска и работы сервисов в согласованном эксплуатационном контуре -== 13.3 Критерии приемки +== Критерии приемки Программный продукт считается соответствующим требованиям, если: @@ -2821,7 +2722,7 @@ Wireframe-прототип: - текущая задолженность клиента и дата актуальности данных отображаются при наличии этих сведений из 1С - критичные дефекты, препятствующие выполнению основных сценариев, устранены до передачи результата -== 13.4 Передаваемые материалы +== Передаваемые материалы В состав передаваемых заказчику материалов входят: @@ -2836,7 +2737,7 @@ Wireframe-прототип: Технические схемы, модель данных, роли, архитектура, стек, состав сервисов и требования к интеграциям являются частью настоящего технического задания и не дублируются в отдельных документах без отдельного согласования сторон. -== 13.5 Порядок фиксации замечаний +== Порядок фиксации замечаний Каждое замечание, выявленное при приемке, должно содержать: @@ -2850,14 +2751,14 @@ Wireframe-прототип: Замечания, не препятствующие выполнению основных пользовательских и интеграционных сценариев, могут быть зафиксированы сторонами для последующего устранения в согласованном порядке. -== 13.6 Гарантийный срок +== Гарантийный срок Гарантийный срок на разработанные модули, сервисы и дополнительный функционал составляет 6 месяцев с даты подписания акта приемки выполненных работ, если иной порядок не согласован сторонами. Гарантия распространяется на дефекты разработанного программного продукта, проявившиеся при штатной эксплуатации и относящиеся к функционалу, реализованному исполнителем. -== 13.7 Первичная проверка гарантийного случая заказчиком +== Первичная проверка гарантийного случая заказчиком До направления гарантийного обращения заказчик выполняет первичную проверку на своей стороне и исключает причины, не относящиеся к разработанному программному продукту. @@ -2875,7 +2776,7 @@ Wireframe-прототип: Если по итогам первичной проверки заказчик предполагает, что причина относится к разработанному исполнителем функционалу, заказчик направляет гарантийное обращение исполнителю. -== 13.8 Порядок гарантийного обращения +== Порядок гарантийного обращения Гарантийное обращение должно быть передано исполнителю в письменной форме или иным согласованным сторонами способом после первичной проверки на стороне заказчика. @@ -2898,7 +2799,7 @@ Wireframe-прототип: Срок устранения гарантийного дефекта составляет не более 3 дней с даты получения полного обращения, содержащего сведения, достаточные для воспроизведения и диагностики дефекта, либо иной срок, согласованный сторонами с учетом критичности и характера дефекта. -== 13.9 Ограничения гарантийного сопровождения +== Ограничения гарантийного сопровождения Гарантийное сопровождение не распространяется на случаи, когда некорректная работа вызвана: