-
包划分可以重新协商，数据更新应提取为核心业务之一
-
社交互动和检索浏览放一起？
社交互动主要是发帖子/私信，和检索浏览关系不大 -
用户管理和系统管理合并成一个模块
系统管理的处理学者认证/申诉放到用户管理里面 -
PPT 检索浏览和成果管理放在前面
-
学者认证只写认证，不写审核？
咱们管理员是不是只负责审核申诉的（？）在认证的时候是自动进行审核，不是管理员来审 -
用户认证、管理员审核、查看认证是一个用例
挑一个作主路径，其他都是备选路径（？） -
管理个人成果：添加个人成果可以独立出来，其他的没必要
-
检索成果：关键词有啥/筛选啥都要写出来（高级检索和关键字检索是不一样的），最好不用数据库检索。核心是快速准确检索
-
定时更新数据库：从需求角度，应调研数据源更新策略和接口，定义具体的针对每个数据源的需求。可以先不考虑实现。（或者可以直接删，基本没人做出来过）
功能需求共性问题
- 名词的使用应前后一致，用户和学者要么统一要么明确区分
- 图文不一致：图里的活动和文字不一致
- 图的线别拐弯
- 活动图中选择节点的使用
活动图中的行为都由动作节点（圆角矩形）完成，选择节点是伪节点，不应有任何描述 - 扩展用例不要体现在被扩展用例的活动图中，应完全分解
- 活动图可以画成业务流程（包含多个用户的用例），但用例需要分解清楚。
eg：管理员和用户的活动应该分别是两个用例 - “异步结果”应该拆分为（扩展）用例
eg：提交材料（用例），管理员审核（扩展），查看认证结果（扩展），进行申诉（扩展） - 功能分解粒度问题。eg：划分增删改查的粒度太小了，它们并不能成为“单独功能”
- 需求说清楚
非功能需求
- 1000 QPS 甚至 10000 QPS
- 活跃用户 100 万（？！）
- 前端 2-3s 太慢了 -> 1s最好
- 登录超过10次要禁用10min
