需求分析（第五组）

一、项目背景

随着我国《"十四五" 残疾人保障和发展规划》的深入推进，信息无障碍建设成为社会关注的焦点。根据中国残联统计数据，我国现有视障人士 1700 万，其中高校在读视障学生数量逐年递增。当前视障群体在校园场景中面临三大核心痛点：动态障碍物检测缺失（如施工路段、临时堆放物）、无障碍导航模式手动切换繁琐、紧急情况下救援响应延迟。现有商业化导航应用虽具备基础无障碍功能，但存在场景适配不足（如未集成实时摄像头检测）、交互成本高（需频繁操作屏幕）、本地化服务缺失（无法精准标注校园无障碍设施）等问题。
为响应教育部《教育信息化 2.0 行动计划》中 "技术赋能特殊教育" 的号召，本项目团队基于对 200 名视障用户的调研数据（82% 受访者曾因障碍物检测缺失摔倒），启动 **"无障碍导航助手"开发。项目旨在通过轻量化多模态感知技术与低成本交互系统设计 **，构建一套校园场景专属的智能导航解决方案，实现动态障碍物实时预警、盲道优先路径规划、紧急 SOS 一键求助三大核心功能，最终达成降低视障学生校园出行风险、提升自主生活能力、推动校园无障碍环境建设的社会目标。

二、用户需求概述

角色 1：视障用户
日常工作任务需求
独立出行：需借助盲道、导盲杖完成教学楼、食堂等校园场所间移动
应急处理：遭遇突发障碍物（如井盖缺失）时缺乏有效预警手段
信息获取：依赖他人帮助获取校园设施位置信息（如无障碍电梯）
系统功能期望
实时障碍物检测：支持 0.5m/1m/2m 分级震动预警（对应危险等级）
智能路径规划：自动识别盲道并生成坡度 < 5% 的安全路线
离线导航模式：存储常用路线支持断网使用
多模态交互：语音指令控制 + 震动反馈（支持息屏操作）
紧急求助系统：摇晃手机触发含定位的短信通知（预设 3 位联系人）

角色 2：紧急联系人
日常工作任务需求
安全监护：需及时掌握视障亲属的位置信息
应急响应：在突发情况下快速定位并实施救援
系统功能期望
位置共享：接收含实时坐标的 SOS 短信（支持高德地图直接导航）
历史轨迹：通过微信小程序查看近 7 日移动路径（需用户授权）
异常警报：连续 10 分钟无定位更新触发提醒（防设备故障）

角色 3：校园管理人员
日常工作任务需求
设施维护：定期巡检无障碍设施（如盲道损坏情况）
数据收集：获取视障学生高频事故区域信息
系统功能期望
热力图分析：按周生成障碍物检测热点区域报告
设施标注：通过管理后台添加 / 更新无障碍设施位置（如电梯编号）
数据导出：导出用户反馈的障碍物类型及处理建议

重点需求引导作用：
实时障碍物检测（角色 1 核心需求）驱动 YOLOv5s 算法的轻量化部署
紧急 SOS 功能（角色 2 关键需求）促成北斗 / GPS 混合定位技术方案
热力图分析（角色 3 新增需求）推动 SQLite 数据库的历史轨迹存储设计
通过多角色需求整合，项目确定以视障用户安全出行为核心，同步满足监护者的应急需求与校园管理的优化需求，形成 "用户感知 - 系统响应 - 环境改善" 的闭环生态。

三、功能性需求

功能模块 1：障碍物检测
功能 1.1：实时检测
输入内容：手机摄像头实时采集的图像数据。
操作流程：图像数据通过 OpenCV 库进行预处理，去除噪声、增强对比度等；随后输入 YOLOv5s 轻量级目标检测模型，模型对图像中的台阶、井盖、临时障碍物等进行识别与分类。
输出结果：检测到障碍物时，输出障碍物的类型（如台阶、井盖等）、距离（通过手机摄像头焦距及图像中物体大小估算）以及位置信息（在图像中的坐标）。

