FullAccess 组软件工程实践团队作业第二次 Myriad 原型设计与需求分析

文章目录

1. 团队项目计划
2. 项目关键点难点与风险分析
3. 项目分工
4. 成员协作方式
5. 软件需求规格说明书
6. 界面原型设计
7. 实现设计与当前完成情况
8. 需求分析 PPT 链接
9. 界面原型设计答辩 PPT 链接
10. 评审与作业自检
11. 阶段体会

校园里，一扇关不上的门，可能先后被三个人发现。有人拍下照片，有人写了位置，还有人只留下一句“东门关不严”。对上报者而言，这是三次希望得到回应的反馈；对学校而言，需要解决的是同一个具体问题。

Myriad 希望把这两件事同时做好：同一处问题，管理员只安排一次处理；每一个认真反馈的人，都能收到属于自己的结果。

本次作业沿着这扇门展开：小林如何上报，管理员如何确认与已有反馈是否重复，王师傅如何接单、完工，最后三个人如何看到处理结果。需求、数据关系、界面和验收标准，都围绕这条链路展开。

一、团队项目计划

1.1 从平台设想到校园试点

上一阶段，我们提出面向校园、社区、园区等区域的智能事件汇聚与协作平台。本次需求分析把首版范围落在一所学校，聚焦学校负责的公共设施与环境问题，包括门窗损坏、照明故障、漏水、环境卫生和需要现场处理的安全隐患。

我们保留了选题中最有价值的部分：低门槛上报、重复问题整理、人工确认、处理过程追踪和多人反馈。组织自助入驻、失物招领、自由配置工单模板、AI 优先级算法和路线规划，暂不纳入首版。原因是这些能力分别引入新的管理关系、业务流程或评价方法，会分散对核心流程的验证。

首版设定三种角色：学生和教职工作为上报者，水电、维修、保洁师傅作为工作者，宿管或后勤老师作为区域管理员。用户在地图上选择问题地点，系统根据场所确定负责区域，不要求用户先理解学校的管理分工。

1.2 整体里程碑

下表中，10 月 15 日提交、10 月 16 日答辩来自本次课程要求；后续日期为团队拟定的内部推进目标，将随课程安排和试点反馈调整。

推进顺序是：先确定谁能操作什么，再建立真实数据的处理闭环，随后接入模型，最后通过实际场景检验效果。模型接入有进度波动时，手工处理链路仍能继续开发和验证。

1.3 本次已落实的成果

目前已形成三类角色的界面与交互、71 个 Figma 画面、可离线打开的 HTML 原型、一份需求规格说明书，以及需求分析和界面原型设计两份 PPT。仓库保存源码、素材来源与字体许可，也保留可以直接演示的交付文件。

10 月 15 日的 Chrome 检查在 1440×900 浅色模式下通过 478 项断言，0 失败、0 控制台错误，覆盖主要流程、多个异常分支、设备相册、状态同步与布局。这是本阶段交互原型的验证结果，真实后端、模型效果与手机端验收安排在后续里程碑。

二、项目关键点难点与风险分析

2.1 先把三个对象分清楚

Myriad 最关键的设计，是区分“上报、事件、工单”。上报保存一个人的原始观察；事件代表一个需要解决的具体问题；工单记录安排某位师傅处理这个问题的一次任务。

这一区分直接决定多人反馈能否成立。三个人报告同一扇门，管理员确认后可以把三份上报归入一个事件，再安排一张当前有效工单。师傅完工时，系统根据事件找到三份上报，各自生成消息。原始文字、照片和提交时间都保留，每位用户仍从自己的回执查看结果。

如果把三者混成一张记录，去重时容易丢掉上报者，改派时容易覆盖旧处理过程，完工时也很难判断应该通知谁。因此，领域模型先于页面细节确定。

2.2 四个需要认真处理的难点

另一条容易混淆的规则是“合并”和“一起派工”。前者把同一个具体问题整理成一个事件；后者把同一场所、同一工种的不同问题一起安排给师傅。一起派工后的每个问题仍有自己的工单，必须分别完工。

2.3 风险与应对

三、项目分工

3.1 按交付成果拆分八个工作包

本次围绕已经形成的说明书、两份 PPT、三端原型、共用组件和验证材料拆分八个工作包，每位成员承担主要成果、交叉核对和相应答辩准备，工作量比例各为 12.5%。

合计：100%。 各端成员同时提供本模块的说明书内容、截图和答辩素材。

3.2 怎样让均分真正可执行

每个工作包按“主要成果 2 份额、交叉核对 1 份额、修订与答辩准备 1 份额”安排，八个包共 32 份额。出现难度差异时，优先拆分核对、截图、异常用例和修订任务，让成员之间补位。

交叉核对按表格顺序循环进行：后一位成员检查前一位成员的成果，第一位检查最后一位。核对时提出具体位置、问题和建议，负责人修改后再关闭问题。最终贡献度结合任务完成、审阅和修订记录确认，不能仅用代码行数或 Git 提交次数计算。

四、成员协作方式

4.1 用华为云统一记录任务与讨论

