掌中生活——原型设计与需求分析

掌中生活 2026-10-15 10:55:28

这个作业属于哪个课程	202601福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践团队第二次作业——原型设计&需求分析
团队名称	掌中生活（LifeMap）
这个作业的目标	完成掌中生活（LifeMap）移动端应用的原型设计与需求分析：依据国标框架撰写《软件需求规格说明书》，设计覆盖 11 个典型用户场景的可交互移动端原型，落实团队计划、分工与协作，完成需求分析与原型答辩材料。
其他参考文献	GB/T 8567-2006《计算机软件文档编制规范》；GB/T 35273《信息安全技术个人信息安全规范》；《构建之法——现代软件工程》（第 3 版）

掌中生活——原型设计与需求分析

掌中生活——原型设计与需求分析
一、团队项目计划
1.1 整体安排与里程碑
1.2 计划的检查与落实机制
二、关键点、难点与风险分析
2.1 关键点
2.2 难点
2.3 风险与应对
三、项目分工
四、成员协作方式
4.1 沟通工具
4.2 版本仓库协作
4.3 冲突处理
4.4 任务同步机制
五、软件需求规格说明书
5.1 文档说明
5.2 文档目录结构
5.3 核心内容速览
5.4 撰写过程中的设计思路与问题解决
六、界面原型设计
6.1 原型链接
6.2 设计说明
七、需求分析PPT链接
八、界面原型答辩PPT链接

一、团队项目计划

本次作业从 10 月 9 日发布到 10 月 15 日 23:59 截止，课堂答辩定在 10 月 16 日。我们按"需求分析 → 评审定稿 → 界面原型 → PPT → 博客提交"的顺序推进，一周内完成《软件需求规格说明书》、界面原型、两份 PPT、两份评审表和本博客共七项交付物。

1.1 整体安排与里程碑

里程碑	计划时间	交付内容	负责人	落实情况
M1 需求分析	10-09 ~ 10-12	用户访谈、11 个用户场景、类图与数据模型、说明书 V0.1	吴军峰、胡昊、陈瀚楷	按计划完成
M2 界面原型	10-10 ~ 10-13	移动端可交互原型（10 个页面）	陈志	按计划完成
M3 需求评审与定稿	10-13 ~ 10-14	评审意见闭环、说明书 V1.2、两份评审表	全组（评审表：陈瀚楷）	已完成
M4 PPT 制作	10-14	需求分析PPT、界面原型答辩PPT	李天赐	已完成
M5 博客与提交	10-15	本博客发布、文档 PDF 上传华为云、链接核对	黄炫文	本文即本项交付
课堂答辩	10-16	需求分析与界面原型答辩	杨俊鑫（讲述）	待进行
核心功能开发（后续阶段）	答辩后启动	可运行 MVP：账号与安全 + 记录闭环 + 提醒 + 检索	黄炫文、李天赐	未开始
联调测试（后续阶段）	待课程周历细化	测试记录与缺陷修复清单	陈瀚楷、李天赐	未开始
部署与演示（后续阶段）	待课程周历细化	部署说明与课堂演示	全组	未开始

1.2 计划的检查与落实机制

计划能按期落实，靠三件事：每天晚上八九点大家在 QQ 群里报告当天进度，有问题随时在群里沟通；10-12、10-13、10-14 三个检查点对照里程碑验收，没完成的任务当场商量补救办法；讲述人审查——杨俊鑫提前通读说明书和两份 PPT，把发现的问题反馈到群里，相关同学负责修改。组长盯进度、协调分工，哪里来不及就加派人手，也参与一部分审查。

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

2.1 关键点

需求真实：作业要求"访问软件项目的真实用户"。我们访谈了在校学生、初入职场者、家庭用户三类目标用户，把真实诉求落到 11 个用户场景里，而不是凭想象写需求。
隐私与安全是核心需求：本系统收纳的信息包含证件、合同、发票与账号凭据等个人敏感资料，安全不是附加项。V0.2 版重点新增了信息加密分级（明文 / 受保护）、受保护记录的二次验证和本地账号体系，这是本项目与普通备忘录类应用最大的区别。
三者一致：类图、界面原型、功能描述必须互相印证。我们用统一的 FR / AC / UC 编号体系做跨文档引用，原型上的每个按钮都能在功能描述里找到出处，类图中的每个实体都能在原型里看到数据入口。
国标符合：说明书依据 GB/T 8567-2006 的框架组织章节，所有缩写与术语在 1.3 节事先定义，通篇使用一致的图形符号（PlantUML 绘制）与文字风格。
链接有效：华为云与墨刀原型的分享权限一律设为"任何人可查看"，否则助教打不开链接会直接扣博客排版分。

