软件工程实践团队第二次作业——原型设计&需求分析

[七匹狼]

七匹狼——第二次作业：原型设计与需求分析

项目	内容
这个作业属于哪个课程	202601福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践团队第二次作业——原型设计&需求分析
团队名称	七匹狼
团队项目	食话说——校园美食推荐及评论分析 Web 端
这个作业的目标	完成团队项目计划、需求规格说明书、界面原型、需求分析 PPT、原型答辩 PPT、团队分工和协作说明
其他参考文献	GB/T 9385-2008《计算机软件需求规格说明规范》；GB/T 8567-2006《计算机软件文档编制规范》；《构建之法》；课程组需求分析资料

目录

• 七匹狼——第二次作业：原型设计与需求分析
• 一、团队项目计划
• 1.1 项目背景与目标
• 1.2 本次作业交付范围
• 1.3 项目里程碑
• 1.4 计划验收方式
• 二、关键点、难点与风险分析
• 2.1 项目关键点
• 关键点一：推荐结果必须能够解释
• 关键点二：评论原文和系统分析结果分开
• 关键点三：数据来源和更新时间清楚
• 关键点四：筛选条件要区分必要条件和偏好
• 关键点五：异常流程也属于需求
• 2.2 主要难点
• 2.3 风险与应对方式
• 三、任务认领与成员投入
• 四、成员协作方式
• 4.1 日常沟通与任务同步
• 4.2 版本仓库协作
• 4.3 当前团队协作截图
• 五、软件需求规格说明书
• 5.1 文档链接
• 5.2 需求规格说明书应覆盖的内容
• 5.3 需求边界
• 六、界面原型设计
• 6.1 原型工具与在线链接
• 6.2 原型页面与职责
• 6.3 原型验收重点
• 七、需求分析 PPT
• 八、界面原型设计答辩 PPT
• 九、结语

一、团队项目计划

1.1 项目背景与目标

校园用户在选择餐馆或档口时，通常需要在群聊、地图平台、外卖平台和个人经验之间反复查找。不同平台的店铺信息、价格、营业时间和评价内容分散，评论也缺少统一的分类和比较方式。

“食话说”是一款面向校园场景的美食推荐及评论分析 Web 平台，主要帮助用户根据口味、预算、用餐时间、距离等条件筛选店铺，并通过评分、标签和评论摘要快速了解店铺的优点与短板。

项目目标不是替代外卖、支付或配送平台，而是把校园美食信息整理成更容易查询和比较的形式。系统需要尽量说明推荐依据、评论来源和数据更新时间，避免只给出一个没有解释的推荐结果。

1.2 本次作业交付范围

本次作业重点交付以下材料：

1. 一份围绕校园美食推荐及评论分析项目的团队计划；
2. 一份按照需求规格说明书结构整理的项目文档；
3. 一套可以访问的界面原型；
4. 一份需求分析 PPT；
5. 一份界面原型设计答辩 PPT；
6. 成员分工、工作量比例和团队协作说明；
7. 评审表、原型链接和仓库材料的提交检查记录。

本次作业不把以下内容写成已经完成的承诺：稳定抓取所有第三方平台、实时保证价格和营业状态准确、复杂个性化推荐、支付配送、登录权限和大规模微服务部署。

1.3 项目里程碑

