第一次团队作业——“行趣”智能旅游软件

作业所属的课程	软件工程2024
作业要求	2024秋软工实践团队作业-第一次
作业的目标	开发一款基于LLM大模型接口的软件，为这个软件做需求分析
团队名称	十光年
团队成员学号-姓名	施靖杰-102201327 邓才慧-102201102 陈宇尧-102201119 陆旭东-102201118 黄宇舟-102201331 邱予-102202121 高鑫源-102201635 黄森福-102201636 洪金举-102202136 朱思颖-102201106

团队展示

团队名称与队标

队伍名称为“十光年”
“光年”是宇宙测量的最大距离单位，光也是宇宙中最快的速度，“十光年”不仅象征团队对未来有长远的规划和愿景，更追求高速发展、创新突破。
光年也往往与宇宙和星际探索联系在一起，暗示着团队用于探索未知领域，突破自我，团队成员之间紧密团结，共同跨越困难，朝着共同的目标不断前进。

1.整体主题

• 太空与光速的象征：标志使用了太空和星际探索的元素，强化了“十光年”这一概念的象征意义。光束穿梭的设计展现了宇宙速度的概念，寓意团队快速发展、前瞻未来、探索未知的精神。
• 星球与光的结合：图案中包含星球和光束，象征着远大目标和追求光速般的进步，展示了团队在不断追求卓越的同时，兼顾稳健和持续的进展。

团队成员

团队合照

团队愿景

我们希望成为一个紧密合作的学生团队，通过实践和项目互相学习，提升技术能力，开发实用的应用，最终在校内外获得认可，为未来职业发展奠定基础。

第一次团队作业

1. 引言

1.1 目的

本项目旨在开发一款名为“行趣”的智能旅行规划应用，利用人工智能技术为用户提供个性化的旅行推荐和实时动态调整的服务。该应用将基于用户的历史数据、偏好信息以及实时天气情况，生成灵活的旅行计划，并且能够处理旅行过程中的突发事件。

1.2 项目背景

随着旅游业的快速发展以及移动应用的普及，用户对个性化、灵活的旅行规划需求日益增长。现有的旅游应用在智能化程度、个性化推荐、实时信息更新和突发事件处理方面存在不足。因此，“行趣”通过集成大语言模型和实时数据API，旨在填补这一市场空白，为用户提供更智能、更贴合需求的旅行服务。

1.3 定义

• API：应用程序接口，指应用与外部系统之间的数据交互方式。
• 用户偏好：根据用户的历史旅行记录、预算、兴趣等定制的个性化需求。
• 模块

  用户身份验证模块（Authentication Module）：A
  产品管理模块（Product Management Module）：PM
  个性化旅行推荐模块(Personalized travel recommendation module)：PTR
  气象感知行程模块（Weather-aware trip module）：WT

• 功能类别

  功能需求（Functional Requirements）：FR
  性能需求（Performance Requirements）：PR
  安全需求（Security Requirements）：SR

1.4 参考资料

本项目参考了百度文言一心、OpenAI GPT-3.5等大语言模型，以及OpenWeatherMap和LocationIQ等API服务。

2. 总体描述

2.1 产品概述

“行趣”是一款智能旅行规划应用，旨在通过AI技术为用户提供个性化旅行推荐服务。它集成了大语言模型，能够根据用户输入的需求生成最优的旅行路线，并结合实时天气、交通、和地理位置信息进行调整。

2.2 用户特点

目标用户包括：

• 年轻职场人士：由于工作繁忙，他们希望获得便捷、快速、个性化的旅行规划。
• 家庭用户：希望得到经济实惠、适合家庭成员的旅行方案，满足他们的个性化需求。

2.3 项目范围

• 用户可以通过应用输入目的地、预算、偏好等信息，系统将自动生成定制的旅行计划。
• 系统能够实时获取天气、交通等信息，并根据情况动态调整行程。
• 用户可以使用内置的智能客服获得7天24小时的旅行咨询和帮助
• 应用将提供紧急事件处理功能，帮助用户应对旅行中的突发情况。

2.4 假设与约束