项目的沟通与版本协作统一使用华为云 CodeArts。Myriad 仓库入口保存代码和正式材料；后续任务同步以 CodeArts 工作项及其评论为统一记录，讨论围绕对应任务展开。

任务条目记录目标、负责人、协作人、截止日期、关联需求、验收条件和成果链接。讨论改变业务规则时，把结论补入对应需求文档，并在任务中说明原因和受影响的页面，避免聊天里已经改了、说明书仍保留旧规则。

4.2 版本仓库怎样协作

仓库已经完成 Git 初始化，保留产品文档、源码、素材许可、可离线运行的 HTML、Figma 导入插件和正式交付文件。

后续多人开发采用以下协作流程：

1. 从同步后的 master 创建任务分支，如 feat/report-flow 或 docs/requirements。
2. 围绕一个工作项提交相关修改，使用 类型(范围): 中文说明，避免混入无关文件。
3. 提交合并请求，说明行为变化、关联需求和验证结果，由另一名成员审阅。
4. 相关检查与审阅通过后合入主分支；更新 HTML 或 Figma 数据时，同步提交其对应源码。

仓库中的基础配置、产品设计文档、原型与正式交付物已按内容分别提交。

4.3 冲突怎样处理

同一文件在同一时段明确一位主要修改者。需要共同写作时，先按章节或模块分配，再由负责人整合；Office 文件采用主稿负责人汇总的方式，避免直接合并两个二进制版本。

文本冲突由产生冲突的成员和文件负责人共同核对，先回到需求确认应保留的行为，再处理代码或文字。合并后重新构建并运行相关检查。源码与生成文件同时冲突时，先解决源码，再重新生成 HTML 或插件数据。

成员不能通过覆盖他人改动或强制推送来消除冲突；若涉及业务意见不同，把两种方案、影响和结论写入工作项，方便后续追溯。

4.4 任务怎样保持同步

团队拟定每天固定一次短同步，每位成员更新已完成事项、下一步和阻塞。任务使用“待开始、进行中、待审阅、已完成”四种状态；“已完成”需要成果链接和验收结果，存在阻塞时记录依赖人和预计解决时间。

每个里程碑进行一次共同走查：由未负责该功能的成员按用户路径操作，负责人解释规则并记录问题。需求变更同步到文档、原型和讲述材料；未解决的问题保留在下一轮任务中，不能仅凭口头说明视为关闭。

五、软件需求规格说明书

阅读链接：需求规格说明书 PDF；Word 原始文件。

说明书按引言、总体描述、功能需求、业务流程与状态、外部接口、数据需求、非功能需求、原型与验收逐层展开，附录说明与上一阶段选题的差异。功能需求以 FR 编号，非功能需求以 NFR 编号，用于把讨论中的规则落实到开发和验收。

5.1 用具体场景描述需求

这些场景用于表达和演示需求。为检查规则是否贴近使用过程，我们进一步做了以下访谈；

后续真实用户核对将覆盖学生、后勤管理员和师傅，重点确认上报门槛、补充意愿、完工凭证和消息获取方式。核对时记录日期、匿名角色、原话、原型观察及需求改动。

5.2 类图与数据关系

图中每份上报属于一个当前事件，一个事件包含一份或多份上报；一个事件可以保留多张历史工单，但最多只有一张当前有效工单。补充属于原始上报，分析结果与操作记录保留判断和变更过程，消息记录把处理结果送到需要知道的人。

这里需要特别区分“历史工单很多张”和“同时有效工单一张”。改派会产生新工单，旧工单成为历史记录；旧受派者此后不能再通过旧任务完成当前事件。这个约束同时出现在数据模型、管理端交互和正式后端验收中。

5.3 将需求写成能够判断的标准

验收表中的响应时间是后续要测量的目标。

六、界面原型设计

6.1 两种原型入口

• **Figma 原型**：用于查看设计画面、页面关系和预设跳转，共 71 个画面。
• **HTML 可交互原型**：链接指向华为云仓库中的 prototype/dist/myriad.html；下载文件后用浏览器打开，可操作三端状态、设备相册和本地数据联动。

HTML 默认进入角色选择页，选择管理端、上报者端或工作者端即可体验；若出现登录页，直接点击登录即可进入演示身份。角色选择与免填登录用于课堂演示。Figma 通过预设画面跳转演示，实际设备相册与本地数据变化请在 HTML 中体验。

6.2 一套单据语言连接三个角色

界面借用了现实中的上报联单：上报者使用粉色回执，工作者使用黄色派工单，管理员使用清晰的表格、抽屉和对比窗口。颜色帮助辨认角色，状态章表达处理进度，照片保留现场证据。

手机端只保留当前角色常用的三个入口。上报者是“回执、消息、我的”，工作者是“派工单、消息、我的”；管理端是“待处理、事件、人员”。我们没有增加展示门户、数据大屏或独立 AI 中心，优先让用户顺着任务找到下一步。

6.3 上报者端

上报分为照片、地点和描述三步。照片最多三张，可以不附；有效地点和描述必填。用户可以搜索场所，补充楼层、房间等具体位置，不需要选择工种、管理员或判断是否重复。