阶段	计划内容	交付物	计划日期	当前状态
M1：需求与范围确认	明确用户、使用场景、核心功能和暂不实现范围	NABCD 分析、需求清单	10 月 9 日—10 月 10 日	已交付
M2：原型设计	绘制主要页面、页面跳转和异常状态	HTML 高保真原型、墨刀交互连线和页面说明	10 月 9 日—10 月 12 日	已交付
M3：需求规格说明书	按引言、用户场景、类图、界面原型、功能和验收标准组织文档	51 页需求规格说明书 PDF/Word	10 月 10 日—10 月 13 日	已交付
M4：需求分析汇报	说明项目背景、用户需求、分析过程、功能结构和风险	需求分析 PPT	10 月 12 日—10 月 13 日	已交付
M5：原型答辩汇报	演示主要页面、操作流程和异常状态	原型模型汇报 PPT	10 月 13 日—10 月 14 日	已交付
M6：材料检查与提交	检查目录、链接、图片、文件权限和格式	最终博客及材料清单	10 月 14 日—10 月 15 日	本项交付
M7：答辩	介绍项目需求、原型设计、功能流程和当前交付内容	课堂答辩及汇报材料	10 月 16 日	未开始
M8：后续开发准备	根据评审意见拆分编码、测试和数据任务	后续开发任务表	答辩后安排	未开始

1.4 计划验收方式

• 点击原型链接后，能够打开只读原型并看到主要页面；
• 从原型入口进入搜索、筛选、店铺详情、评论分析和推荐流程时，页面跳转方向清楚；
• 需求规格说明书中的页面名称、功能描述和验收标准能够与原型对应；
• PPT、需求规格说明书和博客中的项目名称、数据边界和团队成员信息保持一致；
• 所有已填写的公开链接在发布前使用未登录窗口进行一次访问检查。

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

2.1 项目关键点

关键点一：推荐结果必须能够解释

用户不仅需要看到“推荐某家店”，还需要知道推荐依据是什么。例如，系统应说明店铺是否满足预算和距离条件，哪些标签来自店铺信息，哪些结论来自评论分析，哪些信息仍然需要用户自行核实。

关键点二：评论原文和系统分析结果分开

评论原文、评论时间、评论来源与系统提取的标签、摘要和倾向判断不能混在一起。系统总结只能作为辅助信息，不能伪装成用户原话，也不能把自动分析结果表述为店铺官方信息。

关键点三：数据来源和更新时间清楚

本项目优先使用团队整理、用户提供、获得授权或公开可访问的数据。若外部数据源访问失败、字段不完整或更新时间不明确，页面需要提示用户数据限制，不承诺所有信息实时有效。

关键点四：筛选条件要区分必要条件和偏好

预算、距离和营业时间可能是用户必须满足的条件；口味、环境和服务则可能是用户的偏好。系统不能用一个综合分数直接覆盖用户明确提出的必要条件。

关键点五：异常流程也属于需求

无搜索结果、评论为空、字段错误、重复店铺、网络失败和分析失败都需要有明确的提示与下一步操作，不能只画正常状态。

2.2 主要难点

1. 不同来源的店铺名称、地址、价格、营业时间和评论字段不一致，需要统一字段并保留来源信息；
2. 同一条评论可能同时涉及口味、分量、服务和环境，标签提取结果需要允许人工检查；
3. “人均价格”等客观字段与“性价比高”等主观评价不能使用同一种规则处理；
4. 推荐理由需要同时参考用户条件、店铺字段和评论证据，避免只依赖评分排序；
5. 原型、需求文档和 PPT 都要描述同一套页面和流程，材料之间需要交叉检查；
6. 手机端显示宽表格、评论长文本和图表时容易拥挤，需要提前考虑卡片化、折叠和横向滚动。

2.3 风险与应对方式

风险	可能表现	应对方式
数据来源不稳定	接口超时、限制访问或字段缺失	保留本地已有数据，显示失败原因和重试入口
数据过期	价格、营业时间或店铺状态变化	显示更新时间和“待核实”提示，不承诺实时准确
评论误判	正常负面评价被误删或被错误总结	保留原文，规则过滤、自动分析和人工复核分开
推荐不可解释	只有排序结果，没有依据	将推荐理由关联到筛选条件、标签和评论证据
项目范围扩大	同时追求全平台、实时更新和复杂推荐	先完成核心流程，再根据测试结果决定扩展
文档与原型不一致	页面名、按钮名和跳转关系不同	提交前按页面清单逐项走查
链接无法访问	未登录可见性、权限或链接失效	发布前使用未登录窗口逐条检查

