342 lines
15 KiB
Markdown
342 lines
15 KiB
Markdown
# 奥迪小红书小程序门户需求规格说明书
|
||
|
||
## 1. 引言
|
||
|
||
### 1.1 目的
|
||
本文档旨在定义奥迪中国小红书小程序门户系统的功能性和非功能性需求，为系统设计、开发、测试和验收提供基准。本系统将支持奥迪中国在小红书平台展示汽车产品信息，并将用户留资信息直接提交至企业 CRM 系统。
|
||
|
||
### 1.2 范围
|
||
本系统范围包括：
|
||
- 小红书小程序门户前端应用（基于H5技术）
|
||
- 内容管理系统（CMS）平台
|
||
- 私有云环境部署
|
||
- 约70个页面的内容建设（基于甲方设计稿）
|
||
- 三年期运维服务（2026-2028年）
|
||
|
||
系统将允许奥迪市场部门管理展示内容，用户可浏览汽车型号信息并提交联系信息表单。表单数据将直接进入企业 CRM 系统，当前平台不保存潜客个人信息。
|
||
|
||
### 1.3 定义、首字母缩写词和缩略语
|
||
|
||
### 1.4 参考资料
|
||
- RFP文档：奥迪小红书小程序门户项目
|
||
- IEEE 830-1998 软件需求规格说明标准
|
||
- 小红书开放平台技术规范
|
||
|
||
### 1.5 概述
|
||
本文档其余部分详细描述了系统的总体特性、具体功能需求、非功能需求、外部接口需求以及相关业务流程。
|
||
|
||
## 2. 总体描述
|
||
|
||
### 2.1 产品愿景
|
||
建立一个安全、可靠、易于维护、便于迁移的小红书小程序门户，使奥迪中国能够在小红书平台高效展示产品信息，通过成熟平台完成内容运营与发布，并将用户留资直接提交至企业 CRM 系统。
|
||
|
||
### 2.2 产品功能
|
||
- **内容管理**：通过成熟的第三方 CMS 平台管理小红书小程序显示内容
|
||
- **页面建设**：基于甲方设计稿建设约 70 个页面，采用模板化方式提升交付效率
|
||
- **内容预览与发布**：支持预览、发布及版本回溯，审批和定时发布为优选能力
|
||
- **用户交互**：用户可浏览车型信息并提交联系信息，数据直接进入企业 CRM
|
||
- **环境与账号管理**：在专有云/私有云环境部署，并提供后台账号与权限管理
|
||
- **内容迁移**：支持内容、素材和配置的全量导出，为后续迁移至其他平台预留条件
|
||
- **运营维护**：每周人工巡检 JV 官网并同步素材，保障平台可用性和内容持续更新
|
||
|
||
### 2.3 用户特征
|
||
| 用户角色 | 描述 | 技术水平 |
|
||
|---------|------|---------|
|
||
| 奥迪业务/市场负责人 | 负责内容方向决策、关键内容审核、月度运营结果确认 | 业务管理与内容审核能力 |
|
||
| 内容运营专员（供应商/联合团队） | 负责页面搭建、内容制作、预览发布及每周人工素材同步 | 基础内容运营与系统操作能力 |
|
||
| 供应商项目与运维负责人 | 负责项目推进、风险管理、私有云环境维护、账号权限与迁移准备 | 专业项目管理与运维技术背景 |
|
||
| 终端用户（小红书用户） | 浏览车型信息并提交联系表单 | 普通智能手机用户 |
|
||
|
||
### 2.4 约束
|
||
- 必须部署在安全的私有云或专有云环境中
|
||
- 必须符合小红书平台技术规范
|
||
- 用户留资必须直接提交到企业 CRM 系统，当前平台不得保存潜客个人信息
|
||
- 必须支持与奥迪官方渠道内容保持一致，但本期以人工周更为主，不依赖自动接口同步
|
||
- 必须满足个人信息保护法规要求
|
||
- 当前范围不包含多品牌内容隔离，仅保留未来扩展可能
|
||
|
||
### 2.5 假设和依赖关系
|
||
- 奥迪中国已获得小红书企业专业号认证和外链权限
|
||
- 企业 CRM 系统可提供可调用的留资接收接口或等效接入机制
|
||
- JV 官网内容可供运营团队每周人工巡检与更新使用
|
||
- 甲方将提供约 70 个页面所需的设计稿、文案和素材指引
|
||
- 私有云/专有云资源申请、账号开通和网络策略可按项目计划完成
|
||
|
||
### 2.6 数据边界与实施拆分
|
||
- 平台保存的内容包括页面内容、媒体素材、配置数据、操作日志和发布记录
|
||
- 平台不保存终端用户留资数据；用户表单提交后数据直接进入企业 CRM
|
||
- 平台应支持内容、素材和配置的全量导出，以支持后续迁移到其他平台
|
||
- 项目实施与报价按以下三部分拆分：
|
||
- Part 1：平台与环境（今年 7 月到明年 6 月）
|
||
- Part 2：约 70 个页面的搭建（基于设计稿）
|
||
- Part 3：日常运维与每周人工同步
|
||
|
||
## 3. 具体需求
|
||
|
||
### 3.1 功能需求
|
||
|
||
#### 3.1.1 平台准备
|
||
**FR-001**: 系统应提供一个成熟的第三方内容管理平台，允许授权用户编辑小红书小程序显示内容。
|
||
|
||
**FR-002**: 内容管理平台应支持以下内容能力：
|
||
- 文本内容编辑
|
||
- 图片上传和管理
|
||
- 页面组件或模板配置
|
||
- 页面布局调整
|
||
- 预览能力
|
||
|
||
**FR-003**: 系统应支持后台账号创建、角色分配与权限控制。
|
||
|
||
**FR-004**: 系统应提供接口或发布机制，将内容管理平台与小红书小程序前端连接。
|
||
|
||
**FR-005**: 供应商应提供可用于评标演示的 Demo，覆盖关键内容管理和前台浏览留资流程。
|
||
|
||
#### 3.1.2 环境准备
|
||
**FR-006**: 系统必须部署在安全的私有云或专有云环境中。
|
||
|
||
**FR-007**: 云环境应包含以下组件：
|
||
- Web服务器
|
||
- 应用服务器
|
||
- 内容与配置数据库
|
||
- 素材存储
|
||
- 监控和日志系统
|
||
|
||
**FR-008**: 系统应实施网络安全措施，包括防火墙、访问控制、数据传输加密和日志审计。
|
||
|
||
**FR-009**: 系统应支持平台登录账号的开通、停用和权限维护。
|
||
|
||
#### 3.1.3 门户维护与迁移准备
|
||
**FR-010**: 系统应保证 99.5% 的正常运行时间。
|
||
|
||
**FR-011**: 系统应实现自动备份机制，保留内容与配置源环境至少 1 个月。
|
||
|
||
**FR-012**: 系统应具备性能监控和优化能力，防止性能下降。
|
||
|
||
**FR-013**: 系统应建立集成测试、故障排除、回滚和事件响应机制。
|
||
|
||
**FR-014**: 系统应支持内容、素材和关键配置数据的全量导出，以便未来迁移到 Audi 其他平台或第三方平台。
|
||
|
||
#### 3.1.4 内容建设与运营
|
||
**FR-015**: 系统应支持基于甲方设计稿搭建约 70 个页面，采用可复用的模板和内容模型提高交付效率。
|
||
|
||
> **FR-015a 页面类型与模板规范**
|
||
>
|
||
> 系统采用**模板注册表（Template Registry）**架构，将页面类型与预览/编辑组件解耦：
|
||
>
|
||
> - **页面类型（pageType）**：约 70 种，代表每个具体页面（如"车型页"、"专题页"、"活动页"等）。
|
||
> - **页面模板（PageTemplate）**：约 30 种可复用模板，每个模板包含独立的预览组件（Preview）和编辑字段组件（Editor）。
|
||
> - **多对一映射**：多个页面类型可共用同一模板。例如"车型页"和"活动页"共用 `car-page` 模板。
|
||
>
|
||
> 每个模板定义以下内容：
|
||
> | 配置项 | 说明 |
|
||
> |--------|------|
|
||
> | `templateId` | 模板唯一标识（如 `car-page`、`topic-page`） |
|
||
> | `pageTypes` | 该模板适用的页面类型列表 |
|
||
> | `defaultValues` | 新建内容时的默认字段值 |
|
||
> | `PreviewComponent` | 手机端预览渲染组件 |
|
||
> | `EditorComponent` | 后台编辑字段渲染组件 |
|
||
> | `onSourceCarSelected` | 选择来源车型后的数据填充回调 |
|
||
>
|
||
> **扩展方式**：新增页面类型时，若已有合适模板，只需在注册表中添加一行映射；若需要全新预览布局，则新建模板文件夹并注册，主组件无需修改。
|
||
|
||
**FR-016**: 供应商应每周人工巡检 JV 官网内容，并根据巡检结果更新小程序中的车型图片和相关内容。
|
||
|
||
**FR-017**: 内容更新应支持以下操作：
|
||
- 批量图片替换
|
||
- 文案更新
|
||
- 新页面或新车型页面添加
|
||
- 旧页面或旧车型页面下架
|
||
- 发布前预览
|
||
|
||
**FR-018**: 系统应记录所有内容变更历史，支持版本回溯。
|
||
|
||
**FR-019**: 系统宜支持草稿审批和定时发布；若所选成熟平台不具备该能力，不应作为本期上线阻断条件。
|
||
|
||
#### 3.1.5 项目管理与服务交付
|
||
**FR-020**: 系统供应商应提供日常账户服务、时间线管理、风险管理、质量控制和会议材料准备。
|
||
|
||
**FR-021**: 供应商应每周举行进度更新会议，解决出现的问题。
|
||
|
||
**FR-022**: 供应商应每月提供运营报告，并与奥迪中国进行审查。
|
||
|
||
**FR-023**: 对于关键/高优先级事件，供应商应提供专门的事件报告。
|
||
|
||
**FR-024**: 项目实施与报价应明确拆分为平台与环境、约 70 个页面搭建、日常运维与每周同步三部分。
|
||
|
||
#### 3.1.6 运维支持与值班
|
||
**FR-025**: 系统应提供关键/高优先级事件支持机制：工作日服务时间 08:30-17:30，非服务时间 17:30-08:30 待命支持。
|
||
|
||
**FR-026**: 系统应在周末及法定节假日提供关键/高优先级事件 7x24 待命支持。
|
||
|
||
### 3.2 非功能需求
|
||
|
||
#### 3.2.1 性能需求
|
||
**NFR-001**: 小程序前端关键页面响应时间不应超过 3 秒（在正常网络条件下）。
|
||
|
||
**NFR-002**: 系统应支持同时处理 1000 个并发用户浏览和留资提交请求。
|
||
|
||
#### 3.2.2 安全需求
|
||
**NFR-003**: 系统必须实施用户身份验证和授权机制。
|
||
|
||
**NFR-004**: 用户留资数据在传输过程中必须加密，并直接提交至企业 CRM；当前平台不得持久化存储潜客个人信息。
|
||
|
||
**NFR-005**: 系统必须符合《个人信息保护法》要求，明确告知用户数据用途并获得同意。
|
||
|
||
#### 3.2.3 可用性需求
|
||
**NFR-006**: 内容管理界面应直观易用，新用户可在 30 分钟内掌握基本操作。
|
||
|
||
**NFR-007**: 系统应提供详细的帮助文档和操作指南。
|
||
|
||
#### 3.2.4 可维护性需求
|
||
**NFR-008**: 系统应采用模块化设计，便于功能扩展和维护。
|
||
|
||
**NFR-009**: 系统应保留必要的操作日志、发布记录和维护文档，便于运维和交接。
|
||
|
||
#### 3.2.5 可移植性需求
|
||
**NFR-010**: 系统应使用标准开放平台接口，支持与其他系统进行数据交换。
|
||
|
||
**NFR-011**: 内容、素材和配置应能轻松导出并迁移到其他平台，避免供应商锁定。
|
||
|
||
#### 3.2.6 供应商能力与交接需求
|
||
**NFR-012**: 供应商团队应具备小红书小程序集成、应用、云、安全与数据相关实践经验。
|
||
|
||
**NFR-013**: 项目管理核心角色应具备 PMP 或同等级项目管理资质。
|
||
|
||
**NFR-014**: 供应商应说明对现有技术平台、基础设施和 IT 能力的复用方案，并优先采用成熟现成平台降低重复建设成本。
|
||
|
||
**NFR-015**: 供应商应保证项目资源充足，关键岗位需设置备份人选以确保按期上线。
|
||
|
||
**NFR-016**: 供应商应在项目期提供技术支持与知识转移，至少包含系统架构、运维操作、常见故障处理和交接文档。
|
||
|
||
### 3.3 外部接口需求
|
||
|
||
#### 3.3.1 用户接口
|
||
**UI-001**: 小红书小程序前端应采用响应式设计，适配各种移动设备屏幕。
|
||
|
||
**UI-002**: 内容管理后台应提供清晰的导航、预览和操作反馈。
|
||
|
||
#### 3.3.2 硬件接口
|
||
无特殊硬件接口需求。
|
||
|
||
#### 3.3.3 软件接口
|
||
**SI-001**: 系统应提供 CMS 与小程序前端之间的内容发布或内容获取接口。
|
||
|
||
**SI-002**: 小程序留资流程应支持直接对接企业 CRM 接收接口或等效机制，平台不保留留资数据副本。
|
||
|
||
**SI-003**: 与 JV 官网的内容更新流程以人工巡检和人工同步为主，本期不将自动对接官网接口作为前置条件。
|
||
|
||
#### 3.3.4 通信接口
|
||
**CI-001**: 所有外部通信必须使用 HTTPS 协议。
|
||
|
||
**CI-002**: 内容接口和 CRM 提交接口应实施认证、速率限制或等效安全控制机制。
|
||
|
||
## 4. 业务流程
|
||
|
||
### 4.1 内容管理流程
|
||
|
||
```mermaid
|
||
graph TD
|
||
A[内容运营专员登录CMS] --> B[按设计稿新建或维护页面]
|
||
B --> C[上传素材并编辑图文内容]
|
||
C --> D[预览页面效果]
|
||
D --> E{是否启用审批流程}
|
||
E -->|是| F[提交业务/市场负责人审核]
|
||
E -->|否| G[直接发布]
|
||
F --> H{审核通过?}
|
||
H -->|是| G
|
||
H -->|否| I[返回内容运营专员修订]
|
||
G --> J[发布到小红书小程序]
|
||
J --> K[记录版本与操作日志]
|
||
```
|
||
|
||
### 4.2 用户交互流程
|
||
|
||
```mermaid
|
||
graph TD
|
||
A[用户访问小红书笔记] --> B[点击外链进入小程序]
|
||
B --> C[浏览车型信息]
|
||
C --> D{感兴趣?}
|
||
D -->|是| E[填写联系信息表单]
|
||
D -->|否| F[离开页面]
|
||
E --> G[提交表单]
|
||
G --> H{验证通过?}
|
||
H -->|是| I[显示感谢页面]
|
||
H -->|否| J[显示错误信息]
|
||
I --> K[数据直接提交至企业CRM]
|
||
```
|
||
|
||
### 4.3 运维管理流程
|
||
|
||
```mermaid
|
||
graph TD
|
||
A[内容运营专员每周巡检JV官网] --> B[识别素材或页面变更]
|
||
B --> C[在CMS中更新对应内容]
|
||
C --> D[预览并发布]
|
||
D --> E[项目与运维负责人记录周更结果]
|
||
E --> F[系统监控与备份巡检]
|
||
F --> G{发现异常?}
|
||
G -->|是| H[触发告警并组织响应]
|
||
G -->|否| I[继续正常运营]
|
||
H --> J[输出事件报告或月报输入]
|
||
```
|
||
|
||
## 5. 术语表
|
||
|
||
| 中文术语 | 英文术语 | 业务定义 |
|
||
|---------|---------|---------|
|
||
| 小红书小程序 | Red Note Mini App | 在小红书平台内运行的轻量级应用，用于展示产品信息和收集用户数据 |
|
||
| 内容管理系统 | Content Management System (CMS) | 用于创建、管理和修改数字内容的软件应用程序 |
|
||
| 私有云 | Private Cloud | 专为单一组织构建的云计算环境，提供更高的安全性和控制 |
|
||
| 外链 | External Link | 从小红书笔记指向外部网站的链接 |
|
||
| 运维 | Operations and Maintenance | 系统上线后的日常监控、维护和支持活动 |
|
||
| 企业 CRM | Enterprise CRM | 用于接收和管理用户留资信息的企业客户关系管理系统 |
|
||
| 表单 | Form | 用于收集用户输入信息的网页元素集合 |
|
||
| API集成 | API Integration | 不同软件系统之间通过应用程序编程接口进行数据交换和功能调用 |
|
||
| 内容同步 | Content Synchronization | 保持多个系统或平台之间内容一致性的过程，本期以人工周更为主 |
|
||
|
||
## 附录A: 异常流程
|
||
|
||
### A.1 内容更新异常流程
|
||
1. **异常情况**: JV 官网图片或文案无法获取
|
||
- **处理流程**:
|
||
- 系统记录错误日志
|
||
- 发送告警通知给运维团队
|
||
- 使用上次成功同步的图片作为临时替代
|
||
- 运维团队手动介入解决
|
||
|
||
2. **异常情况**: 内容发布失败
|
||
- **处理流程**:
|
||
- 系统自动回滚到上一版本
|
||
- 通知内容管理员
|
||
- 提供详细的错误信息
|
||
- 记录失败原因用于后续分析
|
||
|
||
### A.2 用户表单提交异常流程
|
||
1. **异常情况**: 表单验证失败
|
||
- **处理流程**:
|
||
- 高亮显示错误字段
|
||
- 提供具体的错误提示
|
||
- 保留用户已输入的正确信息
|
||
- 允许用户修正后重新提交
|
||
|
||
2. **异常情况**: CRM 提交失败
|
||
- **处理流程**:
|
||
- 显示友好的错误页面
|
||
- 自动重试机制（最多3次）
|
||
- 如果仍失败，提示用户稍后重试或联系官方渠道
|
||
- 记录失败日志并通知相关接口负责人排查
|
||
|
||
### A.3 系统故障异常流程
|
||
1. **异常情况**: 服务器宕机
|
||
- **处理流程**:
|
||
- 自动切换到备用服务器
|
||
- 发送紧急告警给运维团队
|
||
- 启动故障排查程序
|
||
- 如30分钟内无法恢复，执行回滚计划
|
||
|
||
2. **异常情况**: 安全漏洞检测
|
||
- **处理流程**:
|
||
- 立即隔离受影响组件
|
||
- 通知安全团队
|
||
- 实施临时防护措施
|
||
- 进行全面安全审计 |