功能 1.2：分级预警
输入内容：功能 1.1 检测出的障碍物距离信息。
操作流程：系统根据预设的距离阈值（0.5m、1m、2m）对障碍物距离进行判断。
输出结果：当障碍物距离在 2m 时，手机马达以低频震动预警；距离在 1m 时，以中频震动预警；距离在 0.5m 时，以高频震动预警，同时通过百度语音合成 API 进行语音播报障碍物类型及距离。

与其他功能模块的交互
与导航模块交互：将检测到的障碍物位置信息传递给导航模块，导航模块根据障碍物位置实时调整路径规划，避开障碍物。
与记录模块交互：将检测到的障碍物相关信息（类型、时间、位置）传递给记录模块进行存储，用于后续数据分析。

功能模块 2：路径规划
功能 2.1：基础路径生成
输入内容：用户当前位置（通过北斗 / GPS 混合定位获取）、目的地（用户语音输入或在地图上选择）。
操作流程：系统调用高德地图 API 的 “无障碍路径” 功能接口，结合校园地图数据，以盲道优先为原则，生成从当前位置到目的地的路径。通过设置最大坡度阈值等参数对路径进行纠偏。
输出结果：输出包含一系列坐标点的路径规划结果，以及预计到达时间。

功能 2.2：实时路径调整
输入内容：障碍物检测模块传递的障碍物位置信息、用户实时位置信息。
操作流程：当接收到障碍物位置信息或用户位置偏离规划路径时，系统重新调用路径规划算法，基于新的位置和障碍物情况，在原路径基础上进行局部调整。
输出结果：输出调整后的路径规划结果，通过语音和震动引导用户按照新路径行进。

与其他功能模块的交互
与障碍物检测模块交互：接收障碍物位置信息，作为路径调整的依据。
与导航模块交互：将生成或调整后的路径规划结果传递给导航模块，用于实时导航引导。

功能模块 3：导航引导
功能 3.1：语音导航
输入内容：路径规划模块生成的路径规划结果。
操作流程：系统将路径规划结果中的各个路段信息（如转弯方向、距离）转化为语音指令，通过百度语音合成 API 进行语音播报。同时，根据用户位置实时更新播报内容。
输出结果：持续的语音导航指令，引导用户按照规划路径行进。

功能 3.2：震动导航
输入内容：路径规划模块生成的路径规划结果、用户实时位置信息。
操作流程：系统根据用户距离转弯点、路口等关键位置的距离，通过手机马达发出不同节奏的震动，提示用户即将进行的操作。
输出结果：有节奏的震动反馈，辅助语音导航，方便用户在嘈杂环境或不方便听语音时获取导航信息。

与其他功能模块的交互
与路径规划模块交互：接收路径规划结果，进行导航引导。
与位置定位模块交互：获取用户实时位置信息，更新导航状态。

四、非功能性需求
性能需求
响应时间
日常业务场景：障碍物检测在 0.8 秒内完成响应，路径规划在 3 秒内完成，导航信息更新在 1 秒内完成。
高峰时段（假设多用户同时使用）：障碍物检测响应时间不超过 1 秒，路径规划不超过 5 秒，导航信息更新不超过 2 秒。

吞吐量
系统在单位时间内（每分钟）能够处理至少 100 次障碍物检测请求、50 次路径规划请求，确保在校园内较多视障用户同时使用时，系统仍能稳定运行。
数据存储与读取效率
数据存储：在存储历史路径数据、障碍物检测记录等信息时，每秒能够存储至少 50 条记录。
数据查询：查询近一周的历史路径数据或特定区域的障碍物检测记录时，查询时间不超过 3 秒。
数据更新：更新用户个人设置、地图数据等信息时，更新操作在 1 秒内完成。

安全需求
用户身份验证
采用手机号 + 密码组合登录方式，密码采用 SHA - 256 哈希加密存储。同时，支持短信验证码登录，增强登录安全性，确保只有合法用户能够访问系统。

数据加密
存储加密：用户位置信息、历史路径数据等敏感数据在本地 SQLite 数据库存储时，采用 AES 加密算法进行加密存储。
传输加密：在数据传输过程中，如位置信息上传、路径规划请求与响应等，采用 HTTPS 协议进行加密传输，防止数据被窃取或篡改。