三、任务认领与成员投入

本次作业按照最终交付物来分配工作，而不是简单按照技术方向划分。团队先把任务拆成项目统筹、需求文档、原型制作、汇报材料和审查整理几条工作线，再由成员结合自身情况认领，组长负责把各条线的结果汇总到最终作业中。

工作线	负责成员	对应产出
项目统筹与提交	102400320 林明阳（组长）	任务安排、组员协调、进度跟进、选题 Q&A、作业博客、华为云文件和链接检查，并审查 NABCD 模型
需求文档与模型	102400318 梁强、102400321 林铭宏、102400323 林荣皓、052404137 罗悦翔	需求规格说明书、NABCD 模型、需求建模和流程图等材料；林铭宏协作完成需求规格说明书，林明阳、罗悦翔负责 NABCD 模型审查
界面原型	102400321 林铭宏、102400324 林宇轩、102400318 梁强	墨刀页面、页面跳转、交互调整、原型文件和相关汇报材料；梁强负责审查页面原型
PPT 与内容审查	102400319 林佳鹏、102400324 林宇轩，052404137罗悦翔其他成员配合	需求分析 PPT、答辩材料、页面检查和成果内容审查；林佳鹏完成需求分析评审表，林宇轩负责汇报材料审查

原型模型汇报 PPT 中已经给出了工作线投入比例，具体如下：

工作线	参与成员	工作线比例
制作原型模型	林铭宏、梁强	21%
制作 PPT	罗悦翔、林佳鹏	18%
需求规格说明书	林铭宏、梁强	21%
修改 NABCD 模型	林荣皓	12%
撰写博客	林明阳	9%
审核模型	全体组员	8%
汇报	林宇轩	11%
合计		100%

上表是按交付物划分的工作线比例，其中部分成员共同参与同一条工作线，因此不能直接当作个人贡献度重复填写。下面的个人贡献度需要根据实际投入进一步拆分，并由全员复核。

具体成员的任务认领如下：

成员	认领任务	当前交付内容
102400320 林明阳	统筹、组员协调、提交与 NABCD 审查	协调组员、分配任务、跟进修改、审查 NABCD 模型，整理选题 Q&A 和作业博客，核对仓库及公开链接
102400318 梁强	需求规格说明书与页面原型审查	撰写和修改说明书，补充需求内容并检查文档完整性，同时审查页面原型
102400323 林荣皓	NABCD 与文档协作	整理 NABCD 模型，补充需求分析内容，协助文档格式检查
052404137 罗悦翔	需求建模、NABCD 审查与原型答辩材料	梳理交互逻辑，整理需求模型和流程图，审查 NABCD 模型，协助制作原型答辩材料
102400321 林铭宏	墨刀原型与需求文档协作	完成页面原型、页面布局、交互流程和原型版本整理，协作完成需求规格说明书
102400324 林宇轩	原型汇报、答辩与成果审查	整合原型页面和汇报内容，统一页面跳转、字体及布局，负责答辩准备、汇报完善、各阶段产物审查并提出修改建议
102400319 林佳鹏	需求分析评审与答辩材料	制作需求分析 PPT，完成需求分析评审表，整理课堂答辩材料，检查内容和页数

本阶段个人投入比例按照任务完成情况、材料修改量、答辩汇报和实际协作记录进行估算，当前团队确认如下：

学号	姓名	主要投入方向	贡献度
102400320	林明阳	项目统筹、组员协调、博客整理、仓库和链接核对	13%
102400318	梁强	需求规格说明书撰写、修改与页面原型审查	15%
102400323	林荣皓	NABCD 模型、需求分析和文档整理	13%
052404137	罗悦翔	需求建模、流程图、交互逻辑和原型答辩材料	14%
102400321	林铭宏	墨刀原型、页面交互和需求规格说明书协作	16%
102400324	林宇轩	原型整合、答辩汇报、汇报材料完善、各阶段产物审查和修改建议	16%
102400319	林佳鹏	需求分析 PPT、答辩材料和内容审查	13%