2.4.1 假设

1. 用户有稳定的网络连接：应用依赖于多个外部API（如大语言模型、天气数据和地理位置信息），因此假设用户在使用应用时具有稳定的网络连接，以确保数据的实时获取和响应。
2. 用户使用的设备支持现代Web技术：假设用户的设备支持最新的Web技术和浏览器功能（如JavaScript、HTML5、CSS3），以保证应用界面的正常渲染和交互效果。
3. 外部API服务稳定可用：假设第三方API（如OpenWeatherMap、LocationIQ、百度文心一言等）能够正常提供服务，并且这些服务在整个项目的生命周期内保持稳定可用。
4. 用户信息准确有效：假设用户提供的个人信息（如旅行偏好、账号信息等）是真实且准确的，以便应用能够提供个性化的旅行推荐和服务。
5. 用户同意数据使用政策：假设所有用户在使用应用时已经同意了隐私政策和数据使用条款，允许应用收集和使用其旅行历史和偏好数据以提供个性化服务。

2.4.2 约束

1. 第三方API调用次数限制：应用集成的第三方API（如OpenWeatherMap、LocationIQ等）存在调用次数限制。应用需在这些限制内合理管理API调用，以避免超出每日配额，影响用户体验。
2. 数据安全与隐私保护：应用必须严格遵守数据安全和隐私保护相关法律法规，确保用户数据的加密存储和传输，避免敏感信息泄露。
3. 系统响应时间：系统必须保证在大部分场景下的响应时间不超过2秒，尤其是在旅行推荐和天气信息更新等核心功能上，提供流畅的用户体验。
4. 系统扩展性：项目架构设计需具备扩展性，能够在未来轻松增加新功能或集成新的API服务。同时，系统需支持一定程度的并发访问，确保能应对突发的用户增长需求。
5. UI与用户体验一致性：应用的UI设计和交互体验必须保持一致，遵循跨平台的一致性设计原则，无论用户使用移动端还是桌面端，都应能享受一致的体验。

3. 功能需求

思维导图

3.1 用户身份验证模块

3.1.1 总体概述

用户身份验证模块负责确保只有授权用户能够访问系统。该模块包含登录、图片滑动验证码、身份验证和安全性措施等功能。

3.1.2 具体需求

需求编号	产品功能编号	需求描述	优先级	验收标准
A-FR-001	FUNC-001	用户必须通过有效的账号和密码进行身份认证。	高	在登录界面，用户应能够输入有效的账号和密码，并成功登录系统。
A-SR-001	FUNC-002	系统应当实施图片滑动验证码以防止机器人和暴力破解攻击。	中	在登录界面，用户应能够成功通过图片滑动验证码，并且验证码应难以被自动化程序绕过。
A-FR-002	FUNC-003	系统应当根据用户的角色权限进行访问控制。	高	在登录界面，用户应当仅能访问其具有权限的功能和数据。

3.1.2.1 登录功能描述

需求编号	需求描述	优先级	验收标准
A-FR-003	用户通过输入账号和密码完成登录。	高	用户在登录界面输入账号和密码后，点击“登录”按钮，系统验证成功后进入系统。
A-FR-004	登录失败时应提供明确的错误提示。	高	用户输入错误的账号或密码时，系统应提示“账号或密码错误”。

3.1.2.2 图片滑动验证码

需求编号	需求描述	优先级	验收标准
A-SR-002	系统应在登录时提供图片滑动验证码。	中	用户在登录时，系统应显示图片滑动验证码，用户完成验证后才能继续登录。
A-SR-003	滑动验证码验证失败时应重新生成。	低	用户滑动验证码错误时，系统应重新生成新的验证码，并提示用户重新验证。

3.1.2.3 用户角色和权限

需求编号	需求描述	优先级	验收标准
A-FR-004	系统应根据用户角色分配权限	高	用户登录后，系统应根据用户角色分配不同的功能访问权限。

3.2 个性化旅行推荐

3.2.1 总体概述

用户通过输入旅行目的地、日期、预算和个人偏好，系统使用大语言模型API生成个性化的旅行方案。
系统根据用户的历史旅行数据进行推荐，并支持手动修改和优化。