访问控制
视障用户角色：拥有使用障碍物检测、路径规划、导航引导等全部核心功能的权限，但无法访问系统管理相关功能。
紧急联系人角色：只能查看与视障用户相关的位置信息、历史轨迹（需视障用户授权），无法进行其他操作。
校园管理人员角色：可以访问系统的热力图分析、设施标注、数据导出等管理功能，但不能随意修改用户个人信息。

安全审计
系统记录用户登录日志、关键操作日志（如路径规划请求、紧急 SOS 触发）等安全相关事件。通过定期分析这些日志，及时发现潜在的安全隐患，如异常登录行为、频繁的路径规划请求等，并追溯问题源头。

易用性需求
界面设计
简洁美观：采用简洁的设计风格，界面元素布局合理，色彩对比度高，方便视障用户使用屏幕阅读器识别。
操作流程简化：操作流程尽量简化，减少用户操作步骤。例如，在启动障碍物检测功能时，只需一键点击即可开启。
信息提示友好：在进行各种操作时，提供清晰、简洁的语音提示和文字提示（如果用户可查看），如操作成功提示、错误原因提示等。

操作指南
详细操作指南：系统配备详细的操作指南文档，以文字和语音两种形式呈现，方便视障用户获取。操作指南涵盖从下载安装到使用各个功能模块的详细步骤。
在线客服支持：提供在线客服支持，用户在使用过程中遇到问题时，可以通过语音留言或其他便捷方式联系客服，客服人员及时给予解答和帮助。

多终端支持
系统支持在主流的安卓和 iOS 移动端设备上使用，确保在不同操作系统版本（安卓 5.0 及以上、iOS 10.0 及以上）上都能正常运行，界面适配良好，功能稳定。暂不考虑电脑端访问。

兼容性需求
浏览器兼容
由于系统主要以移动端应用形式存在，不涉及浏览器访问，因此无需考虑浏览器兼容性问题。
软件 / 硬件兼容
硬件设备：兼容市面上主流的智能手机品牌和型号，确保手机摄像头、GPS 模块、加速度传感器、蓝牙等硬件功能能够正常被系统调用。
软件：与手机系统自带的短信功能、语音功能等软件模块能够稳定交互，确保紧急 SOS 功能、语音导航功能等正常运行。

五、系统架构需求
总体架构设计
采用分层架构模式，主要分为以下三层：
表现层：负责与用户进行交互，采用微信小程序开发前端界面。复用开源组件库 WeUI，实现简洁美观的界面设计。接收用户输入的操作指令（如开启障碍物检测、输入目的地等），并将系统处理结果（如导航语音、震动反馈）呈现给用户。
业务逻辑层：处理系统的核心业务逻辑。包含障碍物检测模块、路径规划模块、导航引导模块等。调用底层的数据和算法资源，对用户请求进行处理，并协调各模块之间的交互。例如，路径规划模块根据用户输入的位置信息和地图数据，调用算法生成路径规划结果。
数据访问层：负责与本地数据库（SQLite）进行交互，存储和读取历史路径数据、用户设置信息、障碍物检测记录等。同时，与第三方 API（如高德地图 API、百度语音合成 API）进行对接，获取地图数据、实现语音合成功能等。

选择分层架构的原因是：各层职责明确，便于开发、维护和扩展。表现层专注于用户交互，业务逻辑层专注于业务处理，数据访问层专注于数据操作，降低了模块之间的耦合度。同时，分层架构有利于团队分工协作，提高开发效率。

以下是系统架构图：

以下是系统结构图：

以下是业务流程图（UML 活动图）：

以下是状态机图：