综合各成员承担的任务、材料完成情况和实际协作投入，团队将个人贡献度确定为：林宇轩和林铭宏各 16%，梁强 15%，罗悦翔 14%，林明阳、林荣皓和林佳鹏各 13%，合计 100%。该比例用于反映本阶段的实际分工与投入，后续如有新增任务，再根据实际完成情况统一调整。

四、成员协作方式

4.1 日常沟通与任务同步

团队主要通过 QQ 群进行需求讨论、任务认领、问题反馈和答辩准备，并通过线下会议集中讨论阶段性问题和关键修改。每次阶段同步至少说明：已经完成的任务、当前任务、遇到的阻塞和下一步计划。涉及页面、字段或交付材料的变更，需要在 QQ 群中说明变更原因，避免成员继续按照旧版本工作。

4.2 版本仓库协作

代码和课程材料使用华为云 CodeArts 管理，仓库地址为：七匹狼项目代码仓库。目前仓库中的主要材料路径如下：

• PPT/食话说_需求分析_答辩PPT.pdf
• PPT/食话说_原型模型汇报.pdf
• PPT/食话说_软件需求规格说明书.pdf
• 文档/食话说_NABCD模型分析_修改版.docx
• 文档/食话说原型模型网址链接.txt

协作约定如下：

1. 按功能或材料模块拆分任务，避免一次提交混入无关修改；
2. 完成一个相对完整的功能或材料模块后再提交；
3. 提交说明尽量使用中文，并写清本次修改内容；
4. 提交前检查文件能否打开、链接是否正确、Markdown 是否能正常预览；
5. 涉及页面流程、接口字段或文档结构的修改，由另一名成员进行交叉检查；
6. 发生冲突时先说明各自修改目的，再由相关负责人确定保留方案，不直接覆盖他人内容。

4.3 当前团队协作截图

以下截图用于展示团队围绕会议安排、任务分配、原型修改、NABCD 模型和需求文档交付开展的实际讨论。

图 1：团队发起线下会议，确认项目分工。

图 2：组员针对首页布局、登录入口和原型功能展示进行具体讨论，并根据反馈决定保留或调整页面内容。

图 3：团队讨论 NABCD 模型和需求规格说明书中评论分析、筛选内容的补充，并完成文档交付。

图 4：汇报人主动审查场景描述、竞争力分析和 NABCD 内容，并提出具体修改建议，推动团队进一步完善汇报材料。

五、软件需求规格说明书

5.1 文档链接

Word 文件：

食话说_软件需求规格说明书 .docx 3.39M

代码仓库的需求规格说明书 PDF，可查看：食话说软件需求规格说明书 PDF。备用入口是 CodeArts 仓库主页，文件路径为 PPT/食话说_软件需求规格说明书.pdf。

该文档共 51 页，包含引言、总体描述、用户场景、类图、顺序图、活动图、属性要求、20 页界面原型说明、功能描述和验收验证标准。。

5.2 需求规格说明书应覆盖的内容

需求规格说明书围绕“食话说”项目组织，主要包括：

1. 引言：编写目的、项目背景、项目范围、术语和参考资料；
2. 总体描述：目标用户、使用场景、产品边界和运行环境；
3. 用户场景：学生查找店铺、筛选条件、查看详情、阅读评论和参考推荐；
4. 系统分析：业务流程、类图、核心对象和主要字段；
5. 界面原型：主要页面、页面关系和典型操作流程；
6. 功能描述：店铺搜索、筛选、详情、评论处理、分析和推荐；
7. 非功能需求：可用性、兼容性、数据限制、异常处理和可解释性；
8. 验收验证标准：输入、操作步骤、预期结果和失败时的提示。

5.3 需求边界

