1. 项目概述与核心价值“需求分析”这四个字听起来像是软件工程教科书里最枯燥的章节但在我们拿下计算机设计大赛国奖的征途上它却是整个项目从“想法”蜕变为“作品”的基石是决定项目上限与下限的关键一步。很多参赛团队尤其是学生团队最容易犯的错误就是一头扎进炫酷的技术实现里却忽略了前期对需求的深度挖掘和精准定义。结果往往是做了一个功能齐全、技术栈新颖但评委看完后却会问“这到底解决了什么实际问题”的作品。我们团队在备赛初期就达成了共识需求分析不是走过场而是用最严谨的逻辑去论证我们“为什么要做”以及“要做成什么样”。这个过程直接决定了后续技术选型的合理性、功能设计的聚焦度以及最终答辩时故事讲述的感染力。我们的项目是一个面向特定场景的智能辅助系统。为了避免空谈我将用一个具体的例子来贯穿说明假设我们的项目是“基于计算机视觉的实验室安全行为智能监测系统”。这个标题听起来技术感十足但如果没有扎实的需求分析它很容易变成一个简单的“摄像头违规检测报警”的玩具项目缺乏深度和竞争力。而通过系统性的需求分析我们将其深化为一个解决实验室安全管理痛点、具备实际推广价值的解决方案。接下来我将完整复盘我们是如何进行这次“国奖级”需求分析的从核心思路到具体方法再到产出物的打磨分享我们踩过的坑和总结出的实战经验。2. 需求分析的整体框架与核心思路2.1 跳出技术思维建立问题域视角学生做项目最容易陷入“技术驱动”的陷阱学了深度学习就想做个图像识别了解了物联网就想把所有设备连上网。我们的第一个转变就是从“我想用什么技术”转变为“我要解决什么问题”。以实验室安全监测为例我们最初的想法可能只是“用YOLO检测人是否戴了安全帽”。但如果止步于此项目价值就非常有限。我们通过以下步骤建立了问题域视角利益相关者分析谁关心实验室安全他们的核心诉求是什么实验室管理员诉求是降低事故率、减轻日常巡检负担、实现违规行为可追溯。痛点在于无法7x24小时盯守事后查录像效率低下。实验人员学生/研究员诉求是拥有一个安全的实验环境在疏忽时能得到及时提醒。痛点在于繁忙时容易忽视安全规程。学院/学校安全部门诉求是掌握整体安全态势、进行量化考核、制定改进策略。痛点在于缺乏客观、持续的数据支撑。项目评委诉求是看到项目对现实问题的深刻理解、解决方案的创新性与实用性。痛点在于讨厌“为了技术而技术”的空洞项目。问题场景细化实验室安全具体包含哪些方面个人防护装备PPE穿戴安全帽、实验服、护目镜、手套等。危险区域入侵是否有人进入了化学药品存放区、高压设备区等禁入区域。危险行为识别在实验室内奔跑、饮食、违规操作设备等。环境状态监测烟雾、明火、液体泄漏等。关键点我们并没有试图一次性解决所有问题而是通过调研将“安全帽佩戴检测”和“危险区域入侵”确定为最高频、最易发生且现有手段纯人力管理成本最高的两个核心场景。这体现了需求的优先级排序。注意需求分析的起点必须是真实的问题和真实的人。我们团队花了整整一周时间访谈了3位实验室管理员、10余名经常做实验的同学并查阅了学校近三年的实验室安全简报。这些一手资料远比凭空想象更有说服力也成为了我们答辩时强有力的论据。2.2 需求分层从模糊想法到可执行规格有了问题域的认识我们需要把模糊的“想要一个安全系统”转化为清晰、可被开发实现的需求。我们采用了经典的需求分层方法业务需求 - 用户需求 - 功能需求 - 非功能需求。业务需求这是项目的战略目标回答“为什么做”。示例降低化学实验室因人员违规操作和安全防护不到位导致的安全事故发生率提升安全管理效率实现安全管理的数字化、智能化转型。我们的做法将业务需求与大赛的“服务社会、关注民生”等导向相结合凸显项目的社会价值。用户需求从用户角度描述他们希望系统做什么通常用自然语言描述。实验室管理员“我希望系统能自动发现没戴安全帽就进入实验室的人并立即发出警告。”安全部门领导“我希望每周能收到一份实验室安全报告能看到违规行为的趋势图。”我们的做法为每个核心利益相关者建立“用户画像”并列出他们的核心用户故事。例如“作为实验室管理员当有人员未佩戴安全帽进入监控区域时我希望系统能实时在监控大屏上框出该人员并播放语音警告以便我及时干预。”功能需求定义系统必须提供的具体功能是用户需求的具象化、技术化。示例系统应支持实时视频流输入。系统应能对输入视频流进行实时分析检测画面中的人员。系统应能识别被检测人员是否佩戴安全帽置信度阈值设定为0.85。当检测到未佩戴安全帽的人员时系统应在视频画面中绘制红色边界框并标注“未佩戴安全帽”。系统应同时触发本地语音播报器播放预置的警告语音。系统应将每次违规事件时间、位置、图片快照记录到数据库中。我们的做法使用“系统应能…”的句式确保需求的可测试性。我们为每个功能需求分配了唯一的ID如FR-001并关联到对应的用户需求。非功能需求描述系统运行的约束和品质要求决定了系统“好不好用”。性能需求在主流GPU如NVIDIA GTX 1660 Ti上单路视频流的分析延迟应低于200毫秒。可靠性需求系统核心服务应保证99%以上的可用性故障恢复时间不超过5分钟。安全性需求视频数据流应在传输和存储时进行加密用户访问需进行身份认证。可维护性需求系统应提供管理后台允许管理员配置检测区域、报警规则等。我们的做法非功能需求是区分“玩具Demo”和“可部署系统”的关键。我们特别强调了实时性和准确性因为对于安全预警误报和延迟都是不可接受的。同时我们也考虑了成本选择了性价比高的硬件和可快速部署的软件架构这体现了方案的落地可行性。3. 核心方法与工具如何高效地产出高质量需求3.1 调研方法获取真实声音纸上谈兵永远得不到真需求。我们混合使用了多种调研方法深度访谈与关键用户如资深实验室管理员进行一对一访谈。准备半结构化提纲但鼓励对方自由发挥挖掘潜在痛点。例如我们访谈时发现管理员除了实时报警更头疼的是“说服”违规者他们希望系统能自动截取违规瞬间的清晰图片作为证据。这个需求后来成为了我们“违规证据链”功能的核心来源。问卷调查面向更广泛的实验人员发放问卷量化某些需求。例如“您认为以下哪种违规行为最危险”、“您能接受报警延迟最多几秒”。问卷数据可以做成图表放在答辩PPT里非常直观。现场观察我们申请了在实验室非实验时间进行现场观察了解人员动线、监控摄像头位置、现有安全标识等环境因素。这直接影响了我们后续关于“摄像头部署视角”、“检测区域划定”的技术决策。竞品分析研究市场上已有的商业安防系统或学术界的相关研究。我们分析了海康、大华等厂商的智能安防方案发现它们功能强大但价格昂贵、定制化程度低。而学术界的研究大多聚焦于算法精度对完整系统闭环和用户体验关注不足。这为我们找到了项目的差异化定位低成本、高定制化、轻量级部署的垂直领域解决方案。3.2 分析与建模工具让需求可视化清晰的表达胜过千言万语。我们使用了以下工具来梳理和呈现需求用户故事地图将所有的用户故事User Story按照用户的活动流程进行排列。横轴是时间线如“进入实验室 - 准备实验 - 进行实验 - 离开实验室”纵轴是不同优先级。这张图能一眼看清系统的全貌和核心价值流避免功能碎片化。用例图用UML用例图清晰地展示系统与外部参与者用户、其他系统之间的交互关系。这有助于界定系统边界防止需求蔓延。参与者实验室管理员、实验人员、短信网关、数据库。 用例实时视频监控、安全行为识别、报警通知、数据记录与查询、报告生成。功能列表与需求规格说明书这是最终的交付物。我们用一个在线表格如腾讯文档维护包含字段需求ID、类型功能/非功能、描述、优先级MoSCoW法则Must have, Should have, Could have, Won‘t have、来源、验收标准、状态。原型图即使是偏重后端的系统我们也用墨刀或Figma画了简单的管理后台UI原型和报警大屏的示意图。视觉化的原型能极大减少沟通成本让老师和队友快速理解我们想要做成什么样子。实操心得工具不在多在于用透。我们团队初期贪多什么都想用反而乱了套。后来我们固定用“用户故事地图”梳理逻辑用“在线表格”管理具体需求条目效率大增。MoSCoW优先级法则一定要严格执行必须和指导老师、团队核心成员一起确定哪些是“MVP”最小可行产品必须做的哪些可以放在后期优化。我们的原则是确保“Must have”的需求能构成一个完整、可演示的核心业务流程。4. 从需求到技术方案的关键转化需求分析不是孤立的它必须指引后续的技术设计。这里分享我们如何将需求“翻译”成技术决策。4.1 性能需求如何影响技术选型我们的一个关键非功能需求是“实时性分析延迟200ms”。这直接导致了以下技术选择算法模型选型需求驱动需要高速度、较高精度。技术决策放弃了更重、更慢的两阶段检测器如Faster R-CNN选择了单阶段检测器YOLO系列。经过测试最终选用了在速度和精度上平衡较好的YOLOv5s模型并针对“安全帽”这个特定类别进行了轻量化微调。理由YOLO的单阶段特性使其推理速度更快满足实时性要求。选择“s”版本而非更大的“l”或“x”版本是为了在可接受的精度损失下换取更快的速度便于在中等性能的GPU上部署。部署架构选型需求驱动需要低延迟、高可靠性。技术决策采用“边缘计算”为主“云端协同”为辅的架构。将AI推理模型直接部署在实验室现场的边缘计算设备如英伟达Jetson Nano上而不是将视频流全部上传到中心服务器。理由边缘计算将处理放在数据产生端极大减少了网络传输延迟确保了报警的实时性。同时边缘设备只将报警事件和关键数据非完整视频流上传至云端服务器进行存储和报表分析减轻了带宽压力也符合数据隐私和安全需求。4.2 功能需求如何驱动系统设计用户需求“自动报警并记录”分解为多个功能需求后驱动了整个系统模块的设计FR-001实时分析-视频流处理模块需要使用OpenCV或GStreamer高效抓取RTSP视频流。FR-002, 003安全帽检测-AI推理模块需要加载训练好的YOLO模型并实现前后处理图像缩放、归一化、NMS等。FR-004画面标注-告警可视化模块需要将推理结果边界框、标签实时叠加到视频流上并输出到显示界面。FR-005语音报警-告警触发模块需要调用本地TTS引擎或播放音频文件。FR-006事件记录-数据持久化模块需要设计数据库表结构记录时间、摄像头ID、违规类型、快照图片路径等并实现插入逻辑。每一个功能需求都对应了系统中的一个具体模块或接口这使得我们的系统设计高度契合需求避免了过度设计或设计不足。5. 需求验证与持续迭代确保不跑偏需求文档写出来不是束之高阁的。我们建立了简单的验证和迭代机制需求评审会邀请指导老师、团队所有成员甚至是非技术背景的同学一起评审需求文档。大家从不同角度提问“这个功能用户真的需要吗”、“这个技术方案能实现这个需求吗”、“这个优先级合理吗”。这个过程能发现很多逻辑漏洞和想当然的部分。原型验证对于关键的用户交互流程如管理员查看报警记录我们用高保真原型模拟操作让目标用户我们找了另一位实验室管理员试用收集反馈。我们曾发现最初设计的报表下载流程过于复杂根据反馈简化了。需求跟踪矩阵在开发过程中我们维护一个简单的表格将需求ID与对应的代码文件、测试用例关联起来。确保每一个开发任务都源自明确的需求每一个需求都有对应的实现和验证。拥抱变化在开发中期我们了解到某个实验室有特殊的“防静电手环”佩戴要求。经过评估我们认为这是一个有价值的“Should have”需求且实现成本可控只需增加一个检测类别并重新标注少量数据。我们并没有死守最初的文档而是经过团队讨论和老师同意后将其纳入迭代范围这反而让我们的项目更具针对性和亮点。6. 国奖答辩中如何呈现需求分析需求分析做得再好如果在答辩中讲不出来效果也大打折扣。我们的经验是讲故事而不是念文档不要一上来就说“我们采用了UML用例图”。而是从“我们在调研中发现实验室安全管理存在三大痛点……”开始引出我们的项目动机。可视化呈现将用户故事地图、用例图、功能优先级矩阵MoSCoW做成清晰的PPT图表。一图胜千言。突出决策逻辑重点讲清楚“为什么”。为什么选择YOLO而不是其他算法为什么用边缘计算这些技术选择的背后都是源于对“实时性”、“低成本”、“易部署”等非功能需求的深入考量。这能充分体现团队的系统性思维和工程权衡能力。展示证据适时展示访谈照片、问卷数据摘要、竞品分析对比表证明你的需求不是闭门造车而是源于扎实的调研。关联价值始终将每一个需求点与项目最终要实现的业务价值提升安全、提高效率和社会价值响应智慧校园建设、保障科研人员安全挂钩。7. 常见误区与避坑指南回顾整个历程我们看到很多其他团队在需求分析阶段容易陷入的误区这里分享我们的避坑经验误区一把想法当需求。“我想做一个AI系统”是想法。“实验室管理员需要一个能自动识别未戴安全帽人员并实时报警的系统”才是需求。一定要追问“谁在什么情况下要解决什么问题”直到能清晰地描述出用户和场景。误区二需求大而全贪多嚼不烂。试图做一个“万能实验室安全系统”结果每个功能都做不深。深度优于广度。抓住1-2个核心痛点做深做透形成完整闭环远比做一个功能杂烩的“Demo合集”更有竞争力。误区三忽略非功能需求只关注“做什么”不关心“做多好”、“多快”、“多稳定”。结果做出来的系统延迟高达几秒或者界面极其难用。评委一眼就能看出这是缺乏工程思维的学生作品。务必量化你的非功能需求哪怕只是基于调研的合理估计。误区四需求与分析脱节需求文档写完后就扔给开发后续再无交集。一定要建立可追溯性。确保每一行代码、每一个测试用例都能回溯到最初的需求这样在开发中遇到歧义或需要取舍时才有据可依。误区五闭门造车缺乏用户验证几个队员在寝室里头脑风暴出来的需求往往脱离实际。走出去和你的目标用户聊哪怕只是简单的交流也能获得意想不到的洞见。我们关于“违规证据链”的需求就是在一次看似随意的聊天中获得的。需求分析是一场严谨的逻辑推演和深刻的用户共情。它没有炫酷的代码和直观的界面却从根本上定义了项目的灵魂和骨架。在我们看来这份深入、扎实的需求分析文档是我们作品能够打动评委从众多项目中脱颖而出的第一块也是最重要的一块基石。它让我们在后续的开发、测试、答辩中始终目标清晰步履坚定。 
长河君 · 2026/8/21 4:27:22 · 阅读 1.2k 从需求分析到国奖项目：如何用系统化方法驱动计算机视觉应用开发
1. 项目概述与核心价值“需求分析”这四个字听起来像是软件工程教科书里最枯燥的章节但在我们拿下计算机设计大赛国奖的征途上它却是整个项目从“想法”蜕变为“作品”的基石是决定项目上限与下限的关键一步。很多参赛团队尤其是学生团队最容易犯的错误就是一头扎进炫酷的技术实现里却忽略了前期对需求的深度挖掘和精准定义。结果往往是做了一个功能齐全、技术栈新颖但评委看完后却会问“这到底解决了什么实际问题”的作品。我们团队在备赛初期就达成了共识需求分析不是走过场而是用最严谨的逻辑去论证我们“为什么要做”以及“要做成什么样”。这个过程直接决定了后续技术选型的合理性、功能设计的聚焦度以及最终答辩时故事讲述的感染力。我们的项目是一个面向特定场景的智能辅助系统。为了避免空谈我将用一个具体的例子来贯穿说明假设我们的项目是“基于计算机视觉的实验室安全行为智能监测系统”。这个标题听起来技术感十足但如果没有扎实的需求分析它很容易变成一个简单的“摄像头违规检测报警”的玩具项目缺乏深度和竞争力。而通过系统性的需求分析我们将其深化为一个解决实验室安全管理痛点、具备实际推广价值的解决方案。接下来我将完整复盘我们是如何进行这次“国奖级”需求分析的从核心思路到具体方法再到产出物的打磨分享我们踩过的坑和总结出的实战经验。2. 需求分析的整体框架与核心思路2.1 跳出技术思维建立问题域视角学生做项目最容易陷入“技术驱动”的陷阱学了深度学习就想做个图像识别了解了物联网就想把所有设备连上网。我们的第一个转变就是从“我想用什么技术”转变为“我要解决什么问题”。以实验室安全监测为例我们最初的想法可能只是“用YOLO检测人是否戴了安全帽”。但如果止步于此项目价值就非常有限。我们通过以下步骤建立了问题域视角利益相关者分析谁关心实验室安全他们的核心诉求是什么实验室管理员诉求是降低事故率、减轻日常巡检负担、实现违规行为可追溯。痛点在于无法7x24小时盯守事后查录像效率低下。实验人员学生/研究员诉求是拥有一个安全的实验环境在疏忽时能得到及时提醒。痛点在于繁忙时容易忽视安全规程。学院/学校安全部门诉求是掌握整体安全态势、进行量化考核、制定改进策略。痛点在于缺乏客观、持续的数据支撑。项目评委诉求是看到项目对现实问题的深刻理解、解决方案的创新性与实用性。痛点在于讨厌“为了技术而技术”的空洞项目。问题场景细化实验室安全具体包含哪些方面个人防护装备PPE穿戴安全帽、实验服、护目镜、手套等。危险区域入侵是否有人进入了化学药品存放区、高压设备区等禁入区域。危险行为识别在实验室内奔跑、饮食、违规操作设备等。环境状态监测烟雾、明火、液体泄漏等。关键点我们并没有试图一次性解决所有问题而是通过调研将“安全帽佩戴检测”和“危险区域入侵”确定为最高频、最易发生且现有手段纯人力管理成本最高的两个核心场景。这体现了需求的优先级排序。注意需求分析的起点必须是真实的问题和真实的人。我们团队花了整整一周时间访谈了3位实验室管理员、10余名经常做实验的同学并查阅了学校近三年的实验室安全简报。这些一手资料远比凭空想象更有说服力也成为了我们答辩时强有力的论据。2.2 需求分层从模糊想法到可执行规格有了问题域的认识我们需要把模糊的“想要一个安全系统”转化为清晰、可被开发实现的需求。我们采用了经典的需求分层方法业务需求 - 用户需求 - 功能需求 - 非功能需求。业务需求这是项目的战略目标回答“为什么做”。示例降低化学实验室因人员违规操作和安全防护不到位导致的安全事故发生率提升安全管理效率实现安全管理的数字化、智能化转型。我们的做法将业务需求与大赛的“服务社会、关注民生”等导向相结合凸显项目的社会价值。用户需求从用户角度描述他们希望系统做什么通常用自然语言描述。实验室管理员“我希望系统能自动发现没戴安全帽就进入实验室的人并立即发出警告。”安全部门领导“我希望每周能收到一份实验室安全报告能看到违规行为的趋势图。”我们的做法为每个核心利益相关者建立“用户画像”并列出他们的核心用户故事。例如“作为实验室管理员当有人员未佩戴安全帽进入监控区域时我希望系统能实时在监控大屏上框出该人员并播放语音警告以便我及时干预。”功能需求定义系统必须提供的具体功能是用户需求的具象化、技术化。示例系统应支持实时视频流输入。系统应能对输入视频流进行实时分析检测画面中的人员。系统应能识别被检测人员是否佩戴安全帽置信度阈值设定为0.85。当检测到未佩戴安全帽的人员时系统应在视频画面中绘制红色边界框并标注“未佩戴安全帽”。系统应同时触发本地语音播报器播放预置的警告语音。系统应将每次违规事件时间、位置、图片快照记录到数据库中。我们的做法使用“系统应能…”的句式确保需求的可测试性。我们为每个功能需求分配了唯一的ID如FR-001并关联到对应的用户需求。非功能需求描述系统运行的约束和品质要求决定了系统“好不好用”。性能需求在主流GPU如NVIDIA GTX 1660 Ti上单路视频流的分析延迟应低于200毫秒。可靠性需求系统核心服务应保证99%以上的可用性故障恢复时间不超过5分钟。安全性需求视频数据流应在传输和存储时进行加密用户访问需进行身份认证。可维护性需求系统应提供管理后台允许管理员配置检测区域、报警规则等。我们的做法非功能需求是区分“玩具Demo”和“可部署系统”的关键。我们特别强调了实时性和准确性因为对于安全预警误报和延迟都是不可接受的。同时我们也考虑了成本选择了性价比高的硬件和可快速部署的软件架构这体现了方案的落地可行性。3. 核心方法与工具如何高效地产出高质量需求3.1 调研方法获取真实声音纸上谈兵永远得不到真需求。我们混合使用了多种调研方法深度访谈与关键用户如资深实验室管理员进行一对一访谈。准备半结构化提纲但鼓励对方自由发挥挖掘潜在痛点。例如我们访谈时发现管理员除了实时报警更头疼的是“说服”违规者他们希望系统能自动截取违规瞬间的清晰图片作为证据。这个需求后来成为了我们“违规证据链”功能的核心来源。问卷调查面向更广泛的实验人员发放问卷量化某些需求。例如“您认为以下哪种违规行为最危险”、“您能接受报警延迟最多几秒”。问卷数据可以做成图表放在答辩PPT里非常直观。现场观察我们申请了在实验室非实验时间进行现场观察了解人员动线、监控摄像头位置、现有安全标识等环境因素。这直接影响了我们后续关于“摄像头部署视角”、“检测区域划定”的技术决策。竞品分析研究市场上已有的商业安防系统或学术界的相关研究。我们分析了海康、大华等厂商的智能安防方案发现它们功能强大但价格昂贵、定制化程度低。而学术界的研究大多聚焦于算法精度对完整系统闭环和用户体验关注不足。这为我们找到了项目的差异化定位低成本、高定制化、轻量级部署的垂直领域解决方案。3.2 分析与建模工具让需求可视化清晰的表达胜过千言万语。我们使用了以下工具来梳理和呈现需求用户故事地图将所有的用户故事User Story按照用户的活动流程进行排列。横轴是时间线如“进入实验室 - 准备实验 - 进行实验 - 离开实验室”纵轴是不同优先级。这张图能一眼看清系统的全貌和核心价值流避免功能碎片化。用例图用UML用例图清晰地展示系统与外部参与者用户、其他系统之间的交互关系。这有助于界定系统边界防止需求蔓延。参与者实验室管理员、实验人员、短信网关、数据库。 用例实时视频监控、安全行为识别、报警通知、数据记录与查询、报告生成。功能列表与需求规格说明书这是最终的交付物。我们用一个在线表格如腾讯文档维护包含字段需求ID、类型功能/非功能、描述、优先级MoSCoW法则Must have, Should have, Could have, Won‘t have、来源、验收标准、状态。原型图即使是偏重后端的系统我们也用墨刀或Figma画了简单的管理后台UI原型和报警大屏的示意图。视觉化的原型能极大减少沟通成本让老师和队友快速理解我们想要做成什么样子。实操心得工具不在多在于用透。我们团队初期贪多什么都想用反而乱了套。后来我们固定用“用户故事地图”梳理逻辑用“在线表格”管理具体需求条目效率大增。MoSCoW优先级法则一定要严格执行必须和指导老师、团队核心成员一起确定哪些是“MVP”最小可行产品必须做的哪些可以放在后期优化。我们的原则是确保“Must have”的需求能构成一个完整、可演示的核心业务流程。4. 从需求到技术方案的关键转化需求分析不是孤立的它必须指引后续的技术设计。这里分享我们如何将需求“翻译”成技术决策。4.1 性能需求如何影响技术选型我们的一个关键非功能需求是“实时性分析延迟200ms”。这直接导致了以下技术选择算法模型选型需求驱动需要高速度、较高精度。技术决策放弃了更重、更慢的两阶段检测器如Faster R-CNN选择了单阶段检测器YOLO系列。经过测试最终选用了在速度和精度上平衡较好的YOLOv5s模型并针对“安全帽”这个特定类别进行了轻量化微调。理由YOLO的单阶段特性使其推理速度更快满足实时性要求。选择“s”版本而非更大的“l”或“x”版本是为了在可接受的精度损失下换取更快的速度便于在中等性能的GPU上部署。部署架构选型需求驱动需要低延迟、高可靠性。技术决策采用“边缘计算”为主“云端协同”为辅的架构。将AI推理模型直接部署在实验室现场的边缘计算设备如英伟达Jetson Nano上而不是将视频流全部上传到中心服务器。理由边缘计算将处理放在数据产生端极大减少了网络传输延迟确保了报警的实时性。同时边缘设备只将报警事件和关键数据非完整视频流上传至云端服务器进行存储和报表分析减轻了带宽压力也符合数据隐私和安全需求。4.2 功能需求如何驱动系统设计用户需求“自动报警并记录”分解为多个功能需求后驱动了整个系统模块的设计FR-001实时分析-视频流处理模块需要使用OpenCV或GStreamer高效抓取RTSP视频流。FR-002, 003安全帽检测-AI推理模块需要加载训练好的YOLO模型并实现前后处理图像缩放、归一化、NMS等。FR-004画面标注-告警可视化模块需要将推理结果边界框、标签实时叠加到视频流上并输出到显示界面。FR-005语音报警-告警触发模块需要调用本地TTS引擎或播放音频文件。FR-006事件记录-数据持久化模块需要设计数据库表结构记录时间、摄像头ID、违规类型、快照图片路径等并实现插入逻辑。每一个功能需求都对应了系统中的一个具体模块或接口这使得我们的系统设计高度契合需求避免了过度设计或设计不足。5. 需求验证与持续迭代确保不跑偏需求文档写出来不是束之高阁的。我们建立了简单的验证和迭代机制需求评审会邀请指导老师、团队所有成员甚至是非技术背景的同学一起评审需求文档。大家从不同角度提问“这个功能用户真的需要吗”、“这个技术方案能实现这个需求吗”、“这个优先级合理吗”。这个过程能发现很多逻辑漏洞和想当然的部分。原型验证对于关键的用户交互流程如管理员查看报警记录我们用高保真原型模拟操作让目标用户我们找了另一位实验室管理员试用收集反馈。我们曾发现最初设计的报表下载流程过于复杂根据反馈简化了。需求跟踪矩阵在开发过程中我们维护一个简单的表格将需求ID与对应的代码文件、测试用例关联起来。确保每一个开发任务都源自明确的需求每一个需求都有对应的实现和验证。拥抱变化在开发中期我们了解到某个实验室有特殊的“防静电手环”佩戴要求。经过评估我们认为这是一个有价值的“Should have”需求且实现成本可控只需增加一个检测类别并重新标注少量数据。我们并没有死守最初的文档而是经过团队讨论和老师同意后将其纳入迭代范围这反而让我们的项目更具针对性和亮点。6. 国奖答辩中如何呈现需求分析需求分析做得再好如果在答辩中讲不出来效果也大打折扣。我们的经验是讲故事而不是念文档不要一上来就说“我们采用了UML用例图”。而是从“我们在调研中发现实验室安全管理存在三大痛点……”开始引出我们的项目动机。可视化呈现将用户故事地图、用例图、功能优先级矩阵MoSCoW做成清晰的PPT图表。一图胜千言。突出决策逻辑重点讲清楚“为什么”。为什么选择YOLO而不是其他算法为什么用边缘计算这些技术选择的背后都是源于对“实时性”、“低成本”、“易部署”等非功能需求的深入考量。这能充分体现团队的系统性思维和工程权衡能力。展示证据适时展示访谈照片、问卷数据摘要、竞品分析对比表证明你的需求不是闭门造车而是源于扎实的调研。关联价值始终将每一个需求点与项目最终要实现的业务价值提升安全、提高效率和社会价值响应智慧校园建设、保障科研人员安全挂钩。7. 常见误区与避坑指南回顾整个历程我们看到很多其他团队在需求分析阶段容易陷入的误区这里分享我们的避坑经验误区一把想法当需求。“我想做一个AI系统”是想法。“实验室管理员需要一个能自动识别未戴安全帽人员并实时报警的系统”才是需求。一定要追问“谁在什么情况下要解决什么问题”直到能清晰地描述出用户和场景。误区二需求大而全贪多嚼不烂。试图做一个“万能实验室安全系统”结果每个功能都做不深。深度优于广度。抓住1-2个核心痛点做深做透形成完整闭环远比做一个功能杂烩的“Demo合集”更有竞争力。误区三忽略非功能需求只关注“做什么”不关心“做多好”、“多快”、“多稳定”。结果做出来的系统延迟高达几秒或者界面极其难用。评委一眼就能看出这是缺乏工程思维的学生作品。务必量化你的非功能需求哪怕只是基于调研的合理估计。误区四需求与分析脱节需求文档写完后就扔给开发后续再无交集。一定要建立可追溯性。确保每一行代码、每一个测试用例都能回溯到最初的需求这样在开发中遇到歧义或需要取舍时才有据可依。误区五闭门造车缺乏用户验证几个队员在寝室里头脑风暴出来的需求往往脱离实际。走出去和你的目标用户聊哪怕只是简单的交流也能获得意想不到的洞见。我们关于“违规证据链”的需求就是在一次看似随意的聊天中获得的。需求分析是一场严谨的逻辑推演和深刻的用户共情。它没有炫酷的代码和直观的界面却从根本上定义了项目的灵魂和骨架。在我们看来这份深入、扎实的需求分析文档是我们作品能够打动评委从众多项目中脱颖而出的第一块也是最重要的一块基石。它让我们在后续的开发、测试、答辩中始终目标清晰步履坚定。