2.2 难点

用户场景：要具体到"谁、在什么情况下、想做什么、期望什么结果"。我们按"现状 → 目标 → 操作 → 结果"的结构编写 11 个场景，每个场景都标注用户类型与 P0/P1 优先级，可直接作为原型走查和验收演示的脚本。
类图与数据模型：把"资料—日期—提醒—状态—加密"的闭环映射为 12 个领域类、17 条关系，并配 9 张状态图描述对象在事件驱动下的变化；既要覆盖首期功能，又要把云同步、OCR 等后续功能明确划在范围之外。
移动端原型：10 个页面要能走通"录入—提醒—查找—处理"的完整闭环，其中受保护记录的"掩码 / 验证中 / 明文"三态和全局掩码规则是交互设计上最繁琐的部分。
安全需求落地：四层防线（密钥与加密、访问控制与验证、账号与密码、数据边界与隐私）全部在本机完成，登录密码不参与数据加密、忘记密码不丢数据、通知栏不泄露详情——每条都要能对应到界面上的具体表现。

2.3 风险与应对

风险	影响	应对措施
一周完成七项交付物，时间极紧	延期或质量打折	任务拆到人、天粒度检查点、每晚群里同步进度；哪里来不及组长加派人手
多人并行编辑文档产生版本混乱	内容冲突、返工	章节认领制；改动在群里说明，合并冲突由文件主要作者解决、技术负责人仲裁
需求口径在文档、原型、PPT 之间漂移	三处说法对不上，评审和答辩时被指出矛盾	统一 FR / AC / UC 编号做跨文档引用基准；差异记入说明书附录 B 并按"就严"一侧执行；讲述人审查环节专门核对口径
安全需求全面铺开导致首期范围失控	开发量失控、MVP 做不完	用 P0 / P1 / P2 划清边界：短信验证码找回、云同步等明确列入 P2，首期不承诺；约束与假设单列一节写清楚
华为云上传失败或链接权限错误	链接无效扣分	上传后立即用无痕窗口验证；本地保留 PDF 备份
答辩当天演示翻车	答辩 20 分	讲述人提前通读文档和 PPT 并完整演练，墨刀原型支持在线演示，另备录屏兜底

三、项目分工

本次作业 7 人各负责一块：组长负责分工调配和博客，其余成员按"说明书—原型—PPT—评审表"四条线认领任务，任务在 QQ 群里公示。

成员	本次分工
黄炫文（组长）	任务分工与调配；部分内容审查；选题Q&A博客；作业博客撰写与发布；华为云上传与链接核对
吴军峰	需求规格说明书撰写
陈志	界面原型设计（移动端，10 个页面）
胡昊	需求规格说明书撰写
杨俊鑫	课堂答辩讲述；审查协调沟通（通读说明书与两份 PPT，反馈问题并推动修改）
李天赐	需求分析PPT、界面原型答辩PPT 制作
陈瀚楷	两份评审表；协助需求规格说明书完成

另外，各小组需要结合评审表和博客后的评论问题形成一篇"选题Q&A博客"，由组长负责整理，链接将加入本次汇总评审表。

组员工作量比例：

学号	姓名	工作内容	贡献度
102400415	黄炫文（组长）	任务分工与调配、部分审查、选题Q&A博客、作业博客与上传	16%
102400427	吴军峰	需求规格说明书撰写	13%
102400411	陈志	界面原型设计	13%
102400414	胡昊	需求规格说明书撰写	14%
102400331	杨俊鑫	课堂答辩讲述、审查协调沟通	17%
102400418	李天赐	需求分析PPT、界面原型答辩PPT	14%
102400410	陈瀚楷	两份评审表、协助需求规格说明书	13%

贡献度按实际投入估算，经全员复核确认；承担答辩讲述与审查协调的成员适当上浮，合计 100%。

四、成员协作方式

我们的协作方式比较简单，没有搞复杂的流程：任务在 QQ 群里分好，每个人干自己那一块，每天晚上在群里说一声进度，有问题随时在群里问，谁卡住了大家互相搭把手。

4.1 沟通工具

QQ群：协作的主阵地。分工表、截止时间、文件版本都发在群里，重要事项 @全体成员；每天晚上八九点各成员在群里报告当天进度，其他时间有问题随时在群里问，谁看到谁回。
腾讯共享文档：两份评审表直接在线编辑，全组实时可见，不存在版本冲突的问题。
腾讯会议：答辩前演练、需要一起看文档或原型时使用，平时以群聊为主。
CSDN 博客评论区：老师、助教和其他小组的评论问题集中收集，作为选题Q&A博客的素材。