需求文档需要明确区分以下内容：

• 店铺和评论原始数据与系统整理、提取或总结结果；
• 用户输入的硬性条件与用于排序的偏好条件；
• 本地已有数据与外部查询结果；
• 正常推荐、暂无结果、数据不完整、网络失败和待人工核实状态。

六、界面原型设计

6.1 原型工具与在线链接

原型主体采用 HTML 高保真页面，使用墨刀导入并补充页面之间的交互连线。本次原型共 20 页，其中用户端 14 页、管理端 6 页；原型汇报 PPT 中对设计工具、页面结构和交互规则进行了说明。

原型链接为：食话说原型模型。

6.2 原型页面与职责

原型分为用户端“找到店”和管理端“养数据”两部分，页面数量和职责与需求规格说明书保持一致：

端	页面数量	页面职责与主要内容
用户端	14 页	首页、登录、注册、三步口味画像、个性化推荐、全部结果、店铺详情、收藏、多店对比、个人中心、资料编辑和关于页面。
管理端	6 页	管理端登录、工作台、评论筛查、数据监控、店铺库和管理端个人资料页面。

核心用户流程为：注册或游客进入首页 → 输入一句话需求 → 确认关键词和筛选条件 → 查看 4 家推荐结果 → 查看评论原文与推荐依据 → 收藏或加入对比台。管理端流程为：登录 → 查看待处理数据 → 进行评论筛查或店铺审核 → 查看数据监控和处理记录。

6.3 原型验收重点

1. 正常输入条件后能够进入候选店铺列表；
2. 点击店铺能够进入详情，并看到评论原文和来源说明；
3. 点击评论标签或分析维度能够看到关联内容；
4. 搜索无结果时能看到原因、清空条件或返回重新搜索的入口；
5. 重复店铺或重复评论导入时显示重复项，并让用户选择取消或继续；
6. 字段错误时明确指出具体字段，而不是只显示“操作失败”；
7. 网络失败时保留用户输入，并提供重试或查看本地数据的入口；
8. 删除和编辑操作需要经过清晰的确认步骤；
9. 手机访问时不出现无法阅读的宽表格、长文本溢出或图表重叠。

七、需求分析 PPT

需求分析答辩 PPT 共 12 页，主题是“基于评论关键词匹配的个性化美食推荐平台”。PPT 不是只展示项目愿景，而是按照“问题定义—用户角色—需求模型—功能需求—非功能需求—方案竞争—验收标准”的顺序，把项目从需求分析落实到可核对的交付标准。材料明确列出 26 项功能需求、16 条非功能需求和 46 条验收标准。

• 直接查看需求分析答辩 PPT
• CodeArts 仓库主页
• 文件路径：PPT/食话说_需求分析_答辩PPT.pdf

PPT 的主要内容如下：

1. 问题定义与产品定位：指出校园用户并不是没有美食数据，而是难以把分散评论转化为可以直接使用的决策答案。项目希望通过“一句话输入、少量候选、证据可核对”的方式，把决策时间控制在 1 分钟以内。
2. 用户角色与典型场景：围绕游客、学生党、上班族、家庭用户、平台审核员和平台运营六类角色，说明用户端与管理端的边界，并列出预算就餐、收藏对比、游客试用和评论审核四类场景。
3. 需求模型与核心需求链：通过用况图明确参与者和系统服务，重点展示“口语化搜索—关键词拆解—评论匹配—个性化推荐”的过程。用户输入“预算有点紧、分量大”等表达后，系统将其拆成可确认的标签，并区分必须满足条件和优先考虑条件。
4. 评论治理与证据提取：评论先经过敏感词硬过滤，再经过 AI 筛选，最后由管理员人工排查与打回。通过三道关卡减少广告、重复和无关评论，同时保留正常差评；有效评论再提取口味、价格、分量、环境、服务、等待时间、营业信息和体验风险等十类证据。
5. 功能需求与实现边界：项目共 26 项功能需求，划分为账号与登录、口味画像、个性化推荐、决策辅助、信息透明与信任、评论治理与店铺库六大功能域；其中 P0 必须实现 16 项、P1 重要功能 8 项、P2 增强功能 2 项。PPT 同时列出不做下单支付、订座预约、真实地图导航、社交动态、站内发表评论和数据分析大屏等范围。
6. 非功能需求与安全边界：共 16 条非功能需求，包括 6 条可用性要求和 10 条安全性要求，涉及三次点击内得到推荐、空输入提示、导航一致、评论匿名化、不采集身份与位置轨迹、公开数据合规使用以及管理员二次验证等内容。
7. NABCD 与竞争分析：通过评论治理、关键词提取、多维证据和可解释推荐形成项目差异化，并明确 Web 交付、首期限定城市片区、演示数据与真实信息分开等交付边界。
8. 验收标准：PPT 给出界面验收 20 项和功能验收 26 条，共 46 个可核对点，并用口语化搜索、被排除原因查询、店铺双人审批和数据监控只读等例子说明如何验收。

