团队作业3：需求改进与系统设计

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class12Grade23ComputerScience/
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class12Grade23ComputerScience/homework/13473

一.需求&原型改进
1.1针对老师问题的修改
问题1​：老师提出“软件只用于PC端，软件是否也可以设置为移动端”。
​修改1​：调整开发规划，将软件从仅支持PC端扩展为支持多端适配​（包括移动端，如iOS、Android系统的手机/平板），采用响应式设计或跨端开发框架（如Flutter、React Native），确保在移动端的操作流程（如账单管理、查看）与PC端体验一致且符合移动端交互习惯
问题2​：老师提出“如何上传账单”。
​修改2​：优化账单上传功能，提供多种上传方式​：
支持通过手机相册/文件管理器直接选择账单图片（OCR识别提取账单信息）；
支持手动输入账单信息（如金额、日期、商户等）；
支持从第三方应用（如支付宝、微信支付账单）导入账单数据，简化用户操作步骤。
问题3​：老师提出“可以看到详细帐单吗”。
​修改3​：完善账单详情展示模块，在原有基础上增加更多维度信息​：
展示账单的明细分类（如餐饮、交通、购物等）、消费地点、支付方式、关联的优惠活动；
提供账单的时间筛选（按日/周/月/年）、金额筛选，并支持账单的导出（如PDF、Excel格式）和分享功能。

1.2目标用户调研与需求沟通

1. 目标用户定位
   目标用户为个人消费者​（如上班族、学生）和小型企业主​（如个体商户、初创团队），他们有管理个人/企业账单的需求，希望便捷记录、查看和分析收支情况
2. 用户的“痛”
   移动端缺失的痛​：用户在外出时（如出差、购物）无法及时记录或查看账单，只能依赖PC端，导致账单管理不及时、效率低。
   ​账单上传繁琐的痛​：传统上传方式（如手动输入）耗时久，且容易出错；缺乏便捷的图片识别或第三方导入功能，增加用户操作成本。
   ​账单信息不全的痛​：仅能看到账单的基本金额和时间，无法了解消费的详细背景（如分类、地点、优惠），难以进行精准的收支分析。
3. 用户的使用场景
   ​移动端场景​：用户在通勤路上（如地铁、公交），通过手机快速上传当天的消费账单（如扫码支付的账单图片），并查看本周的支出汇总，规划后续消费。
   ​账单上传场景​：用户在餐厅用餐后，用手机拍摄账单照片，通过软件的OCR功能自动识别金额、商户等信息，无需手动输入，快速完成账单录入。
   ​账单详情场景​：用户在月底进行财务总结时，打开软件查看某笔大额账单的详细信息（如消费地点、关联的优惠活动），分析该笔支出的合理性，优化后续消费计划。
   二.需求规格说明书完善
4. 功能覆盖不全面，缺少关键非功能性需求与扩展功能
   初稿中虽然明确了三大核心功能（数据导入与清洗、智能分类与统计、消费分析可视化、消费报告与洞察），但对如下方面描述不足或缺失：
   用户账户与数据管理：是否支持多账期数据保存？是否支持数据导出/备份？
   异常处理机制：当用户上传的账单格式错误或数据异常时，系统如何提示与容错？
   系统性能与响应速度：特别是在数据量大时，图表渲染、数据加载是否流畅？
   兼容性与可扩展性：是否支持未来扩展其他账单来源（如银行APP账单）？是否支持多语言/主题切换？
   改善：
   在“功能需求”中补充 FR5 数据存储与管理（如本地数据缓存、历史记录查看、数据导出功能）。
   增加 非功能需求：
   NFR1：系统应保证在本地数据量<1000条记录时，图表渲染时间<2秒。
   NFR2：系统应具备基本的输入校验与异常提示功能，如账单格式识别失败时给出明确引导。
   NFR3：界面应适配常见屏幕分辨率，支持深色/浅色主题切换。
5. 用户使用场景与需求痛点挖掘不够深入
   初稿对“用户特征”和“需求痛点”虽有提及，但缺乏具体的使用情境描述，比如：
   学生在月底发现钱花超了，却不知道钱具体花在哪里；
   想了解自己近几个月餐饮/娱乐消费趋势，但手动整理太麻烦；
   担心用在线工具记账会泄露隐私，但又希望获得可视化的消费分析。
   改进：
   在“用户画像”或“需求背景”中，增加典型用户使用场景的细节描述，让功能设计更有针对性。
   补充“用户目标”小节，例如：“用户希望通过3步简单操作，快速了解自己每月消费结构，找到可优化的开销项，并形成理性消费习惯。
6. 缺少用户描述，功能之间的联动关系不直观
   当前说明书以功能点罗列为主（FR1~FR4），但没有描述用户如何一步步使用这些功能来解决实际问题，功能之间的“流转关系”不清晰。
   改进：
   加典型用户使用流程图或故事
   在功能描述中补充功能之间的关联逻辑
   4.功能分析的四个象限