六、数据需求
数据实体
实体 1：视障用户
用户 ID：唯一标识视障用户，由系统自动生成，采用 UUID 算法生成的 32 位字符串。
手机号：用户注册时使用的手机号码，用于登录和紧急联系，格式为 11 位数字。
密码：用户登录密码，采用 SHA - 256 哈希加密存储，长度为 64 位字符串。
紧急联系人 1：用户设置的第一个紧急联系人姓名，字符串类型。
紧急联系人 1 电话：第一个紧急联系人的电话号码，11 位数字。
紧急联系人 2：用户设置的第二个紧急联系人姓名，字符串类型。
紧急联系人 2 电话：第二个紧急联系人的电话号码，11 位数字。
常用地址 1：用户经常前往的地址之一，字符串类型。
常用地址 2：用户经常前往的地址之二，字符串类型。
设置信息：用户个性化设置，如语音播报音量、震动强度等，以 JSON 格式存储。

实体 2：障碍物记录
记录 ID：唯一标识障碍物记录，由系统自动生成，采用自增长整数。
用户 ID：关联视障用户 ID，表明该障碍物记录由哪位用户触发，与视障用户实体形成多对一关系。
检测时间：障碍物被检测到的时间，采用时间戳格式存储。
障碍物类型：如台阶、井盖、临时堆放物等，字符串类型。
位置信息：障碍物所在位置的经纬度坐标，采用浮点数表示。

实体 3：路径规划记录
记录 ID：唯一标识路径规划记录，由系统自动生成，采用自增长整数。
用户 ID：关联视障用户 ID，表明该路径规划记录属于哪位用户，与视障用户实体形成多对一关系。
起始位置：路径规划的起始点经纬度坐标，采用浮点数表示。
目的地：路径规划的目的地经纬度坐标或地址描述，字符串类型。
规划时间：路径规划生成的时间，采用时间戳格式存储。
路径详情：包含路径中各个坐标点的 JSON 数组，详细记录规划路径。

数据关系
文字描述
视障用户与障碍物记录：一个视障用户可以产生多条障碍物记录，而一条障碍物记录只对应一个视障用户，是一对多的关系。
视障用户与路径规划记录：一个视障用户可以有多个路径规划记录，而一条路径规划记录只属于一个视障用户，是一对多的关系。

用例图如下；

E-R图如下：

数据流图（0层）如下：

数据流图（1层）如下：

七、项目进度安排
项目从 2025 年 5 月 1 日开始，各阶段时间安排如下：

需求调研与分析阶段：2025 年 5 月 1 日 - 2025 年 5 月 31 日
    任务：
        利用课余时间，通过线上问卷、线下访谈以及与校内视障社团合作等方式，收集视障用户、紧急联系人以及校园管理人员等各方需求。
        周末和节假日集中对收集到的需求进行梳理，运用亲和图、思维导图等工具整理分析，提炼关键需求点。
        撰写详细的需求文档，在文档撰写过程中，组织团队成员每晚线上讨论，确保需求的准确性和完整性。
        完成初稿后，利用周末时间与客户（视障用户代表、校园管理部门等）沟通，确认需求。
    输出物：《无障碍导航助手需求分析报告（定稿）》
系统设计阶段：2025 年 6 月 1 日 - 2025 年 7 月 31 日
    任务：
        依据需求分析报告，在课余时间进行系统架构设计，确定采用分层架构模式，明确各层职责。可利用每周的技术交流时间向指导老师请教架构设计细节。
        进行数据库设计，包括设计数据实体、数据关系，绘制 ER 图。利用暑假时间集中精力完成数据库设计，遇到问题通过线上论坛、专业社群等渠道寻求帮助。
        开展界面设计，使用 Axure 等工具制作微信小程序界面原型。可在暑假期间组织几次线下小组会议，共同完善界面设计。
        开学后组织团队内部评审，利用周末时间对架构设计、数据库设计、界面设计进行审查和完善。
    输出物：《无障碍导航助手系统设计文档》，包含系统架构图、ER 图、界面原型等