提交后保留自己的回执。处理中、已完成、无需处理和补充请求等变化，通过回执与 App 内消息表达。管理员内部如何合并、派给谁、改派几次，不成为上报者必须理解的流程。

6.4 管理端

管理员打开的是“待处理”。列表按补充信息、合并、派工、改派和人工判断等下一步操作组织，每行提供建议与入口。点行打开抽屉，处理后返回原列表位置；需要比较时，再进入按事件分列的对比窗口。

对比窗口同时展示地点、描述、照片、状态和判断依据。三条候选可以只合并两条；A 与 B 相同、B 与 C 相同，不直接推导 A 与 C 也已确认相同。管理员明确判断不同的关系，应在后续建议中继续生效。

“AI 判断”和“推荐”分别标明来源：前者展示支持、矛盾和缺少的证据，后者说明工种、同场所任务和任务数量等固定规则。管理员点“采纳”即确认操作，没有可执行建议时转入查看和人工处理。

6.5 工作者端

师傅拿到的是具体任务：位置、现场照片、问题说明和管理员安排。开始处理后，完工至少提交一张照片；无法处理时填写原因，由管理员决定回复还是改派。

首版不采集师傅实时位置。推荐中的“手上有同一栋楼任务”来自工单查询，只说明已有任务分布。不同问题一起派工后，每件仍需要独立提交完工凭证。

6.6 课堂演示顺序

1. 小林不选照片，在地图上选择 3 号楼，填写“一楼东边的门关不上”。
2. 管理员查看信息不足建议，确认发出补充请求。
3. 小林补充玻璃门照片和“是靠外面那扇玻璃门”的说明。
4. 管理员对比已有上报，确认三份记录属于同一个问题并合并。
5. 管理员派给王师傅，王师傅开始处理、提交完工照片。
6. 小林、小周、小吴的回执都变为已完成，各自收到消息。

这段演示同时覆盖补充、判断、人工确认、派工和多人反馈。之后再选演“不同问题一起派工”或“无法处理后改派”，说明异常流程怎样回到正常处理。

七、实现设计与当前完成情况

7.1 正式系统准备怎样实现

正式系统方案采用 React Native App、React 管理端、FastAPI 后端、PostgreSQL 与 PostGIS、照片存储、后台任务进程和一家多模态模型 API。PostGIS 用于真实场所归属和空间检索，多模态模型用于同时比较文字与照片。

处理过程分为以下步骤：

1. 先保存上报。 后端校验地点和描述，在同一事务中写入上报、事件和分析任务，返回回执。用户不需要等待模型完成。
2. 程序挑选候选。 条件为同一区域、同一场所或 50 米内，且未结束或 30 天内完成；排除不参与比较的记录，最多取 8 个。
3. 模型比较证据。 输入本次事件、候选事件、照片和类型清单；不发送用户姓名、账号等身份信息。
4. 严格检查返回结果。 JSON 包含事件名称、类型、信息是否足够，以及每个候选的 same、different 或 uncertain 判断和证据。超时或格式错误属于调用失败，与“无法确定”分开处理。
5. 管理员确认操作。 合并、补充、派工和无需处理均经过人工确认，后端再次检查当前状态与权限。
6. 完工后分别反馈。 在事务中更新工单、事件、操作记录及消息任务，再投递给相关用户，失败时重试。

AI 负责理解证据，程序负责地点、状态、权限、候选检索和人员排序，管理员负责业务决定。这样每一步都有明确依据，也有出现错误时可以接管的人。

7.2 当前原型实际采用什么方式

八、需求分析 PPT 链接

需求分析报告 PDF｜PPT 原始文件

需求分析报告共 5 页，按“要解决什么、谁来使用、怎样组织数据、状态如何推进”展开：

课堂讲述配合本文的计划与分工表，以及说明书中的领域模型和验收标准，先让听众理解核心流程，再解释细节约束。

九、界面原型设计答辩 PPT 链接

界面原型设计答辩 PDF｜PPT 原始文件

原型设计答辩共 13 页，用同一扇门贯穿三端，随后展开 AI 输入输出、合并、人员推荐、补充和改派：

十、评审与作业自检

10.1 两份评审表

界面原型设计评审表和需求分析评审表按课程要求使用腾讯共享文档。评审内容包括小组与项目名称、被评内容、具体建议及排名；团队收到反馈后，将建议转为 CodeArts 工作项跟踪修改。

界面原型设计评审表

需求分析评审表

10.2 评分要点对应位置

十一、阶段体会

从选题到需求分析，我们逐渐把“让反馈得到回应”拆成了一条条可以检查的规则：原始上报怎样保留，重复问题由谁确认，师傅做不了时怎样继续，完工结果又怎样回到每个人手中。界面上的一个“已完成”，背后需要这些环节共同成立。

Myriad 的这一阶段，以一扇关不上的门作为起点。我们希望下一阶段的成果，能够经得起学生、管理员和师傅的实际使用：问题有人接，处理有依据，结果看得见。让每次上报都有回应，是 FullAccess 接下来继续完善系统的方向。