3.2.2 功能类图

3.2.3 具体需求

需求编号	产品功能编号	需求描述	优先级	验收标准
PTR-FR-001	FUNC-004	用户能够输入旅行目的地、时间和偏好信息。	高	在推荐页面，用户应能够输入旅行目的地、时间和偏好，并提交这些信息以生成个性化的旅行推荐。
PTR-FR-002	FUNC-005	系统应根据用户输入生成个性化的旅行推荐方案。	高	系统应基于用户的输入信息生成旅行推荐，并展示包含详细行程、酒店推荐和景点规划的方案。
PTR-SR-001	FUNC-006	系统应动态调整旅行计划以应对实时变化。	中	当天气或其他条件发生变化时，系统应能够自动调整用户的行程推荐并通知用户。

3.2.3.1 目的地选择与用户偏好

需求编号	需求描述	优先级	验收标准
PTR-FR-003	用户能够选择旅行目的地。	高	用户在推荐页面选择目的地后，系统应将目的地信息应用于行程推荐中。
PTR-FR-004	用户能够设置个人旅行偏好。	中	用户能够设置偏好（如预算、交通工具、活动类型等），系统应基于这些偏好生成相应的旅行推荐。

3.2.3.2 个性化旅行方案生成

需求编号	需求描述	优先级	验收标准
PTR-FR-005	系统应生成个性化的旅行行程。	高	系统应根据用户输入的目的地、时间、预算和偏好生成详细的旅行行程，行程应包括每日的活动安排、推荐景点和餐饮。
PTR-FR-006	系统应提供住宿、餐饮和景点推荐。	中	系统应根据用户输入的偏好提供住宿、餐饮和景点的推荐，并展示相关信息。

3.2.3.3 实时动态调整

需求编号	需求描述	优先级	验收标准
PTR-SR-002	系统应根据实时天气信息调整行程。	中 当天气预报显示不适宜的天气时，系统应自动调整行程，建议用户更改活动安排。
PTR-SR-003	系统应根据突发事件或紧急情况动态调整行程。	中	系统应能够处理用户旅行中的突发事件（如交通问题、活动取消），并为用户提供替代方案。

3.2.4 原型设计图

3.3 气象感知行程模块

3.3.1 总体概述

天气影响行程模块负责根据实时天气信息动态调整用户的旅行计划，确保用户能够在安全、舒适的条件下进行旅行。该模块包含天气信息获取、天气预警、行程动态调整等功能。

3.3.2 功能类图

3.3.3 具体需求

需求编号	产品功能编号	需求描述	优先级	验收标准
WT-FR-001	FUNC-007	系统应自动获取用户旅行目的地的实时天气信息。	高	系统应能够在用户选择目的地后，自动从天气API获取实时天气数据并展示在行程推荐页面。
WT-SR-001	FUNC-008	系统应根据天气变化自动调整行程计划。	高	当天气发生变化时，系统应能够根据预设规则调整行程并通知用户，提示用户活动的时间或地点变更。
WT-SR-002	FUNC-009	系统应提供极端天气预警功能。	中	当目的地出现极端天气（如暴雨、暴风雪等）时，系统应提前向用户发送预警，建议更改行程或取消某些活动。

3.3.3.1 天气信息获取

需求编号	需求描述	优先级	验收标准
WT-FR-002	系统应自动从天气API获取实时天气数据。	高	在用户选择旅行目的地后，系统应通过API获取实时天气信息，并在行程页面显示温度、降雨量、风速等信息。
WT-FR-003	系统应根据用户的旅行日期预测未来天气。	中	系统应根据用户设置的旅行时间段，预测未来几天的天气情况，并在行程推荐中显示。

3.3.3.2 天气预警功能

需求编号	需求描述	优先级	验收标准
WT-SR-003	系统应在检测到极端天气时发出预警。	高	当天气预报显示暴雨、暴风雪或其他极端天气时，系统应通过通知提醒用户，并建议重新安排行程。
WT-SR-004	系统应在特殊天气情况下建议调整行程。	中	系统在检测到不利的天气情况时，应根据天气影响（如下雨、低温等）建议用户调整活动时间或更改活动地点。