开发阶段：2025 年 8 月 1 日 - 2025 年 10 月 31 日
    任务：
        前端开发人员根据界面设计原型，基于微信小程序框架进行界面开发。利用课余时间和周末推进开发工作，定期在团队内展示开发成果，交流问题。
        后端开发人员采用 Python Flask 框架进行后端服务开发，实现用户管理、数据存储与读取等功能。在开发过程中，与前端开发人员每周进行一次接口对接沟通。
        算法团队集成 YOLOv5s 等目标检测模型，实现障碍物检测功能，调用高德地图 API 实现路径规划功能。利用课余和周末时间进行算法优化和调试，遇到技术难题及时向指导老师或相关专家请教。
        每月定期进行代码审查，利用周末时间开展集成测试，及时发现并解决模块间的集成问题。
        按阶段提交代码成果，每次提交后组织团队成员进行复盘总结。
    输出物：阶段性可运行的代码版本
测试阶段：2025 年 11 月 1 日 - 2025 年 11 月 30 日
    任务：
        全面开展功能测试，利用课余时间按照测试用例对系统各项功能进行逐一测试，检查是否符合需求规格说明书。
        进行性能测试，选择周末时间测试系统在不同场景下的响应时间、吞吐量等性能指标。
        开展安全测试，利用课余时间检查系统的用户身份验证、数据加密、访问控制等安全机制是否有效。
        进行兼容性测试，确保系统在主流安卓和 iOS 设备上能够正常运行，可在课余时间和周末完成。
        记录测试过程中发现的问题，并及时反馈给开发团队进行修复，利用每天晚上的时间跟进修复进度。
        对修复后的问题进行回归测试，确保问题得到彻底解决。
    输出物：《无障碍导航助手测试报告》
上线部署阶段：2025 年 12 月 1 日 - 2025 年 12 月 31 日
    任务：
        在腾讯云轻量应用服务器（学生版）等服务器环境中安装部署系统，利用课余和周末时间完成部署工作，遇到问题及时查阅官方文档或咨询客服。
        上线前进行最后检查，确保系统各项功能正常、数据准确无误，利用周末时间进行全面检查。
        组织视障用户、校园管理人员等相关用户进行培训，可利用周末和课余时间，通过线上线下结合的方式开展培训。
        正式上线系统，保障系统顺利运营，上线后安排专人在课余时间关注系统运行情况，及时处理突发问题。

项目进度甘特图如下：

八、项目风险评估与应对
技术风险
风险描述：
新技术应用难度大：作为大三学生，项目中使用的 YOLOv5s 目标检测模型以及相关手机端传感器融合技术对我们来说具有较高难度，在模型优化、实时检测效果提升以及与手机硬件的适配方面可能面临挑战。
技术选型失误：由于技术经验相对不足，可能选择的微信小程序开发框架或其他技术工具不能很好地满足项目复杂功能需求，例如在实现高精度室内定位功能时，所选技术无法达到预期效果。
技术难题攻克不了：在实现震动与语音双模态精准反馈、复杂场景下的路径规划优化等方面，可能遇到短期内难以解决的技术难题。
可能性评估：高
影响程度评估：高，可能导致项目关键功能无法实现、开发周期大幅延长，甚至项目失败。
应对策略：
提前技术预研：在课程之余，利用课余时间和周末进行技术预研，对关键技术如目标检测模型在手机端的性能测试、不同定位技术的可行性分析等进行深入研究。
引入专家支持：积极邀请学校计算机学院的专业老师作为技术指导，定期组织线上或线下的技术交流会议，及时解决技术难题。
建立技术备用方案：针对室内定位等关键功能，如果最初选择的 Wi-Fi 定位和蓝牙信标定位技术效果不佳，提前研究超宽带（UWB）定位等备用技术方案，以便及时切换。
加强团队技术培训：利用线上课程平台，如慕课、网易云课堂等，组织团队成员学习目标检测、移动开发、算法优化等相关技术课程，提升技术能力。

