第一次团队作业

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

前端组

后端组

测试组

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

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

  • 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

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

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

目标用户包括:

  • 年轻职场人士:由于工作繁忙,他们希望获得便捷、快速、个性化的旅行规划。
  • 家庭用户:希望得到经济实惠、适合家庭成员的旅行方案,满足他们的个性化需求。
  • 用户可以通过应用输入目的地、预算、偏好等信息,系统将自动生成定制的旅行计划。
  • 系统能够实时获取天气、交通等信息,并根据情况动态调整行程。
  • 用户可以使用内置的智能客服获得7天24小时的旅行咨询和帮助
  • 应用将提供紧急事件处理功能,帮助用户应对旅行中的突发情况。

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.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.1 总体概述

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

3.2.2 功能类图

3.3.2 功能类图


特别提示:本信息由相关用户自行提供,真实性未证实,仅供参考。请谨慎采用,风险自负。


举报收藏 0评论 0
0相关评论
相关最新动态
推荐最新动态
点击排行
{
网站首页  |  关于我们  |  联系方式  |  使用协议  |  隐私政策  |  版权隐私  |  网站地图  |  排名推广  |  广告服务  |  积分换礼  |  网站留言  |  RSS订阅  |  违规举报  |  鄂ICP备2020018471号