4.2 版本仓库协作

华为云 CodeArts 仓库：全部交付物统一上传仓库（仓库地址），主干分支 main，日常开发在 dev 与 feature/* 分支进行，功能完成后通过合并请求合入；提交信息遵循约定式提交（feat / fix / docs / refactor），合并前通过自查清单。
文档协作：说明书、界面原型与评审表分别维护；文中所有需求编号（FR-xx）、验收用例编号（AC-xx）、用例编号（UC-xx）作为跨文档引用基准，修改需求时必须同步检查受影响的原型与用例。
链接验证：上传后把链接发到群里，由组长用无痕窗口逐一验证能打开、权限正确。

4.3 冲突处理

意见分歧：设计或内容上有不同意见，就在群里把各自理由摆出来讨论，多数人同意就定下来；僵持不下的由组长拍板，定了就不再反复。本次作业就遇到过一回：原型的默认敏感级别比文档里写的更严，讨论后决定按"就严"一侧执行，并把差异记入说明书附录 B。
版本冲突：合并前先拉取远端最新代码，出现冲突由该文件的主要作者负责解决，涉及多人改动时由技术负责人仲裁，解决后重新验证。
进度问题：谁卡住了在群里喊一声，有空的人搭把手；实在完不成的任务由组长协调换人或加派人手，保证整体进度不受影响。

4.4 任务同步机制

分工公示：分工表发到群里，每人明确自己负责什么、截止什么时候。
每日进度汇报：每天晚上八九点各成员在群里报告当天进度，临近截止互相提醒；10-12、10-13、10-14 三个检查点对照里程碑验收。
讲述人审查：负责上台讲述的杨俊鑫提前通读《软件需求规格说明书》和两份 PPT，把发现的问题反馈到群里，再联系制作 PPT 的同学和相关内容负责人修改，改完在腾讯会议上完整演练一遍，确保答辩当天不出差错。
组长兜底：组长负责盯进度、分配任务，哪里来不及就加派人手，也承担一部分审查工作，内容审查以讲述人为主。

协作记录截图：

分工公示：组长在群里发布分工表，成员确认各自任务与截止时间。

每日进度汇报：每天晚上八九点，各成员在群里同步当天完成的内容和遇到的问题。

问题反馈与讨论：讲述人审查发现的问题反馈到群里，相关同学响应修改。

五、软件需求规格说明书

5.1 文档说明

《软件需求规格说明书》以国标 GB/T 8567-2006《计算机软件文档编制规范》中的需求规格说明框架为参照，结合本项目所处课程阶段的实际情况编写，并参照 GB/T 35273 落实个人信息保护要求。文档采用分层描述，随着"层"的深入细节越具体；所有术语、缩略语在 1.3 节统一定义；图表统一使用 PlantUML 绘制，图文并茂、风格统一。

文档明确了自己的四个用途：作为全组对"系统要做什么、不做什么"的统一认识基线；作为后续设计、编码与测试验收的共同依据；作为与真实用户确认需求理解是否一致的书面凭据；作为本课程作业的交付物。项目背景从"生活信息分散在微信、邮箱、支付软件、备忘录、纸质单据五个渠道"这一现状出发，归纳出重复扣费、错过期限、举证困难三类真实代价作为立项动因。

文档链接（华为云仓库，PDF）： 掌中生活LifeMap-软件需求规格说明书-v1.2.pdf

5.2 文档目录结构

1. 引言
   1.1 编写目的　1.2 项目背景　1.3 术语、缩略语与缩写定义　1.4 参考资料
2. 总体描述
   2.1 目标　2.2 用户特征　2.3 约束与假设　2.4 团队组织方式、成员分工与协作方式　2.5 进度安排与里程碑
3. 用户场景
   3.1 用户场景总览　3.2 典型用户场景详述　3.3 用户场景与功能需求的追踪关系　3.4 现有方案对照与差异定位
4. 类图与数据模型
   4.1 建模范围与预计包含的领域类　4.2 类图　4.3 类说明与主要属性　4.4 数据字典
5. 界面原型
   5.1 本章当前状态　5.2 页面清单　5.3 页面跳转关系　5.4 界面验收标准
6. 功能描述及验收验证标准
   6.1 功能结构总览　6.2 具体功能描述　6.3 输入输出格式　6.4 功能验收标准　6.5 交付验收场景
7. 非功能需求
   7.1 可用性　7.2 安全性　7.3 性能与容量　7.4 兼容性　7.5 可靠性与容错
附录 A 评分点与章节对应表　附录 B 待确认与待补充事项清单　附录 C 文档编写约定

5.3 核心内容速览

内容	规模
典型用户场景	11 个（US-01 ~ US-11），覆盖三类用户、四类信息，按"现状→目标→操作→结果"编写
功能需求	9 个功能模块、21 条首期需求（P0 15 条、P1 6 条）+ 6 条 P2 迭代需求（FR-22 ~ FR-27）
类图与数据模型	12 个领域类 + KeyVault 组件，17 条关系；9 张状态图
界面原型	10 个页面（P1 ~ P10）、12 张原型截图、页面跳转关系图
验收标准	界面验收标准 UI-01 ~ UI-14、功能验收用例 AC-xx、4 条交付验收场景
安全设计	四层防线：密钥与加密、访问控制与验证、账号与密码、数据边界与隐私，全部在本机完成

5.4 撰写过程中的设计思路与问题解决

设计思路：先从"信息在哪里、什么时候处理、处理到哪一步"三个问题出发，确定"资料—日期—提醒—状态"四层台账结构，再逐层展开为用户场景、领域类与功能需求，保证每一层都能向上追踪到用户痛点；隐私与安全不放在末尾的"其他需求"里，而是作为与功能并列的核心需求贯穿全文（V0.2 新增账号与安全模块 FR-01 ~ FR-07）。

撰写中遇到的实际问题与解决方式：

产品名不一致：原型界面中的产品名为"密记"，与文档产品名"掌中生活 LifeMap"不一致 → 在 5.2 节明确口径约定：两者指同一产品，正式版统一使用"掌中生活 LifeMap"。
原型与文档的找回方式冲突：原型"账号与安全"页展示的是短信验证码重置，需要联网能力，与首期"不申请网络权限"的数据边界冲突 → 首期改为 FR-04 本地重置（本地验证项 + 注册时下发的一次性恢复码），短信找回列入 FR-27（P2 迭代），并在原型中同步修正。
默认敏感级别不一致：原型将证件类与账号凭据类一并默认设为受保护，严于文档 7.2 节的默认值 → 该差异记入附录 B，实现时按"就严"一侧执行，并在下一版同步 7.2 节表格。
用例图依赖技术边界：系统用例图涉及"系统安全区（生物识别）"参与者，需等技术方案与功能边界评审通过后绘制 → 先以占位形式标注绘制约定（PlantUML），评审通过后补入，不阻塞其他章节进度。

六、界面原型设计

6.1 原型链接

墨刀可交互原型： https://modao.cc/ai/share/6acde85075d0275ef60fd740?pvp=mobile

6.2 设计说明

原型为移动端尺寸（基准 375 × 812，另适配 320 × 568 / 414 × 896），从 21 条功能需求出发规划 10 个页面，遵循五条设计原则：零学习成本、安全零打扰、一屏一事、状态可见、失败可预期。首期共规划 10 个页面：

编号	页面	核心内容
P1	注册 / 登录	本地账号注册与登录，注册时一次性生成恢复码
P2	首页（待办视图）	待办按剩余天数升序、逾期置顶；受保护记录带锁标记
P3	记录列表	物品 / 财务 / 证件 / 账号凭据四类切换，敏感字段掩码
P4	记录详情	基本信息、关键日期节点、附件；受保护记录三态展示
P5	新建 / 编辑记录	类别联动敏感级别、多个日期节点、附件拍照 / 相册 / 文件
P6	附件查看 / 预览	图片缩放、PDF 翻页；受保护附件验证后可见
P7	敏感记录验证（弹层）	生物识别优先，不可用回退密码；连续 5 次失败锁定 5 分钟
P8	搜索与筛选	关键词 + 类别 + 标签 + 日期区间 + 状态组合筛选
P9	账号与安全	修改密码、找回密码、生物识别开关、自动上锁
P10	设置	提醒默认值、类别默认敏感级别、备份与恢复、数据统计

受保护记录的"掩码 → 验证中 → 明文"三态贯穿全原型：未验证时金额显示 ¥••••••、账号显示 138****0000、附件缩略图灰色遮挡；验证通过 2 分钟内免重复验证，切后台自动恢复掩码。全原型使用统一的色彩令牌（主色 #2F6BFF、受保护 #7A5AF8）与组件规范，12 张页面截图已收录在《软件需求规格说明书》5.2 节。

原型界面示例：

首页待办视图（P2）：顶部三个数字卡（今日到期 / 本周到期 / 已逾期），待办按剩余天数升序排列、逾期置顶标红；受保护记录只显示名称、类别、状态和锁标记，金额与附件不露出。