180 lines
6.1 KiB
Markdown
180 lines
6.1 KiB
Markdown
# 需求定义文档（续）
|
||
|
||
#### 2.3.3 活动图：任务分配与执行流程
|
||
|
||
以下活动图展示了从任务创建到完成的完整业务流程：
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> 任务创建完成
|
||
任务创建完成 --> 选择分配方式
|
||
|
||
state 选择分配方式 {
|
||
[*] --> 手动分配
|
||
[*] --> 智能推荐
|
||
|
||
智能推荐 --> 运行分配算法
|
||
运行分配算法 --> 推荐最佳人选
|
||
推荐最佳人选 --> 确认人选
|
||
|
||
手动分配 --> 选择特定网格员
|
||
选择特定网格员 --> 确认人选
|
||
|
||
确认人选 --> [*]
|
||
}
|
||
|
||
选择分配方式 --> 创建任务分配记录
|
||
创建任务分配记录 --> 更新任务状态为ASSIGNED
|
||
更新任务状态为ASSIGNED --> 通知网格员
|
||
|
||
通知网格员 --> 网格员接收通知
|
||
网格员接收通知 --> 判断是否接受
|
||
|
||
判断是否接受 --> 拒绝: 拒绝
|
||
判断是否接受 --> 接受: 接受
|
||
|
||
拒绝 --> 选择分配方式
|
||
|
||
接受 --> 更新状态为IN_PROGRESS
|
||
更新状态为IN_PROGRESS --> 获取路径规划
|
||
获取路径规划 --> 前往现场处理
|
||
前往现场处理 --> 记录处理过程
|
||
记录处理过程 --> 上传处理结果
|
||
上传处理结果 --> 提交处理结果
|
||
提交处理结果 --> 更新状态为SUBMITTED
|
||
|
||
更新状态为SUBMITTED --> 主管审核结果
|
||
主管审核结果 --> 判断结果是否合格
|
||
|
||
判断结果是否合格 --> 不合格: 不合格
|
||
判断结果是否合格 --> 合格: 合格
|
||
|
||
不合格 --> 填写原因要求重新处理
|
||
填写原因要求重新处理 --> 获取路径规划
|
||
|
||
合格 --> 确认任务完成
|
||
确认任务完成 --> 更新任务状态为APPROVED
|
||
更新任务状态为APPROVED --> 更新反馈状态为CLOSED
|
||
更新反馈状态为CLOSED --> 通知反馈提交者
|
||
通知反馈提交者 --> 更新统计数据
|
||
更新统计数据 --> [*]
|
||
```
|
||
|
||
### 2.4 系统可行性分析
|
||
|
||
#### 2.4.1 技术可行性
|
||
|
||
本系统的技术实现是可行的，主要基于以下分析：
|
||
|
||
1. **前端技术**：市场上已有成熟的前端框架和组件库，可以快速开发出美观、响应式的Web应用，满足不同设备的访问需求。
|
||
|
||
2. **后端技术**：现有的后端框架具备高性能、高并发处理能力，能够满足系统的稳定性和扩展性需求。
|
||
|
||
3. **地图服务**：可以集成成熟的地图API，实现地理位置标记、路径规划等功能，无需从零开发。
|
||
|
||
4. **AI技术**：可以利用现有的自然语言处理和图像识别技术，实现对反馈内容的智能分析和审核。
|
||
|
||
5. **数据存储**：可采用多种数据存储方案，根据系统规模和性能需求灵活选择。
|
||
|
||
#### 2.4.2 经济可行性
|
||
|
||
从经济角度看，本系统的开发和运营是可行的：
|
||
|
||
1. **开发成本**：可以采用主流开源框架和技术栈，降低开发成本和技术门槛。
|
||
|
||
2. **维护成本**：通过模块化设计和完善的文档，可以降低后期维护和升级成本。
|
||
|
||
3. **投资回报**：
|
||
- 提高环境问题处理效率，减少人力资源浪费
|
||
- 降低环境问题带来的经济损失
|
||
- 提升城市环境质量，间接促进经济发展
|
||
- 长期来看具有良好的投资回报
|
||
|
||
4. **社会效益**：改善城市环境质量，提升居民生活满意度，产生显著的社会效益。
|
||
|
||
#### 2.4.3 操作可行性
|
||
|
||
从操作角度看，本系统具有良好的可行性：
|
||
|
||
1. **用户接受度**：
|
||
- 系统界面设计简洁直观，符合用户习惯
|
||
- 操作流程简化，降低学习成本
|
||
- 移动端支持，满足随时随地使用需求
|
||
|
||
2. **培训需求**：系统操作简单，只需简单培训即可上手，降低推广和应用门槛。
|
||
|
||
3. **业务适应性**：系统流程设计符合环境问题处理的实际业务需求，能够无缝融入现有工作流程。
|
||
|
||
4. **组织支持**：系统实施需要相关部门的协调配合，但总体上不会对现有组织架构产生颠覆性影响。
|
||
|
||
#### 2.4.4 法律可行性
|
||
|
||
从法律合规角度看，本系统的实施不存在重大障碍：
|
||
|
||
1. **数据隐私**：系统设计符合数据保护法规要求，对用户隐私数据进行加密存储和严格权限控制。
|
||
|
||
2. **知识产权**：系统开发过程中使用的第三方库和组件均可采用开源或获得授权的方式，避免知识产权风险。
|
||
|
||
3. **合规性**：系统功能和流程设计可以确保符合相关法律法规和行业标准，确保合法合规运营。
|
||
|
||
## 3. 功能性需求
|
||
|
||
### 3.1 功能层次方框图
|
||
|
||
以下功能层次图展示了系统的整体功能架构：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
%% 用户交互层
|
||
subgraph "用户交互层"
|
||
direction LR
|
||
C["公众服务模块\n(问题上报)"]
|
||
H["个人中心模块\n(我的反馈/资料)"]
|
||
D["管理驾驶舱\n(数据决策)"]
|
||
end
|
||
|
||
%% 核心业务层
|
||
subgraph "核心业务层"
|
||
direction LR
|
||
AI["AI分析模块\n(内容审核)"]
|
||
E["任务管理模块\n(分配、流转、执行)"]
|
||
end
|
||
|
||
%% 应用支撑层
|
||
subgraph "应用支撑层"
|
||
direction LR
|
||
F["网格与地图模块\n(LBS & 寻路)"]
|
||
I["文件服务模块\n(附件存取)"]
|
||
end
|
||
|
||
%% 基础服务层
|
||
subgraph "基础服务层"
|
||
direction LR
|
||
B["用户与认证模块"]
|
||
G["系统管理模块\n(用户/权限)"]
|
||
J["日志审计模块"]
|
||
end
|
||
|
||
%% 定义关系
|
||
C -- "提交反馈" --> AI
|
||
AI -- "分析结果" --> E
|
||
C -- "附件" --> I
|
||
E -- "调用" --> F
|
||
E -- "任务附件" --> I
|
||
E -- "统计数据" --> D
|
||
|
||
H -- "查询个人数据" --> E
|
||
|
||
%% 基础服务支撑所有上层模块 (关系隐含)
|
||
G -- "管理" --> B
|
||
|
||
classDef userLayer fill:#d4f1f9,stroke:#05a8e5;
|
||
classDef coreLayer fill:#ffe6cc,stroke:#f7a128;
|
||
classDef appSupportLayer fill:#d5e8d4,stroke:#82b366;
|
||
classDef baseLayer fill:#e1d5e7,stroke:#9673a6;
|
||
|
||
class C,H,D userLayer;
|
||
class AI,E coreLayer;
|
||
class F,I appSupportLayer;
|
||
class B,G,J baseLayer;
|
||
``` |