需求变更风险
风险描述：
业务调整：校园管理部门可能根据实际使用情况或新的校园建设规划，对系统功能提出新的需求或调整原有需求，如增加特定区域的导航限制或新的无障碍设施标注需求。
用户需求理解变化：视障用户在试用过程中，可能由于沟通理解偏差，对系统的操作方式、反馈形式等提出新的需求，导致需求变更。
可能性评估：中
影响程度评估：高，频繁的需求变更可能打乱开发计划，导致项目进度延迟、成本超支，同时影响团队的开发积极性和系统稳定性。
应对策略：
建立严格需求变更流程：明确需求变更必须经过需求提出、影响评估、审批通过、实施调整等环节，确保变更的必要性和合理性。
成立变更评估小组：由团队中的项目经理、技术负责人、需求分析人员等组成变更评估小组，对每一项需求变更进行全面评估，包括对项目进度、成本、技术实现难度等方面的影响。
合理调整项目计划与资源分配：根据变更评估结果，及时对项目计划进行调整，合理分配团队成员的时间和精力，确保项目能够顺利推进。

人力资源风险
风险描述：
关键人员离职：团队中负责核心算法开发、小程序前端设计等关键岗位的成员，可能由于学业压力、个人职业规划等原因中途退出项目，导致技术衔接困难，项目进度受阻。
团队协作不畅：团队成员来自不同专业和背景，在沟通协作上可能存在障碍，例如算法团队与开发团队在数据接口定义、数据传输格式等方面存在分歧，影响项目推进效率。
人员技能不足：部分团队成员可能对某些新技术或业务领域了解有限，如对无障碍设计规范、复杂算法原理等掌握不够深入，影响系统的开发质量。
可能性评估：中
影响程度评估：中高，可能导致项目进度延迟、质量下降，增加项目失败的风险。
应对策略：
关键岗位备份：对于关键岗位，提前培养备份人员，在项目开发过程中，确保每个关键技术环节至少有两名成员熟悉，以便在人员变动时能够及时接替工作。
加强团队建设：定期利用周末或课余时间组织团队建设活动，如户外拓展、技术分享会等，增强团队凝聚力和协作能力；建立每日线上站会、每周线下例会等沟通机制，及时解决团队内部的沟通问题。
建立激励机制：制定合理的项目绩效考核和激励制度，将项目成果与成员的学业成绩加分、综合素质评价等挂钩，提高团队成员的工作积极性和稳定性。
开展培训提升技能：根据项目需求和团队成员技能短板，利用课余时间邀请专业人士进行线上或线下培训，如无障碍设计规范培训、前沿算法应用培训等，提升团队整体技术水平。

外部因素风险
风险描述：
政策法规变化：国家或地方关于无障碍设施建设、信息安全、个人隐私保护等方面的政策法规发生变化，可能导致系统需要进行相应调整，如数据隐私保护政策加强，要求对系统的数据存储和使用方式进行改进。
市场波动：如果市场上出现功能更完善、体验更好的同类无障碍导航产品，可能影响本项目的推广和应用，导致项目的社会影响力和实际应用价值降低。
第三方合作伙伴问题：高德地图 API、百度语音合成 API 等第三方接口出现故障、调整收费策略或与系统兼容性问题，影响系统的正常运行，如高德地图 API 免费额度大幅减少，增加项目运营成本。
可能性评估：中
影响程度评估：高，可能导致项目无法正常运营、用户流失、成本大幅增加，甚至项目夭折。
应对策略：
关注政策法规动态：安排团队成员定期关注相关政策法规的更新变化，及时向指导老师请教解读，根据政策要求及时调整项目方案，确保系统合规运营。
建立市场监测机制：利用课余时间定期收集市场上同类产品的信息，分析竞争态势，及时调整项目的功能优化方向和推广策略，突出本项目的特色和优势。
与第三方签订严谨合同：在与第三方合作伙伴签订合同时，明确服务标准、价格调整机制、故障处理责任、数据安全保障等条款，降低合作风险。
提前规划替代方案：对于关键的第三方服务，寻找备用方案，如在语音合成方面，除百度 API 外，研究科大讯飞语音合成、阿里云语音合成等备用方案，以便在出现问题时能够及时切换。

个人贡献评分准则
合作共赢

评估贡献比例
| 姓名 | 贡献比例 |
| 李潇潇 | 16% |
| 吴吉祥 | 14% |
| 张博 | 14% |
| 黄豪 | 14% |
| 马瑞祥 | 14% |
| 喜鹤礼 | 14% |
| 马健 | 14% |