因此，这份 PPT 主要承担“把项目想法变成可验证需求”的作用，为需求规格说明书、原型页面和后续测试提供统一依据。

八、界面原型设计答辩 PPT

原型模型汇报 PPT 共 10 页，围绕“让吃什么重新变简单”介绍高保真 Web 原型的设计过程和最终结构。PPT 说明本项目采用 HTML 完成页面表现，再导入墨刀补充交互连线；原型共 20 页，包括用户端 14 页和管理端 6 页。

• 直接查看原型模型汇报 PPT
• CodeArts 仓库主页
• 文件路径：PPT/食话说_原型模型汇报6版.pdf

PPT 主要介绍以下内容：

1. 原型设计原则：以易用性、统一性和简洁性为主要原则，保证流程清晰、入口明确、20 页页面共享统一样式，并对管理端页面持续做减法。
2. 用户端“找到店”：包括首页、登录/注册、口味画像、个性化推荐、全部结果、店铺详情、收藏与对比、个人中心和关于页面，服务于从发现店铺到查看证据、收藏和比较的完整流程。
3. 管理端“养数据”：包括管理端登录、工作台、评论筛查、数据监控、店铺库和管理端资料页面，形成评论治理、店铺维护和数据状态查看的管理闭环。
4. 核心操作流程：用户完成登录或以游客身份进入后，先填写口味、预算和场景，再输入一句话需求；系统拆出 6 个关键词标签，给出 4 家重点推荐店铺，用户可以继续查看评论原文、收藏或进行多店对比，其余结果放入“全部结果”中。
5. 推荐与评论筛查展示：推荐部分强调关键词匹配、评论证据和加权排序，不依赖单一星级；评论部分展示正则筛选、AI 筛选和人工审核三轮流程，说明评论通过后才进入有效评论集。
6. 迭代与后续交付：原型经过 7 轮迭代，由最初的 11 页逐步完善为 20 页；最终形成用户端“找到店”和管理端“养数据”的双角色闭环，为后续 UI 细化和编码实现保留接口。

PPT 中记录的工作线比例为：制作原型模型 21%、制作 PPT 18%、需求规格说明书 21%、修改 NABCD 模型 12%、撰写博客 9%、审核模型 8%、汇报 11%，合计 100%。这组数据是工作线比例，不直接等同于个人贡献度；博客中的个人贡献度按照成员实际投入另行列出。

九、结语

本次作业的重点是把“食话说”从一个项目想法整理成可以被检查的需求、原型和交付材料。我们会以需求规格说明书作为文字依据，以墨刀原型验证页面流程，以 PPT 说明项目背景和设计思路，再根据评审意见逐步推进后续开发。对于数据时效性、评论分析准确性和推荐结果可解释性，项目会保留必要的限制说明，不把尚未验证的功能写成确定结果。