3.3.3.3 行程动态调整

需求编号	需求描述	优先级	验收标准
WT-FR-004	系统应根据天气自动调整旅行活动时间。	中	系统应能够自动调整行程中受天气影响的活动，并在行程页面向用户显示新的活动时间安排。
WT-FR-005	系统应在不适合户外活动的天气情况下提供替代方案。	中	当检测到旅行目的地的天气不适合户外活动时，系统应为用户提供室内活动或其他替代方案，并展示在行程中。

3.3.4 原型设计图

4. 非功能性需求

4.1 性能要求

• 系统响应时间应小于2秒，确保用户在进行旅行方案查询和调整时能获得即时反馈。
• 系统应能支持至少100名用户的同时访问，保证在高并发情况下仍能正常运行。
• 数据处理和旅行方案生成的时间应不超过10秒，以提供流畅的用户体验。

4.2 兼容性要求

• 系统应兼容不同的移动设备操作系统（如Android、iOS）。
• 前端应基于响应式设计，确保在各种屏幕尺寸和分辨率下良好的显示效果。

4.3 安全性要求

• 系统必须采用SSL加密传输用户数据，确保用户信息在传输过程中不会被窃取或篡改。
• 用户数据（包括旅行偏好、账号信息等）应经过加密存储，避免未经授权的访问。

4.4 可维护性要求

• 系统应遵循模块化设计，便于后期的功能扩展和维护。
• 代码应有良好的注释和文档，便于开发者后期进行维护和修改。
• 系统应提供日志记录功能，便于在问题发生时进行调试和修复。

4.5 可用性要求

• 系统的界面应简单直观，操作步骤应尽可能减少，确保用户可以轻松上手使用。
• 系统应提供详细的帮助文档和FAQ，帮助用户解决常见问题。
• 用户在访问系统时，不应频繁遇到停机或故障，系统的可用性应达到99.9%以上。

5. 系统接口

5.1 用户接口

• 系统应提供一个简洁的用户登录和注册界面，支持账号密码登录以及第三方登录（如QQ、微信）。
• 应为用户提供旅行偏好设置界面，用户可以选择目的地、旅行预算、偏好活动等。
• 系统应具备旅行方案的可视化界面，显示推荐的行程、天气信息和调整建议。

5.2 硬件接口

• 系统服务器应能够与本地存储设备和备份系统相连接，确保数据安全和高效存储。
• 应支持连接不同的移动设备（如智能手机、平板电脑）以保证用户能够通过多终端访问。

5.3 软件接口

• 系统应通过API与外部大语言模型（如OpenAI、百度文心一言）进行连接，实现个性化旅行推荐。
• 系统应与第三方天气API（如OpenWeatherMap）和地理位置API（如LocationIQ）集成，实时获取天气和位置数据。
• 系统应支持与数据库（如MySQL）进行交互，以存储和查询用户数据及旅行历史记录。

5.4 通信接口

• 系统与外部API通信应使用HTTPS协议，确保数据传输的安全性。
• 后端服务器与前端应用之间应采用RESTful API进行通信，前端使用Axios或类似的库进行数据请求。

6. 其他需求

6.1 数据库需求

• 数据库应具备高可用性和可扩展性，支持大量用户数据的存储和快速查询。
• 数据库应具备定期备份机制，确保数据的安全性和完整性。
• 所有用户的旅行历史、推荐方案、登录信息和偏好数据应存储在数据库中，并提供优化的查询功能。

6.2 法规和标准遵从

• 系统必须遵守《中华人民共和国网络安全法》等相关法律法规，确保数据处理和存储的合规性。
• 系统应符合GDPR等国际数据隐私保护法规，确保用户的个人隐私数据得到有效保护。

6.3 可移植性

• 系统应能够在不同的操作系统（如Linux、Windows）上正常运行。

7. 附录

修订历史

版本	日期	修订人	修订内容
0.0.1v	2024-10-22	施靖杰	初始版本