象限	功能类型	功能
第一象限	基础功能	日常收支快速录入（如扫码/语音记账）
第二象限	提升记账体验的功能	智能分类优化（AI识别收支场景自动归类）
第三象限	临时功能	账单错误紧急修正（如重复记账/金额错误）
第四象限	设计额外功能	财务报表可视化

5.任务分解WBS及相应的项目进度计划

阶段	任务细分	耗时（周）
需求	记账场景问题收集与需求分析（如：收支分类模糊、统计效率低等痛点）	2
设计	功能四象限优先级确认（核心功能：快速记账；次要功能：多维度统计；辅助功能：个性化设置等）	4
开发	后端：记账分类模块开发 + 账单CRUD接口（增删改查）	5
后期	功能灰度发布	3

1.需求：聚焦“记账场景”的痛点（如分类模糊、统计低效），调研对象明确为会计（专业需求）+ 个人用户（日常需求），更贴合记账工具的用户画像。
2.设计：功能优先级围绕“快速记账（核心）→ 统计分析（次要）→ 个性化（辅助）”展开；技术方案新增“AI自动分类”（记账工具的核心智能化需求）、“数据加密”（财务数据安全）。
3.开发：后端侧重“AI分类模块”）和“账单接口”（支撑记账流程）；前端强调“响应式界面+图表可视化”；测试聚焦多设备兼容+AI分类准确性
4.部署：灰度发布针对“会计/个人用户”（目标用户），迭代优化围绕“修复BUG+优化AI分类+提升易用性”，确保工具贴合实际使用场景
三..接口设计

接口功能 端点 (Endpoint)
上传并解析账单 /api/upload
获取分析概览 /api/analysis/overview?file_id=123&period=2025-11
获取消费趋势 /api/analysis/trend?file_id=123&range=6months
获取分类消费明细 /api/analysis/details?file_id=123&category=餐饮
生成消费报告 /api/report/generate
核心数据表详细说明
1. USERS(用户表)作用：存储用户的基本信息，实现简单的数据隔离。即使作为本地应用，也可支持未来“多用户模式”（如家庭成员）。
关键字段：password_hash存储的是加密后的密码，而非明文，这是基本的安全规范。
2. BILL_FILES(账单文件表)作用：记录每一次上传的账单文件元信息。保留此记录便于用户管理上传历史，避免重复处理相同文件。
关键字段：file_type用于区分支付宝和微信账单，便于后续使用不同的解析规则。
3. CATEGORIES(分类规则表)作用：这是实现智能分类的核心。该表不仅定义了分类名称，更以JSON格式存储了分类关键词规则。
示例：category_name为“餐饮”，其 keywords字段值可以是 ["食堂", "餐厅", "外卖", "美食", "餐", "饭"]。程序通过匹配交易信息中的文字和这些关键词来实现自动归类。这种设计使得增删、修改分类规则变得非常灵活。
4. TRANSACTIONS(交易记录表)作用：存储从账单文件中解析出来的每一条交易记录，是数据分析的基石。
关键字段：amount：金额，用正负值区分收入与支出，便于聚合计算。
category_id：这是一个外键，允许为NULL。初始自动分类时，如果无法匹配任何规则，此值为空；用户也可以手动重分类，此时会更新此字段。这体现了设计的灵活性。
5. BUDGETS(预算表)作用：支持用户为不同消费类别设置月度预算，是实现“消费预警”等高级功能的基础。
关键关系：通过 user_id和 category_id与用户和分类关联。

系统架构设计分层架构：​ 采用经典的三层架构，使开发分工明确。
表现层（UI）：​ 负责展示用户界面（如网页界面），与用户交互。
业务逻辑层（BLL）：​ 包含核心处理逻辑，如账单解析、智能分类算法、数据统计分析。
数据访问层（DAL）：​ 负责与本地数据库（如SQLite）交互，安全地存储和读取用户消费数据。
技术选型：前端：​ HTML5 + CSS3 + JavaScript (使用ECharts图表库)
后端：​ Python Flask框架
数据库：​ SQLite（轻量级，无需安装，适合桌面应用）
数据处理：​ Pandas库

四.Alpha任务分配计划

1. 选取Product Backlog功能项 (5分)根据优先级和依赖关系，从需求列表中选出Alpha阶段要实现的核心功能，例如：用户登录与数据本地存储
   支付宝CSV账单解析与导入
   基于关键词的消费智能分类
   消费数据的饼图与趋势图展示
2. 分解为Sprint Backlog任务
   任务：
   设计数据库表结构
   实现Flask后端基础框架
   开发主页面UI
   集成ECharts，实现饼图组件
   甘特图形式的迭代计划

五.测试计划
测试策略：​ 我们将采用边开发边测试的策略。开发人员负责单元测试，测试人员负责功能测试和集成测试。
测试阶段与内容：
1.单元测试：​ 针对核心函数（如账单解析、分类算法）进行测试。
2.功能测试：​ 验证每个功能点（如文件上传、图表生成）是否按需求正常工作。
3.界面测试：​ 检查用户界面是否美观、易用。
4.兼容性测试：​ 确保在主流浏览器上正常运行